Noções Básicas Sobre Alta Disponibilidade e Resiliência do Site

  • Artigo

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2016-11-28

Bancos de dados de caixa de correio e os dados que eles contêm são um dos componentes mais críticos (talvez o mais crítico) de qualquer organização do Exchange. No Microsoft Exchange Server 2010, você pode proteger bancos de dados de caixa de correio e seus dados configurando os bancos de dados de caixa de correio para alta disponibilidade e resiliência de site. O Exchange 2010 reduz o custo e a complexidade de implantar uma solução de mensagens resilientes de site e altamente disponíveis, enquanto fornece níveis mais altos de disponibilidade de ponta a ponta e oferece suporte a grandes caixas de correio. Ampliando as capacidades de replicação nativas apresentadas no Exchange Server 2007, a nova arquitetura de alta disponibilidade do Exchange 2010 fornece uma estrutura simplificada e unificada para alta disponibilidade e resiliência de site. O Exchange 2010 integra a alta disponibilidade à arquitetura principal do Exchange, permitindo que clientes de todos os tamanhos e em todos os segmentos implantem de maneira econômica um serviço de continuidade de mensagens em suas organizações.

Procurando tarefas de gerenciamento relacionadas à alta disponibilidade e à resiliência de site? Consulte Gerenciando a alta disponibilidade e resiliência do site.

Sumário

Terminologia Principal

Principais Características da Solução Exchange Server 2010

Mobilidade de Banco de Dados

Implantação Incremental

Grupos de Disponibilidade de Banco de Dados

Cópias do Banco de Dados de Caixa de Correio

Active Manager

Alterações na Alta Disponibilidade de Versões Anteriores do Exchange

Alta Disponibilidade para Funções de Servidor Diferentes da Função Caixa de Correio

Resiliência do site

Disponibilidade de Ponta a Ponta

Terminologia Principal

A seguintes termos se aplicam:

  • Serviço de Catálogo de Endereços
    Um serviço no servidor de acesso para cliente que fornece um ponto de extremidade de acesso a diretório para clientes do Microsoft Outlook.
  • Replicação contínua - modo de bloqueio
    Uma nova forma de replicação contínua no SP1 em que cada atualização, ao ser gravada na buffer de log da cópia ativa do banco de dados, também é enviada a um buffer de log em cada uma das cópias passivas da caixa de correio. Quando o buffer de log está cheio, cada cópia do banco de dados compila, inspeciona e cria o próximo arquivo de log na sequência de geração.
  • Replicação contínua - modo de arquivo
    O nome da forma original da replicação contínua no lançamento da versão de fabricação (RTM) do Exchange 2010, pelo qual arquivos de log de transação fechados são puxados da cópia do banco de dados ativo para uma ou mais cópias de banco de dados passivas.
  • Grupo de disponibilidade de banco de dados (DAG)
    Um grupo de até 16 servidores de Caixa de Correio do Exchange 2010 que hospedam um conjunto de bancos de dados replicados.
  • Mobilidade de banco de dados
    A capacidade de um único banco de dados de caixa de correio do Exchange 2010 ser replicado e montado e outros servidores de Caixa de Correio do Exchange 2010.
  • Recuperação de desastres
    Qualquer processo usado para se recuperar manualmente de uma falha. Pode ser uma falha que afeta um único item, ou uma falha que afeta toda uma localização física.
  • API de replicação de terceiros do Exchange
    Uma API fornecida pelo Exchange que permite o uso de replicação síncrona de terceiros para um grupo de disponibilidade de banco de dados, ao invés de replicação contínua.
  • Alta disponibilidade
    Uma solução que fornece disponibilidade de serviço, de dados, e recuperação automática de falhas que afetam o serviço ou dados (como uma falha de rede, armazenamento ou servidor).
  • Implantação incremental
    A capacidade de implantar alta disponibilidade e resiliência de site depois da instalação do Exchange 2010.
  • Cópia de banco de dados de caixa de correio defasada
    Uma cópia de banco de dados passiva que tem um intervalo de repetição de log superior a zero.
  • Cópia de banco de dados de caixa de correio
    Um banco de dados de caixa de correio (arquivo .edb e logs), que é ativo ou passivo.
  • Resiliência de caixa de correio
    O nome de uma solução unificada de alta disponibilidade e resiliência de site no Exchange 2010.
  • Serviço de Acesso para Cliente RPC
    Um serviço no servidor de acesso para cliente que fornece um ponto de extremidade MAPI para clientes do Microsoft Outlook.
  • Resiliência do site
    Um processo de recuperação de desastre manual usado para ativar um datacenter alternativo ou em espera quando um datacenter primário não é mais capaz de oferecer um nível suficiente de serviço a fim de atender as necessidades da organização. Também inclui o processo de reativação de um datacenter primário que tenha sido recuperado, restaurado ou recriado. Você pode configurar sua solução de mensagens para alta disponibilidade e habilitar a resiliência de site usando os recursos e funcionalidades internos no Exchange 2010.
  • Redundância de sombra
    Um recurso de servidor de transporte que fornece redundância para mensagens durante todo o tempo em que estão em trânsito.
  • *over(pronuncia-se "star over")
    Abreviação para switchovers (alternâncias) e failovers. Uma alternância é uma ativação manual de uma ou mais cópias de bancos de dados. Um failover é uma ativação automática de uma ou mais cópias de bancos de dados após uma falha.

Voltar ao início

Principais Características da Solução Exchange Server 2010

