Planificar un diseño de grupo de administración

Información general

Un grupo de administración se identifica mediante una sola base de datos operativa, uno o varios servidores de administración, y uno o varios agentes y dispositivos supervisados. La conexión de grupos de administración permite ver y editar alertas y otros datos de supervisión desde una sola consola. Las tareas también se pueden iniciar desde un grupo de administración local para ejecutarse en los objetos administrados de un grupo de administración conectado.

La implementación más sencilla de Operations Manager es un solo grupo de administración. Cada grupo adicional requiere al menos su propia base de datos operativa y servidor de administración. Cada grupo también debe mantenerse por separado con sus propias opciones de configuración, módulos de administración e integración con otras soluciones de supervisión e ITSM.

La implementación del grupo de administración distribuida formará la base del 99 % de las implementaciones de Operations Manager. Permite la distribución de características y servicios en varios servidores para permitir escalabilidad y redundancia para algunas de esas características. Puede incluir todos los roles de servidor de Operations Manager y admitir 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 ninguna comunicación directa entre la consola de Operations y las bases de datos. Toda la comunicación se dirige a un servidor de administración específico a través del puerto TCP 5724 y luego a los servidores de bases de datos mediante OLE BD en TCP 1433 o a 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 SQL Server que hospeda las bases de datos operativas y de almacenamiento de datos.

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

La integración con Operations Manager se extiende a otros productos como BMC Remedy, IBM, Netcool u otras soluciones de administración empresarial usadas por tu organización. Para obtener más información sobre cómo planear la interoperabilidad con estas soluciones, consulta Integración con otras soluciones de admnistración.

Componentes del 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 era el primer servidor de administración instalado en un grupo de administración. RmS fue el punto focal para administrar la configuración del grupo de administración, administrar y comunicarse con agentes, y comunicarse con la base de datos operativa y otras bases de datos del grupo de administración. RMS también sirvió como destino para la consola de Operations y el destino preferido para las consolas web. En System Center 2012 R2: Operations Manager, se quitó el rol del servidor de administración raíz, de modo que todos los servidores de administración ahora se encuentran en el mismo nivel. Esta configuración sigue existiendo en System Center 2016 y versiones posteriores: Operations Manager.

RMS ya no es un único punto de error, ya que todos los servidores de administración hospedan los servicios hospedados anteriormente solo por RMS. Los roles se distribuyen a todos los servidores de administración. Si un servidor de administración deja de estar 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 destinados a RMS. Si no tienes ningún módulo de administración destinado previamente a RMS, no tendrás que usar el emulador de RMS.

El grupo de administración puede contener varios servidores de administración para proporcionar capacidad adicional y disponibilidad continua. Cuando se agregan dos o más servidores de administración a un grupo de administración, los servidores de administración se convierten automáticamente en parte de los tres grupos de recursos predeterminados y el trabajo se distribuye entre los miembros del grupo. En el caso de los grupos de recursos definidos personalizados, los miembros se agregan manualmente. Cuando se produce un error en un miembro del grupo de recursos, otros miembros del grupo de recursos se encargan de asumir la carga de trabajo de ese miembro. Cuando se agrega un nuevo servidor de administración, el nuevo se hace cargo automáticamente de parte del trabajo de los miembros existentes del grupo de recursos. Consulta 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, de forma predeterminada, los agentes que dependen 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 capacidad de conmutación por error debe tenerse en cuenta si la alta disponibilidad es un requisito.

Los agentes se conectan a un servidor de administración para comunicarse con todos los demás componentes de Operations Manager. Parte del trabajo realizado por un servidor de administración es el proceso de tomar los datos operativos enviados por agentes e insertarlos en la base de datos operativa y en el almacenamiento de datos.

Un servidor de administración típico controlará aproximadamente 3000 agentes. El rendimiento real del servidor varía según el volumen de datos operativos recopilados; pero, los servidores de administración normalmente pueden admitir 3000 agentes cada uno, incluso con un volumen relativamente alto de datos operativos.

No hay ningún límite en el número máximo de servidores de administración por grupo de administración. Pero es un procedimiento recomendado 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 la base de datos y el almacenamiento de datos de Operations Manager, ya que con frecuencia envían grandes volúmenes de datos a estos almacenes. En general, estas conexiones de SQL Server consumen más ancho de banda y son más sensibles a la latencia de red. Por lo tanto, todos los servidores de administración deben estar en la misma red de área local que la base de datos operativa y la base de datos de Data Warehouse y nunca se implementan en una red de área amplia. Debe haber menos de 10 milisegundos de latencia entre un servidor de administración y una instancia de SQL Server que hospeda las bases de datos de Operations Manager.

Servidor de puerta de enlace

Operations Manager requiere la autenticación mutua 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 se cifra. 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, usan mecanismos de autenticación 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 cumplir 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 que no es de confianza independiente. El servidor de puerta de enlace actúa como proxy entre los agentes y el servidor de administración. Sin el servidor de puerta de enlace, los agentes todavía podían realizar la autenticación de certificados con un servidor de administración, pero un certificado X.509 tendría que emitirse e instalarse en cada agente mediante la herramienta MOMCertImport.exe y cada uno requeriría 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, pueden usar la autenticación de Kerberos. En este caso, solo el servidor de puerta de enlace y los servidores de administración conectados requerirán certificados. 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á unido al mismo dominio kerberos de confianza que los roles que admiten el grupo de administración de Operations Manager, o has implementado Operations Manager en IaaS de Azure (una máquina virtual con SQL Server que hospeda las bases de datos operativas y una o varias máquinas virtuales que hospedan el rol de servidor de administración) y supervisa cargas de trabajo locales que no son de confianza.

A continuación se presenta un ejemplo de implementación de Operations Manager que supervisa los recursos de IaaS de Azure.

A continuación se muestra un ejemplo de implementación de Operations Manager hospedada 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 recomiendan varios servidores de puerta de enlace si se requieren 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 rellenar la cola entrante en el servidor de puerta de enlace, los datos de la cola se quitan según su prioridad, lo que significa que una interrupción sostenida del servidor de puerta de enlace en este escenario podría provocar la pérdida de datos.
• Cuando hay un gran número de agentes conectados a través de servidores de puerta de enlace, considera 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 solo 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 efectiva en el servidor de administración es el número total de agentes que le informan directamente o mediante servidores de puerta de enlace.
• Para evitar que el servidor de puerta de enlace inicie la comunicación con un servidor de administración, incluso cuando está configurado para conmutar por error varios servidores de administración para 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 cumplir 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 al grupo de administración al que se puede acceder a través de un explorador web. No tiene la funcionalidad completa de la consola de Operations y proporciona acceso solo a las vistas Supervisión y Mi área de trabajo. La consola web proporciona acceso a todos los datos y tareas de supervisión que son acciones que se pueden ejecutar en equipos supervisados desde la consola de Operations. El acceso a los datos de la consola web tiene las mismas restricciones que el acceso al contenido de la consola de Operations.

Servidor de informes

Los informes de System Center: Operations Manager se instalan en SQL Server Reporting Services (compatible con la versión de Operations Manager que usas) y la única configuración de Reporting Services válida que admite Operations Manager Reporting es el modo nativo.

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 instales ninguna otra aplicación de Reporting Services en esta misma instancia de SQL Server.

Los componentes del servidor de informes de Operations Manager se pueden instalar en el mismo servidor que ejecuta SQL Server 2014 o Reporting Services 2016 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, debes escalar verticalmente para controlar más usuarios simultáneos y cargas de ejecución de informes más amplios. Se recomienda que el servicio de informes de Operations Manager no se encuentre en la misma instancia de SQL Server que hospeda la base de datos de almacenamiento de datos y está 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 de alta disponibilidad mediante configuraciones de agrupación en clústeres admitidas.

Para mantener esta base de datos en un tamaño coherente, la configuración de limpieza de Operations Manager especifica el período de tiempo durante el cual se pueden conservar los datos en ella. De forma predeterminada, esta duración es de siete (7) días.

Base de datos de Data Warehouse de informes

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

En la tabla siguiente se resaltan los tipos de datos predeterminados y el período de retención después de la configuració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	Notificación sin procesar	400
Supervisión de clientes	Notificación sin procesar	30
Supervisión de clientes	Diariamente	400
Eventos	Notificación sin procesar	100
Rendimiento	Notificación sin procesar	10
Rendimiento	Cada hora	400
Rendimiento	Diariamente	400
Estado	Notificación sin procesar	180
Estado	Cada hora	400
Estado	Diariamente	400

Un almacenamiento de datos puede servir a varios grupos de administración. Esto permite que un solo informe incorpore datos de todos los equipos de toda 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 lograr una alta disponibilidad. Si no está agrupado, se debe supervisar cuidadosamente para que se puedan solucionar rápidamente los problemas.

Recopilador de ACS

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

Base de datos de ACS

La base de datos de ACS es el repositorio central de eventos generados por una directiva de auditoría dentro de una implementación de ACS. La base de datos de ACS se puede ubicar en el mismo equipo que el recopilador de ACS, pero para obtener el mejor rendimiento, cada uno debe instalarse en un servidor dedicado. De forma predeterminada, los datos se conservan durante catorce (14) días.

Reenviador de ACS

El servicio que se ejecuta en reenviadores de ACS se incluye en el agente de Operations Manager. De forma predeterminada, este servicio se instala pero no está habilitado cuando se instala el agente de Operations Manager. Puedes habilitar este servicio para varios equipos de agente a la vez mediante la tarea Habilitar recopilación de auditorías o con PowerShell. Después de habilitar este servicio, todos los eventos de seguridad se envían al recopilador de ACS, además del registro de seguridad local.

Consideraciones de diseño

Se deben tener en cuenta los siguientes factores al decidir implementar uno o varios grupos de administración:

• Mayor capacidad. Operations Manager no tiene límites integrados con respecto al número de agentes que un solo grupo de administración puede admitir. Según el hardware que uses y la carga de supervisión (más módulos de administración implementados suponen una mayor carga de supervisión) en el grupo de administración, es posible que necesites 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 para proporcionar una vista consolidada de los datos de supervisión y alerta de ellos. Esto se puede lograr mediante la implementación de un grupo de administración adicional (que podría o no tener responsabilidades de supervisión) que tenga acceso a todos los datos de todos los demás grupos de administración. Después se dice que estos grupos de administración 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 y los demás que proporcionan datos a ellos se denominan 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. Tu empresa puede incluir varios grupos de TI, cada uno con su propio área de responsabilidad. El área puede ser un área geográfica específica o una división de negocios. Por ejemplo, en el caso de una sociedad de cartera, puede ser una de las empresas subsidiarias. Cuando este tipo de delegación completa de autoridad administrativa del grupo de TI centralizado existe, puede resultar útil implementar una estructura de grupo 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 reside en el centro de datos de TI centralizado.
• Idiomas instalados. Todos los servidores con un rol de servidor de Operations Manager instalados en ellos deben estar instalados en el mismo idioma. Es decir, no puedes instalar el servidor de administración mediante la versión en inglés de Operations Manager 2012 R2 y luego implementar la consola de Operations mediante la versión japonesa. Si la supervisión necesita abarcar varios idiomas, se necesitará un grupo de administración adicional para 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 usa 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 ajustar la funcionalidad del módulo de administración antes de migrarlo al entorno de producción. Además, algunas empresas emplean un entorno de ensayo para los servidores en los que los servidores recién creados se colocan durante un período de grabación antes de colocarse 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 del lanzamiento 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 de UNIX/Linux, implementarás el Servicio de recopilación de auditorías (ACS). Puede ser beneficioso implementar un grupo de administración que admita la función de ACS exclusivamente si los requisitos de seguridad de tu empresa exigen que la función de ACS se controle y administre 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 confirmarse en la base de datos. Estos registros de transacciones se pueden enviar a otro servidor que ejecuta Microsoft SQL Server y se confirman en una copia de la base de datos de Operations Manager allí. Esta característica es una opción para proporcionar redundancia de la base de datos operativa de Operations Manager entre dos servidores SQL Server en el mismo grupo de administración. Cuando es necesario realizar una conmutación por error controlada, los servidores de administración del grupo de administración requieren un cambio en el registro para hacer referencia a SQL Server secundario y comunicarse con ellos. Se puede implementar un grupo de administración de conmutación por error que coincida exactamente con la configuración del grupo de administración principal (módulos de administración, invalidaciones, suscripciones de notificación, seguridad, etc.) y los agentes se configuran para informar a los dos 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 la pérdida cero de la supervisión operativa.

Antes de implementar System Center Operations Manager en un entorno de producción, planea 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 admitirá los procesos de administración de incidentes y problemas, y cómo visualizará los datos de diferentes niveles de asistencia 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 una supervisión central de esos servidores. La configuración del grupo de administración conectado, que se muestra en la imagen siguiente, es un conjunto de procesos de flujo de trabajo diseñados para crear una infraestructura jerárquica de administración de sistemas.

Esta configuración se puede usar para lograr una supervisión centralizada. Está diseñada 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.

Al conectar grupos de administración de Operations Manager, se puede mantener la funcionalidad de supervisión centralizada al mismo tiempo que se habilita:

• La supervisión de un mayor número de objetos de administración de lo que es posible 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 este modo, puede ver todas las alertas y otros datos de supervisión de varios grupos de administración en una sola consola del operador, así como interactuar con ellos. 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, consulta Conexión de grupos de administración en Operations Manager.

Idiomas instalados

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