Lições do Datacenter: Disponibilidade Gerenciada

Artikkeli
12/05/2012

Artigo original publicado no sábado, 22 de setembro de 2012

O monitoramento é um componente fundamental para qualquer implantação de sucesso do Exchange. Em versões anteriores, investimos muito no desenvolvimento de um mecanismo de correlação e trabalhamos em conjunto com o grupo de produto SCOM para oferecer uma solução de alerta completa para ambientes do Exchange.

Tradicionalmente, o monitoramento envolvia a coleta de dados e, se necessário, a realização de uma ação com base nos dados coletados. Por exemplo, no contexto do SCOM, diferentes mecanismos foram usados para coletar dados pelo Pacote de Gerenciamento do Exchange:

Tipo de Monitoramento	Exchange 2010
Serviço não funcionando	Regra do manifesto de integridade
Contador de desempenho	Regra de contador do manifesto de integridade
Eventos do Exchange	Regra de evento do manifesto de integridade
Eventos não Exchange	Regra de evento do manifesto de integridade
Scripts, cmdlets	Regra de script do manifesto de integridade
Cmdlets de teste	Testa cmdlets

Metas de Monitoramento do Exchange Server 2013

Quando começamos o desenvolvimento do Exchange 2013, uma área de foco principal foi melhorar o monitoramento ponta a ponta de todas as implantações do Exchange, da menor implantação local à maior implantação do mundo, o Office 365. Tínhamos três grandes metas em mente:

Trazer nosso conhecimento e experiência do serviço Office 365 para clientes locais Por aproximadamente 6 anos, o grupo de produto do Exchange tem operado o Exchange Online. O modelo de operações que usamos é conhecido como modelo de operações do desenvolvedor (DevOps). Neste modelo, os problemas são encaminhados diretamente para o desenvolvedor de um recurso se o recurso está com mau funcionamento com o serviço ou quando um cliente relata um problema desconhecido que é direcionado. Independente da origem do problema, o encaminhamento diretamente para o desenvolvedor oferece a responsabilidade para o desenvolvimento de um software resolvendo os defeitos do software.

Como resultado do uso deste modelo, aprendemos muito. Por exemplo, no Pacote de Gerenciamento do Exchange 2010, há quase 1100 alertas. Mas durante os anos, descobrimos que apenas cerca de 150 destes alertas são úteis no Office 365 (e desabilitamos o resto). Além disso, descobrimos que quando um desenvolvedor recebe uma escalação, é mais provável que são responsáveis e trabalhem para resolver o problema (através de uma correção de código, novos fluxo de trabalho de recuperação, sintonizando o alerta, etc.) porque o desenvolvedor não deseja ser interrompido continuamente ou acordado para resolver o mesmo problema novamente. Dentro do modelo DevOps, temos um processo onde cada semana as chamadas terão uma reunião de participação para revisar os incidentes das últimas semanas; o resultado é que os fluxos de trabalho de recuperação interna são desenvolvidos, como redefinir pools de aplicativos IIS, etc. Antes do Exchange 2013, tínhamos nossos próprios mecanismos internos que lidavam com estes fluxos de trabalho recuperados. Este conhecimento nunca chegou aos produtos locais. Com o Exchange 2013, nós modulado o mecanismo de fluxo de trabalho de recuperação para que as aprendizagens sejam compartilhadas com nossos clientes locais.
Monitoramento baseado na experiência do usuário final Também aprendemos que várias das metodologias usadas para monitoramento não realmente nos ajudava a operar o ambiente. Como resultado, estamos mudando para uma visão focalizada no cliente sobre como abordamos o monitoramento.

