Exchange Server 2010

Artigo
08/19/2016

Garantindo a alta disponibilidade no Microsoft Exchange Server 2010

William R. Stanek

Recursos de alta disponibilidade no Exchange Server 2010
Compreendendo a grupos de disponibilidade do banco de dados

Bancos de dados e os dados que eles contêm são fundamentais para qualquer organização do Exchange. Para garantir a alta disponibilidade para bancos de dados de caixa de correio, o Exchange 2007 fornecido uma variedade de replicação e agrupamento opções, incluindo a replicação contínua local, clusters de cópia única e servidores caixa de correio agrupados. Embora esses recursos representado aperfeiçoamentos sobre ofertas anteriores, eles ainda pairam muitos desafios de implementação. Para iniciantes, cada abordagem para alta disponibilidade foi gerenciada de maneira diferente. Com clusters de cópia única, Mailbox todos os servidores em um cluster usado armazenamento compartilhado. Implementar clustering significava que os administradores do Exchange tinham que configurar o Windows clustering de failover, que é bastante complexo e pode exigir uma grande quantidade de tempo do administrador para obter um alto nível de tempo de atividade. Com a replicação contínua Exchange 2007 usado internos de replicação assíncrono para criar cópias dos dados e mantido cópias usando transação log repetição e envio. Embora usado replicação contínua local para criar cópias locais em um ambiente que não estão em cluster, usado replicação contínua em cluster ou replicação contínua em espera em um ambiente agrupado e cada tipo de replicação contínua foi gerenciado de forma diferente.

Exchange Server 2010 tem uma abordagem radicalmente diferente para alta disponibilidade porque alta disponibilidade é integrada a sua arquitetura de núcleo, criando uma solução de ponta a ponta que fornece serviço disponibilidade, disponibilidade de dados e recuperação automática. O resultado é que, uma chave, solução de alta disponibilidade substitui muitas, diferentes soluções usadas anteriormente. Esta solução é o grupo de disponibilidade do banco de dados (DAG).

DAGs fornecem o failover automático e recuperação no nível do banco de dados (em vez de nível do servidor) sem exigir clusters quando implantar vários servidores Mailbox com várias cópias de bancos de dados de caixas de correio. Devido a essas alterações, criando uma solução de servidor de Mailbox alta disponibilidade não requer hardware de cluster ou configuração avançada de cluster. Em vez disso, DAGs fornecer componente base para alta disponibilidade e failover é automático para bancos de dados de caixa de correio que fazem parte do mesmo DAG. DAGs podem ser estendidos para vários sites do Active Directory e alterações de arquitetura relacionadas a servidores Mailbox ativar um banco de dados de uma única caixa de correio mover entre sites do Active Directory. Como resultado, um banco de dados única caixa de correio em um site do Active Directory pode failover para outro site do Active Directory.

Você precisa se lembrar que são cópias do banco de dados para bancos de dados de caixa de correio somente. Para redundância e alta disponibilidade dos bancos de dados de pasta pública, você usará a replicação de pasta pública. Diferentemente de replicação contínua em cluster, no quais várias cópias de uma pasta pública banco de dados não pode existir no mesmo cluster, você pode duplicar bancos de dados de pasta pública entre servidores em um DAG.

Antes de me aprofundar os detalhes de DAGs, let’s examinar outras maneiras de alta disponibilidade opções foram alteradas para Exchange 2010.

Tour rápido de alta disponibilidade de recursos no Exchange Server 2010

Em versões anteriores, o Exchange operado como um aplicativo de cluster usado o modelo de gerenciamento de recursos de cluster. Nesta abordagem, implementado alta disponibilidade para servidores Mailbox primeiro criando um cluster de failover do Windows e executando a instalação do Exchange no modo de cluster. Como parte do processo de instalação, o recurso de cluster do Exchange (exres.dll) DLL foi registrado, permitindo a criação de um servidor de caixas de correio em cluster. Em contraste, Exchange 2010 não operar como um aplicativo em cluster e o modelo de gerenciamento de recursos de cluster não é mais usado para alta disponibilidade. DLL de recurso de cluster do Exchange e todos os recursos de cluster que ele fornecido não mais existem. Em vez disso, o Exchange 2010 usa seu próprio modelo interno de alta disponibilidade. Embora alguns componentes do Windows clustering de failover ainda são usadas neste modelo, eles são gerenciados agora exclusivamente pelo Exchange 2010.

