Alternâncias e failovers

APLICA-SE A:2016 2019 Subscription Edition

As ativações pós-falha e as ativações pós-falha são as duas formas de interrupções no Microsoft Exchange Server:

• Uma transição é uma falha agendada de uma base de dados ou servidor que é explicitamente iniciada por um cmdlet ou pelo sistema de disponibilidade gerido no Exchange Server. Normalmente, as transições são feitas para preparar a execução de uma operação de manutenção. As transições envolvem mover a cópia ativa da base de dados da caixa de correio para outro servidor no grupo de disponibilidade da base de dados (DAG). Se não for encontrado nenhum destino em bom estado de funcionamento durante uma transição, os administradores receberão um erro e a base de dados da caixa de correio permanecerá ativada ou montada.

• Um failover se refere a eventos inesperados que resultam na indisponibilidade de serviços, dados ou ambos. Um failover envolve a recuperação automática do sistema de uma falha por meio da ativação de uma cópia do banco de dados da caixa de correio passiva a fim de torná-la a cópia do banco de dados da caixa de correio ativa. Se não for encontrado nenhum destino em bom estado de funcionamento durante uma ativação pós-falha, a base de dados da caixa de correio será desmontada.

Exchange Server foi concebido para processar as ativações pós-falha e as ativações pós-falha.

Procurando tarefas de gerenciamento relacionadas à alta disponibilidade e à resiliência de site? Consulte Gerenciando a alta disponibilidade e resiliência do site.

Alternâncias

Existem três tipos de comutação no Exchange Server:

• Alternâncias de banco de dados

• Alternâncias de servidor

• Alternâncias de datacenter

Alternâncias de banco de dados

Uma alternância de banco de dados é o processo por meio do qual um banco de dados ativo individual é trocado por outra cópia do banco de dados (uma cópia passiva), e essa cópia do banco de dados torna-se a nova cópia do banco de dados ativo. Alternâncias de banco de dados podem acontecer dentro de datacenters e entre eles. Pode efetuar uma transição de base de dados com o Centro de administração do Exchange (EAC) ou a Shell de Gestão do Exchange. Independentemente da interface usada, o processo de alternância é o seguinte:

1. O administrador inicia uma alternância de banco de dados para mover a cópia atual do banco de dados da caixa de correio ativa para outro servidor.

2. O cliente utilizado para a tarefa realiza uma chamada RPC para o serviço de Replicação do Microsoft Exchange em um membro do DAG.

3. Se o membro do DAG não mantiver a função de Gerenciador Ativo Primário (PAM), este remeterá a tarefa para o servidor que mantiver a função PAM.

4. A tarefa realiza uma chamada RPC para o serviço de Replicação do Microsoft Exchange no servidor que mantém a função PAM.

5. O PAM lê e atualiza as informações de localização do banco de dados que estão armazenadas no banco de dados de cluster do DAG.

6. O PAM entra em contato com o serviço de Replicação do Microsoft Exchange no membro do DAG cuja cópia passiva está sendo ativada como a nova cópia do banco de dados da caixa de correio ativa.

7. O serviço de Replicação do Microsoft Exchange no servidor de destino consulta os serviços de Replicação do Microsoft Exchange em todos os outros membros do DAG para determinar a melhor fonte de log para a cópia do banco de dados.

8. O banco de dados do servidor atual é desmontado, e o serviço de Replicação do Microsoft Exchange no servidor de destino copia os logs restantes para o servidor de destino.

9. O serviço de Replicação do Microsoft Exchange no servidor de destino solicita a montagem de um banco de dados.

10. O serviço de Armazenamento de Informações do Microsoft Exchange no servidor de destino repete os arquivos de log e monta o banco de dados.

11. Quaisquer códigos de erro são retornados para o serviço de Replicação do Microsoft Exchange do servidor de destino.

12. O PAM atualiza as informações do estado da cópia do banco de dados no banco de dados de cluster do DAG.

13. Quaisquer códigos de erro são retornados pelo serviço de Replicação do Microsoft Exchange do servidor de destino para o serviço de Replicação do Microsoft Exchange do PAM.