Exchange 2007 O  diminuiu os custos da alta disponibilidade e tornou a resiliência de site muito mais econômica ao apresentar tecnologias como a replicação contínua em cluster (CCR) e a replicação contínua em espera (SCR). No entanto, alguns desafios permaneceram:

  • Windows O cluster de failover do poderia ser confuso devido à sua complexidade.

  • Atingir um alto nível de tempo de ativação poderia exigir um alto nível de intervenção do administrador.

  • Cada tipo de replicação contínua era gerenciado de forma diferente e separadamente.

  • A recuperação de uma falha de um único banco de dados em um servidor de Caixa de Correio grande poderia resultar em uma interrupção temporária do serviço para todos os usuários do servidor de Caixa de Correio.

  • O recurso de dumpster de transporte do servidor de Transporte de Hub só era capaz de proteger mensagens destinadas a caixas de correio em um ambiente de CCR. Se um servidor de Transporte de Hub falhasse durante o processamento de mensagens e não pudesse ser recuperado, poderia haver perda de dados.

Exchange 2010 O Exchange inclui mudanças de núcleo significativas, que integram a alta disponibilidade à arquitetura, diminuindo o custo e facilitando a implantação e a manutenção, comparadas às versões anteriores do Exchange 2010. O inclui uma nova plataforma unificada, para alta disponibilidade e resiliência de site.

Com as melhorias de núcleo significativas implementadas no Exchange 2010, o tamanho máximo do banco de dados de caixa de correio recomendado, usando replicação contínua, foi aumentado de 200 gigabytes (GB) no Exchange 2007 para 2 terabytes no Exchange 2010. Com mais empresas percebendo o valor maior em grandes caixas de correio (de 2 GB para 10 GB), tamanhos de bancos de dados significativamente maiores podem se tornar uma realidade rapidamente. O suporte a esses bancos de dados maiores significa sair de mecanismos de recuperação legados, como backup e restauração, e entrar em formas mais novas e mais rápidas de proteção, como replicação de dados e redundância de servidor. Por último, o tamanho dos banco sde dados de caixa de correio depende de muitos fatores derivados durante o processo de planejamento do Exchange 2010. Para obter orientações de planejamento detalhadas para caixas de correio e servidores de Caixa de Correio, consulte Design do Armazenamento do Servidor de Caixa de Correio.

Exchange 2010 O combina os recursos chave disponibilidade e resiliência da CCR e da SCR em uma única solução, que trata a replicação de dados internos e externos. Os servidores de caixa de correio podem ser definidos como parte de um DAG, para oferecer a recuperação automática no nível do banco de dados de caixa de correio, em vez do nível de servidor. Outros conceitos novos de alta disponibilidade foram introduzidos no Exchange 2010, como a mobilidade de banco de dados e a implantação incremental.

Voltar ao início

Mobilidade de Banco de Dados

Exchange 2007 O Exchange apresentou muitas alterações na arquitetura, criadas para que fosse mais rápido e simples implantar soluções de alta disponibilidade e resiliência de site no . Essas melhorias incluíam uma experiência de Instalação integrada, definições de configuração otimizadas, e a capacidade de gerenciar a maioria dos aspectos da solução de alta disponibilidade usando ferramentas de gerenciamento nativas do Exchange.

No entanto, o gerenciamento de uma solução de alta disponibilidade do Exchange 2007 exigia conceitos de cluster complexos, como o conceito de movimentação de identidades de rede e o gerenciamento de recursos de cluster. Além disso, ao solucionar problemas relacionados a um servidor de Caixa de Correio clusterizado, ferramentas do Exchange e ferramentas de cluster eram usadas para analisar e correlacionar logs e eventos de duas fontes diferentes: do Exchange e do cluster.

Mais dois aspectos limitantes da arquitetura do Exchange 2007 também foram avaliados e revisados, com base nas opiniões dos clientes:

  • Os servidores do Exchange 2007 clusterizados exigem hardware dedicado. Somente a função de servidor Caixa de Correio podia ser instalada em um nó no cluster. Isso significa que era necessário um mínimo de quatro servidores do Exchange para redundância total dos componentes primários de uma implantação, por exemplo, as funções de servidor principais (Caixa de Correio, Transporte de Hub e Acesso para Cliente).

  • No Exchange 2007, ocorre o failover de um servidor de caixa de correio clusterizado em nível de servidor. Como resultado, se ocorresse uma única falha de banco de dados, o administrador tinha que executar o failover em todo o servidor de Caixa de Correio clusterizado para outro nó do cluster (resultando em um breve período de inatividade para todos os usuários do servidor, e não apenas para os usuários com uma caixa de correio no banco de dados afetado), ou tinha que desconectar os usuários do banco de dados que falhou (provavelmente por horas), enquanto restaurava o banco de dados a partir de um backup.

Exchange 2010 foi projetada com o conceito de mobilidade de banco de dados. A mobilidade de banco de dados expande o uso que o sistema faz da replicação contínua, replicando um banco de dados para vários servidores diferentes que estão agurpados em conjunto. Esse modelo oferece melhor proteção do banco de dados e maior disponibilidade. Neste modelo, a proteção de failover automática e o controle de alternância manual são fornecidos no nível do banco de dados de caixa de correio, ao invés do nível de servidor.

Em caso de falhas, os outros servidores que têm cópias do banco de dados podem montar o banco de dados. Como resultado desta e de outras mudanças na arquitetura, as ações de failover agora são concluídas muito mais rápido do que em versões anteriores do Exchange. Por exemplo, o failover de um servidor de caixa de correio clusterizado em um ambiente de CCR executando o Exchange 2007 com o Service Pack 1, é concluído em aproximadamente 2 minutos (presumindo uma falha intra-site, onde o endereço IP do servidor de caixa de correio clusterizado não muda). Em comparação, o failover de um banco de dados de caixa de correio em um ambiente do Exchange 2010 é concluído em 30 segundos ou menos (contando a partir do momento em que a falha é detectada até quando uma cópia de banco de dados é montada, presumindo que a cópia disponível esteja íntegra e atualizada com a repetição de log). A combinação de failovers em nível de banco de dados e de tempos de failover significativamente mais rápidos aumenta o tempo de ativação global da organização.