Interessante, muitas das tecnologias de replicação do subjacente permanecem — eles simplesmente tiver evoluiu e agora funcionam de maneiras significativamente diferentes. Como grupos de armazenamento foram removidos do Exchange 2010, replicação contínua é executada no nível do banco de dados. Em vez de usar SMB (Server Message Block) para o log de remessa e propagação 2010 Exchange usa uma única porta TCP definida pelo administrador para transferência de dados. Em vez de ter cópias passivas puxar um arquivo de log fechado da cópia ativa, a cópia ativa envia arquivos de log para cópias passivas e o fluxo de dados é protegido usando criptografia ou compactado para reduzir o tamanho de dados replicados. Embora a cópia ativa do banco de dados em versões anteriores do Exchange pode ser usada somente para propagação e reseeding, no Exchange Server 2010 ativas e passivos cópias de bancos de dados de caixas de correio podem ser especificadas como fontes para propagação e reseeding, permitindo que você mais adicionar facilmente uma cópia de um banco de dados para outro servidor.

Outra alteração significativa tem que fazer com a maneira como os dados replicados. No Exchange 2007, o Microsoft Exchange replicação serviço repetidos logs em cópias do banco de dados passivo e criado um cache de operações de leitura/gravação que foi usado para reduzir a operações de E/s de leitura. Quando a cópia passiva do banco de dados foi ativada, os cache do banco de dados foi perdido, entretanto, porque o serviço Microsoft Exchange Information Store montado o banco de dados não tinha esse cache disponível. Isso significava que a cópia passiva foi ativada e disponibilizada em um estado frio sem um cache pronto. Um estado frio é o mesmo estado em que o cache do banco de dados teria sido na seguinte uma reinicialização do servidor ou uma reinicialização dos serviços executando o armazenamento em cache. Sendo em um estado frio significava que o servidor não tem operações de leitura/gravação em cache, uma condição que normalmente aumentou o número de operações de E/s de leitura necessária até que o tamanho do cache suficientemente aumentado para reduzir a E/s de disco no servidor. No Exchange 2010, o serviço Microsoft Exchange Information Store repete logs e manipula as operações de montagem, garantindo que o cache está disponível quando a cópia passiva é ativada e disponibilizada. Como resultado, o servidor é mais provável poder usar o cache para reduzir as operações de E/s de leitura após um failover ou alternância.

Com servidores Mailbox altamente disponíveis, mensagens de email são seguras assim que chegarem em uma caixa de correio; proteger mensagens de email em trânsito é outra questão, entretanto. Se um servidor de transporte de Hub falha durante o processamento de mensagens e não pode ser recuperado, mensagens podem ser perdidas. Como proteção contra perda de dados, o Exchange 2007 introduziu o transporte dumpster recurso, garantiu servidores Transporte de Hub mantido uma fila de mensagens entregues recentemente para destinatários cujas caixas de correio foram protegidas por replicação contínua local ou replicação contínua em cluster. Mensagens foram mantidas no transporte dumpster até um limite de tempo definido pelo administrador ou o tamanho limite foi atingido. No caso de um failover, um servidor de caixas de correio em cluster automaticamente solicitado cada servidor de transporte de Hub no site do Active Directory reenviar email do transporte dumpster fila. Essa abordagem impediu que o email perdido durante o tempo necessário para o cluster de failover. Embora essa abordagem funciona, está disponível somente para entrega de mensagem em um ambiente de replicação contínua e não endereço potencial perda de mensagem quando mensagens estão em trânsito entre servidores de transporte de Hub e transporte de borda.

Exchange 2010 endereços essas limitações de várias maneiras. O transporte dumpster agora recebe feedback para determinar quais mensagens foram entregues e replicadas. Servidores de transporte de Hub mantém uma cópia das mensagens enviadas a um banco de dados replicados de caixa de correio em um DAG. A cópia é mantida na fila de transporte (mail.que) até que o servidor Transporte de Hub foi notificado logs de transação que representa a mensagem foram replicados para e inspecionados por todas as cópias do banco de dados de caixa de correio com êxito. Em seguida, os logs são truncados do transporte dumpster, garantindo que o transporte dumpster fila é usada somente para manter cópias de mensagens ainda não tiver sido replicados cujos logs de transação. Além disso, quando um banco de dados de caixa de correio em um Active Directory site failsover para outro site do Active Directory, transporte dumpster redelivery solicitações são enviadas para o site original e o novo site.

