Partilhar via

Replicação Contínua em Espera: resiliência de site com cluster em espera

  • Artigo

 

Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

Tópico modificado em: 2008-11-18

Este tópico detalha como uma organização, Contoso, Ltd., usa a SCR (replicação contínua em espera) em um cenário de resiliência de site. Nesse cenário, o data center principal falha e a Contoso, Ltd. toma a decisão de ativar o data center secundário. Depois que o data center secundário é ativado, o data center principal é reconfigurado e, por fim, restaurado como o data center principal em uma alternância controlada. A Contoso, Ltd. possui dois data centers: um data center principal, chamado de Active Directory SITEA, e um segundo data center de backup, chamado de Active Directory SITEB. SITEA está localizado em Portland, Oregon, e SITEB está localizado em San José, Califórnia.

SITEA contém os seguintes componentes de infra-estrutura:

  • Servidor de diretório, DC1, que também fornece serviços de DNS seguros e integrados no Active Directory

  • Servidor de Acesso para Cliente, CAS1

  • Servidor de Transporte de Hub, HUB1

  • Servidor de caixas de correio clusterizadas, EXCMS1, sendo executado em um cluster de cópia única (SCC) com dois nós, EXCLUS1, que contém NODEA e NODEB. Observe que:

    • Os nós no cluster de failover estão sendo executados no sistema operacional Windows Server 2008, e o cluster de failover está configurado com um quorum de Nós e Discos Principais.

    • O valor de Vida Útil (TTL) do DNS do recurso de Nome de Rede do servidor de caixas de correio clusterizadas é configurado como cinco minutos. Para fazer essa configuração, é necessário executar o comando a seguir e, depois, parar e iniciar o servidor de caixas de correio clusterizadas.

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

      Dica

      A propriedade HostRecordTTL está disponível somente nos clusters de failover que executam o Windows Server 2008. Este comando não pode ser usado em clusters de failover que executem o sistema operacional Windows Server 2003.

SITEB contém os seguintes componentes de infra-estrutura:

  • Servidor de diretório, DC2, que também fornece serviços de DNS seguros e integrados no Active Directory

  • Servidor de Acesso para Cliente, CAS2

  • Servidor de Transporte de Hub, HUB2

  • Cluster de nó único, DRCLUS1, que será usado como cluster de failover em espera. Observe que:

    • O nó nesse cluster, NODEC, é o único no cluster de failover em espera, e está executando o Windows Server 2008. O cluster de failover em espera está configurado com um quorum de Nós Principais.

      Dica

      Em clusters de failover que executam o Windows Server 2003, o cluster de failover em espera de nó único seria configurado com um quorum local.

    • A função de servidor Caixa de Correio passiva é instalada no NODEC através do mesmo caminho de instalação do EXCLUS1. Isso é necessário para que seja possível realizar uma recuperação de servidor usando Setup /RecoverCMS como parte do processo de ativação do destino de SCR. Para usar o processo de recuperação do servidor, o caminho de instalação do Exchange Server deve ser o mesmo para os computadores de origem e de destino de SCR. Se o Exchange Server estiver instalado em %ProgramFiles%\Microsoft\Exchange Server no computador de origem SCR, ele também deverá estar instalado em %ProgramFiles%\Microsoft\Exchange Server em todos os computadores que serão destinos SCR para o servidor de origem SCR. Se esses caminhos de instalação não corresponderem, o processo de recuperação do servidor falhará, pois o caminho de instalação no Registro não corresponderá ao valor do atributo msExchInstallPath do objeto de servidor de caixas de correio no Active Directory.

    • Usando o snap-in Usuários e Computadores do Active Directory, a conta do computador para DRCLUS1 é configurada com permissão total no objeto de computador de EXCMS1. Isso é feito para que a conta do computador de EXCMS1 possa ser redefinida por DRCLUS1 no caso de SITEB ser ativado devido a falha de SITEA.

      Dica

      Esta etapa é usada somente em clusters de failover que executam o Windows Server 2008. Isso ocorre porque o Serviço de cluster é executado no contexto de segurança do sistema local. Esta etapa não é necessária em clusters de failover que executam o Windows Server 2003 quando a mesma conta de Serviço de cluster é usada para os dois clusters de failover.

