Lecciones del centro de datos: disponibilidad administrada

Artículo original publicado el sábado, 22 de septiembre de 2012

La supervisión es un componente clave de cualquier implementación de Exchange. En versiones anteriores, invertimos mucho en el desarrollo de un motor de correlación y mantuvimos una colaboración estrecha con el grupo de productos de System Center Operations Manager (SCOM) para ofrecer una solución de alertas completa en los entornos de Exchange.

Tradicionalmente, la supervisión implicaba recopilar datos y, si era necesario, realizar una acción basada en los datos recopilados. Por ejemplo, en el contexto de SCOM, se usaban distintos mecanismos para recopilar datos a través del módulo de administración de Exchange:

Objetivos de supervisión de Exchange Server 2013

Cuando empezamos a crear Exchange 2013, una de las áreas más importantes era mejorar la supervisión de un extremo a otro en todas las implementaciones de Exchange, desde la implementación local más pequeña hasta la implementación más grande del mundo: Office 365. Nos marcamos tres objetivos principales:

1. Ofrecer nuestra experiencia y nuestros conocimientos del servicio Office 365 a los clientes locales: el grupo de productos de Exchange lleva casi 6 años ofreciendo Exchange Online. El modelo de operaciones que usamos se conoce como "modelo de operaciones de desarrollador" (DevOps). En este modelo, los problemas se remiten directamente al desarrollador de una característica si esta funciona mal dentro del servicio o cuando un cliente informa de un problema desconocido que se remite. Independientemente del origen del problema, remitir un problema directamente al desarrollador enfatiza la responsabilidad del desarrollo del software y permite solucionar los defectos del software.

   Usando este modelo hemos aprendido mucho. Por ejemplo, en el módulo de administración de Exchange 2010, existen casi 1.100 alertas, pero con el paso de los años, hemos observado que solo unas 150 de estas son útiles en Office 365, así que deshabilitamos el resto. Además, nos dimos cuenta de que cuando se remite un problema a un desarrollador, hay más probabilidades de que este asuma la responsabilidad y trabaje para solucionar el problema (con revisiones de código, con flujos de trabajo de recuperación nuevos, ajustando la alerta, etc.) porque el desarrollador no quiere que lo estén interrumpiendo ni despertando para solucionar el mismo problema una y otra vez. Dentro del modelo DevOps, todas las semanas los que están de guardia celebran una reunión de entrega para revisar los incidentes de la semana anterior: el resultado es el desarrollo de flujos de trabajo de recuperación internos, como el restablecimiento de grupos de aplicaciones de IIS, etc. Antes de Exchange 2013, teníamos un motor interno que administraba estos flujos de trabajo de recuperación, pero nunca llegamos a incorporar estos conocimientos en los productos locales. Con Exchange 2013, compartimentamos el motor del flujo de trabajo de recuperación para poder compartir los conocimientos con los clientes locales.

2. Supervisar basándonos en la experiencia del usuario final: también hemos observado que muchas de las metodologías que usábamos para supervisar realmente no nos ayudaban a trabajar en el entorno. Como consecuencia, vamos a empezar a basar la supervisión en un enfoque centrado en el cliente.

   En versiones anteriores, cada equipo de componentes desarrollaba un modelo de estado incluyendo todos los componentes dentro del sistema. Por ejemplo, el transporte se compone de SMTP-IN, SMTP-OUT, agentes de transporte, categorizador, motor de enrutamiento, controlador de almacenamiento, etc. Luego, el equipo de componentes creaba alertas sobre cada uno de estos componentes. Además, en el módulo de administración existen alertas que le avisan de que el controlador de almacenamiento ha fallado. Lo que falta aquí es que la alerta nos dé información sobre la experiencia del usuario de un extremo a otro o sobre lo que falla en la experiencia. Por eso, en Exchange 2013 estamos intentando darle la vuelta al modelo. No nos desharemos de la supervisión de nivel de sistema porque es importante, pero más importante aún si queremos administrar un servicio es saber lo que ven los usuarios. Para averiguarlo, hemos dado la vuelta al modelo y estamos trabajando para supervisar la experiencia del usuario.

