Alta disponibilidad y recuperación ante desastres

System Center: los servidores y características de Operations Manager pueden producir errores, lo que afecta a la funcionalidad de Operations Manager. La cantidad de datos y funcionalidad perdidas 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 abordan 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 los servidores de administración y cargas de trabajo específicas. Estas cargas de trabajo incluyen la supervisión de dispositivos de red, la supervisión multiplataforma y las cargas de trabajo específicas del grupo de administración administradas previamente por el servidor de administración raíz.

La configuración de varios servidores, grupo de administración único puede usar SQL Server AlwaysOn para proporcionar alta disponibilidad y continuidad del servicio de las bases de datos de Operations Manager. La tolerancia a errores del servidor de administración se proporciona al tener al menos dos servidores de administración y mediante el uso de los grupos de recursos para supervisar servidores UNIX, servidores Linux y dispositivos de red. Los servidores Windows basados en agente se pueden configurar con un servidor de administración principal y secundario para redirigir las comunicaciones del agente si se produce un error en un servidor de administración.

El emulador de RMS también se puede mover a otro servidor de administración si el servidor de administración que hospeda el emulador de RMS no está disponible.

Las conexiones de la consola del operador se pueden hacer de alta disponibilidad mediante la configuración de alta disponibilidad para Data Access Services. 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. Uno o varios servidores de administración se agregan como miembros del grupo de NLB y, al abrir cualquiera de las consolas, se hace referencia al nombre virtual registrado en DNS, de los servidores de administración con equilibrio de carga.

Nota:

No se admite un equilibrador de carga de red para el servidor de consola web de Operations Manager.

Se pueden implementar varios servidores de puerta de enlace a través de un límite de confianza para proporcionar rutas redundantes para los agentes que se encuentran a través de ese límite de confianza. Al igual que los agentes pueden conmutar por error entre un servidor de administración principal y uno o varios servidores de administración secundarios, también pueden conmutar por error entre servidores de puerta de enlace. Además, se pueden usar varios servidores de puerta de enlace para distribuir la carga de trabajo de administración de equipos administrados sin agente y dispositivos de red administrados.

Además de proporcionar redundancia a través de la conmutación por error de puerta de enlace de agente, los servidores de puerta de enlace se pueden configurar para conmutar por error entre servidores de administración en un grupo de administración si hay varios servidores de administració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 front-end, que no se pueden replicar en la granja de servidores web.

Recuperación ante desastres

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

Aunque las soluciones de alta disponibilidad y recuperación ante desastres proporcionarán protección contra errores del sistema o pérdida del sistema, no se deben confiar en ellos para la protección frente a la pérdida accidental, no deseada o malintencionada de datos o daños. En estos casos, es posible que tenga que usarse una copia de seguridad de copias de seguridad copiadas o de replicación diferidos para las operaciones de restauración. En muchos casos, una operación de restauración es la forma más adecuada de recuperación ante desastres. Un ejemplo de esto podría ser una base de datos de informes de prioridad baja o datos de análisis. En muchos casos, el costo de habilitar la recuperación ante desastres multisitio en el nivel de sistema o aplicación supera mucho el valor de los datos. En los casos en los que el valor a corto plazo de los datos es bajo y la necesidad de acceder a los datos se puede retrasar sin un impacto empresarial grave si un error o recuperación ante desastres de sitio excesivo, considere la posibilidad de usar procesos simples de copia de seguridad y restauración para la recuperación ante desastres si el ahorro de costos lo garantiza.

Comprender el impacto y la tolerancia al tiempo de inactividad ayudará a impulsar las decisiones que deben entenderse para diseñar correctamente la arquitectura de Operations Manager y el nivel de complejidad y costo necesarios para admitir la recuperación ante desastres. Además, tenga en cuenta la extensión de la supervisión de la pérdida de datos que la organización de TI puede tolerar sin causar 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 de recuperación ante desastres más comunes para Operations Manager son:

• Creación de un grupo de administración duplicado implementado en su centro de datos secundario que duplica en escala y configuración, al 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 servidores de administración implementados en una configuración en espera inactiva, no participando en el grupo de administración hasta que sea necesario 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án que existir y, posiblemente, configurarse en un estado activo/pasivo para evitar la duplicación de incidentes, elementos de configuración, etc. Los agentes serán multiinicio 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 AlwaysOn de SQL Server 2014 o 2016 para proporcionar 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 de clúster de conmutación por error de dos nodos (FCI) en el centro de datos principal y un servidor SQL Server independiente en el centro de datos secundario como parte de un único clúster de conmutación por error de Windows Server (WSFC). La réplica secundaria del grupo de disponibilidad AlwaysOn estaría en la instancia independiente que no sea FCI, como se muestra en el diagrama siguiente.

En este ejemplo, sería necesario implementar uno o varios servidores windows con la misma configuración de hardware y nombre de equipo, y volver a instalar el rol de servidor de administración mediante el parámetro /Recover . 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 obtener más información, consulte instalación de Operations Manager desde el símbolo del sistema.

Durante este tiempo, los agentes ponerán 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 a partir de la última copia de seguridad correcta 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 deberá 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 el 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 puede incluir servidores de administración hospedados en el centro de datos principal y tener que seguir funcionando como parte del plan de recuperación. Los servicios De System Center Data Access, System Center Configuration Management y Microsoft Monitoring Agent deben detenerse y establecerse en manual o deshabilitarse y solo iniciarse 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 del servidor de administración se capture y planee cuando sea necesario implementar el plan de recuperación ante desastres.

Si un sitio se queda sin conexión, el agente conmutará por error al servidor de administración de 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 del centro de datos principal que deben administrarlos para evitar que intenten realizar la conmutación por error a un servidor de administración en el centro de datos secundario, lo que solo retrasaría la recuperación y los 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 script administrado con la solución de administración de configuración empresarial.

Operations Manager se puede implementar en máquinas virtuales de Azure como una opción alternativa de recuperación ante desastres para mantener la continuidad del grupo de administración. También será necesario implementar SQL Server en una máquina virtual en Azure y no en una configuración híbrida, ya que la latencia entre un servidor de administración y 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.