Disponibilidad administrada

Se aplica a: Exchange Server 2013 SP1

Garantizar que los usuarios tengan una buena experiencia de correo electrónico siempre ha sido el objetivo principal de los administradores del sistema de mensajería. Para ayudar a garantizar la disponibilidad y confiabilidad de la organización de Microsoft Exchange Server 2013, todos los aspectos del sistema deben supervisarse activamente y los problemas detectados deben resolverse rápidamente. En versiones anteriores de Exchange, la supervisión de componentes críticos del sistema normalmente implicaba el uso de una aplicación externa como Microsoft System Center 2012 Operations Manager para recopilar datos y proporcionar una acción de recuperación para los problemas detectados como resultado del análisis de los datos recopilados. Exchange 2010 y versiones anteriores incluían manifiestos de estado y motores de correlación en forma de módulos de administración. Estos componentes permitieron a Operations Manager determinar si un componente determinado era correcto o incorrecto. Además, Operations Manager también usó la infraestructura de cmdlets de diagnóstico integrada en Exchange 2010 para ejecutar transacciones sintéticas en diversos aspectos del sistema.

Exchange 2013 adopta un nuevo enfoque para supervisar y conservar la experiencia del usuario final de forma nativa mediante una característica denominada Disponibilidad administrada que proporciona acciones integradas de supervisión y recuperación.

La disponibilidad administrada, también conocida como Supervisión activa o Supervisión activa local, es la integración de acciones integradas de supervisión y recuperación con la plataforma de alta disponibilidad de Exchange. Está diseñada para detectar y solucionar problemas a medida que surgen y que el sistema los detecta. A diferencia de las técnicas y soluciones de supervisión externas para Exchange, la disponibilidad administrada no intenta identificar ni comunicar la causa principal de un problema. En cambio, está enfocada en los aspectos de recuperación que abordan tres áreas clave de la experiencia del usuario:

• Disponibilidad: ¿Pueden los usuarios acceder al servicio?
• Latencia: ¿Cómo es la experiencia para los usuarios?
• Errores: ¿Los usuarios pueden lograr lo que quieren?

La consolidación de roles de servidor y otros cambios arquitectónicos en Exchange 2013 requieren un nuevo enfoque para las metodologías de supervisión y el modelo de mantenimiento usados en versiones anteriores de Exchange. La disponibilidad administrada está diseñada para abordar estos cambios proporcionando una solución nativa de supervisión y recuperación de estado. Se aleja de la supervisión de segmentos independientes individuales del sistema para supervisar la experiencia integral del usuario, y protege la experiencia del usuario final mediante acciones orientadas a la recuperación.

La disponibilidad administrada es un proceso interno que se ejecuta en cada servidor de Exchange 2013. Sondea y analiza cientos de métricas de mantenimiento cada segundo. Si se encuentra que algo está mal, la mayor parte del tiempo se solucionará automáticamente. Pero siempre habrá problemas que la disponibilidad administrada no podrá solucionar por sí sola. En esos casos, la disponibilidad administrada remitirá el problema a un administrador por medio del registro de eventos.

Disponibilidad administrada implementada en forma de dos servicios:

• Servicio Exchange Health Manager (MSExchangeHMHost.exe): este servicio es un proceso de controlador que se usa para administrar los procesos de trabajo. Se usa para crear, ejecutar, iniciar y detener procesos de trabajo, según sea necesario. También se usa para recuperar procesos de trabajo en caso de que generen errores, para evitar que los procesos de trabajo sean un punto único de error.

• Proceso de trabajo del Administrador de mantenimiento de Exchange (MSExchangeHMWorker.exe): este servicio es el proceso de trabajo responsable de realizar tareas en tiempo de ejecución dentro del marco de disponibilidad administrado.

La disponibilidad administrada usa el almacenamiento persistente para realizar sus funciones:

• Los archivos XML en la carpeta \bin\Monitoring\config se utilizan para almacenar valores de configuración para algunos de los elementos de trabajo de sondeo y supervisión.
• Active Directory se utiliza para almacenar reemplazos globales.
• El Registro de Windows se utiliza para almacenar datos de tiempo de ejecución, como marcadores y reemplazos locales (específicos del servidor).
• La infraestructura de registro de eventos de canal Crimson de Windows se utiliza para almacenar los resultados de los elementos de trabajo.
• Los buzones de mantenimiento se utilizan para la actividad de sondeo. Se crearán varios buzones de mantenimiento en cada base de datos de buzones de correo que existe en el servidor.

Como se ilustra en el siguiente diagrama, la disponibilidad administrada incluye tres componentes principales asincrónicos que están funcionando constantemente.

El primer componente se denomina sondeo. Los sondeos son responsables de tomar medidas en el servidor y recopilar datos. Los resultados de esas medidas fluyen al segundo componente, monitor. El monitor contiene la lógica empresarial que usa el sistema en función de lo que se considere como un estado correcto en los datos recopilados. De manera similar a un motor de reconocimiento de patrones, el monitor busca los diferentes patrones en todas las medidas recopiladas y, luego, decide si algo es correcto o no. Por último, hay respondedores, que son los responsables de las acciones de escalación y recuperación. Cuando hay algo incorrecto, la primera acción es intentar recuperar dicho componente. Este esfuerzo de recuperación podría incluir acciones de recuperación en varias fases; por ejemplo, el primer intento puede ser reiniciar el grupo de aplicaciones, el segundo puede ser reiniciar el servicio, el tercer intento puede ser reiniciar el servidor y el intento posterior puede ser desconectar el servidor para que ya no acepte tráfico. Si las acciones de recuperación fracasan, el sistema escala el problema a la persona a través de las notificaciones de registro de eventos.

Hay tres categorías principales de sondeos: sondeos recurrentes, notificaciones y comprobaciones. Los sondeos recurrentes son transacciones sintéticas realizadas por el sistema para probar la experiencia integral del usuario. Las comprobaciones son la infraestructura que realiza la recopilación de datos de rendimiento, incluido el tráfico de usuario, y mide los datos recopilados con respecto a los umbrales establecidos para determinar los picos de errores del usuario. Esta funcionalidad de medición permite que la infraestructura de comprobaciones se tenga en cuenta cuando los usuarios experimentan problemas. Por último, la lógica de notificación permite al sistema tomar medidas inmediatamente en función de un evento crítico, sin tener que esperar a los resultados de los datos recopilados por un sondeo. Estas excepciones o condiciones se pueden detectar y reconocer sin un conjunto de ejemplo grande.

Los sondeos recurrentes se ejecutan cada pocos minutos y comprueban algún aspecto del estado del servicio. Estos sondeos pueden transmitir un correo electrónico mediante Exchange ActiveSync al buzón de supervisión, pueden conectarse a un punto de conexión de RPC o pueden comprobar la conectividad del acceso de cliente al buzón de correo.

Todos los sondeos se definen en el inicio del servicio del administrador de mantenimiento en el canal crimson Microsoft.Exchange.ActiveMonitoring\ProbeDefinition. Cada definición de sondeo tiene muchas propiedades, pero las propiedades más relevantes son:

• Nombre: nombre del sondeo, que comienza con un SampleMask del monitor del sondeo.
• TypeName: el tipo de objeto de código del sondeo que contiene la lógica del sondeo.
• ServiceName: nombre del conjunto de mantenimiento que contiene este sondeo.
• TargetResource: objeto que el sondeo está validando. Este nombre de propiedad se anexa al nombre del sondeo cuando se ejecuta para convertirse en un resultado de sondeo ResultName.
• RecurrenceIntervalSeconds: frecuencia con la que se ejecuta el sondeo.
• TimeoutSeconds: cuánto tiempo esperará el sondeo antes de que se produce un error.

Hay cientos de sondeos recurrentes. Muchos de estos sondeos se realizan según la base de datos, por lo tanto, a medida que aumenta el número de bases de datos, aumenta la cantidad de sondeos. La mayoría de los sondeos se definen en código y, por ende, no se pueden detectar directamente.

Los conceptos básicos de un sondeo recurrente son los siguientes: se inicia cada RecurrenceIntervalSeconds y comprueba (o sondea) algún aspecto del mantenimiento. Si el componente está en buen estado, el sondeo pasa y escribe un evento informativo en el canal Microsoft.Exchange.ActiveMonitoring\ProbeResult con un ResultType de 3. Si la comprobación no se realiza correctamente o se agota el tiempo de espera, el sondeo presenta un error y escribe un evento de error en el mismo canal. Un ResultType de 4 significa que se produjo un error en la comprobación y un ResultType de 1 significa que se agotó el tiempo de espera. Muchos sondeos se volverán a ejecutar si agotan el tiempo de espera, hasta el valor de la propiedad MaxRetryAttempts .

Las notificaciones son sondeos que no ejecutan el marco del administrador de mantenimiento, sino otro servicio del servidor. Estos servicios ejecutan su propia supervisión y suministran sus datos al marco de disponibilidad administrada al escribir directamente los resultados de los sondeos. No podrá ver estos sondeos en el canal ProbeDefinition, ya que en este canal solo se describen los sondeos que ejecuta el marco de disponibilidad administrada. Por ejemplo, el monitor ServerOneCopyMonitor se desencadena por los resultados de los sondeos escritos por el servicio MSExchangeDAGMgmt. Este servicio lleva a cabo su propia supervisión, determina si hay un problema y registra un resultado de sondeo. La mayoría de los sondeos de notificación tienen la capacidad de registrar tanto un evento rojo que indica que el monitor presenta errores y un evento en verde que representa que el monitor está nuevamente en mantenimiento.

Las comprobaciones son sondeos que solo registran eventos cuando un contador de rendimiento está por encima o por debajo de un umbral definido. Se trata de un caso realmente especial de sondeos de notificación, ya que hay un servicio que supervisa los contadores de rendimiento en el servidor y registra los eventos del canal ProbeResult cuando se alcanza el umbral configurado.

Para encontrar el contador y el umbral que se considera incorrecto, puede buscar en el monitor esta comprobación. Los monitores del tipo Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor o Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor significan que el sondeo que ven es un sondeo de comprobación.

Los monitores consultan los datos recopilados por los sondeos para determinar si es necesario realizar una acción basada en un conjunto de reglas predefinido. Según la regla o la naturaleza del problema, un monitor puede iniciar un respondedor o remitir el problema a una persona mediante una entrada del registro de eventos. Además, los monitores definen cuánto tiempo después de un error se ejecuta un respondedor y el flujo de trabajo de la acción de recuperación. Los monitores tienen diversos estados. Desde una perspectiva de estado del sistema, los monitores tienen dos estados:

• Correcto: el monitor funciona correctamente y todas las métricas recopiladas están dentro de los parámetros operativos normales.
• Incorrecto: el monitor no está en buen estado y ha iniciado la recuperación a través de un respondedor o ha notificado a un administrador a través de la escalación.

Desde una perspectiva administrativa, los monitores tienen muchos más estados que aparecen en el shell:

• Degradado: cuando un monitor está en un estado incorrecto de 0 a 60 segundos, se considera degradado. Si un monitor tiene un estado incorrecto durante más de 60 segundos, se considera incorrecto.
• Deshabilitado: un administrador ha deshabilitado explícitamente el monitor.
• No disponible: el servicio Microsoft Exchange Health consulta periódicamente a cada monitor su estado. Si no obtiene una respuesta a la consulta, el estado del monitor es no disponible.
• Reparación: un administrador establece el estado De reparación para indicar al sistema que una acción correctiva está en proceso por parte de un humano, lo que permite al sistema y a los seres humanos diferenciar entre otros errores que pueden producirse al mismo tiempo que se realizan acciones correctivas (como una operación de resección de copia de base de datos).

Cada monitor tiene una propiedad SampleMask en su definición. A medida que se ejecuta el monitor, busca eventos en el canal ProbeResult que tengan un resultName que coincida con samplemask del monitor. Estos eventos pueden provenir de sondeos recurrentes, notificaciones o comprobaciones. Si se alcanzan los umbrales del monitor, es incorrecto. Desde la perspectiva del monitor, los tres tipos de sondeos son iguales ya que cada uno registra resultados en el canal ProbeResult.

Cabe mencionar que un solo sondeo incorrecto no indica necesariamente que hay algo mal en el servidor. El diseño de los monitores es el que identifica correctamente cuando hay un problema real que debe corregirse. Por lo tanto, muchos monitores tienen umbrales de varios errores de sondeo antes de convertirse en incorrectos. Incluso los respondedores pueden corregir automáticamente muchos de estos problemas, por lo que el mejor sitio en el que debe buscar problemas que requieren intervención manual es en el canal crimson Microsoft.Exchange.ManagedAvailability\Monitoring. Este canal incluye el error de sondeo más reciente.

Como su nombre indica, los respondedores ejecutan cierto tipo de respuesta para una alerta que ha generado un monitor. Los respondedores realizan varias acciones de recuperación, como restablecer un grupo de trabajo de aplicaciones para reiniciar un servidor. Hay varios tipos de respondedores:

• Reiniciar respondedor: finaliza y reinicia un servicio
• Restablecer AppPool Respondedor: detiene y reinicia un grupo de aplicaciones en Internet Information Services (IIS)
• Respondedor de conmutación por error: inicia una conmutación por error de servidor o base de datos
• Respondedor de comprobación de errores: inicia una comprobación de errores del servidor, lo que provoca un reinicio del servidor.
• Respondedor sin conexión: toma un protocolo de un servidor fuera del servicio (rechaza las solicitudes de cliente)
• Respondedor en línea: vuelve a colocar un protocolo en un servidor en producción (acepta solicitudes de cliente)
• Escalado del respondedor: escala el problema a un administrador mediante el registro de eventos

Además de los respondedores enumerados anteriormente, algunos componentes también tienen respondedores especializados que son exclusivos de su componente.

Todos los respondedores incluyen el comportamiento de limitación, que proporciona un mecanismo de secuenciación integrado para controlar las acciones del respondedor. El comportamiento de limitación está diseñado para garantizar que el sistema no está en peligro o haya empeorado como resultado de las acciones de recuperación del respondedor. Todos los respondedores están limitados de alguna manera. Cuando se produce la limitación, es posible que se omita o retrase la acción de recuperación del respondedor, según la acción de respuesta. Por ejemplo, cuando se limita el respondedor de comprobación de errores, su acción se omite y no se retrasa.

Conjunto de mantenimiento

Desde una perspectiva de creación de informes, la disponibilidad administrada tiene dos vistas de mantenimiento: una interna y otra externa. La vista interna usa conjuntos de mantenimiento. Cada componente de Exchange 2013 (por ejemplo, Outlook Web App, Exchange ActiveSync, el servicio almacén de información, la indexación de contenido, los servicios de transporte, etc.) se supervisa mediante la disponibilidad administrada mediante sondeos, monitores y respondedores. Un grupo de sondeos, monitores y respondedores para un componente determinado se denomina conjunto de mantenimiento. Un conjunto de mantenimiento es un grupo de sondeos, monitores y respondedores que determinan si el componente está en buen estado. El estado actual de un conjunto de mantenimiento (por ejemplo, si es correcto o incorrecto) se determina mediante el estado de los monitores del conjunto de mantenimiento. Si todos los monitores del conjunto de mantenimiento están en buen estado, el conjunto de mantenimiento está en buen estado. Si un monitor no está en buen estado, el estado del conjunto de mantenimiento se determinará por su monitor menos correcto.

Para obtener los pasos detallados para ver el estado de los conjuntos de mantenimiento o el mantenimiento del servidor, vea Manage health sets and server health.

Grupos de mantenimiento

La vista externa de disponibilidad administrada consta de grupos de mantenimiento. Los grupos de mantenimiento se exponen a System Center Operations Manager 2007 R2 y System Center Operations Manager 2012.

Hay cuatro grupos de mantenimiento principales:

• Puntos táctiles del cliente: componentes que afectan a las interacciones del usuario en tiempo real, como los protocolos o el almacén de información
• Componentes del servicio: componentes sin interacciones directas del usuario en tiempo real, como el servicio de replicación de buzones de Microsoft Exchange o el proceso de generación de libreta de direcciones sin conexión (OABGen)
• Componentes del servidor: los recursos físicos del servidor, como el espacio en disco, la memoria y las redes
• Disponibilidad de dependencias: la capacidad del servidor para acceder a las dependencias necesarias, como Active Directory, DNS, etc.

Cuando se instala el módulo de administración de Exchange, System Center Operations Manager (SCOM) actúa como un portal de mantenimiento para ver información relacionada con el entorno de Exchange. El panel de SCOM incluye tres vistas de mantenimiento de servidor de Exchange:

• Alertas activas: los respondedores de escalado escriben eventos en el registro de eventos de Windows que consume el monitor dentro de SCOM. Estos eventos aparecen como alertas en la vista Alertas activas.
• Mantenimiento de la organización: en esta vista se muestra un resumen del estado general del estado de la organización de Exchange. Estos paquetes acumulativos incluyen la visualización de mantenimiento para grupos de disponibilidad de bases de datos individuales y mantenimiento dentro de sitios específicos de Active Directory.
• Estado del servidor: los conjuntos de mantenimiento relacionados se combinan en grupos de mantenimiento y se resumen en esta vista.

Reemplazos

Los reemplazos proporcionan a un administrador la capacidad para configurar algunos aspectos de los sondeos, monitores y respondedores de disponibilidad administrada. Los reemplazos se pueden usar para ajustar algunos de los umbrales utilizados por la disponibilidad administrada. También se pueden usar para habilitar acciones de emergencia para eventos inesperados que pueden requerir parámetros de configuración distintos de los valores predeterminados de fábrica.

Las invalidaciones se pueden crear y aplicar a un único servidor (este proceso se conoce como invalidación de servidor) o se pueden aplicar a un grupo de servidores (este proceso se conoce como invalidación global). Los datos de configuración de reemplazo del servidor se almacenan en el Registro de Windows en el servidor en el que se aplica el reemplazo. Los datos de configuración de reemplazo global se almacenan en Active Directory.

Los reemplazos se pueden configurar para que duren indefinidamente o se pueden configurar para una duración determinada. Además, los reemplazos globales se pueden aplicar a todos los servidores o solo a los servidores que ejecutan una versión específica de Exchange.

Al configurar un reemplazo, este no surte efecto inmediatamente. El servicio de administración del estado de Microsoft Exchange busca datos de configuración actualizados cada 10 minutos. Además, los reemplazos globales serán dependientes de la latencia de replicación de Active Directory.

Para obtener pasos detallados para ver o configurar invalidaciones globales o de servidor, consulte Configuración de invalidaciones de disponibilidad administrada.

Cmdlets y tareas de administración

Existen tres tareas operativas principales que normalmente los administradores realizan con respecto a la disponibilidad administrada:

• Extracción o visualización del mantenimiento del sistema
• Visualización de conjuntos de mantenimiento y detalles sobre sondeos, monitores y respondedores
• Administración de reemplazos

Las dos herramientas principales de administración para la disponibilidad administrada son el registro de eventos de Windows y el Shell. Los registros de disponibilidad administrada constituyen una gran cantidad de información en el registro de eventos de canal Crimson ActiveMonitoring y ManagedAvailability de Exchange.

• Definiciones de sondeo, monitor y respondedor, que se registran en los respectivos registros de eventos de *definición.
• Resultados de sondeo, monitor y respondedor, que se registran en los respectivos registros de eventos de *resultados.
• Más información acerca de las acciones de recuperación del respondedor, incluso cuando se inicia la acción de recuperación y se considera completa (ya sea correcta o no), que se registran en el registro de eventos de RecoveryActionResults.

Se usan 12 cmdlets para la disponibilidad administrada, los cuales se describen en la tabla siguiente.