Todos os servidores em ambos os sites do Active Directory são configurados para usar servidores DNS integrados ao Active Directory. O intervalo de replicação do Active Directory para ambos os sites do Active Directory está configurado como 15 minutos.

O SCR é configurado de maneira que os arquivos de log de transações sejam replicados de três grupos de armazenamento do EXCMS1 para destinos SCR do NODEC. Essa configuração foi feita com os comandos a seguir:

Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC

Dica

Para habilitar simultaneamente todos os grupos de armazenamento em EXCMS1 para SCR, execute o comando a seguir: Get-StorageGroup -Server EXCMS1 | Enable-StorageGroupCopy -StandbyMachine NODEC

A integridade e o status da SCR de cada grupo de armazenamento foram verificados com os cmdlets Test-ReplicationHealth e Get-StorageGroupCopyStatus no Shell de Gerenciamento do Exchange. Por exemplo:

Get-StorageGroupCopyStatus EXCMS1\SG1 -StandbyMachine NODEC

As movimentações do servidor de caixas de correio clusterizadas foram verificadas conforme o funcionamento esperado, como backups e truncamento de log.

Falha do site principal e ativação do site de backup

De repente, e sem qualquer aviso, ocorre um grande terremoto em Portland. Embora ninguém tenha se ferido gravemente, muitos danos ocorrem no SITEA, o que obriga o corte de serviços essenciais, como energia, água e gás natural. Como poderá levar meses para que o SITEA possa ser usado pela Contoso Ltda, é tomada a decisão de executar uma ativação manual do SITEB e ter todos os dados de mensagens e serviços fornecidos por esse site.

