Planejamento da alta disponibilidade e resiliência do site

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2016-11-28

O Microsoft Exchange Server 2010 inclui uma nova estrutura unificada para resiliência da caixa de correio que inclui novos recursos como o DAG (grupo de disponibilidade do banco de dados) e cópias do banco de dados de caixa de correio. Muito embora a implantação desses novos recursos seja um processo rápido e simples, deve haver um planejamento cuidadoso prévio para assegurar que qualquer solução resiliente do site e de alta disponibilidade que use esses recursos atenda às suas expectativas e aos seus requisitos de negócios.

Durante a fase de planejamento, os arquitetos de sistema, os administradores e as outros participantes principais devem identificar os requisitos do desenvolvimento, em especial os requisitos de alta disponibilidade e de resiliência do site. Existem requisitos gerais que devem ser atendidos para a implantação desses recursos, bem como requisitos de hardware, software e rede que também devem ser atendidos. Para obter diretrizes sobre os requisitos de armazenamento para DAGs, consulte Design do Armazenamento do Servidor de Caixa de Correio.

Sumário

Requisitos gerais

Requisitos de hardware

Requisitos de repositório

Requisitos de software

Requisitos de rede

Requisitos de servidor testemunha

Planejando a resiliência do site

Planejamento de alternâncias de datacenter

Requisitos gerais

Antes de implantar um DAG e criar cópias de banco de dados de caixa de correio, certifique-se de que as recomendações de sistema a seguir foram atendidas:

• O DNS (Sistema de Nomes de Domínio) deve estar em execução. O ideal é que o servidor DNS aceite atualizações dinâmicas. Se o servidor DNS não aceitar atualizações dinâmicas, você deverá criar um registro de host DNS (A) para cada servidor do Exchange. Caso contrário, o Exchange não funcionará corretamente.

• Cada servidor de caixa de correio em um DAG deve ser um servidor membro no mesmo domínio.

• Não há suporte para a adição de um servidor de caixa de correio do Exchange 2010 que também seja um servidor de diretório para um DAG.

• O nome atribuído ao DAG deve ser um nome de computador válido, disponível e exclusivo com 15 caracteres ou menos.

Requisitos de hardware

Em geral, não há nenhum requisito de hardware especial que seja específico de DAGs ou cópias de banco de dados de caixa de correio. Os servidores usados devem atender a todos os requisitos determinados nos tópicos para o Pré-requisitos do Exchange 2010 e o Requisitos de sistema do Exchange 2010. Para obter informações de planejamento de hardware, consulte os seguintes tópicos:

• Noções básicas sobre configurações de processador e desempenho do Exchange

• Noções Básicas Sobre Configurações de Memória e Desempenho do Exchange

• Design do Armazenamento do Servidor de Caixa de Correio

• Noções Básicas Sobre Taxas de Função de Servidor e Desempenho do Exchange

Requisitos de repositório

Em geral, não há nenhum requisito de armazenamento especial que seja específico de DAGs ou cópias de banco de dados de caixa de correio. Os DAGs não solicitam ou usam armazenamento compartilhado gerenciado por cluster. O armazenamento compartilhado gerenciado por cluster tem suporte para uso em um DAG somente quando o DAG é configurado para usar uma solução que aproveita a API de Replicação de Terceiros integrada ao Exchange 2010. Para obter informações de planejamento de armazenamento, consulte Design do Armazenamento do Servidor de Caixa de Correio.

Requisitos de software

OS DAGs estão disponíveis no Exchange 2010 Standard Edition e no Exchange 2010 Enterprise Edition. Além disso, um DAG pode conter uma combinação de servidores com o Exchange 2010 Standard Edition e o Exchange 2010 Enterprise Edition em execução.

Cada membro do DAG também deve ter o mesmo sistema operacional em execução. Há suporte para o Exchange 2010 nos sistemas operacionais Windows Server 2008 e Windows Server 2008 R2. Todos os membros de um DAG devem ter o Windows Server 2008 ou o Windows Server 2008 em execução. Eles não podem conter uma combinação de Windows Server 2008 e Windows Server 2008 R2.

Além de atender aos pré-requisitos de instalação do Exchange 2010, existem requisitos do sistema operacional que devem ser atendidos. Os DAGs usam a tecnologia de Agrupamento de Failover do Windows e, assim, exigem a versão Enterprise do Windows.

Requisitos de rede

Existem requisitos de rede específicos que devem ser atendidos para cada DAG e cada membro do DAG. As redes do DAG são semelhantes às redes públicas, mistas e privadas usadas em versões anteriores do Exchange. No entanto, diferentemente das versões anteriores, o uso de uma única rede em cada membro do DAG é uma configuração compatível. Além disso, a terminologia foi alterada um pouco. Em vez de redes públicas, privadas ou mistas, cada DAG tem uma única rede MAPI, usada por outros servidores (por exemplo, outros servidores do Exchange 2010, servidores de diretório etc.) para se comunicar com o membro do DAG, e zero ou mais redes de replicação, que são redes dedicadas a registrar em log o envio e a propagação.