14. O serviço de Replicação do Microsoft Exchange do PAM retorna quaisquer erros para a interface administrativa em que a tarefa foi chamada.

15. O PowerShell Remoto retorna os resultados da operação para a interface administrativa de chamada.

Para obter etapas detalhadas sobre como realizar um alternância de banco de dados, consulte Ativar uma cópia do banco de dados de caixa de correio.

Alternâncias de servidor

Uma alternância de servidor é o processo pelo qual todos os bancos de dados ativos em um membro do DAG são ativados em um ou mais outros membros do DAG. Tal como as transições de base de dados, pode ocorrer uma ativação de comutação de servidor num datacenter e entre datacenters e pode ser iniciada através do EAC e da Shell de Gestão do Exchange. Independentemente da interface utilizada, o processo de alternância do servidor é o seguinte:

1. O administrador inicia uma alternância de servidor para mover todas as cópias atuais do banco de dados da caixa de correio ativas para um ou mais servidores diferentes.

2. A tarefa segue as mesmas etapas descritas anteriormente, neste tópico, para alternâncias de banco de dados (Etapas 2 a 4) para cada um dos bancos de dados ativos no servidor atual.

3. O PAM lê e atualiza as informações de localização do banco de dados que estão armazenadas no banco de dados de cluster do DAG.

4. O PAM entra em contato com o serviço de Replicação do Microsoft Exchange de cada membro do DAG que possui uma cópia passiva sendo ativada.

5. O serviço de Replicação do Microsoft Exchange nos servidores de destino consulta os serviços de Replicação do Microsoft Exchange em todos os outros membros do DAG para determinar a melhor fonte de log para a cópia do banco de dados.

6. O banco de dados do servidor atual é desmontado, e o serviço de Replicação do Microsoft Exchange de cada servidor de destino copia os logs restantes.

7. O serviço de Replicação do Microsoft Exchange em cada servidor de destino solicita a montagem de um banco de dados.

8. O serviço de Armazenamento de Informações do Microsoft Exchange de cada servidor de destino repete os arquivos de log e monta o banco de dados.

9. Quaisquer códigos de erro são retornados para o serviço de Replicação do Microsoft Exchange do servidor de destino.

10. O PAM atualiza as informações do estado da cópia do banco de dados no banco de dados de cluster do DAG.

11. Quaisquer códigos de erro são retornados pelo serviço de Replicação do Microsoft Exchange do servidor de destino para o serviço de Replicação do Microsoft Exchange do PAM.

12. O serviço de Replicação do Microsoft Exchange do PAM retorna quaisquer erros para a interface administrativa em que a tarefa foi chamada.

13. O PowerShell Remoto retorna os resultados da operação para a interface administrativa de chamada.

Para obter os passos detalhados sobre como efetuar uma ativação de comutação de servidor, veja efetuar uma ativação de comutação de servidor.

Switchovers do Datacenter

Em uma configuração resiliente do site, a recuperação automática como resposta a uma falha no nível do site pode ocorrer dentro de um DAG, o que permite que o sistema de mensagens permaneça em um estado funcional. Essa configuração exige pelo menos três locais, devido ao fato de exigir a implantação dos membros DAG em dois locais e do servidor testemunha do DAG em um terceiro local.

Se não tiver três localizações ou mesmo que tenha três localizações, mas quiser controlar as ações de recuperação ao nível do datacenter, pode configurar um DAG para recuperação manual se ocorrer uma falha ao nível do site. Nesse caso, você executaria um processo chamado alternância de datacenter. Assim como em muitos cenários de recuperação de desastres, o planejamento e a preparação antecipados para uma alternância de datacenter podem simplificar o processo de recuperação e reduzir a duração da interrupção. Para obter os passos detalhados para efetuar uma ativação de comutação do datacenter, veja Datacenter switchovers (Comutadores de Datacenter)

Failovers

Um failover é um processo de ativação automático que pode ocorrer no banco de dados, no servidor ou no nível do datacenter. Os failovers ocorrem em resposta a uma falha que afeta um banco de dados individual (por exemplo, uma perda de armazenamento isolada), um servidor completo (por exemplo, uma falha na placa mãe ou perda de energia) ou um site completo (por exemplo, a perda de todos os membros DAG em um site).

