Consideraciones de diseño del grupo de recursos

Un grupo de recursos es una agrupación lógica de servidores de administración o servidores de puerta de enlace que se usan para distribuir el trabajo entre sí y asumir el trabajo de un miembro con errores. En otras palabras, proporcionan alta disponibilidad y escalabilidad para los flujos de trabajo. Al diseñar un grupo de administración, se deben tener en cuenta las consideraciones para la supervisión de dispositivos de red, sistemas Linux/UNIX y otras cargas de trabajo 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 proporcionando varios miembros, los cuales 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. Puedes crear grupos de recursos con fines específicos. Por ejemplo, puedes crear un grupo de recursos de servidores de administración en tu centro de datos principal 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 en el grupo y uno no está indisponible, pierdes el Quorum.

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 cuentas con un número par de miembros en el grupo para permitir que se alcance el Quorum. Esto también se aplica a los tres grupos de recursos creados de forma predeterminada cuando se crea por primera vez el grupo de administración, el cual se describe más adelante en este artículo. Para todos los grupos de recursos creados con el cmdletde PowerShell NewSCOM-ResourcePool, se establece en deshabilitado de forma predeterminada. La inclusión de la base de datos de Operations Manager como observador predeterminado reduce la complejidad del grupo de administración, ya que solo requiere implementar dos servidores de administración como mínimo para mantener una alta disponibilidad de tus grupos de recursos.

Otro rol que admite un grupo de recursos es el de 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, participa en las decisiones de Quorum. Esto nunca se usa en circunstancias normales y, por lo tanto, no se debe tener en cuenta.

Hay dos tipos de pertenencia:

• Automático
• Manual

Al crear un grupo de recursos, su pertenencia se establece 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
Todos los grupos de recursos de servidores de administración	Realiza flujos de trabajo para el cálculo de grupos, disponibilidad, acumulación de estado de supervisión distribuida y limpieza de bases de datos.
Grupo de recursos de notificaciones	Los flujos de trabajo del Servicio de suscripción de alertas están destinados 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 están destinados a este grupo de recursos para admitir la asignación automática de agentes a los servidores de administración.

Dado que la pertenencia al grupo de recursos de todos los servidores de administración es automática, cualquier servidor de administración a cargo se convierte automáticamente en miembro de este grupo de recursos. En determinadas arquitecturas y consideraciones de diseño, como las que incorporan operaciones de contingencia dispersas geográficamente, es posible que no se desee 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ático a manual. Por lo tanto, los servidores de administración deben agregarse al grupo de recursos todos los servidores de administración mediante la asignación manual.

Nota:

La pertenencia del grupo de recursos de todos los servidores de administración es de solo lectura. Para cambiar su pertenencia de automático a manual, consulta Modificación de la pertenencia al grupo.

Al introducir 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 ejemplos siguientes, se ilustra el concepto de disponibilidad del grupo de recursos en función de las siguientes configuraciones, solo con servidores de administración o solo con servidores de puerta de enlace.

Servidor de administración único

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

Dos servidores de administración

• El observador predeterminado está habilitado por defecto.
• Hay alta disponibilidad para el grupo porque hay tres miembros de votación: dos servidores de administración y el observador predeterminado.
• Si deshabilitas el observador predeterminado, perderás la alta disponibilidad del grupo.

Tres servidores de administración

• El observador predeterminado está habilitado por defecto.
• 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 puedes tener dos servidores de administración sin disponibilidad para mantener el Quorum. Si dos servidores de administración no están disponibles, tienes exactamente el 50 % de los miembros de votación, por lo que 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 inactivos, por lo tanto, no aumenta la disponibilidad del grupo.
• Puedes considerar la posibilidad de quitar el observador predeterminado en este escenario.

Cuatro servidores de administración

• El observador predeterminado está habilitado por defecto.
• 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, tienes 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 de este escenario proporciona un valor significativo, ya que aumenta el número de servidores de administración que pueden estar inactivos. Sin el observador predeterminado, solo tendrías cuatro miembros de Quorum, lo que solo permite que un miembro no esté disponible.

Cinco servidores de administración

• El observador predeterminado está habilitado por defecto.
• Hay alta disponibilidad para el grupo, ya que existen seis miembros de votación: cinco servidores de administración y el observador predeterminado.
• De manera predeterminada, solo puedes tener dos servidores de administración sin disponibilidad para mantener el Quorum. Si no hay tres servidores de administración disponibles, es 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 inactivos, por lo tanto, no aumenta la disponibilidad del grupo.
• Puedes considerar la posibilidad de quitar el observador predeterminado en este escenario.

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

Dada la forma en que el observador predeterminado desempeña un rol, cada servidor de administración del grupo consulta su propio servicio de SDK local, lo que le permite consultar una tabla en la base de datos operativa del 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 por defecto.
• 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 por defecto.
• 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 requieren tres servidores de puerta de enlace para mantener el Quorum del grupo.

Tres servidores de puerta de enlace

• El observador predeterminado está habilitado por defecto.
• Hay alta disponibilidad para el grupo porque hay tres miembros de votación: tres servidores de puerta de enlace.
• De manera predeterminada, solo puedes tener dos servidores de administración sin disponibilidad para mantener el Quorum. Si dos servidores de puerta de enlace están inactivos, se cuenta con menos del 50 % de los miembros de votación, por lo que 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.

Escenarios de supervisión que admiten grupos de recursos

Los siguientes flujos de trabajo se hospedan en grupos de recursos en Operations Manager:

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

Nota:

Los agentes de Windows no informan a los grupos de recursos.

La supervisión de red en Operations Manager requiere su propio grupo de recursos dedicado independiente. Esto se debe a que los flujos de trabajo de supervisión de red se ejecutan en servidores de administración (en el módulo SNMP) y no en los agentes. Esto supone una pesada carga para los servidores de administración una vez que incluyas la supervisión de puertos de red, especialmente si seleccionas la mayoría de los puertos activos disponibles en el dispositivo. Por lo tanto, para mejorar el rendimiento, se recomienda usar servidores de administración dedicados en grupos de recursos dedicados para 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.

La supervisión de Linux/UNIX en Operations Manager se puede asignar a un grupo de recursos dedicado si fuera necesario para habilitar la supervisión de alta disponibilidad y la administración de agentes. No obstante, no es un requisito. Operations Manager usa certificados para autenticar el acceso a los equipos que administra. Cuando el Asistente de detección implementa un agente, recupera el certificado del agente, firma el certificado, vuelve a implementar el certificado en el agente y, a continuación, reinicia al agente. Con miras a posibilitar la compatibilidad con 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 no está disponible, los otros servidores de administración no podrán confiar en los certificados firmados por el servidor en el que se produjo un error.

Pasos siguientes

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