Em versões anteriores, cada equipe de componente desenvolveria um modelo de integridade articulando todos os vários componentes dentro do seu sistema. Por exemplo, o transporte é composto de SMTP-IN, SMTP-OUT, agentes de transporte, categorizador, mecanismo de roteamento, unidade de armazenamento, etc. A equipe de componente iria construir alertas sobre cada um destes componentes. No Pacote de Gerenciamento, existem alertas que permitem você saber qual unidade de armazenamento falhou. Mas o que estava faltando é o fato que o alerta não conta sobre a experiência do usuário ponta a ponta ou o que pode estar incorreto nesta experiência. Portanto, no Exchange 2013, estamos tentando mudar o modelo. Estamos nos livrando do nosso monitoramento a nível do sistema porque é importante. Mas o que realmente importa, se você deseja gerenciar um serviço, é o que seus usuários estão vendo? Portanto, mudamos o modelo e estamos nos esforçando para testar e monitorar a experiência do usuário.
Proteja a experiência do usuário através da computação orientada para a recuperação Com as versões anteriores do Exchange, o monitoramento era focado no sistema e componentes e não em como recuperar e restaurar a experiência do usuário final automaticamente.

Monitorando o Exchange Server 2013 - Disponibilidade gerenciada

A Disponibilidade gerenciada é uma infraestrutura de monitoramento e recuperação integrada com a solução de alta disponibilidade do Exchange. A Disponibilidade gerenciada detecta a recupera problemas conforme eles ocorrem e quanto são descobertos.

A Disponibilidade gerenciada é focalizada no usuário. Desejamos medir três aspectos fundamentais – a disponibilidade, a experiência (que para a maioria dos protocolos clientes é medida como latência) e se os erros estão ocorrendo. Para compreender estes três aspectos, vamos ver um exemplo, um usuário utilizando o Outlook Web App (OWA).

O aspecto de disponibilidade é simplesmente se o usuário pode ou não acessar a página da web do OWA de autenticação baseada em formulário. Se não for possível, a experiência é quebrada e isto irá gerar uma orientação de help desk. Em termos de experiência, se eles podem fazer o login no OWA, como é a experiência – a interface carrega, eles podem acessar o email? O último aspecto é a latência – o usuário pode fazer o login e acessar a interface, mas qual a velocidade da renderização de email no navegador? Estas são as áreas que compõe a experiência do usuário final.

Uma diferença fundamental entre as versões anteriores e o Exchange 2013, é que no Exchange 2013 nossa solução de monitoramento não está tentando oferecer a causa principal (isto não significa que os dados não sejam registrados em logs ou as exclusões não sejam geradas ou que a causa principal não possa ser descoberta). É importante compreender que com as versões anteriores, nunca fomos tão eficazes na comunicação da causa principal - algumas vezes estávamos certos, frequentemente errados.

Componentes da Disponibilidade gerenciada

A Disponibilidade gerenciada é integrada nas funções do servidor no Exchange 2013. Inclui três componentes assíncronos principais. O primeiro componente é o mecanismo de teste. A responsabilidade do mecanismo de teste é realizar medições no servidor. Isto flui para o segundo componente, que é o monitor. O monitor contém a lógica comercial que codifica o que é considerado íntegro. Você pensa nele como um mecanismo de reconhecimento de padrão; é olhando para diferentes padrões dentro de diferentes medições que podemos tomar uma decisão sobre se algo é considerado íntegro ou não. Por fim, há o mecanismo do respondedor, que eu indiquei como Recuperação no diagrama abaixo. Quando algo não está íntegro, a primeira ação é tentar recuperar este componente. A Disponibilidade gerenciada oferece ações de recuperação de várias etapas - a primeira tentativa pode ser reiniciar o pool de aplicativos, a segunda tentativa pode ser reiniciar o serviço, a terceira tentativa pode ser reiniciar o servidor e a tentativa final pode ser colocar o servidor offline para que não aceite mais tráfego. Se estas tentativas falharem, a disponibilidade gerenciada encaminha o problema para uma pessoa através da notificação de log de eventos.

Você também pode observar que descentralizamos algumas coisas. No passado, tínhamos o agente SCOM em cada servidor e encaminhávamos todas as medições para um servidor SCOM central. O servidor SCOM precisaria avaliar todas as medições para determinar se algo é íntegro ou não. Em um ambiente de alta escala, a correção complexa funciona sempre. Observamos que este alerta levaria mais tempo para ser iniciado, etc. Colocar tudo em um local central não funciona. Portanto, ao invés de cada servidor agir como uma ilha - cada servidor executa seus testes, se monitora e toma ações para auto-recuperação e, claro, encaminhar se necessário.