Voltar ao início

Implantação Incremental

Exchange 2010 O * introduz o conceito de* implantação incrementalExchange, que permite a você implantar disponibilidade de dados e serviços para todos os servidores de Caixa de Correio e bancos de dados depois da instalação do . A redundância de dados e serviços é alcançada por meio do uso de novos recursos do Exchange 2010, como os DAGs e as cópias de bancos de dados.

Em versões anteriores do Exchange, a disponibilidade de serviço das funções de servidor de Caixa de Correio era alcançada através da implantação do Exchange em um cluster de failover do Windows. Para implantar o Exchange em um cluster, primeiro era preciso criar um cluster de failover, para então instalar os arquivos de programa do Exchange. Esse processo criava um servidor de Caixa de Correio especial, chamado de servidor de caixa de correio clusterizado (ou Servidor Virtual do Exchange, em versões anteriores do Exchange). Se você já tivesse instalado os arquivos de programa do Exchange em um servidor que não fosse clusterizado e decidisse ter um servidor de caixa de correio clusterizado, seria preciso criar um cluster usando um novo hardware ou remover o Exchange do servidor existente, instalar o cluster de failover e reinstalar o Exchange.

Voltar ao início

Grupos de Disponibilidade de Banco de Dados

Um DAG é o componente base da estrutura de alta disponibilidade e resiliência de site interna do Exchange 2010. Um DAG é um grupo de até 16 servidores de Caixa de Correio que hospeda um conjunto de bancos de dados e oferece recuperação automática, no nível de banco de dados, diante de falhas que afetem bancos de dados individuais. Qualquer servidor em um DAG pode hospedar uma cópia de um banco de dados de caixa de correio de qualquer outro servidor no DAG. Quando um servidor é adicionado a um DAG, funciona com outros servidores no DAG para oferecer recuperação automática de falhas que afetem bancos de dados de caixa de correio, como uma falha de disco ou uma falha do servidor.

Exchange 2007 O introduziu uma tecnologia de replicação de dados interna, chamada replicação contínua. A replicação contínua está disponível em três formas: local, cluster e espera, reduziu significativamente o custo de implantação de uma infraestrutura de alta disponibilidade do Exchange, e forneceu uma experiência de implantação e gerenciamento muito melhor em comparação às versões anteriores do Exchange. Mesmo com a economia de custos e as melhorias, no entanto, executar uma infraestrutura do Exchange 2007 altamente disponível ainda exigia muito tempo e expertise, porque a integração entre o Exchange e o cluster de failover do Windows não era perfeita. Além disso, os clientes queriam uma forma mais fácil de replicar os dados de emails para uma localização remota, para proteger seu ambiente do Exchange contra desastres em nível de site.

Exchange 2010 O Exchange 2007 usa a mesma tecnologia de replicação contínua encontrada no Exchange 2010. O combina a replicação de dados interna (CCR) e a replicação de dados externa (SCR) em uma estrutura única, chamada grupo de disponibilidade de banco de dados (DAG). Depois de adicionar servidores ao DAG, você pode adicionar cópias de bancos de dados replicados incrementalmente (até 16 no total) e o Exchange 2010 alterna entre essas cópias automaticamente, para manter a disponibilidade.

Diferente do Exchange 2007, onde servidores de caixa de correio clusterizados exigiam hardware dedicado, os servidores de Caixa de Correio em um DAG podem hospedar outras funções do Exchange (Acesso para Cliente, Transporte de Hub e Unificação de Mensagens), fornecendo redundância completa dos serviços do Exchange e de dados, com apenas dois servidores.

Essa nova arquitetura de alta disponibilidade também fornece recuperação simplificada de várias falhas (nos níveis de disco, servidor e datacenter) e pode ser implantada em vários tipos de armazenamento.

Para obter mais informações sobre DAGs, consulte Noções básicas sobre grupos de disponibilidade de banco de dados.

Voltar ao início

Cópias do Banco de Dados de Caixa de Correio

Os recursos de alta disponibilidade e resiliência de site, introduzidos pela primeira vez no Exchange 2007, são usados no Exchange 2010 para criar e manter cópias de bancos de dados, para que você possa alcançar suas metas de disponibilidade no Exchange 2010. O Exchange 2010 também introduz o conceito de mobilidade de banco de dados, que são failovers de nível de banco de dados gerenciados pelo Exchange.

A mobilidade de banco de dados desconecta bancos de dados dos servidores, adiciona suporte para até 16 cópias de um único banco de dados e oferece uma experiência nativa para a adição de cópias de banco de dados a um banco de dados. No Exchange 2007, um recurso chamado portabilidade de banco de dados também permitia movimentar um banco de dados de caixa de correio entre servidores. Uma diferença significativa entre a portabilidade de banco de dados e a mobilidade de banco de dados, no entanto, é que, todas as cópias de um banco de dados têm o mesmo GUID.

Definir uma cópia de banco de dados como o banco de dados de caixa de correio ativo é conhecido como alternância. Quando uma falha que afeta um banco de dados ocorre e um novo banco de dados torna-se a cópia ativa, este processo é conhecido como failover. Este processo também refere-se a uma falha de servidor na qual um ou mais servidores colocam online o banco de dados que anteriormente estava online no servidor onde a falha aconteceu. Quando uma alternância ou failover ocorre, outras funções de servidor do Exchange 2010 tomam conhecimento da alternância quase imediatamente, e redirecionam o tráfego de mensagens e os clientes para o novo banco de dados ativo.

Por exemplo, se um banco de dados ativo em um DAG falhar devido a uma falha do armazenamento subjacente, o Active Manager automaticamente se recupera, executando failover para uma cópia do banco de dados em outro servidor de Caixa de Correio no DAG. Se o banco de dados estiver fora dos critérios de montagem automática e não puder ser montado automaticamente, você pode executar o failover do banco de dados manualmente.

Para obter mais informações sobre cópias de banco de dados de caixa de correio, consulte Noções Básicas Sobre Cópias do Banco de Dados de Caixa de Correio.

Voltar ao início

Active Manager

No Exchange 2007 e versões anteriores, o Exchange usava o modelo de gerenciamento de recursos do cluster para instalar, implementar e gerenciar a solução de alta disponibilidade do servidor de Caixa de Correio. Historicamente, construir um servidor de Caixa de Correio altamente disponível envolvia, primeiro, construir um cluster de failover do Windows e, em seguida, executar a Instalação do Exchange no modo clusterizado. Neste modo, o arquivo DLL do recurso de cluster do Exchange, exres.dll, seria registrado e permitiria a criação de um servidor de caixa de correio clusterizado (chamado de Servidor Virtual do Exchange, em versões legadas). Ao implantar clusters de armazenamento compartilhado legados, ou clusters de cópia única, etapas adicionais para configurar o armazenamento eram necessárias, antes e depois da formação do cluster de failover, e depois da formação do servidor de caixa de correio clusterizado e do grupo de armazenamento.

Exchange 2010 O * inclui um novo componente, chamado* Active ManagerExchange, que fornece funcionalidades que substituem o modelo de recursos e características de gerenciamento de failover fornecidos pela integração com o serviço de Cluster em versões anteriores do . Para obter mais informações sobre o Active Manager, consulte Noções Básicas Sobre o Gerenciador de Ativos.

Voltar ao início

Alterações na Alta Disponibilidade de Versões Anteriores do Exchange

Há várias alterações na arquitetura principal do Exchange 2010 que têm efeito direto sobre como configurar o Exchange para alta disponibilidade, e sobre como executar a recuperação de site. Uma mudança significativa é a remoção de servidores de caixa de correio clusterizados e o uso do modelo de recursos do Cluster de Failover do Windows. Outras mudanças significativas incluem a globalização de bancos de dados e aprimoramentos na tecnologia de replicação contínua interna, introduzida pela primeira vez no Exchange 2007.

Remoção de Servidores de Caixa de Correio Clusterizados

No Exchange 2010, o Exchange não é mais um aplicativo clusterizado, e o modelo de recursos do cluster não é mais usado para a alta disponibilidade do Exchange. A DLL exres.dll e todos os recursos de cluster do Exchange que ele fornecia não existem mais, incluindo servidores de caixa de correio clusterizados. Em vez disso, o Exchange 2010 usa seu próprio modelo de alta disponibilidade interno. Alguns componentes do cluster de failover do Windows ainda são usados, mas agora estão integrados a outras funcionalidades pelo Exchange 2010.

Globalização de Bancos de Dados

No Exchange 2010, cada banco de dados é associado a um único fluxo de logs dedicado, representado por uma série de arquivos de log de 1 MB, nomeados sequencialmente. O conceito de grupos de armazenamento também foi removido do Exchange 2010. Como resultado dessas alterações, os bancos de dados do Exchange possuem um fluxo de logs dedicado, e não compartilham mais fluxos de logs com outros bancos de dados.

Diferente das versões anteriores do Exchange, os bancos de dados não estão mais estreitamente amarrados a um servidor de Caixa de Correio específico. Além disso, bancos de dados não são mais identificados pelos servidores de Caixa de Correio onde residem, e os nomes dos servidores não são mais parte das identidades dos bancos de dados. Como resultado dessas alterações, os bancos de dados agora são objetos globais no Active Directory e em cada organização do Exchange. Ao usar o Console de Gerenciamento do Exchange, os bancos de dados agora são gerenciados a partir do nó Caixa de Correio, no nó Configuração da Organização.

Cada servidor de Caixa de Correio pode hospedar um máximo de 100 bancos de dados (total combinado do número de bancos de dados ativos e passivos). O número total de bancos de dados é igual ao número combinado de bancos de dados ativos e passivos em um servidor. O banco de dados de recuperação não conta no limite de 100 bancos de dados.

Mudanças na replicação contínua no Exchange 2010 RTM

A tecnologia de replicação contínua introduzida no Exchange 2007 também está disponível no Exchange 2010. Porém, o recurso evoluiu consideravelmente para suportar novos recursos de alta disponibilidade e maior escalabilidade. Algumas dessas alterações na arquitetura incluem:

  • Como os grupos de armazenamento são removidos no Exchange 2010, a replicação contínua agora opera no nível do banco de dados. O Exchange 2010 ainda usa um banco de dados de mecanismo de armazenamento extensível (ESE) que produz logs de transação replicados para um ou mais locais e reproduzidos em uma ou mais cópias de banco de dados de caixa de correio.  Cada banco de dados de caixa de correio pode ter até 16 cópias.

  • O envio de logs não usa mais o protocolo SMB (Server Message Block) e notificações do sistema de arquivos do Windows. O envio de logs não usa mais o modelo "pull", no qual a cópia passiva "puxa" um arquivo de log fechado da cópia ativa. Ao invés disso, a cópia passiva usa notificações baseadas em TCP para comunicar a cópia ativa sobre quais arquivos de log são exigidos pela cópia passiva. A cópia ativa, então, "empurra" os arquivos de log para cada cópia passiva configurada via soquete TCP.

  • Exchange 2010 a replicação contínua usa uma porta TCP definida pelo administrador para transferência de dados. Além disso, o Exchange 2010 inclui opções internas para criptografia de rede e compactação para o fluxo de dados.

  • A propagação não se restringe mais apenas ao uso da cópia ativa do banco de dados. Agora as cópias passivas de bancos de dados de caixas de correio podem ser especificadas como fontes para a propagação e a repropagação de cópias de bancos de dados.

  • As cópias de bancos de dados são apenas para bancos de dados de caixa de correio. Para redundância e alta disponibilidade de bancos de dados de pastas públicas, é recomendável o uso da replicação de pasta pública. Ao contrário da CCR, onde várias cópias de um banco de dados de pasta pública não podem existir no mesmo cluster, você pode usar a replicação de pasta pública para replicar bancos de dados de pastas públicas entre servidores em um DAG.

  • No Exchange 2007, o serviço de Replicação do Microsoft Exchange era responsável pela repetição de logs em cópias de bancos de dados passivas. Quando uma cópia passiva era ativada, o cache do banco de dados que tinha sido construído pelo serviço de Replicação do Microsoft Exchange como resultado de uma atividade de repetição, seria perdido quando o serviço de Armazenamento de Informações do Microsoft Exchange montasse o banco de dados. Isso coloca o cache do banco de dados em um estado conhecido como estado frio. O cache do banco de dados, usado para armazenar operações de gravação/leitura em cache, é pequeno em tamanho (frio) durante esse período. Portanto, sua capacidade de reduzir as operações de E/S de leitura é significativamente diminuída. No Exchange 2010, a funcionalidade de repetição da cópia passiva executada anteriormente pelo serviço de Replicação do Microsoft Exchange, foi movido para o serviço de Armazenamento de Informações do Microsoft Exchange. Como resultado, um cache de banco de dados aquecido está presente e imediatamente disponível para uso depois que um failover ou alternância ocorre.

