Interrupções agendadas e não agendadas

 

Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Tópico modificado em: 2007-10-29

Interrupções agendadas e não agendadas são duas formas de interrupção em um ambiente de CCR (replicação contínua em cluster). Interrupções agendadas são iniciadas explicitamente pelo administrador para a recuperação de uma falha ou para a execução de uma operação de manutenção. Interrupções não agendadas referem-se a eventos inesperados que resultam na indisponibilidade de serviços, dados ou ambos. A CCR foi projetada para processar interrupções agendadas e não agendadas.

Interrupções agendadas

A CCR permite agendar uma interrupção estendida de sistema de um nó específico, sem uma interrupção estendida do servidor de caixas de correio em cluster (CMS). A funcionalidade de interrupção agendada da CCR é projetada para verificar se todos os dados do log do nó ativo foram copiados com êxito para o nó passivo. Como resultado, as interrupções agendadas nunca apresentam perda de dados, embora a replicação ocorra de forma assíncrona. As falhas e o failover resultante podem fazer com que os dados de log muito recentes fiquem indisponíveis para o nó passivo no momento em que ele é colocado online.

Em um ambiente de CCR, apenas um nó pode ser colocado offline de cada vez. Colocar mais de um nó offline resultará em uma interrupção no serviço. Em qualquer hora específica, o computador que está hospedando o compartilhamento de arquivos para o quorum de MNS (Conjunto de Nós Principais) com a testemunha de compartilhamento de arquivos ou o nó passivo do cluster de failover podem ser colocados offline para manutenção de hardware e software, atualizações e correções. Recomendamos que você nunca desative um nó sem antes verificar se ele está ativo ou hospedando recursos. Você pode determinar se ele está hospedando algum recurso usando o Administrador de Cluster. Você pode verificar o status do nó executando o cmdlet Get-ClusteredMailboxServerStatus no Shell de Gerenciamento do Exchange. Para obter mais informações sobre a exibição do status de um CMS, consulte Como exibir o status de um servidor de caixas de correio em cluster.

Dica

O suporte à interrupção agendada de CCR não está integrado ao processo de desligamento do Windows Server. Você deve mover o CMS para um nó diferente antes de desligar o nó ativo. Para obter etapas detalhadas que explicam como mover um CMS de um nó para outro, consulte Como mover um servidor de caixas de correio clusterizadas em um ambiente CCR.

Tarefas administrativas

Interrupções agendadas são iniciadas explicitamente pelo administrador para a recuperação de uma falha ou para a execução de uma operação de manutenção. Uma interrupção agendada permite ao sistema mover o CMS do nó ativo para o nó passivo (transformando o nó passivo no novo nó ativo) e montar os bancos de dados replicados e grupos de armazenamento. Depois de serem montados, os bancos de dados se tornam a origem de todas as atualizações subseqüentes para qualquer replicação adicional. As duas cópias alternam funções de replicação: uma cópia produz as alterações de banco de dados e a outra, recebe e aplica as alterações de banco de dados.

Como a CCR usa replicação assíncrona, a transição do CMS ativo de um nó do cluster para outro nó no cluster exige coordenação entre o cluster e o suporte à replicação. A CCR implementa essa coordenação. O administrador inicia uma interrupção agendada usando o cmdlet Move-ClusteredMailboxServer do Shell de Gerenciamento do Exchange.

Dica

Realizar essa operação resulta em uma breve interrupção do serviço. Além disso, os backups de qualquer grupo de armazenamento no CMS são interrompidos.

O cmdlet Move-ClusteredMailboxServer verifica se o nó passivo tem uma cópia válida e íntegra. Além disso, verifica se a cópia é relativamente atual. Se a cópia não for relativamente atual, a interrupção poderá ser estendida durante a conclusão da replicação. Se essas verificações forem bem-sucedidas, a transição será iniciada. Quando não há falhas durante a movimentação, a tarefa é concluída quando o CMS está em execução no nó selecionado e todos os bancos de dados estão montados. Podem ocorrer falhas durante esse processo que podem impedir a transição ou afetar se todos os bancos de dados são montados automaticamente. Se isso ocorrer, o comportamento de interrupções não agendadas é empregado.