Os DAGs e as cópias do banco de dados da caixa de correio fornecem redundância completa (e recuperação rápida) tanto dos dados como dos serviços que fornecem acesso aos dados. A tabela seguinte lista as ações de recuperação esperadas para várias falhas. Algumas falhas exigem que o administrador inicie a recuperação, e outras são tratadas automaticamente pelo sistema.

Descrição	Ativação automática	Ação de reparo automático	Estado durante o reparo: Ativo	Estado durante o reparo: Passivo	Ações de reparo	Comments
Falha simples no banco de dados do Mecanismo de Armazenamento Extensível (ESE): As unidades que armazenam o banco de dados estão retornando erros em algumas leituras (por exemplo, um erro -1018).	Possível interrupção breve. Possível failover automático.	Correção automática de página incorreta.	Alternância manual, failover automático ou reparo online.	Falhou	Recompilação de RAID, reparo do banco de dados e da cópia do banco de dados, restauração e execução da recuperação em vez de correção da página ou correção de página da cópia.	Pode haver outros códigos de falhas simples do banco de dados. Não inclui falhas de bloco do sistema de arquivos NTFS. Se o failover ou a alternância forem executados, o servidor de host será atualizado.
Falha na base de dados " semi-suave" do ESE: as unidades que armazenam a base de dados estão a devolver erros em algumas escritas.	Breve interrupção durante o failover automático.	Recompilação automática do disco/volume após possível substituição da unidade.	Desmontado se não for possível recuperá-lo.	Falhou	A recompilação de RAID pode resolver o problema. Cópia e reparo, restauração e execução da recuperação ou recompilação do disco/volume após possível substituição.	Um erro semissuave de gravação do ESE significa que algumas gravações foram bem-sucedidas. Não inclui falha de bloco NTFS.
Falha "semissuave" de log do ESE: As unidades que armazenam os dados de log estão retornando erros não recuperados em algumas leituras ou gravações.	Breve interrupção durante o failover automático.	Recompilação automática do disco/volume após possível substituição da unidade.	Desmontado se não for possível recuperá-lo.	Falhou	A recompilação de RAID pode resolver o problema. Cópia e reparo, restauração e execução da recuperação ou recompilação do disco/volume após possível substituição.	Um erro semissuave de leitura/gravação do ESE significa que algumas leituras/gravações foram bem-sucedidas. Se o banco de dados falhar, a recuperação automática ocorrerá antes de o processo de recuperação de dados de log começar.
Erro de software ou esgotamento de recursos do ESE: Um erro em que o ESE finaliza a instância (por exemplo, Evento ID 1022, profundidade do ponto de verificação muito alta).	Breve interrupção durante o failover automático.	Nenhuma.	Desmontado se não for possível recuperá-lo.	Falhou	Correção de problema de recurso subjacente.	Essa falha poderia ser o erro de superfície dos outros casos.
Falhas de bloco NTFS: As unidades que armazenam o banco de dados ou os logs apresentam erro de leitura ou gravação em uma estrutura de controle NTFS.	Breve interrupção durante o failover automático.	Volume reconstruído após possível substituição da unidade.	Desmontado se não for possível recuperá-lo.	Falhou	A recompilação de RAID pode resolver o problema. Os utilitários para NTFS podem resolver os problemas com NTFS. A recuperação do Exchange pode ser necessária.	É mais provável que esta situação ocorra quando o RAID não está a ser utilizado. Se este cenário afetar o volume de registo ativo, alguns ficheiros de registo recentes serão perdidos. Não inclui erros corrigidos automaticamente pelo NTFS ou sua pilha de hardware ou software subjacente.
Falha na base de dados ou na unidade de registo: uma unidade que armazena a base de dados ou os registos falhou e está inacessível.	Breve interrupção durante o failover automático.	Unidade reformatada ou substituída, seguida de recompilação completa de volume.	Desmontado se não for possível recuperá-lo.	Falhou	Substituição de unidade seguida de possível recompilação de RAID. Substituição de unidade seguida de recompilação completa de volume. Recompilação completa de volume.	Não se aplica.
Falha de volume de log ou banco de dados: O volume falha por causa de problemas de volume de nível inferior ou NTFS.	Breve interrupção durante o failover automático.	Unidade reformatada ou substituída.	Desmontado se não for possível recuperá-lo.	Falhou	Substituição de unidade seguida de possível recompilação de RAID. Substituição de unidade seguida de recompilação completa de volume. Recompilação completa de volume.	Não se aplica.
Banco de dados ou volume de log sem espaço: O sistema de arquivos NTFS com o banco de dados ou os arquivos de log está sem espaço.	Failover automático se outra cópia não estiver em estado similar.	Nenhuma.	Desmontado.	Falhou	Execução de backups completos ou incrementais, exclusão manual de logs, espera de intervalo de tempo, continuação da cópia do banco de dados ou reparo da cópia do banco de dados com falha.	Não se aplica.
O administrador desmonta o banco de dados errado.	Se o failover automático não estiver bloqueado pelo administrador, haverá uma breve interrupção. Se o failover automático estiver protegido, haverá uma interrupção até que o banco de dados seja montado.	Nenhuma.	Desmontado.	Não se aplica.	O administrador corrige o erro.	Não se aplica.
O administrador suspende a cópia do banco de dados errada.	Dependendo da configuração e da cópia afetada, a recuperação automática poderá ser evitada.	Nenhuma.	Não se aplica.	Suspenso	O administrador corrige o erro.	Não se aplica.
O administrador desmonta um banco de dados para armazenamento, NTFS ou manutenção do volume.	Se o failover automático não estiver bloqueado pelo administrador, haverá uma breve interrupção. Se o failover automático estiver bloqueado, haverá interrupção até que o administrador conclua a tarefa.	Nenhuma.	Desmontado.	Não se aplica	O administrador conclui a tarefa.	Não se aplica.
O administrador suspende uma cópia do banco de dados para armazenamento, NTFS ou manutenção do volume.	Dependendo da configuração e da cópia afetada, a recuperação automática poderá ser evitada.	Nenhuma.	Não se aplica.	Suspenso	O administrador conclui as ações.	Não se aplica.
O administrador desmonta um banco de dados para manutenção de banco de dados offline.	Interrupção até ser reparado.	Nenhuma.	Desmontado.	Suspenso	O administrador conclui as ações.	Há divergência entre cópias ativas e passivas do banco de dados. O administrador deve suspender as cópias.
Falha do controlador de armazenamento, de disco ou da rede da área de armazenamento (SAN).	Breve interrupção durante o failover automático.	Nenhuma.	Desmontado.	Qualquer	Reparo do hardware.	Uma cópia do banco de dados passiva estará no estado em que se encontrava quando o sistema apresentou falha.
Manutenção do hardware do servidor.	Breve interrupção durante o failover automático (a menos que bloqueado por um administrador).	Nenhuma.	Desmontado.	Qualquer	Conclusão das ações.	Uma cópia do banco de dados passiva estará no estado em que se encontrava quando o sistema foi encerrado.
Manutenção do software do servidor.	Breve interrupção durante o failover automático (a menos que bloqueado por um administrador).	Nenhuma.	Desmontado.	Qualquer	Conclusão das ações.	Uma cópia do banco de dados passiva estará no estado em que se encontrava quando o sistema foi encerrado.
O serviço Arquivo de Informações do Microsoft Exchange é parado ou colocado em pausa por um administrador.	Breve interrupção durante o failover automático.	Nenhuma.	Desmontado.	Qualquer	Reinicie o serviço Arquivo de Informações do Microsoft Exchange.	Não aplicável.
O serviço Arquivo de Informações do Microsoft Exchange falha; O sistema operativo ainda está em execução.	Breve interrupção durante o failover automático.	O Service Control Manager reinicia o serviço Microsoft Exchange Information Store.	Desmontado.	Qualquer	Reinicie manual ou automaticamente o serviço Microsoft Exchange Information Store.	Uma cópia passiva da base de dados estará no estado que existia quando o serviço Arquivo de Informações do Microsoft Exchange falhou.
Falha parcial do serviço Arquivo de Informações do Microsoft Exchange; parte do arquivo do Exchange deixa de funcionar, mas não é identificada como falha completa.	Possível interrupção breve durante o failover automático.	Nenhuma.	Montado e parcialmente funcional.	Qualquer um, mas pode estar parcialmente funcional.	Reinicie o servidor, o sistema operativo ou o serviço Microsoft Exchange Information Store.	Não aplicável.
Falha do servidor: O servidor apresentou falha por causa de um dos seguintes motivos: Falha completa de energia Falha não recuperada do chip do processador, da placa-mãe ou do painel traseiro Erro de parada do sistema operacional O sistema operacional parou de responder Falha total na comunicação	Breve interrupção durante o failover automático.	Reinicializar o computador.	Desmontado.	Qualquer	Restauração de energia, alteração das configurações do sistema operacional, alteração das configurações de hardware, substituição do hardware, reinicialização do sistema operacional, manutenção do sistema operacional, manutenção do hardware ou reparo de problemas na comunicação.	Não se aplica.
O DAG apresenta falha de quorum.	Interrupção até ser reparado.	Nenhuma.	Desmontado.	Qualquer	Reparo do quorum com falha, atribuição de novo quorum ou restauração da rede que está causando a falha no quorum.	Uma cópia do banco de dados passiva estará no estado em que se encontrava quando o sistema apresentou falha.
Falha na comunicação da rede MAPI: O servidor não está mais disponível na rede MAPI.	Breve interrupção durante o failover automático; deve estar sem perdas.	Nenhuma. Continua havendo tentativas de comunicação.	Desmontado.	Qualquer	Correção do problema de comunicação ao corrigir problemas de hardware ou software.	Não aplicável.
Falha na comunicação da rede de replicação: o servidor não pode receber heartbeats, cópias de registo ou semente através da rede de replicação com falha.	Pode haver breve interrupção de cópias e propagações enquanto a carga de trabalho é transferida para outra rede.	Nenhuma. Continua havendo tentativas de comunicação.	Nenhuma.	Qualquer	Correção do problema de comunicação ao corrigir problemas de hardware ou software.	Resiliência afetada por falha.
Falha de comunicação de rede múltipla: o servidor não pode receber heartbeats, cópias de registo ou semente através de várias redes.	Breve interrupção durante o failover automático; deve estar sem perdas.	Nenhuma. Continua havendo tentativas de comunicação.	Desmontado.	Qualquer	Correção do problema de comunicação ao corrigir problemas de hardware ou software.	Pelo menos uma rede ainda está funcionando.
Falha parcial de uma ou mais redes: Redes apresentam altas taxas de erro.	Falha não detectada; nenhuma ação.	Nenhuma.	Montado, mas há possíveis problemas de desempenho.	Qualquer	Correção do problema de comunicação ao corrigir problemas de hardware ou software.	Redes apresentam taxas de erro mais altas do que o normal.
Travamento não detectado do sistema operacional: O sistema operacional parou de responder, mas não foi detectado pelo monitoramento ou cluster.	Nenhuma.	Nenhuma.	Qualquer um.	Qualquer	Reiniciar ou encerrar os recursos que não estão respondendo.	O travamento não foi detectado, portanto nenhuma ação foi executada. Algumas funcionalidades podem ser operacionais.
A unidade do sistema operacional apresenta falha.	Breve interrupção durante o failover automático.	Nenhuma.	Desmontado.	Qualquer	Substituição da unidade e reconstrução do servidor ou do volume usando RAID.	Não se aplica.
A unidade do sistema operacional está sem espaço.	Breve interrupção durante o failover automático.	Nenhuma.	Desmontado.	Qualquer	Liberação manual de espaço no volume.	Não aplicável.
A unidade que contém binários do Exchange tem uma falha de volume ou unidade.	Breve interrupção durante o failover automático.	Nenhuma.	Desmontado.	Qualquer	Substituição da unidade e reinstalação do aplicativo ou reconstrução do volume usando a RAID.	Não aplicável.
A unidade que contém os binários do Exchange está sem espaço.	Breve interrupção durante o failover automático.	Nenhuma.	Desmontado.	Qualquer	Liberação manual de espaço no volume.	Não se aplica.
Novo log inválido detectado: A sequência de log foi interrompida por um arquivo existente.	Breve interrupção durante o failover automático; assume outras cópias que não têm o mesmo problema.	Nenhuma.	Desmontado.	Falhou	Remoção dos logs destrutivos após a determinação de sua origem.	Os logs destrutivos não devem replicar.
A replicação contínua detecta log inválido: A repetição detecta um log inadequado durante uma cópia ou repetição.	Não se aplica.	Descartar log.	Não se aplica.	Falhou	Descarte do log inválido; movimentação do fluxo do log de impacto.	Não se aplica.

Failovers de banco de dados

Um failover de banco de dados ocorre quando uma cópia do banco de dados que estava ativa não é mais capaz de permanecer ativa. As seguintes ocorrências fazem parte de uma ativação pós-falha da base de dados:

1. A falha do banco de dados é detectada pelo serviço de Armazenamento de Informações do Microsoft Exchange.

2. O serviço de Armazenamento de Informações do Microsoft Exchange grava eventos de falha no log de eventos do canal vermelho.

3. O Gerenciador Ativo do servidor que contém o banco de dados com falha detecta os eventos de falha.

4. O Gerenciador Ativo solicita o status da cópia do banco de dados dos outros servidores que mantêm uma cópia do banco de dados.

5. Os outros servidores retornam o status da cópia do banco de dados solicitado pelo Gerenciador Ativo solicitador.

6. O PAM inicia a movimentação do banco de dados ativo para outro servidor no DAG usando um algoritmo de seleção de melhor cópia.

7. O PAM atualiza o local de montagem do banco de dados no banco de dados do cluster para consultar o servidor selecionado.

8. O PAM envia uma solicitação para o Gerenciador Ativo do servidor selecionado para se tornar o mestre do banco de dados.

9. O Gerenciador Ativo do servidor selecionado solicita que o serviço de Replicação do Microsoft Exchange tente copiar os últimos logs do servidor anterior e defina o sinalizador montável do banco de dados.

