Monitorando a alta disponibilidade e resiliência do site
Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Tópico modificado em: 2015-03-09
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, as funções e as responsabilidades envolvidas em operações devem ser formalizadas. É importante entender a conexão entre as práticas e os procedimentos operacionais benéficos e uma infraestrutura adequada.. 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, scripts e recursos internos que podem ser usados como parte do monitoramento proativo regular quando o Exchange está configurado para alta disponibilidade ou resiliência de 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 oferece um novo fluxo de log de eventos que aproveita as funcionalidades do canal crimson no Windows Server, além de scripts internos que podem coletar e analisar dados desses 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).
Sumário
Cmdlet Get-MailboxDatabaseCopyStatus
Cmdlet Test-ReplicationHealth
Log de Eventos do Canal Crimson
Script CollectOverMetrics.ps1
Script CollectReplicationMetrics.ps1
Script CheckDatabaseRedundancy.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. |
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.
Cmdlet Get-MailboxDatabaseCopyStatus
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
Cmdlet Get-MailboxDatabaseCopyStatus
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. Os logs 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.
Cmdlet Get-MailboxDatabaseCopyStatus
Script CollectOverMetrics.ps1
O Exchange 2010 inclui um script chamado CollectOverMetrics.ps1, que pode ser encontrado na pasta Scripts. CollectOverMetrics.ps1 lê logs de eventos de membros do DAG para reunir informações sobre operações de banco de dados (como montagens, movimentações e failovers de banco de dados) abrangendo um período de tempo específico. Para cada operação, o script retorna as seguintes informações:
Identidade do banco de dados
Hora de início e término da operação
Servidores em que o banco de dados estava montado no início e no término da operação
Motivo para a operação
Se a operação foi bem-sucedida, incluindo os detalhes de erros no caso de falha da operação
O script grava essas informações em arquivos .csv com uma operação por fila. Ele grava um arquivo .csv separado para cada DAG.
O script suporta parâmetros que permitem personalizar seu comportamento e sua saída. Por exemplo, os resultados podem ser restritos a um subconjunto especificado usando os parâmetros Database ou ReportFilter. Somente as operações que correspondem a esses filtros serão incluídas no relatório HTML do resumo. 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. Caracteres curinga podem ser usados para coletar informações e gerar relatórios sobre vários DAGs. |
Database |
Fornece uma lista de bancos de dados para os quais o relatório precisa ser gerado. Há suporte para caracteres curinga, por exemplo, |
StartTime |
Especifica a duração do período de tempo a relatar. O script coleta somente os eventos registrados durante esse período. Como resultado, o script pode capturar registros parciais da operação (por exemplo, apenas o final de uma operação no início do período ou vice-versa). Se nem StartTime nem EndTime forem especificados, o script adotará como padrão as últimas 24 horas. Se apenas um parâmetro for especificado, o período será de 24 horas, começando ou terminando no horário especificado. |
EndTime |
Especifica a duração do período de tempo a relatar. O script coleta somente os eventos registrados durante esse período. Como resultado, o script pode capturar registros parciais da operação (por exemplo, apenas o final de uma operação no início do período ou vice-versa). Se nem StartTime nem EndTime forem especificados, o script adotará como padrão as últimas 24 horas. Se apenas um parâmetro for especificado, o período será de 24 horas, começando ou terminando no horário especificado. |
ReportPath |
Especifica a pasta usada para armazenar os resultados do processamento de eventos. Se este parâmetro for omitido, a pasta Scripts será usada. Quando especificado, o script usa uma lista de arquivos .csv gerados por ele como dados de origem para gerar um relatório HTML resumido. O relatório é o mesmo que é gerado com a opção -GenerateHtmlReport. Os arquivos podem ser gerados abrangendo vários grupos de disponibilidade de banco de dados em muitos períodos de tempo diferentes, ou mesmo com horários sobrepostos. O script mescla todos esses dados. |
GenerateHtmlReport |
Especifica que o script colete todas as informações que gravou, agrupe os dados pelo tipo de operação e gere um arquivo HTML que inclua estatísticas para cada um desses grupos. O relatório inclui o número total de operações em cada grupo, o número de operações que falharam e estatísticas sobre o tempo gasto em cada grupo. O relatório também detalha os tipos de erros que resultaram em falha nas operações. |
ShowHtmlReport |
Especifica que o relatório gerado em HTML deve ser exibido em um navegador Web depois de ser gerado. |
SummariseCSVFiles |
Especifica que o script leia os dados de arquivos .csv existentes que foram gerados anteriormente por ele. Em seguida, esses dados são usados para gerar um relatório resumido semelhante ao relatório gerado pelo parâmetro GenerateHtmlReport. |
ActionType |
Especifica o tipo de ações operacionais que o script deve coletar. Os valores válidos para esse parâmetro são |
ActionTrigger |
Especifica quais operações administrativas devem ser coletadas pelo script. Os valores válidos para esse parâmetro são |
RawOutput |
Especifica que o script grave os resultados que teriam sido gravados em arquivos .csv diretamente no fluxo de saída, como aconteceria com write-output. Essas informações podem ser canalizadas para outros comandos. |
IncludedExtendedEvents |
Especifica que o script colete os eventos que fornecem detalhes de diagnóstico do tempo gasto montando bancos de dados. Esse pode ser um estágio muito demorado se o log de eventos de Aplicativo nos servidores for muito grande. |
MergeCSVFiles |
Especifica que o script mescle todos os arquivos .csv contendo dados sobre cada operação em um único arquivo .csv. |
ReportFilter |
Especifica que um filtro deve ser aplicado às operações, usando os campos que aparecem nos arquivos .csv. Esse parâmetro usa o mesmo formato de uma operação |
Exemplos de CollectOverMetrics.ps1
O seguinte exemplo coleta métricas para todos os bancos de dados que correspondem a DB* (o que inclui um caractere curinga) em um DAG denominado DAG1. Depois da coleta das métricas, um relatório HTML é gerado e exibido.
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport
Os seguintes exemplos demonstram maneiras de filtrar o relatório HTML resumido. O primeiro usa o parâmetro Database, que recebe uma lista de nomes de bancos de dados. O relatório resumido resultante conterá dados apenas sobre esses bancos de dados. Os dois próximos exemplos usam a opção ReportFilter. O último exemplo filtra todos os bancos de dados padrão.
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }
Cmdlet Get-MailboxDatabaseCopyStatus
Script CollectReplicationMetrics.ps1
CollectReplicationMetrics.ps1 é outro script de métrica de integridade incluído no Exchange 2010. Esse script fornece uma forma ativa de monitoramento, porque coleta métricas em tempo real, enquanto o script é executado. CollectReplicationMetrics.ps1 coleta dados de contadores de desempenho relacionados à replicação de banco de dados. O script reúne dados de contador de vários servidores de Caixa de Correio, grava os dados de cada servidor em um arquivo .csv e pode então relatar diferentes estatísticas abrangendo todos esses dados (por exemplo, por quanto tempo cada cópia falhou ou foi suspensa, o comprimento médio da fila de cópia ou de repetição ou quanto tempo as cópias permaneceram fora de seus critérios de failover).
Você pode especificar os servidores individualmente ou DAGs inteiros. Você pode ou executar o script para coletar primeiro os dados e depois gerar o relatório, ou pode executá-lo apenas para coletar os dados ou para apenas para gerar um relatório sobre os dados que já foram coletados. É possível especificar a frequência de amostragem dos dados e a duração total da coleta de dados.
Os dados coletados de cada servidor são gravados em um arquivo chamado CounterData.<ServerName>.<TimeStamp>.csv. O relatório de resumo será gravado em um arquivo chamado HaReplPerfReport.<NomeDoDAG>.<TimeStamp>.csv, ou HaReplPerfReport.<TimeStamp>.csv caso o script não tenha sido executado com o parâmetro DagName.
O script inicia trabalhos de PowerShell para coletar os dados de cada servidor. Esses trabalhos são executados durante todo o período em que os dados estão sendo coletados. Se você especificar um grande número de servidores, esse processo pode usar uma quantidade considerável de memória. O estágio final do processo, quando os dados são processados em um relatório resumido, também pode ser bastante demorado para grandes quantidades de dados. É possível executar o estágio de coleta em um computador e depois copiar os dados para outro local para processamento.
O script CollectReplicationMetrics.ps1 suporta parâmetros que permitem personalizar 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 esse 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, |
ReportPath |
Especifica a pasta usada para armazenar os resultados do processamento de eventos. Se esse parâmetro for omitido, a pasta Scripts será usada. |
Duration |
Especifica a quantidade de tempo em que o processo de coleta deve ser executado. Os valores típicos seriam de uma a três horas. Durações maiores devem ser usadas somente com longos intervalos entre cada amostra ou como uma série de trabalhos mais curtos executados por tarefas agendadas. |
Frequency |
Especifica a freqüência na qual as métricas de dados são coletadas. Os valores típicos seriam de 30 segundos, um minuto ou cinco minutos. Sob circunstâncias normais, intervalos mais curtos que esses não mostrarão mudanças significativas entre cada amostra. |
Servers |
Especifica a identidade dos servidores dos quais serão coletadas estatísticas. É possível especificar qualquer valor, incluindo caracteres curinga ou GUIDs. |
SummariseFiles |
Especifica uma lista de arquivos .csv para gerar um relatório resumido. Esses são os arquivos chamados CounterData.<CounterData>* gerados pelo script CollectReplicationMetrics.ps1. |
Mode |
Especifica os estágios de processamento que o script executa. É possível usar os seguintes valores:
|
MoveFilestoArchive |
Especifica que o script deve mover os arquivos para uma pasta compactada após o processamento. |
LoadExchangeSnapin |
Especifica que o script deve carregar os comandos de Shell do Exchange. Esse parâmetro é útil quando o script precisa ser executado de fora do Shell de Gerenciamento do Exchange, como em uma tarefa agendada. |
Exemplo de CollectReplicationMetrics.ps1
O seguinte exemplo coleta dados correspondentes a uma hora de todos os servidores no DAG "DAG1", amostrados em intervalos de um minuto, e gera um relatório resumido. Além disso, o parâmetro ReportPath é usado, o que faz com que o script coloque todos os arquivos no diretório atual.
CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath
O seguinte exemplo lê os dados de todos os arquivos que correspondem a "CounterData*" e gera um relatório resumido.
CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath
Cmdlet Get-MailboxDatabaseCopyStatus
Script CheckDatabaseRedundancy.ps1
Como seu nome sugere, a finalidade do script CheckDatabaseRedundancy.ps1 script é monitorar a redundância de bancos de dados de caixa de correio replicados, confirmando que há pelo menos duas cópias configuradas, íntegras e atualizadas, e alertar quando só existe uma cópia íntegra de um banco de dados replicado. Nesse caso, tanto cópias ativas como passivas são contadas ao determinar a redundância.
Quando a função de servidor Caixa de Correio é instalada, o script CheckDatabaseRedundancy.ps1 é configurado automaticamente pelo Exchange para ser executado como uma tarefa agendada chamada de Alerta de Cópia de Banco de Dados Um. Por padrão, a tarefa agendada do Alerta de Cópia de Banco de Dados Um é configurada para ser executada a cada 60 minutos. Você pode modificar esse comportamento e as configurações de tarefa agendada usando o Agendador de Tarefas do Windows. O script é projetado para a primeira verificação de associação do DAG, por isso, se o servidor de Caixa de Correio não é membro de um DAG, o script é encerrado imediatamente.
O script também pode ser executado interativamente a partir da pasta de scripts. Ao executar o script interativamente, você deve especificar um nome de banco de dados ou um nome de membro de DAG. Para especificar um banco de dados você usa o parâmetro MailboxDatabaseName e para especificar um membro de DAG o parâmetro MailboxServerName. Quando executado de modo interativo no console, o script executa a verificação de redundância apenas uma vez e produz a saída de CurrentState (vermelho ou verde) na tela.
Como outros scripts e cmdlets, CheckDatabaseRedundancy.ps1 também pode ser executado no modo de monitoramento e gerar eventos com a adição do parâmetro MonitoringContext. A tarefa agendada criada pelo Exchange executa o script em modo de monitoração. Esse modo também permite que o script seja invocado por uma solução de monitoramento, como o Microsoft System Center Operations Manager (SCOM). No modo de monitoramento, o script gera eventos de alerta vermelho e verde no log de eventos de Aplicativo do servidor local. Um evento de alerta vermelho (ID do evento 4113) é gerado apenas se o banco de dados tiver permanecido em estado “vermelho” por 20 minutos ou mais (duração total, não consecutiva) durante uma hora de execução do script, e um evento de alerta verde (ID do evento 4114) quando o banco de dados tiver permanecido em estado “verde” por 10 minutos consecutivos. Por padrão, quando um evento de alerta vermelho é gerado, ele continua a ser relatado a cada 15 minutos.
Além disso, o script possui algumas outras opções úteis. Por exemplo, é possível adicionar o parâmetro ShowDetailedErrors para obter maiores detalhes sobre quaisquer erros que ocorram e o parâmetro Verbose para obter informações adicionais para solução de problemas. O script também inclui um parâmetro SendSummaryMailTos que pode ser usado para enviar, após sua execução, um relatório resumido por email para uma lista de endereços de email especificados. Isso permite que administradores examinem rapidamente os relatórios a cada hora para ver se ocorreu algum problema de redundância. Se você usar a funcionalidade do email, precisará incluir o parâmetro SummaryMailFrom sempre que usar o parâmetro SendSummaryMailTos.
A Microsoft recomenda executar esse script regularmente como parte de suas operações de monitoramento normais, usando a tarefa automática agendada ou um sistema de monitoramento, como o SCOM. Para assegurar que a redundância do banco de dados não permaneça comprometida por longos períodos de tempo, execute o script a cada 60 minutos. O script inclui um parâmetro chamado TerminateAfterDurationSecs que, quando definido como -1 ou 0 ao executar o script, pode ser usado para executá-lo por uma período de tempo infinito.
Se você não estiver executando uma solução de monitoramento como o SCOM, recomendamos que permita a tarefa criada automaticamente para automatizar e agendar a execução do script.
Há problemas conhecidos no Agendador de Tarefas do Windows Server 2008 SP2 que podem fazer com que o Agendador de Tarefas falhe quando você tiver agendado uma tarefa de execução demorada. Estas questões não existem no Windows Server 2008R2; Assim, se possível, execute o script a partir de Windows Server 2008R2. Se você não puder executar o script a partir do Windows Server 2008 R2 e você estiver executando-o do Windows Server 2008 SP2, recomendamos duas modificações. Primeiro, em vez de executar o script com sua supressão transitória interna de 60 minutos, execute o script a cada 5 minutos usando os seguintes parâmetros:
CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors
Segundo, se possível, use o SCOM para definir o comportamento de supressão transitória (por exemplo, se 3 eventos de alerta vermelho forem registrados em um período de 20 minutos, gerar um alerta; e se um evento de alerta verde for registrado, alterar CurrentState para verde).
Se a tarefa agendada do Alerta de Cópia de Banco de Dados Um é alterado ou removida, você pode excluir e reagendar executando o comando a seguir:
schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY
Substitua os parâmetros no script acima pelos parâmetros de script que desejar usar. Os parâmetros adicionais para o script também são descritos no script.
Ao usar a ferramenta de linha de comando schtasks para criar uma tarefa agendada, a opção /TR é limitada a 261 caracteres. O exemplo acima excede esse limite. Se os parâmetros e caminhos usados fizerem com que a opção /TR exceda 261 caracteres, você terá que criar manualmente a tarefa agendada usando o miniaplicativo Agendador de Tarefas no menu Ferramentas Administrativas. Alternativamente, é possível copiar e colar o seguinte XML no Bloco de Notas, editá-lo adequadamente, salvá-lo como um arquivo XML e importá-lo usando o miniaplicativo Agendador de Tarefas.
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2010-05-11T15:55:47</Date>
<Author>administrator</Author>
</RegistrationInfo>
<Triggers>
<TimeTrigger>
<Repetition>
<Interval>PT1H</Interval>
<StopAtDurationEnd>false</StopAtDurationEnd>
</Repetition>
<StartBoundary>2010-05-11T15:55:00</StartBoundary>
<Enabled>true</Enabled>
</TimeTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>SYSTEM</UserId>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>Powershell.exe</Command>
<Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
</Exec>
</Actions>
</Task>
Cmdlet Get-MailboxDatabaseCopyStatus
© 2010 Microsoft Corporation. Todos os direitos reservados.