Vários conceitos de replicação contínua usados no Exchange 2007 também permanecem no Exchange 2010. Eles incluem os conceitos de gerenciamento de failover, divergência, o uso da discagem automática de montagem de banco de dados e o uso de replicação e redes de acesso do cliente (MAPI).

Mudanças na replicação contínua no Exchange 2010 SP1

Na versão RTM do Exchange 2010 e em todas as versões do Exchange Server 2007, a replicação contínua funciona enviando cópias dos arquivos de log gerados pela cópia de bancos de dados ativos para as cópias de bancos de dados passivos. Começando com o Exchange 2010 SP1, essa forma de replicação contínua é conhecida como replicação contínua - modo de arquivo. O SP1 introduz também uma nova forma de replicação contínua conhecida como replicação contínua - modo de bloqueio. No modo de bloqueio, cada atualização, ao ser gravada na buffer de log ativo da cópia ativa do banco de dados, também é enviada para um buffer de log em cada uma das cópias passivas da caixa de correio. Quando o buffer de log está cheio, cada cópia do banco de dados compila, inspeciona e cria o próximo arquivo de log na sequência de geração. Caso uma falha afete a cópia ativa, as cópias passivas terão sido atualizadas com a maioria ou todas as últimas atualizações.  A cópia ativa não aguarda que a replicação seja concluída para impedir que problemas na replicação afetem a experiência do cliente.

O modo de bloqueio reduz sensivelmente a latência entre o momento em que uma alteração é feita na cópia ativa e o momento em que a alteração é replicada nas cópias passivas. Além de replicar gravações de arquivos de log individuais, o modo de bloqueio altera também o processo de ativação de uma cópia passiva. Se uma cópia está em modo de bloqueio quando ocorre uma falha, o sistema usa qualquer conteúdo de log parcial que esteja disponível durante o processo de ativação. Isso impede que o arquivo de log atual na cópia ativa seja um ponto único de falha.

O modo de operação inicial é sempre o modo de arquivo. O modo de bloqueio só está ativo quando a replicação contínua está atualizada no modo de arquivo. A transição de entrada e saída do modo de bloqueio é executada automaticamente pelo copiador de log. Quando a cópia passiva solicita o arquivo de log atual, ela indica que a replicação contínua está atualizada (o tamanho da fila de cópia é 0) e o sistema deve ser mudado automaticamente do modo de arquivo para o modo de bloqueio.

É possível determinar se uma cópia de banco de dados passiva está no modo de bloqueio monitorando o contador de desempenho Replicação contínua – modo de bloqueio ativo no objeto de desempenho Replicação do MSExchange. Cada cópia de banco de dados tem sua própria instância desse contador. O valor do contador é definido como 1 quando a cópia passiva está em modo de bloqueio e 0 quando a cópia passiva está em modo de arquivo. Você também pode determinar o valor desse contador usando os cmdlets Get-Counter ou Get-WmiObject, como é mostrado nestes exemplos:

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Alterações no Dumpster de Transporte do Exchange 2007

A função de servidor Transporte de Hub do Exchange 2010 inclui um recurso chamado dumpster de transporte, que foi introduzido pela primeira vez no Exchange 2007. O dumpster de transporte é projetado para ajudar na proteção contra perda de dados, mantendo uma fila de todas as mensagens de email enviadas recentemente para usuários cujas caixas de correio estavam protegidas por CCR ou LCR. Quando uma falha com perdas ocorre em um desses ambientes, uma massa dos dados que normalmente teriam sido perdidos como resultado da falha, é automaticamente recuperada pelo dumpster de transporte.

O dumpster de transporte é usado apenas para bancos de dados de caixa de correio replicados. Ele não protege mensagens enviadas para pastas públicas, nem mensagens enviadas para destinatários em bancos de dados de caixa de correio que não são replicados. A fila do dumpster de transporte de um banco de dados de caixa de correio específico está localizado em todos os servidores de Transporte de Hub do site do Active Directory que contêm o DAG.

