Microsoft Exchange Server 2010: Estratégias de alta disponibilidade
As estratégias que a Microsoft oferece para a criação de caixas de correio Microsoft Exchange altamente disponíveis têm evoluído ao longo dos anos.
Extraído de "Exchange 2010 – uma prática abordagem," publicado pela Red Gate Books (2009).
Jaap Wesselius
Desde o Exchange Server 5.5, Microsoft ofereceu Clustering do Windows como uma opção para a criação de um ambiente altamente disponível de caixa de correio Exchange. Existem dois nós de servidor em um ambiente típico de armazenamento compartilhado de cluster. Ambos estão executando o Exchange Server, e ambos os servidores estão conectados a uma solução de armazenamento compartilhado.
Nos primeiros dias, este armazenamento compartilhado foi construído em um barramento SCSI compartilhado. Mais tarde ele normalmente usado redes de armazenamento (SANs) com uma conexão de rede Fibre Channel ou iSCSI. A parte importante foi o armazenamento compartilhado onde se localizavam os bancos de dados do Exchange Server.
Apenas um servidor nó é o "dono" de dados compartilhados. Este nó fornece os serviços de cliente. É também conhecido como o nó ativo. Outro nó não é capaz de acessar esses dados e é, portanto, o nó passivo. Uma rede privada entre nós dois servidor é usada para comunicações dentro do cluster, como um sinal de batimento cardíaco. Isso permite que ambos os nós determinar o estado do cluster e certifique-se de que outros nós ainda estão vivos.
Além de dois nós, ele cria um "Exchange Virtual Server" como um recurso de cluster. Isso não tem nada a ver com máquinas virtuais. Este é o recurso ao qual os clientes do Outlook se conectar para acessar suas caixas de correio. Quando o nó ativo falhar, o nó passivo tem sobre o servidor Virtual do Exchange, que, em seguida, continua a ser executado. Embora os usuários notarão um curto tempo de inatividade durante o failover, é uma experiência de outra maneira sem emenda. Nenhuma ação é necessária do usuário.
Embora essa solução oferece redundância, ainda há um ponto único de falha — o banco de dados compartilhado do Exchange server. Em um ambiente típico, este banco de dados é armazenado em uma SAN. Pela sua própria natureza, uma SAN é um ambiente altamente disponível. Quando algo acontecer ao banco de dados, embora, como uma falha de lógica, o banco de dados está disponível para ambos os nós. Isso resulta em total indisponibilidade.
Replicação de banco de dados do Exchange
Com o Exchange Server 2007, a Microsoft ofereceu uma nova solução para a criação de ambientes de alta disponibilidade do Exchange: replicação de banco de dados. Replicação de banco de dados cria uma cópia de um banco de dados, resultando em redundância de banco de dados. Essa tecnologia estava disponível em três sabores:
- **Replicação contínua local (LCR):**Essa abordagem cria uma cópia do banco de dados no mesmo servidor.
- **Replicação contínua em cluster (CCR):**Isso cria uma cópia do banco de dados em outro nó em um cluster de failover do Windows (só pode haver dois nós em um cluster CCR).
- **Em espera (SCR) replicação contínua:**Isso veio com o Exchange Server 2007 SP1. Ele cria uma cópia de um banco de dados em qualquer outro servidor Exchange (não necessariamente em cluster). Isso não é destinado para alta disponibilidade (HA); é mais para recuperação de desastres.
É assim que funciona em um ambiente de cluster CCR replicação de banco de dados. Exchange Server 2007 é instalado em um Windows Server 2003 ou Windows Server 2008 failover cluster. Não há nenhum armazenamento compartilhado em uso dentro do cluster. Cada nó tem seu próprio armazenamento. Isso pode ser em uma SAN (iSCSI ou Fibre Channel) ou armazenamento de conexão direta (DAS) — discos físicos locais.
O nó ativo em solicitações de cliente de serviços de cluster e o Exchange Server usa a tecnologia de banco de dados padrão com um banco de dados, arquivos de log e um arquivo de ponto de verificação. Quando terminar com um arquivo de log do Exchange Server, é imediatamente enviada para o nó passivo do cluster. Isto pode ser através de uma conexão de rede normal ou através de uma rede dedicada a replicação.
O nó passivo recebe o arquivo de log e ele verifica erros. Se ele não encontrar nenhum, os dados no arquivo de log são retransmitidos para a cópia passiva do banco de dados. Este é um processo assíncrono, ou seja, que a cópia passiva é sempre um par de arquivos de log por trás da cópia ativa, para que a informação está "falta" na cópia passiva.
Neste ambiente, todas as mensagens — até mesmo mensagens internas — são enviados por um servidor de transporte de Hub. O servidor de transporte de Hub mantém controle sobre essas mensagens em um ambiente CCR. Ele pode enviar, portanto, faltando informação (que na verdade solicita o nó passivo) para a cópia passiva do cluster no caso de um failover de cluster. Isto é chamado o "Dumpster de transporte" em um servidor de transporte de Hub.
Este tipo de replicação funciona muito bem. Replicação de CCR é bastante confiável, mas há um par de possíveis inconvenientes:
- Um ambiente de CCR do Exchange Server 2007 é executado no Windows Server 2003 ou Windows Server 2008 de clustering. Para muitos, isso adiciona muita complexidade para o ambiente.
- Windows Server 2003 cluster em um ambiente com várias sub-redes é quase impossível, embora isso melhorou (mas ainda não é perfeito) no cluster de failover do Windows Server 2008.
- Resiliência de site não é perfeita.
- Só é possível em um ambiente de dois nós de cluster de CCR.
- Todos os três tipos de replicação (LCR, CCR e SCR) são geridos de forma diferente.
Para superar esses problemas, Microsoft melhorou drasticamente a tecnologia de replicação. Ele também reduziu a sobrecarga administrativa. Este feito foi alcançado por esconder completamente os componentes de cluster por trás da implementação do Exchange Server 2010. Os componentes de cluster ainda estão lá, mas a administração é feita inteiramente com o Console de gerenciamento do Exchange (EMC) ou o Shell de gerenciamento do Exchange (EMS).
Replicação contínua de DAG
No Exchange Server 2010, a Microsoft introduziu o conceito de um grupo de disponibilidade de banco de dados (DAG). Esta é uma unidade lógica de servidores de caixa de correio do Exchange Server 2010. Todos os servidores de caixa de correio de um DAG pode replicar bancos de dados para outro. Um único DAG pode conter 16 servidores de caixa de correio e até 16 cópias de um banco de dados.
A idéia de múltiplas cópias de banco de dados em uma organização do Exchange é chamada de mobilidade do Exchange. Há um banco de dados em vários servidores, cada instância do que é 100% idênticas e, portanto, tem o mesmo GUID.
Com um DAG no lugar, os clientes se conectam a um banco de dados ativo. Este é o banco de dados onde todos os dados foram armazenados inicialmente. Novas mensagens de SMTP, ou de fora ou dentro da organização, são armazenadas neste banco de dados primeiro.
Quando o Exchange Server terminou de processar informações no arquivo de log do banco de dados, ele Replica o arquivo para outros servidores. Você pode atribuir os servidores que recebem uma cópia do banco de dados. O arquivo de log é inspeccionado após o recebimento e se tudo estiver certo, a informação no arquivo de log é descartada para a cópia local do banco de dados.
No Exchange Server 2010, todos os clientes se conectam ao servidor de acesso de cliente, incluindo todos os clientes de Messaging Application Programming Interface, ou MAPI, como o Microsoft Outlook. Clientes Outlook suportados no Exchange Server 2010 incluem o Outlook 2003, Outlook 2007 e Outlook 2010.
Assim o cliente Outlook se conecta ao servidor de acesso de cliente, que, em seguida, se conecta a caixa de correio na cópia ativa do banco de dados. Infelizmente, isto só é verdade para bancos de dados de caixa de correio. Quando um cliente Outlook precisa acessar um banco de dados de pasta pública, o cliente ainda acessa o servidor de caixa de correio diretamente.
Quando a cópia ativa de um banco de dados ou o seu servidor falha, uma das cópias do banco de dados passivas se torna ativa. Você pode configurar a ordem de failover durante o processo de configuração de cópia de banco de dados. O servidor de acesso para cliente automaticamente avisos do failover e começa a usar o novo banco de dados ativo. Porque o cliente Outlook estiver conectado ao servidor de acesso para cliente e não diretamente para o banco de dados, um failover de banco de dados é completamente transparente. Mensagens tais como, "a conexão com o servidor foi perdida", e "a conexão com o servidor é restaurada," simplesmente não aparecem mais.
Ao criar um ambiente de servidor de alta disponibilidade de caixa de correio em um DAG, não há nenhuma necessidade de criar um cluster de failover com antecedência. Você pode adicionar servidores de caixa de correio adicional ao DAG na mosca. No entanto, para o DAG funcionar corretamente, você ainda está usando alguns componentes de cluster de failover. Estes são instalados durante a configuração do DAG. Você faz todos os DAG e banco de dados gerenciamento de cópia via EMC ou EMS. Você não tem que usar o Gerenciador de Cluster do Windows.
O DAG com cópias de banco de dados é a única tecnologia HA que Exchange Server 2010 usa. Tecnologias mais antigas como SCR, CCR e SCR não estão mais disponíveis. O cluster de cópia única tradicional com armazenamento compartilhado não é mais suportado, quer.
Configurar um DAG não é limitado a um servidor, mantendo apenas a função de servidor caixa de correio. É possível criar uma situação de dois servidores de transporte de Hub, acesso para cliente e funções de servidor caixa de correio em ambos os servidores e, em seguida, criar um DAG e configurar cópias de banco de dados.
No entanto, não é uma configuração de HA para os servidores de acesso para cliente ou de transporte de Hub a menos que você colocou os balanceadores de carga na frente deles. Você não pode usar o padrão de balanceamento de carga de rede do Windows em combinação com os componentes de cluster de failover. No entanto, esta é uma grande melhoria para pequenas implantações do Exchange Server 2010, onde HA ainda é necessário.
.jpg)
Jaap Wesselius é o fundador da DM consultores, uma empresa com um forte foco em soluções de mensagens e colaboração. Depois de trabalhar na Microsoft há oito anos, Wesselius decidiu cometer mais de seu tempo para a Comunidade de intercâmbio na Holanda, resultando em um prêmio de MVP em Exchange Server 2007. Ele também é um colaborador regular em Unified Communications usuário grupo holandês e um autor regular para Simple-Talk.
Saiba mais sobre "Exchange 2010 – uma prática abordagem" em red-gate.com/our-company/about/book-store.