Instalando a Replicação Contínua em Cluster
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Tópico modificado em: 2007-10-30
Antes de implantar a replicação contínua em cluster (CCR), é recomendável ler atentamente Replicação Contínua em Cluster. Além disso, verifique se você atende a todos os requisitos especificados em Planejando a replicação contínua em cluster. A instalação de um ambiente CCR no Windows Server 2003 ocorre em diversas fases:
Instalação do hardware, começando com a formação e configuração da rede de cluster.
Formação de clusters, começando com o primeiro nó e, em seguida, com o segundo.
Configuração e proteção da testemunha de compartilhamento de arquivos, e configuração de redes de cluster e de tolerância a pulsações de cluster perdidas.
Instalação das funções de servidor Caixa de Correio ativa e passiva no cluster. O servidor de caixas de correio clusterizadas (CMS) será criado durante a instalação da função de servidor Caixa de Correio ativa.
Dica
Recomendamos que você conclua cada fase antes de iniciar a próxima fase. Após você concluir todas as fases, recomendamos a verificação da solução de CCR antes de colocá-la em produção.
Também será preciso executar algumas tarefas pós-instalação para o CMS:
Ajuste das configurações de controle de failover.
Ajustae da configuração padrão do dumpster de transporte.
Verificação da capacidade de mover um CMS entre os nós do cluster.
Habilitação de uma ou mais redes mistas para envio de logs e propagação.
As seções a seguir explicam cada uma das fases de instalação com mais detalhes.
Formação e configuração da rede
Você deverá ter um número suficiente de endereços IP estáticos disponíveis ao criar CMSs em um ambiente CCR de dois nós. Os endereços IP são necessários para as redes públicas e particulares; além disso, todos os endereços IP das redes de cluster deverão estar na mesma sub-rede. Estes são os requisitos relacionados a endereços públicos e particulares:
Endereços particulares Cada nó exige um endereço IP estático para cada adaptador de rede usado para a rede privada de cluster. Você deve usar endereços IP estáticos que não estejam na mesma sub-rede ou rede que uma das redes públicas. É recomendável usar 10.10.10.10 e 10.10.10.11 com a máscara de sub-rede 255.255.255.0 como endereços IP privados dos nós.
Endereços públicos Cada nó exige um endereço IP estático para cada adaptador de rede usado para a rede pública de cluster. Além disso, são necessários endereços IP estáticos para que o cluster de failover e o CMS possam ser acessados por clientes e administradores. Você deve usar endereços IP estáticos que não estejam na mesma sub-rede ou rede que uma das redes privadas.
Práticas recomendadas de rede para servidores de caixas de correio em cluster
Recomendamos também que você siga estas práticas recomendadas para a rede de cluster:
Usar nomes significativos A criação de um cluster dá a você muitas oportunidades de usar nomes significativos para nós de cluster, interfaces de rede de cluster, nome do cluster e nomes de CMS. Por exemplo, a rede usada para comunicação com outros servidores e clientes Exchange pode ser chamada Pública. A rede usada para comunicação entre os nós de cluster pode ser chamada Particular. Use nomes que possam ser relacionados entre si sem que seja necessário consultar um mapa de topologia. Outra convenção útil é relacionar os nós de um cluster ao nome do CMS. Por exemplo, use mbx01, mbx01-node1 e mbx01-node2 para o CMS e os dois nós, respectivamente.
Usar endereços IP privados para interfaces de rede privada Consulte a tabela a seguir para obter uma lista de intervalos de endereços IP e máscaras de sub-rede que podem ser usados para as interfaces de rede privada.
Intervalos de endereços e máscaras de sub-rede para interfaces de rede privada
Rede Intervalo de endereços IP Máscara de sub-rede Particular 1
10.10.10.10-255
255.255.255.0
Particular 2
10.10.10.11-255
255.255.255.0
Observe o seguinte:
Se sua rede pública usar uma rede 10.x.x.x e uma máscara de sub-rede 255.255.255.0, recomendamos que você use endereços IP e máscara de sub-rede de rede privada alternativos.
Recomendamos não usar nenhum tipo de adaptador com tolerância a falhas ou agrupamento para a rede privada. Se você precisar de redundância para a rede privada, use vários adaptadores de rede configurados para Apenas Comunicação Interna e defina a prioridade de rede na configuração do cluster. É importante verificar se a versão do firmware e do driver é a mais recente, caso você use essa tecnologia. Entre em contato com o fabricante do adaptador de rede para obter informações sobre compatibilidade em um cluster de servidor. Para obter mais informações sobre agrupamento de adaptadores de rede em implantações de clusters de servidores, consulte o artigo 254101 da Base de Dados de Conhecimento Microsoft, Agrupamento de adaptadores de rede e clusters de servidores (em inglês).
Para configurar as redes no cluster para uso com uma solução CCR do Microsoft Exchange Server 2007, configure as redes públicas e privadas seguindo as etapas descritas em Como configurar conexões de rede para Replicação Contínua em Cluster.
Formando o cluster de failover
Um cluster de failover é formado quando o primeiro nó é adicionado ao cluster. Esse processo fornece ao cluster um nome de rede e um endereço IP de rede exclusivos. O nome de rede e o endereço IP, que compõem coletivamente a identidade da rede do cluster, movem-se entre os nós do cluster à medida que os nós ficam online e offline. Geralmente, a identidade de rede do cluster é raramente usada na administração de um CMS.
Se estiver familiarizado com a implantação de clusters de failover ou de clusters do Exchange de versões anteriores, você achará a implantação de clusters para CCR algo completamente diferente. Se não tiver experiência em soluções de cluster, você achará a implantação muito menos complexa do que as configurações típicas de cluster.
Você pode criar um novo cluster usando as instruções em Como criar um cluster de failover do Windows Server 2003 para replicação contínua em cluster. Este procedimento inclui instruções para interface gráfica de usuário e interface de linha de comando para formar o cluster de failover, adicionando o segundo nó ao cluster de failover e configurando o cluster para usar um quorum de Conjunto de Nós Principais (MNS).
Dica
O CCR no Windows Server 2003 exige um modelo de quorum chamado quorum de MNS com testemunha de compartilhamento de arquivos. Esse modelo de quorum está disponível no Windows Server 2003 Service Pack 2 (SP2), que é necessário para o Exchange 2007 Service Pack 1 (SP1). Para usar o quorum de MNS com testemunha de compartilhamento de arquivos com a versão RTM do Exchange 2007 e o Windows Server 2003 SP1, instale um hotfix em cada nó antes de implantar a CCR. O hotfix é descrito no artigo 921181 da Base de Dados de Conhecimento, Está disponível uma atualização que adiciona um recurso de testemunha de compartilhamento de arquivos e um recurso de pulsações de cluster configuráveis aos clusters de servidor baseados no Microsoft Windows Server 2003 Service Pack 1 (página em inglês). Para obter etapas detalhadas sobre como instalar o hotfix, consulte Como instalar o recurso Testemunha de Compartilhamento de Arquivos do conjunto de nós principais.
Configuração pós-instalação do cluster de failover
Depois que o cluster de failover tiver sido formado com ambos os nós e configurado com um quorum de MNS, será necessário executar algumas tarefas pós-configuração antes de instalar o Exchange em qualquer dos nós. Configure as redes do cluster, a tolerância a perdas de heartbeats do cluster e o componente de testemunha de compartilhamento de arquivos do quorum de MNS.
Configurando as redes de cluster
Depois que ambos os nós tiverem sido adicionados ao cluster, os componentes de rede do cluster precisarão ser configurados. Especificamente, as redes do cluster, a prioridade da rede do cluster e as configurações de tolerância das pulsações de cluster perdidas precisam ser configuradas. A tabela a seguir detalha as opções disponíveis para configurar as redes do cluster.
Opções para configurar as redes do cluster
| Opção | Descrição |
|---|---|
Apenas acesso para cliente (rede pública) |
Selecione essa opção se desejar que o Serviço de cluster use esse adaptador de rede somente para comunicação externa com outros clientes. Nenhuma comunicação entre nós ou tráfego de atualização de bancos de dados de cluster ocorrerá nesse adaptador de rede. |
Apenas comunicação interna de clusters (rede privada) |
Selecione essa opção se desejar que o serviço de Cluster use a rede somente para a comunicação entre nós de cluster e para o tráfego de atualização de bancos de dados de cluster. |
Todas as comunicações (rede mista) |
Selecione essa opção se desejar que o serviço de Cluster use o adaptador de rede para a comunicação entre nós de cluster e para o tráfego de atualização de bancos de dados de cluster e para comunicação com clientes externos. Essa opção é selecionada por padrão para todas as redes. |
Para que haja suporte aos CMSs implantados em um ambiente CCR, eles precisam de pelo menos duas placas de rede em ambos os nós. Em um ambiente CCR, recomendamos a configuração de uma rede como rede privada e a configuração de outra rede como rede mista. Se uma rede é configurada como rede privada, e a outra rede é configurada como uma rede pública, a rede privada representa um ponto de falha único para o CMS.
Para obter etapas detalhadas sobre como configurar os componentes de rede do cluster, consulte Como configurar os componentes e a prioridade da rede do cluster.
Configurando definições de tolerância para pulsações de cluster perdidas
Após a configuração da comunicação do cluster e da prioridade da rede, recomendamos que você configure definições específicas de tolerância para pulsações de cluster perdidas. Esta ação configura o serviço de cluster que monitora a conectividade da rede entre os nós de cluster para que seja tolerante a interrupções mais breves. Isso impede a ocorrência de failovers em alguns casos em que a interrupção de energia na rede é breve. Recomendamos configurar redes de cluster mistas e privadas em ambos os nós para que constituam dez pulsações perdidas. Esse nível de configuração corresponde a aproximadamente 12 segundos.
Para obter etapas detalhadas sobre como configurar tolerâncias de serviço de Cluster para pulsações perdidas, consulte How to Configure Tolerance Settings for Missed Cluster Heartbeats.
Configurando a testemunha de compartilhamento de arquivos
Após a formação e configuração do cluster, a testemunha de compartilhamento de arquivos deve ser configurada. O CCR usa a testemunha de 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 em um ambiente CCR ocorre quando:
Ocorrem falhas em todas as redes designadas para realizar comunicações internas de cluster.
Os dois nós não podem receber sinais de pulsação um do outro.
Os dois nós tornam-se o nó ativo ao colocar, ou tentar colocar, o CMS online.
O compartilhamento de arquivos para a testemunha pode ser hospedado em qualquer servidor que esteja executando o sistema operacional Microsoft Windows. No entanto, recomendamos que você use um servidor de Transporte de Hub no site do serviço de diretórios do Active Directory que contém os nós do cluster para hospedá-lo. Um servidor de Transporte de Hub é recomendado para assegurar que um administrador do Exchange tenha total autoridade e controle sobre o compartilhamento. Para obter etapas detalhadas sobre como configurar o compartilhamento de arquivos para uso como testemunha de compartilhamento de arquivos, consulte Como configurar a testemunha de compartilhamento de arquivos.
Instalação e configuração do servidor de caixas de correio em cluster
Você pode instalar a função de servidor Caixa de Correio em um cluster, executando algumas etapas em cada nó. Depois que o cluster for formado e validado e tiver sido configurado para usar o quorum de MNS com a testemunha de compartilhamento de arquivos, você deverá instalar primeiro a função de servidor Caixa de Correio no nó ativo. A instalação do nó ativo é um processo que instala a função de servidor Caixa de Correio no nó e, em seguida, cria um CMS no nó.
Para obter etapas detalhadas sobre como instalar a função de servidor Caixa de Correio no nó ativo, consulte Como instalar a função de Caixas de Correio Clusterizadas Ativas em um ambiente de CCR no Windows Server 2003.
Dica
Se você estiver instalando o nó ativo em um computador com Windows Server 2003 que não esteja localizado no mesmo site do Active Directory que o controlador de domínio designado com a função de controlador de domínio primário (PDC), primeiramente você deverá criar uma conta de computador com o nome pretentido para o CMS. A conta de computador deverá ser habilitada e o objeto computador deverá estar disponúvel no site local do Active Directory. Se não houver uma conta de computador para o CMS e o PDC não estiver no site local do Active Directory, a instalação não continuará.
Após instalar a função de servidor Caixa de Correio no nó ativo, recomendamos que você verifique se a configuração do banco de dados e dos logs de transações do primeiro grupo de armazenamento estão conforme o planejado. Talvez você precise movê-las antes de continuar com o segundo nó. Por padrão, o grupo de armazenamento inicial e o banco de dados são colocados em %Arquivos de programas%\Microsoft\Exchange Server\Mailbox\First Storage Group.
Para obter as etapas detalhadas sobre como configurar o primeiro grupo de armazenamento de um cluster, consulte Como mover um grupo de armazenamento e seu banco de dados.
Após instalar a função de servidor Caixa de Correio e um CMS no nó ativo e verificar a configuração do primeiro grupo de armazenamento, você deverá instalar a função de servidor Caixa de Correio no nó passivo. A instalação do nó passivo é um processo que instala a função de servidor Caixa de Correio no nó. Para obter etapas detalhadas sobre como instalar a função de servidor Caixa de Correio no nó passivo, consulte Como instalar a função de Caixas de Correio Clusterizadas Passivas em um ambiente de CCR no Windows Server 2003.
Tarefas pós-instalação
Após instalar a função de servidor Caixa de Correio nos dois nós e criar um CMS, você deverá executar algumas tarefas pós-instalação. Essas tarefas incluem:
Ajuste de configurações de controle de failover.
Ajuste da configuração padrão do dumpster de transporte.
Verificando a capacidade de mover um CMS entre os nós do cluster.
Habilitando várias redes para atividade de replicação contínua.
Ajustando as Configurações de Controle de Failover
A CCR inclui atributos que permitem controlar o comportamento de failover de um CMS. Configure esses atributos usando o cmdlet Set-MailboxServer. Esses atributos são fornecidos para que você possa controlar os dois algoritmos de decisão a seguir:
Algoritmo 1 O Algoritmo 1 controla se o banco de dados está montado no momento do failover. No tempo de failover, se for detectado que o banco de dados perdeu menos do que a quantidade de logs configurada, ele será montado automaticamente. O número aceitável de logs perdidos pode ser configurado com um valor chamado AutoDatabaseMountDial. Esse parâmetro, que é representado no Active Directory por um atributo do Exchange Server chamado msExchDataLossForAutoDatabaseMount, tem três valores: Lossless, Good Availability e Best Availability. Lossless indica 0 log perdido; Good Availability indica 3 logs perdidos; e Best Availability, que é o padrão, indica 6 logs perdidos. Ao configurar o sistema para Good Availability ou Best Availability, não use espaços. Por exemplo, use GoodAvailability e BestAvailability.
Algoritmo 2 O Algoritmo 2 permite que você determine se é mais importante estar online com dados antigos do que estar offline. Se a montagem do banco de dados falhar com base no algoritmo 1, você poderá estabelecer o tempo para realizar uma segunda verificação. O tempo de espera é configurado pelo atributo ForcedDatabaseMountAfter. O valor é definido em unidades de horas com o padrão ilimitado.
Importante
Quando o valor do ForcedDatabaseMountAfter for alcançado, o banco de dados será montado independentemente da cópia do grupo de armazenamento ter 1 log perdido, 10 logs perdidos ou 1.000 logs perdidos, os quais podem resultar em significativa perda de dados. Sendo assim, esse parâmetro não deve ser usado se os SLAs (acordos de nível de serviço) garantirem uma quantidade máxima de perda de dados possíveis.
Para obter mais informações sobre ajuste de failover, consulte Como ajustar o failover e montar configurações para Replicação Contínua em Cluster.
Ajustando o Dumpster de Transporte
O dumpster de transporte é um recurso da função de servidor de Transporte de Hub, que envia mensagens recebidas recentemente após uma interrupção não programada. O dumpster de transporte deve sempre ser ajustado quando se utiliza CCR ou LCR (replicação contínua local). O dumpster de transporte é habilitado em toda a organização definindo-se a quantidade de armazenamento disponível por grupo de armazenamento e o tempo de permanência da mensagem no dumpster de transporte.
O servidor de Transporte de Hub mantém uma fila de emails que foram entregues recentemente a um CMS. No caso de um failover com perdas, a CCR solicita automaticamente que todos os servidores de Transporte de Hub no site enviem novamente os emails da fila do dumpster de transporte. O armazenamento de informações exclui automaticamente as duplicatas e entrega novamente as mensagens perdidas. Você pode usar o Console de Gerenciamento do Exchange ou o cmdlet Set-TransportConfig do Shell de Gerenciamento Exchange para alterar as definições de configuração padrão do dumpster de transporte, que são aplicadas no nível de grupo de armazenamento.
Recomendamos configurar o parâmetro MaxDumpsterSizePerStorageGroup, que especifica o tamanho máximo da fila do dumpster de transporte de cada grupo de armazenamento, com um tamanho igual ao tamanho da mensagem máxima que pode ser enviada multiplicado por 1,5. Por exemplo, se o tamanho máximo das mensagens for 10 megabytes (MB), configure o parâmetro MaxDumpsterSizePerStorageGroup com um valor igual a 15 MB. Também recomendamos configurar o parâmetro MaxDumpsterTime, que especifica quanto tempo uma mensagem de email deve permanecer na fila do dumpster de transporte, com o valor 7.00:00:00, correspondente a 7 dias. Acreditamos que seja um tempo suficiente para permitir que uma interrupção estendida ocorra sem perda de mensagens de email. Ao usar o recurso de dumpster de transporte, será necessário espaço adicional em disco no servidor de Transporte de Hub para hospedar as filas do dumpster de transporte. A quantidade necessária de espaço de armazenamento é aproximadamente igual ao valor de MaxDumpsterSizePerStorageGroup multiplicado pelo número de grupos de armazenamento em todos os CMSs de um ambiente CCR e em todos os grupos de armazenamento habilitados para LCR no site do Active Directory que contém o servidor de Transporte de Hub.
Para obter etapas detalhadas sobre como habilitar e configurar o dumpster de transporte, consulte Como configurar o dumpster de transporte.
Verificando a solução de CCR
Depois de concluir a instalação de uma solução de CCR ou de fazer alterações significativas na configuração, recomendamos que você verifique a integridade e o status do CMS e se os dois nós estão corretamente configurados para oferecer suporte ao CMS.
A maneira recomendada de verificar a integridade e o status do CMS é executar os cmdlets Get-StorageGroupCopyStatus e Get-ClusteredMailboxServerStatus:
O cmdlet Get-StorageGroupCopyStatus fornece informações atuais sobre o status de replicação de cada grupo de armazenamento. Para obter etapas detalhadas sobre como exibir o status de grupos de armazenamento em um ambiente CCR, consulte Como exibir o status de uma cópia de replicação contínua de cluster usando o Shell de Gerenciamento do Exchange.
O cmdlet Get-ClusteredMailboxServerStatus fornece o status operacional básico do CMS. Para obter etapas detalhadas sobre como saber o status operacional básico de um CMS, consulte Como exibir o status de um servidor de caixas de correio em cluster.
A maneira recomendada de verificar se os dois nós são capazes de colocar o CMS online é usar o cmdlet Move-ClusteredMailboxServer para mover o CMS para cada nó.
Habilitando várias redes para atividade de replicação contínua
Na versão RTM do Exchange 2007, ocorrem todas as cópias e a propagação de arquivos de log na rede pública. No Exchange 2007 SP1, qualquer rede de cluster redundante configurada como uma rede mista pode ser habilitada para atividade de replicação contínua. Essa atividade inclui propagação e repropagação em grupo e envio de logs.
No Exchange 2007 SP1, somente as redes do cluster designadas como mistas podem ser habilitadas para replicação contínua. Uma rede mista é qualquer rede do cluster configurada para tráfego de acesso ao cluster (comunicação entre nós) e para cliente. As redes do cluster configuradas para acesso ao cluster, mas não para acesso para cliente (às vezes, chamadas de redes privadas) não podem ser habilitadas para replicação contínua.
O suporte a envio de logs em uma rede mista é configurado com o cmdlet Enable-ContinuousReplicationHostName. De maneira similar, a desativação deste recurso é realizada usando o cmdlet Disable-ContinuousReplicationHostName. Depois que um CMS é criado em um ambiente CCR, um administrador pode executar Enable-ContinuousReplicationHostName nos dois nós do cluster e especificar dois endereços IP e nomes de host. Depois de fazer isso, o sistema seleciona aleatoriamente uma rede mista para cópia do log após a configuração bem-sucedida e confirmação de que a rede mista está operacional.
Para obter etapas detalhadas sobre como habilitar redes de cluster para a atividade de replicação contínua, consulte Como habilitar redes redundantes de cluster para envio e propagação de logs no Windows Server 2003.
Dica
Além do nome do host, do endereço IP e do grupo de cluster que é criado no cluster de failover, toda vez que você executa o cmdlet Enable-ContinuousReplicationHostName, você também está criando uma conta de computador no domínio do Active Directory que contém o CMS. Por padrão, no Windows Server 2003, o número máximo de contas de computador que podem ser adicionadas por um usuário ao qual não tenham sido delegados privilégios de administrador de domínios nem concedidas as ACEs (entradas de controle de acesso) Criar Objetos de Computador e Excluir Objetos de Computador é dez. Um administrador do Exchange que use os cmdlets Enable-ContinuousReplicationHostName e Disable-ContinuousReplicationHostName com freqüência e não tenha privilégios de administrador de domínio ou as ACEs mencionadas acima pode chegar ao limite de dez contas rapidamente. Soluções alternativas para esse problema estão documentadas no artigo 307532 da Base de Dados de Conhecimento, How to troubleshoot the Cluster service account when it modifies computer objects. Informações adicionais podem ser encontradas no artigo 251335 da Base de Dados de Conhecimento, Domain Users Cannot Join Workstation or Server to a Domain.
A propagação e a nova propagação em um ambiente CCR são executadas com o cmdlet Update-StorageGroupCopy. No Exchange 2007 SP1, esse cmdlet foi estendido para incluir um novo parâmetro chamado DataHostNames. Esse parâmetro é usado para especificar qual rede deve ser usada para propagação ou nova propagação. O valor é uma lista com vários valores de dois nomes: um FQDN (nome de domínio totalmente qualificado) ou um nome de host. Um desses nomes deve identificar o nó passivo.