Para fornecer redundância para mensagens durante o tempo todo estiverem em trânsito, Exchange 2010 adiciona o recurso de redundância de sombra. Sombra redundância usa uma abordagem semelhante para o transporte dumpster, exceto a exclusão de mensagens de bancos de dados de transporte está atrasada até que o servidor de transporte verifica todos os saltos de próximo mensagem concluiu entrega. Se o servidor de transporte de não entrega de próximo salto, a mensagem é reenviada para entrega para o próximo salto. Esta abordagem usa menos largura de banda do que criando cópias duplicadas de mensagens em vários servidores. Aqui, o tráfego de rede adicionais somente gerado é a troca de mensagens de status de descarte entre servidores de transporte. Descartar mensagens de status são geradas pelo Gerenciador de redundância de sombra e indicam quando uma mensagem de email está pronta para ser descartadas do banco de dados de transporte.

Sombra redundância é uma extensão do serviço SMTP (Simple Mail Transfer Protocol) e é usada como ambos os servidores em uma conexão SMTP oferece suporte ao recurso. Quando você tiver caminhos redundantes mensagem em sua topologia de roteamento, o sombra redundância faz qualquer servidor de transporte descartável, eliminando a confiança no estado de qualquer servidor de Hub ou Transporte de borda específico. Nesse caso, se um servidor de transporte falha ou se você deseja levá-lo offline para manutenção, você pode fazer isso a qualquer momento, removendo, substituir ou atualizar sem ter que esvaziar suas filas ou se preocupar que mensagens serão perdidas.

O Gerenciador de redundância sombra usa uma abordagem de pulsação em determinar a disponibilidade de servidores para o qual a sombra mensagens são enfileiradas. Iniciando servidor emite uma mensagem XQUERYDISCARD e em resposta, o servidor de destino retorna descartar notificações. Essa troca de notificação é a pulsação.

Se um servidor não pode estabelecer uma conexão com um servidor primário dentro do intervalo de tempo limite de pulsação, que é 300 segundos por padrão, o servidor redefine o timer e tentativas novamente, até três vezes (o valor padrão da contagem de repetição pulsação). Se um servidor primário falhar responder pelo tempo que atingiu a contagem de repetição, o servidor determina que o servidor primário falhou, assume a propriedade das mensagens de sombra e reenvia-los. Em seguida, as mensagens são entregues para seus destinos conforme apropriado. Em alguns cenários, como quando o servidor original vem online com seu banco de dados original, duplicada entrega de mensagens pode resultar. Devido a recursos de detecção de mensagem duplicada no Exchange, os usuários de caixa de correio do Exchange não ver mensagens duplicadas. No entanto, os destinatários não-Exchange Mailbox servidores podem receber cópias duplicadas.

Compreendendo DAGs

Embora muitos aprimoramentos de alta disponibilidade que já descrito até agora são importantes, nenhum recurso único tem tanta impacto sobre a maneira de que gerenciar o Exchange 2010 como grupos de disponibilidade do banco de dados. DAGs são o componente básico de alta disponibilidade no Exchange 2010. As regras para DAGs são simples. Cada DAG pode ter até 16 Mailbox servidores como membros. Cada servidor pode ser um membro de apenas um DAG e pode hospedar somente uma cópia de um banco de dados. Hospedado cópia pode ser uma cópia ativa ou cópia passiva. Uma cópia ativa difere de uma cópia passiva, está em uso e sendo acessados por usuários em vez de off-line. Não é possível criar duas cópias do mesmo banco de dados no mesmo servidor. Após isso, qualquer servidor um DAG podem hospedar uma cópia de qualquer banco de dados de caixa de correio de qualquer outro servidor o DAG. Embora vários bancos de dados podem estar ativos simultaneamente, apenas uma cópia de determinado banco de dados pode estar ativa em qualquer momento e até 15 cópias passivas deste banco de dados pode ser em outros servidores em um DAG.

