Planejamento de alta disponibilidade e de resiliência do site

Aplica-se a: Exchange Server 2013

Durante a fase de planejamento, os arquitetos de sistema, os administradores e os outros participantes principais devem identificar os requisitos de negócios e de arquitetura da implantação, em especial os requisitos de alta disponibilidade e de resiliência do site.

Há requisitos gerais que devem ser atendidos para implantar esses recursos e requisitos de hardware, software e rede que também devem ser atendidos.

Requisitos gerais

Antes de implantar um grupo de disponibilidade de banco de dados (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 2013 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 definidos nos tópicos dos pré-requisitos do Exchange 2013 e dos requisitos do sistema do Exchange 2013.

Requisitos de armazenamento

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. Há suporte para o armazenamento compartilhado gerenciado por cluster para uso em um DAG somente quando o DAG estiver configurado para usar uma solução que usa a API de Replicação de Terceiros incorporada ao Exchange 2013.

Requisitos de software

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

Cada membro do DAG também deve ter o mesmo sistema operacional em execução. O Exchange 2013 é suportado nos sistemas operacionais Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2. Todos os membros de um determinado DAG devem executar o mesmo sistema operacional. O Windows Server 2012 R2 só tem suporte para membros do DAG que executem o Service Pack 1 ou posterior do Exchange 2013.

Além de atender aos pré-requisitos de instalação do Exchange 2013, existem requisitos do sistema operacional que devem ser atendidos. Os DAGs usam a tecnologia de Cluster de Failover do Windows e, como resultado, eles exigem a versão Enterprise ou Datacenter do Windows Server 2008 R2 ou a versão Standard ou Datacenter dos sistemas operacionais Windows Server 2012 ou Windows Server 2012 R2.

Requisitos de rede

Existem requisitos de rede específicos que devem ser atendidos para cada DAG e cada membro do DAG. Cada DAG deve ter uma única rede MAPI, que é usada por um membro DAG para se comunicar com outros servidores (por exemplo, outros servidores ou servidores de diretório do Exchange 2013) e zero ou mais redes de replicação, que são redes dedicadas ao envio e à semente de log.

Em versões anteriores do Exchange, recomendamos pelo menos duas redes (uma rede MAPI e uma rede de replicação) para DAGs. No Exchange 2013, há suporte para várias redes, mas nossa recomendação depende da topologia da rede física. Se você tiver várias redes físicas entre membros da DAG que são fisicamente separadas umas das outras, o uso de uma rede MAPI e Replicação separada fornecerá mais redundância. Se você tiver várias redes que são parcialmente separadas fisicamente, mas convergem para uma única rede física (por exemplo, um único link WAN), é recomendável usar uma única rede (preferencialmente 10 gigabits Ethernet) para o tráfego MAPI e replicação. Essa abordagem fornece simplicidade para a rede e o caminho de rede.

Considere os seguintes fatores ao projetar a infraestrutura de rede para seu 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 que você use um mínimo de 1 gigabit Ethernet, mas preferencialmente 10 gigabit Ethernet. 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 DAG fornece uma rede MAPI e uma rede de replicação, com redundância da rede de replicação e os seguintes comportamentos de recuperação:

  • Se uma falha afetar a rede MAPI, ocorrerá um failover do servidor (supondo que haja cópias de banco de dados de caixa de correio saudáveis que podem ser ativadas).

  • Se uma falha afetar a rede replicação, se a rede MAPI não for afetada pela falha, as operações de envio e semeadura de log serão revertidas para usar a rede MAPI, mesmo que a rede MAPI tenha 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 suspender e retomar, para evitar a breve interrupção causada ao se 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.

• Mais redes de replicação 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 o teaming, essa tecnologia não impede que a rede em si seja um único ponto de falha. Além disso, a equipe acrescenta complexidade desnecessária ao DAG.

• 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 de sua localização geográfica em relação a outros membros da DAG, cada membro do DAG deve ter latência de rede de ida e volta não maior que 500 milissegundos entre si. À medida que a latência de ida e volta entre dois servidores da Caixa de Correio que hospedam cópias de um banco de dados aumenta, o potencial de replicação não estar atualizado também aumenta. Independentemente da latência da solução, os clientes devem validar que as redes entre todos os membros da DAG são capazes de satisfazer as metas de proteção de dados e disponibilidade da implantação. Configurações com valores de latência mais altos podem 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 de ida e volta podem não ser o requisito de largura de banda e latência de rede mais rigorosos para uma configuração de vários datacenteres. Avalie a carga total de rede, que inclui acesso ao cliente, Active Directory, transporte, replicação contínua e outro tráfego de aplicativos, para determinar os requisitos de rede necessários para seu ambiente.

• As redes do DAG dão suporte ao Protocolo TCP/IP versão 4 (IPv4) e IPv6. 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 2013 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 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 2013.

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 em execução no Windows Server 2008 R2 ou Windows Server 2012 exige um mínimo de um endereço IP na rede MAPI. Um DAG requer mais endereços IP quando a rede MAPI é estendida em várias sub-redes. DAGs em execução no Windows Server 2012 R2 criados com um ponto de acesso administrativo de cluster não exigem um endereço IP.

A figura a seguir ilustra um DAG em que todos os nós do DAG têm a rede MAPI na mesma sub-rede.

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

A figura a seguir ilustra um DAG que tem uma rede MAPI que se estende por duas sub-redes: 172.19.18.*x_ e 172.19.19.*x_.

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.

Cada vez que a rede MAPI do DAG é estendida em outra sub-rede, mais um endereço IP para essa sub-rede deve 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.

Observação

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 2013 para que esses recursos estejam disponíveis. Mesmo que o ponto de acesso administrativo do cluster subjacente (por exemplo, seu endereço IP e recursos de Nome de Rede) esteja offline, a comunicação interna ainda ocorrerá dentro do DAG usando os nomes do servidor membro 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 pontes 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ções
Cliente para redes Microsoft	Habilitado
Agendador de pacotes QoS	Opcionalmente habilitado
Compartilhamento de arquivos e impressoras para redes Microsoft	Habilitado
Protocolo TCP/IP versão 6 (TCP/IP v6)	Habilitado
Protocolo TCP/IP versão 4 (TCP/IP v4)	Habilitado
Driver de E/S do mapeador da descoberta de topologia da camada de link	Habilitado
Respondente da descoberta de topologia da camada de link	Habilitado

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ções
Cliente para redes Microsoft	Desabilitado
Agendador de pacotes QoS	Opcionalmente habilitado
Compartilhamento de arquivos e impressoras para redes Microsoft	Desabilitado
Protocolo TCP/IP versão 6 (TCP/IP v6)	Habilitado
Protocolo TCP/IP versão 4 (TCP/IP v4)	Habilitado
Driver de E/S do mapeador da descoberta de topologia da camada de link	Habilitado
Respondente da descoberta de topologia da camada de link	Habilitado

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 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 devem usar um servidor testemunha. O servidor testemunha pode ser qualquer computador com o Windows Server em execução. Não há nenhum requisito para 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á online e pode 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).

É fundamental que cada membro DAG tenha uma visã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 do cérebro dividido. A síndrome do cérebro dividido é uma condição que ocorre quando os membros do DAG não conseguem se comunicar entre si, embora estejam operantes. A síndrome cerebral dividida é evitada sempre exigindo que a maioria dos membros da DAG (e se os DAGs tiverem um número par de membros, o servidor testemunha DAG) esteja disponível e interagindo para que o DAG esteja operacional.

Planejar a resiliência do site

Diariamente, 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 os locais a serem usados 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 objetivo de tempo de recuperação e o objetivo de ponto de recuperação. Esses valores são medidos em minutos. O objetivo de tempo de recuperação é o tempo necessário para a restauração do serviço. O objetivo de ponto de recuperação 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 é a ativação do Data Center em espera SLA?
• 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 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. Geralmente, o design do certificado dependerá dos clientes em uso e dos requisitos de certificado por 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 prática recomendada, minimize o número de certificados que você usa para seus servidores Exchange e servidores de proxy reverso. 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 do 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 Outlook no Active Directory com o mesmo Nome Principal na Forma Padrão Microsoft (msstd). Por exemplo, se usar 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 certificado específicos que podem exigir o uso de mais certificados. O Exchange 2013 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 OCS para o Nome da Entidade de Certificação impediria que o Outlook Anywhere funcionasse corretamente, você precisaria usar um certificado extra e separado para o ambiente OCS.

Planejamento de rede

Além dos requisitos de rede específicos que devem ser atendidos para cada DAG e para cada servidor que é membro de um DAG, há alguns requisitos e recomendações específicos para 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 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:

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

• Os registros DNS voltados para o cliente devem ter um valor TTL (Time to Live) de 5 minutos: a quantidade de tempo de inatividade que os clientes experimentam depende não apenas da rapidez com que uma alternância pode ocorrer, mas também da rapidez com que a replicação DNS ocorre e da consulta dos clientes para obter informações atualizadas de DNS. Os registros DNS para todos os serviços cliente do Exchange, incluindo Outlook Web App, Exchange ActiveSync, serviços Web do Exchange, Outlook Anywhere, SMTP, POP3 e IMAP4 nos servidores DNS internos e externos devem ser definidos com um TTL de 5 minutos.

• Use rotas estáticas para configurar a conectividade entre redes de replicação: para fornecer conectividade de rede entre cada um dos adaptadores de rede de replicação, use rotas estáticas persistentes. Esse processo é uma configuração rápida e única executada em cada membro DAG ao usar 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 2013 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. Eis alguns exemplos:

• 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). Esses serviços incluem Active Directory, infraestrutura de rede (por exemplo, DNS ou TCP/IP), serviços de telefonia (se o Unified Messaging estiver em uso) e infraestrutura de site (como energia ou resfriamento).

• 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 políticas 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 destinos SMTP diferentes em servidores de transporte diferentes, a configuração apropriada deve ser definida no segundo datacenter para habilitar pelo menos um (se não todos os três) servidores 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. Esse requisito pode significar garantir que as configurações de balanceamento de carga estejam em vigor, que o DNS global esteja configurado e que a conexão com a 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 SLA 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.