Figura 1: Componentes da Disponibilidade gerenciada

Testes

A infraestrutura de teste é composta de três estruturas diferentes:

Os testes são transações sintéticasintegradas por cada equipe de componentes. São semelhantes aos cmdlets de teste em versões anteriores. Os testes medem a percepção do serviço executando transações do usuário ponta a ponta sintéticas.
As verificações são mecanismos de monitoramento passivos. As verificações medem o tráfego do cliente atual.
A estrutura de notificação permitem realizar ações imediatas e não aguardar a execução de um teste. Desta forma, se detectar uma falha, podemos realizar uma ação imediata. A estrutura de notificação é baseada em notificações. Por exemplo, quando o certificado vencer, um evento de notificação é acionado, alertando as operações que o certificado precisa ser renovado.

Monitores

Os dados coletados pelos testes são alimentados em monitores. Não há necessariamente uma correção um a um entre os testes e monitores; vários testes podem alimentar dados em um único monitor. O monitor procura os resultados dos testes e oferece uma conclusão. A conclusão é binária - ou o monitor está íntegro ou não.

Como mencionado anteriormente, o monitoramento do Exchange 2013 focaliza na experiência do usuário final. Para realizar isso, temos que monitorar diferentes camadas no ambiente:

Figura 2: Monitoramento em diferentes camadas para verificar a experiência do usuário

Como você pode ver no diagrama acima, temos quatro verificações diferentes. A primeira verificação é o Auto-teste da caixa de correio; este teste valida se o protocolo local ou interface pode acessar o banco de dados. A segunda verificação é conhecida como auto-teste de protocolo e valida se o protocolo local no Servidor de caixa de correio está funcionando. A terceira verificação é o auto-teste do proxy e executa no servidor de Acesso do Cliente, validando se a funcionalidade do proxy para o protocolo está funcionando. A quarta e última verificação é a verificação completa que valida a experiência do usuário final (proxy do protocolo para as funções de armazenamento). Cada verificação realiza uma detecção em intervalos diferentes.

Monitoramos diferentes camadas para lidar com dependências. Como não há um mecanismo de correlação no Exchange 2013, tentamos diferenciar nossas dependências com códigos de erros exclusivos que correspondem aos diferentes testes e com testes que não incluem dependências de toque. Por exemplo, se você ver um Auto-teste de caixa de correio e um Auto-teste de protocolo falharem ao mesmo tempo, o que isto significa? Isto informa que seu repositório está inativo? Não necessariamente; o que informa é que sua instância de protocolo local no Servidor de caixa de correio não está funcionando. Se você ver um Auto-teste de protocolo funcionando, mas um Auto-teste de caixa de correio em falha, o que isto significa? Este cenário informa que há um problema na camada de "armazenamento" que pode ser que o repositório ou o banco de dados esteja offline.

O que isto significa na perspectiva de monitoramento é que agora temos um maior controle sobre quais alertas são emitidos. Por exemplo, se estamos avaliando a integridade do OWA, provavelmente podemos atrasar o acionamento de um alerta no cenário onde um Auto-teste de caixa de correio falhou, mas um Auto-teste de protocolo funciona. No entanto, um alerta seria iniciado se os monitores de Auto-teste de caixa de correio e Auto-teste de protocolo não estão íntegros.

Respondedores

Os respondedores executam respostas com base nos alertas gerados por um monitor. Os respondedores nunca funcionam a não ser que um monitor não esteja íntegro.

Existem vários tipos de respondedores disponíveis:

