Compartilhar via

Replicação Contínua em Cluster

  • Artigo

 

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

Tópico modificado em: 2008-03-21

A CCR (replicação contínua em cluster) é um recurso de alta disponibilidade do Microsoft Exchange Server 2007 que combina a tecnologia de repetição e envio de logs assíncronos incorporados no Exchange 2007 com os recursos de gerenciamento e failover fornecidos pelo Serviço de Cluster.

A CCR foi projetada para proporcionar alta disponibilidade para servidores de Caixa de Correio do Exchange 2007, fornecendo uma solução que:

  • Não tem nenhum ponto de falha.

  • Não tem requisitos especiais de hardware.

  • Não tem requisitos de armazenamento compartilhado.

  • Pode ser implantada em uma ou duas configurações de data center.

  • Pode reduzir a freqüência do backup completo, reduzir o volume total de dados de backup, bem como encurtar o SLA (acordo de nível de serviço) em razão do tempo de recuperação desde a primeira falha.

A CCR usa a funcionalidade de recuperação de falha de banco de dados do Exchange 2007 para permitir atualização contínua e assíncrona de uma segunda cópia do banco de dados, com as alterações feitas na cópia ativa. Durante a instalação do nó passivo em um ambiente de CCR, cada grupo de armazenamento e seu banco de dados é copiado do nó ativo para o passivo. Essa operação é denominada propagação e fornece uma linha de base do banco de dados para replicação. Depois de executada a propagação inicial, a cópia e a repetição do log serão executadas continuamente.

Em um ambiente de CCR, os recursos de replicação são integrados ao serviço de cluster para fornecer uma solução de alta disponibilidade. Além de fornecer disponibilidade de dados e serviços, a CCR oferece também interrupções agendadas. Quando for necessário instalar atualizações ou executar manutenção, o administrador poderá mover um servidor de caixas de correio clusterizadas (denominado Exchange Virtual Server nas versões anteriores do Exchange Server) manualmente para um nó passivo. Depois de concluída a operação de movimentação, o administrador pode executar a manutenção necessária.

A operação de movimentação é executada com o uso do cmdlet Move-ClusteredMailboxServer no Shell de Gerenciamento do Exchange. O Microsoft Exchange Server 2007 Service Pack 1 (SP1) também inclui um novo assistente para Gerenciar Servidores de Caixa de Correio Clusterizadas no Console de Gerenciamento do Exchange, que você pode usar para mover servidores de caixa de correio clusterizadas. A lógica usada por estas tarefas executa a imposição necessária para garantir que nenhum dado de caixa de correio se perca durante a movimentação. As tarefas também executam verificações antes da movimentação para conferir se a replicação no nó passivo já está pronta para ser ativada rapidamente.

Os principais fatos sobre a CCR são os seguintes:

  • A replicação contínua é assíncrona.   Os logs não são copiados até que sejam fechados e não estejam mais sendo usados pelo servidor de caixas de correio. Isso significa que o nó passivo em geral não tem uma cópia de cada arquivo de log existente no nó ativo. A única exceção será quando o administrador tiver iniciado uma interrupção agendada do nó ativo para aplicar uma atualização ou executar alguma outra manutenção.

  • A replicação contínua não coloca quase nenhuma carga de entrada/saída de CPU no nó ativo durante operação normal.   A CCR usa o nó passivo para copiar e repetir os logs. Os logs são acessados pelo nó passivo por meio de um compartilhamento de arquivo seguro.

  • As alterações dos nós ativo e passivo durante a existência do cluster são designadas automaticamente.   Por exemplo, após um failover, a designação de ativo e passivo é invertida. Isso significa inverter a direção de replicação. Nenhuma ação administrativa é exigida para inverter a replicação. O sistema gerencia a inversão da replicação automaticamente.

  • O failover e as interrupções agendadas são simétricos em função e desempenho   Por exemplo, o failover do Nó 1 para o Nó 2 e o failover do Nó 2 para o Nó 1 levam exatamente o mesmo tempo. Normalmente, seria menos de dois minutos. Em servidores maiores, as interrupções agendadas em geral durariam menos de quatro minutos. A diferença de tempo entre um failover e interrupções agendadas está associada ao tempo gasto para efetuar um encerramento controlado do nó ativo em uma interrupção agendada. Essa diferença de desempenho pode ser reduzida em um futuro service pack.

  • Há suporte para backups do VSS (Serviço de Cópias de Sombra de Volume) no nó passivo.   Isso permite que os administradores descarreguem backups do nó ativo e ampliem a janela de backup. Além disso, as configurações maiores não são obrigadas pelos requisitos de desempenho a ter suporte de VSS de hardware para usar os backups do VSS. A carga de trabalho no nó passivo relaciona-se principalmente à cópia e à repetição de logs, e nenhuma dessas operações possui limitação em tempo real, como o servidor de caixas de correio clusterizadas do nó ativo. Por exemplo, o nó ativo precisa atender aos pedidos do cliente prontamente. Uma janela de backup maior pode ser usada, já que o nó passivo não tem limitações de resposta em tempo real, permitindo com isso bancos de dados e caixa de correio de tamanho maior.

  • O total de dados na mídia de backup é reduzido.   A cópia passiva da CCR fornece a primeira linha de defesa contra corrupção e perda de dados. Dessa forma, uma falha dupla deve ocorrer para que os backups sejam necessários. A recuperação da primeira falha pode ter um SLA relativamente curto, visto que nenhuma restauração é necessária. A recuperação da segunda falha pode ter um SLA mais longo. O resultado é que os backups podem ser feitos em um ciclo semanal completo, com uma estratégia de incremento diário. Isso reduz o volume total de dados que devem ser colocados na mídia de backup.

  • A CCR pode ser combinada com a replicação contínua em espera (SCR)   A CCR pode ser combinada com a SCR para replicar localmente grupos de armazenamento em um data center primário (usando a CCR para alta disponibilidade) e remotamente em um data center secundário ou de backup (usando a SCR para resiliência do site). O data center secundário pode conter um nó passivo em um cluster de failover que hospeda destinos SCR. Esse tipo de cluster é chamado de cluster em espera, pois não contêm servidores de caixas de correio clusterizadas, mas pode ser rapidamente configurado com um servidor de caixas de correio clusterizadas de substituição em um cenário de recuperação. Se o data center primário falhar ou for perdido, os destinos SCR hospedados nesse cluster em espera poderão ser rapidamente ativados.