A ativação do SITEB começa com a verificação de serviços de diretório e resolução de DNS. Como o SITEB já contém um servidor de diretório que também está hospedando o DNS integrado ao Active Directory, esses serviços estão íntegros, atualizados e não foram afetados grandemente pela interrupção do SITE. Depois de verificar os serviços de diretório e o DNS, a próxima etapa é começar a ativação dos destinos de SCR e uma recuperação do servidor de caixas de correio clusterizadas. Para fazer isso, siga estas etapas na ordem indicada:

  1. O Shell de Gerenciamento do Exchange é aberto em NODEC, enquanto os comandos a seguir são executados para preparar a montagem dos destinos da SCR.

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Force

    Importante

    O parâmetro Force deverá ser sempre especificado quando a origem da SCR não estiver disponível.

    Dica

    Uma alternativa à execução de três comandos Restore-StorageGroupCopy distintos, conforme mostra a etapa 1, seria usar um novo script incluído no Microsoft Exchange Server 2007 Service Pack 1 (SP1), chamado GetSCRSources.ps1, e canalizar a saída do script para uma única tarefa Restore-StorageGroupCopy, da seguinte forma: GetSCRSources | Restore-StorageGroupCopy -StandbyMachine $env:ComputerName -Force

  2. Use o snap-in Gerenciamento de DNS para remover o registro de DNS existente para EXCMS1 do DNS.

    Dica

    Esta etapa é usada somente em clusters de failover que executam o Windows Server 2008. Isso ocorre porque o Serviço de cluster é executado no contexto de segurança do sistema local. Esta etapa não é necessária em clusters de failover que executam o Windows Server 2003 quando a mesma conta de Serviço de cluster é usada para os dois clusters de failover.

  3. A SCR é desabilitada para todos os grupos de armazenamento como preparação para o processo /RecoverCMS. Se a SCR não for desabilitada para todos os grupos de armazenamento, Setup /RecoverCMS irá falhar. É possível desabilitar a SCR usando os comandos a seguir:

    Disable-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Confirm:$False

  4. Para recuperar o servidor de caixas de correio clusterizadas (EXCMS1), use a opção /RecoverCMS na instalação. A recuperação ocorre em NODEC, usando os comandos a seguir para realizar a recuperação:

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    Observe o seguinte:

    • O valor de CMSIPAddress no comando anterior provavelmente seria um endereço IP diferente do endereço IP original de EXCMS1. Isso se deve ao fato de EXCMS1 estar sendo recuperado externamente. Ou seja, era hospedado originalmente no SITEA e está sendo recuperado no SITEB.

    • Setup /RecoverCMS será concluído com êxito após a replicação de DNS e a liberação do cache DNS do servidor de recuperação (NODEC). Se a Instalação falhar, use o NSLookup do controlador de domínio principal (PDC) e do NODEC para confirmar se o endereço IP correto é resolvido no NODEC; em seguida, execute novamente a Instalação após a verificação.

    • Em clusters de failover que executam o Windows Server 2003, o objeto de computador de EXCMS1 é redefinido durante o processo Setup /RecoverCMS. Essa redefinição precisa ser replicada para o site do Active Directory local para que a Instalação seja concluída com êxito. Se o PDC não estiver no site do Active Directory local, verifique se há links do site do Active Directory funcionando entre o PDC e o site do Active Directory local.

    • Após a conclusão do processo de recuperação da instalação, EXCMS1 foi recuperado no SITEB e agora é hospedado no NODEC em uma SCC de nó único chamada DRCLUS1.

    • Como resultado da operação de recuperação do servidor de caixas de correio clusterizadas, o TTL do DNS para EXCMS1 é revertido ao valor padrão de 20 minutos. Ele deverá ser novamente definido como cinco minutos através do comando a seguir e, em seguida, parando e iniciando o servidor de caixas de correio clusterizadas.

      Cluster.exe res EXCMS1 /priv HostRecordTTL=300

  5. Em seguida, os bancos de dados nos três grupos de armazenamento são montados usando a tarefa Mount-Database.

  6. Uma operação de recuperação de outras funções de servidor (especificamente, Acesso para Cliente e Transporte de Hub) não precisa ser executada neste cenário, visto que CAS2 e HUB2 já existem no SITEB.

    Dica

    Como parte da operação de recuperação do servidor de Acesso para Cliente, os URLs externos precisam ser reconfigurados de modo que apontem para os servidores de Acesso para Cliente no SITEB.

    Dica

    Esse exemplo de cenário não inclui a recuperação de servidores de Transporte de Borda. Se houvesse servidores de Transporte de Borda no SITEA que também tivessem sido perdidos durante a falha do site, novos servidores de Transporte de Borda precisariam ser colocados online no SITEB, bem como os registros de DNS de Troca de Mensagens (MX) para os domínios SMTP da Contoso precisariam ser atualizados para apontar para os novos servidores de Transporte de Borda.

  7. Se a organização Contoso incluir sites adicionais do Active Directory, as mensagens serão enfileiradas no site principal do Active Directory. Depois que as informações de associação do site do EXCMS1 forem replicadas para todos os outros sites do Active Directory, você poderá tentar novamente, de forma manual, as filas SMTP que contêm mensagens destinadas ao site primário. (Na ausência de uma nova tentativa manual, o mecanismo de transporte tentará automaticamente a fila em 12 horas.) Dessa forma, as mensagens serão recategorizadas. Depois de recategorizadas, as mensagens serão entregues para EXCMS1 no SITEB.

Nesse ponto, desde que os servidores DNS usados pelos clientes e por outros servidores tenham o endereço IP correto para EXCMS1, todos os clientes deverão estar aptos a acessar suas caixas de correio usando seus métodos de acesso originais (por exemplo, Microsoft Outlook Web Access, Exchange ActiveSync e Microsoft Office Outlook).

Reconfiguração do site principal

