Alta disponibilidad y recuperación ante desastres
Los servidores y las características de System Center Operations Manager podrían producir errores, lo que afectaría 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 recuperarla.
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 y grupo de administración único puede usar SQL Server Always On 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, Linux y dispositivos de red. Los servidores de 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 de Operations se pueden hacer de alta disponibilidad mediante la configuración de 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. 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.
Mientras SQL Server Reporting Services admite un modelo de implementación de escalabilidad horizontal que permite ejecutar varias instancias del servidor de informes que comparten una sola base de datos del servidor de informes, Operations Manager no lo admite. 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 DR proporcionarán protección frente a errores del sistema o pérdida del sistema, no se debe 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 diferida para las operaciones de restauración. En muchos casos, una operación de restauración es la forma más adecuada de DR. 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 DR multisitio en el nivel de sistema o aplicación supera por 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 ellos se puede retrasar sin un impacto empresarial grave si un error o DR de sitio excesivo, considera la posibilidad de usar procesos simples de copia de seguridad y restauración para la DR 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 coste necesarios para admitir la recuperación ante desastres. Además, ten en cuenta que 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 más compleja. La configuración entre ambos debe ser coherente para que, al transicionar, no haya ninguna diferencia en lo que se supervisa, se notifica o se informa, se presenta y, por último, se escala. También deberá existir la integración con otras plataformas de supervisión o plataformas ITSM, como System Center - Service Manager, Remedy o ServiceNow y estar configurada posiblemente en un estado activo/pasivo para evitar la duplicación de incidentes, elementos de configuración, etc. Los agentes serán de 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 quieres evitar la complejidad de un grupo de administración duplicado, también puedes 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, considera la posibilidad de implementar un grupo de disponibilidad Always On de SQL Server 2014 o 2016 para proporcionar recuperación de las bases de datos operativas y de Data Warehouse 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 solo Clúster de conmutación por error de Windows Server (WSFC). La réplica secundaria del grupo de disponibilidad Always On 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 del 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 más información, consulta Instalar Operations Manager desde el símbolo del sistema.
Durante este tiempo, los agentes pondrá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ás implementar los demás roles necesarios para reanudar la funcionalidad de supervisión mínima. Si este enfoque no es aceptable, puedes implementar servidores de administración en el centro de datos secundario para la recuperación en espera. Quítalos 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 deben seguir funcionando como parte del plan de recuperación. Los servicios de acceso a datos de System Center, administración de configuración de System Center 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), este deberá planificarse 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 planifique cuando sea necesario implementar el plan de recuperación ante desastres.
Si un sitio se desconecta, 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. Vuelve a configurar los agentes de Windows para almacenar en caché solo los servidores de administración del centro de datos principal que deben administrar 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 implementas 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 insertas 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.
Ten 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.