Em algumas condições, as interrupções agendadas são usadas para recuperar servidores com falhas parciais. Um exemplo é um servidor com banco de dados ou arquivos de log danificados. Nesse caso, a lógica de enviar logs através do sistema de replicação bloqueia o cmdlet Move-ClusteredMailboxServer. O administrador tem uma opção simples para gerenciar essa situação. O administrador desmonta os bancos de dados problemáticos e emite o comando Move-ClusteredMailboxServer com uma opção que tenta copiar os logs associados a bancos de dados desmontados, mas não apresenta falhas na movimentação se todos os logs não puderem ser copiados. O resultado é que a recuperação, mesmo de um grupo de armazenamento danificado, é realizada facilmente com o cmdlet Move-ClusteredMailboxServer.

O cmdlet Move-ClusteredMailboxServer permite que um administrador registre o motivo do início da movimentação. Esse motivo é colocado no log de eventos. O comando também força o administrador a especificar o nó que hospedará o CMS. Isso impede que administradores movam erroneamente o CMS quando ele já estiver corretamente hospedado.

A interface de gerenciamento de linha de comando do Cluster.exe e a GUI (interface gráfica do usuário) do Administrador de Cluster incluem o recurso de movimentação de um CMS. O uso desses métodos aciona a lógica de liberação da replicação. Entretanto, recomendamos não usar esses métodos pelos seguintes motivos:

• Esses métodos não validam a integridade ou o estado da cópia passiva. Portanto, seu uso pode resultar em uma interrupção estendida enquanto o nó executa as operações necessárias para tornar o banco de dados montável.

• Esses métodos também podem deixar o banco de dados indefinidamente offline porque a replicação está em uma condição de interrupção.

Restaurando a atividade de replicação após uma interrupção agendada

O processo para restaurar um ambiente de CCR após uma interrupção agendada de um nó ativo é reiniciar o nó. A replicação é automaticamente iniciada na inicialização do sistema. Existem dois casos a serem considerados:

• A interrupção agendada foi totalmente bem-sucedida, não apresentando falhas durante a transição associada à interrupção agendada e todos os bancos de dados voltaram a ficar online automaticamente. Neste caso, o administrador executou a interrupção agendada de modo a verificar que ambos os nós tinham grupos de armazenamento e bancos de dados consistentes. O resultado é que o nó pode aparecer e continuar imediatamente a replicação. A cópia pode ser tornada atual por meio da repetição de logs. Nenhuma ação especial é necessária.

• A interrupção agendada foi apenas parcialmente bem-sucedida ou alguns dados foram corrompidos antes da interrupção agendada. Neste caso, a interrupção agendada não conseguiu verificar se todos os logs na origem foram disponibilizados para o destino para que ela montasse os bancos de dados correspondentes. Em geral, esta situação ocorre como resultado de uma falha antes da interrupção agendada ou posteriormente na operação de interrupção agendada. Portanto, não há consistência entre os bancos de dados de origem e de destino. Em alguns casos, a CCR pode se recuperar automaticamente de algumas inconsistências. Se esse for o caso, a replicação será iniciada e processará os logs disponíveis. Se a replicação não puder se recuperar automaticamente, marcará a cópia como quebrada e gerará um evento indicando o problema. Presumindo que o armazenamento seja viável, a ação de recuperação primária será propagar novamente a cópia. Para obter mais informações sobre o procedimento para corrigir esses problemas, consulte Como propagar uma cópia de Replicação Contínua em Cluster.

Interrupções não agendadas

Interrupções não agendadas ocorrem como uma resposta automática do sistema a alguns tipos de falha. A CCR concentra a recuperação automática nessas falhas, nas quais há um alto grau de confiança de que a disponibilidade será melhorada e que a maioria dos ambientes desejaria uma recuperação automática.

Uma interrupção não agendada permite que o sistema ative o servidor de Caixa de Correio no nó passivo, tornando-o ativo, e monte os bancos de dados e os grupos de armazenamento replicados. Depois de serem montados, os bancos de dados se tornam a origem de todas as atualizações subseqüentes para qualquer replicação adicional. As duas cópias alternam funções de replicação: uma cópia produz as alterações de banco de dados e a outra, recebe e aplica as alterações de banco de dados.

Como a CCR usa replicação assíncrona, uma interrupção não agendada significa que ocorrerá alguma perda de dados. No mínimo, os logs que estão sendo ativamente gravados pelo servidor ativo não estarão disponíveis para as atividades de recuperação. A CCR trata esse problema fornecendo controle administrativo do comportamento do failover e fornecendo um recurso para ajudar a recuperar a massa dos dados que provavelmente seriam afetados.

