Implantações de Alta Disponibilidade

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

Tópico modificado em: 2008-01-17

Um dos principais temas de desenvolvimento para alta disponibilidade no Microsoft Exchange Server 2007 foi o desafio das práticas de alta disponibilidade e das opções de configuração que estavam presentes em versões anteriores do Exchange Server. Seguindo um processo de planejamento estruturado com o Exchange 2007, você pode diminuir seus custos de implantação e operação, ao mesmo tempo em que fornece mais serviços a seus usuários finais.

As soluções de alta disponibilidade no Exchange Server 2003 foram implantadas com sucesso na produção pelo Microsoft e muitos clientes para fornecer um ambiente de mensagens altamente disponível. Além disso, muitos clientes implantaram com sucesso a tecnologia de replicação de parceiro e criaram soluções de failover automático para um segunda cópia dos dados quando ocorre uma falha. O Exchange 2007 inclui aperfeiçoamentos para as soluções de alta disponibilidade encontradas no Exchange 2003 e novos recursos de alta disponibilidade que eliminam a necessidade de tecnologias de replicação de terceiros e reduzem os custos e a complexidade da solução geral. Algumas das principais razões por trás desses aperfeiçoamentos foram resultado direto do feedback dos clientes que informaram o seguinte:

• O requisito de armazenamento compartilhado para a solução aumentou os custos e a complexidade da solução. Por exemplo, o hardware da solução inteira precisou ser selecionado na categoria Solução de Cluster do Catálogo de Produtos Testados do Windows Server. No Exchange 2007, os clusters de cópia única (SCCs) mantêm esse requisito, mas os servidores de caixas de correio clusterizadas configurados em um ambiente de replicação contínua de cluster (CCR) não têm esse requisito.

• O uso de uma cópia única dos dados da caixa de correio significou que as falhas dessa cópia ou seu armazenamento estavam muito rompidas, resultando freqüentemente em interrupções demoradas e às vezes perda de dados.

• Uma falta de integração de instalação e gerenciamento entre o serviço de Cluster e o Exchange Server forçou o administrador do Exchange a entender conceitos e funcionalidades do cluster. Isso representou uma curva de aprendizado significativa para alguns administradores do Exchange.

• As configurações padrão não foram ajustadas para obter ótimos comportamentos de recuperação. Os administradores tiveram que reconfigurar manualmente os recursos de cluster padrão e as configurações de cluster para atender às recomendações de melhores práticas.

• Todos os serviços do Exchange (acesso de cliente, transporte e armazenamento) foram tratados usando a mesma estratégia de disponibilidade, mesmo que na arquitetura houvesse algumas diferenças drásticas entre eles, incluindo estratégias de alta disponibilidade diversas.

• Alguns clientes exigiram tecnologia do parceiro para alcançar a solução que mantinha duas cópias dos seus dados da caixa de correio. Essas soluções somaram-se aos custos e complexidade da implantação.

As soluções de alta disponibilidade no Exchange 2007 foram projetadas para dar conta de todas as deficiências na abordagem de alta disponibilidade do Exchange 2003. O Exchange 2007 volta-se para as deficiências por meio de alterações arquiteturais, suporte a novas configurações, alteração nos modelos de gerenciamento, e introduzindo novas abordagens para alta disponibilidade. O resultado é uma solução flexível que fornece a cada organização a liberdade para escolher uma solução que atenda às suas necessidades específicas.

Opções de Implantação de Alta Disponibilidade

A alta disponibilidade sempre deve ser projetada tanto no nível do componente individual quanto no contexto do sistema ou solução como um todo. Geralmente há dois tipos de opções de implantação de alta disponibilidade Exchange 2007:

• Implantações de data center único com redundância que podem recuperar automaticamente algumas falhas após uma pequena interrupção. No caso de uma falha do site, uma solução de data center única conta com os procedimentos de recuperação de desastre para voltar ao status operacional.