Arquitetura do núcleo da CCR

A CCR combina os seguintes elementos:

  • Os recursos de failover e virtualização fornecidos pelos clusters de failover da Microsoft.

  • Um modelo de quorum de cluster de failover baseado na maioria que usa um compartilhamento de arquivos como testemunha da atividade de cluster

  • Os recursos de repetição e replicação do log de transações no Exchange 2007

  • Um recurso de fila de mensagens do servidor de Transporte de Hub denominado dumpster de transporte.

Cluster de failover do Windows

Conforme mostrado na figura a seguir, no Exchange 2007, a CCR usa dois computadores (chamados de nós) unidos em um único cluster de failover em execução no Windows Server 2003 Service Pack 2 ou no Windows Server 2008. Os nós no cluster de failover hospedam um único servidor de caixas de correio clusterizadas. O nó que está executando um servidor de caixas de correio clusterizadas é chamado de nó ativo e o nó que não está executando um servidor de caixas de correio clusterizadas, mas é parte do cluster e o destino da replicação contínua, é chamado de nó passivo. Como resultado das interrupções agendadas, mantidas e não agendadas, a designação de um nó como ativo ou passivo será alterada várias vezes ao longo do tempo de vida do cluster de failover.

Implantação básica da CCR

Arquitetura de replicação contínua em cluster

O cluster de failover é construído com o serviço de Cluster e um modelo de quorum de tipo de cluster especificado:

Testemunha de compartilhamento de arquivos

Ambos os modelos de quorum mencionados anteriormente usam um compartilhamento de arquivos em um terceiro computador como testemunha. Nesses modelos de quorum, é usado um compartilhamento de arquivos em um terceiro computador para evitar uma ocorrência de partição de rede dentro do cluster, também conhecida como síndrome do cérebro dividido. A síndrome do cérebro dividido ocorre quando todas as redes designadas para realizar comunicação interna de clusters falham e os nós não podem receber sinais de pulsação uns dos outros. Para evitar a síndrome de cérebro dividido, é preciso exigir sempre que a maioria dos dois nós e o compartilhamento de arquivos estejam disponíveis e interagindo para que o servidor de caixas de correio clusterizadas fique operacional. Quando a maioria dos computadores está em comunicação, diz-se que o cluster tem um quorum. O compartilhamento de arquivos da testemunha pode estar hospedado em qualquer computador que esteja executando o Windows Server. Não é necessário que a versão do sistema operacional Windows Server que hospeda o compartilhamento de arquivos corresponda ao sistema operacional do ambiente de CCR. No entanto, é recomendável usar um servidor de Transporte de Hub no site do serviço de diretório do Active Directory que contém o servidor de caixas de correios clusterizadas para hospedar o compartilhamento de arquivos, pois isso permite que o administrador de sistema de mensagens mantenha o controle sobre o compartilhamento de arquivos.

