Disponibilidade gerenciada

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. Em sua organização Exchange Server, todos os aspectos do sistema devem ser monitorados ativamente e quaisquer problemas detectados devem ser resolvidos rapidamente. Para isso, um recurso chamado Disponibilidade Gerenciada fornece ações internas de monitoramento e recuperação que preservam a experiência do usuário final.

Disponibilidade gerenciada

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?

A disponibilidade gerenciada fornece uma solução de monitoramento e recuperação de integridade nativa. 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 que é executado em todos os servidores do Exchange. 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 aumentará o problema para um administrador com log de eventos.

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

• Serviço do Exchange Health Manager (MSExchangeHMHost.exe): este é 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 é 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.

Componentes de disponibilidade gerenciada

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

Componentes de disponibilidade gerenciada

Sondas

O primeiro componente é chamado de Sonda. As investigações são responsáveis por fazer medições no servidor e coletar dados.

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. As verificações também medem os dados coletados em relação aos limites definidos para determinar picos de falhas do usuário, que permitem 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 que o sistema tome medidas imediatamente, com base em um evento crítico e sem precisar aguardar os resultados dos dados coletados por uma investigação. Há exceções ou condições típicas que podem ser detectadas e reconhecidas sem um conjunto grande de amostras.

As investigações recorrentes são executadas a cada poucos minutos e avaliam 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. Isso é 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 .

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

Monitorar

Os resultados das medidas coletadas pelas sondas fluem para o segundo componente, o Monitor. O monitor contém toda a lógica de negócios usada pelo sistema 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.

Monitora a consulta dos dados para determinar se a ação precisa ser tomada com base em um conjunto de regras predefinido. 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 estados adicionais que aparecem no Shell de Gerenciamento do Exchange:

• 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 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 notar 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. É por isso que 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. Isso incluirá o erro de investigação mais recente.

Respondentes

Por fim, há respondentes, que são responsáveis por ações de recuperação e escalonamento. Tal como indica o nome deles, os respondentes executam algum tipo de resposta a um alerta gerado por um monitor. Quando algo perde integridade, a primeira ação é tentar recuperar esse componente. Isso pode incluir ações de recuperação de 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 colocar o servidor em modo offline, para que ele não aceite mais 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.

Os respondentes tomam várias ações de recuperação, como redefinir um pool de trabalho do aplicativo ou 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 (Internet Information Services).

• 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 registro em 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 componente em Exchange Server (por exemplo, Outlook na Web, Exchange ActiveSync, o serviço da Repositório de Informações, indexação de conteúdo, serviços de transporte etc.) é monitorado pela disponibilidade gerenciada usando investigações, 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. Grupos de integridade são expostos ao System Center Operations Manager 2012 R2.

Há quatro grupos principais de integridade:

• Pontos de toque do cliente Componentes que afetam interações de 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 as dependências necessárias, como Active Directory, DNS e assim por diante.

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, os quais são consumidor pelo monitor no SCOM. São exibidos como alertas no modo de exibição Alertas Ativos.

• Integridade da organização Um resumo de rollup da integridade global da integridade da organização Exchange é mostrada nesse modo de 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 de 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 (isso é conhecido como substituição de servidor) ou podem ser aplicadas a um grupo de servidores (isso é conhecido como uma 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 você configurar uma substituição, ela não entrará em vigor imediatamente. 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 primárias que os administradores normalmente fazem em relação à 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 ferramentas de gerenciamento primário para disponibilidade gerenciada são o Log de Eventos do Windows e o Shell de Gerenciamento do Exchange. 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, inclusive quando a ação de recuperação é iniciada, e ela é considerada completa (com êxito ou não), que são registradas no log de eventos RecoveryActionResults.

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