Respondedor Reiniciar Finaliza e reinicia o serviço
Respondedor Reiniciar AppPool Reinicia o pool de aplicativos IIS
Respondedor Failover Desativa um servidor de caixa de correio do Exchange 2013
Respondedor Bugcheck Inicia uma verificação de erros do servidor
Respondedor Offline Coloca um protocolo na máquina fora de serviço
Respondedor Encaminhar Encaminha um problema
Respondedor Componente Especializado

O respondedor offline é usado para remover um protocolo de utilização nos servidores do Client Access. Este respondedor foi projetado para ser agnóstico ao balanceador de carga. Quando este respondedor é invocado, o protocolo não reconhecerá a verificação de integridade do balanceador de carga, habilitando o balanceador de carga a remover o servidor ou protocolo do pool de balanceamento de carta. Da mesma forma, há um respondedor online correspondente que é iniciado automaticamente quando o monitor correspondente se torna íntegro novamente (assumindo que não há outro monitor associado em um estado não íntegro) - o respondedor online apenas permite o protocolo responder à verificação de integridade do balanceador de carga, que permite o balanceador de carga a adicionar o servidor ou ou protocolo de volta no pool do balanceador de carga. O respondedor offline pode ser invocado manualmente também através do cmdlet Set-ServerComponentState. Isto permite o administrador colocar manualmente os servidores do Client Access no modo de manutenção.

Quando o respondedor encaminhamento é invocado, gera um evento do Windows que o Pacote de Gerenciamento do Exchange 2013 reconhece. Não é um evento normal do Exchange. Não é mesmo um evento que diz que o OWA está quebrado ou que temos um IO difícil. É um evento do Exchange de que o conjunto de integridade esteja íntegro ou não íntegro. Usamos eventos de única instâncias como este para manipular os monitores dentro do SCOM. Estamos fazendo isto com base em um evento gerado no respondedor encaminhar em oposto aos eventos em todo o produto. Outra forma de pensar sobre ele é um nível de não direção. A Disponibilidade gerenciada decide quando girar um monitor dentro do SCOM. A Disponibilidade gerenciada toma a decisão sobre quando um encaminhamento deve ocorrer ou, em outras palavras, quando uma pessoa deve ser envolvida.

Os respondedores também podem ser acionados para garantir que todo o serviço não esteja comprometido. O acionamento é diferente dependendo do respondedor:

Alguns respondedores levam em conta o número mínimo de servidores dentro do DAG ou pool CAS de carga balanceada
Alguns respondedores levam em conta a quantidade de tempo entre as execuções.
Alguns respondedores levam em conta o número de ocorrências que o respondedor iniciou.
Alguns podem usar qualquer combinação acima.

Dependendo do respondedor, quando o acionamento ocorre, a ação do respondedor pode ser atrasada ou simplesmente ignorada.

Sequências de recuperação

É importante compreender que o monitor define os tipos de respondedores executados e o prazo no qual são executados; é isto que desejamos referir como uma sequência de recuperação para um monitor. Por exemplo, vamos dizer que os dados de teste para o protocolo OWA (o Auto-teste de protocolo) adiciona o monitor como não íntegro. Neste ponto, o horário atual é salvo (iremos chamar isto de T). O monitor começa uma canalização de recuperação baseada na hora atual. O monitor pode definir as ações de recuperação em intervalos de tempo informados dentro da canalização de recuperação. No caso do protocolo SWA monitorar o servidor de Caixa de correio, a sequência de recuperação é:

Em T=0, o respondedor de Reinicialização do Pool de Aplicativos IIS é executado.
Se T=5 minutos, o monitor não foi revertido para um estado íntegro, o respondedor Failover é iniciado e os bancos de dados são retirados do servidor.
Se T=8 minutos, o monitor não foi revertido para um estado íntegro, o respondedor Bugcheck é iniciado e o servidor é reiniciado forçadamente.
Se T=15 minutos, o monitor ainda não foi revertido para um estado íntegro e o respondedor Encaminhar é acionado.

A canalização da sequência de recuperação irá parar quando o monitor se tornar íntegro. Observe que a ação nomeada por último não precisa concluir antes da próxima ação iniciar. Além disso, um monitor pode ter vários intervalos de tempo nomeado.