• Implantações de vários data centers com redundância que podem recuperar automaticamente a maioria das falhas individuais. Uma solução de vários data centers permite que a organização sobreviva a uma falha do data center sem reclassificar para procedimentos de recuperação de desastres. Falhas não recuperáveis, como uma falha total do site, exigem intervenção manual para recuperação.

Essas duas opções de implantação são abordadas em mais detalhes posteriormente neste tópico.

Configurações de Data Center Único

As configurações de data center único para as funções de servidor Unificação de Mensagens, Transporte de Hub, Acesso para Cliente e Transporte de Borda envolvem servidores igualmente configurados e redundantes. Para servidores de Caixa de Correio, há três configurações de alta disponibilidade que fornecem disponibilidade de dados e serviços em um único data center: SCC, CCR e replicação contínua local (LCR). A figura a seguir ilustra uma implantação geral para uma configuração redundante de data center único.

Configuração de data center único com redundância total

Na figura anterior, a configuração de redundância para a função de servidor Caixa de Correio é abstraída. Isso porque há várias opções disponíveis para uma organização, incluindo diversas configurações que usam SCC e CCR.

Clusters de Cópia Única

A configuração do cluster de armazenamento compartilhado no Exchange 2007 chama-se SCC (single copy cluster, cluster de cópia única). Um SCC usa o serviço de Cluster e armazenamento compartilhado para hospedar um servidor de caixas de correio clusterizadas. Um servidor de caixas de correio clusterizadas é um computador lógico que se move entre nós físicos ao longo de sua vida útil. Isso é possível pela capacidade de o serviço de Cluster criar e gerenciar a identidade de rede flutuante. A identidade de rede flutuante é usada como identidade de rede do servidor de caixas de correio clusterizadas. A Instalação do Exchange cria automaticamente essa identidade de rede usando o nome do host e o endereço IP fornecido pelo administrador. A identidade de rede flutuante move-se entre os nós no cluster com base na disponibilidade do nó e nas necessidades de manutenção. Esses mecanismos permitem que os usuários acessem seus dados da caixa de correio, se o armazenamento estiver disponível e pelo menos um dos nós, funcional. Para que a recuperação de falhas funcione, o Exchange e o serviço de Cluster trabalham juntos para que o servidor de caixas de correio clusterizadas fique online em um nó disponível após uma falha.

A seguir há vários aperfeiçoamentos importantes no Exchange 2007 sobre os clusters de armazenamento compartilhado presentes nas versões anteriores do Exchange Server:

• Somente a função do servidor de Caixas de Correio tem suporte a cluster, e é a única função que pode ser instalada em um cluster de failover.

• O comportamento de failover foi otimizado para só falhar quando houver uma alta probabilidade de que um failover melhore a disponibilidade. Somente uma falha completa do nó ou incapacidade do nó de se comunicar com clientes causa um failover.

• A maior parte da administração foi movida do Administrador do Cluster para ferramentas do Exchange, como o Shell de Gerenciamento do Exchange. Isso reduz a curva de aprendizado dos administradores de SCC.

• A instalação do servidor de caixas de correio clusterizadas foi integrada na Instalação, fornecendo a mesma experiência que uma instalação autônoma.

A figura a seguir ilustra uma configuração típica de SCC. Um SCC suporta até oito clusters de nó que que tenham pelo menos um nó passivo.

Figura 2 Arquitetura básica de um cluster de cópia única

Na figura anterior, os dois nós estão juntos em um cluster de failover. Um disco compartilhado é usado pelo cluster para gerenciar o recurso de quorum do cluster, que é representado pelo Quorum de disco. O nó ativo possui atualmente os recursos de disco que hospedam os arquivos de logs e banco de dados do servidor de caixas de correio clusterizadas. A propriedade é ilustrada pelas linhas azuis do nó ativo para os discos. Nessa configuração, os discos são acessíveis pelo nó ativo, mas não simultaneamente pelo nó passivo.

