Planear el diseño de un grupo de administración

Importante

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

Información general

Un grupo de administración se caracteriza por una única base de datos operativa, por uno o más servidores de administración y por uno o más agentes y dispositivos supervisados. Si se conectan grupos de administración, se pueden ver y editar alertas y otros datos de supervisión desde una única consola. De igual modo, se pueden iniciar tareas desde un grupo de administración local para que se ejecuten en objetos administrados de un grupo de administración conectado.

La implementación más sencilla de Operations Manager es un grupo de administración único. Cada grupo adicional requiere al menos una base de datos operativa y un servidor de administración propios. Asimismo, cada grupo debe mantenerse por separado con su propia configuración, sus módulos de administración y su integración con otras soluciones de supervisión e ITSM.

La implementación distribuida de grupos de administración constituirá la base del 99 por ciento de las implementaciones de Operations Manager. Permite la distribución de características y servicios en varios servidores para hacer posible la escalabilidad y redundancia de algunas de esas características. Puede incluir todos los roles de servidor de Operations Manager y admite la supervisión de dispositivos a través de límites de confianza mediante el servidor de puerta de enlace.

En el diagrama siguiente se presenta una posible opción para la topología del grupo de administración distribuida.

Nota

No hay comunicación directa entre la consola del operador y las bases de datos. Todas las comunicaciones se dirigen a un servidor de administración específico a través del puerto TCP 5724 y, tras esto, a los servidores de base de datos a través de OLE DB en el puerto TCP 1433, o bien en un puerto definido por el usuario especificado por el administrador de SQL durante la instalación de la instancia del motor de base de datos de SQL Server. Sin embargo, hay comunicación directa entre una consola de Diagnóstico de aplicaciones (colocada con la consola web) y el SQL Server hospedar las bases de datos operativas y de almacenamiento de datos.

Un grupo de administración que ha implementado en su entorno puede integrarse con Microsoft Operations Management Suite (OMS) y mediante Log Analytics, puede correlacionar, visualizar y actuar sobre el rendimiento, los eventos y las alertas. Esto le proporciona una mayor visibilidad al poder realizar búsquedas personalizadas en todo el conjunto de datos con el fin de correlacionar los datos entre sistemas y aplicaciones, hospedados en el entorno local o en la nube.

La integración con Operations Manager es extensible a otros productos como BMC Remedy, IBM, Netcool u otras soluciones de administración empresarial que se usen en la organización. Para más información sobre cómo planear la interoperabilidad con estas soluciones, vea Integration with other enterprise management products (Integración con otros productos de administración empresarial).

Componentes de grupo de administración

Servidor de administración

En Operations Manager 2007, el Servidor de administración raíz (RMS) era un tipo especializado de servidor de administración en un grupo de administración y fue el primer servidor de administración que se instaló en un grupo de administración. El RMS era el punto focal desde donde administrar la configuración del grupo de administración, administrar y comunicarse con los agentes y comunicarse con la base de datos operativa y otras bases de datos del grupo de administración. El RMS también servía como destino de la Consola del operador y como destino preferido para las consolas web. En System Center 2012 R2 Operations Manager se quitó el rol de Servidor de administración raíz, de modo que todos los servidores de administración ahora se encuentran en mismo nivel. Esta configuración sigue siendo así en System Center 2016 - Operations Manager y versiones posteriores.

El RMS ya no es un punto único de posible error, puesto que todos los servidores de administración hospedan los servicios que anteriormente solo hospedaba el RMS. Los roles se distribuyen a todos los servidores de administración. Si un servidor de administración no está disponible, sus responsabilidades se redistribuyen automáticamente. Un rol de emulador de RMS proporciona compatibilidad con versiones anteriores para los módulos de administración que tienen el RMS como destino. Si no tiene ningún módulo de administración destinado anteriormente a RMS, no tendrá que usar el emulador de RMS.

El grupo de administración puede contener varios servidores de administración para ofrecer capacidad adicional y disponibilidad continua. Cuando se agregan dos o más servidores de administración a un grupo de administración, estos pasan automáticamente a formar parte de los tres grupos de recursos predeterminados y el trabajo se distribuye entre los miembros del grupo. En los grupos de recursos definidos por el usuario, los miembros se agregan manualmente. Cuando se produce un error en un miembro del grupo de recursos, otros miembros del grupo de recursos se encargarán de asumir la carga de trabajo de ese miembro. Cuando se agrega un nuevo servidor de administración, el nuevo servidor de administración recoge automáticamente parte del trabajo de los miembros existentes del grupo de recursos. Revise Consideraciones de diseño del grupo de recursos para obtener más información sobre cómo funcionan y las recomendaciones que influyen en el plan de diseño.

Si un servidor de administración no está disponible por cualquier motivo, los agentes que dependan de él conmutarán por error automáticamente a otro servidor de administración. Al seleccionar el número y la ubicación de los servidores de administración, esta posibilidad de conmutación por error deberá tenerse en consideración cuando la alta disponibilidad sea un requisito.

Los agentes se conectan a un servidor de administración para comunicarse con otros componentes de Operations Manager. Una de las tareas realizadas por un servidor de administración consiste en tomar los datos enviados por los agentes e insertarlos en la base de datos operativa y en el almacenamiento de datos.

Un servidor de administración al uso se encargará aproximadamente de 3000 agentes. Si bien el rendimiento real de un servidor depende del volumen de datos operativos recopilados, cada servidor de administración suele tener cabida para 3000 agentes, incluso con un volumen de datos operativos relativamente alto.

No hay ningún límite en el número máximo de servidores de administración por grupo de administración. Sin embargo, es recomendable usar el menor número posible de servidores de administración después de abordar las restricciones de escalabilidad, alta disponibilidad y recuperación ante desastres.

Los servidores de administración deben tener una buena conectividad de red con el almacenamiento de datos y con la base de datos de Operations Manager, ya que envían grandes volúmenes de información a estos almacenes con bastante frecuencia. Estas conexiones de SQL Server suelen consumir más ancho de banda y son más sensibles a la latencia de red. Por lo tanto, conviene que todos los servidores de administración estén en la misma red de área local que la base de datos operativa y la base de datos de Data Warehouse y que nunca se implementen en una red de área local. Debe haber al menos una latencia inferior a 10 milisegundos entre un servidor de administración y la instancia de SQL Server que hospeda las bases de datos de Operations Manager.

Servidor de puerta de enlace

Operations Manager requiere que la autenticación mutua se realice entre agentes y servidores de administración antes del intercambio de información entre ellos. Para proteger el proceso de autenticación entre los dos, el proceso está cifrado. Cuando el agente y el servidor de administración residen en el mismo dominio de Active Directory o en dominios de Active Directory que han establecido relaciones de confianza, se sirven de los mecanismos de autenticación de Kerberos V5 proporcionados por Active Directory. Cuando los agentes y los servidores de administración no se encuentran dentro del mismo límite de confianza, se deben usar otros mecanismos para satisfacer el requisito de autenticación mutua segura.

Los servidores de puerta de enlace se usan cuando un firewall separa los agentes de los servidores de administración o cuando los agentes están en un dominio independiente que no es de confianza. El servidor de puerta de enlace actúa como un proxy entre los agentes y el servidor de administración. Sin el servidor de puerta de enlace, los agentes pueden seguir autenticando certificados con un servidor de administración, aunque para ello habría que emitir e instalar un certificado X.509 en cada agente mediante la herramienta MOMCertImport.exe, y cada uno de ellos necesitaría tener acceso al servidor de administración a través del firewall. Si los agentes están en el mismo dominio que el servidor de puerta de enlace o si están en un dominio de confianza, se puede usar la autenticación Kerberos. En tal caso, solo serán necesarios certificados para el servidor de puerta de enlace y los servidores de administración conectados. Esto incluye la supervisión de máquinas virtuales que se ejecutan en la infraestructura como servicio (IaaS) de Microsoft Azure, con Operations Manager (es decir, la supervisión en la nube híbrida) que no está unida al mismo dominio kerberos de confianza que los roles que admiten el grupo de administración de Operations Manager o ha implementado Operations Manager en IaaS de Azure (una máquina virtual con SQL Server hospedar las bases de datos operativas y una o varias máquinas virtuales que hospedan el rol de servidor de administración) y supervisan las cargas de trabajo locales que no son de confianza.

Este es un ejemplo de implementación de Operations Manager que supervisa recursos de IaaS de Azure.

Este es un ejemplo de implementación de Operations Manager hospedado en IaaS de Azure.

Normalmente, los servidores de puerta de enlace no se usan para administrar el uso del ancho de banda porque el volumen general de datos enviados desde agentes a un servidor de administración es similar si se usa o no un servidor de puerta de enlace. El propósito previsto de un servidor de puerta de enlace es reducir el esfuerzo necesario para administrar certificados para agentes en dominios que no son de confianza y reducir el número de rutas de comunicación que se deben permitir a través de firewalls.

• Tener más de 2000 agentes por servidor de puerta de enlace puede afectar negativamente a la capacidad de recuperarse en caso de una interrupción sostenida que impida que el servidor de puerta de enlace se comunique con el servidor de administración. Se recomienda usar varios servidores de puerta de enlace si se necesitan más de 2000 agentes. La alternativa, si el tiempo de recuperación del servidor de puerta de enlace es un problema, es probar el sistema para asegurarse de que el servidor de puerta de enlace puede vaciar rápidamente su cola después de una interrupción sostenida entre el servidor de puerta de enlace y el servidor de administración. Además, después de que la cola de entrada en el servidor de puerta de enlace se llene, los datos de la cola se quitan según la prioridad establecida, lo que significa que una interrupción constante del servidor de puerta de enlace en este escenario puede provocar pérdidas de datos.
• Cuando hay un gran número de agentes conectados a través de servidores de puerta de enlace, considere la posibilidad de usar un servidor de administración dedicado para todos los servidores de puerta de enlace. Tener todos los servidores de puerta de enlace conectados a un único servidor de administración sin ningún otro agente conectado a él puede acelerar el tiempo de recuperación en caso de una interrupción sostenida. La carga eficaz en el servidor de administración es el número total de agentes que dependen de él, ya sea directamente o a través de servidores de puerta de enlace.
• Para evitar que el servidor de puerta de enlace inicie la comunicación con un servidor de administración, incluido cuando se configura para conmutar por error entre varios servidores de administración para lograr alta disponibilidad, la herramienta de aprobación de puerta de enlace incluye el argumento de línea de comandos /ManagementServerInitiatesConnection. Esto permite a Operations Manager respetar la directiva de seguridad de un cliente cuando se implementan sistemas en una red perimetral o en otro entorno de red y la comunicación solo se puede iniciar desde la intranet.

Servidor de consola web

La consola web proporciona una interfaz del grupo de administración que es accesible a través de un explorador web. No tiene toda la funcionalidad de la consola del operador y proporciona acceso solo a las vistas Supervisión y Mi área de trabajo. La consola web da acceso a todos los datos de supervisión y las tareas que son acciones que se pueden ejecutar en los equipos supervisados desde la Consola del operador. El acceso a datos en la consola web presenta las mismas restricciones que el acceso al contenido en la Consola del operador.

Servidor de informes

Reporting for System Center – Operations Manager is installed on SQL Server Reporting Services (that is supported by the version of Operations Manager you're using) and the only valid configuration of Reporting Services supported by Operations Manager Reporting is native mode.

Nota

La instalación de System Center - Operations Manager Reporting Services integra la seguridad de la instancia de SQL Reporting Services con la seguridad basada en roles de Operations Manager. No instale ninguna otra aplicación de Reporting Services en esta misma instancia del SQL Server.

Los componentes de Operations Manager Reporting Server se pueden instalar en el mismo servidor que ejecuta SQL Server 2014 o 2016 Reporting Services o en otro equipo. Para obtener un rendimiento óptimo, especialmente en un entorno empresarial con generación de informes paralelos de gran volumen por parte de los usuarios mientras los informes interactivos o programados se procesan simultáneamente, debe escalar verticalmente para controlar más usuarios simultáneos y cargas de ejecución de informes más grandes. Se recomienda que el servicio Operations Manager Reporting no esté ubicado en la misma SQL Server que hospeda la base de datos de almacenamiento de datos e instalada en un sistema dedicado.

Base de datos operativa

La base de datos operativa es una base de datos de SQL Server que contiene todos los datos operativos, la información de configuración y las reglas de supervisión de un grupo de administración. La base de datos de Operations Manager es un único origen de error para el grupo de administración, por lo que se puede hacer que esté altamente disponible con configuraciones admitidas de agrupación en clústeres.

Para mantener esta base de datos con un tamaño uniforme, la configuración de limpieza de Operations Manager especifica la cantidad de tiempo que se pueden conservar datos en ella. Esta duración es de siete (7) días de forma predeterminada.

Base de datos de almacenamiento de datos de informes

El almacenamiento de datos de informes es una base de datos de SQL Server que recopila y almacena los datos operativos para los informes a largo plazo. Estos datos se escriben directamente a partir de reglas que recopilan datos para los informes y a partir de procesos de sincronización de datos en la base de datos operativa. El mantenimiento del almacenamiento de datos, incluidas su agregación, limpieza y optimización, se realiza automáticamente en Operations Manager.

En la siguiente tabla se indican los tipos de datos predeterminados y el período de retención tras la instalación inicial de la base de datos de almacenamiento de datos.

Dataset	Tipo de agregación	Período de retención (en días)
Alerta	Raw	400
Supervisión de cliente	Raw	30
Supervisión de cliente	Diario	400
Eventos	Raw	100
Rendimiento	Raw	10
Rendimiento	Cada hora	400
Rendimiento	Diario	400
State	Raw	180
State	Cada hora	400
State	Diario	400

Un almacenamiento de datos puede prestar servicio a varios grupos de administración. Gracias a esto, un informe puede contener datos procedentes de todos los equipos de la organización.

Al igual que la base de datos de Operations Manager, la base de datos de almacenamiento de datos se puede agrupar para disponer de alta disponibilidad. Si no está agrupado, debe supervisarse cuidadosamente para que se puedan solucionar rápidamente los problemas.

Recopilador de ACS

El recopilador de ACS recibe y procesa eventos de los reenviadores de ACS y, a continuación, envía estos datos a la base de datos de ACS. Este procesamiento incluye el desensamblado de los datos para que se pueda distribuir entre varias tablas dentro de la base de datos de ACS, lo que minimiza la redundancia de datos y aplica filtros para que no se agreguen eventos innecesarios a la base de datos de ACS.

Base de datos de ACS

La base de datos de ACS es el repositorio central para eventos que se generan a partir de una directiva de auditorías en una implantación de ACS. La base de datos de ACS se puede ubicar en el mismo equipo que el recopilador de ACS pero, para obtener un rendimiento óptimo, cada uno de ellos debe instalarse en un servidor dedicado. Los datos se conservan durante catorce (14) días de forma predeterminada.

Reenviador de ACS

Este servicio, ejecutado en los reenviadores de ACS, está incluido en el agente Operations Manager. Este servicio se instala de forma predeterminada cuando se instala el agente Operations Manager, pero no se habilita. Para habilitarlo para varios equipos con agente de una sola vez, use la tarea para habilitar la recopilación de auditorías o PowerShell. Una vez habilitado, todos los eventos de seguridad se envían al recopilador de ACS además de al registro de seguridad local.

Consideraciones de diseño

Los siguientes factores deben tenerse en cuenta a la hora de decidir si implementar uno o varios grupos de administración:

• Mayor capacidad. Operations Manager no tiene ningún límite integrado en cuanto al número de agentes que puede admitir un único grupo de administración. Según el hardware que se use y la carga de supervisión del grupo de administración (más módulos de administración implementados se traduce en una mayor carga de supervisión), puede que se necesiten varios grupos de administración para mantener un rendimiento aceptable.
• Vistas consolidadas. Cuando se usan varios grupos de administración para supervisar un entorno, se necesita un mecanismo que proporcione una vista consolidada de los datos de supervisión y alertas procedentes de ellos. Esto se puede realizar implementando un grupo de administración extra (que puede o no tener responsabilidades de supervisión) que tenga acceso a todos los datos de todos los demás grupos de administración. Así, de estos grupos de administración se dice que están conectados. El grupo de administración que se usa para proporcionar una vista consolidada de los datos se denomina grupo de administración local, mientras que los otros grupos que le proporcionan datos se conocen como grupos de administración conectados.
• Seguridad y administración. La creación de particiones de grupos de administración por motivos administrativos y de seguridad es similar en concepto a la delegación de autoridad administrativa sobre unidades organizativas o dominios de Active Directory a diferentes grupos administrativos. Su empresa puede incluir varios grupos de TI, cada uno con su propia área de responsabilidad. El área podría ser una división empresarial o un área geográfica determinada. Por ejemplo, en el caso de una sociedad de cartera, puede ser una de las empresas filiales. Cuando exista este tipo de delegación completa de la autoridad administrativa desde el grupo de TI centralizado, podría ser útil implementar una estructura de grupos de administración en cada una de las áreas. Luego, se pueden configurar como grupos de administración conectados a un grupo de administración local que esté en el centro de datos de TI centralizado.
• Idiomas instalados. Todos los servidores que tengan un rol de servidor de Operations Manager instalado en ellos deben estar instalados en el mismo idioma. Es decir, no puede instalar el servidor de administración mediante la versión en inglés de Operations Manager 2012 R2 y, a continuación, implementar la consola del operador mediante la versión japonesa. Si la supervisión debe abarcar varios idiomas, se necesitará un grupo de administración extra por cada idioma de los operadores.
• Funcionalidad de producción y preproducción. En Operations Manager, se recomienda tener una implementación de producción que se use para supervisar las aplicaciones de producción y una implementación de preproducción que tenga una interacción mínima con el entorno de producción. El grupo de administración de preproducción se usa para probar y optimizar la funcionalidad del módulo de administración antes de migrarla al entorno de producción. Por otra parte, algunas empresas emplean un entorno de ensayo donde los servidores recién creados se colocan durante un período de prueba antes de ponerlos en producción. El grupo de administración de preproducción se puede usar para supervisar el entorno de ensayo para garantizar el estado de los servidores antes de la implementación de producción.
• Funcionalidad de ACS dedicada. Si los requisitos incluyen la necesidad de recopilar eventos de registro de seguridad de auditoría de Windows o eventos de seguridad unix/Linux, implementará el servicio de recopilación de auditorías (ACS). Puede que sea conveniente implementar un grupo de administración que admita la función de ACS exclusivamente si los requisitos de seguridad de su compañía exigen que la función de ACS esté controlada y administra por un grupo administrativo distinto del que administra el resto del entorno de producción.
• Funcionalidad de recuperación ante desastres. En Operations Manager, todas las interacciones con la base de datos de Operations Manager se registran en los registros de transacciones antes de asignarse a la base de datos. Estos registros de transacciones se pueden enviar a otro servidor que ejecuta Microsoft SQL Server y confirmarse en una copia de la base de datos de Operations Manager allí. Esta característica es una opción que proporciona redundancia de la base de datos operativa de Operations Manager entre dos servidores SQL Server en el mismo grupo de administración. Cuando hay que realizar una conmutación por error controlada, los servidores de administración del grupo de administración requieren un cambio en el Registro para poder hacer referencia al servidor SQL Server secundario y comunicarse con él. Se puede implementar un grupo de administración de conmutación por error, que coincide con la configuración exacta del grupo de administración principal (módulos de administración, invalidaciones, suscripciones de notificación, seguridad, etc.) y los agentes están configurados para informar a ambos grupos de administración. Si el grupo de administración principal en su totalidad deja de estar disponible por cualquier motivo, no hay tiempo de inactividad del entorno de supervisión. Esta solución garantiza la continuidad del servicio del grupo de administración y que no se va a producir ninguna pérdida de supervisión operativa.

Antes de implementar System Center Operations Manager en un entorno de producción, planee el diseño del grupo de administración. Durante la fase de planificación, comprender los componentes del servicio de TI (es decir, infraestructura y nivel de aplicación) y el número de sistemas y dispositivos que los admiten, cómo integrará y apoyará los procesos de administración de incidentes y problemas, y cómo visualizará los datos de los distintos niveles de soporte técnico de escalación de incidentes, ingeniería, consumidores de servicios y administración.

Grupos de administración conectados

Muchas empresas con servidores en varias ubicaciones geográficas requieren que esos servidores se supervisen de forma centralizada. La configuración del grupo de administración conectado, que se muestra en esta imagen, es un conjunto de procesos de flujo de trabajo diseñados para crear una infraestructura jerárquica de administración de sistemas.

Con esta configuración se puede llevar a cabo una supervisión centralizada. Está diseñado para admitir la visualización de alertas y datos de supervisión, y para iniciar tareas en un objeto administrado de un grupo de administración conectado.

Cuando se conectan grupos de administración de Operations Manager, se puede mantener una supervisión centralizada y, al mismo tiempo, permitir lo siguiente:

• Supervisión de un mayor número de objetos administrados que con un solo grupo de administración.
• Aislamiento de la actividad de supervisión por unidades de negocio lógicas (como "Marketing") o por ubicaciones físicas (como Roma).

Al conectar grupos de administración, no se implementan nuevos servidores; en su lugar, permite que el grupo de administración local tenga acceso a las alertas y a la información de detección que se encuentra en un grupo de administración conectado. De esta manera, puede ver e interactuar con todas las alertas y otros datos de supervisión procedentes de diversos grupos de administración en una única consola del operador. Además, puede ejecutar tareas en los equipos supervisados de los grupos de administración conectados. Para obtener información sobre cómo conectar grupos de administración, consulte Conexión de grupos de administración en Operations Manager.

Idiomas instalados

Los grupos de administración de Operations Manager admiten únicamente un idioma instalado. Si el entorno de TI general que necesita supervisar tiene más de un idioma instalado, se necesitará un grupo de administración independiente por cada idioma.