Systems Center Operations Manager (SCOM)

O Systems Center Operations Manager (SCOM) é usado como um portal para ver a informação de integridade relacionada ao ambiente do Exchange. Estados não íntegros dentro do portal SCOM são acionados por eventos gravados no log de aplicativos através do respondedor Encaminhar. O painel SCOM foi refinado e agora possui três áreas principais:

Alertas ativos
Integridade da organização
Integridade do servidor

O Pacote de Gerenciamento SCOM do Exchange Server 2013 será suportado com o SCOM 2007 R2 e SCOM 2012.

Substituições

Com qualquer ambiente, os padrões nem sempre podem ser a melhor condição ou as condições podem existir que exigem uma ação de emergência. A Disponibilidade gerenciada inclui a capacidade de substituir todo o ambiente ou um servidor individual. Cada substituição pode ser definida por uma duração específica ou para aplicar a uma versão específica do servidor. Os cmdlets *-ServerMonitoringOverride e *-GlobalMonitoringOverride permitem os administradores definirem, removerem ou exibirem substituições.

Determinação de integridade

Monitores muito semelhantes ou vinculados a uma determinada arquitetura de componente são agrupados para formar conjuntos de integridade. A integridade de um conjunto de integridade é sempre determinada pela "pior" avaliação dos monitores dentro do conjunto de integridade – isto significa que se você possui 9 monitores dentro de um conjunto de integridade e 1 monitor não está íntegro, o conjunto de integridade é considerado não íntegro. É possível determinar o conjunto de monitores (testes e respondedores associados) em um determinado conjunto de integridade usando o cmdlet Get-MonitoringItemIdentity.

Para exibir a integridade, você usa os cmdlets Get-ServerHealth e Get-HealthReport. Get-ServerHealth é usado para recuperar os dados de integridade brutos, enquanto Get-HealthReport opera em dados de integridade brutos e oferece uma visão atual da integridade. Estes cmdlets podem operar em várias camadas:

Podem mostrar a integridade para um determinado servidor, detalhado pelo conjunto de integridade.
Podem ser usados para detalhar um determinado conjunto de integridade e ver o status de cada monitor.
Podem ser usados para resumir a integridade de um determinado conjunto de servidores (membros DAG ou matriz de carga balanceada do CAS).

Conjuntos de integridade são mais agrupados em unidades funcionais chamados Grupos de Integridade. Existem quatro Grupos de Integridade e eles são usados para relatórios dentro do Portal de Gerenciamento SCOM:

Pontos de Toque do Cliente – componentes com interações do cliente diretas em tempo real (por exemplo, OWA).
Componentes de Serviço – componentes sem interação do cliente direta em tempo real (por exemplo, geração de OAB).
Componentes do Servidor – recursos físicos de um servidor (por exemplo, disco, memória).
Disponibilidade de Dependência – capacidade do servidor de chamar dependências (por exemplo, Active Directory).

Conclusão

A Disponibilidade gerenciada realiza uma variedade de avaliações de integridade dentro de cada servidor. Estes testes regulares e periódicos determinam a viabilidade de vários componentes no servidor, que estabelece a integridade do servidor (ou conjunto de servidores) antes e durante a carga do usuário. Quando problemas são detectados, ações corretivas de várias etapas são trazidas para o servidor para colocá-lo em um estado de funcionamento. No caso onde os servidores não voltam para um estado íntegro, a Disponibilidade gerenciada pode alertar os operadores que é necessário ter atenção;

O resultado final é que a Disponibilidade gerenciada focaliza na experiência do usuário e garante que enquanto problemas ocorrerem, a experiência é minimamente impactada, se for impactada.

Ross Smith IV Gerente Principal do ProgramaExperiência do Cliente do Exchange

Greg "O Pai do Exchange HA" Thiel Arquiteto Gerente do Programa PrincipalExchange Server

Esta é uma publicação de blog traduzida. Consulte o artigo original sobre a Lessons from the Datacenter: Managed Availability

Jaa