Site Resilience Configurations
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Tópico modificado em: 2007-10-29
Nos últimos anos, mais empresas têm reconhecido que o sistema de mensagens é fundamental para o sucesso. Para muitas organizações, ele faz parte dos planos de continuidade da companhia, e a resiliência do site deve ser projetada na implantação do serviço de mensagens. Fundamentalmente, muitas soluções resilientes do site envolvem a implantação de hardware de backup em um segundo data center. Isso geralmente resulta nas 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 (acordo de nível de serviço) de ativação do data center em espera?
Como o serviço é movido novamente para o data center principal?
Os recursos são dedicados para a solução de resiliência do site?
Respondendo essas perguntas, você começa a dar forma à sua solução de mensagens de resiliência do site. Um requisito principal da recuperação de falha no site é criar uma solução que obtenha os dados de mensagens necessários para um data center de backup que hospede o serviço de mensagens.
Este tópico fornece detalhes sobre várias configurações resilientes do site para a versão RTM do Microsoft Exchange Server 2007 e o Exchange 2007 Service Pack 1 (SP1). Antes de começar a considerar soluções de resiliência do site, você deve se familiarizar com os seguintes termos:
Cluster estendido Também conhecido como cluster disperso geograficamente, é uma configuração de cluster na qual os nós do cluster estão presentes em mais de um data center.
Portabilidade do banco de dados Tarefa administrativa que permite que as caixas de correio sejam redirecionadas a um servidor diferente quando o banco de dados do host correspondente for movido.
Site do Active Directory estendido Site do serviço de diretório Active Directory que contém computadores de mais de um data center (por exemplo, um site do Active Directory que abrange vários locais físicos).
Associação do site do Active Directory Membro de um determinado site do Active Directory baseado no endereço IP principal do computador. Qualquer alteração no endereço IP ou no site do Active Directory que o contém modifica a associação do site do Active Directory do computador.
Data center de produção O data center que hospeda os servidores ativos de um serviço e sua infra-estrutura associada.
Data center de backup quente Um data center de backup que está pronto para assumir imediatamente o serviço e dar prosseguimento à entrega. Não é necessária nenhuma configuração especial para executar o serviço nesse local.
Data center de backup morno Um data center de backup que tem servidores disponíveis para assumir o serviço do data center de produção. A ativação do serviço nesse data center requer intervenção manual.
Data center de backup frio Um data center de backup que tem a capacidade - e possivelmente a infra-estrutura - para assumir o serviço. São necessários esforços significativos para colocar o serviço em operação nesse data center.
Dedicado Servidores que foram projetos apenas para oferecer suporte aos usuários do data center principal.
Não Dedicado Servidores que estão oferecendo suporte aos usuários do data center principal, bem como usuários em outros locais.
Termos como produção, morna e dedicada podem ser combinados para descrever uma implantação resiliente do site. Por exemplo, um data center de produção cujo backup é feito por um data center de backup dedicado e amplamente configurado seria denominado Produção:Morna (Dedicada).
Recursos que aceitam resiliência do site
Existem vários recursos do Exchange 2007 que podem ser usados como blocos de construção para uma solução de resiliência do site. São eles:
Clusters estendidos, que podem ser usados para replicar dados ou simplificar a ativação do data center de backup.
Portabilidade do banco de dados, que pode ser usada para ativar dados replicados.
Sites do Active Directory estendidos, que podem ser usados para dar suporte a clusters estendidos ou habilitar um data center de backup.
Alteração da associação do site do Active Directory de um computador, que pode ser feita como parte da ativação de um data center de backup.
Backups regulares de fita, juntamente com o armazenamento externo, que podem ser usados para recuperar dados de caixa de correio no data center de backup.
Além disso, produtos de terceiros oferecem replicação de dados, que podem ser usada para transferir dados para um data center de backup. Esses produtos podem ser utilizados em conjunto com servidores autônomos, clusters de recuperação ou um SCC (cluster de cópia única) estendido. Nessas configurações, os dados do cluster ou servidor principal são replicados para a configuração de um cluster ou servidor secundário em um segundo data center. Quando ocorre falha no site, o cluster ou servidor no segundo data center é ativado manualmente.
No Exchange 2007 SP1, foi adicionado um novo recurso chamado SCR (replicação contínua em espera), desenvolvido especificamente para cenários de resiliência do site. Como o próprio nome diz, a SCR foi projetada para cenários que usem ou habilitem o uso de servidores de recuperação em espera. A SCR amplia os recursos de replicação contínua existentes no Exchange 2007 RTM e habilita novos cenários de disponibilidade de dados para servidores de Caixa de Correio que executam o Exchange 2007 SP1. A SCR usa a mesma tecnologia de repetição e envio de logs usada pela LCR (replicação contínua local) e pela CCR (replicação contínua em cluster) para fornecer opções e configurações de implantação adicionadas.
A SCR permite uma separação entre alta disponibilidade (composta por disponibilidade de dados e serviços) e resiliência do site. Por exemplo, a SCR pode ser combinada com a CCR para replicar grupos de armazenamento localmente em um data center principal (usando a CCR para alta disponibilidade) e remotamente em um data center de backup ou secundário (usando a SCR para resiliência do site). O data center secundário pode conter um nó passivo em um cluster de failover que hospeda os destinos SCR. Esse tipo de cluster é chamado de cluster em espera, pois não contêm nenhum servidor de caixas de correio clusterizadas, mas pode ser configurado rapidamente com um servidor de caixas de correio clusterizadas substituto em um cenário de recuperação. Se o data center principal falhar ou for perdido, os destinos SCR hospedados nesse cluster em espera poderão ser rapidamente ativados.
Para obter mais informações sobre SCR, consulte Replicação Contínua Em Espera.
Soluções para atingir a resiliência do site
Uma organização pode considerar várias soluções de resiliência do site. O restante deste tópico fornece informações sobre as seguintes soluções de resiliência do site:
Produção:Fria (Dedicada)
Produção:Morna (Dedicada)
Produção:Morna (Não-dedicada) com dois sites do Active Directory
Produção:Produção (Não-dedicada) com um site do Active Directory
A solução descrita neste tópico presume a perda total da infra-estrutura de mensagens quando ocorrer falha no data center de produção. O data center de backup deve ter conectividade com a Internet e todos os serviços necessários para hospedar o Exchange. Além disso, os processos de ativação devem ser inseridos no script e testados regularmente.
Produção:Fria (Dedicada)
A solução mais básica de resiliência do site de mensagens é aquela em que a organização tem contratos firmados para hardware e instalações, mas não possui um data center de backup ativo. Todos os dados da caixa de correio têm seu backup feito regularmente e são movidos para fora do site. Os dados do Active Directory recebem tratamento semelhante. A ativação da solução de resiliência do site exige que o hardware seja adquirido e implantado. Para reduzir o tempo total de interrupção, a organização pode ter contratos de entrega rápida com fornecedores de hardware para peças importantes de hardware.
Uma variação dessa solução é estabelecer relacionamento com um fornecedor de recuperação de desastre que possa disponibilizar o hardware a partir de um pool mantido por ele. Esse tipo de relacionamento permite que os dados de backup sejam mantidos no local do fornecedor para reduzir o tempo de recuperação. O armazenamento dedicado no local do fornecedor pode ser os destinos de replicação da caixa de correio e de dados do Active Directory.
Para simplificar, é provável que as configurações implantadas acabem tendo uma aparência semelhante ao ambiente de produção ou, pelo menos, a parte dele. Durante um processo de recuperação como esse, é melhor trabalhar com o máximo de tecnologia e dependências familiares possível.
Produção:Morna (Dedicada)
No modelo de recuperação Produção:Morna (Dedicada), o data center de produção tem um data center de backup designado com equipamento dedicado. O equipamento dedicado é usado quando o data center de produção fica indisponível. Conforme mencionado anteriormente, o data center de produção não é ativado automaticamente. O administrador precisa disparar manualmente sua ativação. Quando disparada, a ativação reconfigura a infra-estrutura e o equipamento de backup dedicados para fornecer o serviço de mensagens. A figura a seguir ilustra uma configuração Produção:Morna (Dedicada).
Exemplo de uma implantação Produção:Morna (Dedicada)
.gif "Produção: Implantação a quente (dedicada)")
A figura anterior mostra o data center de produção (A) hospedando as funções de servidor Transporte de Borda, Transporte de Hub, Acesso para Cliente e Caixa de Correio. O data center de backup morno (B) tem servidores de backup dedicados para cada função e para o Active Directory. A figura ilustra o uso de redundância simples para todas as funções de servidor, exceto Caixa de Correio. A redundância de Caixa de Correio é resolvida por uma configuração de servidor em espera ou de cluster com uma solução de replicação adequada.
As possíveis soluções de redundância da caixa de correio são:
CCR (replicação contínua em cluster) em uma configuração de cluster estendido A CCR usa o envio de logs para criar e gerenciar uma segunda cópia dos dados da caixa de correio. Dessa forma, o cluster de dois nós da CCR tem um nó em cada data center. Nesta configuração, o serviço Cluster do Windows exige sub-redes estendidas entre os dois locais. O cluster estendido permite que o servidor de caixas de correio clusterizadas realize failover simplesmente registrando outra vez o endereço IP designado no nó do outro data center.
SCC (cluster de cópia única) com replicação de parceiro síncrona A replicação de parceiro permite que o sistema tenha duas cópias dos dados do servidor de Caixa de Correio. Assim como ocorre com a CCR, é necessária uma sub-rede estendida para que o failover do cluster seja bem-sucedido.
Cluster em espera com replicação de parceiro Os dados da caixa de correio são replicados para um segundo cluster no data center de backup, e o processo de recuperação de desastre do servidor é usado para restaurar o serviço. A replicação pode ser síncrona ou assíncrona. Nenhum cluster é necessário e não há requisito de sub-rede estendida.
Servidor em espera com replicação de parceiro Os dados da caixa de correio são replicados para um segundo servidor no data center de backup, e a portabilidade do banco de dados ou o processo de recuperação de desastre do servidor é usado para restaurar o serviço. A replicação pode ser síncrona ou assíncrona. Nenhum cluster é necessário e não há requisito de sub-rede estendida.
LCR (replicação contínua local) com segunda cópia hospedada no segundo data center Esta não é a solução preferida, mas pode ser suficiente para algumas organizações. Nesta configuração, o armazenamento baseado em Internet SCSI (iSCSI) é usado para armazenar a cópia passiva dos dados. As características de rede da conexão devem permitir que a cópia passiva permaneça razoavelmente consistente com a cópia ativa. Nesta configuração, a LCR não está disponível para ativação local rápida, pois é improvável que a largura de banda e a latência da rede aceitem o acesso para cliente.
A figura anterior ilustra o uso de uma das soluções em cluster. Isso ocorre porque o servidor de Caixa de Correio é mostrado no site do Active Directory do data center de produção. Em uma solução em cluster, as redes em cada nó do cluster devem estar na mesma sub-rede. Em uma solução sem cluster, uma sub-rede única não é exigida, embora seja recomendada. Você pode usar uma sub-rede diferente, se necessário.
Supondo-se que uma solução em cluster seja usada, o curso normal das operações será como o seguinte:
Todos os emails da Internet de entrada fluirão pelo servidor de Transporte de Borda no Data Center A.
Todos os emails destinados a servidores de Caixa de Correio no site do Active Directory Redmond-Prod serão processados pelos servidores de Transporte de Hub em Redmond-Prod.
Os servidores de caixas de correio clusterizadas no site do Active Directory Redmond-Prod serão hospedados em seus nós configurados no Data Center A ou no Data Center B. O nó A e o nó B fazem parte de Redmond-Prod e são atendidos pelos servidores de Transporte de Hub e de Acesso para Cliente de Redmond-Prod.
Como a CCR aceita dois nós, o segundo nó deve estar no Data Center B. Isso significa que uma falha de nó ativo do Data Center A força o servidor de caixas de correio clusterizadas a se mover para o Data Center B. Nesse caso, ele ainda será atendido pelos servidores de Transporte de Hub e de Acesso para Cliente no Data Center A.
Um SCC com três servidores e duas cópias dos dados pode ser configurado para que uma falha faça com que o servidor de caixas de correio clusterizadas permaneça no Data Center A, em vez de realizar fail over no Data Center B. No entanto, se a falha for baseada em armazenamento, continuará sendo necessário ativar o nó passivo no Data Center B.
Os requisitos de largura de banda da rede entre os dois data centers têm três fatores de acionamento:
Requisitos de latência do serviço Cluster O serviço Cluster não exige mais do que meio segundo de ida e volta entre os nós do cluster.
Requisitos de largura de banda para replicação A CCR exige menos largura de banda do que a maioria das soluções de replicação de terceiros, pois se baseia no envio de logs, e não na cópia do banco de dados. A largura de banda necessária para uma solução de CCR depende de uma série de fatores que normalmente são exclusivos para cada ambiente. Os requisitos incluem largura de banda para:
Envio de logs
Notificações do sistema de arquivos, que é como o serviço Replicação do Microsoft Exchange sabe quando há um novo arquivo de log pronto para envio
Tráfego do servidor de diretório
Tráfego de cliente, se os clientes não estiverem localizados no mesmo local físico que o servidor de caixas de correio clusterizadas
Tráfego de pulsação de cluster
Atualizações de banco de dados do cluster
Qualquer outro aplicativo que usa a rede
Os servidores de Transporte de Hub e de Acesso para Cliente requerem comunicação da LAN entre si mesmos e os servidores de Caixa de Correio por eles atendidos Para servidores de Acesso para Cliente, esse requisito é mais importante porque ele atende usuários online. O acesso à caixa de correio para controladores de domínio pode fluir por uma conexão WAN (rede de longa distância), e sua latência afeta o acesso de MAPI online.
Os requisitos de latência e de largura de banda podem ser reduzidos quando uma solução sem cluster é implantada. Os requisitos de rede para replicação permanecem e são significativos. No entanto, a maioria dos outros requisitos não está presente, a menos que você preveja a ativação do servidor de Caixa de Correio de backup sem a falha completa do Data Center A.
Quando o data center de produção falhar, o administrador poderá restaurar o fluxo e os serviços de mensagens da seguinte forma:
Movendo os servidores de Caixa de Correio no data center de backup para o site do Active Directory Redmond-DR.
Movendo os servidores de Transporte de Hub, de Acesso para Cliente e de diretório no data center de backup para o site do Active Directory Redmond-Prod.
A segunda opção é a estratégia recomendada porque minimiza o impacto em outras partes do ambiente. Por exemplo, servidores do Exchange em qualquer filial não precisam alterar o roteamento percebido para emails na fila. Eles simplesmente se conectarão quando os servidores corretos estiverem ativos e disponíveis.
A ativação do Data Center B segue estas etapas de alto nível:
A infra-estrutura da rede é colocada online.
A infra-estrutura do Active Directory é colocada online.
O servidor de Caixa de Correio restante é colocado online. Esta etapa pode envolver forçar o cluster a ficar online com o único servidor restante.
O site do Active Directory Redmond-Prod é atualizado com os endereços IP dos servidores de Transporte de Hub, de Acesso para Cliente e de diretório em Redmond-DR.
O registro MX referente aos domínios da organização é atualizado com o endereço IP do servidor de Transporte de Borda no Data Center B.
O servidor de Acesso para Cliente recém-movido é adicionado a uma configuração NLB (Balanceamento de Carga da Rede).
O serviço de mensagens do Data Center A é restaurado no Data Center B.
Quando o Data Center A estiver disponível, o Data Center B poderá ser desativado usando estas etapas de alto nível:
Os servidores individuais do Data Center A são colocados online. Eles participarão do fornecimento do serviço, a menos que os serviços do Exchange sejam interrompidos ou desabilitados manualmente. Na migração de retorno, permitirão que os servidores do data center A fiquem online.
Permita que os servidores de Transporte de Hub no Data Center B drenem suas filas e coloque-os offline.
Coloque os servidores de Acesso para Cliente no Data Center B fora da configuração NLB. Os clientes então se conectarão através dos servidores no Data Center A.
O registro MX referente aos domínios da organização é atualizado com o endereço IP do servidor de Transporte de Borda no Data Center A.
Execute quaisquer atualizações necessárias de infra-estrutura de rede.
Mova os servidores de caixas de correio clusterizadas para o Data Center A.
Atualize o Redmond-DR do site do Active Directory com os endereços IP dos servidores que foram movidos durante a ativação.
O serviço de mensagens do data center A é restaurado.
Assim como ocorre em qualquer solução de falha no site, a ativação do data center de produção e de backup deve ser inserida no script e testada regularmente. O uso de uma solução em cluster para o servidor de Caixa de Correio reduz o tempo de ativação do data center de backup. É possível que outras soluções tenham alguma replicação do Active Directory e do DNS (sistema de nome de domínio) necessária que possa afetar quando o fluxo de mensagens será retomado e os clientes poderão acessar suas caixas de correio.
A solução Produção:Morna (Dedicada) tem a vantagem de que os computadores dedicados fornecem um nível de serviço previsível.
Produção:Morna (Não-dedicada) com dois sites do Active Directory
Na configuração Produção:Morna (Dedicada), os servidores de Transporte de Borda, Transporte de Hub e Acesso para Cliente no data center de backup são recursos em espera dedicados do Data Center A. Esta configuração representa um investimento significativo em hardware que não está sendo totalmente utilizado. Um modelo alternativo está representado nesta figura:
Exemplo de uma implantação Produção:Morna (Não-dedicada)
.gif "Exemplo de Produção: Implantação a quente (não dedicada)")
Produção:Morna (Não-dedicada) exige que o administrador dispare manualmente a ativação do data center de backup. Quando disparado, o processo de ativação reconfigura alguns equipamentos e a infra-estrutura no data center de backup para assumir o serviço de mensagens para os usuários do Data Center A.
Assim como ocorre com a solução Produção:Morna (Dedicada), existem dois sites do Active Directory na solução Produção:Morna (Não-dedicada). Porém, ao contrário da solução Produção:Morna (Dedicada), os dois sites do Active Directory abrangem outro data center. Os recursos dedicados no data center de backup se tornaram servidores redundantes para uma configuração de produção diferente no data center de backup. Essa abordagem disponibiliza esses recursos para uso normal, criando assim dois data centers de produção que, na realidade, são backup um do outro.
Por exemplo, como mostra a figura Exemplo de implantação Produção:Morna (Não-dedicada), quando o Data Center A falha, o servidor de Transporte de Hub 4, o servidor de Acesso para Cliente 4 e o servidor de Catálogo Global 4 são adicionados ao site do Active Directory Redmond e, em conjunto com o Nó B de Redmond, atendem aos usuários do Data Center A para fornecer o serviço de mensagens. Após a falha no site, os dois ambientes de produção são executados com capacidade e redundância reduzidas, em comparação com o estado normal do site. Supondo que haja suporte para carga em andamento, essa configuração é aceitável. Por exemplo, o email da Internet é transmitido pelo servidor de Transporte de Borda no Data Center B. Para dar suporte a uma interrupção estendida do data center, a empresa pode ter contratos com fornecedores que enviem rapidamente hardware adicional quando solicitado. O hardware adicional poderá ser usado para restaurar a redundância ou adicionar mais capacidade.
A operação normal das implantações do site do Active Directory de Redmond e Dublin será a mesma para esta solução e para a solução Produção:Morna (Dedicada). Da mesma forma, a largura de banda da rede entre os dois locais terá os mesmos fatores de controle, exceto pelo fato de que os servidores Redmond e Dublin precisam ter suporte simultâneo.
A ativação do data center de backup é feita:
Movendo-se o nó ativo e o servidor de caixas de correio clusterizadas para o site do Active Directory do data center operacional.
Movendo-se os servidores de Transporte de Hub, de Acesso para Cliente e de diretório no data center de backup para o site do Active Directory do data center com falha.
A solução de ativação recomendada é mover os servidores de Transporte de Hub e de Acesso para Cliente para o site do Active Directory do data center com falha. Essa solução resulta em uma ativação mais simples e menos desordenada.
Nessa solução, a recuperação do Data Center A é realizada pela seguintes etapas de alto nível:
A infra-estrutura da rede é colocada online. É possível que não seja necessária nenhuma alteração na infra-estrutura da rede, pois o email da Internet já está sendo recebido pelo Data Center B.
The A infra-estrutura do Active Directory para o Data Center A é colocada online (site do Active Directory Redmond).
O servidor de Caixa de Correio restante é colocado online. Esta etapa pode envolver forçar o cluster a ficar online com o único servidor restante.
O site do Active Directory Redmond é atualizado com os endereços IP do servidor de Transporte de Hub 4, do servidor de Acesso para Cliente 4 e do servidor de Catálogo Global 4.
O servidor de Acesso para Cliente 3 é adicionado à configuração NLB de Redmond.
O serviço de mensagens do data center A é restaurado.
Quando o Data Center A estiver disponível, o Data Center B poderá ser restaurado para sua configuração normal usando estas etapas de alto nível:
Os servidores individuais do data center A são colocados online. Eles participarão do fornecimento do serviço, a menos que os serviços do Exchange sejam interrompidos ou desabilitados manualmente. Na migração de retorno, permitirão que os servidores do data center A fiquem online.
Permita que o servidor de Transporte de Hub 4 drene suas filas e coloque-o offline.
Coloque o servidor de Acesso para Cliente 4 fora da configuração NLB. Os clientes continuarão podendo se conectar aos servidores no Data Center A.
Execute quaisquer atualizações necessárias de infra-estrutura de rede.
Mova o servidor de caixas de correio clusterizadas para o Data Center A.
Atualize o Dublin do site do Active Directory com os endereços IP dos servidores que foram movidos durante a ativação.
Os dois data centers são restaurados para suas condições originais.
Assim como ocorre em qualquer solução de falha no site, a ativação do data center de produção e de backup deve ser inserida no script e testada regularmente. O uso de uma solução de cluster para o servidor de Caixa de Correio reduz o tempo de ativação do data center de backup. É possível que outras soluções tenham alguma replicação do Active Directory e do DNS necessária que possa afetar quando o fluxo de mensagens será retomado e os clientes poderão acessar suas caixas de correio.
Esta solução permite que os servidores usados para resiliência do site sejam aplicados em operação normal. Isso pode reduzir o custo da solução de resiliência do site, mas talvez não consiga manter a carga completa do sistema quando necessário. Por exemplo, se a carga nos servidores de Transporte de Hub no Data Center B for aumentada para 80 % da capacidade, a ativação do Data Center de backup para A excederá a capacidade do Transporte de Hub. Com essa solução, os administradores devem controlar atentamente a utilização do sistema para garantir que a solução permaneça viável. Se a carga aumentar, será necessário adquirir e implantar novo hardware.
Produção:Produção (Não-dedicada) com um site do Active Directory
Organizações que precisem de uma solução capaz de dar suporte à ativação automática de um site de backup devem implantar uma solução Produção:Produção (Não-dedicada). Esta solução implanta servidores redundantes em um único site do Active Directory que abrange os dois data centers, conforme ilustrado na figura a seguir.
Exemplo de uma implantação Produção:Produção (Não-dedicada)
.gif "Produção: Implantação (não dedicada) de produção")
Esta solução implanta os recursos dos dois data centers em um único site do Active Directory. Qualquer recurso no site pode ser usado para atender praticamente qualquer solicitação. Por exemplo, um servidor de Transporte de Borda no Data Center A pode usar um servidor de Transporte de Hub no Data Center B para entregar uma mensagem a um usuário cuja caixa de correio esteja em um servidor de caixas de correio clusterizadas hospedado no Data Center A. Da mesma forma, por padrão, não há nenhuma localidade ou referência para o tráfego do Active Directory. Por esses motivos, essa solução não é recomendada.
A ativação do data center de backup é semelhante à recuperação de várias falhas no servidor. A recuperação da ativação exige simplesmente a restauração do serviço nos servidores com falha. Assim como ocorre com as soluções não-dedicadas discutidas anteriormente, o resultado do gerenciamento de capacidade insatisfatória pode ser a carga ultrapassar a capacidade do servidor após uma falha no data center. Os administradores devem verificar se a solução pode aceitar a carga esperada após uma falha no data center. Qualquer falha no gerenciamento da capacidade adequada pode resultar em falha total do serviço de mensagens após uma falha no data center único.