Quando ocorre uma falha, a CCR sempre ativa o servidor de Caixa de Correio no nó passivo restante. Os controles do sistema estão associados à montagem dos bancos de dados nesse nó agora ativo. A CCR fornece controles administrativos para determinar se os bancos de dados serão montados. A posição padrão é Best availability Nessa posição, o sistema monta automaticamente todos os bancos de dados que estão sincronizados com o banco de dados de produção anteriormente ativo. Best availability permite mais variações na inconsistência entre as duas cópias. O valor Good availability colocará um banco de dados online, se durante o tempo necessário para gerar um novo log o último log gerado for replicado. Lossless garante que a cópia não seja colocada online a menos que possa ser confirmado que não haverá perda de dados. Se a opção Lossless for usada, ocorrerá a recuperação automática quando o servidor original estiver novamente operacional e todos os dados de log estiverem disponíveis e não danificados.

Dica

O uso da configuração Lossless pode resultar em interrupções estendidas. Os Administradores podem usar a configuração Lossless e tomar uma decisão explícita sobre montar bancos de dados ou não. A configuração Lossless pode facilmente resultar em interrupções estendidas durante uma falha.

Se um ou mais bancos de dados estiverem em uma condição em que a configuração não os monta automaticamente, mesmo assim o administrador pode decidir explicitamente montar a cópia com o conteúdo disponível. O administrador deve verificar o estado da cópia e depois emitir dois comandos. O primeiro comando informa o mecanismo de replicação que essa cópia deve ser feita para ser uma origem de replicação (origem de alterações), isto é, a cópia deve ser montável. O segundo comando monta o banco de dados.

Para obter informações adicionais sobre a recuperação de danos ou falhas quando a CCR está habilitada, consulte Gerenciando a Replicação Contínua em Cluster.

Controles administrativos

Controles administrativos são fornecidos para controlar o comportamento no caso de uma interrupção não agendada. A CCR fornece um atributo para servidores de Caixa de Correio que podem ser usados para controlar o comportamento de recuperação de interrupção não agendada. O atributo AutoDatabaseMountDial apresenta três valores possíveis: Lossless, Good availability e Best availability.

• Lossless   Lossless significa zero logs perdidos. Quando o atributo é definido como Lossless, na maioria das circunstâncias o sistema aguarda que o nó com falha volte a ficar online antes que os bancos de dados sejam montados. Mesmo então, o sistema que falhou deve retornar com todos os logs acessíveis e não danificados. Após a falha, o nó passivo é ativado e o serviço de Armazenamento de Informações do Microsoft Exchange é colocado online. Ele faz verificações para determinar se os bancos de dados podem ser montados sem perda de dados. Se puderem, os bancos de dados serão montados. Se não, o sistema tentará periodicamente copiar os logs. Se o servidor retornar com os logs intactos, essa tentativa será bem-sucedida e os bancos de dados serão montados. Se o servidor retornar sem os logs intactos, os logs restantes não estarão disponíveis e os banco de dados afetados não serão montados.

  Dica

  A qualquer momento após a conclusão do failover, um administrador pode interceder e decidir montar usando os bancos de dados e logs disponíveis no nó anteriormente passivo. Essa tarefa é realizada usando um processo simples com duas etapas. Presume-se que o administrador que decidiu interceder o faz com base em uma análise do tempo necessário para tornar o servidor original operacional. A consistência da replicação entre os dois nós no momento da falha e a urgência dos clientes para acessar o servidor são alguns fatores que fazem parte dessa análise.

• Good availability   Good availability significa três logs perdidos. O valor Good availiability fornece uma recuperação totalmente automática quando a replicação está operando normalmente e replicando logs à medida que são gerados.

• Best availability   Best availability significa seis logs perdidos, que é a configuração padrão. O valor Best availability opera de forma semelhante ao Good availability, mas permite a recuperação automática quando a replicação apresentar um pouco mais de latência. Assim, o novo nó ativo pode estar ligeiramente atrasado em relação ao antigo nó ativo depois do failover, aumentando assim a probabilidade da divergência do banco de dados ocorrer, o que exige uma nova propagação completa para correção.

Para obter mais informações sobre o comportamento de gerenciamento de interrupções, consulte Como ajustar o failover e montar configurações para Replicação Contínua em Cluster.