No Exchange 2007, as mensagens eram retidas no dumpster de transporte até que o tempo limite definido pelo administrador ou o limite de tamanho fosse alcançado. No Exchange 2010, o dumpster de transporte agora recebe um retorno do pipeline de replicação para determinar quais mensagens foram entregues e replicadas. Enquanto a mensagem passa pelos servidores de Transporte de Hub em seu caminho para um banco de dados de caixa de correio replicado em um DAG, uma cópia é mantida na fila de transporte (mail.que) até que os logs de transações representando a mensagem tenham sido replicados com sucesso e inspecionados por todas as cópias do banco de dados de caixa de correio.  Após os logs terem sido replicados e inspecionados por todas as cópias de banco de dados, as mensagens nesses logs são truncadas a partir do dumpster de transporte. Isso mantém a fila do dumpster de transporte menor, mantendo apenas cópias de mensagens cujos logs de transações ainda não foram replicados.

O Active Manager de cada DAG acompanha o valor da última vez que o log foi inspecionado em cada cópia passiva do banco de dados. O cliente Active Manager sendo executado no servidor de Transporte de Hub obtém estas informações no Standby Active Manager (SAM) do DAG e as converte em marca-d’água baseada no tempo. O servidor de Transporte de Hub então compara o tempo de entrega das mensagens no dumpster de transporte com a marca d'água. Se o tempo de entrega de uma mensagem é anterior à marca d'água, a mensagem é truncada no dumpster de transporte.

O dumpster de transporte também foi aprimorado para considerar as alterações na função de servidor Caixa de Correio que permitem que um único banco de dados de caixa de correio seja movido entre sites do Active Directory. DAGs podem ser estendidos para vários sites do Active Directory e, como resultado, um único banco de dados de caixa de correio em um site do Active Directory pode sofrer failover para outro site do Active Directory. Quando isso acontece, qualquer solicitação de reentrega do dumpster de transporte é enviada para os dois sites do Active Directory: o site original e o novo site.

Alterações no Comportamento do Roteamento Quando o Transporte de Hub e a Caixa de Correio estão Co-Localizados em um DAG

Quando o servidor de Transporte de Hub está co-localizado com um servidor de Caixa de Correio membro de um DAG, há alterações no comportamento de roteamento para garantir que os recursos de resiliência em ambas as funções de servidor fornecerão a proteção necessária para as mensagens enviadas e recebidas por usuários no servidor. A função de servidor Transporte de Hub foi modificada e agora tenta rotear novamente uma mensagem para um servidor de Caixa de Correio local para outro servidor de Transporte de Hub no mesmo site, se o servidor de Transporte de Hub também for membro do DAG e tiver uma cópia do banco de dados de caixa de correio montada localmente. Esse salto extra foi adicionado para colocar a mensagem no dumpster de transporte em um servidor de Transporte de Hub diferente.

Por exemplo, EX1 hospeda as funções de servidor Caixa de Correio e Transporte de Hub e é membro de um DAG. Quando uma mensagem chega em transporte para EX1, direcionada a um destinatário cuja caixa de correio também está em EX1, o transporte torna a rotear a mensagem para outro servidor de Transporte de Hub no site (por exemplo, EX2), e esse servidor entrega a mensagem para a caixa de correio em EX1.

Há uma segunda alteração de comportamento, similar, relacionada ao serviço de Envio de Mensagens do Microsoft Exchange. Esse serviço foi modificado para não enviar mensagens para uma função de servidor Transporte de Hub local quando o servidor de Caixa de Correio ou o servidor de Transporte de Hub for membro de um DAG. Nesse cenário, o comportamento do transporte é balancear a carga das solicitações de envio por outros servidores de Transporte de Hub no mesmo site do Active Directory, e reverter para o servidor de Transporte de Hub local se não houver outros servidores de Transporte de Hub disponíveis no mesmo site.

Voltar ao início

Alta Disponibilidade para Funções de Servidor Diferentes da Função Caixa de Correio

A alta disponibilidade para as funções de servidor Transporte de Hub, Transporte de Borda, Acesso para Cliente e Unificação de Mensagens é alcançada por meio de uma combinação de redundância de servidor, balanceamento de carga e rodízio de DNS, bem como do gerenciamento pró-ativo de servidor, serviço e infraestrutura. Em geral, você pode obter alta disponibilidade para as funções de servidor Acesso para Cliente, Transporte de Hub, Transporte de Borda e Unificação de Mensagens usando as seguintes estratégias e tecnologias:

  • Transporte de Borda   Você pode implantar vários servidores de Transporte de Borda e usar vários registros de recursos MX do DNS para equilibrar a carga de atividade entre os servidores. Também é possível usar o Balanceamento de Carga de Rede (NLB) para fornecer balanceamento de carga e alta disponibilidade para servidores de Transporte de Borda.

  • Acesso para Cliente   Você pode usar o NLB ou um dispositivo de balanceamento de carga da rede baseado em hardware de terceiros para obter alta disponibilidade do servidor de Acesso para Cliente.

  • Transporte de Hub   É possível implantar vários servidores de Transporte de Hub para obter alta disponibilidade de transporte interno. A resiliência foi projetada na função de servidor Transporte de Hub da seguinte maneira:

    • Servidor de Transporte de Hub para servidor de Transporte de Hub (intra-organização)   A comunicação de servidor de Transporte de Hub para servidor de Transporte de Hub em uma organização executa automaticamente o balanceamento de carga entre os servidores de Transporte de Hub disponíveis no site de destino do Active Directory.

    • Servidor de Caixa de Correio para servidor de Transporte de Hub (intra-sites do Active Directory)   Os serviços de Envio de Mensagens do Microsoft Exchange nos servidores de Caixa de Correio executam automaticamente o balanceamento de carga entre todos os servidores de Transporte de Hub disponíveis no mesmo site do Active Directory.

    • Servidor de Unificação de Mensagens para servidor de Transporte de Hub   O servidor de Unificação de Mensagens executa automaticamente o balanceamento de carga das conexões entre todos os servidores de Transporte de Hub disponíveis no mesmo site do Active Directory.

    • Servidor de Transporte de Borda para servidor de Transporte de Hub   O servidor de Transporte de Borda executa automaticamente o balanceamento de carga entre o tráfego SMTP de entrada e todos os servidores de Transporte de Hub do site do Active Directory nos quais o servidor de Transporte de Borda está inscrito.

    Para redundância adicional (por exemplo, aplicativos que exigem uma retransmissão SMTP), você pode criar um novo registro DNS (por exemplo, relay.empresa.com), atribuir um endereço IP e usar um balanceador de carga de hardware para redirecionar esse endereço IP para vários servidores de Transporte de Hub. Você também pode usar o NLB para os conectores cliente nos servidores de Transporte de Hub. Ao usar um balanceador de carga de hardware, você precisa confirmar que nenhum tráfego intra-organização esteja cruzando o balanceador de carga de hardware, porque o tráfego intra-organização usa algoritmos internos de balanceamento de carga (conforme descrito anteriormente).

  • Unificação de Mensagens   Implantações de Unificação de Mensagens podem se tornar mais resilientes com a implantação de vários servidores de Unificação de Mensagens, em que dois ou mais estão em um único plano de discagem. Os gateways VoIP aceitos pela Unificação de Mensagens podem ser configurados para rotear chamadas para servidores de Unificação de Mensagens no estilo de rodízio. Além disso, esses gateways podem recuperar a lista de servidores de um plano de discagem do DNS. Em qualquer um dos casos, os gateways VoIP apresentarão uma chamada para um servidor de Unificação de Mensagens e, se não for aceita, a chamada será apresentada a outro servidor, oferecendo redundância no momento em que a chamada é estabelecida.

