Disponibilidade gerenciada

Aplica-se a: Exchange Server 2013 SP1

A garantia de que os usuários tenham uma boa experiência com emails sempre foi o principal objetivo dos administradores de sistemas de mensagens. Para ajudar a assegurar a disponibilidade e a confiabilidade da sua organização Exchange Server 2013, todos os aspectos do sistema devem ser ativamente monitorados, e qualquer problema detectado deve ser rapidamente resolvido. Em versões anteriores do Exchange, o monitoramento de componentes críticos do sistema geralmente envolvia o uso de um aplicativo externo, como o Microsoft System Center 2012 Operations Manager, para coletar dados e fornecer a ação de recuperação para os problemas detectados como resultado da análise dos dados coletados. O Exchange 2010 e versões anteriores incluíam manifestos de integridade e mecanismos de correlação na forma de pacotes de gerenciamento. Esses componentes habilitavam o Operations Manager a determinar se um determinado componentes está íntegro ou não. Além disso, o Operations Manager também usava a infraestrutura de cmdlet de diagnóstico, interna ao Exchange 2010, para executar transações sintéticas baseadas em vários aspectos do sistema.

O Exchange 2013 adota uma nova abordagem para monitorar e preservar a experiência do usuário final nativamente usando um recurso chamado Disponibilidade Gerenciada que fornece ações internas de monitoramento e recuperação.

A disponibilidade gerenciada, também conhecida como Monitoramento Ativo ou Monitoramento Ativo Local, é a integração de ações internas de monitoramento e recuperação com a plataforma de alta disponibilidade do Exchange. O recurso foi projetado para detectar e se recuperar de problemas assim que eles ocorrem e são descobertos pelo sistema. Diferentemente das soluções e técnicas anteriores de monitoramento externo do Exchange, a disponibilidade gerenciada não tenta identificar ou comunicar a causa raiz de um problema. Em vez disso, ela se concentra nos aspectos de recuperação que tratam das três principais áreas da experiência do usuário.

• Disponibilidade: os usuários podem acessar o serviço?
• Latência: como é a experiência para os usuários?
• Erros: os usuários podem realizar o que desejam?

Essa consolidação de função de servidor e outras alterações de arquitetura do Exchange 2013 exigem uma nova abordagem para as metodologias de monitoramento e para o modelo de integridade de versões anteriores do Exchange. A disponibilidade gerenciada foi projetada para cuidar dessas alterações fornecendo uma solução nativa de monitoramento de integridade e recuperação. Ela abandona o monitoramento de fatias separadas individuais do sistema e adota o monitoramento da experiência completa do usuário, protegendo a experiência do usuário final por meio de ações orientadas à recuperação.

A disponibilidade gerenciada é um processo interno executado em cada servidor do Exchange 2013. Ela examina e analisa centenas de métricas de integridade a cada segundo. Se algo errado for detectado, isso será, na maior parte das vezes, corrigido automaticamente. Mas sempre haverá problemas que a disponibilidade gerenciada, por si só, não poderá resolver. Nesses casos, a disponibilidade gerenciada encaminhará o problema para um administrador, usando o log de eventos.

A disponibilidade gerenciada é implementada na forma de dois serviços:

• Serviço do Exchange Health Manager (MSExchangeHMHost.exe): esse serviço é um processo de controlador usado para gerenciar processos de trabalho. É usado para compilar, executar e iniciar e parar o processo de trabalho, conforme o necessário. Também é usado para recuperar o processo de trabalho em caso de falha, para evitar que o processo de trabalho se torne um único ponto de falha.

• Processo do Exchange Health Manager Worker (MSExchangeHMWorker.exe): esse serviço é o processo de trabalho responsável por executar tarefas em tempo de execução dentro da estrutura de disponibilidade gerenciada.

A disponibilidade gerenciada usa o armazenamento persistente para executar suas funções:

• Os arquivos XML da pasta \bin\Monitoring\config são usados para armazenar definições de configuração para alguns dos itens de trabalho da sonda e do monitor.
• Active Directory é usado para armazenar substituições globais.
• O Registro do Windows é usado para armazenar dados de tempo de execução, como indicadores, e substituições locais (específicas de servidor).
• A infraestrutura de log de evento do canal carmesim do Windows é usada para armazenar resultados de itens de trabalho.
• As caixas de correio de integridade são usadas para atividades de investigação. Várias caixas de correio de integridade serão criadas em cada banco de dados de caixa de correio existente no servidor.

