Nova alta disponibilidade e funcionalidade de resiliência de sites

Artigo
05/20/2011

Aplica-se a: Exchange Server 2010

Tópico modificado em: 2009-12-08

O Microsoft Exchange Server 2010 reduz o custo e a complexidade de implantação de uma solução de email que oferece os mais altos níveis de disponibilidade de servidor e resiliência de site. Ampliando as capacidades de replicação nativas apresentadas no Exchange Server 2007, a nova arquitetura de alta disponibilidade do Exchange 2010 oferece um framework simplificado e unificado para alta disponibilidade e recuperação de desastres. 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.

Lições Aprendidas com o Exchange Server 2007

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

Alguns administradores se sentiram intimidados pela complexidade do cluster de failover do Windows.
Atingir um alto nível de tempo de ativação pode 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 pode resultar em uma interrupção temporária do serviço para todos os usuários do servidor de Caixa de Correio.
As soluções de resiliência de site não eram perfeitas.
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 LCR ou 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.

O Exchange 2010 inclui alterações importantes que integram a alta disponibilidade profundamente em sua arquitetura, diminuindo ainda mais seus custos e tornando mais fácil a implantação e a manutenção para seus clientes do que no Exchange 2007. Agora as organizações podem implantar uma organização do Exchange totalmente redundante com apenas dois servidores, e se beneficiar de failovers em nível de banco de dados. Os clientes se beneficiam das capacidades de failover automático em nível de banco de dados sem ter que se tornar peritos em cluster de failover do Windows. Além disso, você pode adicionar resiliência de site às suas implantações existentes de alta disponibilidade com menos complexidade.

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

Ainda assim, o gerenciamento de uma solução de alta disponibilidade do Exchange 2007 exigia dos administradores o domínio de alguns conceitos de cluster, 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, os administradores tinham que usar ferramentas do Exchange e ferramentas de cluster 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 reavaliados e reprojetados com base nas opiniões dos clientes:

Os servidores do Exchange 2007 clusterizados exigem hardware dedicado. Somente a função de servidor de Caixa de Correio podia ser instalada em um nó do 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, ou seja, as funções principais de servidor (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 dar failover em todo o servidor de Caixa de Correio clusterizado para outro nó do cluster (resultando em um breve tempo 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 deixar offline os usuários do banco de dados que falhou (provavelmente por horas) enquanto restaurava o banco de dados a partir de um backup.

Resiliência de caixa de correio

O Exchange 2010 foi reprojetado em torno do conceito de resiliência de caixa de correio, com a arquitetura alterada para que a proteção automática de failover passe a ser oferecida no nível do banco de dados de caixa de correio, e não no nível do servidor. No Exchange 2010, isso é chamado de mobilidade de banco de dados. O resultado disso e de outras alterações de arquitetura do cache de banco de dados é que as ações de failover agora são concluídas muitos mais rapidamente do que em versões anteriores do Exchange. Por exemplo, o failover de um servidor de caixa de correio em cluster em um ambiente CCR executando o Exchange 2007 com Service Pack 2 (SP2) é concluído em aproximadamente dois minutos. 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 dramaticamente o tempo global de ativação da organização.

A arquitetura de resiliência de caixa de correio integrada ao Exchange 2010 proporciona novos benefícios para organizações e seus administradores de mensagens:

Várias funções de servidor podem coexistir em servidores que fornecem alta disponibilidade. Isso permite a pequenas organizações implantar uma configuração com dois servidores que ofereça redundância de dados e serviços de caixa de correio, ao mesmo tempo que oferece serviços redundantes de Acesso para Cliente e Transporte de Hub.
Um administrador não precisa mais construir um cluster de failover para ter alta disponibilidade. Agora os clusters de failover são criados pelo Exchange 2010 de forma invisível para o administrador. Ao contrário de versões anteriores dos clusters do Exchange que usavam uma DLL de recurso de cluster fornecida pelo Exchange chamada ExRes.dll, o Exchange 2010 não usa e não precisa mais de uma DLL de recurso de cluster. O Exchange 2010 não é um aplicativo clusterizado e usa apenas uma pequena porção dos componentes de cluster de failover, mais especificamente suas capacidades de pulsação e o banco de dados de cluster, para oferecer a mobilidade de banco de dados.
Os administradores podem adicionar a alta disponibilidade ao ambiente do Exchange 2010 após a implantação do Exchange, sem ter que desinstalar o Exchange para então reimplantar a configuração de alta disponibilidade.
O Exchange 2010 oferece uma visão do fluxo de eventos que aglutina e combina os eventos do sistema operacional com os eventos do Exchange.
Como os objetos de grupo de armazenamento não existem mais no Exchange 2010 e os bancos de dados de caixa de correio são portáveis entre todos os servidores de Caixa de Correio do Exchange 2010, é fácil mover bancos de dados quando necessário.

Para mais informações, consulte Alta disponibilidade e resiliência do site.

Proteção flexível de Caixa de Correio

O Exchange 2010 inclui vários recursos novos e alterações importantes que, quando implantados e configurados corretamente, podem oferecer proteção flexível de caixa de correio que elimina a necessidade de fazer backups tradicionais de seus dados. O uso dos recursos de alta disponibilidade se integram ao Exchange 2010 para minimizar o tempo de inatividade e a perda de dados caso haja um desastre também podem reduzir o custo total de propriedade do sistema de mensagens. Ao combinar esses recursos a outros recursos integrados, como à Retenção de Documentos, as organizações podem reduzir ou eliminar sua dependência de backups pontuais tradicionais e perceber a economia de custo disso.

Além de determinar se o Exchange 2010 permitirá a você abandonar os backups pontuais tradicionais, também recomendamos que você avalie os custos de sua infraestrutura de backup atual. Considere os custos de perda de dados e tempo de inatividade de usuário final ao tentar se recuperar de um desastre usando sua infraestrutura de backup existente. Inclua também os custos com hardware, instalação e licenças, além do custo de gerenciamento associado à recuperação de dados e à manutenção de backups. Dependendo dos requisitos de sua organização, é bem provável que um ambiente puro do Exchange 2010 com pelo menos três cópias de banco de dados de caixa de correio ofereça um custo total de propriedade menor do que um com backups.

Para mais informações sobre a proteção flexível de caixa de correio, consulte Understanding Backup, Restore and Disaster Recovery.

Alterações na alta disponibilidade em relação a versões anteriores do Exchange

O Exchange 2010 inclui muitas alterações em sua arquitetura de núcleo. O Exchange 2010 combina os recursos mais importantes de disponibilidade e resiliência do CCR e do SCR em uma única solução de alta disponibilidade que lida com a replicação de dados locais e externos. Os servidores de caixa de correio podem ser definidos como parte de um grupo de disponibilidade de banco de dados (DAG) para oferecer a recuperação automática em nível de banco de dados de caixa de correio individual em vez de nível de servidor. Cada banco de dados de caixa de correio pode ter até 16 cópias. Outros conceitos novos de alta disponibilidade foram introduzidos no Exchange 2010, como a mobilidade de banco de dados e a implantação incremental. Os conceitos de uma organização sem backups e RAID também estão sendo apresentados no Exchange 2010.

Resumindo, os principais aspectos da disponibilidade de dados e serviços da função de servidor de caixa de correio e dos bancos de dados de caixa de correio são:

O Exchange 2010 usa uma versão aprimorada da mesma tecnologia de replicação contínua apresentada no Exchange 2007. Para mais informações, consulte Alterações na replicação contínua em relação ao Exchange Server 2007, mais adiante neste tópico.
Os grupos de armazenamento não existem mais no Exchange 2010. Em seu lugar, estão bancos de dados de caixas de correio simples, cópias de bancos de dados de caixas de correio e bancos de dados de pastas públicas. As interfaces de gerenciamento primárias de bancos de dados do Exchange mudaram de lugar no Console de Gerenciamento do Exchange, indo do nó de caixa de correio em Configuração do Servidor para o nó de caixa de correio em Configuração da Organização.
Algumas tecnologias de Cluster de Failover do Windows são usadas pelo Exchange 2010, mas agora elas são completamente gerenciadas pelo Exchange. Os administradores não precisam instalar, criar ou configurar nenhum aspecto do cluster de failover ao implantar servidores de Caixa de Correio de alta disponibilidade.
Cada servidor de Caixa de Correio pode hospedar até 100 bancos de dados, e cada banco de dados pode ter até 16 cópias.
Além do recurso de dumpster de transporte, 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 por 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 qualquer um dos próximos saltos falharem antes de relatar sucesso na entrega, a mensagem será reenviada para entrega para o próximo salto. Para mais informações sobre a redundância de sombra, consulte Noções Básicas Sobre Redundância de Sombra.

Implantação incremental

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 que chamamos 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 hardware novo ou remover o Exchange do servidor existente, instalar o cluster de failover e reinstalar o Exchange.

O Exchange 2010 introduz o conceito de implantação incremental, que permite a você implantar disponibilidade de dados e serviços para todos os servidores de caixa de correio e bancos de dados após a instalação do Exchange. 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.

Grupos de disponibilidade de banco de dados

Um DAG é um conjunto de até 16 servidores de Caixa de Correio que 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 caixas de correios, como uma falha de disco ou uma falha do servidor.

Para mais informações sobre DAGs, consulte Noções Básicas Sobre Grupos de Disponibilidade de Banco de Dados.

Cópias de banco de dados de Caixa de Correio

Os recursos de alta disponibilidade e resiliência de site introduzidos no Exchange 2007 são usados no Exchange 2010 para criar e manter cópias de banco de dados, permitindo a você alcançar seus objetivos de disponibilidade no Exchange 2010. O Exchange 2010 também introduz o novo conceito de mobilidade de banco de dados, os failovers em 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 importante entre a portabilidade de banco de dados e a mobilidade de banco de dados, no entanto, é que, na mobilidade de banco de dados, todas as cópias têm o mesmo GUID.

Outras características importantes da mobilidade de banco de dados são:

Como os grupos de armazenamento foram removidos do Exchange 2010, a replicação contínua agora opera no nível do banco de dados. No Exchange 2010, os logs de transação são replicados para um ou mais servidores de Caixa de Correio e são repetidos para uma cópia de um banco de dados de caixa de correio armazenado nesses servidores.
Um failover é um processo de ativação automática que pode ocorrer no nível do banco de dados ou no nível do servidor. Uma alternância é um processo de ativação manual que você pode realizar no nível do banco de dados, do servidor ou do data center (site).
Os nomes de bancos de dados do Exchange 2010 devem ser exclusivos dentro da organização do Exchange.
Se um banco de dados de caixa de correio for configurado com uma ou mais cópias de banco de dados, o caminho completo de todas as cópias de banco de dados deve ser idêntico em todos os servidores de Caixa de Correio que hospedam uma cópia.
Qualquer cópia de banco de dados de caixa de correio (a cópia passiva ou a cópia ativa) pode ser copiada para um backup usando um aplicativo de backup baseado no Serviço de Cópias de Sombra de Volume (VSS) sensível ao Exchange.

Para 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.

Alterações na replicação contínua em relação ao Exchange Server 2007

A tecnologia de replicação contínua subjacente encontrada anteriormente no CCR e no SCR permanece no Exchange 2010 e evoluiu para oferecer suporte a novos recursos de alta disponibilidade como cópias de banco de dados, mobilidade de banco de dados e DAGs. Algumas dessas alterações arquiteturais novas são descritas resumidamente a seguir:

Como os grupos de armazenamento foram removidos do 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 Mecanismo de Armazenamento Extensível (ESE) que produz logs de transação replicados para uma ou mais localidades e repetidos para uma ou mais cópias de um banco de dados de caixa de correio.
Como a funcionalidade de repetição de log realizada pelo serviço de Replicação do Microsoft Exchange no Exchange 2007 foi movida para a versão do Exchange 2010 do serviço de Armazenamento de Informações do Microsoft Exchange (store.exe), a perda de desempenho associada a failovers e alternâncias (decorrentes do uso de cache de banco de dados) não existe mais. Quando ocorre um failover ou uma alternância, o banco de dados ativado tem um cache passivo pronto para o uso.
O envio e a propagação de logs não usam mais o protocolo SMB para transferência de dados. A replicação contínua do Exchange 2010 usa uma única porta TCP definida pelo administrador para a transferência de dados. Além disso, o Exchange 2010 inclui opções integradas para criptografia de rede e compactação para o fluxo de dados.
O envio de logs não usa mais um modelo no qual a cópia passiva “puxa” os arquivos de log da cópia ativa. Em vez disso, a cópia ativa “empurra” os arquivos de log para cada cópia passiva configurada.
A propagação não mais se restringe apenas ao uso da cópia ativa do banco de dados. Agora as cópias passivas de bancos de dados de caixas de correios podem ser especificadas como fontes para a propagação e a repropagação de cópias de banco de dados.
As cópias de banco 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, recomendamos o uso de replicação de pasta pública. Ao contrário do CCR, no qual 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.

Vários conceitos de replicação contínua usados no Exchange 2007 também permanecem no Exchange 2010. Estão inclusos conceitos como gerenciamento de failover, divergência, o uso da discagem automática de montagem de banco de dados e o uso de redes públicas e privadas.

Alterações no comportamento de 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 de 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 pôr a mensagem no dumpster de transporte em um servidor de Transporte de Hub diferente.

Por exemplo, EX1 hospeda as funções 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 esteja 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á mais uma mudança de comportamento semelhante relacionada ao serviço de Envio de Email do Microsoft Exchange. Esse serviço foi modificado para não optar pelo envio de mensagens para uma função de Transporte de Hub local quando a Caixa de Correio e o Servidor de Transporte de Hub forem membros de um DAG. Nesse cenário, o comportamento do transporte é o de 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.

Disponibilidade de ponta a ponta

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

Resiliência de transporte
Caixa de correio de movimentação online
Proteção de dados nativa do Exchange
Ressincronização incremental
API de Replicação de Terceiros

Resiliência de Transporte

O Exchange 2007 introduziu o recurso de dumpster de transporte do servidor de Transporte de Hub. O dumpster de transporte mantém uma fila de mensagens entregues a destinatários cujas caixas de correio estavam em um ambiente CCR (e no Exchange 2007 SP1, em um LCR). Esse recurso foi desenvolvido para ajudar na proteção contra perda de dados ao fornecer ao administrador a opção de fazer com que um servidor de Caixa de Correio clusterizado fique online automaticamente em outro nó, com uma quantidade limitada de perda de dados. Isso é chamado de failover com perdas. Quando ocorria um failover com perdas, o sistema tornava a entregar automaticamente as mensagens de email recentes entregues a usuários no servidor de Caixa de Correio clusterizado que falhou, usando o dumpster de transporte onde as mensagens de email ainda estavam armazenadas. Embora essa solução ajudasse a minimizar a quantidade de dados perdidos em um failover com perdas, a solução protegia apenas contra a perda de dados em um site, e não oferecia proteção para mensagens em trânsito.

O Exchange 2010 apresenta alterações arquiteturais de núcleo que lidam com as duas coisas. Como os DAGs podem se estender por sites do Active Directory, é possível que um banco de dados de caixa de correio individual seja movido entre sites do Active Directory. Devido a essa mudança no design, a solicitação de reentrega do dumpster de transporte diante de um failover de banco de dados com perdas agora é emitido para servidores de Transporte de Hub tanto no site original quanto no site novo do banco de dados do Active Directory.

Outra alteração relevante no dumpster de transporte é que agora ele recebe feedback do pipeline de replicação. Quando mensagens no dumpster de transporte são replicadas para todas as cópias de banco de dados de caixa de correio, elas são removidas do dumpster de transporte. Isso garante que apenas dados não replicados sejam mantidos no dumpster de transporte.

Além do recurso de dumpster de transporte, 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 por 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 qualquer um dos próximos saltos falhar antes de relatar sucesso na entrega, a mensagem será reenviada para entrega para o próximo salto. Para mais informações sobre a redundância de sombra, consulte Noções Básicas Sobre Redundância de Sombra.

Caixa de Correio de movimentação online

O Exchange 2010 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 caixa de correio. Havia várias desvantagens em ter cmdlets executando a operação de movimentação:

As movimentações de caixas de correio geralmente levam horas para serem concluídas, e, durante a movimentação, os usuários não podem acessar suas caixas de correio.
Se a janela de comandos usada para executar o cmdlet Move-Mailbox fosse fechada, a movimentação era encerrada e tinha que ser reiniciada desde o começo.
O computador usado para realizar a movimentação participava na 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 novos cmdlets de solicitação de movimentação no Exchange 2010 podem ser usados para realizar 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. Para mais informações sobre a caixa de correio de movimentação online, consulte Noções Básicas Sobre Solicitações de Movimentação.

Proteção de dados nativa do Exchange

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

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 relevante no Exchange 2010 é que os bancos de dados não estão mais ligados fortemente 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, poderá usar essas cópias como seus backups. Para mais informações sobre essa estratégia, consulte Understanding Backup, Restore and Disaster Recovery.

Ressincronização Incremental

O Exchange 2007 introduziu os conceitos de resiliência de log perdido (LLR) e nova propagação incremental. A LLR é 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 LLR permite a montagem de um banco de dados de caixa de correio mesmo quando arquivos de log gerados recentemente estiverem indisponíveis. A LLR funciona atrasando gravações no banco de dados até que o número especificado de gerações de log tenha sido criado. A LLR atrasa atualizações recentes do arquivo de banco de dados por um período curto. A duração de tempo que as gravações são atrasadas depende da rapidez com que os logs estão sendo gerados.

Dica

A LLR é codificada para um arquivo de log para todos os bancos de dados de caixa de correio do Exchange 2010.

Uma nova propagação incremental 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 LLR. 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.

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

Após 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 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 do Microsoft Exchange

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

O Exchange 2010 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 em vez do recurso de replicação contínua integrado. Para informações sobre produtos de parceiros para o Exchange 2010, consulte o site de Parceiros do Exchange 2010. Se você for um parceiro procurando informações sobre a API de Replicação de Terceiros, entre em contato com seu representante Microsoft.

Recursos do Exchange Server 2007 cortados

Os seguintes recursos do Exchange 2007 e do Exchange 2007 SP1 não existem mais no Exchange 2010. Seus substitutos são indicados na tabela.

Recurso	Substituto
Replicação contínua em cluster (CCR)	Grupos de disponibilidade do banco de dados e cópias de banco de dados de caixa de correio
Replicação contínua em espera (SCR)	Grupos de disponibilidade do banco de dados e cópias de banco de dados de caixa de correio
Replicação contínua local (LCR)	Grupos de disponibilidade do banco de dados e cópias de banco de dados de caixa de correio
Clusters de cópia única (SCC)	Grupos de disponibilidade do banco de dados e cópias de banco de dados de caixa de correio; API síncrona de terceiros integrada para substituir a replicação de dados de terceiros usada no SCC
Servidores de Caixas de Correio clusterizados	Grupos de disponibilidade do banco de dados e cópias de banco de dados de caixa de correio
Grupos de armazenamento	Bancos de dados
Grupo de armazenamento de recuperação	Banco de dados de recuperação