3. Proteger la experiencia del usuario a través de la informática orientada a la recuperación: en las versiones anteriores de Exchange, la supervisión se centraba en el sistema y los componentes, no en la forma de recuperar y restaurar la experiencia del usuario final automáticamente.

Supervisar Exchange Server 2013: disponibilidad administrada

La disponibilidad administrada es una infraestructura de supervisión y recuperación que está integrada con la solución de alta disponibilidad de Exchange. La disponibilidad administrada detecta problemas y se recupera de ellos en cuanto se producen y descubren.

La disponibilidad administrada se centra en el usuario. Queremos medir tres aspectos fundamentales: la disponibilidad, la experiencia (que, en la mayoría de los protocolos cliente, se mide como latencia) y si se producen errores. Para comprender estos tres aspectos, vamos a ver el ejemplo de un usuario que trabaja con Outlook Web App (OWA).

El aspecto de la disponibilidad consiste simplemente en si el usuario puede o no obtener acceso a la página web de la autenticación basada en formularios de OWA. Si no puede, la experiencia del usuario se interrumpe y el problema se remite al servicio de asistencia. Si puede iniciar sesión en OWA, analizamos cómo es la experiencia: ¿la interfaz se carga?, ¿puede obtener acceso al correo? El último aspecto es el de la latencia: el usuario puede iniciar sesión y obtener acceso a la interfaz, pero ¿con qué rapidez se representa el correo en el explorador? Estas son las áreas que componen la experiencia del usuario final.

Una diferencia fundamental entre versiones anteriores y Exchange 2013 es que, en Exchange 2013, la solución de supervisión no intenta entregar la causa raíz (esto no significa que los datos no se anoten en los registros, que no se generen volcados ni que no se descubra la causa raíz). Es importante entender que en ninguna de las versiones anteriores conseguimos comunicar de forma eficaz la causa raíz: a veces acertábamos; otras, no.

Componentes de la disponibilidad administrada

La disponibilidad administrada está integrada en ambos roles de servidor en Exchange 2013. Incluye tres componentes asincrónicos principales. El primero de ellos es el motor de sondeo. La responsabilidad del motor de sondeo es tomar medidas en el servidor, lo que nos lleva al segundo componente, el monitor. El monitor contiene la lógica de negocios que codifica lo que consideramos un buen estado. Podemos verlo como un motor de reconocimiento de patrones que busca distintos patrones dentro de las medidas que tenemos y luego puede decidir si el estado de algo es bueno o no. Por último, tenemos el motor respondedor, que he denominado Recuperar en el diagrama de abajo. Cuando el estado de algo no es bueno, lo primero que se debe hacer es intentar recuperar el componente. La disponibilidad administrada ofrece acciones de recuperación de varias fases: el primer intento puede ser el de reiniciar el grupo de aplicaciones; el segundo, el de reiniciar el servicio; el tercero, el de reiniciar el servidor; y el último, el de desconectar el servidor para que deje de aceptar tráfico. Si estos intentos no dan resultado, la disponibilidad administrada remitirá el problema a una persona mediante una notificación de registro de evento.

También verá que hemos descentralizado algunas cosas. Antes teníamos el agente de SCOM en todos los servidores y transmitíamos todas las medidas a un servidor de SCOM central. El servidor de SCOM evaluaba todas las medidas para determinar si algo tenía un buen estado o no. En un entorno a gran escala, la compleja correlación complica las cosas. Lo que hemos observado es que las alertas tardarían más en saltar, etc. Si insertábamos todo en el mismo sitio, no se producía la remisión, por lo que hemos hecho que cada servidor actúe como una isla para que ejecute sus propios sondeos, se supervise a sí mismo y haga las acciones necesarias para recuperarse automáticamente y, si es necesario, remitir problemas.