Como o site secundário (SITEB) agora está atuando como o data center principal, o data center original, ou seja, o SITEA, deve ser reconfigurado para que os serviços agora hospedados no SITEB não entrem em conflito com aqueles criados depois que o SITEA está pronto para ser ativado novamente para uso. O SITEA deve ser colocado online de maneira controlada por um administrador, usando as etapas a seguir:

  1. Coloque online primeiro os serviços de diretório e de resolução de nomes DNS, e faça isso colocando o DC1 online.

  2. Depois de colocar o DC1 online, coloque o CAS1 e o HUB1.

    Observe que depois de colocar o HUB1 online, um administrador deverá verificar se todas as mensagens de suas filas foram entregues. Se as mensagens estiverem paradas nas filas, será possível enviá-las novamente usando o comando a seguir.

    Retry-queue [queue name] -Resubmit $True

  3. Coloque online os nós que estão hospedando o cluster EXCLUS1. Para fins deste cenário, NODEA é colocado online primeiro e, em seguida, NODEB.

  4. Quando ambos os nós estiverem online, o servidor de caixas de correio clusterizadas permanecerá em estado offline. Isso inclui todos os recursos que compõem o servidor de caixas de correio clusterizadas, especialmente o recurso de Nome de Rede. Esse recurso não pode tornar-se online porque EXCMS1 já está online e usando o mesmo nome de rede. Colocar EXCMS1 online em NODEA ou NODEB resultaria em um conflito de nome na rede.

  5. No nó que atualmente possui o grupo de recursos que contém o servidor de caixas de correio clusterizadas, um administrador deve limpar o servidor de caixas de correio clusterizadas e seus recursos do cluster de failover. Para fazer isso, o administrador primeiro remove qualquer recursos que não seja do Exchange do grupo de clusters que contém o servidor de caixas de correio em cluster. Em seguida, o administrador deve executar o comando a seguir no NODEA:

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

    Observe que:

    • Depois que o servidor de caixas de correio clusterizadas e seus recursos tiverem sido excluídos de EXCLUS1, recomenda-se usar o snap-in Administrador de Cluster ou Gerenciamento de Cluster de Failover para verificar se todos os recursos do servidor de caixas de correio clusterizadas foram removidos.

    • EXCLUS1 agora é um cluster de failover com dois nós passivos, NODEA e NODEB, cada um com a função de servidor Caixa de Correio passiva instalada. Nesse ponto, não há servidor de caixas de correio clusterizadas no EXCLUS1.

  6. Pelo fato de os nós de cluster estarem em execução no Windows Server 2008, após executar Setup /ClearLocalCMS, o objeto de computador virtual (VCO) será desabilitado. Para reabilitar o VCO, clique em Iniciar, aponte para Todos os Programas, aponte para Ferramentas Administrativas e clique em Usuários e Computadores do Active Directory. Expanda o domínio, expanda Computadores, clique com o botão direito do mouse no VCO do EXCMS1 e clique em Habilitar Conta.

  7. Para preparar uma alternância controlada do SITEB para o SITEA, NODEA se tornará um destino de SCR para os grupos de armazenamento hospedados em EXCMS1 no SITEB. Isso é feito usando os seguintes comandos em NODEC:

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEA

    Dica

    Se o armazenamento usado pelo cluster de failover original não tiver sido afetado pela falha do SITEA, e os bancos de dados originais e seus logs de transação para os três grupos de armazenamento ainda existirem em NODEA, talvez seja possível usá-los para fins de replicação contínua sem ter de executar uma nova propagação completa para cada grupo de armazenamento em NODEA. Se não for possível usar os arquivos existentes, ou o log circular tiver sido configurado para o servidor de caixas de correio clusterizadas original, uma nova propagação completa para cada grupo de armazenamento deverá ser efetuada com a execução do cmdlet Update-StorageGroupCopy.

Um SCC é usado para fins de exemplo neste cenário. Se, em vez disso, o cenário de recuperação usar um servidor de caixas de correio clusterizadas em um ambiente de CCR, é recomendável executar uma etapa adicional na qual o nó passivo também é preparado para a alternância controlada, graduando-o com os bancos de dados e os arquivos de log. Esta etapa é executada unicamente para fins de otimização, visando eliminar a necessidade de propagar os grupos de armazenamento passivos depois que o ambiente de CCR for novamente movido para o SITEA. Essa tarefa é executada por um destes dois métodos:

  • Suspendendo a replicação contínua para os três destinos da SCR e, em seguida, copiando os arquivos e bancos de dados do grupo de armazenamento do NODEA para os locais apropriados no NODEB.

  • Habilitando o NODEB como um destino de SCR do EXCMS1.

Alternância controlada para o site principal original

