Switchovers do Datacenter

Artigo
04/04/2023

Aplica-se a: Exchange Server 2013 SP1

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 você não tiver três locais, ou mesmo se tiver três locais mas não quiser controlar as ações de recuperação no nível do datacenter, é possível configurar o DAG para recuperação manual, caso haja uma falha de nível de 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.

There are four basic steps that you complete to perform a datacenter switchover, after making the initial decision to activate the second datacenter:

Encerrar um datacenter em execução parcial: essa etapa envolve o término dos serviços do Exchange no datacenter primário, se algum serviço ainda estiver em execução. This is particularly important for the Mailbox server role because it uses an active/passive high availability model. If services in a partially failed datacenter aren't stopped, it's possible for problems from the partially failed datacenter to negatively affect the services during a switchover back to the primary datacenter.

Importante

If network or Active Directory infrastructure reliability has been compromised as a result of the primary datacenter failure, we recommend that all messaging services be off until these dependencies are restored to healthy service.
Valide e confirme os pré-requisitos para o segundo datacenter: essa etapa pode ser executada em paralelo com a etapa 1 porque a validação da integridade das dependências de infraestrutura no segundo datacenter é amplamente independente dos primeiros serviços de datacenter. Each organization typically requires its own method for performing this step. For example, you may decide to complete this step by reviewing health information collected and filtered by an infrastructure monitoring application, or by using a tool that's unique to your organization's infrastructure. This is a critical step, because activating the second datacenter when its infrastructure is unhealthy and unstable is likely to yield poor results.
Ativar os servidores da caixa de correio: esta etapa inicia o processo de ativação do segundo datacenter. Essa etapa pode ser executada em paralelo com a etapa 4 porque os serviços do Microsoft Exchange podem lidar com interrupções de banco de dados e se recuperar. Ativar os servidores da caixa de correio envolve um processo de marcação dos servidores com falha do datacenter primário como indisponível, seguido pela ativação dos servidores no segundo datacenter. O processo de ativação dos servidores da Caixa de Correio depende se o DAG está no modo DAC (coordenação de ativação de banco de dados). Para obter mais informações sobre o modo de coordenação de ativação de banco de dados, confira Modo de Coordenação de Ativação do Datacenter.

If the DAG is in DAC mode, you can use the Exchange site resilience cmdlets to terminate a partially failed datacenter (if necessary) and activate the Mailbox servers. For example, in DAC mode, this step is performed by using the Stop-DatabaseAvailabilityGroup cmdlet. In some cases, the servers must be marked as unavailable twice (once in each datacenter). Next, the Restore-DatabaseAvailabilityGroup cmdlet is run to restore the remaining members of the database availability group (DAG) in the second datacenter by reducing the DAG members to those that are still operational, thereby reestablishing quorum. If the DAG isn't in DAC mode, you must use the Windows Failover Cluster tools to activate the Mailbox servers. After either process is complete, the database copies that were previously passive in the second datacenter can become active and be mounted. At this point, Mailbox server recovery is complete.
Ativar os servidores de Acesso ao Cliente: isso envolve o uso das informações de mapeamento de URL e a metodologia de alteração do DNS (Sistema de Nomes de Domínio) para executar todas as atualizações de DNS necessárias. The mapping information describes what DNS changes to perform. The amount of time required to complete the update depends on the methodology used and the Time to Live (TTL) settings on the DNS record (and whether the deployment's infrastructure honors the TTL).

Users should start to have access to messaging services sometime after steps 3 and 4 are completed. Steps 3 and 4 are described in greater detail later in this topic.

Terminating a Partially Failed Datacenter

Quando o DAG estiver em modo DAC, as ativações específicas para encerrar quaisquer membros DAG sobreviventes no datacenter principal são as seguintes:

When the DAG is in DAC mode, the specific actions to terminate any surviving DAG members in the primary datacenter are as follows:

The DAG members in the primary datacenter must be marked as stopped in the primary datacenter. Parado é um estado do Active Manager que impede a montagem de bancos de dados e o Active Manager em cada servidor no datacenter com falha é colocado nesse estado usando o cmdlet Stop-DatabaseAvailabilityGroup . O parâmetro ActiveDirectorySite desse cmdlet pode ser usado para marcar todos os servidores no datacenter primário, conforme interrompido com um único comando. This step may not be possible depending on the failure. This step should be taken if the state of the datacenter permits it. The Stop-DatabaseAvailabilityGroup cmdlet should be run against all servers in the primary datacenter. Se o servidor mailbox não estiver disponível, mas o Active Directory estiver operando no datacenter primário, o comando Stop-DatabaseAvailabilityGroup com o parâmetro ConfigurationOnly deve ser executado em todos os servidores nesse estado no datacenter primário ou o servidor da caixa de correio deve ser desativado. Failure to either turn off the Mailbox servers in the failed datacenter or to successfully perform the Stop-DatabaseAvailabilityGroup command against the servers will create the potential for split-brain syndrome to occur across the two datacenters. You may need to individually turn off computers through power management devices to satisfy this requirement.
The second datacenter must now be updated to represent which primary datacenter servers are stopped. Isso é feito executando o mesmo comando Stop-DatabaseAvailabilityGroup com o parâmetro ConfigurationOnly usando o mesmo parâmetro ActiveDirectorySite e especificando o nome do site do Active Directory no datacenter primário com falha. The purpose of this step is to inform the servers in the second datacenter about which mailbox servers are available to use when restoring service.

Os membros DAG no datacenter principal devem ser forçados do cluster subjacente do DAG executando os seguintes comandos em cada membro:

Os membros DAG no segundo datacenter devem agora ser reiniciados e, em seguida, usados para concluir o processo de remoção do segundo datacenter. Pare o serviço de cluster em cada membro DAG no segundo datacenter executando o seguinte comando em cada membro:
```
net stop clussvc
```
```
cluster <DAGName> node <DAGMemberName> /forcecleanup
```
Os membros da DAG no segundo datacenter agora devem ser reiniciados e usados para concluir o processo de despejo do segundo datacenter. Pare o serviço cluster em cada membro DAG no segundo datacenter executando o seguinte comando em cada membro:
```
net stop clussvc
```
On a DAG member in the second datacenter, force a quorum start of the Cluster service by running the following command:
```
net start clussvc /forcequorum
```
Open the Failover Cluster Management tool and connect to the DAG's underlying cluster. Expand the cluster, and then expand Nodes. Right-click each node in the primary datacenter, select More Actions, and then select Evict. When you're done evicting the DAG members in the primary datacenter, close the Failover Cluster Management tool.

Ativando servidores de Caixa de Correio

As etapas necessárias para ativar os membros da Caixa de Correio durante uma autenticação do datacenter também dependerão de se o DAG estiver em modo DAC. Antes de ativar os membros DAG em um segundo datacenter, recomendamos que os serviços de infraestrutura no segundo datacenter estejam prontos para ativação do serviço de mensagem.

Quando o DAG estiver em modo DAC, as etapas para a conclusão da ativação dos servidores de caixa de correio no segundo datacenter são as seguintes:

O serviço de Cluster deve ser interrompido em cada membro do DAG do segundo datacenter. Você pode usar o cmdlet Stop-Service para parar o serviço (por exemplo, Stop-Service ClusSvc), ou usar net stop clussvc de um prompt de comando elevado.
Os servidores de Caixa de Correio no datacenter em espera podem então ser ativados usando-se o cmdlet Restore-DatabaseAvailabilityGroup. O site do Active Directory do datacenter em espera é passado para o cmdlet Restore-DatabaseAvailabilityGroup a fim de identificar quais servidores serão usados para restaurar o serviço e configurar o DAG para usar um servidor testemunha alternativo. Se o servidor testemunha alternativo não tiver sido configurado anteriormente, você poderá configurá-lo usando os parâmetros AlternateWitnessServer e AlternateWitnessDirectory do cmdlet Restore-DatabaseAvailabilityGroup . Se esse comando for executado com êxito, os critérios do quorum serão reduzidos para os servidores do datacenter em espera. Se o número de servidores nesse datacenter for um número par, o DAG passará a usar o servidor testemunha alternativo conforme identificado pela configuração do objeto do DAG.
Agora, os bancos de dados podem ser ativados. Dependendo da configuração específica usada pela organização, pode ser que esse processo não seja automático. Se os servidores do datacenter em espera tiverem uma configuração de ativação bloqueada, o sistema não efetuará o failover automático do datacenter primário para o datacenter em espera de quaisquer bancos de dados. Se nenhuma restrição de failover estiver presente para qualquer uma das cópias do banco de dados no datacenter em espera, o sistema ativará as cópias no segundo datacenter considerando que estejam íntegras. Se os bancos de dados estiverem com uma configuração de ativação bloqueada que requer uma ação manual explícita, existem duas opções:
1. Desfazer a configuração que bloqueia a ativação. Isso fará o sistema retornar ao seu comportamento-padrão, que é ativar quaisquer cópias disponíveis.
2. Manter as configurações inalteradas e usar o cmdlet Move-ActiveMailboxDatabase para concluir a ativação do banco de dado no segundo datacenter. Para concluir essa etapa usando o cmdlet Move-ActiveMailboxDatabase quando a ativação bloqueada estiver definida, deve-se identificar explicitamente o destino da mudança.
A última etapa é rever todos os alertas e as mensagens de erro das tarefas. Quaisquer alertas indicados devem ser acompanhados e corrigidos. O modelo de projeto de tarefa para esses comandos é falhar somente se não puderem alcançar o objetivo fundamental de seu projeto. Por exemplo, o cmdlet Restore-DatabaseAvailabilityGroup falhará se não puder reduzir o quorum do DAG para permitir que um servidor no segundo datacenter seja reinicializado para executar os serviços sem causar uma interrupção no quorum. Contudo, cada saída de tarefa é também usada para identificar os problemas que requerem o acompanhamento do administrador. É extremamente recomendável salvar todas as saídas de tarefa e revê-las para executar ações de acompanhamento.

Quando o DAG não estiver em modo DAC, as etapas para a conclusão da ativação dos servidores de caixa de correio no segundo datacenter são as seguintes:

O quorum deve ser modificado com base no número de membros DAG no segundo datacenter.
1. Se houver um número ímpar de membros DAG, altere o modelo do quorum DAG de um Nó, um Compartilhamento de Arquivo Principais para um quorum de Nó principal executando o seguinte comando:
```
cluster <DAGName> /quorum /nodemajority
```
2. Se houver um número par de membros DAG, reconfigure o servidor e o diretório testemunha executando o seguinte comando no Shell de Gerenciamento do Exchange:
```
Set-DatabaseAvailabilityGroup <DAGName> -WitnessServer <ServerName>
```
Inicie o serviço de Cluster em quaisquer membros DAG remanescentes no segundo datacenter executando o seguinte comando:
```
net start clussvc
```
Execute alternâncias de servidor para ativar os banco de dados da caixa de correio no DAG executando o seguinte comando para cada membro DAG:
```
Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
```
Monte os banco de dados da caixa de correio em cada membro DAG no segundo site executando o seguinte comando:
```
Get-MailboxDatabase <DAGMemberinSecondSite> | Mount-Database
```

Ativando servidores de acesso para clientes

Os clientes conectam-se a pontos de extremidade de serviço (por exemplo, Outlook Web App, Descoberta automática, Exchange ActiveSync, Outlook Anywhere, POP3, IMAP4 and a matriz de Acesso para Cliente RPC) para acessar serviços e dados do Exchange. Portanto, a ativação de servidores de Acesso para Cliente requer a alteração do mapeamento dos registros de DNS desses pontos de extremidade de serviço dos endereços IP no datacenter primário para os endereços IP no datacenter secundário, que são configurados como os novos pontos de extremidade de serviço. Dependendo da sua configuração de DNS, os registros de DNS que devem ser modificados podem estar ou não na mesma zona de DNS.

Os clientes se conectarão automaticamente aos novos pontos de extremidade de serviço, de duas maneiras:

Os clientes continuarão a tentar a conexão e devem se conectar automaticamente após a TTL expirar para a entrada original do DNS e após a entrada expirar do cache DNS do cliente. Os usuários também podem executar o ipconfig /flushdns comando de um prompt de comando para limpar manualmente o cache DNS.
Os clientes que estão iniciando ou reiniciando executarão uma pesquisa de DNS na inicialização e obterão o novo endereço IP do ponto de extremidade de serviço, que será um servidor de Acesso para Cliente ou uma matriz no segundo datacenter.

Presumindo que todas as alterações de configuração adequadas foram concluídas para definir e configurar os serviços no segundo datacenter, a fim de que funcionem como se estivessem no datacenter primário, e presumindo que a configuração do DNS estabelecido está correta, não são necessárias mais alterações para ativar os servidores de Acesso para Cliente.

Ativando os serviços de transporte

Os clientes e outros servidores que enviam mensagens normalmente identificam esses servidores usando o DNS. Ativar os serviços de transporte no segundo datacenter envolve alterar os registros de DNS para apontar para o endereço IP dos servidores de Caixa de Correio no segundo datacenter. Os clientes e os servidores de envio irão se conectar automaticamente aos servidores no segundo datacenter de uma das seguintes maneiras:

Os clientes continuarão a tentar a conexão e devem se conectar automaticamente após a TTL expirar para a entrada original do DNS e após a entrada expirar do cache DNS do cliente. Os usuários também podem executar o ipconfig /flushdns comando de um prompt de comando para limpar manualmente o cache DNS.
Os clientes que estejam iniciando ou reiniciando executarão uma pesquisa de DNS na inicialização e obterão o novo endereço de IP do ponto de extremidade SMTP, que será um servidor de Caixa de Correio do segundo datacenter.

Presumindo que todas as alterações de configuração adequadas para definir e configurar os serviços no segundo datacenter de modo a que funcionem como se estivessem no datacenter primário tenham sido concluídas, e presumindo que a configuração de DNS estabelecida esteja correta, não deverão ser necessárias mais alterações para ativar os servidores de transporte.

Ativando serviços de Unificação de Mensagens

Os serviços de Unificação de Mensagens (UM) conectam-se a um sistema de PABX e às linhas telefônicas de uma organização. A conexão lógica entre o sistema de PABX e o serviço de Unificação de Mensagens é fornecida por um gateway de IP. Os gateways de IP incluem funcionalidade de alta disponibilidade e são capazes de alternar entre vários serviços de Unificação de Mensagens quando uma falha é detectada.

Se houver serviços de Mensagens Unificadas no segundo datacenter que estavam em um estado desabilitado porque são dedicados à solução de resiliência do site, eles podem ser habilitados usando o cmdlet Enable-UMService (por exemplo, Enable-UMService EX4).

Presumindo que os gateways de IP estejam associados aos serviços de Unificação de Mensagens por meio de servidores de DNS, a ativação dos serviços de Unificação de Mensagens envolverá, portanto, alterar os registros de DNS para apontar para os novos endereços IP que serão configurados para os serviços de Unificação de Mensagens no segundo datacenter. Presumindo que todas as alterações de configuração adequadas para definir e configurar os serviços no segundo datacenter de modo que funcionem como se estivessem no datacenter primário tenham sido concluídas, e presumindo que a configuração de DNS estabelecida esteja correta, não deverão ser necessárias mais alterações para ativar os serviços de Unificação de Mensagens.

Se o gateway de IP em uso não oferecer suporte ao uso de nomes de DNS para resolver os serviços de Unificação de Mensagens, serão necessárias etapas de configuração adicionais para apontar manualmente o gateway de IP para os endereços IP dos serviços de Unificação de Mensagens no segundo datacenter.

Ativando servidores de Transporte de Borda

As etapas para ativar a função do servidor de Transporte de Borda variarão dependendo da configuração específica. Os servidores de Transporte de Borda em dois datacenters podem ser configurados como ativo/passivo ou ativo/ativo. Na configuração ativo/passivo, o servidor de Transporte de Borda do segundo datacenter fica ocioso até que o segundo datacenter seja ativado. Na configuração ativo/ativo, os servidores de Transporte de Borda nos dois datacenters fazem entregas contínuas de mensagens.

Na configuração ativo/ativo, nenhuma etapa é necessária para ativar os servidores de Transporte de Borda do segundo datacenter porque eles já estão em execução. Na configuração ativo/passivo, o registro de recurso MX do DNS para cada domínio SMTP precisa ser atualizado como parte da alternância do datacenter primário para o datacenter em espera. Embora a configuração ativo/ativo forneça uma solução de alternância de datacenter simples, ela carrega a desvantagem de requerer um monitoramento de carga cuidadoso para garantir que, após a alternância do datacenter, os servidores de Transporte de Borda no segundo datacenter ofereçam capacidade suficiente para dar suporte à carga aumentada que flui através deles, como resultado da indisponibilidade dos servidores de Transporte de Borda no datacenter primário.

Até mesmo com uma configuração ativo/ativo, é adequado atualizar os registros de recurso MX dos servidores de Transporte de Borda durante uma alternância de datacenter. Permitir que o registro de recurso MX do datacenter com falha continue a apontar para o datacenter com falha significa que, quando o datacenter iniciar a recuperação, ele pode começar a fazer tentativas de conexão com seus servidores de Transporte de Borda. Isso pode acontecer enquanto os serviços de Transporte de Borda estão em um estado instável (por exemplo, porque serviços dependentes estão sendo restaurados no datacenter).

Presumindo que os registros DNS estão sob o controle da organização, ativar os servidores de Transporte de Borda envolve atualizar o registro de recurso MX de cada domínio SMTP hospedado pelo servidor.

Observação

Se o registro de recurso MX utilizado por sua organização não estiver hospedado por um servidor DNS sob o controle de sua organização, deve-se considerar a consulta a um registro CNAME no registro de recurso MX e o uso de um registro CNAME sob o controle da organização, que pode, então, ser atualizado.

As atualizações do DNS permitem o tráfego de entrada, e o tráfego de saída é manipulado pela ativação dos bancos de dados de caixa de correio em um site que tem servidores de Transporte de Borda funcionais:

Quando as conexões SMTP de entrada são iniciadas usando as informações atualizadas de resolução de nome, os clientes SMTP se conectarão aos servidores de Transporte de Borda no segundo datacenter. O tráfego será roteado adequadamente pelo servidor de Transporte de Borda, e não serão requeridas alterações adicionais.
Quando conexões SMTP de saída são iniciadas, elas tentam o servidor de Transporte de Borda localmente disponível, e essas mensagens são enfileiradas ou enviadas imediatamente de acordo com o status do servidor de recebimento.

Restaurando o serviço para o datacenter primário

Geralmente, as falhas dos datacenters são temporárias ou permanentes. Quando há uma falha permanente, como um evento que causou a destruição permanente de um datacenter primário, não se espera que o datacenter primário seja ativado. Contudo, quando há uma falha temporária (por exemplo, uma perda de energia prolongada ou danos prolongados, porém reparáveis), há uma expectativa de que o datacenter primário acabe sendo restaurado para o funcionamento normal.

O processo de restauração do serviço para um datacenter com falha anterior é chamado de retorno de alternância. As etapas utilizadas na realização do switchback de um datacenter são similares às etapas para a realização da alternância de um datacenter. Uma distinção significativa é que os switchbacks dos datacenters são programados e a duração da interrupção costuma ser muito menor.

É importante que o switchback não seja realizado até que as dependências da infraestrutura do Exchange sejam reativadas, estejam em funcionamento e estáveis e tenham sido validadas. Se essas dependências não estiverem disponíveis ou íntegras, é provável que o processo de switchback cause uma interrupção com duração maior do que a necessária ou falhe totalmente.

Switchback de Função de Servidor Caixa de Correio

A função de servidor Caixa de Correio deve ser a primeira função a ser restaurada no datacenter primário. As seguintes etapas detalham o processo de switchback da função de servidor Caixa de Correio:

Como parte do processo de alternância de datacenter, os servidores de Caixa de Correio no datacenter primário foram colocados no estado interrompido. Quando o ambiente (como o datacenter primário, as dependências do Exchange e a conectividade WAN (rede de longa distância)) está pronto, o primeiro passo é colocar os servidores de Caixa de Correio do datacenter primário restaurado em um estado iniciado e incorporá-los ao DAG. O modo no qual ele é feito depende de se o DAG está em modo DAC.
1. Se o DAG estiver em modo DAC, é possível reincorporar os membros do DAG no site principal usando o cmdlet do Start-DatabaseAvailabilityGroup. Em seguida, para certificar-se de que o modelo de quorum adequado está sendo usado pelo DAG, execute o cmdlet Set-DatabaseAvailabilityGroup contra o DAG sem especificar nenhum parâmetro.
2. Se o DAG não estiver em modo DAC, é possível reincorporar os membros do DAG usando o cmdlet do Add-DatabaseAvailabilityGroupServer.
Após os servidores de Caixa de Correio do datacenter primário serem incorporados ao DAG, eles precisam de um tempo para sincronizar suas cópias do banco de dados. Dependendo da natureza da falha, da extensão da interrupção e das decisões tomadas pelo administrador durante a interrupção, pode ser necessário reenviar as cópias do banco de dados. Por exemplo, se durante a interrupção, você remover as cópias do banco de dados do datacenter primário com falha para permitir o truncamento do arquivo de log para as cópias ativas restantes no segundo datacenter, será necessária uma nova propagação. Cada banco de dados pode prosseguir individualmente deste ponto em diante. Depois que uma cópia replicada do banco de dados no datacenter primário estiver íntegra, é possível prosseguir para a próxima etapa.

Observação

Esse processo não requer que todos os bancos de dados sejam removidos ao mesmo tempo. É recomendável mover a maior parte dos bancos de dados de sua organização de uma só vez, porém alguns bancos de dados podem se demorar no segundo datacenter, se houver problemas associados às cópias do banco de dados no datacenter primário.
Depois que a maior parte dos bancos de dados estiver em um estado íntegro no datacenter primário, a interrupção do switchback poderá ser programada. Quando a hora agendada chegar, estas instruções devem ser seguidas:
1. Durante o processo de alternância do datacenter, o DAG foi configurado para usar um servidor testemunha alternativo. O DAG deve ser reconfigurado para usar um servidor testemunha no datacenter primário. Se você estiver usando o mesmo servidor testemunha e o diretório de testemunhas que foi usado antes da interrupção do datacenter primário, você poderá executar o Set-DatabaseAvailabilityGroup -Identity DAGName comando. Se você pretende usar um servidor testemunha ou um diretório testemunha diferente do servidor ou diretório testemunha original, use o comando Set-DatabaseAvailabilityGroup para configurar os parâmetros do servidor testemunha e do diretório testemunha com os valores apropriados.
2. Os bancos de dados que são reativados no datacenter primário devem ser desmontados do segundo datacenter. Você pode usar o cmdlet Dismount-Database para desmontar os bancos de dados.
3. Depois que os bancos de dados forem desmontados, os URLs do servidor de Acesso para Cliente devem ser movidos do segundo datacenter para o datacenter primário. Isso é conseguido alterando-se o registro DNS dos URLs para apontar para o servidor de Acesso para Cliente ou matriz no datacenter primário. Isso fará o sistema agir, ainda que um failover do banco de dados tenha ocorrido em cada banco de dados que estava sendo movido.
  
  Importante
  
  Não passe para a próxima etapa até que os URLs do servidor de Acesso para Cliente tenham sido movidos e a TTL do DNS e das entradas de cache tenham expirado. Ativar os bancos de dados no datacenter primário antes de mover os URLs do servidor de Acesso para Cliente para o datacenter primário resultará em uma configuração inválida (por exemplo, um banco de dados montado que não tem servidores de Acesso para Clientes em seu site do Active Directory).
4. Como cada banco de dados do datacenter primário está em um estado íntegro, é permitida a sua ativação no datacenter primário ao realizar as alternâncias do banco de dados. Isso é obtido usando-se o cmdlet Move-ActiveMailboxDatabase para cada banco de dados que será ativado.
5. Depois que cada banco de dados tiver sido movido para o datacenter primário, eles podem ser montados usando-se o cmdlet Mount-Database.

Depois que um ou mais bancos de dados estiverem ativos e montados no datacenter primário, os procedimentos de switchback para os outros servidores poderão ser realizados.

Switchback de servidor de Acesso para Cliente

Como parte do processo de alternância, os registros de DNS internos e externos usados por clientes, outros servidores e gateways de IP para resolver os pontos de extremidade de serviço para servidores de Acesso para Cliente, serviços de Transporte e Unificação de Mensagens e servidores de Transporte de Borda foram modificados para apontar para os pontos de extremidade correspondentes no segundo datacenter. O processo de switchback para outras funções de servidor envolve modificar esses registros para apontar para os pontos de extremidade de serviço restaurados no datacenter primário.

Assim como nas alterações de DNS que foram feitas durante a alternância para o segundo datacenter, os clientes, servidores e gateways IP continuarão a tentar a conexão e deverão conectar-se automaticamente após a TTL expirar para a entrada original do DNS, e após a expiração da entrada do cache DNS.

Restabelecendo a resiliência do site

Após a conclusão bem-sucedida do switchback do datacenter primário, é possível restabelecer a resiliência do site para o datacenter primário ao verificar a integridade e o status de cada cópia do banco de dados de caixa de correio no segundo datacenter. Além disso, se quaisquer cópias de banco de dados no segundo datacenter estiverem originalmente bloqueadas para ativação, é possível reconfigurar essas configurações, nesse momento.

Compartilhar via