Voltar ao início

Resiliência do site

O Exchange 2010 inclui uma plataforma unificada para alta disponibilidade e resiliência do site. Ao combinar o suporte de resiliência do site nativo no Exchange 2010 com o planejamento adequado, um segundo datacenter pode ser rapidamente ativado para atender aos clientes dos datacenters com falha. Um datacenter ou uma falha no site são gerenciados de maneira diferente dos tipos de falhas que podem causar failover em um servidor ou banco de dados. Em uma configuração de alta disponibilidade, a recuperação automática é iniciada pelo sistema, e a falha normalmente deixa o sistema de mensagens em um estado totalmente funcional. Por outro lado, uma falha de datacenter é considerada um evento de recuperação de desastre. A recuperação deve ser realizada e concluída manualmente para que o serviço do cliente seja restaurado e a interrupção seja encerrada. O processo realizado é denominado alternância de datacenter. Assim como em muitos cenários de recuperação de desastres, planejamento e preparação antecipados para uma alternância de datacenter podem simplificar o processo de recuperação e reduzir a duração da interrupção.

Para detalhes sobre planejamento e implantação de resiliência do site, consulte Planejamento da alta disponibilidade e resiliência do site, Implantando a alta disponibilidade e resiliência do site e Switchovers do Datacenter.

Voltar ao início

Disponibilidade de Ponta a Ponta

Exchange 2010 O  também inclui muitos recursos projetados para aumentar a disponibilidade de ponta a ponta do sistema. Esses recursos incluem:

  • Redundância de sombra

  • Movimentação online de caixa de correio

  • Proteção flexível de Caixa de Correio

  • Ressincronização incremental

  • API de replicação de terceiros

Redundância de Sombra

Além do dumpster de transporte e das melhorias no comportamento do roteamento descritas anteriormente, um novo recurso de servidor de Transporte de Hub chamado redundância de sombra foi acrescentado. A redundância de sombra fornece redundância para mensagens durante todo o tempo em que estiverem em trânsito. A solução envolve uma técnica semelhante ao dumpster de transporte. Com a redundância de sombra, a exclusão de uma mensagem do banco de dados de transporte é atrasada até que o servidor de transporte confirme que todos os próximos saltos da mensagem tenham concluído a entrega. Se algum dos saltos seguintes falhar antes de reportar a entrega com sucesso, a mensagem é reenviada para entrega para o salto seguinte. Para obter mais informações sobre a redundância de sombra, consulte Noções Básicas Sobre Redundância de Sombra.

Movimentação Online de Caixa de Correio

Exchange 2010 O  inclui um novo recurso que permite mover caixas de correio de forma assíncrona. No Exchange 2007, ao usar o cmdlet Move-Mailbox para mover uma caixa de correio, o cmdlet fazia um registro no banco de dados de origem e no banco de dados de destino, e movia o conteúdo de uma caixa de correio para outra. Havia várias desvantagens em ter cmdlets executando a operação de movimentação:

  • As movimentações de caixa de correio geralmente levavam horas para serem concluídas e, durante a movimentação, os usuários não podiam acessar suas caixas de correio.

  • Se o Prompt de Comando usado para executar o cmdlet Move-Mailbox fosse fechado, a movimentação era encerrada e tinha que ser reiniciada.

  • O computador usado para realizar a movimentação participava da transferência de dados. Se um administrador executasse os cmdlets a partir de sua estação de trabalho, os dados de caixa de correio fluiriam do servidor de origem para a estação de trabalho do administrador, e dali para o servidor de destino.

Os cmdlet New-MoveRequest no Exchange 2010 pode ser usado para executar movimentações assíncronas. Ao contrário do que ocorria no Exchange 2007, os cmdlets não executam a movimentação em si. A movimentação é realizada pelo Serviço de Replicação de Caixa de Correio do Microsoft Exchange, um novo serviço executado no servidor de Acesso para Cliente. O cmdlet New-MoveRequest envia solicitações ao Serviço de Replicação de Caixa de Correio do Microsoft Exchange. Para obter mais informações sobre movimentações de caixa de correio online, consulteNoções Básicas Sobre Solicitações de Movimentação