Ilustración 1: Componentes de la disponibilidad administrada

Sondeos

La infraestructura de sondeos se compone de tres marcos independientes:

1. Los sondeos son transacciones sintéticascreadas por cada equipo de componentes. Se parecen a los cmdlets de prueba de versiones anteriores. Los sondeos miden la percepción del servicio ejecutando transacciones sintéticas de usuario de un extremo a otro.
2. Las comprobaciones son un mecanismo de supervisión pasiva. Miden el tráfico real del cliente.
3. El marco de notificaciones nos permite tomar acciones inmediatas sin esperar que se ejecute un sondeo. Así, si detectamos un error, podemos actuar rápidamente. Este marco se basa en las notificaciones. Por ejemplo, cuando un certificado expira, se desencadena un evento de notificación para alertar a las operaciones de que hay que renovar el certificado.

Monitores

Los datos recopilados por los sondeos se transmiten a los monitores. No existe necesariamente una correlación unívoca entre sondeos y monitores: muchos sondeos pueden transmitir datos a un solo monitor. Los monitores miran los resultados de los sondeos y llegan a una conclusión, que es binaria: el estado del monitor solo puede ser bueno o deficiente.

Como ya he señalado, la supervisión de Exchange 2013 se centra en la experiencia del usuario final. Para lograr esto, tenemos que supervisar en distintas capas del entorno:

Ilustración 2: Se supervisa en distintas capas para analizar la experiencia del usuario

Como vemos en el diagrama de arriba, existen cuatro comprobaciones distintas. La primera es la prueba automática de buzón; este sondeo valida que el protocolo local o la interfaz puedan obtener acceso a la base de datos. La segunda se conoce como prueba automática de protocolo y valida que el protocolo local del servidor Buzón de correo funcione. La tercera es la prueba automática de proxy y se ejecuta en el servidor Acceso de clientes para validar que las funciones del proxy correspondientes al protocolo funcionen. La cuarta y última es una comprobación inclusiva que valida la experiencia de un extremo a otro (del proxy de protocolo a las funciones de almacén). Cada comprobación efectúa detecciones a diversos intervalos.

Supervisamos en capas diferentes para tratar las dependencias. Como en Exchange 2013 no hay motor de correlación, intentamos diferenciar las dependencias con códigos de error únicos que se corresponden con distintos sondeos y con sondeos que no incluyen dependencias adyacentes. Por ejemplo, si ve que una prueba automática de buzón y una prueba automática de protocolo fallan a la vez, ¿esto qué le dice? ¿Significa que el almacén no funciona? No necesariamente; lo que nos dice seguro es que la instancia del protocolo local del servidor Buzón de correo no funciona. Si ve una prueba automática de protocolo correcta, pero la prueba automática de buzón tiene errores, ¿qué está pasando? Este escenario nos dice que hay un problema en la capa "almacenamiento" que se puede deber a que el almacén o la base de datos estén desconectados.

Desde el punto de vista de la supervisión, esto significa que ahora tenemos un control más preciso sobre las alertas que se emiten. Por ejemplo, si evaluamos el estado de OWA, es más probable que una alerta tarde más en saltar en el escenario en que la prueba automática de buzón falla pero la prueba automática de protocolo funciona. Sin embargo, si el estado de los monitores de estas dos pruebas no fuese bueno, saltaría una alerta.

Respondedores

Los respondedores ejecutan respuestas basándose en las alertas generadas por un monitor siempre que el estado del monitor sea deficiente.

Hay varios tipos de respondedores disponibles:

• Reiniciar respondedor: cierra y reinicia el servicio
• Reiniciar respondedor AppPool: ejecuta el grupo de aplicaciones de IIS en ciclos
• Respondedor de conmutación por error: deja sin funcionamiento un servidor Buzón de correo de Exchange 2013
• Respondedor de comprobación de errores: inicia una comprobación de errores del servidor
• Respondedor desconectado: deja sin funcionamiento el protocolo de una máquina
• Remitir respondedor: remite un problema
• Respondedores con componentes especializados 

