Compartilhar via

Nova funcionalidade de alta disponibilidade e resiliência de site no Exchange 2010 SP1

  • Artigo

 

Aplica-se a: Exchange Server 2010 SP1

Tópico modificado em: 2015-03-09

O Microsoft Exchange Server 2010 Service Pack 1 (SP1) inclui novos recursos, bem como novas melhorias nos recursos que foram introduzidas na RTM (versão do fabricante) do Exchange 2010. Os recursos novos e aprimorados estendem os cenários nos quais é possível obter dados e disponibilidade de serviço para o ambiente do Exchange 2010.

Veja a seguir os novos recursos de alta disponibilidade e aprimoramentos dos recursos já existentes que estão disponíveis no Exchange 2010 SP1:

  • Replicação contínua - modo de bloqueio

  • Redistribuição de banco de dados ativo de caixa de correio

  • Suporte aprimorado ao modo de coordenação de ativação de datacenter

  • Novos e Aprimorados Scripts de Gerenciamento e Monitoramento

  • Melhorias na interface do usuário do Console de Gerenciamento do Exchange

  • Melhorias no desempenho do failover

  • Recuperação de mecanismo de armazenamento extensível em E/S parada

Esses recursos serão discutidos mais detalhadamente a seguir.

Replicação Contínua - Modo de Bloqueio

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 Exchange 2010 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 estiver cheio, cada cópia do banco de dados desenvolve, 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.

Replicação contínua - o modo de bloqueio está ativo apenas quando a replicação contínua for atualizada no modo de arquivo. A transição de entrada e saída do modo de bloqueio é executada automaticamente pelo copiador de log. O modo de bloqueio reduz drasticamente 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 para 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.

Redistribuição de banco de dados ativo de caixa de correio

O Exchange 2010 SP1 inclui um script chamado RedistributeActiveDatabases.ps1 que pode ser periodicamente executado por administradores para equilibrar a distribuição de cópias de bancos de dados ativos em um DAG (grupo de disponibilidade de banco de dados) com base na preferência de ativação configurada pelo administrador. Além disso, o reconhecimento de distribuição de cópia foi adicionado ao melhor processo de seleção de cópia do Active Manager. Especificamente, a primeira passagem da melhor seleção de cópias para alternâncias sem perdas agora classifica os alvos possíveis por preferência ao invés de menos perda.

Suporte Aprimorado ao Modo de Coordenação de Ativação de Datacenter

O Exchange 2010 RTM inclui um modo de configuração para suporte à resiliência de site de DAG chamado modo Coordenação de Ativação de Datacenter (DAC). No modo DAC, os cmdlets do Exchange podem ser usados para executar uma alternância de datacenter. Na versão RTM, o modo DAC é limitado a DAGs com pelo menos três membros que possuem pelo menos dois ou mais membros no datacenter principal.

No Exchange 2010 SP1, o modo DAC foi estendido para suportar DAGs de dois membros que possuem cada um de seus membros em um datacenter distinto. O suporte ao modo DAC para DAGs de dois membros usa o servidor testemunha para oferecer uma arbitragem adicional. Além disso, o modo DAC foi estendido para suportar DAGs que possuem todos os membros implantados em um site único do Active Directory, incluindo sites únicos do Active Directory que tenham sido estendidos para locais múltiplos.

Novos e Aprimorados Scripts de Gerenciamento e Monitoramento

O Exchange 2010 SP1 inclui diversos scripts novos e aprimorados que melhoram grandemente a experiência de monitoramento e gerenciamento:

  • CheckDatabaseRedundancy.ps1 (novo)   É possível usar este script para verificar a redundância de bancos de dados replicados; o script irá gerar eventos caso a resiliência do banco de dados se encontre em um estado comprometedor (por exemplo, há apenas uma cópia íntegra de um banco de dados replicado). O script é acompanhado por uma alteração do pacote de gerenciamento do Microsoft System Center Operations Manager 2007 que pode ser usada para monitorar bancos de dados sem redundância, o que é particularmente útil em ambientes sem RAID.

  • StartDagServerMaintenance.ps1 e StopDagServerMaintenance.ps1 (novo)   É possível usar o StartDagServerMaintenance.ps1 para desativar um membro do DAG para manutenção. O script fará a retirada de bancos de dados ativos do servidor e bloquear bancos de dados para que não se movam para aquele servidor. Ele se certificará ainda de que todas as funcionalidades críticas de suporte a DAG (por exemplo, a função Active Manager Principal, PAM) que podem estar no servidor sejam movidas para outro servidor e bloqueadas para que não voltem para o servidor. Outro script, o StopDagServerMaintenance.ps1, é fornecido para completar a operação e remover os bloqueios.

  • CollectOverMetrics.ps1 (aprimorado)   Você pode usar este script para coletar dados de alternância e failover. Este script foi aprimorado no Exchange 2010 SP1 para incluir métricas de replicação contínua - modo de bloqueio e mais detalhes do pipeline de replicação e de repetição. Além disso, ele também apresenta relatórios aprimorados.

  • CollectReplicationMetrics.ps1 (aprimorado)   Este script é uma forma ativa de monitoramento, pois coleta métricas relacionadas à replicação contínua em tempo real, enquanto o script é executado. O script suporta parâmetros que permitem que você personalize seu comportamento e sua saída.