Os nós ativo e passivo estão conectados por pelo menos duas redes (privada e mista). Somente uma das duas redes é usada para comunicação do cliente (a rede mista). O serviço de Cluster verifica regularmente a integridade de comunicação das duas redes.

Para obter mais informações sobre SCC, consulte Clusters de cópia única.

Replicação Contínua em Cluster

Como o nome diz, um cluster de cópia única contém uma única cópia dos dados da caixa de correio. Falha na hospedagem do armazenamento dos dados da caixa de correio não resultam em recuperação automática. Na verdade, tal falha resultaria normalmente em interrupção estendida e perda de dados. As melhorias no SCC em relação às soluções de cluster anteriores atendem a muitos feedbacks fornecidos pelos clientes em soluções de alta disponibilidade anteriores. Entretanto, o SCC ainda tem a complexidade que acompanha o armazenamento compartilhado. Ele tem pelo menos dois pontos de falha: o disco de quórum único e a cópia única dos dados do Exchange. No Exchange 2007, há um segundo tipo de configuração de alta disponibilidade que fornece redundância completa sem exigir hardware da categoria de Soluções de Cluster do Catálogo de Produtos Testados do Windows Server. Essa solução chama-se CCR (replicação contínua em cluster).

A CCR usa o envio de logs assíncrono interno para replicar os dados da caixa de correio entre dois servidores em um cluster de failover. A integração de replicação e clusters produz uma solução que não tem um ponto único de falha e fornece recuperação automática de falhas do servidor. Além disso, elimina a necessidade de armazenamento compartilhado, reduzindo, portanto, os custos e a complexidade da implantação. A CCR só suporta clusters de dois nós e somente duas cópias dos dados (a cópia ativa e a passiva). A figura a seguir ilustra um ambiente de CCR típico.

Implantação básica da CCR

Duas alterações significativas ilustradas na figura anterior são a ausência de um disco de quórum compartilhado e a presença de um compartilhamento de arquivo em um terceiro computador fora do cluster. O compartilhamento de arquivo é parte dos novos recursos do quórum do cluster que foram introduzidos com a atualização descrita no Microsoft artigo 921181 da Base de Dados de Conhecimento,Uma atualização está disponível para adicionar um recurso de testemunha de compartilhamento de arquivos e um recurso configurável de pulsações de cluster aos clusters de servidor baseados no Windows Server 2003 Service Pack 1. A atualização permite que o serviço de Cluster use um recurso de quórum com um compartilhamento de arquivo em vez de um nó do eleitor no cluster. Sem a atualização, as únicas opções do quórum são usar um disco compartilhado ou uma configuração de nó tradicional, ambos com desvantagens e custos maiores:

• Usar um disco compartilhado introduz novamente a complexidade de armazenamento compartilhado na solução.

• Os quóruns de conjuntos de nós principais exigem três ou mais nós. Nessa configuração, um nó extra, conhecido como nó do eleitor, é necessário para funcionar como nó do eleitor no cluster.

Para obter mais informações sobre CCR, consulte Replicação Contínua em Cluster.

Replicação contínua local

A CCR fornece redundância completa de dados e serviços, e o SCC fornece redundância de serviço. Para as organizações que exigem redundância de dados sem redundância de serviço, há a LCR (local continuous replication, replicação contínua local). A LCR não é uma solução em cluster e, portanto, não fornece disponibilidade de serviço. A figura a seguir ilustra um ambiente de LCR típico.

Implantação básica de replicação contínua local

A LCR usa a tecnologia interna de replicação contínua descrita na seção de CCR anterior, para criar uma segunda cópia (referida como cópia passiva) de um grupo de armazenamento no computador local. O computador deve ser um servidor de Caixa de Correio autônomo (não em cluster). Em um ambiente de LCR, o administrador decide que grupos de armazenamento têm uma cópia passiva e configura uma segunda localização para a cópia passiva no mesmo servidor.