10. O serviço de Replicação do Microsoft Exchange copia os logs do servidor que anteriormente tinham a cópia ativa do banco de dados.

11. O Gerenciador Ativo lê o número de geração de log máximo a partir do banco de dados do cluster.

12. O serviço de Armazenamento de Informações do Microsoft Exchange monta a nova cópia ativa do banco de dados.

Failovers de servidor

Um failover de servidor ocorre quando o membro do DAG não é mais capaz de prestar serviços à rede MAPI ou quando o serviço do Cluster de um membro do DAG não é mais capaz de contatar os demais membros do DAG. As seguintes ocorrências fazem parte de uma ativação pós-falha do servidor:

1. O serviço de Cluster do PAM envia uma notificação para o PAM mediante uma de duas condições:

2. Nó Inativo: o servidor está acessível, mas não consegue participar em operações do DAG.

3. Rede MAPI Inativa: o servidor não pode ser contactado através da rede MAPI e, por conseguinte, não pode participar em operações da DAG.

4. Se o servidor for alcançável, o PAM entra em contato com o Gerenciador Ativo do servidor afetado e solicita que todos os bancos de dados sejam desmontados imediatamente.

5. Para cada cópia do banco de dados afetada:

6. O PAM solicita o status da cópia do banco de dados de todos os servidores do DAG.