Interface do Usuário do Console de Gerenciamento do Exchange Aprimorada

O Exchange 2010 SP1 inclui melhorias do Console de Gerenciamento do Exchange (EMC) para gerenciamento de DAGs. Por exemplo, o EMC agora inclui suporte para gerenciamento de endereços IP e definições do servidor testemunha alternativo para DAGs. Não é mais necessário usar o Shell de Gerenciamento do Exchange para configurar essas definições.

Desempenho Aprimorado de Failover

O Exchange 2010 SP1 inclui alterações para aprimorar o comportamento e o desempenho de failover e alternância. Na versão RTM do Exchange 2010, quando ocorre um failover ou uma alternância, a cópia passiva que está sendo ativada para imediatamente de repetir os arquivos de log que foram copiados para aquela cópia passiva. A cópia ativa é então desmontada (se já não estiver) e qualquer arquivo de logo restante é copiado para a cópia passiva que está sendo ativada. Supondo que quaisquer dados ausentes estejam na configuração da discagem automática da montagem do banco de dados, a cópia passiva torna-se a nova cópia ativa e o banco de dados é montado em um estado de desligamento anormal. Nesse ponto, todos os arquivos de log que foram copiados para a cópia anteriormente passiva (e agora ativa) serão repetidos para tornar o banco de dados consistente.

No Exchange 2010 SP1, quando ocorre um failover ou uma alternância, o serviço de Replicação do Microsoft Exchange na cópia passiva que está sendo ativada continua a repetir arquivos de log que foram copiados para a cópia passiva até que o último arquivo de log gerado pela cópia ativa seja copiado para ela. Isso permite que uma operação de montagem seja executada em um banco de dados que esteja em um estado quase consistente.

Outras alterações de melhoria do desempenho envolvem tempos-limite e outros detalhes de algoritmos para melhorar o desempenho de failover além do desempenho de E/S pós-failover.

Recuperação de mecanismo de armazenamento extensível em E/S parada

O Exchange 2010 SP1 inclui nova lógica de recuperação que utiliza o comportamento de verificação de bug incorporado do Windows quando certas condições ocorrem. Especificamente, o mecanismo de armazenamento extensível (ESE) foi atualizado para detectar quando a E/S está parada e para tomar ação corretiva para recuperar o servidor automaticamente. O ESE mantém um thread de monitoramento de E/S que detecta quando uma E/S esteve pendente por um período de tempo específico. Por padrão, se uma E/S de um banco de dados estiver pendente por mais de um minuto, o ESE registrará um evento Se um banco de dados mostra uma E/S pendente por mais de 4 minutos, o ESE registrará um evento de falha específico, se for possível. Evento ESE 507, 508, 509 ou 510 pode ou não estar registrado, dependendo da natureza da E/S parada. Se o problema for tal que o volume do sistema operacional seja afetado ou a habilidade de gravar o log de evento seja afetada, os eventos não serão registrados. Se os eventos forem registrados, o serviço do Microsoft Exchange Replication (MSExchangeRepl.exe) irá intencionalmente encerrar o processo wininit.exe para causar uma verificação de bug do Windows.

Em alguns casos, a pilha inteira de armazenamento pode ser afetada pelo travamento, tornando impossível gravar eventos de falha no canal crimson ou em qualquer área do log de eventos do Windows. O ESE também monitora o canal de crimes verificando que o log de evento pode ser escrito. Se a gravação do log de evento falhar por um longo período de tempo, o MSExchangeRepl intencionalmente causará uma verificação de bug do Windows ao finalizar o processo wininit.exe. Quando a E/S do sistema operacional estiver parada, o sistema obviamente fica inapto a gravar qualquer evento ESE no log de eventos.

Dica

Logs de Aplicativos e Serviços são uma categoria nova de logs de eventos no Windows Server 2008. Estes logs armazenam eventos de um único aplicativo ou componente, ao invés de eventos que possam ter impacto em todo o sistema. Esta nova categoria de logs de eventos é referenciada como um canal crimson do aplicativo. Para mais informações, consulte Monitorando a alta disponibilidade e resiliência do site.

Esse recurso de recuperação baseado em verificação de bug no Exchange 2010 SP1 foi projetado para realizar a recuperação da E/S parada ou de um controlador parado rapidamente, em vez de tentar novamente ou esperar até que a pilha de armazenamento apresente um erro que cause failover. Quando a verificação de erro ocorre, o código de erro lê da seguinte forma:

CRITICAL_OBJECT_TERMINATION (f4)

Um processo ou thread crucial para a operação do sistema fechou inesperadamente ou foi finalizado.

Aviso

A presença desse código de erro de verificação de bug não significa necessariamente que a causa foi o Exchange. Qualquer finalização do wininit.exe, incluindo aquela executada por administrador usando o Gerenciador de Tarefas ou outra ferramenta de gerenciamento de tarefa irá causar o mesmo código de erro de verificação de bug.

 © 2010 Microsoft Corporation. Todos os direitos reservados.