Ao usar LCR, o administrador deve decidir explicitamente que grupos de armazenamento têm cópias passivas. Os administradores podem decidir criar uma cópia passiva de um grupo de armazenamento existente ou habilitar a LCR para um novo grupo de armazenamento durante o processo de criação. O administrador deve configurar uma segunda localização para os arquivos de log e banco de dados dos grupos de armazenamento que são habilitados para LCR.

Na LCR, a ativação da segunda cópia é manual. Não há failover na LCR porque failover é uma operação de cluster, e a LCR não é uma solução em cluster. Em vez disso, o administrador deve decidir quando a cópia ativa não estará mais viável e ativar manualmente a cópia passiva, tornando-a a nova cópia ativa. O processo para ativar a cópia passiva é simples e rápido.

A qualquer momento, um administrador pode decidir habilitar a LCR e criar uma cópia passiva de um banco de dados existente, ou um administrador pode habilitar imediatamente a LCR ao criar um novo banco de dados. Após a habilitação da LCR, uma cópia de linha de base é criada usando um processo de propagação, e a replicação (envio de logs) é iniciada. Uma boa prática é localizar a cópia passiva em discos ou em um armazenamento isolado da cópia ativa. Essa prática minimiza a chance de várias falhas simultâneas. A LCR tem um impacto de recurso no servidor da Caixa de Correio. O servidor da Caixa de Correio está realizando todo o processamento associado à replicação contínua, e o planejamento de capacidade do servidor deve levar isso em conta. A carga de entrada/saída (E/S) na cópia ativa é limitada porque a maioria das atividades de E/S para a cópia passiva está associada aos arquivos de log e banco de dados da cópia passiva.

A LCR suporta backups da cópia passiva usando VSS (Volume Shadow Copy Service) com suporte a Exchange. Quando os volumes de disco que contêm a cópia ativa são separados apropriadamente da cópia passiva, os backups de VSS sem suporte VSS baseado em hardware são uma boa opção. Os backups da cópia passiva descarregam a E/S do backup dos volumes de disco da cópia ativa. Como a cópia passiva não exige uma resposta em tempo real para os clientes, ela pode acomodar os custos associados ao uso de um gravador de VSS baseado em software. Além disso, dependendo do seu planejamento de capacidade, pode ser prático estender a janela de backup no servidor com LCR. O fator principal é sustentar a carga de CPU do agente de backup por toda a janela de backup.

A cópia passiva representa a primeira linha de defesa contra corrupção e falha de dados. Com a LCR, a primeira recuperação de falha pode ter um SLA (service level agreement, acordo de nível de serviço) relativamente curto Uma falha dupla requer restauração do backup. Com esse modelo, um SLA de uma falha dupla pode ser muito maior. Assim, uma rotina de backups completos semanais e backups incrementais diários é uma estratégia viável e recomendada. Essa estratégia também reduz o conteúdo total movido para a mídia de backup.

Resumindo, a LCR é uma excelente opção para organizações que necessitem de recuperação rápida de falhas ou danos nos dados, mas podem permitir interrupções do servidor por motivos agendados ou não. A LCR fornece os seguintes benefícios:

• Recuperação rápida em duas etapas de danos ou falhas de um banco de dados ativo.

• Seletividade do administrador, o que protege os usuários que mais precisam disso.

• Disponibilidade em servidores de Caixa de Correio de qualquer tamanho e em todos os produtos.

• Impacto mínimo no banco de dados ativo e E/S de log.

• Capacidade de descarregar E/S de backup de bancos de dados ativo e volumes de log.

• Capacidade de reduzir o total de dados movidos para a mídia de backup, ao mesmo tempo em que estende a janela de backup.

• Abstração da administração no nível do Exchange por meio do uso do Console de Gerenciamento do Exchange ou do Shell de Gerenciamento do Exchange.

Para obter mais informações sobre LCR, consulte Replicação contínua local.