Depois que o SITEA tiver sido aprovado para uso, uma alternância manual e controlada dos dados e serviços do SITEB para o SITEA poderá ser executada. As etapas realizadas para efetuar a alternância controlada são, na verdade, o inverso das etapas executadas para ativar o SITEB:

  1. A primeira etapa é desmontar todos os bancos de dados de EXCMS1. Isso é feito para interromper a geração de arquivos de log de transação e preparar a ativação dos destinos de SCR em NODEA. Os bancos de dados podem ser desmontados usando o Console de Gerenciamento do Exchange, ou o cmdlet Dismount-Database no Shell de Gerenciamento do Exchange.

  2. Em NODEA, um administrador prepara todos os grupos de armazenamento para montagem. Esta tarefa é executada com os comandos a seguir:

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEA

    Observe que:

    • Nos três comandos anteriores, o parâmetro Force não é usado porque o servidor de origem de SCR está disponível. Como o parâmetro Force não é usado, a tarefa tentará automaticamente copiar todos os arquivos de log da origem de SCR.

    • Após a conclusão de cada tarefa, o administrador deve verificar se todos os arquivos de log de cada grupo de armazenamento foram copiados para NODEA, e se a SCR foi desabilitada.

    • Se NODEB também tiver sido configurado como um destino de SCR, será necessário desabilitá-lo e restaurá-lo antes de prosseguir. Neste cenário, recomenda-se executar Restore-StorageGroupCopy primeiro em NODEB e, depois, em NODEA; em seguida, Setup /RecoverCMS deve ser executado em NODEA.

  3. O servidor de caixas de correio clusterizadas (EXCMS1) em DRCLUS1 deve ser parado. Essa tarefa deve ser executada em NODEC, usando o assistente de Gerenciamento de Servidor de Caixas de Correio Clusterizadas no Console de Gerenciamento do Exchange, ou o cmdlet Stop-ClusteredMailboxServer, no Shell de Gerenciamento do Exchange.

  4. O registro A para EXCMS1 deve ser removido do DNS usando o snap-in Gerenciamento de DNS.

    Dica

    O registro A de EXCMS1 só precisa ser removido quando o cluster de failover está sendo executado no Windows Server 2008. Caso esteja sendo executado no Windows Server 2003, não será necessário executar essa etapa.

  5. Para recuperar o servidor de caixas de correio clusterizadas (EXCMS1), use a opção /RecoverCMS na instalação. A recuperação ocorre em NODEA, usando os comandos a seguir para realizar a recuperação:

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    Observe que:

    • O valor de CMSIPAddress no comando anterior provavelmente seria o endereço IP original de EXCMS1. Isso se deve ao fato de EXCLUS1 estar sendo recuperado novamente ao seu local original.

    • Após a conclusão do processo de recuperação da instalação, EXCMS1 foi recuperado no SITEA e agora é hospedado no NODEA em uma SCC de dois nós chamada EXCLUS1.

    Dica

    Novamente, um SCC é usado para fins de exemplo neste cenário. Se, em vez disso, o cenário de recuperação usar um servidor de caixas de correio clusterizadas em um ambiente de CCR, talvez seja necessário realizar etapas adicionais. A operação /RecoverCMS suspende a replicação contínua, nesse caso, de NODEA para NODEB.. Um administrador deve executar Resume-StorageGroupCopy para os grupos de armazenamento a fim de restabelecer as atividades de replicação e reprodução. Em seguida, o administrador deverá verificar se a atividade de replicação foi retomada. Se o estágio de NODEB, conforme descrito anteriormente, não tiver sido bem-sucedido, as cópias passivas dos grupos de armazenamento precisarão ser propagadas novamente.

    • Como resultado da operação de recuperação do servidor de caixas de correio clusterizadas, o TTL do DNS para EXCMS1 é revertido ao valor padrão de 20 minutos. Ele deverá ser novamente definido como cinco minutos através do comando a seguir e, em seguida, parando e iniciando o servidor de caixas de correio clusterizadas:

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

  6. Os bancos de dados nos três grupos de armazenamento são montados usando o cmdlet Mount-Database.

  7. Uma operação de recuperação de outras funções de servidor (isto é, Acesso para Cliente e Transporte de Hub) não precisa ser executada neste cenário, visto que CAS1 e HUB1 já existem no SITEA.

    Dica

    Como parte da operação de recuperação do servidor de Acesso para Cliente, os URLs externos precisam ser reconfigurados de modo que apontem para os servidores de Acesso para Cliente no SITEA.

    Dica

    Esse exemplo de cenário não inclui a recuperação de servidores de Transporte de Borda. Se servidores de Transporte de Borda estiverem em uso, os registros de DNS de Troca de Mensagens (MX) para os domínios SMTP da Contoso precisarão ser atualizados para apontar para os servidores de Transporte de Borda corretos.

  8. Se a organização Contoso incluir sites adicionais do Active Directory, as mensagens serão enfileiradas no site principal do Active Directory. Depois que as informações de associação do site do EXCMS1 forem replicadas para todos os outros sites do Active Directory, você poderá tentar novamente, de forma manual, as filas SMTP que contêm mensagens destinadas ao site primário. (Na ausência de uma nova tentativa manual, o mecanismo de transporte tentará automaticamente a fila em 12 horas.) Dessa forma, as mensagens serão recategorizadas. Depois de recategorizadas, as mensagens serão entregues para EXCMS1 no SITEA.

  9. Nesse ponto, desde que os servidores DNS usados pelos clientes e por outros servidores tenham o endereço IP correto para EXCMS1, todos os clientes deverão estar aptos a acessar suas caixas de correio usando seus métodos de acesso originais (por exemplo, Outlook Web Access, Exchange ActiveSync e Outlook). Além disso, depois que as alterações de DNS tiverem sido replicadas para o SITEB, e a associação de site do EXCMS1 tiver sido replicada, os servidores de Transporte de Hub rotearão as mensagens para o site correto do Active Directory. Um administrador também pode forçar manualmente um novo envio das mensagens que possam estar em alguma fila em HUB1 ou HUB2. Esta tarefa pode ser executada com o comando a seguir:

    Retry-queue [queue name] -Resubmit $True