Muito embora haja suporte para uma única rede, recomendamos que cada DAG tenha pelo menos duas redes: uma rede MAPI única e uma rede de replicação única. Isso fornece redundância para a rede e o caminho de rede, além de permitir ao sistema distinguir uma falha de servidor de uma falha de rede. O uso de um único adaptador de rede impede o sistema de distinguir esses dois tipos de falha.

Dica

A documentação do produto nesta área de conteúdo é escrita com o pressuposto de que cada membro do DAG contém pelo menos dois adaptadores de rede, que cada DAG está configurado com uma rede MAPI e pelo menos uma rede de replicação, além de o sistema ser capaz de distinguir uma falha de rede de uma falha de servidor.

Considere o seguinte ao criar a infraestrutura de rede para o DAG:

• Cada membro do DAG deve ter pelo menos um adaptador de rede capaz de se comunicar com todos os outros membros do DAG. Se você estiver usando um único caminho de rede, recomendamos usar gigabit Ethernet. Durante o uso de um único adaptador de rede em cada membro do DAG, a rede do DAG não precisa estar habilitada para replicação e deve ser configurada como uma rede MAPI. Como não há nenhuma outra rede, o sistema usará a rede MAPI também como uma rede de replicação. Além disso, durante o uso de um único adaptador de rede em cada membro do DAG, recomendamos criar a solução geral tendo o adaptador de rede único e o caminho em mente.

• O uso de dois adaptadores de rede em cada membro do DAG fornece uma rede MAPI e uma rede de replicação, além dos seguintes comportamentos de recuperação:

  • Se uma falha afetar a rede MAPI, ocorrerá um failover de servidor (pressupondo que haja cópias de banco de dados de caixa de correio íntegras que possam ser ativadas).

  • Em caso de uma falha afetar a rede de replicação, se a rede MAPI não for afetada pela falha, as operações de registro em log do envio e da propagação serão revertidas para usar a rede MAPI, mesmo se a rede MAPI tiver sua propriedade ReplicationEnabled definida como False. Quando a rede de replicação com falha for restaurada com integridade e estiver pronta para continuar as operações de registro em log do remessa e propagação, você deve alternar manualmente para a rede de replicação. Para alterar a replicação de uma rede MAPI para uma rede de replicação recuperada, você pode suspender e retomar a replicação contínua utilizando os cmdlets Suspend-MailboxDatabaseCopy e Resume-MailboxDatabaseCopy, ou reiniciar o serviço de replicação do Microsoft Exchange. Recomendamos utilizar as operações suspensas e retomar para evitar a breve interrupção causada ao reiniciar o serviço de replicação do Microsoft Exchange.

• Cada membro do DAG deve ter o mesmo número de redes. Por exemplo, se você pretende usar um único adaptador de rede em um membro do DAG, todos os membros do DAG também devem usar um único adaptador de rede.

• Cada DAG deve ter mais de uma rede MAPI. A rede MAPI deve fornecer conectividade a outros servidores do Exchange e outros serviços, como Active Directory e DNS.

• Redes de replicação adicionais podem ser adicionadas conforme necessário. Também é possível impedir um adaptador de rede individual de ser um único ponto de falha, usando uma equipe de adaptadores de rede ou tecnologia semelhante. No entanto, mesmo usando a equipe, isso não impede a rede de ser, ela própria, um único ponto de falha.

• Cada rede em cada servidor membro do DAG deve estar em sua própria sub-rede da rede. Cada servidor no DAG pode estar em uma sub-rede diferente, mas as redes MAPI e de replicação devem ser roteáveis e fornecer conectividade, como esta:

  • Cada rede em cada servidor membro do DAG está em sua própria sub-rede da rede separada da sub-rede usada por todas as outras redes no servidor.

  • A rede MAPI de cada servidor membro do DAG pode se comunicar com a rede MAPI de todos os outros membros do DAG.

  • A rede de replicação de cada servidor membro do DAG pode se comunicar com a rede de replicação de todos os outros membros do DAG.

  • Não há nenhum roteamento direto que permita o tráfego de pulsação da rede de replicação em um servidor membro do DAG para a rede MAPI em outro servidor membro DAG, ou vice-versa, ou entre várias redes de replicação no DAG.

• Independentemente do local geográfico relativo a outros membros do DAG, cada membro do DAG não deve ter uma latência de rede de viagem de ida e volta maior que 500 ms (milissegundos) entre cada membro. Conforme a latência de ida e volta entre dois servidores de caixa de correio hospedando cópias de um banco de dados aumenta, o potencial para que a replicação não esteja atualizada também aumenta. Seja qual for a latência da solução, os clientes devem validar que as redes entre todos os membros do DAG sejam capazes de atingir os objetivos de proteção de dados e disponibilidade da implantação. Configurações com valores de latência mais altos pode exigir um ajuste especial de parâmetros do DAG, de replicação e de rede, como o aumento do número de bancos de dados ou a diminuição do número de caixas de correio por banco de dados, para que se atinjam os objetivos desejados.

• Os requisitos de latência da viagem de ida e volta talvez não sejam os requisitos mais restritos de latência e de largura de banda da rede para uma configuração de vários datacenters. Avalie a carga de rede total, que inclui acesso para cliente, Active Directory, transporte, replicação contínua e outros tráfegos de aplicativo, para determinar os requisitos de rede necessários para o ambiente.

• As redes do DAG dão suporte ao IPv4 (protocolo IP versão 4) e ao IPv6 (protocolo IP versão 6). Só há suporte ao IPv6 quando o IPv4 também é usado; não há suporte a um ambiente de IPv6 puro. Só há suporte ao uso de endereços IPv6 e intervalos de endereços IP quando IPv6 e IPv4 estão habilitados nesse computador e a rede dá suporte a ambas as versões do endereço IP. Se o Exchange 2010 for implantado nessa configuração, todas as funções de servidor poderão enviar e receber dados de dispositivos, servidores e clientes que usem endereços IPv6.

• O endereçamento APIPA (Automatic Private IP Addressing) é um recurso do Microsoft Windows que atribui automaticamente endereços IP quando não há nenhum servidor de protocolo DHCP (Dynamic Host Configuration Protocol) disponível na rede. Não há suporte a endereços APIPA (inclusive endereços atribuídos manualmente do intervalo de endereços APIPA) a serem usados por DAGs ou pelo Exchange 2010.

Requisitos de endereço IP e nome do DAG

Durante a criação, cada DAG recebe um nome exclusivo e um ou mais endereços IP estáticos, ou configurados para usarem DHCP. Independentemente de usar endereços atribuídos estática ou dinamicamente, qualquer endereço IP atribuído ao DAG deve estar na rede MAPI.

Cada DAG exige pelo menos um endereço IP na rede MAPI. Um DAG exige endereços IP adicionais quando a rede MAPI é estendida em várias sub-redes. A figura a seguir ilustra um DAG em que todos os nós do DAG têm a rede MAPI na mesma sub-rede.

Grupo de disponibilidade do banco de dados com a rede MAPI na mesma sub-rede

Neste exemplo, a rede MAPI em cada membro do DAG está na sub-rede 172.19.18.x. Dessa forma, o DAG exige um único endereço IP nessa sub-rede.

A próxima figura ilustra um DAG com uma rede MAPI que se estende por duas sub-redes: 172.19.18.x e 172.19.19.x.

Grupo de disponibilidade do banco de dados com a rede MAPI em várias sub-redes

Neste exemplo, a rede MAPI em cada membro do DAG está em uma sub-rede separada. Dessa forma, o DAG exige dois endereços IP: um para cada sub-rede na rede MAPI.

Sempre que a rede MAPI do DAG for estendida até uma sub-rede adicional, um endereço IP adicional para essa sub-rede deverá ser configurado para o DAG. Todos os endereços IP configurados para o DAG são atribuídos a e usados pelo cluster de failover subjacente do DAG. O nome do DAG também é usado como o nome do cluster de failover subjacente.

A qualquer momento específico, o cluster do DAG só usará um dos endereços IP atribuídos. O Cluster de Failover do Windows registra esse endereço IP no DNS quando o endereço IP do cluster e os recursos de nome da rede estão online. Além de usar um endereço IP e um nome da rede, um CNO (objeto de rede de cluster) é criado no Active Directory. O nome, o endereço IP e o CNO do cluster são usados internamente pelo sistema para proteger o DAG e para fins de comunicação interna. Os administradores e os usuários finais não precisam ter interface com ou se conectar ao nome do DAG ou ao endereço IP.

Dica

Muito embora o endereço IP do cluster e o nome da rede sejam usados internamente pelo sistema, não há nenhuma dependência difícil no Exchange 2010 para que esses recursos estejam disponíveis. Mesmo se os recursos de endereço IP e nome da rede do cluster subjacente estiverem offline, a comunicação interna continuará ocorrendo dentro do DAG, usando os nomes do servidor membro do DAG. No entanto, recomendamos monitorar periodicamente a disponibilidade desses recursos para ter certeza de que eles não permaneçam offline por mais de 30 dias. Se o cluster subjacente permanecer offline por mais de 30 dias, a conta CNO do cluster poderá ser invalidada pelo mecanismo de coleta de lixo no Active Directory.

Configuração do adaptador de rede para DAGs

Cada adaptador de rede deve ser configurado corretamente com base no uso desejado. Um adaptador de rede usado para uma rede MAPI é configurado de maneira diferente de um adaptador de rede usado para uma rede de replicação. Além de configurar cada adaptador de rede corretamente, você também deve configurar a ordem de conexão da rede no Windows para que a rede MAPI esteja na parte superior da ordem de conexão. Para instruções detalhadas sobre como modificar a ordem de conexão da rede, consulte Modificar a ordem das ligações de protocolo.

Configuração do adaptador de rede MAPI

Um adaptador de rede a ser usado por uma rede MAPI deve ser configurado conforme a descrição na tabela a seguir.

Recursos de rede	Configuração
Cliente para redes Microsoft	Habilitado
Agendador de pacotes QoS	Opcionalmente, habilitar
Compartilhamento de arquivos e impressoras para redes Microsoft	Enable
TCP/IP v6 (protocolo IP versão 6)	Opcionalmente, habilitar
TCP/IP v4 (protocolo IP versão 4)	Enabled
Driver de E/S do mapeador da descoberta de topologia da camada de link	Enabled
Respondente da descoberta de topologia da camada de link	Enabled

As propriedades do TCP/IP v4 para um adaptador de rede MAPI são configuradas da seguinte forma:

• O endereço IP da rede MAPI do membro do DAG pode ser atribuído manualmente ou configurado para usar DHCP. Se o DHCP for usado, recomendamos o uso de reservas persistentes para o endereço IP do servidor.

• A rede MAPI normalmente usa um gateway padrão, embora ele não seja obrigatório.

• Pelo menos um endereço de servidor DNS deve ser configurado. É recomendável o uso de vários servidores DNS para redundância.

• A caixa de seleção Registrar endereços desta conexão no DNS deve ser marcada.

Configuração do adaptador de rede de replicação

Um adaptador de rede a ser usado por uma rede de replicação deve ser configurado conforme a descrição na tabela a seguir.

Recursos de rede	Configuração
Cliente para redes Microsoft	Desabilitado
Agendador de pacotes QoS	Opcionalmente, habilitar
Compartilhamento de arquivos e impressoras para redes Microsoft	Desabilitado
TCP/IP v6 (protocolo IP versão 6)	Opcionalmente, habilitar
TCP/IP v4 (protocolo IP versão 4)	Enabled
Driver de E/S do mapeador da descoberta de topologia da camada de link	Enabled
Respondente da descoberta de topologia da camada de link	Enabled

As propriedades do TCP/IP v4 para um adaptador de rede de replicação são configuradas da seguinte forma:

• O endereço IP da rede de replicação do membro do DAG pode ser atribuído manualmente ou configurado para usar DHCP. Se o DHCP for usado, recomendamos o uso de reservas persistentes para o endereço IP do servidor.

• As redes de replicação normalmente não têm gateways-padrão e, se a rede MAPI tiver um, nenhuma outra rede deverá ter. O roteamento do tráfego de rede em uma rede de replicação pode ser configurado usando-se rotas persistentes e estáticas para a rede correspondente em outros membros do DAG que usam endereços de gateway com a possibilidade de rotear entre as redes de replicação. Todo o outro tráfego correspondente a essa rota será tratado pelo gateway padrão configurado no adaptador da rede MAPI.

• Os endereços de servidor DNS não devem ser configurados.

• A caixa de seleção Registrar endereços desta conexão no DNS não deve ser marcada.

Requisitos gerais

Requisitos de servidor testemunha

Servidor testemunha é um servidor fora de um DAG usado para atingir e manter um quorum quando o DAG tiver um número par de membros. Os DAGs com um número ímpar de membros não usam um servidor testemunha. Todos os DAGs com um número par de membros usarão um servidor testemunha. O servidor testemunha pode ser qualquer computador com o Windows Server em execução. Não há nenhum requisito de que a versão do sistema operacional Windows Server do servidor testemunha corresponda ao sistema operacional usado por membros do DAG.

O quorum é mantido no nível do cluster, abaixo do DAG. Um DAG tem quorum quando a maioria de seus membros estão online e podem se comunicar com os outros membros online do DAG. Essa noção de quorum é um aspecto do conceito de quorum no failover de cluster do Windows. Um aspecto relacionado e necessário ao quorum em clusters de failover é o recurso de quorum. O recurso de quorum é um recurso dentro de um cluster de failover que fornece um meio de arbitragem que leva a um estado de cluster e decisões de associação. O recurso de quorum também fornece armazenamento persistente para armazenar informações de configuração. Um complemento ao recurso de quorum é o log de quorum, que é um banco de dados de configuração do cluster. O log de quorum contém informações como quais servidores são membros do cluster, quais recursos são instalados no cluster e o estado desses recursos (por exemplo, online ou offline).

É essencial que cada membro do DAG tenha uma exibição consistente de como o cluster subjacente do DAG está configurado. O quorum funciona como o repositório definitivo de todas as informações de configuração relacionadas ao cluster. O quorum também é usado como um desempate para evitar a síndrome da "divisão". A síndrome da divisão é uma condição que ocorre quando os membros do DAG não conseguem se comunicar, embora estejam em funcionamento. A síndrome da divisão é evitada exigindo-se sempre a disponibilidade e a interação da maioria dos membros do DAG (e, no caso dos DAGs com um número par de membros, o servidor testemunha do DAG) para que o DAG esteja operacional.

Planejando a resiliência do site

Diariamente, mais e mais empresas reconhecem que o acesso a um sistema de mensagens confiável e disponível é fundamental para seu sucesso. Para muitas organizações, o sistema de mensagens faz parte dos planos de continuidade dos negócios, e a implantação do serviço de mensagens foi projetada tendo a resiliência do site em mente. Fundamentalmente, muitas soluções resilientes do site envolvem a implantação de hardware em um segundo datacenter.

Em último caso, o design geral de um DAG, inclusive o número de membros do DAG e o número de cópias de banco de dados de caixa de correio, dependerá dos SLAs (contratos de nível de serviço) de recuperação de cada organização que cobrem vários cenários de falha. Durante o estágio de planejamento, os arquitetos das soluções e os administradores identificam os requisitos de implantação, inclusive os requisitos da resiliência do site em especial. Eles identificam o(s) local(is) a ser(em) usado(s) e os alvos de SLA de recuperação obrigatórios. O SLA identificará dois elementos específicos que devem ser a base do design de uma solução que fornece alta disponibilidade e resiliência do site: o RTO (Recovery Time Objective) e o RPO (Recovery Point Objective). Esses valores são medidos em minutos. RTO é o tempo necessário para a restauração do serviço. RPO se refere à atualização dos dados após a conclusão da operação de recuperação. Um SLA também pode ser definido para restaurar o serviço completo do datacenter principal após a correção de seus problemas.

Os arquitetos das soluções e os administradores também identificarão qual conjunto de usuários exige proteção de resiliência do site e determinarão se a solução multissite terá a configuração ativa/passiva ou ativa/ativa. Em uma configuração ativa/passiva, nenhum usuário costuma ser hospedado em um datacenter em espera. Em uma configuração ativa/ativa, os usuários são hospedados em ambos os locais, e parte da porcentagem do número total de bancos de dados dentro da solução tem um local ativo preferencial em um segundo datacenter. Quando há falha no serviço para os usuários de um datacenter, esses usuários são ativados no outro datacenter.

A criação dos SLAs apropriados normalmente exige respostas para as seguintes perguntas básicas:

• Que nível de serviço é exigido após a falha do data center principal?

• Os usuários precisam de seus dados ou apenas de serviços de mensagens?

• Com que rapidez os dados são exigidos?

• Quantos usuários devem ter suporte?

• Como os usuários acessarão seus dados?

• O que é o SLA de ativação do datacenter em espera?

• Como o serviço é movido novamente para o datacenter principal?

• Os recursos são dedicados para a solução de resiliência do site?

Respondendo essas perguntas, você começa a formar um design resiliente do site para a solução de mensagens. Um requisito básico da recuperação de falha do site é criar uma solução que leve os dados necessários para o datacenter em espera que hospeda o serviço de mensagens em espera.

Planejamento de namespace

O Exchange 2010 altera a forma com que você planeja o design do namespace ao implantar uma configuração resiliente do site. O planejamento de namespace apropriado é essencial para que haja êxito nas alternâncias de datacenter. Do ponto de vista de um namespace, cada datacenter usado em uma configuração de resiliência do site é considerado ativo. Dessa forma, cada datacenter exigirá seu próprio namespace exclusivo para os vários serviços do Exchange 2010 nesse site, inclusive namespaces para Outlook Web App, Outlook Anywhere, Serviços Web do Exchange ActiveSync, Exchange, Acesso para Cliente RPC, protocolo POP3 (Post Office Protocol version 3), protocolo IMAP4 (Internet Message Access Protocol version 4) e protocolo SMTP (Simple Mail Transfer Protocol). Além disso, um dos datacenters também hospeda o namespace para Descoberta Automática. Esse design também permite realizar uma alternância de banco de dados único do datacenter principal para um segundo datacenter a fim de validar a configuração dos dados secundários como parte da validação e da prática de alternância de um datacenter.

Como prática, recomendamos que você use DNS dividido para os nomes de host do Exchange usados por clientes. DNS dividido refere-se a uma configuração de servidor DNS na qual os servidores DNS internos retornam um endereço IP interno para um nome de host e servidores DNS externos (voltados para Internet) retornam um endereço IP público para o mesmo nome de host. Como o uso de DNS dividido utiliza os mesmos nomes de host interna e externamente, essa estratégia permite que você minimize o número de nomes de hosts necessários.

A figura a seguir ilustra o planejamento de namespace para a configuração resiliente de um site.

Namespaces para a implantação do DAG resiliente de site

Conforme mostrado acima, cada datacenter usa um namespace separado e exclusivo e cada um contém servidores DNS em uma configuração de DNS dividido para esses namespaces. O datacenter Redmond, considerado o datacenter principal, está configurado com um namespace de protocolo.contoso.com. Já o datacenter Portland está configurado com um namespace de protocolo.standby.contoso.com. Os namespaces podem incluir designações de em espera, como na figura do exemplo, podem ser baseados na região (por exemplo, protocolo.portland.contoso.com) ou podem ser baseados em outras convenções de nomenclatura que atendam às necessidades da organização. O requisito principal é que, independentemente da convenção de nomenclatura usada, cada datacenter tenha seu próprio namespace exclusivo.

Configuração de FailbackURL

Alguns navegadores da Web, incluindo o Microsoft Internet Explorer, mantém o cache de nome DNS durante cada sessão do navegador que é separado do cache DNS fornecido pelo sistema operacional. Durante o failback para o datacenter primário após uma alternância de datacenter, o uso que o navegador Web faz desse cache separado pode resultar em loops de logon para usuários do Outlook Web App, onde os usuários são redirecionados para a mesma URL em um loop repetitivo.

Durante o processo de failback, o endereço IP do namespace do Outlook Web App é alterado no DNS de um ponto de extremidade no datacenter em espera de volta para seu ponto de extremidade original no datacenter primário. Depois que o TTL do registro de DNS expira, e até depois que o cache de DNS do sistema operacional é limpo, os navegadores Web que mantêm seu próprio cache de nomes em separado podem continuar conectando ao ponto de extremidade no datacenter em espera, mesmo que o namespace esteja hospedado no datacenter primário.

Geralmente basta fechar o navegador da Web para limpar seu cache de nomes em separado e impedir os loops de logon. Porém, para minimizar o problema para todos os usuários de navegadores da Web e do Outlook Web App, você pode configurar a propriedade FailbackURL de seu diretório virtual do Outlook Web App. O parâmetro FailbackUrl especifica o nome de host que o Outlook Web App usa para se conectar ao servidor de Acesso para Cliente após o failback para um site primário. Esse namespace exige uma entrada de DNS separada apontando para o endereço IP original do servidor de Acesso para Cliente. O valor do parâmetro FailbackUrl deve ser diferente do valor do parâmetro ExternalUrl para o diretório virtual do Outlook Web App. Quando um usuário do Outlook Web App fornece suas credenciais, o servidor de Acesso para Cliente irá detectar se a URL de redirecionamento é a mesma URL que o usuário está visitando. Se as URLs forem iguais, o servidor de Acesso para Cliente irá verificar se o parâmetro FailbackUrl está configurado:

• Se o parâmetro FailbackUrl estiver configurado, ele irá redirecionar o usuário para a URL onde ele deve ser capaz de acessar o Outlook Web App.

• Se o parâmetro FailbackUrl não estiver configurado, o usuário irá receber uma mensagem de erro indicando que uma alteração na configuração do servidor está impedindo temporariamente o acesso à sua caixa de correio. A mensagem instrui o usuário a fechar todas as janelas do navegador (apagando o cache de nomes do navegador) e tentar novamente em alguns minutos.

Planejamento de certificado

Não há nenhuma consideração exclusiva ou especial quanto ao design de certificados durante a implantação de um DAG em um único datacenter. No entanto, durante a extensão de um DAG por vários datacenters em uma configuração resiliente do site, existem algumas considerações específicas em relação aos certificados. Em geral, o design do certificado dependerá do uso dos clientes, bem como dos requisitos de certificado de outros aplicativos que usam certificados. Mas há algumas recomendações específicas e práticas recomendadas que você deve seguir com relação ao tipo e ao número de certificados.

Como uma melhor prática, você deve minimizar o número de certificados usados para os servidores de Acesso para Cliente, os servidores de proxy reverso e os servidores de transporte (de Borda e Hub). Recomendamos o uso de um único certificado para todas esses pontos de extremidade de serviço em cada datacenter. Essa abordagem minimiza o número de certificados necessários, o que reduz o custo e a complexidade da solução.

Para clientes do Outlook Anywhere, recomendamos que você use um único certificado SAN (Nome Alternativo Para o Requerente) para cada datacenter e inclua vários nomes de host no certificado. Para assegurar a conectividade do Outlook Anywhere após a alternância de um banco de dados, servidor ou datacenter, você deve usar o mesmo Nome Principal do Certificado em cada certificado e configurar o objeto de configuração do provedor do OutlookActive Directory com o mesmo Nome Principal na Forma Padrão Microsoft (msstd). Por exemplo, se usasse um Nome Principal do Certificado de mail.contoso.com, você configuraria o atributo da seguinte forma:

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Alguns aplicativos que se integram ao Exchange têm requisitos de certificados específicos que podem exigir o uso de certificados adicionais. O Exchange 2010 pode coexistir com o OCS (Office Communications Server). O OCS exige certificados com 1024 bits ou certificados maiores que usam o nome de servidor do OCS para o Nome Principal do Certificado. Como o uso de um nome de servidor do OCS para o Nome Principal do Certificado impediria o Outlook Anywhere de funcionar corretamente, você precisaria usar um certificado adicional e à parte para o ambiente do OCS.

Para obter mais informações sobre como usar certificados SAN para o acesso para cliente ao Exchange 2010, consulte Configurar Certificados SSL para Usar Vários Nomes do Host do Servidor de Acesso para Cliente.

Planejamento de rede

