La copia de seguridad y la restauración de Ops Manager con una instancia secundaria de Ops Manager se encuentra en Vista previa. Esta función y su documentación pueden cambiar en cualquier momento durante el período de vista previa.
Puede implementar una segunda instancia de Ops Manager, denominada Ops Manager secundario, para respaldar un Ops Manager principal y sus Bases de datos de respaldo. El Administrador de operaciones secundario también sirve como vía de recuperación en caso de que pierda el Administrador de operaciones principal.
Este patrón protege los datos operativos que Ops Manager almacena en su base de datos de aplicaciones y en los almacenes de metadatos. Utilice esta guía para diseñar, configurar y operar la recuperación ante desastres para Ops Manager.
Esta guía está dirigida a los administradores de Ops Manager que gestionan las copias de seguridad y la recuperación ante desastres, así como a los equipos que diseñan topologías de alta disponibilidad y recuperación ante desastres para Ops Manager.
Cómo funciona la copia de seguridad de Secondary Ops Manager
En este patrón, dos instancias de Ops Manager tienen responsabilidades distintas:
El administrador de operaciones principal gestiona las implementaciones de MongoDB y sus copias de seguridad, como de costumbre.
El administrador de operaciones secundario gestiona y realiza copias de seguridad únicamente de las bases de datos de respaldo del administrador de operaciones principal. El administrador de operaciones secundario no gestiona los clústeres de aplicaciones.
El agente de MongoDB se ejecuta en cada host de la base de datos de la aplicación del administrador de operaciones principal y se registra con el administrador de operaciones secundario. El administrador de operaciones secundario realiza copias de seguridad continuas y puntuales de esas bases de datos de respaldo.
Si pierde el Administrador de operaciones principal, restaure sus bases de datos de respaldo desde el Administrador de operaciones secundario y, a continuación, inicie un nuevo Administrador de operaciones principal. El Administrador de operaciones principal se reconecta a las bases de datos de respaldo restauradas y reanuda la administración de sus implementaciones de MongoDB.
Cuando los agentes de MongoDB se reconectan tras el reinicio, informan de una versión de configuración más reciente que la de la base de datos restaurada. El administrador de operaciones principal detecta la discrepancia, entra automáticamente en el modo de restauración para el proyecto afectado, sincroniza todos los agentes con la configuración restaurada y bloquea los cambios de implementación hasta que se complete la conciliación.
Arquitectura
La siguiente tabla describe los componentes de este patrón y sus responsabilidades:
Componente | Responsabilidad |
|---|---|
Gerente de Operaciones Principales | Gestiona tus implementaciones de MongoDB y sus copias de seguridad. Almacena sus propios datos operativos en su base de datos de aplicación, almacén de metadatos de instantáneas y almacén de metadatos de oplog. |
Gerente de Operaciones Secundarias | Ejecuta un demonio de copia de seguridad que escribe en un3almacén de bloques de almacenamiento compatible con S2 para instantáneas de bases de datos de aplicaciones y fragmentos de oplog. Realiza copias de seguridad continuas de las bases de datos de respaldo del Administrador de operaciones principal. No administra los clústeres de aplicaciones. |
Base de datos de la aplicación | Almacena los datos operativos principales del Administrador de operaciones, incluyendo la configuración del proyecto, el estado de la automatización y los metadatos de la copia de seguridad. Debe realizar una copia de seguridad de la base de datos de la aplicación. |
Almacenes de metadatos de instantáneas y registros de operaciones | Almacene los índices de bloques y oplog de las implementaciones de las que el Administrador de operaciones principal realiza copias de seguridad. Realice también copias de seguridad de estos almacenes. |
MongoDB Agent | Se ejecuta en cada servidor de base de datos de respaldo y se registra con el Administrador de operaciones secundario para realizar copias de seguridad y restauraciones. |
El administrador de operaciones secundario almacena las copias de seguridad de las bases de datos de respaldo del administrador de operaciones principal en su propio almacén de bloques de almacenamiento compatible con S3, separado del almacenamiento de copias de seguridad del administrador de operaciones principal.
Variantes de despliegue
Implemente el Administrador de operaciones secundario en un dominio de fallos separado del Administrador de operaciones principal para evitar que un único fallo afecte a ambas instancias. Las variantes comunes incluyen:
Diferentes regiones
Implemente el Administrador de operaciones secundario en una región de nube diferente a la del Administrador de operaciones principal. Esta variante protege contra la pérdida de una región.
Diferentes centros de datos
Implemente el Administrador de operaciones secundario en un centro de datos diferente al del Administrador de operaciones principal. Esta variante protege contra la pérdida de un centro de datos.
Red de respaldo independiente
Coloque el Administrador de operaciones secundario en una red independiente dedicada al tráfico de copias de seguridad. Esta variante aísla el tráfico de copias de seguridad de la red de su aplicación.
Importante
Implemente el Administrador de operaciones secundario en un dominio de fallos independiente, como un rack, zona de disponibilidad, región o segmento de red diferente al del Administrador de operaciones principal. Si ambas instancias comparten un dominio de fallos, un único fallo puede interrumpir tanto el Administrador de operaciones principal como su ruta de recuperación.
Versiones compatibles y limitaciones
Antes de utilizar este patrón, revise los siguientes requisitos y limitaciones.
Versiones compatibles
Tanto la instancia principal como la secundaria de Ops Manager deben ejecutar Ops Manager 8.0.24 o posterior.
El Administrador de operaciones secundario debe ejecutar la misma versión o una posterior que el Administrador de operaciones principal. No ejecute un Administrador de operaciones secundario que sea una versión anterior a la del Administrador de operaciones principal.
Advertencia
Restaure la base de datos de la aplicación en un Ops Manager principal que ejecute la misma versión o una versión posterior a la del Ops Manager principal original del que se tomó la instantánea. Si el binario de reemplazo es anterior a la versión registrada en la base de datos de la aplicación, Ops Manager no se iniciará y mostrará el error "No se permiten reversiones".
Limitaciones
Este patrón realiza copias de seguridad de las bases de datos de respaldo del Administrador de operaciones principal. No realiza copias de seguridad de clústeres de MongoDB arbitrarios. El Administrador de operaciones principal continúa gestionando las copias de seguridad de sus implementaciones de MongoDB.
La copia de seguridad y la conciliación del almacén de metadatos de instantáneas y del almacén de metadatos de oplog es un procedimiento manual. Ops Manager no selecciona automáticamente un punto de restauración para estos almacenes. Como resultado, los metadatos de la copia de seguridad pueden ser inconsistentes después de una restauración, y algunas copias de seguridad podrían no ser restaurables. Ops Manager valida una instantánea antes de restaurarla y, en caso de fallo, muestra un error en lugar de realizar una restauración insegura.
El modo de restauración no se aplica a las implementaciones gestionadas externamente, como las gestionadas por un operador de Kubernetes. Tras restaurar la base de datos de la aplicación, los agentes de estos proyectos reciben la configuración restaurada directamente en su siguiente sondeo y convergen sin entrar en el modo de restauración. No es necesario realizar ninguna acción en estos proyectos.
Una instantánea puede volverse irrecuperable si sus bloques de datos ya no se encuentran en el almacén de instantáneas. Antes de la restauración, el Administrador de operaciones principal verifica que existan los bloques de la instantánea. Si faltan bloques, la restauración falla con un error y deja el conjunto de réplicas sin modificar, en lugar de borrarlo y fallar a mitad del proceso.
Una restauración no probada supone un riesgo operativo. Valide periódicamente la ruta de copia de seguridad y restauración. Consulte el manual de validación en el Administrador de operaciones de restauración desde un Administrador de operaciones secundario.
Próximos pasos
Para configurar y utilizar este patrón, consulte las siguientes páginas: