Ops Manager es un componente necesario para cualquier implementación empresarial de MongoDB. Ops Manager automatiza, supervisa y realiza copias de seguridad de las bases de datos de MongoDB. El recurso personalizado MongoDBOpsManager define tres componentes:
Aplicación de gestión de operaciones: el componente principal de la gestión de operaciones y la interfaz de usuario frontal.
Base de datos de la aplicación: la base de datos MongoDB subyacente para Ops Manager.
Demonio de copia de seguridad: presta soporte a la aplicación Administrador de operaciones en los procesos de copia de seguridad y restauración.
El operador de Kubernetes gestiona la especificación del recurso MongoDBOpsManager. Cuando la especificación cambia, el operador de Kubernetes valida los cambios y aplica las actualizaciones correspondientes en cada clúster de Kubernetes donde se implementan los componentes de Ops Manager.
El siguiente diagrama muestra la arquitectura de una implementación de Ops Manager en un único clúster de Kubernetes:
La base de datos de la aplicación
Para la base de datos de la aplicación, el operador de Kubernetes implementa un conjunto de réplicas de MongoDB como un StatefulSet. Cada Pod tiene los siguientes contenedores:
mongod — el proceso de la base de datos.
Agente de MongoDB: gestiona el
mongodciclo de vida. Puede anular la versión del Agente de MongoDB mediante la$AGENT_IMAGEvariable de entorno oagent.versionen el gráfico de Helm.Agente de monitorización: envía datos de monitorización al gestor de operaciones. La versión se selecciona automáticamente para garantizar la compatibilidad con versiones anteriores y no se puede modificar.
El operador de Kubernetes pasa la configuración de la base de datos de la aplicación a los agentes a través de un Secret (<om_resource_name>-db-config) montado en cada Pod.
Kubernetes crea un Pod por cada miembro. Cada agente de MongoDB inicia mongod y lo agrega al conjunto de réplicas. El operador de Kubernetes crea PersistentVolumeClaims para cada Pod, y puede personalizarlos usando spec.applicationDatabase.podSpec.persistence.
El operador de Kubernetes crea un servicio sin cabeza para la conectividad interna. En implementaciones de clústeres múltiples, el operador de Kubernetes también crea un servicio por Pod (<om_resource_name>-db-N-svc) para la direccionabilidad individual mongod.
Consideraciones sobre la topología de la base de datos de la aplicación
Para elegir un nodo principal, la mayoría de los nodos del conjunto de réplicas de la base de datos de la aplicación deben estar disponibles. Si es posible, utilice un número impar de clústeres de Kubernetes miembros y distribuya los nodos entre centros de datos, zonas o clústeres.
Consideremos estos ejemplos de distribución:
Base de datos de aplicación de cinco miembros, dos clústeres: Coloque 3 miembros en 1 el 2 Clúster y en el 2 Clúster. Si 2 el Clúster falla, el Clúster 1 tiene la mayoría. Si el Clúster 1 falla, el Clúster 2 no.
Base de datos de aplicación de cinco miembros, tres clústeres: Coloque 2 miembros en cada uno de los clústeres 1 2y, y 1 en el 3 clúster. Cualquier fallo de un solo clúster deja una mayoría.
Base de datos de aplicaciones de siete miembros, dos clústeres: Ubicación 4 en 1 3 el clúster y en el 2 clúster. Solo la pérdida del clúster 2 preserva la mayoría.
Para obtener más información, consulte Arquitecturas de implementación de conjuntos de réplicas y recuperación ante desastres para recursos de Ops Manager y AppDB.
El recurso de la aplicación del administrador de operaciones
Después de que la Base de Datos de la Aplicación alcance un estado de En Ejecución, el operador de Kubernetes comienza a implementar la Aplicación Ops Manager:
El operador de Kubernetes configura un StatefulSet en cada clúster miembro de Kubernetes.
Kubernetes crea un Pod por cada réplica de Ops Manager.
Cada pod contiene un proceso de la Aplicación Ops Manager.
Para que una implementación de clúster único sea resistente a fallos de Pod, aumente spec.replicas. Para que una implementación de clúster múltiple sea resistente a fallos de centros de datos, establezca spec.topology en MultiCluster y distribuya las instancias entre los clústeres de Kubernetes.
El recurso del demonio de copia de seguridad
Si spec.backup.enabled es true, el operador de Kubernetes inicia el demonio de copia de seguridad después de que la aplicación del administrador de operaciones alcance el estado de ejecución. El operador de Kubernetes implementa un StatefulSet para el demonio de copia de seguridad en cada clúster miembro. Kubernetes crea tantos pods del demonio de copia de seguridad como se especifique en spec.backup.members.
Si la copia de seguridad está habilitada, el operador de Kubernetes crea un PersistentVolumeClaim para la base de datos principal del demonio de copia de seguridad en cada clúster miembro. La base de datos principal se configura a través de spec.backup.headDB.
El operador de Kubernetes invoca las API de Ops Manager para garantizar que la configuración de copia de seguridad de la aplicación Ops Manager coincida con la definición de recurso personalizada. Configure los almacenes de oplog, los almacenes de bloques o los almacenes de instantáneas S3 a nivel global spec.backup, no por clúster.
También puede cifrar los trabajos de copia de seguridad, pero se aplican limitaciones cuando la misma instancia de Kubernetes Operator no administra los MongoDBOpsManager MongoDB recursos personalizados y.
Conciliación del gerente de operaciones
El siguiente diagrama describe cómo el operador de Kubernetes concilia los cambios en el CRD MongoDBOpsManager:
La reconciliación se lleva a cabo siguiendo estos pasos:
Crea o actualiza el
<om_resource_name>-db-configSecreto que contiene la configuración que utiliza el agente de MongoDB para iniciar el conjunto de réplicas de la base de datos de la aplicación.Crea o actualiza el
<om_resource_name>-dbStatefulSet para la base de datos de la aplicación. Este StatefulSet contiene al menos tres Pods. Cada Pod ejecuta un agente de MongoDB que inicia unmongoden su Pod. El Secret de configuración se monta en cada Pod.En implementaciones de clústeres múltiples, el StatefulSet se denomina
<om_resource_name>-db-<cluster-idx>(por ejemplo,om-db-1).Crea o actualiza el
<om_resource_name>Conjunto deestado para la aplicación Administrador de operaciones. Cada réplica se conecta a la base de datos de la aplicación. La mayoría de los cambios activan una actualización progresiva. Habilitar TLS para la base de datos de la aplicación también activa un reinicio progresivo debido a que cambia la cadena de conexión. Los cambios enspec.backupno activan una actualización progresiva.En implementaciones de clústeres múltiples, el StatefulSet se denomina
<om_resource_name>-<cluster-idx>(por ejemplo,om-1).Crea un usuario administrador a través de la API de Ops Manager y guarda las credenciales en el
<om_resource_name>-admin-keysecreto. Este paso solo se realiza durante la implementación inicial.Permite la monitorización mediante una actualización progresiva del StatefulSet de la base de datos de la aplicación. Esto solo ocurre en la implementación inicial.
Despliega el demonio de copia de seguridad
spec.backup.enabledsitruees. El StatefulSet se denomina<om_resource_name>-backup-daemon(o<om_resource_name>-backup-daemon-<cluster-idx>en despliegues de clústeres múltiples).Configura la copia de seguridad mediante las API de Ops Manager para garantizar que la configuración de la copia de seguridad coincida con la definición del recurso personalizado.