Monitorando a alta disponibilidade e resiliência do site
Aplica-se a: Exchange Server 2010
Tópico modificado em: 2010-01-11
Garantir que seus servidores estejam operando confiavelmente e que suas cópias de bancos de dados sejam íntegras são os principais objetivos das operações diárias de mensagens. Para ajudar a garantir a disponibilidade e a confiabilidade da sua organização do Microsoft Exchange Server 2010, você deve monitorar ativamente o hardware, o sistema operacional Windows e os serviços do Exchange 2010. Monitoramento proativo combinado com manutenção preventiva pode ajudá-lo a identificar possíveis erros antes que um problema sério interfira na operação da sua organização do Exchange.
Monitorar sua organização do Exchange envolve verificação regular em busca de problemas com os serviços ou dados. O monitoramento normalmente também inclui um sistema de notificação que envia alertas quando problemas ocorrem. O Windows Server 2008 e o Exchange 2010 incluem várias ferramentas e serviços para ajudar a garantir que sua organização do Exchange esteja funcionando sem problemas. As principais vantagens do monitoramento diário são:
- Atender aos requisitos dos seus SLAs (acordos de nível de serviço)
- Garantir a conclusão bem sucedida de tarefas administrativas específicas, como operações diárias de backup
- Detectar e endereçar problemas, como aqueles que podem afetar o serviço de mensagens ou a disponibilidade dos dados
Dentro de uma organização do Exchange 2010, os procedimentos, regras e responsabilidades envolvidos nas operações devem ser formalizados. É importante entender a conexão entre práticas e procedimentos operacionais benéficos e uma infraestrutura íntegra. Os processos e procedimentos operacionais completos e bem documentados ajudam a garantir que todos os componentes no ambiente de uma organização do qual o Exchange depende sejam gerenciados de forma eficiente e efetiva.
O Exchange 2010 inclui várias ferramentas e recursos internos que podem ser usados como parte do monitoramento proativo regular quando o Exchange está configurado para alta disponibilidade ou resiliência do site. Os principais cmdlets de monitoramento para alta disponibilidade e resiliência do site são Get-MailboxDatabaseCopyStatus e Test-ReplicationHealth. Além de fornecer cmdlets que podem executar funções de monitoramento e reportar status, o Exchange 2010 também destaca um novo fluxo de log de eventos que aproveita as funcionalidades do canal crimson no Windows Server, e scripts internos que podem coletar dados destes canais de eventos.
Você pode usar os detalhes deste tópico para monitorar a integridade e o status de cópias de bancos de dados de caixa de correio para grupos de disponibilidade de banco de dados (DAGs). Para informações gerais sobre o monitoramento do Exchange 2010, consulte Monitorando o Exchange 2010.
Sumário
Cmdlet Get-MailboxDatabaseCopyStatus
Cmdlet Test-ReplicationHealth
Log de Eventos do Canal Crimson
Script CollectOverMetrics.ps1
Script CollectReplicationMetrics.ps1
Cmdlet Get-MailboxDatabaseCopyStatus
Você pode usar o cmdlet Get-MailboxDatabaseCopyStatus para visualizar informações de status sobre cópias de bancos de dados de caixa de correio. Este cmdlet permite que você visualize informações sobre todas as cópias de um banco de dados em particular, informações sobre uma cópia específica de um banco de dados em um servidor específico, ou informações sobre todas as cópias de bancos de dados em um servidor. A tabela a seguir descreve os valores possíveis para o status de cópia de uma cópia de banco de dados de caixa de correio.
Status da cópia do banco de dados
| Status da cópia do banco de dados | Descrição |
|---|---|
Falha |
A cópia do banco de dados de caixa de correio está no estado de Falha porque não está suspensa, e ainda não pode copiar ou reproduzir arquivos de log. Enquanto estiver no estado de Falha e não estiver suspensa, o sistema verificará periodicamente se o problema que causou a alteração do status da cópia para Falha foi resolvido. Depois de o sistema detectar que o problema está resolvido, e de não encontrar outros problemas, o status da cópia automaticamente será alterado para Íntegra. |
Propagação |
A cópia do banco de dados de caixa de correio está sendo propagada, o índice de conteúdo para a cópia do banco de dados de caixa de correio está sendo propagado, ou ambos estão sendo propagados. Depois da conclusão bem-sucedida da propagação, o status de cópia deve mudar para Inicializando. |
SeedingSource |
A cópia do banco de dados de caixa do correio está sendo usada como uma fonte de uma operação de propagação de cópia de banco de dados. |
Suspensa |
A cópia do banco de dados de caixa de correio está no estado Suspensa como resultado de um administrador ter suspendido manualmente a cópia do banco de dados, executando o cmdlet Suspend-MailboxDatabaseCopy. |
Íntegra |
A cópia do banco de dados de caixa de correio está copiando e reproduzindo arquivos de log com sucesso, ou copiou e reproduziu com sucesso todos os arquivos de log disponíveis. |
ServiceDown |
O serviço de Replicação do Microsoft Exchange está indisponível ou está sendo executado no servidor que hospeda a cópia do banco de dados de caixa de correio. |
Inicializando |
A cópia do banco de dados de caixa de correio estará no estado Inicializando quando uma cópia de banco de dados for criada, quando o serviço de Replicação do Microsoft Exchange estiver iniciando ou tiver iniciado recentemente e durante as transições de Suspensa, ServiceDown, Falha, Propagação, SinglePageRestore, LostWrite, ou Desconectada para outro estado. Neste estado, o sistema está verificando se o banco de dados e o fluxo de log estão em um estado consistente. Na maioria dos casos, o status da cópia permanecerá no estado Inicializando por aproximadamente 15 segundos, mas em todos os casos geralmente não deve ficar neste estado por mais de 30 segundos. |
Ressincronizando |
A cópia do banco de dados de caixa de correio e seus arquivos de log estão sendo comparados com a cópia ativa do banco de dados para verificar se há divergência entre as duas cópias. O status da cópia permanecerá neste estado até que alguma divergência seja detectada e resolvida. |
Montada |
A cópia ativa está online e aceitando conexões de clientes. Apenas a cópia ativa da cópia do banco de dados de caixa de correio pode ter o status de cópia Montada. |
Desmontada |
A cópia ativa está offline e não aceita conexões de clientes. Apenas a cópia ativa da cópia do banco de dados de caixa de correio pode ter o status de cópia Desmontada. |
Montando |
A cópia ativa está sendo colocada online e ainda não aceita conexões de clientes. Apenas a cópia ativa da cópia do banco de dados de caixa de correio pode ter o status de cópia Montando. |
Desmontando |
A cópia ativa está sendo colocada offline e está encerrando as conexões de clientes. Apenas a cópia ativa da cópia do banco de dados de caixa de correio pode ter o status de cópia Desmontando. |
DesconectadaEÍntegra |
A cópia do banco de dados de caixa de correio não está mais conectada à cópia ativa do banco de dados e estava no estado Íntegra quando a perda da conexão aconteceu. Este estado representa a cópia do banco de dados em relação à conectividade com sua cópia de banco de dados de origem. Pode ser informado durante falhas de rede do DAG entre a cópia de origem e a cópia de banco de dados de destino. |
DesconectadaERessincronizando |
A cópia do banco de dados de caixa de correio não está mais conectada à cópia ativa do banco de dados e estava no estado Ressincronizando quando a perda da conexão aconteceu. Este estado representa a cópia do banco de dados em relação à conectividade com sua cópia de banco de dados de origem. Pode ser informado durante falhas de rede do DAG entre a cópia de origem e a cópia de banco de dados de destino. |
FalhaESuspensa |
Os estados Falha e Suspensa foram definidos simultaneamente pelo sistema porque uma falha foi detectada, e porque a resolução da falha explicitamente exige a intervenção do administrador. Um exemplo é se o sistema detectar divergências irreversíveis entre o banco de dados de caixa de correio ativo e a cópia do banco de dados. Diferente do estado Falha, o sistema não verificará periodicamente se o problema foi resolvido e não recuperará automaticamente. Ao invés disso, um administrador deve intervir para resolver a causa da falha subjacente antes que a cópia do banco de dados possa passar para um estado de integridade. |
AtivaçãoSuspensa |
A cópia do banco de dados de caixa de correio foi bloqueada manualmente para ativação por um administrador. |
SinglePageRestore |
Este estado indica que uma operação de restauração de página única está ocorrendo na cópia do banco de dados de caixa de correio. |
O cmdlet Get-MailboxDatabaseCopyStatus também inclui um parâmetro chamado ConnectionStatus, que retorna detalhes sobre as redes de replicação em uso. Se este parâmetro for utilizado, dois campos de saída adicionais, IncomingLogCopyingNetwork e SeedingNetwork, serão preenchidos na saída da tarefa.
Exemplos de Get-MailboxDatabaseCopyStatus
Os exemplos seguintes usam o cmdlet Get-MailboxDatabaseCopyStatus. Cada exemplo redireciona os resultados para o cmdlet Format-List para exibir a saída em formato de lista.
Este exemplo retorna informações de status para todas as cópias do banco de dados DB2.
Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List
Este exemplo retorna o status para todas as cópias de banco de dados no servidor de Caixa de Correio MBX2.
Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List
Este exemplo retorna o status para todas as cópias de banco de dados no servidor de Caixa de Correio local.
Get-MailboxDatabaseCopyStatus -Local | Format-List
Este exemplo retorna as informações de status, envio de logs e rede de propagação para o banco de dados DB3 no servidor de Caixa de Correio MBX1.
Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List
Para mais informações sobre o uso do cmdlet Get-MailboxDatabaseCopyStatus, consulte Get-MailboxDatabaseCopyStatus.
Retornar ao início
Cmdlet Test-ReplicationHealth
Você pode usar o cmdlet Test-ReplicationHealth para visualizar informações de status da replicação contínua sobre cópias de bancos de dados de caixa de correio. Este cmdlet pode ser usado para verificar todos os aspectos do status da replicação e da reprodução para fornecer uma visão geral completa de um servidor de Caixa de Correio em um DAG.
O cmdlet Test-ReplicationHealth é projetado para o monitoramento proativo da replicação contínua e do pipeline de replicação contínua, da disponibilidade do Active Manager e da integridade e status do serviço de cluster, quorum e componentes de rede subjacentes. Pode ser executado local ou remotamente em qualquer servidor de Caixa de Correio em um DAG. O cmdlet Test-ReplicationHealth executa os testes descritos na tabela a seguir.
Testes do cmdlet Test-ReplicationHealth
| Nome do teste | Descrição |
|---|---|
ClusterService |
Verifica se o serviço de Cluster está em execução e acessível no membro do DAG especificado ou, se nenhum membro do DAG estiver especificado, no servidor local. |
ReplayService |
Verifica se o serviço de Replicação do Microsoft Exchange está em execução e acessível no membro do DAG especificado ou, se nenhum membro do DAG estiver especificado, no servidor local. |
ActiveManager |
Verifica se a instância do Active Manager em execução no membro especificado do DAG (ou, se nenhum membro do DAG estiver especificado, no servidor local) está em uma função válida (primária, secundária ou autônoma). |
TasksRpcListener |
Verifica se o servidor de tarefas de chamada de procedimento remoto (RPC) está em execução e acessível no membro do DAG especificado ou, se nenhum membro do DAG estiver especificado, no servidor local. |
TcpListener |
Verifica se o ouvinte da cópia do log do TCP está em execução e acessível no membro do DAG especificado ou, se nenhum membro do DAG estiver especificado, no servidor local. |
DagMembersUp |
Verifica se todos os membros do DAG estão disponíveis, em execução e acessíveis. |
ClusterNetwork |
Verifica se todas as redes gerenciadas por cluster no membro do DAG especificado (ou, se nenhum membro do DAG estiver especificado, no servidor local) estão disponíveis. |
QuorumGroup |
Verifica se o grupo de cluster padrão (grupo de quorum) está em um estado íntegro e online. |
FileShareQuorum |
Verifica se o servidor testemunha e o diretório testemunha e o compartilhamento configurado para DAG estão acessíveis. |
DBCopySuspended |
Verifica se alguma cópia de banco de dados de caixa de correio está no estado Suspensa no membro do DAG especificado ou, se nenhum membro do DAG estiver especificado, no servidor local. |
DBCopyFailed |
Verifica se alguma cópia de banco de dados de caixa de correio está no estado Falha no membro do DAG especificado ou, se nenhum membro do DAG estiver especificado, no servidor local. |
DBInitializing |
Verifica se alguma cópia de banco de dados de caixa de correio está no estado Inicializando no membro do DAG especificado ou, se nenhum membro do DAG estiver especificado, no servidor local. |
DBDisconnected |
Verifica se alguma cópia de banco de dados de caixa de correio está no estado Desconectada no membro do DAG especificado ou, se nenhum membro do DAG estiver especificado, no servidor local. |
DBLogCopyKeepingUp |
Verifica se a cópia e inspeção de log pelas cópias passivas de bancos de dados no membro do DAG especificado (ou, se nenhum membro do DAG estiver especificado, no servidor local) estão aptas para prosseguir com a atividade de geração de log na cópia ativa. |
DBLogReplayKeepingUp |
Verifica se a atividade de reprodução para as cópias passivas de bancos de dados no membro do DAG especificado (ou, se nenhum membro do DAG estiver especificado, no servidor local) está apta para prosseguir com a atividade de cópia e inspeção de log. |
Exemplo de Test-ReplicationHealth
Este exemplo usa o cmdlet Test-ReplicationHealth para testar a integridade da replicação para o servidor de Caixa de Correio MBX1.
Test-ReplicationHealth -Identity MBX1
Retornar ao início
Log de Eventos do Canal Crimson
O Windows Server 2008 inclui duas categorias de logs de eventos: Logs do Windows e logs de Aplicativos e Serviços. A categoria de logs do Windows inclui os logs de eventos disponíveis nas versões anteriores do Windows: Logs de eventos de Aplicativo, Segurança e Sistema. Também inclui dois novos logs: o log de Instalação e log ForwardedEvents. Logs do Windows têm por objetivo armazenar eventos de aplicativos e eventos herdados que se aplicam a todo o sistema.
Logs de Aplicativos e Serviços são uma categoria nova de logs de eventos. 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.
A categoria de logs de Aplicativos e Serviços inclui quatro subtipos: Logs Admin, Operacional, Analítico e Depuração. Os eventos nos logs Admin são de particular interesse se você usa os registros do log de eventos para solucionar problemas. Os eventos no log Admin devem fornecer orientação sobre como responder aos eventos. Os eventos no log Operacional também são úteis, mas podem exigir mais interpretação. Os logs Admin e Depuração não são tão amigáveis. Os logs Analíticos (que por padrão estão ocultos e desabilitados) armazenam eventos que rastreiam um problema, e geralmente um alto volume de eventos é registrada. Logs de Depuração são usados por desenvolvedores quando depuram aplicativos.
O Exchange 2010 registra eventos no canal crimson na área de logs de Aplicativos e Serviços. Você pode exibir esses canais executando estas etapas:
- Abra o Visualizador de Eventos.
- Na árvore do console, navegue até Logs de Aplicativos e Serviços > Microsoft > Exchange.
- Em Exchange, selecione um canal crimson: HighAvailability ou MailboxDatabaseFailureItems.
O canal HighAvailability contém eventos relacionados à inicialização e desligamento do serviço de Replicação do Microsoft Exchange, e os vários componentes executados dentro do serviço de Replicação do Microsoft Exchange, como o Active Manager, a API da replicação síncrona de terceiros, o servidor de tarefas RPC, o ouvinte de TCP e o gravador do Serviço de Cópias de Sombra de Volume (VSS). O canal HighAvailability também é usado pelo Active Manager para registrar eventos relacionados ao monitoramento de funções do Active Manager e eventos de ação de banco de dados, como uma operação de montagem de banco de dados e truncamento de log, e para registrar eventos relacionados ao cluster subjacente do DAG.
O canal MailboxDatabaseFailureItems é usado para registrar eventos associados a qualquer falha que afete um banco de dados de caixa de correio replicado.
Retornar ao início
Script CollectOverMetrics.ps1
O Exchange 2010 inclui um script chamado CollectOverMetrics.ps1, que pode ser encontrado na pasta Scripts. Este é um script de fluxo de trabalho que coleta informações sobre várias estatísticas relacionadas a alternância e failover. O uso do script CollectOverMetrics.ps1 é uma forma passiva de monitoramento. O script coleta e analisa eventos que já foram registrados. O script suporta parâmetros que permitem que você personalize seu comportamento e saída. Os parâmetros disponíveis estão listados na tabela a seguir.
Parâmetros do script CollectOverMetrics.ps1
| Parâmetro | Descrição |
|---|---|
DatabaseAvailabilityGroup |
Especifica o nome do DAG do qual você deseja coletar métricas. Se este parâmetro for omitido, o DAG do qual o servidor local é membro será usado. |
Banco de Dados |
Fornece uma lista de bancos de dados para os quais o relatório precisa ser gerado. Há suporte para caracteres curinga, por exemplo, |
TemporaryDataPath |
Especifica o local para armazenar arquivos temporários. Se este parâmetro for omitido, o nome do diretório será: %SystemDrive%\Temp\CollectOverMetrics\<ScriptStartTime> |
StartTime |
Especifica a hora em que os dados de evento começarão a ser coletados. Se este parâmetro for omitido, o início será 00:00 (meia-noite) de ontem. |
EndTime |
Especifica a hora em que a coleta dos dados de evento será interrompida. Se este parâmetro for omitido, os eventos serão coletados até 23:59 de ontem. |
ReportPath |
Especifica a pasta usada para armazenar os resultados do processamento de eventos. Se este parâmetro for omitido, a pasta Scripts será usada. |
ReportAlias |
Especifica o alias do email ao qual o relatório deve ser enviado. |
IncludeAppLogs |
Especifica se os eventos no log de eventos de Aplicativo também devem ser coletados, mesclados e processados. Por padrão, os provedores a seguir serão incluídos: MSExchangeIS, MSExchangeIS Mailbox Store, e MSExchangeRepl. |
AppLogProviders |
Especifica se eventos de log específicos de eventos de Aplicativo devem ser coletados. Se este parâmetro for especificado, os fornecedores listados para IncludeAppLogs não serão incluídos, e será preciso especificá-los explicitamente usando o parâmetro AppLogProviders. |
AnalyzeOnly |
Especifica se os dados já foram coletados e se o processamento único é requerido. |
MergedXmlFile |
Especifica o nome do arquivo XML no qual os registros de log de eventos coletados serão mesclados. |
GenerateHtmlReport |
Especifica se o relatório deve ser emitido no formado de tabela HTML simples para facilitar a visualização. |
ShowHtmlReport |
Especifica se o relatório gerado em HTML deve ser exibido em um navegador Web depois da sua geração. |
DotSourceMode |
Especifica se nada precisa ser executado imediatamente, mas este arquivo tem seu caminho originado por um ponto e um espaço para usar os métodos do Windows PowerShell definidos nele. |
Exemplos de CollectOverMetrics.ps1
Os exemplos seguintes usam o script CollectOverMetrics.ps1.
Este exemplo coleta métricas para todos os bancos de dados que correspondem a DB* (o que inclui um caractere curinga) no DAG DAG1. Depois da coleta das métricas, um relatório HTML é gerado e exibido.
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport
Este exemplo coleta métricas para todos os bancos de dados no DAG DAG2. Depois da coleta das métricas, um relatório HTML é gerado e exibido.
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG2 -GenerateHTMLReport -ShowHTMLReport
Retornar ao início
Script CollectReplicationMetrics.ps1
Outro script de métrica de integridade incluído no Exchange 2010 é o CollectReplicationMetrics.ps1. Este script é uma forma ativa de monitoramento, porque coleta métricas em tempo real, enquanto o script é executado. O script suporta parâmetros que permitem que você personalize seu comportamento e sua saída. Os parâmetros disponíveis estão listados na tabela a seguir.
Parâmetros do script CollectReplicationMetrics
| Parâmetro | Descrição |
|---|---|
DagName |
Especifica o nome do DAG do qual você deseja coletar métricas. Se este parâmetro for omitido, o DAG do qual o servidor local é membro será usado. |
DatabaseNames |
Fornece uma lista de bancos de dados para os quais o relatório precisa ser gerado. Há suporte para caracteres curinga, por exemplo, |
ReportAlias |
Especifica o alias do email ao qual o relatório deve ser enviado. |
TemporaryDataPath |
Especifica o local para armazenar arquivos temporários. Se este parâmetro for omitido, o nome do diretório será: %SystemDrive%\Temp\CollectReplicationMetrics\<ScriptStartTime> |
ReportPath |
Especifica a pasta usada para armazenar os resultados do processamento de eventos. Se este parâmetro for omitido, a pasta Scripts será usada. |
Duração |
Especifica a quantidade de tempo em que o processo de coleta deve ser executado. |
Frequência |
Especifica a freqüência na qual as métricas de dados são coletadas. |
Verbose |
Exibe a saída de tarefas na tela depois do término da tarefa. |
ProcessOnly |
Especifica se os dados já foram coletados e se o processamento único é requerido. |
Exemplo de CollectReplicationMetrics.ps1
O exemplo a seguir usa o script CollectReplicationMetrics.ps1.
Este exemplo coleta métricas para todos os bancos de dados no DAG DAG1 e exibe os dados coletados em um relatório na tela.
CollectReplicationMetrics.ps1 -DagName DAG1 -Verbose
Retornar ao início