Consideraciones de diseño del grupo de recursos

Importante

Esta versión de Operations Manager ha llegado al final del soporte técnico. Se recomienda actualizar a Operations Manager 2022.

Un grupo de recursos es una agrupación lógica de servidores de administración o de servidores de puerta de enlace que se distribuyen el trabajo entre sí y asumen el trabajo de un miembro en el que se produzca un error. En otras palabras, proporcionan alta disponibilidad y escalabilidad para los flujos de trabajo. Al diseñar un grupo de administración, se deben realizar consideraciones para supervisar dispositivos de red, los sistemas UNIX/Linux y otras cargas de trabajo que están diseñadas para aprovechar las ventajas de un grupo de recursos.

Información general

Los grupos de recursos garantizan la continuidad de la supervisión al proporcionar varios miembros, que son servidores de administración o servidores de puerta de enlace que pueden asumir flujos de trabajo de supervisión si uno de los miembros del grupo deja de estar disponible. Puede crear grupos de recursos para fines específicos. Por ejemplo, puede crear un grupo de recursos de servidores de administración en su centro de datos primario para supervisar los dispositivos de red.

Los grupos de recursos aplican una lógica similar a la agrupación en clústeres de un “conjunto de nodos de mayoría”, donde (< número de nodos como miembros del grupo >/2) + 1. Como mínimo, debe haber tres miembros en el grupo para mantener el cuórum, que debe ser más del 50 % de los miembros de votación del cuórum en un grupo para mantener la disponibilidad del grupo. Si solo tiene dos miembros del grupo y uno no está disponible, ha perdido el cuórum.

Para cada grupo de recursos creado en la consola del operador, la base de datos de Operations Manager, que se conoce como observador predeterminado, siempre tiene un voto, incluso si tiene un número par de miembros en el grupo para permitir que se alcance el cuórum. Esto también se aplica a los tres grupos de recursos creados de forma predeterminada al crear por primera vez el grupo de administración, que se describe más adelante en este artículo. Para todos los grupos de recursos creados con el cmdlet de PowerShell NewSCOM-ResourcePool, se establece en deshabilitado de manera predeterminada. Al incluir la base de datos de Operations Manager como el observador predeterminado se reduce la complejidad del grupo de administración solo pidiéndole que implemente dos servidores de administración como mínimo para mantener una alta disponibilidad de sus grupos de recursos.

Otro rol que admite un grupo de recursos son los Observadores. Se trata de un servidor de administración o un servidor de puerta de enlace que no participa en la carga de flujos de trabajo para el grupo; sin embargo, participan en decisiones de cuórum. Nunca se usa en circunstancias normales y, por lo tanto, no debe tenerse en cuenta.

Hay dos tipos de pertenencia:

• Automático
• Manual

Cuando crea un grupo de recursos, su suscripción está establecida en manual y no se puede volver a configurar en automático. Cuando se crea un grupo de administración de System Center Operations Manager, se crean de manera predeterminada tres grupos de recursos con pertenencia automática. En la tabla siguiente se describen estos tres grupos de recursos.

Nombre del grupo de recursos	Descripción
Grupo de recursos de todos los servidores de administración	Realiza los flujos de trabajo de cálculo de grupo, disponibilidad, informe del estado de monitor distribuido y limpieza de la base de datos.
Grupo de recursos de notificaciones	Los flujos de trabajo del servicio de suscripción a alertas se destinan a este grupo de recursos para admitir notificaciones de alerta.
Grupo de recursos de asignación de AD	Los flujos de trabajo de integración de AD se destinan a este grupo de recursos para admitir la asignación automática de agentes en los servidores de administración.

Debido a que la pertenencia del grupo de recursos de todos los servidores de administración es automática, cualquier servidor de administración que se inicie se convierte automáticamente en miembro de este grupo de recursos. En ciertas arquitecturas y consideraciones de diseño, como aquellas que incorporan geográficamente operaciones de contingencia dispersa, puede que no se quiera la asignación automática al Grupo de recursos de todos los servidores de administración. En estas situaciones, es posible cambiar la asignación de pertenencia de automática a manual. Como tal, los servidores de administración deben agregarse al Grupo de recursos de todos los servidores de administración mediante la asignación manual.

Nota

La pertenencia al Grupo de recursos de todos los servidores de administración es de solo lectura. Para cambiar su pertenencia de automático a manual, vea Modifying Pool Membership (Modificación de la pertenencia a un grupo).

Con la introducción de los grupos de recursos, se recomienda que todos los miembros estén conectados por una red de baja latencia (menos de 10 ms). Los grupos de recursos no se deben implementar en varios centros de datos ni en un entorno de nube híbrida como Microsoft Azure.

Ejemplos de disponibilidad del grupo de recursos

En los siguientes ejemplos se muestra el concepto de disponibilidad del grupo de recursos basándose en las siguientes configuraciones, solo con los servidores de administración o solo con los servidores de puerta de enlace.

Servidor de administración único

• El observador predeterminado está habilitado de manera predeterminada y no proporciona ninguna ventaja ya que existen solo dos miembros y el cuórum no se alcanza.
• No hay alta disponibilidad porque el servidor de administración es un único punto de error.

Dos servidores de administración

• El observador predeterminado está habilitado de manera predeterminada.
• Hay alta disponibilidad para el grupo porque hay tres miembros de votación: dos servidores de administración y el observador predeterminado.
• Si deshabilita el observador predeterminado, perderá la alta disponibilidad en el grupo.

Tres servidores de administración

• El observador predeterminado está habilitado de manera predeterminada.
• Hay alta disponibilidad para el grupo, ya que hay cuatro miembros de votación: tres servidores de administración y el observador predeterminado.
• De manera predeterminada, solo puede tener un servidor de administración sin disponibilidad para mantener el cuórum. Si dos servidores de administración no están disponibles, tiene exactamente el 50 % de los miembros de votación y el grupo de recursos ya no funciona para administrar las cargas de trabajo de supervisión.
• El observador predeterminado no aumenta el número de servidores de administración que pueden estar fuera de servicio, por lo que no aumenta la disponibilidad del grupo.
• Puede considerar la posibilidad de quitar el observador predeterminado en este escenario.

Cuatro servidores de administración

• El observador predeterminado está habilitado de manera predeterminada.
• Hay alta disponibilidad para el grupo, ya que hay cinco miembros de votación: cuatro servidores de administración y el observador predeterminado.
• De manera predeterminada, solo puede tener dos servidores de administración sin disponibilidad para mantener el cuórum. Si hay tres servidores de administración inactivos, tiene menos del 50 % de los miembros de votación y el grupo de recursos ya no funciona para administrar las cargas de trabajo de supervisión.
• El observador predeterminado en este escenario proporciona un valor significativo, porque aumenta el número de servidores de administración que pueden estar fuera de servicio. Sin el observador predeterminado, solo tendría cuatro miembros de cuórum, que solo permite que uno de ellos no esté disponible.

Cinco servidores de administración

• El observador predeterminado está habilitado de manera predeterminada.
• Hay alta disponibilidad para el grupo, ya que hay seis miembros de votación: cinco servidores de administración y el observador predeterminado.
• De manera predeterminada, solo puede tener dos servidores de administración sin disponibilidad para mantener el cuórum. Si tres servidores de administración no están disponibles, esto supone exactamente un 50 % de miembros de votación y el grupo de recursos ya no funciona para administrar las cargas de trabajo de supervisión.
• El observador predeterminado no aumenta el número de servidores de administración que pueden estar fuera de servicio, por lo que no aumenta la disponibilidad del grupo.
• Puede considerar la posibilidad de quitar el observador predeterminado en este escenario.

Una vez que llegue a tres o más servidores de administración en un grupo de recursos, donde tiene un número impar de miembros en el grupo, puede considerar la posibilidad de quitar el observador predeterminado como miembro. Si llega a cinco servidores de administración, existe la posibilidad de que la base de datos operativa experimente una carga significativa, lo que podría generar suficiente latencia para afectar a los cálculos del grupo de recursos.

Con la manera en que el observador predeterminado desempeña un rol, cada servidor de administración del grupo consulta su propio servicio SDK local, que le permite consultar una tabla en la base de datos operativa para el observador predeterminado. Si la base de datos o el servicio SDK se encuentran bajo carga, experimentará una latencia que no existiría de otro modo.

Servidor de puerta de enlace único

• El observador predeterminado está habilitado de manera predeterminada.
• No hay alta disponibilidad porque el servidor de puerta de enlace es un único punto de error.
• El observador predeterminado no debe usarse aquí porque los servidores de puerta de enlace no tienen un servicio de SDK local y, por lo tanto, no pueden consultar la base de datos operativa.

Dos servidores de puerta de enlace

• El observador predeterminado está habilitado de manera predeterminada.
• No hay alta disponibilidad porque solo hay dos miembros del grupo y el observador predeterminado no es un participante porque los servidores de puerta de enlace no se comunican directamente con la base de datos operativa. Se necesitan tres servidores de puerta de enlace para mantener el cuórum de grupo.

Tres servidores de puerta de enlace

• El observador predeterminado está habilitado de manera predeterminada.
• Hay alta disponibilidad para el grupo porque hay tres miembros de votación: tres servidores de puerta de enlace.
• De forma predeterminada, solo puede tener un servidor de puerta de enlace no disponible para mantener el cuórum. Si dos servidores de puerta de enlace están fuera de servicio, esto supone menos del 50 % de miembros de votación y el grupo de recursos ya no funciona para administrar las cargas de trabajo de supervisión.
• El observador predeterminado no debe usarse aquí porque los servidores de puerta de enlace no tienen un servicio de SDK local y, por lo tanto, no pueden consultar la base de datos operativa.

Supervisión de escenarios compatible con grupos de recursos

Los siguientes flujos de trabajo están hospedados por grupos de recursos en Operations Manager:

• Administración de dispositivos de red
• Administración de agentes de UNIX/Linux
• Supervisión de direcciones URL de aplicaciones web

Nota

Los agentes de Windows no notifican a grupos de recursos.

La supervisión de red en Operations Manager requiere su propio grupo de recursos independiente y dedicado. Esto se debe a que los flujos de trabajo de supervisión de red se ejecutan en los servidores de administración (en el módulo SNMP) y no en los agentes. Esto supone una carga elevada en los servidores de administración cuando incluye la supervisión de puertos de red, especialmente si selecciona la mayoría de los puertos activos disponibles en el dispositivo. Por lo tanto, para mejorar el rendimiento se recomienda utilizar servidores de administración dedicados en grupos de recursos dedicados a la supervisión de red. Además, los servidores de administración que son miembros de este grupo deben quitarse de los grupos de todos los servidores de administración, notificaciones y asignación de AD.

Si es necesario, la supervisión de UNIX/Linux en Operations Manager puede asignarse a un grupo de recursos dedicado para habilitar la supervisión y administración de agente de alta disponibilidad, pero no es obligatorio. Operations Manager usa certificados para autenticar el acceso a los equipos que administra. Cuando el Asistente para detección implementa un agente, recupera el certificado del agente, firma el certificado, implementa el certificado en el agente y, a continuación, reinicia el agente. Para admitir una alta disponibilidad, cada servidor de administración en el grupo de recursos debe tener todos los certificados raíz que se utilizan para firmar los certificados implementados en los agentes en los equipos UNIX y Linux. De lo contrario, si un servidor de administración deja de estar disponible, los demás servidores de administración no podrán confiar en los certificados firmados por el servidor que produjo un error.

Pasos siguientes

Para obtener información sobre cómo crear y administrar grupos de recursos, vea Administración de grupos de recursos.