Proteção Flexível de Caixa de Correio

Há várias alterações no núcleo da arquitetura do Exchange 2010 com efeito direto sobre a forma como seus bancos de dados de caixas de correio e as caixas de correio que eles contêm são protegidos.

Uma alteração significativa é a remoção dos grupos de armazenamento. No Exchange 2010, cada banco de dados é associado a um único fluxo de logs, representado por uma série de arquivos de log de 1 MB. Cada servidor pode hospedar um máximo de 100 bancos de dados.

Outra mudança significativa no Exchange 2010 é que os bancos de dados não estão mais estreitamente ligados a um servidor de caixa de correio específico. A mobilidade de banco de dados expande o uso que o sistema faz da replicação contínua, replicando um banco de dados para vários servidores diferentes. Isso oferece melhor proteção do banco de dados e maior disponibilidade. Em caso de falhas, os outros servidores que têm cópias do banco de dados podem montar o banco de dados.

A capacidade de ter várias cópias de um banco de dados hospedadas em vários servidores significa que, se você tiver um número suficiente de cópias de banco de dados, pode usar essas cópias como seus backups. Para obter mais informações sobre essa estratégia, consulte Understanding Backup, Restore and Disaster Recovery.

Ressincronização Incremental

Exchange 2007 O introduziu os conceitos de resiliência de log perdido e nova propagação incremental. A resiliência de log perdido é um componente interno do ESE que permite recuperar bancos de dados de caixa de correio do Exchange, mesmo que um ou mais dos arquivos de log de transações gerados mais recentemente tenham sido perdidos ou danificados. A resiliência de log perdido permite a montagem de um banco de dados de caixa de correio mesmo quando arquivos de log gerados recentemente estiverem indisponíveis. A resiliência de log perdido funciona atrasando gravações no banco de dados, até que o número especificado de gerações de log tenha sido criado. A resiliência de log perdido atrasa atualizações recentes do arquivo do banco de dados por um período curto. A duração de tempo em que as gravações são atrasadas depende da rapidez com que os logs estão sendo gerados.

Exchange 2007 O também introduziu o conceito de nova propagação incremental, que oferecia a capacidade de corrigir divergências no fluxo de log de transações entre um grupo de armazenamento de origem e de destino, apoiando-se nas capacidades de repetição atrasada da resiliência de log perdido. A nova propagação incremental não oferecia uma maneira de corrigir divergências na cópia passiva de um banco de dados depois que logs divergentes eram repetidos, o que forçava a necessidade de uma nova propagação completa. IDiferentemente do Exchange 2007, não há qualquer quantidade de perda de log que exija uma nova propagação total no Exchange 2010

No Exchange 2010, ressincronização incremental é o novo nome do recurso que corrige divergências automaticamente em cópias de banco de dados, sob as seguintes condições:

  • Depois de um failover automático de todas as cópias configuradas de um banco de dados

  • Quando uma nova cópia é habilitada e alguns arquivos de banco de dados e de logs já existem no local da cópia

  • Quando replicações são retomadas após uma suspensão ou um reinício do serviço de Replicação doMicrosoft Exchange

Como resultado dessas alterações, a resiliência de log perdido é agora fixa para um arquivo de log para todos os bancos de dados de caixa de correio do Exchange 2010.

Quando é detectada uma divergência entre um banco de dados ativo e uma cópia desse banco de dados, a ressincronização incremental realiza as seguintes tarefas:

  • Pesquisa historicamente no fluxo de arquivos de log para localizar o ponto de divergência.

  • Localiza as páginas alteradas do banco de dados na cópia divergente.

  • Lê as páginas alteradas da cópia ativa e copia os arquivos de log necessários da cópia ativa.

  • Aplica as alterações de página do banco de dados à cópia divergente.

  • Executa a recuperação na cópia divergente e repete os arquivos de log necessários para a cópia do banco de dados.

API de Replicação de Terceiros

Exchange 2010 O também inclui uma nova API de replicação de terceiros que permite que as organizações usem soluções de replicação síncronas de terceiros, ao invés do recurso de replicação contínua interno. A Microsoft oferece suporte a soluções de terceiros que usam essa API, desde que a solução ofereça as funcionalidades necessárias para substituir todas as funcionalidades nativas de replicação contínua que são desabilitadas como resultado do uso da API. As soluções têm suporte apenas quando a API é usada dentro de um DAG para gerenciar e ativar cópias do banco de dados de caixa de correio. Não há suporte ao uso da API fora desses limites.  Além disso, a solução deve atender às especificações aplicáveis de suporte a hardware do Windows (teste de validação não é necessário para suporte).

Ao implantar uma solução que use a API de replicação interna de terceiros, lembre-se que o fornecedor da solução é responsável pelo suporte primário à solução. A Microsoft dá suporte aos dados do Exchange para soluções replicadas e não-replicadas. Soluções que usam a replicação de dados devem aderir à política de suporte da Microsoft, como descrito no artigo 895847 da Base de Conhecimento Microsoft Suporte de replicação de dados para vários sites do Exchange Server. Além disso, as soluções que utilizam o modelo de recurso de cluster de failover do Windows deve atender os requisitos de suportabilidade de cluster do Windows descrito no artigo 943984 da da Base de Conhecimento Microsoft, A Política de suporte Microsoft para clusters de failover do Windows Server 2008.

A política de suporte a backup e restauração da Microsoft para implantações que usam soluções de replicação de terceiros baseadas em API é a mesma adotada para implantações nativas de replicação contínua.

Se você for um parceiro procurando informações sobre a API de replicação de terceiros, entre em contato com seu representante Microsoft. Para obter informações sobre produtos de parceiros para o Exchange 2010, consulte Parceiros do Microsoft Exchange.

Voltar ao início

 © 2010 Microsoft Corporation. Todos os direitos reservados.