Disponibilidad administrada

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. En la organización Exchange Server, todos los aspectos del sistema deben supervisarse activamente y los problemas detectados deben resolverse rápidamente. Para conseguir esto, una característica denominada Disponibilidad administrada proporciona acciones de recuperación y supervisión integradas que conservan la experiencia del usuario final.

Disponibilidad administrada

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 disponibilidad administrada proporciona una supervisión de mantenimiento nativo y una solución de recuperación. 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 exchange. 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 elevará el problema a un administrador con registro de eventos.

La disponibilidad administrada se implementa mediante dos servicios:

• Servicio Exchange Health Manager (MSExchangeHMHost.exe): se trata de 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 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.

Componentes de disponibilidad administrada

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

Componentes de disponibilidad administrada

Sondeos

El primer componente se denomina sondeo. Los sondeos son responsables de tomar medidas en el servidor y recopilar datos.

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. Estas también miden los datos recopilados según umbrales definidos para determinar puntas en los errores de usuario, que permite que la infraestructura de comprobaciones sepa cuándo tienen problemas los usuarios. Por último, la lógica de notificación permite que el sistema actúe inmediatamente según un evento crítico, y sin tener que esperar los resultados de los datos recopilados mediante un sondeo. Por lo general, estas son excepciones o condiciones que se pueden detectar y reconocer sin un conjunto grande de muestras.

Los sondeos recurrentes se ejecutan cada pocos minutos y evalúan algún aspecto del mantenimiento 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 El nombre del conjunto de mantenimiento que contiene el sondeo.

• TargetResource El objeto que está validando el sondeo. Esto se anexa al nombre del sondeo cuando se ejecuta para convertirse en un resultado de sondeo ResultName.

• RecurrenceIntervalSeconds La frecuencia de ejecución del sondeo.

• TimeoutSeconds El tiempo que esperará el sondeo antes de presentar 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.

Supervisar

Los resultados de las medidas recopiladas por los sondeos se reflejan en el segundo componente, el monitor. El monitor contiene la lógica empresarial que usa el sistema 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, después, decide si algo es correcto o no.

Los monitores consultan los datos para determinar si es necesario realizar alguna acción según 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 estados adicionales que aparecen en el Shell de administración de Exchange:

• 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 De mantenimiento de Exchange 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.

Vale la pena tener en cuenta que un único error de sondeo no indica necesariamente que algo está mal con el servidor. Es el diseño de monitores para identificar correctamente cuándo hay un problema real que debe corregirse. Esta es la razón por la que muchos monitores tienen umbrales incorrectos de varios sondeos antes de presentar errores. 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. Incluirá el error de sondeo más reciente.

Respondedores

Por último, hay respondedores, que son los responsables de las acciones de escalación y recuperación. Como su nombre indica, los respondedores ejecutan cierto tipo de respuesta para una alerta que ha generado un monitor. Cuando algo no es correcto, la primera acción es intentar recuperar el componente. Esto puede incluir acciones de recuperación de varias etapas; por ejemplo, el primer intento puede ser reiniciar el grupo de aplicaciones; el segundo, reiniciar el servicio; el tercero, reiniciar el servidor y, el próximo, desconectar el servidor de modo 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.

Los respondedores realizan varias acciones de recuperación, como restablecer un grupo de trabajo de aplicaciones o reiniciar un servidor. Hay varios tipos de respondedores:

• Respondedor de reinicio: termina y reinicia un servicio.

• Respondedor de restablecimiento de grupo de aplicaciones: 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 en el servidor, lo que provoca un reinicio del servidor.

• Respondedor sin conexión: toma un protocolo en un servidor fuera de servicio (rechaza solicitudes del cliente).

• Respondedor en línea: vuelve a colocar un protocolo en un servidor en producción (acepta solicitudes del cliente).

• Respondedor de remisión: remite 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 Server (por ejemplo, Outlook en la Web, 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 están expuestos en System Center Operations Manager 2012 R2.

Hay cuatro grupos de mantenimiento principales:

• Puntos de contacto 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 buzón de Microsoft Exchange o el proceso de generación de las listas 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 remisión escriben eventos en el registro de eventos de Windows que usa el monitor en SCOM. Estas aparecen como alertas en la vista de alertas activas.

• Mantenimiento de la organización En esta vista se muestra un resumen acumulativo 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.

• Mantenimiento 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.

Los reemplazos se pueden crear y aplicar a un servidor único (lo que se conoce como reemplazo de servidor) o se pueden aplicar a un grupo de servidores (lo que se conoce como reemplazo 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 una invalidación, no surtirá 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

Hay tres tareas operativas principales que los administradores normalmente realizarán 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 de administración principales para la disponibilidad administrada son el registro de eventos de Windows y el Shell de administración de Exchange. 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.

• Detalles sobre las acciones de recuperación del respondedor, incluso cuando se inicia la acción de recuperación y se considera completa (correcta o no), que se registran en el registro de eventos RecoveryActionResults.

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