Dica

O compartilhamento de arquivos usado pela testemunha do compartilhamento de arquivos não pode ser hospedado em um ambiente de Sistema de Arquivos Distribuído (DFS).

A testemunha do compartilhamento de arquivos utiliza um compartilhamento de arquivos em um computador fora do cluster para agir como uma testemunha das atividades dos dois nós que formam o cluster. A testemunha é utilizada pelos dois nós para rastrear o nó que está no controle do cluster. O bloco de notas é necessário apenas quando os dois nós não conseguem se comunicar entre si. Considere um servidor de caixas de correio clusterizadas de dois nós, formado pelo Nó1 e pelo Nó2. Neste caso, o Nó1 é o nó que pode ter o controle do bloco de notas e, portanto, obter o controle do cluster e criar o servidor de caixas de correio clusterizadas. Se o Nó2 estiver operacional, mas não puder se comunicar com o Nó1, o Nó2 tentará controlar o bloco de notas e falhará. A incapacidade de o Nó2 controlar o bloco de notas significa que ele não deve criar um servidor de caixas de correio clusterizadas.

Quando os dois nós podem interagir, o bloco de notas não é necessário e pode ficar offline. Entretanto, uma falha subseqüente de um dos nós evitará que o servidor de caixas de correio clusterizadas fique online se a testemunha de compartilhamento de arquivos não estiver disponível.

O compartilhamento de arquivos não mantém mais estados do que o que foi descrito anteriormente. Portanto, todas as informações de configuração do cluster são trocadas entre os dois nós. É importante entender isto, pois significa que, se o Nó1 estiver disponível e o Nó2 não estiver disponível, o Nó2 não poderá ficar disponível até ele se comunicar com o Nó1, mesmo se ocorrer comunicação com a testemunha de compartilhamento de arquivos.

O suporte da testemunha de compartilhamento de arquivos fornece uma verificação periódica da testemunha de compartilhamento de arquivos. Se a verificação de acesso falhar, será gerado um evento. O evento poderá ser detectado, coletado e reportado pelo sistema de monitoramento. Isto permite que a equipe de operações corrija o problema antes de ele causar uma interrupção devido a uma segunda falha simultânea.

O compartilhamento de arquivos é acessado nas seguintes condições:

  • Quando um nó de cluster aparece e apenas um nó do cluster está disponível.

  • Quando um problema com a conexão da rede evita que um nó anteriormente acessível comunique-se com o cluster.

  • Quando um nó de cluster deixa o cluster.

  • Periodicamente, para validações. A freqüência é configurável.

Por essas razões, a carga no compartilhamento de arquivos é leve. Como resultado, um único servidor pode fornecer compartilhamentos de arquivos para vários ambientes de CCR. No entanto, cada ambiente de CCR deve ter pasta e compartilhamento dedicados nesse servidor.

Considerações sobre Testemunha de Compartilhamento de Arquivos

A CCR é um ambiente de dois nós que usa um quorum MNS com testemunha de compartilhamento de arquivos ou um quorum Maioria dos Nós e Compartilhamentos de Arquivos em vez do terceiro nó (ou mais nós) do cluster que era necessário em clusters MNS tradicionais. Um ambiente de CCR geograficamente disperso é uma implantação de dois data centers em que o nó ativo é implantado no data center primário e o nó passivo é implantado em um data center secundário. Assim em um ambiente de CCR geograficamente disperso, há duas opções para colocação do compartilhamento de arquivos: colocá-lo no data center primário ou em um terceiro data center.

A primeira opção é configurar o compartilhamento de arquivos em um servidor Transporte de Hub no data center primário. Um servidor Transporte de Hub é recomendado porque permite que um administrador de mensagens gerencie e monitore interrupções do compartilhamento de arquivos. Nossa experiência e comentários de clientes indicam que os tipos mais comuns de interrupções do serviço de rede ocorrem em topologias WAN. Colocar o compartilhamento de arquivos no data center primário é útil porque impede interrupções do serviço devido a falhas de rede entre os dois data centers. O uso dessa configuração significa que não ocorrerá o failover automático caso haja uma interrupção do data center primário. No entanto, isso garante que a maioria no cluster de failover não é afetada por uma falha de rede entre o data center primário e o secundário.

A segunda opção é configurar o compartilhamento de arquivos em uma função de servidor gerenciado em um terceiro site fisicamente separado. Uma função de servidor gerenciado é um servidor que tem suporte e manutenção em um nível semelhante ao de outros servidores que são críticos para a entrega do serviço de mensagens. Um exemplo de uma função de servidor gerenciado é um servidor Transporte de Hub no data center primário. Esse terceiro site fisicamente separado pode ser uma filial ou um terceiro data center. Um requisito dessa configuração é que o terceiro site deve ter uma infra-estrutura de rede para os data centers primário e secundário que tenha baixa latência e alta confiabilidade.

