Alta disponibilidad y recuperación ante desastres

Importante

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

Los servidores y características de System Center Operations Manager pueden producir un error, lo que afecta a la funcionalidad de Operations Manager. La cantidad de datos y funcionalidades que se pierde durante un error es diferente en cada escenario de error. Depende del rol de la característica con errores y del tiempo necesario para recuperar la característica con errores.

Alta disponibilidad

Las necesidades de alta disponibilidad se dirigen mediante la creación de redundancia en el grupo de administración para las bases de datos operativas y de almacenamiento de datos de Operations Manager, la puerta de enlace y servidores de administración y las cargas de trabajo específicas. Estas cargas de trabajo incluyen la supervisión de dispositivos de red y multiplataforma, y las cargas de trabajo específicas del grupo de administración que se administraron previamente con el servidor de administración raíz.

La configuración del grupo de administración único y de varios servidores puede hacer uso de SQL Server AlwaysOn para proporcionar alta disponibilidad y continuidad del servicio de las bases de datos de Operations Manager. Al tener al menos dos servidores de administración y usar grupos de recursos para la supervisión de servidores de UNIX y Linux y de dispositivos de red, se proporciona tolerancia a errores del servidor de administración. Los servidores de Windows basados en agentes pueden configurarse con un servidor de administración principal y secundario para redirigir las comunicaciones del agente en caso de que se produjera un error de un servidor de administración.

El emulador de RMS también se puede mover a otro servidor de administración, en caso de que el servidor de administración que hospeda el emulador de RMS dejase de estar disponible.

Se puede hacer que las conexiones de la consola del operador sean de alta disponibilidad al configurar la alta disponibilidad para los servicios de acceso a datos. Esto se puede hacer mediante la instalación del equilibrio de carga de red (NLB) de Microsoft o mediante equilibradores de carga basados en hardware o alias DNS. Se agregan uno o más servidores de administración como miembros del grupo de NLB y, al abrir la consola de cualquiera, hace referencia al nombre virtual registrado en DNS, de los servidores de administración de equilibrio de carga.

Nota

No se admite una Load Balancer de red para el servidor de consola web de Operations Manager.

Varios servidores de puerta de enlace pueden implementarse en un límite de confianza para proporcionar las rutas redundantes para los agentes que se encuentran en ese límite de confianza. Así como los agentes pueden conmutar por error entre un servidor de administración principal y uno o más servidores de administración secundarios, también pueden conmutar por error entre los servidores de puerta de enlace. Además, varios servidores de puerta de enlace pueden utilizarse para distribuir la carga de trabajo de la administración de los equipos administrados sin agente y de los dispositivos de red administrados.

Además de proporcionar redundancia a través de la conmutación por error de la puerta de enlace del agente, los servidores de puerta de enlace pueden configurarse para conmutar por error entre servidores de administración de un grupo de administración, si varios servidores de administración están disponibles.

Aunque SQL Server Reporting Services admite un modelo de implementación escalada que permite ejecutar varias instancias del servidor de informes que comparten una base de datos de servidor de informes única, no se admite con Operations Manager. Operations Manager Reporting instala una extensión de seguridad personalizada como parte de la configuración de los componentes de front-end, que no se pueden replicar en toda la granja de servidores web.

Recuperación ante desastres

La recuperación ante desastres se relaciona con las medidas tomadas para garantizar que las operaciones se puedan reanudar si se produce un error grave (por ejemplo, pérdida de todo el centro de datos que hospeda la infraestructura principal). Es un elemento importante que se debe tener en cuenta en cualquier implementación y las decisiones que se toman en la planeación de la recuperación ante desastres afectan a cómo Operations Manager podrá seguir admitiendo la supervisión proactiva y la generación de informes sobre el rendimiento y la disponibilidad de los servicios de TI críticos. Esta sección se centrará en la estrategia recomendada de recuperación ante desastres y resistencia, y qué pasos que deben seguir para garantizar una recuperación sin problemas.

Aunque las soluciones de alta disponibilidad y recuperación ante desastres proporcionarán protección frente a errores del sistema o pérdida del sistema, no se deben confiar en para la protección frente a daños o pérdidas de datos accidentales, no deseadas o malintencionadas. En estos casos, es posible que tenga que usarse una copia de seguridad de copias de seguridad copiadas o de replicación diferida para las operaciones de restauración. En muchos casos, la forma más adecuada de recuperación ante desastres es una operación de restauración. Un ejemplo de esto podría ser una base de datos de informe de prioridad baja o datos de análisis. En muchos casos, el costo para habilitar el multisitio de recuperación ante desastres en el nivel de aplicación o de sistema supera de lejos el valor de los datos. En los casos en que el valor de los datos a corto plazo es bajo y la necesidad de tener acceso a los datos se pueden retrasar sin que tenga un gran impacto en el negocio en caso de un error o sitio de recuperación ante desastres excesivo, considere la posibilidad de usar una simple copia de seguridad y procesos de restauración para recuperación ante desastres si lo exigen los ahorros de costos.

Comprender el impacto y la tolerancia del tiempo de inactividad le ayudará a tomar las decisiones que se deben entender para diseñar adecuadamente la arquitectura de Operations Manager y el nivel de complejidad y costo necesarios para admitir la recuperación ante desastres. Además, considere el alcance de supervisión de la pérdida de datos que la organización de TI puede tolerar sin que se produzcan consecuencias empresariales. Esto se describe mejor en dos términos: objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO).

Las dos configuraciones de diseño más comunes de recuperación ante desastres para Operations Manager son:

• Creación de un grupo de administración duplicado implementado en el centro de datos secundario que duplica la escala y la configuración del grupo de administración principal.
• Implementación de servidores adicionales en un centro de datos secundario para admitir la base de datos operativa y de almacenamiento de datos, con los servidores de administración implementados en una configuración de espera pasiva, sin participar en el grupo de administración hasta que se deban realizar acciones de recuperación.

La implementación de un grupo de administración duplicado es una opción cuando no hay tolerancia al tiempo de inactividad; sin embargo, es la opción más compleja. La configuración entre ambos debe ser coherente para que, al cortar, no haya ninguna diferencia en lo que se supervisa, se notifica o se notifica, se presenta y, por último, se escala. La integración con otras plataformas de supervisión o plataformas ITSM, como System Center: Service Manager, Remedy o ServiceNow, también tendrá que existir y, posiblemente, configurarse en un estado activo/pasivo para evitar la duplicación de incidentes, elementos de configuración, etc. Agentes que actuarán como host múltiple entre ambos grupos de administración, por lo que habrá duplicación de datos.

El diagrama siguiente es un ejemplo de este escenario de diseño.

Si la recuperación inmediata no es necesaria para la implementación de Operations Manager y desea evitar la complejidad de un grupo de administración duplicado, también puede implementar componentes de grupo de administración adicionales en el centro de datos secundario para conservar la funcionalidad del grupo de administración. Como mínimo, considere la posibilidad de implementar un grupo de disponibilidad de SQL Server 2014 o 2016 Always On para proporcionar la recuperación de las bases de datos operativas y de almacenamiento de datos entre dos o más centros de datos, donde se implementa una instancia del clúster de conmutación por error (FCI) de dos nodos en el centro de datos principal, y un SQL Server independiente en el centro de datos secundario como parte de un clúster de conmutación por error de Windows Server (WSFC) único. La réplica secundaria para el grupo de disponibilidad Always On estaría en la instancia independiente no FCI, tal como se muestra en el diagrama siguiente.

En este ejemplo, tendría que implementar uno o varios servidores de Windows con el mismo nombre de equipo y configuración de hardware y volver a instalar el rol de servidor de administración mediante el parámetro /recuperación. Aquí tiene un ejemplo:

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

Para más información, consulte Instalación de Operations Manager desde el símbolo del sistema.

Durante este tiempo, los agentes ponen en cola los datos recopilados (alertas, eventos, rendimiento, etc.) hasta que puedan reanudar la comunicación con un servidor de administración en el grupo de administración. Este enfoque evita la instalación de nuevas instancias de SQL Server y la restauración de bases de datos desde la última copia de seguridad buena conocida. Sin embargo, en este escenario de recuperación es probable que haya un retraso más largo al volver a un estado operable, dado que tendrá que implementar los demás roles necesarios para reanudar la funcionalidad de supervisión mínima. Si este enfoque no es aceptable, puede implementar servidores de administración en su centro de datos secundario para la recuperación en espera. Quítelos como miembros de los tres grupos de recursos principales: grupo de recursos de todos los servidores de administración, notificaciones y asignación de AD. Esto también incluye cualquier grupo de recursos personalizado que pueda incluir servidores de administración hospedados en el centro de datos principal y que tienen que seguir funcionando como parte del plan de recuperación. Se deberían detener y establecer en modo manual o deshabilitado los servicios de acceso a datos de System Center, administración de la configuración de System Center y Microsoft Monitoring Agent, y solo iniciarlos en un escenario de recuperación ante desastres.

Si un servidor de administración admite la integración (a través de un conector hospedado directamente en el servidor de administración o desde otro producto de System Center, como VMM, Orchestrator o Service Manager), deberá planearse con pasos de recuperación manuales o automáticos en función de la configuración de integración y la secuencia de pasos de recuperación. Esto garantiza que cualquier otra dependencia en el servidor de administración se capture y planee para cuando se necesite implementar el plan de recuperación ante desastres.

Si un sitio se desconecta, el agente conmutará por error al servidor de administración en otro sitio, suponiendo que la configuración de conmutación por error del agente lo permita. Vuelva a configurar los agentes de Windows para almacenar en caché solo los servidores de administración de su centro de datos principal que los debe administrar para impedir que intenten conmutar por error a un servidor de administración en el centro de datos secundario, lo que solo retrasaría la detección y la creación de informes. Esto se puede lograr si implementa manualmente el agente de forma automatizada con un script (por ejemplo, VBScript o, mejor aún, PowerShell) para preconfigurar durante la instalación o después de la implementación si inserta el agente desde la consola, de nuevo mediante un método scripted administrado con la solución de administración de configuración empresarial.

Se puede implementar Operations Manager en máquinas virtuales de Azure como una opción de recuperación ante desastres alternativa para mantener la continuidad del grupo de administración. También será necesario implementar SQL Server en una máquina virtual de Azure y no en una configuración híbrida, ya que la latencia entre un servidor de administración y el SQL Server que hospeda las bases de datos de Operations Manager afectará negativamente al rendimiento del grupo de administración.

Tenga en cuenta el ámbito de supervisión, la topología de red y la conectividad de red a Microsoft Azure (es decir, VPN de sitio a sitio o ExpressRoute), puntos de integración (es decir, soluciones ITSM, otros productos de System Center, complementos de terceros, etc.), acceso a la consola, leyes o directivas pertinentes, etc. para diseñar correctamente este escenario dentro de IaaS de Azure u otros proveedores de nube pública.