Além dos requisitos específicos de rede que devem ser atendidos para cada DAG, bem como para cada servidor membro de um DAG, existem alguns requisitos e recomendações específicos de configurações de resiliência do site. Assim como acontece com todos os DAGs, independentemente de os membros do DAG serem implantados em um único site ou em vários sites, a latência de rede de retorno da viagem de ida e volta entre os membros do DAG e o DAG não deve ser maior que 500 ms. Além disso, há definições de configuração específicas recomendáveis para os DAGs que se estendem por vários sites:

• Redes MAPI devem ser isoladas das redes de replicação As diretivas de rede do Windows, as diretivas de firewall do Windows ou as ACLs (listas de controle de acesso) devem ser usadas para bloquear o tráfego entre a rede MAPI e a(s) rede(s) de replicação. Essa configuração é necessária para impedir o crosstalk de pulsação da rede.

• Registros DNS voltados para o cliente devem ter uma TTL (vida útil) de cinco minutos O tempo de inatividade enfrentado pelo cliente depende não apenas da velocidade com que pode ocorrer a alternância, mas também da velocidade com que ocorre a replicação do DNS e da velocidade com que os clientes consultam informações atualizadas do DNS. Os registros de DNS de todos os serviços de cliente do Exchange, inclusive Outlook Web App, Exchange ActiveSync, Serviços Web do Exchange, Outlook Anywhere, SMTP, POP3, IMAP4 e Acesso para Cliente RPC nos servidores DNS internos e externos devem ser definidos com uma TTL de cinco minutos.

• Usar rotas estáticas para configurar a conectividade em redes de replicação Para fornecer a conectividade de rede entre cada um dos adaptadores de rede de replicação, use rotas estáticas persistentes. Essa é uma configuração rápida e única realizada em todos os membros do DAG durante o uso de endereços IP estáticos. Se você estiver usando o DHCP para obter endereços IP para redes de replicação, também será possível usá-lo para atribuir rotas estáticas para a replicação, o que simplifica o processo de configuração.

Planejamento de resiliência do site geral

Além dos requisitos listados acima para alta disponibilidade, existem outras recomendações para implantar o Exchange 2010 em uma configuração resiliente do site (por exemplo, a extensão de um DAG até vários datacenters). O que você faz durante a fase de planejamento afetará diretamente o êxito da solução de resiliência do site. Por exemplo, um design de namespace ruim pode causar dificuldades com certificados, e uma configuração de certificado incorreta pode impedir usuários de acessar serviços.

Para minimizar o tempo necessário à ativação de um segundo datacenter e permitir ao segundo datacenter hospedar os pontos de extremidade de serviço de um datacenter com falha, o planejamento apropriado deve ser concluído. Por exemplo:

• As metas de SLA para a solução de resiliência do site devem estar bem compreendidas e documentadas.

• Os servidores no segundo datacenter devem ter capacidade suficiente para hospedar a população de usuários combinada de ambos os datacenters.

• O segundo datacenter deve ter todos os serviços habilitados fornecidos no datacenter principal (a menos que o serviço não esteja incluído como parte do SLA de resiliência do site). Isso inclui o Active Directory, a infraestrutura de rede (DNS, TCP/IP etc.), os serviços de telefonia (se a Unificação de Mensagens estiver sendo usada) e a infraestrutura do site (energia, refrigeração etc.).

• Para que alguns serviços possam atender a usuários do datacenter com falha, eles devem ter os certificados de servidor configurados corretamente. Alguns serviços não permitem a instanciação (por exemplo, POP3 e IMAP4) e só permitem o uso de um único certificado. Nesses casos, o certificado deve ser um certificado SAN que inclua vários nomes, ou os vários nomes devem ser semelhantes o suficiente para que um certificado curinga possa ser usado (pressupondo que as diretivas de segurança da organização permitam o uso de certificados curinga).

• Os serviços necessários devem ser definidos no segundo datacenter. Por exemplo, se o primeiro datacenter tiver três URLs SMTP diferentes em servidores de transporte diferentes, a configuração apropriada deverá ser definida no segundo datacenter para habilitar pelo menos um (se não todos os três) servidor de transporte para hospedar a carga de trabalho.

• A configuração de rede necessária deve estar in-loco para dar suporte à alternância de datacenter. Isso pode significar a verificação de que as configurações de balanceamento de carga estejam in-loco, de que o DNS global esteja configurado e de que a conexão da Internet esteja habilitada com o roteamento apropriado configurado.

• A estratégia de habilitação das alterações de DNS necessárias a uma alternância de datacenter deve ser compreendida. As alterações de DNS específicas, inclusive suas configurações de TTL, devem ser definidas e documentadas para dar suporte ao(s) SLA(s) em vigor.

• A estratégia de teste da solução também deve ser estabelecida e considerada no SLA. A validação periódica da implantação é a única forma de garantir que a qualidade e a viabilidade da implantação não sejam degradadas com o passar do tempo. Após a validação da implantação, recomendamos que a parte da configuração que afeta diretamente o êxito da solução seja documentada explicitamente. Além disso, recomendamos que você aperfeiçoe os processos de gerenciamento de alterações quanto a esses segmentos da implantação.

Requisitos gerais

Planejamento de alternâncias de datacenter