Repetição e replicação do log de transações

A repetição e replicação do log de transações é usada para copiar os dados alterados e atualizar o banco de dados da cópia passiva. A replicação tira proveito do histórico de alterações produzido pelo ESE (Extensible Storage Engine). Esse histórico de alterações é representado como uma seqüência de arquivos de log de tamanho fixo de 1 megabyte (MB). A funcionalidade de replicação copia os arquivos de log para o nó passivo à medida que cada arquivo de log é gerado. O mecanismo de replicação é assíncrono para o banco de dados online. Quando os logs chegam no nó passivo, há uma verificação de integridade e eles são repetidos na cópia do banco de dados que é armazenado no nó passivo. O processo de repetição realiza as alterações descritas no log de alterações no banco de dados do nó passivo, tornando-o correspondente ao banco de dados de produção com um pequeno intervalo.

Como os dados são replicados entre os nós, o servidor de caixas de correio clusterizadas pode operar em qualquer nó do cluster. Este recurso proporciona aumento na disponibilidade, pois as interrupções agendadas e falhas de um nó não provocam uma interrupção estendida do servidor de caixas de correio clusterizadas. Além disso, interrupções de serviço do armazenamento em um nó não causarão impacto sobre a disponibilidade do outro nó e do servidor de caixas de correio clusterizadas. Supondo que o compartilhamento de arquivo ainda esteja disponível e possa se comunicar com o nó passivo, uma interrupção do nó ativo faz com que o servidor de caixas de correio clusterizadas se mova para o nó remanescente e continue operando.

Em um ambiente CCR, a pasta de arquivos de log de transação no nó ativo é compartilhada por meio de um compartilhamento de arquivos Windows padrão. O identificador global exclusivo (GUID) do objeto do grupo de armazenamento é usado para o nome de compartilhamento; um cifrão ($) é adicionado ao final do compartilhamento. O serviço de replicação do Microsoft Exchange no nó passivo se conecta ao compartilhamento no nó ativo e copia ou recebe os arquivos de log utilizando o protocolo SMB. O nó passivo, então, verifica o arquivo de log e o repete na cópia do banco de dados no nó passivo.

Dica

O tráfego SMB de replicação do arquivo de log de transação não é criptografado. Se necessário, é possível utilizar a segurança do Protocolo IPsec para criptografar o tráfego. Somente a replicação de arquivo de log de transação ocorre utilizando o protocolo SMB. Para propagar novamente uma cópia passiva, use a interface de programação de aplicativo (API) de backup do ESE, que é uma comunicação não criptografada. Se for necessário, o IPSec poderá ser usado para criptografar esses dados.

Replicação contínua sobre redes de cluster redundantes

Na versão RTM (Versão de Fabricação) do Microsoft Exchange Server 2007, toda a cópia e propagação de arquivos de log em um ambiente CCR ocorre em uma rede pública. Essa configuração possui os seguintes limites:

  • Quando o nó passivo fica indisponível por várias horas, um número significativo de logs podem ser gerados e precisem ser transferidos. O movimento desses logs deve ser o mais rápido possível quando o nó passivo estiver disponível. Ao copiar os logs pela rede pública, o movimento dos logs compete com o tráfego do cliente. Isso afeta o tráfego do cliente e deixa a ressincronização mais lenta.

  • Quando a rede pública falha, o failover tem perdas, mesmo que os dados do log estejam disponíveis.

  • O uso de uma rede isolada para a comunicação de log permite a segurança dos dados de mensagem sem o uso de criptografia e sem a perda de desempenho associada.

  • Tempestades de log podem ocorrer em algumas circunstâncias. Quando ocorrem, o sistema passa por uma sobrecarga excepcionalmente alta de replicação. Isso poderá resultar na privação do cliente se os dados de log precisarem se comunicados por meio da mesma rede usada para a comunicação com clientes.

Nem todos esses problemas ocorrerão na mesma freqüência. No entanto, é certo que o primeiro problema acontecerá com freqüência de meses porque os nós passivos ficam offline para atividades regulares de manutenção.

O Exchange 2007 SP1 minimiza os efeitos dos problemas anteriores permitindo que o administrador crie uma ou mais redes mistas no cluster (a rede mista é uma rede de cluster que oferece suporte tanto a tráfego de pulsação de cluster interno quanto a tráfego de cliente) para envio de logs. O Exchange 2007 SP1 também permite que o administrador defina uma rede mista específica a ser usada para propagação.