Como ilustrado no desenho a seguir, a disponibilidade gerenciada inclui três componentes assíncronos principais, que estão constantemente trabalhando.

O primeiro componente é chamado de Sonda. As investigações são responsáveis por fazer medições no servidor e coletar dados. Os resultados dessas medidas fluem para o segundo componente, o Monitor. O monitor contém toda a lógica de negócios usada pelo sistema com base no que é considerado íntegro nos dados coletados. De modo similar a um mecanismo de reconhecimento de padrão, o monitor analisa os vários e diferentes padrões em todas as medições coletadas e, então, decide se algo pode ser considerado íntegro. Por fim, há respondentes, que são responsáveis por ações de recuperação e escalonamento. Quando algo perde integridade, a primeira ação é tentar recuperar esse componente. Esse esforço de recuperação pode incluir ações de recuperação em vários estágios; por exemplo, a primeira tentativa pode ser reiniciar o pool de aplicativos, a segunda pode ser reiniciar o serviço, a terceira tentativa pode ser reiniciar o servidor, e a tentativa subsequente pode ser tirar o servidor offline para que ele não aceite mais o tráfego. Se as ações de recuperação falharem, o sistema encaminhará o problema para alguém por meio de notificações do log de eventos.

Há três categorias primárias de investigações: investigações recorrentes, notificações e verificações. As investigações recorrentes são transações sintéticas executadas pelo sistema para testar a experiência de usuário de ponta a ponta. Verificações são a infraestrutura que executa a coleta de dados de desempenho, incluindo o tráfego do usuário, e mede os dados coletados em relação aos limites definidos para determinar picos de falhas do usuário. Essa funcionalidade de medição permite que a infraestrutura de verificação fique ciente quando os usuários estão enfrentando problemas. Por fim, a lógica de notificação permite ao sistema tomar providências imediatas, com base em um evento crítico, sem precisar esperar os resultados dos dados coletados por uma sonda. Essas exceções ou condições podem ser detectadas e reconhecidas sem um conjunto de exemplo grande.

As investigações recorrentes são executadas a cada poucos minutos e verificam algum aspecto da integridade do serviço. Essas investigações podem transmitir um email por meio de Exchange ActiveSync para uma caixa de correio de monitoramento, elas podem se conectar a um ponto de extremidade RPC ou verificar a conectividade de acesso do cliente à caixa de correio.

Todas as investigações são definidas na inicialização de serviços do Health Manager no canal vermelho Microsoft.Exchange.ActiveMonitoring\ProbeDefinition. Cada definição de investigação tem muitas propriedades, mas as propriedades mais relevantes são:

• Nome: o nome da investigação, que começa com um SampleMask do monitor da investigação.
• TypeName: o tipo de objeto de código da investigação que contém a lógica da investigação.
• ServiceName: o nome do conjunto de integridade que contém esta investigação.
• TargetResource: o objeto que a investigação está validando. Esse nome da propriedade é acrescentado ao nome da investigação quando ela é executada para se tornar um resultado de investigação ResultName
• RecorrênciaIntervalSeconds: com que frequência a investigação é executada.
• TimeoutSeconds: quanto tempo a investigação aguardará antes de falhar.

Há centenas de investigações recorrentes. Muitas dessas investigações são por banco de dados, portanto, à medida que o número de bancos de dados aumenta, o número de investigações também aumenta. A maioria das investigações é definida em código e, portanto, não são diretamente detectáveis.

Os conceitos básicos de uma investigação recorrente são os seguintes: iniciar cada RecorrênciaIntervalSeconds e verificar (ou sondar) algum aspecto da integridade. Se o componente estiver íntegro, a investigação passará e gravará um evento informativo no canal Microsoft.Exchange.ActiveMonitoring\ProbeResult com um ResultType de 3. Se a verificação falhar ou o tempo limite, a investigação falhará e gravará um evento de erro no mesmo canal. Um ResultType de 4 significa que a verificação falhou e um ResultType de 1 significa que ele acabou o tempo limite. Muitas investigações serão executadas novamente se tiverem tempo limite, até o valor da propriedade MaxRetryAttempts .

Observação

O canal do ProbeResult crimson pode ficar muito ocupado com centenas de investigações em execução a cada poucos minutos e registrar um evento, portanto, pode haver um impacto real no desempenho do servidor exchange se você tentar consultas caras nos logs de eventos em um ambiente de produção.

As notificações são investigações que não são executadas pela estrutura do health manager, mas por algum outro serviço no servidor. Esses serviços executam seu próprio monitoramento e, em seguida, alimentam seus dados na estrutura de Disponibilidade Gerenciada escrevendo diretamente os resultados da investigação. Você não verá essas investigações no canal ProbeDefinition, pois este canal descreve apenas as investigações que serão executadas pela estrutura de Disponibilidade Gerenciada. Por exemplo, o ServerOneCopyMonitor Monitor é disparado pelos resultados da investigação escritos pelo serviço MSExchangeDAGMgmt. Esse serviço executa seu próprio monitoramento, determina se há um problema e registra um resultado de investigação. A maioria das investigações de notificação tem a capacidade de registrar um evento vermelho que torna o monitor não íntegro e um evento verde que torna o monitor saudável novamente.

Verificações são investigações que só registram eventos quando um contador de desempenho passa acima ou abaixo de um limite definido. Eles são realmente um caso especial de investigações de notificação, pois há um serviço monitorando os contadores de desempenho no servidor e registrando eventos no canal ProbeResult quando o limite configurado é atendido.

Para encontrar o contador e o limite considerados não íntegros, você pode examinar o monitor para essa verificação. Monitores do tipo Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor ou Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor significam que a investigação que eles assistem é uma investigação de verificação

Os monitores consultam os dados coletados pelas sondas para determinar se a ação deve ser realizada com base em um conjunto predefinido de regras. Dependendo da regra ou da natureza do problema, um monitor poderá iniciar um respondente ou encaminhar o problema para alguém por meio de uma entrada no log de eventos. Além disso, os monitores definem quanto tempo após uma falha que um respondente é executado e o fluxo de trabalho da ação de recuperação. Monitores têm vários estados. Na perspectiva de estado do sistema, os monitores têm dois estados:

• Saudável: o monitor está operando corretamente e todas as métricas coletadas estão dentro de parâmetros operacionais normais
• Não íntegro: o monitor não é saudável e iniciou a recuperação por meio de um respondente ou notificou um administrador por meio de escalonamento.

De uma perspectiva administrativa, os monitores têm muitos outros estados que aparecem no Shell:

• Degradado: quando um monitor está em um estado não íntegro de 0 a 60 segundos, ele é considerado degradado. Se o monitor apresentar um estado de não integridade por mais de 60 segundos, ele será considerado Não Íntegro.
• Desabilitado: o monitor foi explicitamente desabilitado por um administrador.
• Indisponível: o serviço Microsoft Exchange Health consulta periodicamente cada monitor por seu estado. Se o serviço não conseguir uma resposta para a consulta, o estado do monitor se tornará Não Disponível.
• Reparação: um administrador define o estado reparador para indicar ao sistema que a ação corretiva está em processo por um humano, o que permite que o sistema e os humanos diferenciem entre outras falhas que podem ocorrer ao mesmo tempo em que ações corretivas estão sendo tomadas (como uma operação de ressecando cópia de banco de dados).

Cada monitor tem uma propriedade SampleMask em sua definição. Conforme o monitor é executado, ele procura eventos no canal ProbeResult que tenham um ResultName que corresponda ao SampleMask do monitor. Esses eventos podem ser de investigações recorrentes, notificações ou verificações. Se os limites do monitor forem atingidos, ele se tornará não íntegro. Na perspectiva do monitor, todos os três tipos de investigação são os mesmos que cada um faz logon no canal ProbeResult.

Vale a pena observar que uma única falha de investigação não indica necessariamente que algo está errado com o servidor. É o design dos monitores para identificar corretamente quando há um problema real que precisa ser corrigido. Portanto, muitos monitores têm limites de várias falhas de investigação antes de se tornarem insalubres. Mesmo assim, muitos desses problemas podem ser corrigidos automaticamente pelos respondentes, portanto, o melhor lugar para procurar problemas que exigem intervenção manual está no canal vermelho Microsoft.Exchange.ManagedAvailability\Monitoring. Este canal inclui o erro de investigação mais recente.

Tal como indica o nome deles, os respondentes executam algum tipo de resposta a um alerta gerado por um monitor. Os respondentes tomam várias ações de recuperação, como redefinir um pool de trabalho do aplicativo para reiniciar um servidor. Há vários tipos de respondentes:

• Reiniciar Responder: encerra e reinicia um serviço
• Redefinir o AppPool Responder: interrompe e reinicia um pool de aplicativos no IIS (Serviços de Informações da Internet)
• Failover Responder: inicia um failover de banco de dados ou servidor
• Bugcheck Responder: inicia uma verificação de bugs do servidor, causando assim uma reinicialização do servidor
• Responder offline: tira um protocolo em um servidor de serviço (rejeita solicitações de cliente)
• Respondente Online: coloca um protocolo em um servidor de volta à produção (aceita solicitações de cliente)
• Escalar Responder: aumenta o problema para um administrador por meio do log de eventos

Além dos respondentes listados acima, alguns componentes também têm respondentes especializados e exclusivos do componente.

Todos os respondentes incluem o comportamento de limitação, que fornece um mecanismo de sequenciamento interno para controlar ações de respondente. O comportamento de limitação foi projetado para garantir que o sistema não será comprometido ou prejudicado como resultado das ações de recuperação do respondente. Todos os respondentes são limitados de alguma forma. Quando ocorre uma limitação, a ação de recuperação do respondente pode ser ignorada ou atrasada, dependendo da ação. Por exemplo, quando o respondente de verificação de erro é limitado, sua ação é ignorada, em vez de atrasada.

Conjuntos de integridade

Na perspectiva de relatórios, a disponibilidade gerenciada tem dois modos de exibição de integridade, um interno e outro externo. A exibição interna usa conjuntos de integridade. Cada componentes do Exchange 2013 (por exemplo, o Outlook Web App, o Exchange ActiveSync, o serviço Armazenamento de Informações, a indexação de conteúdo, os serviços de transporte etc.) é monitorado pela disponibilidade gerenciado usando sondas, monitores e respondentes. Um grupo de investigações, monitores e respondentes de determinado componente é chamado de conjunto de integridade. Um conjunto de integridade é um grupo de sondas, monitores e respondentes, que determina se o componente é íntegro. O estado atual de um conjunto de integridade (por exemplo, se ele é saudável ou não) é determinado usando o estado dos monitores do conjunto de integridade. Se todos os monitores de um conjunto de integridade forem íntegros, então o conjunto de integridade terá um estado íntegro. Se qualquer monitor não tiver um estado íntegro, então o estado do conjunto de integridade será determinado pelo monitor menos íntegro.

Para obter etapas detalhadas para exibir o estado dos conjuntos de integridade ou integridade do servidor, consulte Gerenciar conjuntos de integridade e integridade do servidor.

Grupos de integridade

A exibição externa da disponibilidade gerenciada é composta por grupos de integridade. Os grupos de integridade são expostos no System Center Operations Manager 2007 R2 e no System Center Operations Manager 2012.

Há quatro grupos principais de integridade:

• Pontos de Toque do Cliente: componentes que afetam interações do usuário em tempo real, como protocolos ou o Repositório de Informações
• Componentes de serviço: componentes sem interações diretas e em tempo real do usuário, como o serviço de Replicação da Caixa de Correio do Microsoft Exchange ou o processo de geração de catálogo de endereços offline (OABGen)
• Componentes do servidor: os recursos físicos do servidor, como espaço em disco, memória e rede
• Disponibilidade de dependência: a capacidade do servidor de acessar dependências necessárias, como Active Directory, DNS etc.

Quando o Pacote de Gerenciamento do Exchange é instalado, o SCOM (System Center Operations Manager) atua como um portal de integridade para exibir informações relacionadas ao ambiente do Exchange. O painel do SCOM inclui três modos de exibição do servidor de integridade do Exchange:

• Alertas Ativos: Os Respondentes de Escalonamento gravam eventos no log de eventos do Windows que são consumidos pelo monitor no SCOM. Esses eventos aparecem como alertas na exibição Alertas Ativos.
• Integridade da Organização: um resumo da integridade geral da integridade da organização do Exchange é exibido nesta exibição. Esses rollups incluem a exibição da integridade de cada grupo de disponibilidade de banco de dados, além da integridade em sites Active Directory específicos.
• Integridade do servidor: os conjuntos de integridade relacionados são combinados em grupos de integridade e resumidos nesse modo de exibição.