El respondedor desconectado se usa para quitar un protocolo de los servidores Acceso de clientes. Este respondedor se ha designado para admitir distintos equilibradores de carga. Cuando el respondedor se invoca, el protocolo no reconoce la comprobación de estado del equilibrador de carga; de esta forma, el equilibrador de carga puede quitar el servidor o el protocolo del grupo de equilibrio de carga. Igualmente, existe un respondedor en línea correspondiente que se inicia automáticamente cuando el monitor correspondiente vuelve a tener buen estado (suponiendo que no haya otros monitores asociados que tengan un estado deficiente). El respondedor en línea permite al protocolo responder a la comprobación de estado del equilibrador de carga y esto, a su vez, permite al equilibrador de cargar agregar nuevamente el servidor o el protocolo al grupo de equilibradores de carga. El respondedor desconectado también se puede invocar manualmente a través del cmdlet Set-ServerComponentState, lo que permite a los administradores poner los servidores Acceso de clientes en el modo de mantenimiento manualmente.

Cuando el respondedor de remisiones se invoca, genera un evento de Windows que el módulo de administración de Exchange 2013 reconoce. No se trata de un evento de Exchange normal; no es un evento que indique que OWA no funcione o que la ES haya sido complicada. Es un evento de Exchange que dice que un conjunto de estados es bueno o deficiente. Usamos eventos de instancia única como ese para manipular los monitores en SCOM basándonos en un evento generado en el respondedor de remisiones en lugar de en eventos propagados por el producto. Otra forma de mirarlo es según el nivel de direccionamiento indirecto. La disponibilidad administrada decide cuándo damos la vuelta a un monitor en SCOM y cuándo se debe remitir algo o, lo que es lo mismo, cuándo se necesita la participación humana.

Los respondedores también pueden limitarse para asegurar que el funcionamiento del servicio completo no se vea afectado. La limitación varía según el respondedor:

• Algunos respondedores tienen en cuenta el número mínimo de servidores que hay en el DAG o en el grupo de CAS con carga equilibrada.
• Algunos respondedores tienen en cuenta el tiempo transcurrido entre ejecuciones.
• Algunos respondedores tienen en cuenta el número de veces que el respondedor se inició.
• Algunos pueden usar una combinación de lo anterior.

En función del respondedor, la acción de este puede verse retrasada o directamente omitida cuando se produce la limitación.

Secuencias de recuperación

Es importante entender que los monitores definen los tipos de respondedores que se ejecutan y la escala de tiempo en que lo hacen; esto es lo que conocemos como secuencia de recuperación de un monitor. Supongamos, por ejemplo, que los datos de sondeo del protocolo de OWA (la prueba automática de protocolo) desencadenan un estado deficiente en el monitor. En este momento, se guarda el tiempo actual (lo llamaremos T). El monitor inicia una canalización de recuperación basada en el tiempo actual y puede definir acciones de recuperación a intervalos temporales con nombre en la canalización de recuperación. En el caso del monitor del protocolo de OWA que hay en el servidor Buzón de correo, la secuencia de recuperación es la siguiente:

1. Cuando T=0, se ejecuta el respondedor Restablecer grupo de aplicaciones de IIS.
2. Si cuando T=5 minutos el monitor no ha revertido a un estado bueno, se inicia el respondedor Conmutación por error y las bases de datos se quitan del servidor.
3. Si cuando T=8 minutos el monitor no ha revertido a un estado bueno, se inicia el respondedor Comprobaciones de errores y el servidor se reinicia a la fuerza.
4. Si cuando T=15 minutos el monitor sigue sin revertir a un estado bueno, se desencadena el respondedor Remitir.