Dica

As redes de cluster usadas para envio de logs e propagação devem ser configuradas como redes mistas. Um rede mista consiste em qualquer rede de cluster que esteja configurada tanto para o tráfego de acesso de cluster (pulsação) quanto para o de cliente. Além disso, no adaptador de rede que está sendo configurado com um nome de host de replicação contínua, o administrador deverá desmarcar a caixa de seleção Registrar os endereços desta conexão no DNS na caixa de diálogo de propriedades Configurações TCP/IP Avançadas e usar entradas DNS estáticas ou entradas de arquivos de hosts em cada nó para permitir a resolução dos nomes de host recentemente criados por cada nó. O servidor DNS usado pelo adaptador de rede pode estar localizado na rede pública ou privada; no entanto, independentemente de sua localização, ele deverá estar acessível para ambos os nós para que a resolução de nome de host possa ocorrer. Além disso, no Windows Server 2008, os adaptadores de rede usados para envio de logs ou propagação exigem que o NetBIOS seja habilitado.

O suporte para cópia de logs sobre uma rede mista é configurado usando um novo cmdlet denominado Enable-ContinuousReplicationHostName. Da mesma forma, a desativação desse recurso é feita com o cmdlet Disable-ContinuousReplicationHostName.

Quando um servidor de caixas de correio clusterizadas existir em um ambiente CCR, um administrador pode executar Enable-ContinuousReplicationHostName em ambos os nós do cluster e especificar nomes de host e endereços IP adicionais, que serão posteriormente criados em grupos de cluster dedicados que estarão associados a cada nó. Após ter realizado essa tarefa, o serviço de replicação do Microsoft Exchange começará a usar a rede recentemente criada para cópia de logs logo após a configuração bem-sucedida e a confirmação de que a nova rede está operacional. Se várias redes novas forem criadas, o serviço de replicação do Microsoft Exchange irá selecionar aleatoriamente uma delas. Se a rede especificada ficar indisponível, o serviço de replicação do Microsoft Exchange começará a usar automaticamente outras redes de replicação ou, se nenhuma rede estiver disponível, ele usará a rede pública para envio de logs em cinco minutos. (A descoberta da rede do serviço de replicação do Microsoft Exchange ocorre a cada cinco minutos.) Quando a rede de replicação preferida estiver disponível de novo, o serviço de replicação do Microsoft Exchange irá automaticamente revertê-la para o envio de logs.

Para obter mais informações sobre cmdlets, consulte Enable-ContinuousReplicationHostName e Disable-ContinuousReplicationHostName.