Substituições

As substituições capacitam o administrador a configurar alguns aspectos de sondas, monitores e respondentes da disponibilidade gerenciada. As substituições podem ser usadas para ajustar alguns dos limites utilizados pela disponibilidade gerenciada. Elas também podem ser usadas para habilitar ações emergenciais para eventos inesperados, o que pode exigir definições de configuração diferentes dos padrões predefinidos.

As substituições podem ser criadas e aplicadas a um único servidor (esse processo é conhecido como substituição de servidor) ou podem ser aplicadas a um grupo de servidores (esse processo é conhecido como substituição global). Os dados de configuração da substituição de servidor são armazenados no Registro do Windows, no servidor em que a substituição foi aplicada. Os dados de configuração da substituição global são armazenados em Active Directory.

As substituições podem ser configuradas com duração infinita ou com uma duração específica. Além disso, as substituições globais podem ser configuradas para aplicação em todos os servidores ou apenas nos servidores que executam uma determinada versão do Exchange.

Quando configura cria uma substituição, ela não tem efeito imediato. O serviço Gerenciador de Integridade do Microsoft Exchange verifica se há dados de configuração atualizados, a cada 10 minutos. Além disso, as substituições globais são dependentes da latência de replicação do Active Directory.

Para obter etapas detalhadas para exibir ou configurar substituições globais ou servidor, consulte Configurar substituições de disponibilidade gerenciada.

Cmdlets e tarefas de gerenciamento

Há três tarefas operacionais principais que, em geral, os administradores executam na disponibilidade gerenciada:

• Extração ou exibição da integridade do sistema
• Exibição de conjuntos de integridade e detalhes sobre sondas, monitores e respondentes
• Gerenciamento de substituições

As duas principais ferramentas de gerenciamento da disponibilidade gerenciada são Logo de Eventos do Windows e o Shell. A disponibilidade gerenciada registra uma grande quantidade de informações nos logs de eventos do canal carmesim ActiveMonitoring e ManagedAvailability do Exchange; por exemplo:

• As definições de investigação, monitor e respondente, que são registradas nos respectivos logs de eventos *Definição.
• Resultados de investigação, monitor e respondente, que são registrados nos respectivos logs de eventos *Resultados.
• Detalhes sobre as ações de recuperação do respondente, incluindo quando a ação de recuperação foi iniciada e quando foi considerada concluída (se bem-sucedida ou não), o que é registrado no log de evento RecoveryActionResults.

Há 12 cmdlets usados para disponibilidade gerenciada, os quais estão descritos na tabela a seguir.

Cmdlet	Descrição
Get-ServerHealth	Usado para obter informações brutas de integridade do servidor, como conjuntos de integridade e seu estado atual (saudável ou não íntegro), monitores de conjunto de integridade, componentes do servidor, recursos de destino para investigações e carimbos de data/hora relacionados à investigação ou monitorar horários de início ou parada e tempos de transição de estado.
Get-HealthReport	Usado para obter uma exibição de integridade sumário que inclua conjuntos de integridade e seu estado atual.
Get-MonitoringItemIdentity	Usado para exibir as investigações, monitores e respondentes associados a um conjunto de integridade específico.
Get-MonitoringItemHelp	Usado para exibir descrições sobre algumas das propriedades de investigações, monitores e respondentes.
Add-ServerMonitoringOverride	Usado para criar uma substituição local específica do servidor de uma investigação, monitor ou respondente.
Get-ServerMonitoringOverride	Usado para exibir uma lista de substituições locais no servidor especificado.
Remove-ServerMonitoringOverride	Usado para remover uma substituição local de um servidor específico.
Add-GlobalMonitoringOverride	Usado para criar uma substituição global para um grupo de servidores.
Get-GlobalMonitoringOverride	Usado para exibir uma lista de substituições globais configuradas na organização.
Remove-GlobalMonitoringOverride	Usado para remover uma substituição global.
Set-ServerComponentState	Usado para configurar o estado de um ou mais componentes do servidor.
Get-ServerComponentState	Usado para exibir o estado de um ou mais componentes do servidor.