Reconfiguração do site de backup

Após a conclusão de uma alternância manual e controlada do SITEB para o SITEA, o SITEB poderá ser retornado ao seu status operacional de data center de backup. Isso inclui limpar o servidor de caixas de correio clusterizadas em espera do cluster de failover no SITEB e habilitar novamente NODEC como destino de SCR para os três grupos de armazenamento em EXCMS1. Para fazer isso, siga estas etapas na ordem indicada:

  1. Durante a alternância controlada, o servidor de caixas de correio clusterizadas em execução em DRCLUS1, no SITEB, foi parado para que pudesse ser ativado em EXCLUS1, no SITEA. Depois que EXCMS1 é colocado com êxito em produção novamente em EXCLUS1, suas informações de configuração precisam ser removidas de DRCLUS1. As informações de configuração podem ser limpas e o EXCMS1 pode ser totalmente removido do DRCLUS1 removendo qualquer recurso que não seja do Exchange do grupo de clusters que contém o servidor de caixas de correio em cluster e executando o seguinte comando:

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

  2. Pelo fato de o nó de cluster estar em execução no Windows Server 2008, após executar Setup /ClearLocalCMS, o VCO será desabilitado. Para reabilitar o VCO, clique em Iniciar, aponte para Todos os Programas, aponte para Ferramentas Administrativas e clique em Usuários e Computadores do Active Directory. Expanda o domínio, expanda Computadores, clique com o botão direito do mouse no VCO do EXCMS1 e clique em Habilitar Conta.

  3. Depois que o servidor de caixas de correio clusterizadas e seus recursos tiverem sido excluídos de DRCLUS1, um administrador deverá usar o snap-in Administrador de Cluster ou Gerenciamento de Cluster de Failover para verificar se todos os recursos do servidor de caixas de correio clusterizadas foram removidos.

  4. O SCR é configurado de maneira que os arquivos de log de transações sejam replicados de três grupos de armazenamento do EXCMS1 para destinos SCR do NODEC. Essa configuração é feita com os comandos a seguir:

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC

    Dica

    Antes de habilitar a SCR para replicar os grupos de armazenamento de EXCMS1 para NODEC, você deverá verificar se não existem conflitos de caminhos de bancos de dados ou grupos de armazenamento. Verifique também se todos os grupos de armazenamento e arquivos de banco de dados antigos e desnecessários foram removidos dos caminhos originais.

  5. A integridade e o status da SCR para cada grupo de armazenamento são verificados usando os cmdlets Test-ReplicationHealth e Get-StorageGroupCopyStatus. As movimentações do servidor de caixas de correio clusterizadas entre os nós, bem como as operações de backup e truncamento de log, também deverão ser verificadas conforme o funcionamento esperado. Após a conclusão de todas as verificações, os data centers principal e secundário estarão de volta aos seus modos de operação originais, nos termos do sistema de mensagens do Exchange 2007.