O suporte para propagação em um cluster redundante é configurado usando o cmdlet Update-StorageGroupCopy, que foi atualizado no Exchange 2007 SP1 [ara incluir um novo parâmetro chamado DataHostNames. Esse parâmetro é usado para especificar que rede de cluster deverá ser usada para propagação. Para obter mais informações sobre as alterações ao cmdlet Update-StorageGroupCopy no Exchange 2007 SP1, consulte Update-StorageGroupCopy.

Após uma rede de cluster ter sido criada para replicação contínua, você pode usar o cmdletGet-ClusteredMailboxServerStatus para exibir informações atualizadas sobre as redes de cluster que foram habilitadas para atividade de replicação contínua. Os detalhes da nova saída incluem:

  • OperationalReplicationHostNames:{Host1,Host2,Host3}

  • FailedReplicationHostNames:{Host4}

  • InUseReplicationHostNames:{Host1,Host2}

Para obter mais informações sobre as alterações feitas no cmdlet Get-ClusteredMailboxServerStatus no Exchange 2007 SP1, consulte Get-ClusteredMailboxServerStatus.

Dumpster de Transporte

A massa de dados perdidos que ocorre durante uma recuperação automática é recuperada automaticamente em seguida por um recurso do servidor de Transporte de Hub denominado dumpster de transporte. O dumpster de transporte de um banco de dados específico pode estar localizado em todos os servidores de Transporte de Hub do site do Active Directory que contém o servidor de caixas de correio clusterizadas. Quando uma mensagem passa pelos servidores de Transporte de Hub em seu caminho para um servidor de caixas de correio clusterizadas de um ambiente de CCR, uma cópia é mantida na fila de transporte (mail.que) até que a janela de replicação tenha passado. O dumpster de transporte é um componente necessário para implantações de CCR. O dumpster de transporte se beneficia da redundância do ambiente para recuperar parte dos dados afetados pelo failover. Especificamente, os servidores de Transporte de Hub mantêm uma fila de mensagens entregues recentemente. Essa fila é limitada pelo tempo em que as mensagens são mantidas e pelo espaço total utilizado. No caso de um failover com perdas, a CCR do servidor de caixas de correio clusterizadas solicita automaticamente que todos os servidores de Transporte de Hub do site do Active Directory enviem novamente as mensagens da fila do dumpster de transporte. O armazenamento de informações exclui automaticamente as duplicatas e entrega novamente as mensagens perdidas.

O dumpster de transporte é habilitado para CCR e, no Exchange 2007 SP1, também para replicação contínua local (LCR). O dumpster de transporte não está habilitado para SCR nem para clusters de cópia única (SCCs). Para CCR, a condição necessária para que uma mensagem de email seja retida no dumpster de transporte é que ela tenha pelo menos um destinatário cuja caixa de correio esteja em um servidor de caixas de correio clusterizadas ou, no SP1, em um banco de dados de caixa de correio habilitado para LCR.

O dumpster de transporte foi desenvolvido para ajudar na proteção contra perda de dados ao fornecer ao administrador uma opção de configuração de CCR para que o servidor de caixas de correio clusterizadas fique online automaticamente em outro nó, com uma quantidade limitada de perda de dados. Quando isto ocorre, o sistema automaticamente entrega todas as mensagens recentes de email enviadas aos usuários do servidor, beneficiando-se do dumpster de transporte onde essas mensagens de email ainda estão armazenadas. Isso ajuda a evitar a perda de dados na maior parte das situações. Em um ambiente de CCR, a solicitação de nova entrega do dumpster de transporte em todos os servidores de Transporte de Hub do site é realizada automaticamente. No Exchange 2007 RTM, o intervalo de repetição é embutido em código para sete dias. No Exchange 2007 SP1, o intervalo de repetição é igual ao conjunto de valores para MaxDumpsterTime. Em um ambiente de LCR, a solicitação de nova entrega de todos os servidores de Transporte de Hub ocorre como parte da tarefa Restore-StorageGroupCopy

Situações em que a perda de dados não é mitigada pelo dumpster de transporte incluem:

  • Pasta rascunhos de qualquer cliente Microsoft Outlook no modo online.

  • Compromissos, atualizações de contatos, atualizações de propriedades, tarefas e atualizações de tarefas.

  • Emails de saída em trânsito do cliente para o servidor de Transporte de Hub. Há um período em que a mensagem de email existe somente no servidor de caixa de correio do remetente.

Implantando a Replicação Contínua em Cluster

A implantação da CCR é semelhante à de um servidor Exchange autônomo e à de um SCC. Para obter mais informações sobre SCCs, consulte Clusters de cópia única. Entretanto, há algumas diferenças significativas que devem ser levadas em conta na implantação de CCR. Recomendamos que você analise os tópicos a seguir antes de projetar e implantar CCR em seu ambiente:

Quando estiver pronto para a implantação de CCR, você poderá começar o processo executando as etapas em todas as fases da instalação descritas nos seguintes tópicos:

Aprimoramentos da CCR no Exchange 2007 SP1

O Exchange 2007 SP1 contém diversos aprimoramentos de CCR, inclusive mais elementos de interface do usuário do Console de Gerenciamento do Exchange, status e monitoramento aperfeiçoados e melhor desempenho.

Aprimoramentos do Console de Gerenciamento do Exchange

Vários elementos de interface de novo usuário foram adicionados no Exchange 2007 SP1, aprimorando a experiência de gerenciamento de recursos de alta disponibilidade, incluindo a CCR. Esses aprimoramentos incluem:

  • Interface de usuário de dumpster de transporte   Uma nova guia Configurações Globais foi adicionada ao nó de Transporte de Hub na área de trabalho Configuração da Organização. Essa guia inclui uma página de Propriedades de Configurações de Transporte que pode ser usada para definir as configurações de dumpster de transporte para a organização:

    • Tamanho máximo por grupo de armazenamento (MB)   Especifica o tamanho máximo da fila do dumpster de transporte para cada grupo de armazenamento.

    • Tempo máximo de retenção (dias)   Especifica por quanto tempo um email deverá permanecer na fila do dumpster de transporte.

  • Replicação contínua   Foram incluídos no Console de Gerenciamento do Exchange controles adicionais de interface do usuário que permitem que o administrador suspenda, continue, atualize e restaure a replicação contínua. Esses controles são equivalentes ao uso dos seguintes cmdlets do Shell de Gerenciamento do Exchange:

    • Suspend-StorageGroupCopy

    • Resume-StorageGroupCopy

    • Update-StorageGroupCopy

    • Restore-StoreGroupCopy

    Você pode usar esses cmdlets e as tarefas do Console de Gerenciamento do Exchange correspondentes para gerenciar a replicação contínua nos ambientes CCR e LCR.

Aprimoramentos de Monitoramento e Status

O Exchange 2007 SP1 também apresenta várias alterações que foram criadas para aprimorar a gerenciabilidade do Exchange 2007. Essas alterações aprimoram os recursos de relatório de cluster no Exchange 2007 RTM e incluem uma funcionalidade adicional criada para monitoramento pró-ativo de ambientes de replicação contínua. Especificamente, as alterações e aprimoramentos corrigem deficiências conhecidas com o cmdlet Get-StorageGroupCopyStatus, apresentam um novo cmdlet chamado Test-ReplicationHealth e fornecem maior visibilidade pela janela de perda coberta pelo dumpster de transporte.

Aprimoramentos do Cmdlet Get-StorageGroupCopyStatus

No Exchange 2007 RTM, há várias condições em que o status reportado por Get-StorageGroupCopyStatus e os contadores de desempenho de replicação contínua são imprecisos ou confusos:

  • Um grupo de armazenamento inativo (ou seja, que não esteja alterando) pode informar seu status como adequado quando, na verdade, não está. Esse cenário ocorre por que uma condição inadequada não foi detectada até que um log seja repetido.

  • Durante a inicialização da replicação, o status da replicação está sendo reavaliado e pode não ser preciso. Quando a inicialização estiver concluída, o status será atualizado.

  • O valor do campo LastLogGenerated pode estar errado quando um banco de dados no grupo armazenamento é desmontado.

  • Quando há um ou mais logs ausentes no meio de um fluxo de logs, a cópia passiva continua tentando fazer a recuperação, fazendo com que o status de replicação alterne entre os estados de falha e os estados adequados. Quando isto ocorre, as filas de repetição e de cópia continuam a crescer.

  • Em algumas condições raras, um log pode ser verificado com êxito, mas a repetição pode falhar mesmo assim. Nessa situação, o sistema alternará entre os estados com falha e adequado, enquanto tentar recuperar. Quando isto ocorre, as filas de repetição e de cópia continuam a crescer.

O cmdlet Get-StorageGroupCopyStatus também foi aprimorado com a adição de novas informações sobre o status de ambientes CCR:

  • O cmdlet Get-StorageGroupCopyStatus relata um SummaryCopyStatus de ServiceDown quando o serviço de Replicação do Microsoft Exchange no computador de destino não está acessível por rede.

  • O cmdlet Get-StorageGroupCopyStatus relata um SummaryCopyStatus de Inicializando quando o serviço de Replicação do Microsoft Exchange no computador de destino não concluiu suas verificações iniciais de inicialização. Um novo contador de desempenho também foi criado para representar este status como Booleano.

  • O cmdlet Get-StorageGroupCopyStatus relatará um SummaryCopyStatus de Sincronizando quando não tiver concluído uma nova propagação incremental.

Os novos estados do valor SummaryCopyStatus serão visíveis apenas ao utilizar a versão SP1 do Exchange 2007 das ferramentas de gerenciamento do Exchange. Quando você utilizar a versão RTM do Exchange 2007 das ferramentas de gerenciamento do Exchange, o status de qualquer um dos estados anteriores será relatado como Com Falha.

Cmdlet Test-ReplicationHealth

O Exchange 2007 SP1 apresenta um novo cmdlet chamado Test-ReplicationHealth. Esse cmdlet é projetado para monitoramento pró-ativo de replicação contínua e da pipeline de replicação contínua. O cmdlet Test-ReplicationHealth verifica todos os aspectos da replicação, os serviços de Cluster e a replicação do grupo de armazenamento e o status de replay para fornecer uma visão geral completa do sistema de replicação. Particularmente, quando executado em um nó no cluster, o cmdlet Test-ReplicationHealth realiza os testes descritos na tabela a seguir.

Testes realizados pelo cmdlet Test-ReplicationHealth cmdlet

Test Descrição

Status de rede de cluster

Verifique se todas as redes gerenciadas por clusters no nó local estão sendo executadas. Esse teste é executado apenas em um ambiente CCR.

Estado do grupo de quorum

Verifica se o grupo de cluster contendo o recurso de quorum está adequado. Esse teste é executado apenas em um ambiente CCR.

Estado do quorum de compartilhamento de arquivos

Verifica se o valor do FileSharePath usado pelo quorum de Conjunto de Nós Principais com testemunha de compartilhamento de arquivo está acessível. Esse teste é executado apenas em um ambiente CCR.

Estado do grupo de servidor de caixas de correio clusterizadas

Verifica se o servidor de caixas de correio clusterizadas está adequado, confirmando se todos os recursos no grupo estão online. Esse teste é executado apenas em um ambiente CCR.

Estado do nó

Verifica se nenhum dos nós no cluster está no estado pausado. Esse teste é executado apenas em um ambiente CCR.

Status do registro de DNS

Verifica se todas as interfaces de rede gerenciadas por cluster que tenham Exigir registro de DNS para obter êxito definido transmitiram o registro de DNS. Esse teste é executado apenas em um ambiente CCR.

Status do serviço de replicação

Verifica se o serviço de replicação do Microsoft Exchange no computador local está adequado.

Cópia do grupo de armazenamento suspensa

Verifica se a replicação contínua foi suspensa para qualquer grupo de armazenamento habilitado para a replicação contínua.

Falha na cópia do grupo de armazenamento

Verifica se todas as cópias do grupo de armazenamento estão em um estado de Falha.

Comprimento da fila de replicação do grupo de armazenamento

Verifica se algum grupo de armazenamento tem um comprimento da fila de cópias de replicação maior que os limites da prática recomendada. Atualmente, estes limites são:

  • Aviso   O comprimento da fila é de 3 a 5 logs.

  • Falha   O comprimento da fila é de 6 ou mais logs.

Bancos de dados desmontados após failover

Verifica se algum banco de dados está desmontado ou com falha após um failover. Este teste somente verifica os bancos de dados que falharam como resultado do failover.

Aprimoramentos no Desempenho

Aprimoramentos no desempenho que beneficiam as implantações de alta disponibilidade foram realizados no Exchange 2007 SP1. Esses aprimoramentos incluem:

  • Reduções de E/S nos discos contendo cópias passivas de grupos de armazenamento em ambientes de replicação contínua   No Exchange 2007 SP1, a estrutura da arquitetura da replicação contínua foi modificada para que o cache do banco de dados seja mantido no nó passivo entre lotes de atividade de repetição de log. A persistência do cache de banco de dados entre lotes da atividade de repetição de log habilita o serviço de replicação do Microsoft Exchange a aproveitar os recursos de cache de banco de dados do ESE, o que, por sua vez, reduz o volume de E/S de disco que ocorre nos LUNs (números de unidade lógica) da cópia passiva. Em contrapartida, no Exchange 2007 RTM, um novo cache de banco de dados foi criado para cada lote de atividade de repetição, o que, em alguns casos, duplica ou triplica a atividade de E/S do disco no nó ativo.

  • Movimentação mais rápida de servidores de caixas de correio clusterizadas entre nós em um ambiente CCR   Essas melhorias habilitam servidores de caixas de correio clusterizadas a se moverem entre nós em dois minutos ou menos. Isso inclui as movimentações realizadas por um administrador (usando o cmdlet Move-ClusteredMailboxServer) e failovers que são gerenciados pelo serviço de cluster. Para realizar movimentações rápidas em um ambiente CCR, os bancos de dados ficam offline sem liberar o cache do banco de dados. Esse comportamento reduz o tempo de inatividade que ocorre quando o servidor de caixas de correio clusterizadas é movido para outro nó.

Usando Replicação Contínua em Espera com CCR

A SCR é um novo recurso apresentado no Exchange 2007 SP1. A SCR estende os recursos de replicação contínua existentes e permite novos cenários de disponibilidade de dados para servidores de Caixa de Correio do Exchange 2007. A SCR usa o mesmo envio de logs e tecnologia de repetição usados pela LCR e pela CCR para fornecer configurações e opções de implantação adicionais.

A SCR permite que você use replicação contínua para replicar dados de servidor de caixa de correio de um servidor de caixa de correio autônoma (com ou sem LCR) ou de um servidor de caixas de correio clusterizadas (em um ambiente SCC ou CCR).

O processo de ativação de cópias de dados de servidor de caixa de correio que são criados e mantidos pela SCR é manual e foi criado para ser usado quando uma falha significativa ocorre (e não para interrupções simples de servidor que são recuperáveis através da reinicialização ou outra maneira rápida). Você pode ativar um destino SCR usando a portabilidade do banco de dados, a opção de recuperação de servidor (Setup /m:RecoverServer) ou, se o servidor de caixas de correio for em cluster, a opção de recuperação de servidor de caixas de correio clusterizadas (Setup /RecoverCMS). A opção escolhida será baseada em sua configuração e no tipo de falha que ocorrer.

Para obter mais informações sobre SCR, consulte Replicação Contínua Em Espera.

Para obter mais informações

Os tópicos a seguir abordam quando e como usar a CCR como parte de um plano de resiliência do site e de alta disponibilidade: