Alta disponibilidade e resiliência do site em Exchange Server

Você pode proteger seus bancos de dados de caixa de correio Exchange Server e os dados que eles contêm configurando seus servidores e bancos de dados do Exchange para alta disponibilidade e resiliência do site. Exchange Server minimiza o custo e a complexidade da implantação de uma solução de mensagens altamente disponível e resiliente, ao mesmo tempo em que fornece altos níveis de disponibilidade de serviço e dados e suporte para caixas de correio muito grandes.

Exchange Server permite que clientes de todos os tamanhos e em todos os segmentos implantem economicamente um serviço de continuidade de mensagens em sua organização, baseando-se nos recursos de replicação nativos e na arquitetura de alta disponibilidade introduzida no Exchange 2010. Para obter uma lista de alterações desde o Exchange 2010, consulte Alterações na alta disponibilidade e resiliência do site em relação às versões anteriores.

Terminologia principal

Os seguintes termos principais são importantes para entender a alta disponibilidade ou a resiliência de site:

Active Manager

Um componente interno do Exchange executado dentro do serviço de Replicação do Microsoft Exchange responsável pelo monitoramento de falhas e pela ação corretiva por meio de failover em um grupo de disponibilidade de banco de dados (DAG).

AutoDatabaseMountDial

Uma configuração de propriedade de um servidor de Caixa de Correio que determina se uma cópia de banco de dados passiva será montada como a nova cópia ativa, com base no número de arquivos de log ausentes na cópia sendo montada.

Replicação contínua - modo de bloqueio

No modo de bloqueio, cada atualização, ao ser gravada na buffer de log ativo da cópia ativa do banco de dados, também é enviada para um buffer de log em cada uma das cópias passivas da caixa de correio no modo de bloqueio. Quando o buffer de log estiver cheio, cada cópia do banco de dados desenvolve, inspeciona e cria o próximo arquivo de log na sequência de geração.

Replicação contínua - modo de arquivo

No modo de arquivo, os arquivos de log de transações fechadas são enviados da cópia ativa do banco de dados para uma ou mais cópias passivas do bancos de dados.

Grupo de disponibilidade de banco de dados

Um grupo de até 16 servidores do Exchange que hospeda um conjunto de bancos de dados replicados.

Mobilidade de banco de dados

A capacidade de um banco de dados de caixa de correio Exchange Server ser replicado e montado em outros servidores do Exchange.

Datacenter

Normalmente, isso se refere a um site do Active Directory; no entanto, pode também se referir a um local físico. No contexto desta documentação, datacenter é igual a site do Active Directory.

Modo Coordenação de Ativação de Datacenter

A propriedade da configuração do DAG que, quando habilitada, força o serviço de Replicação do Microsoft Exchange a adquirir permissão para montar bancos de dados na inicialização.

Recuperação de desastres

Qualquer processo usado para se recuperar manualmente de uma falha. Pode ser uma falha que afeta um único item, ou uma falha que afeta toda uma localização física.

API de replicação de terceiros do Exchange

Uma API fornecida pelo Exchange que permite o uso de replicação síncrona de terceiros para um DAG, ao invés de replicação contínua.

Alta disponibilidade

Uma solução que fornece disponibilidade de serviço, de dados, e recuperação automática de falhas que afetam o serviço ou dados (como uma falha de rede, armazenamento ou servidor).

Implantação incremental

A capacidade de implantar alta disponibilidade e resiliência do site após Exchange Server é instalada.

Cópia de banco de dados de caixa de correio defasada

Uma cópia de banco de dados passiva que tem um intervalo de repetição de log superior a zero.

Cópia de banco de dados de caixa de correio

Um banco de dados de caixa de correio (arquivo .edb e logs), que é ativo ou passivo.

Resiliência de caixa de correio

O nome de uma solução unificada de alta disponibilidade e resiliência de site no Exchange Server.

Disponibilidade gerenciada

Um conjunto de processos internos compostos por investigações, monitoramentos e respondentes que incorporam o monitoramento e a alta disponibilidade em todas as funções de servidor e em todos os protocolos.

*over (pronuncia-se "star over")

Abreviação de alternâncias e failovers. Uma alternância é uma ativação manual de uma ou mais cópias de bancos de dados. Um failover é uma ativação automática de uma ou mais cópias de bancos de dados após uma falha.

Rede de Segurança

Anteriormente conhecido como lixeira de transporte, este é um recurso do serviço de transporte que armazena uma cópia de todas as mensagens para os dias X . A configuração padrão é de 2 dias.

Redundância de sombra

Um recurso de servidor de transporte que fornece redundância para mensagens durante todo o tempo em que estão em trânsito.

Resiliência do site

Uma configuração que estende a infraestrutura de mensagens para multiplicar os sites de Active Directory e fornecer continuidade operacional para o sistema de mensagens no caso de uma falha afetar um dos sites.

Grupos de disponibilidade do banco de dados

Um DAG é o componente base da estrutura de alta disponibilidade e resiliência do site embutida em Exchange Server. Um DAG é um grupo de até 16 servidores do Exchange que hospeda um conjunto de bancos de dados e fornece recuperação automática no nível do banco de dados de falhas que afetam bancos de dados, redes ou servidores individuais. Qualquer servidor em um DAG pode hospedar uma cópia de um banco de dados de caixa de correio de qualquer outro servidor no DAG. Quando um servidor é adicionado a um DAG, funciona com outros servidores no DAG para oferecer recuperação automática de falhas que afetem bancos de dados de caixa de correio, como uma falha de disco ou uma falha do servidor. Para obter mais informações sobre DAGs, consulte Grupos de disponibilidade do banco de dados.

Cópias de banco de dados de caixa de correio

Os recursos de alta disponibilidade e resiliência do site usados pela primeira vez no Exchange 2010 são usados em Exchange Server para criar e manter cópias de banco de dados. Exchange Server também aproveita o conceito de mobilidade de banco de dados, que são failovers no nível do banco de dados gerenciado pelo Exchange.

A mobilidade de banco de dados desconecta bancos de dados dos servidores, adiciona suporte para até 16 cópias de um único banco de dados. Ele também oferece uma experiência nativa para a criação de cópias de um banco de dados.

Definir uma cópia de banco de dados como o banco de dados de caixa de correio ativo é conhecido como uma alternância. Quando ocorre uma falha que afeta um banco de dados ou acesso a um banco de dados e um novo banco de dados se torna a cópia ativa, esse processo é conhecido como failover. Este processo também refere-se a uma falha de servidor na qual um ou mais servidores colocam online o banco de dados que anteriormente estava online no servidor onde a falha aconteceu. Quando ocorre uma alternância ou failover, outros servidores do Exchange ficam cientes da alternância quase imediatamente e redirecionam o tráfego de clientes e mensagens para o novo banco de dados ativo.

Por exemplo, se um banco de dados ativo em um DAG falhar devido a uma falha de armazenamento subjacente, o Active Manager se recuperará automaticamente falhando em uma cópia de banco de dados em outro servidor no DAG. Em Exchange Server, a disponibilidade gerenciada fornece comportamentos para se recuperar da perda de acesso de protocolo a um banco de dados, incluindo a reciclagem de pools de trabalho de aplicativos, a reinicialização de serviços e servidores e o início de failovers de banco de dados.

Para obter mais informações sobre cópias de banco de dados de caixa de correio, consulte Cópias de banco de dados de caixa de correio.

Active Manager

Exchange Server aproveita o Active Manager para gerenciar a integridade, o status, a replicação contínua do banco de dados e o banco de dados e outros aspectos de alta disponibilidade. Para obter mais informações sobre o Active Manager, consulte Active Manager.

Resiliência do site

No Exchange 2010, era possível implantar um DAG entre dois data centers e hospedar o testemunha em um terceiro data center e habilitar o failover para a função de servidor de Caixa de Correio para um dos data centers. Mas você não conseguiu failover para a solução em si porque o namespace ainda precisava ser alterado manualmente para as funções de servidor que não são da Caixa de Correio.

No Exchange 2016 e no Exchange 2019, o namespace não precisa se mover com o DAG. O Exchange utiliza a tolerância a falhas integrada ao namespace por meio de vários endereços IP, balanceamento de carga (e se necessário, a capacidade de colocar os servidores em operação e tirá-los de operação). Os clientes HTTP modernos funcionam com esta redundância automaticamente. A pilha HTTP pode aceitar vários endereços IP para um nome de domínio totalmente qualificado (FQDN), e se o primeiro endereço IP que ela tentar tiver falha grave (ou seja, não conseguir se conectar), ela tentará o próximo endereço IP na lista. Em uma falha de software (conexão perdida após estabelecimento da sessão, talvez devido a uma falha intermitente no serviço em que, por exemplo, um dispositivo está ignorando pacotes e precisa ser retirado de operação), pode ser que o usuário precise atualizar seu navegador.

Isso significa que o namespace não é mais um ponto único de falha, como era no Exchange 2010. No Exchange 2010, talvez o maior ponto único de falha no sistema de mensagens seja o FQDN que você fornece aos usuários porque ele informa o usuário aonde ir. No paradigma do Exchange 2010, mudar onde esse FQDN vai não é tão fácil porque você precisa alterar o DNS e lidar com a latência de DNS, o que em algumas partes do mundo é muito ruim. E você tem caches de nome nos navegadores que geralmente levam cerca de 30 minutos ou mais e com os quais é preciso lidar também.

Em Exchange Server, os clientes têm mais de um lugar para ir. Quase todos os protocolos de acesso ao cliente no Exchange Server são baseados em HTTP. Exemplos incluem Outlook, EAS, EWS, Outlook na Web e EAC). Todos os clientes HTTP com suporte têm a capacidade de usar vários endereços IP, fornecendo failover no lado do cliente. Você pode configurar o DNS para lidar com vários endereços IP para um cliente durante uma resolução de nome. O cliente solicita mail.contoso.com e recebe de volta dois endereços IP ou quatro endereços IP, por exemplo. Contudo, vários endereços IP que o cliente recebe de volta serão usados de maneira confiável pelo cliente. Isso torna o cliente muito melhor porque, se um dos endereços IP falhar, o cliente terá um ou mais endereços IP alternativos para tentar se conectar. Se um cliente tentar um e ele falhar, ele aguardará cerca de 20 segundos e tentará o próximo na lista. Assim, se você perder o VIP para a matriz de serviço acesso ao cliente, a recuperação para os clientes ocorrerá automaticamente e em cerca de 21 segundos.

Os benefícios são os seguintes:

• Em Exchange Server, se você perder o balanceador de carga em seu site primário, basta desativá-lo (ou talvez desativar o VIP) e repará-lo ou substituí-lo. Os clientes que ainda não estão usando o VIP no data center secundário farão automaticamente failover para o VIP secundário sem nenhuma alteração de namespace e sem nenhuma alteração no DNS. Isso não só significa que você não precisará mais realizar a alternância, mas também que todo o tempo normalmente associado a uma recuperação de alternância de data center não será gasto. No Exchange 2010, você precisava lidar com a latência de DNS (daí, a recomendação para definir a vida útil (TTL) como 5 minutos, e a introdução da URL de failback). No Exchange 2016 e no Exchange 2019, você não precisa fazer isso porque obtém failover rápido (20 segundos) do namespace entre VIPs (datacenters).

• Como você pode fazer o failover do namespace entre os data centers, tudo o que você precisa para realizar um failover de data center é um mecanismo de failover da função de servidor de Caixa de Correio entre data centers. Para obter um failover automático para o DAG, você simplesmente arquiteta uma solução em que o DAG é dividido igualmente entre dois data centers e coloca o servidor testemunha em um terceiro local, de forma que possa ser arbitrado pelo membros do DAG em qualquer um dos data centers, independentemente do estado da rede entre os data centers que contêm os membros do DAG. Se você tiver apenas dois datacenters e um terceiro local físico não estiver disponível, você poderá colocar o servidor testemunha em uma máquina virtual do Microsoft Azure. Consulte Usar uma VM do Microsoft Azure como um servidor de testemunha DAG para obter mais informações.

• Nesse cenário, os esforços do administrador são para simplesmente corrigir o problema e não para restaurar o serviço. Você simplesmente corrige a coisa que falhou; enquanto isso, o serviço está em operação, e a integridade dos dados foi mantida. O nível de urgência e estresse que você sente ao reparar um dispositivo quebrado não é nada como a urgência e o estresse que sente quando está trabalhando para restaurar o serviço. É melhor para o usuário e menos estressante para o administrador.

Você pode permitir que o failover ocorra sem precisar realizar switchbacks (às vezes mencionadas incorretamente como failbacks). Se você perder servidores em seu datacenter primário, resultando em uma interrupção de 20 segundos para os clientes, talvez você nem se importe com a falha de volta. Nesse ponto, sua preocupação principal seria corrigir o problema principal (por exemplo, substituir o balanceador de carga com falha). Quando isso estiver online novamente e funcionando, alguns clientes começarão a usá-lo, e outros poderão continuar operacional por meio do segundo data center.

Exchange Server também fornece funcionalidade que permite que os administradores lidem com falhas intermitentes. Uma falha intermitente é quando, por exemplo, a conexão TCP inicial pode ser feita, mas nada acontece em seguida. Uma falha intermitente requer que um tipo de ação administrativa extra seja executada porque ela pode ser resultado de um dispositivo de substituição sendo colocado em operação. Enquanto este processo de reparo estiver ocorrendo, o dispositivo poderá ser ligado e aceitar algumas solicitações, mas não estará realmente pronto para atender os clientes até a execução das etapas de configuração necessárias. Nesse cenário, o administrador pode executar uma alternância de namespace simplesmente removendo o VIP do dispositivo sendo substituído a partir do DNS. Em seguida, durante esse período de serviço, nenhum cliente tentará se conectar a ele. Quando o processo de substituição tiver terminado, o administrador poderá adicionar o VIP de volta ao DNS, e os clientes finalmente começarão a utilizá-lo.

Para obter detalhes sobre como planejar e implantar a resiliência do site, consulte Planejar alta disponibilidade e resiliência do site e Implantar alta disponibilidade e resiliência do site.

API de replicação de terceiros

Exchange Server inclui uma API de replicação de terceiros que permite que as organizações usem soluções de replicação síncronas de terceiros em vez do recurso de replicação contínua interno. A Microsoft oferece suporte a soluções de terceiros que usam essa API, desde que a solução ofereça as funcionalidades necessárias para substituir todas as funcionalidades nativas de replicação contínua que são desabilitadas como resultado do uso da API. As soluções têm suporte apenas quando a API é usada dentro de um DAG para gerenciar e ativar cópias do banco de dados de caixa de correio. Não há suporte ao uso da API fora desses limites. Além disso, a solução deve atender às especificações aplicáveis de suporte a hardware do Windows. (O teste de validação não é necessário para suporte.)

Ao implantar uma solução que use a API de replicação interna de terceiros, lembre-se que o fornecedor da solução é responsável pelo suporte primário à solução. A Microsoft dá suporte aos dados do Exchange para soluções replicadas e não-replicadas. As soluções que usam a replicação de dados devem seguir a política de suporte da Microsoft para replicação de dados. Além disso, as soluções que utilizam o modelo do recurso Windows Failover Cluster devem atender os requisitos de suporte a cluster do Windows conforme descrito na Base de Conhecimento da Microsoft artigo 943984, A Política de Suporte da Microsoft Clusters de Failover do Windows Server 2008 ou Windows Server 2008 R2 Failover Clusters ou A Política de Suporte da Microsoft Clusters de Failover do Windows Server 2012.

A política de suporte para restaruação e backup da Microsoft para implantações que usam soluções baseadas em API de replicação de terceiros é a mesma que aquela para implantações nativas de replicação contínua.

Se você for um parceiro procurando informações sobre a API de replicação de terceiros, entre em contato com seu representante Microsoft.

Documentação de resiliência de site e disponibilidade elevada

A tabela a seguir contém links para tópicos que ajudarão você a aprender e gerenciar DAGs, cópias de banco de dados de caixa de correio e backup e restauração para Exchange Server.