Quando você criar seu primeiro DAG em uma organização do Exchange, Exchange cria um cluster de failover do Windows, mas há nenhum grupos de cluster para o Exchange e não há recursos de armazenamento do cluster. O DAG usa somente a pulsação do cluster, redes de cluster e os recursos de banco de dados de cluster de clusters de failover do Windows. A pulsação do cluster é usada para detectar falhas. Cada DAG requer pelo menos uma rede para tráfego de replicação e pelo menos uma rede para MAPI e outro tráfego. O banco de dados de cluster armazena as alterações de estado do banco de dados e outras informações importantes. Como adicionar outros servidores para o DAG, os servidores associados ao cluster subjacente e modelo de quorum do cluster é automaticamente modificado conforme necessário com base no número de servidores membro.

Gerenciador Active é o componente Exchange 2010 que fornece o recurso recursos de gerenciamento de modelo e failover. Gerenciador Active é executado em todos os servidores de caixas de correio que são membros de um DAG operando como o detentor da função principal (o primário Active Manager) ou um detentor de função em espera secundário (o Gerenciador de Active Standby) de um determinado banco de dados. O principal decide qual banco de dados copia estará ativa e que copia para ativar. O principal recebe notificações de alteração de topologia e reage a falhas do servidor. O principal também possui o recurso de quorum do cluster. Se o servidor que atua como o principal falhar, a função principal move automaticamente para outro servidor o DAG e que o servidor apropria-se do recurso de quorum do cluster.

O secundário detecta falhas de bancos de dados replicados, locais e o armazenamento de informações locais e emite notificações de falha para o primário, perguntando primário para iniciar um failover. O secundário não determinar qual servidor assume nem atualizar estado de local do banco de dados. O principal executa essas tarefas. Quando um banco de dados ativo falha, Active Manager usa um algoritmo de seleção Copiar práticas para selecionar uma cópia do banco de dados para ativar. Esse algoritmo identifica a melhor cópia do banco de dados para ativar com base no status do banco de dados, o status do índice de conteúdo, o comprimento da fila de cópia e o comprimento da fila de repetição na cópia do banco de dados. Se mais de uma cópia do banco de dados atenda aos critérios de seleção, o valor de preferência de ativação é usado e o banco de dados com o menor valor de preferência é ativado e montado.

Após adicionar servidores para um DAG, bancos de dados ativos em cada servidor podem ser replicados para outros servidores o DAG e você pode configurar outras propriedades DAG, como compactação de rede para replicação de banco de dados ou criptografia de rede. Dentro de um DAG logs de transação são replicados para cada servidor membro que tenha uma cópia de um banco de dados de caixa de correio e repetidos na cópia do banco de dados de caixa de correio. Depois de criar várias cópias do banco de dados, você pode usar o console de gerenciamento do Exchange e o Exchange Management Shell para monitorar o status de replicação e integridade de seus DAGs. No caso de uma interrupção de failover do banco de dados poderá ocorrer automaticamente ou você pode iniciar manualmente a alternância. Uma alternância cópia ativa está desmontada e uma cópia em outro servidor o DAG passiva é montada e feita cópia ativa.

Simplificação True

Como expliquei neste artigo, o Exchange 2010 tem muitos aprimoramentos importantes que melhoram a disponibilidade, incluindo integração dos recursos de alta disponibilidade no núcleo, alterações de arquitetura melhorar a disponibilidade e mais. De todos os recursos novos e alterados, DAGs são meu favorito. DAGs verdadeiramente simplificar implementações de cluster e permitem que você enfocar o que importa mais — os dados. Espero que você encontrar este artigo útil e você verá para Meus novos livros, “ Exchange Server 2010 Administrator do Pocket Consultant, ” “ Windows 7 Administrator do Pocket Consultant ” e “ do administrador do Windows Server 2008 Pocket Consultant, 2ª Edição. ”

William r. Stanek (williamstanek.com) é um especialista de tecnologia à esquerda, um instrutor de ensino pretty darn-boa e autor premiada de livros de mais de 100. Atuais ou próximo livros incluem “ Active Directory Administrator do Pocket Consultant, ” “ Group Policy Administrator do Pocket Consultant ”, “ Windows 7 Administrator do Pocket Consultant ”, “ Exchange Server 2010 Administrator do Pocket Consultant ” e “ Windows Server 2008 Inside Out ”. Siga Twitter em Stanek https://twitter.com/WilliamStanek.