La canalización de la secuencia de recuperación parará cuando el monitor tenga un buen estado. Recuerde que no es necesario que la última acción temporal con nombre termine para que se inicie la siguiente acción temporal con nombre. Además, un monitor puede tener cualquier cantidad de intervalos temporales con nombre.

Systems Center Operations Manager (SCOM)

Systems Center Operations Manager (SCOM) es un portal que contiene información de estado relacionada con el entorno de Exchange. Los estados deficientes que hay en el portal SCOM los desencadenan eventos escritos en el registro de aplicaciones a través del respondedor Remitir. El panel de SCOM se ha perfeccionado y ahora tiene tres áreas principales:

• Alertas activas
• Estado de la organización
• Estado del servidor

El módulo de administración de Exchange Server 2013 SCOM será compatible con SCOM 2007 R2 y SCOM 2012.

Reemplazos

En cualquier entorno puede suceder que los valores predeterminados no sean la mejor opción o que existan condiciones que exijan una acción de urgencia. La disponibilidad administrada incluye la posibilidad de habilitar reemplazos en todo el entorno o en un solo servidor. Cada reemplazo se puede configurar durante un tiempo determinado o para que se aplique a una versión concreta del servidor. Los cmdlets *-ServerMonitoringOverride y *-GlobalMonitoringOverride permiten a los administradores establecer, quitar o ver reemplazos.

Determinación de estado

Los monitores que se parecen o están ligados a la arquitectura de un componente en particular se agrupan en conjuntos de estados. El estado de un conjunto de estados siempre está determinado por la peor evaluación de todos los monitores del conjunto de estados. Esto significa que si hay 9 monitores dentro de un conjunto de estados y 1 monitor tiene un estado deficiente, el conjunto de estados se considerará deficiente. Puede determinar la colección de monitores (y los sondeos y respondedores asociados) en un conjunto de estados concreto usando el cmdlet Get-MonitoringItemIdentity.

Para ver el estado, use los cmdlets Get-ServerHealth y Get-HealthReport. Get-ServerHealth se usa para recuperar los datos de estado sin procesar, mientras que Get-HealthReport trabaja con estos datos y proporciona una instantánea actual del estado. Estos cmdlets pueden funcionar en diversas capas:

• Pueden mostrar el estado de un servidor dado desglosándolo por conjunto de estados.
• Se pueden usar para analizar un conjunto de estados concreto y ver el estado de cada monitor.
• Se pueden usar para resumir el estado de un conjunto de servidores determinado (miembros de DAG o una matriz con carga equilibrada de CAS).

Los conjuntos de estados se agrupan a su vez en unidades funcionales denominadas "grupos de estados". Existen cuatro grupos de estados, que se usan para crear informes dentro del portal de administración de SCOM:

1. Puntos de contacto con el cliente: componentes con interacción directa y en tiempo real con el cliente (por ej., OWA).
2. Componentes de servicio: componentes sin interacción directa y en tiempo real con el cliente (por ej., generación de OAB).
3. Componentes de servicio: recursos físicos de un servidor (por ej., disco, memoria).
4. Disponibilidad de las dependencias: capacidad del servidor para llamar a las dependencias (por ej., Active Directory).

Conclusión

La disponibilidad administrada realiza diversas evaluaciones de estado en cada servidor. Estas pruebas periódicas determinan la viabilidad de varios componentes en el servidor, los cuales establecen el estado del servidor (o conjunto de servidores) antes y durante la carga de usuarios. Cuando se encuentran problemas, se adoptan medidas correctoras de varios pasos para que el servidor vuelva a estar en funcionamiento. En el caso de que el servidor no vuelva a tener un buen estado, la disponibilidad administrada puede alertar a los operadores para que lo revisen.

El resultado final es que la disponibilidad administrada se centra en la experiencia del usuario y garantiza que, aunque se produzcan problemas, la repercusión que tengan en la experiencia sea mínima o nula.

Esta publicación del blog es una traducción. Puede leer el artículo original en Lessons from the Datacenter: Managed Availability