O planejamento e a preparação apropriados envolvem não apenas a implantação dos recursos do segundo datacenter, como servidores de Acesso para Cliente e servidores de Transporte de Borda, mas também a pré-configuração desses recursos para minimizar as alterações obrigatórias como parte de uma operação de alternância de datacenter.

Dica

Os serviços de Acesso para Cliente e de Transporte de Borda são obrigatórios no segundo datacenter, mesmo quando a ativação automática dos bancos de dados de caixa de correio no segundo datacenter está bloqueada. Esses serviços são necessários para realizar alternâncias de banco de dados, bem como realizar testes e validações dos serviços e dos dados no segundo datacenter.

Para compreender melhor a forma como funciona o processo de uma alternância de datacenter, é útil compreender a operação básica da alternância de um datacenter do Exchange 2010.

Conforme a ilustração na figura a seguir, uma implantação resiliente do site consiste em um DAG com membros em ambos os datacenters.

Grupo de disponibilidade do banco de dados com membros em dois datacenters

Quando um DAG é estendido até vários datacenters, ele deve ser criado de forma que a maioria dos membros do DAG esteja localizada no datacenter principal ou, quando cada datacenter tiver o mesmo número de membros, o datacenter principal hospedará o servidor testemunha. Esse design garante que o serviço será fornecido no datacenter principal, mesmo se houver falha na conectividade de rede entre os dois datacenters. No entanto, isso também significa que, quando houver falha no datacenter principal, o quorum será perdido para os membros do segundo datacenter.

Também são possíveis falhas parciais no datacenter e elas acontecerão. A pressuposição é de que se houver perda de funcionalidade suficiente no datacenter principal a ponto de impedir o serviço e o gerenciamento efetivos, uma alternância de datacenter deverá ser realizada para ativar o segundo datacenter. O processo de ativação envolve a configuração, pelo administrador, dos servidores sobreviventes de estado parcialmente operacional para cessar serviço. Assim, a ativação pode continuar no segundo datacenter. Isso é feito para impedir ambos os conjuntos de serviços de realizar testes e operar simultaneamente.

Em decorrência da perda do quorum, os membros do DAG no segundo datacenter não podem ficar online automaticamente. Por isso, a ativação dos servidores de caixa de correio no segundo datacenter também exige uma etapa na qual os servidores membros do DAG são forçados a criar quorum, quando os servidores no datacenter com falha são removidos internamente (mas apenas temporariamente) do DAG. Isso resulta em uma solução de serviço parcial estável e capaz de apresentar certo nível de falhas adicionais e, ainda assim, continuar funcionando.

Dica

Um pré-requisito da possibilidade de apresentar falhas adicionais é o DAG ter pelo menos quatro membros e os quatro membros estarem espalhados por dois sites do Active Directory (por exemplo, pelo menos dois membros em cada datacenter).

Esse é o processo básico usado para restabelecer a funcionalidade de função de Caixa de Correio no segundo datacenter. A ativação das outras funções no segundo datacenter não envolve ações explícitas nos servidores afetados no segundo datacenter. Em vez disso, os servidores no segundo datacenter se tornam os pontos de extremidade desses serviços normalmente hospedados pelo datacenter principal. Por exemplo, um usuário normalmente hospedado no datacenter principal pode usar https://mail.contoso.com/owa para se conectar ao Outlook Web App. Após a falha no datacenter, esses pontos de extremidade de serviço são movidos para pontos de extremidade no segundo datacenter como parte da operação de alternância. Durante a operação de alternância, os pontos de extremidade de serviço do datacenter principal são redirecionados em endereços IP alternativos para os mesmos serviços no segundo datacenter. Isso minimiza a quantidade de alterações que devem ser feitas nas informações de configuração armazenadas no Active Directory durante o processo de alternância. Em geral, há duas formas de concluir essa etapa:

• Atualizar registros de DNS; ou

• Reconfigurar DNS ou balanceadores de carga para habilitar e desabilitar endereços IP alternativos, o que move serviços entre data centers.

Uma estratégia de teste da solução deve ser estabelecida. Ela deve ser considerada no SLA. A validação periódica da implantação é a única forma de garantir que a implantação não seja degradada com o passar do tempo.

A conclusão cuidadosa dessas etapas de planejamento afetará diretamente o êxito da alternância de um datacenter. Por exemplo, um design de namespace ruim pode causar dificuldades com certificados, e uma configuração de certificado incorreta pode impedir usuários de acessar serviços.

Após a validação da implantação, recomendamos que todas as partes da configuração que afetam diretamente o êxito da alternância de um datacenter sejam documentadas explicitamente. Além disso, talvez seja prudente aperfeiçoar os processos de gerenciamento de alterações quanto a esses segmentos da implantação.

Para mais informações sobre alternâncias de datacenter, inclusive a ativação de um datacenter secundário e a reativação de um datacenter com falha (principal), consulte Switchovers do Datacenter.

Requisitos gerais

 © 2010 Microsoft Corporation. Todos os direitos reservados.