7. O PAM recebe uma resposta de todos os membros alcançáveis e ativos do DAG.

8. O PAM tenta determinar a melhor fonte de log dentre todos os servidores que respondem ao consultar o número mais recente de geração de log de cada um dos respondentes.

9. Cada um dos servidores responde com o número de geração de log.

10. O PAM recupera o status do catálogo de índices de pesquisa atual do banco de dados do cluster.

11. Com base no número de geração de log e a integridade do catálogo de cada cópia do banco de dados, o PAM seleciona as melhores cópias a fim de ativá-las.

12. O PAM atualiza o local de montagem do banco de dados no banco de dados do cluster.

13. O PAM inicia o failover do banco de dados comunicando-se com o Gerenciador Ativo de um ou mais outros servidores.

14. O Gerenciador Ativo dos servidores selecionados solicitam que o serviço de Replicação do Microsoft Exchange tente copiar os últimos logs do servidor anterior e defina o sinalizador montável.

15. Quando o banco de dados é montável, o Gerenciador Ativo dos servidores monta os bancos de dados.

Para obter mais informações sobre o melhor processo de seleção de cópias do Gerenciador Ativo, consulte Active Manager.

Failovers de datacenter

Foram feitas alterações significativas desde o Exchange 2010 relativamente à configuração da resiliência do site. Com a simplificação do espaço de nomes, a consolidação de funções de servidor, a separação dos serviços de Acesso de Cliente e a recuperação do DAG (no Exchange Server, o espaço de nomes não precisa de ser movido com o DAG) e as alterações em torno do balanceamento de carga, Exchange Server fornece opções de resiliência do site, como a capacidade de utilizar um único espaço de nomes global. Se tiver mais de duas localizações para implementar componentes do serviço de mensagens, Exchange Server também ativa a configuração do serviço de mensagens para ativação pós-falha automática em resposta a falhas que exigiram intervenção manual em versões anteriores.

O Exchange utiliza a tolerância a falhas incorporada no espaço de nomes através de vários endereços IP, balanceamento de carga e, se necessário, a capacidade de utilizar servidores dentro e fora de serviço. Exchange Server permite utilizar a capacidade dos clientes de colocar em cache múltiplos endereços IP devolvidos a partir de um servidor DNS em resposta a um pedido de resolução de nomes. Os clientes com a capacidade de colocar em cache múltiplos endereços IP (que incluem quase todos os clientes baseados em HTTP no Exchange Server, como o Outlook, Outlook Anywhere, EAS, EWS, Outlook na Web, EAC, RPS, etc.), têm a capacidade de utilizar esses múltiplos endereços IP, o que fornece ativação pós-falha do 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 bem melhor porque se um dos endereços IP falhar, o cliente tem outros 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 perder a conectividade à matriz principal dos Serviços de Acesso de Cliente (CAS) e tiver um segundo endereço IP publicado para uma segunda matriz CAS, a recuperação para os clientes ocorre automaticamente (e em cerca de 21 segundos).

Os clientes HTTP modernos (sistemas operativos e browsers com 10 anos ou menos) trabalham com esta redundância automaticamente. A pilha HTTP pode aceitar vários endereços IP para um FQDN e, se o primeiro IP falhar (por exemplo, não conseguir ligar), tentará o PRÓXIMO IP na lista. Numa falha recuperável (ligação perdida após a sessão estabelecida, devido a uma falha intermitente no serviço em que, por exemplo, um dispositivo está a remover pacotes e precisa de ser retirado do serviço), o utilizador poderá ter de atualizar o browser.

Com a configuração adequada, a ativação pós-falha pode ocorrer ao nível do cliente e os clientes serão redirecionados automaticamente para um segundo datacenter onde os serviços de Acesso de Cliente estão em execução e os servidores que estão a executar os serviços de Acesso de Cliente irão efetuar o proxy da comunicação para o servidor da Caixa de Correio do utilizador, que continua a não ser afetado pela falha (porque não faz uma transição). Em vez de trabalhar para recuperar o serviço, o serviço recupera-se sozinho e pode concentrar-se em corrigir o problema principal (por exemplo, substituir um balanceador de carga com falha).

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 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. A chave é isolar a terceira localização falhas de rede que afetam as localizações contendo membros DAG.

Se tiver apenas dois datacenters e quiser configurar a ativação pós-falha automática, pode utilizar o Microsoft Azure como a sua terceira localização. Terá de criar uma rede virtual do Azure e ligá-la aos seus dois datacenters através de uma VPN de vários pontos. Em seguida, poderá colocar o servidor de testemunhos numa máquina virtual do Microsoft Azure. Para obter mais informações, veja Using a Microsoft Azure VM as a DAG witness server (Utilizar uma VM do Microsoft Azure como um servidor de testemunhos da DAG).