MongoDB Ops Manager es un componente necesario para cualquier implementación de MongoDB Enterprise. 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 Ops Manager — el componente principal de Ops Manager y la interfaz de usuario front-end.
Base de datos de la aplicación: la base de datos MongoDB que da soporte a MongoDB Ops Manager.
daemon de copias de seguridad — es compatible con la aplicación MongoDB Ops Manager 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 adecuadas en cada clúster de Kubernetes donde implementa los componentes de Ops Manager.
El siguiente diagrama muestra la arquitectura de una implementación de MongoDB 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 set de réplicas de MongoDB como un StatefulSet. Cada Pod tiene los siguientes contenedores:
mongod — el proceso de la base de datos.
MongoDB Agent — gestiona el ciclo de vida
mongod. Puede anular la versión del MongoDB Agent utilizando la variable de entorno$AGENT_IMAGEoagent.versionen la gráfica Helm.Agente de supervisión: envía datos de supervisión a Ops Manager. La versión se selecciona automáticamente para la compatibilidad con versiones anteriores y no se puede anular.
El operador de Kubernetes transfiere la configuración de la base de datos de la aplicación a los agentes mediante un Secret (<om_resource_name>-db-config) montado en cada Pod.
Kubernetes crea un Pod por nodo. Cada MongoDB Agent inicia mongod y lo agrega al set de réplicas. El operador de Kubernetes crea PersistentVolumeClaims para cada Pod, y puede personalizarlas con spec.applicationDatabase.podSpec.persistence.
El operador de Kubernetes crea un servicio sin encabezado para la conectividad interna. En implementaciones de varios clústeres, el operador de Kubernetes también crea un servicio por Pod (<om_resource_name>-db-N-svc) para la direccionabilidad individual de mongod.
Consideraciones sobre la topología de la base de datos de la aplicación
Para elegir un primario, la mayoría de los nodos del set de réplicas de la base de datos de la aplicación deben estar disponibles. Si es posible, utilice una cantidad impar de clústeres de Kubernetes de nodos y distribuya los nodos a través de centros de datos, zonas o clústeres.
Considere estos ejemplos de distribución:
Base de datos de la aplicación de cinco nodos, dos clústeres: coloque 3 nodos en el clúster 1 y 2 en el clúster 2. Si el clúster 2 falla, el clúster 1 tiene mayoría. Si el clúster 1 falla, el clúster 2 no.
Base de datos de la aplicación de cinco nodos, tres clúster: coloque 2 nodos en los clúster 1 y 2, y 1 en el clúster 3. Cualquier error de un solo clúster deja una mayoría.
Base de datos de la aplicación de siete nodos, dos clúster: coloque 4 en el clúster 1 y 3 en el clúster 2. Solo la pérdida del clúster 2 conserva la mayoría.
Para obtener más información, consulta Arquitecturas de implementación de set de réplicas y Recuperación ante desastres para los recursos de MongoDB Ops Manager y AppDB.
El recurso de aplicación de MongoDB Ops Manager
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 de Kubernetes de los nodos.
Kubernetes crea un Pod por réplica de MongoDB Ops Manager.
Cada pod contiene un proceso de la Aplicación Ops Manager.
Para que una implementación de un solo clúster sea resistente a fallas de Pod, aumente spec.replicas. Para que una implementación de varios clústeres sea resistente a fallas del centro de datos, establezca spec.topology en MultiCluster y distribuya las instancias en los clústeres de Kubernetes.
El recurso de daemon de copias de seguridad
Si spec.backup.enabled es true, el operador de Kubernetes inicia el daemon de copias de seguridad después de que la aplicación de Ops Manager alcance el estado de ejecución. El operador de Kubernetes implementa un StatefulSet para el daemon de copias de seguridad en cada clúster de nodos. Kubernetes crea tantos pods de daemon de copias de seguridad como se especifica 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 copias de seguridad en cada clúster nodo. Puede configurar la base de datos principal 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 personalizado. Configure oplog stores, blockstores o S3 almacenamientos de snapshot a nivel global spec.backup, no por clúster.
También puedes cifrar las tareas de copia de seguridad, pero se aplican limitaciones cuando la misma instancia del operador de Kubernetes no gestiona tanto los recursos personalizados MongoDBOpsManager como MongoDB.
Reconciliación de MongoDB Ops Manager
El siguiente diagrama describe cómo el operador de Kubernetes concilia los cambios en el CRD MongoDBOpsManager:
La conciliación procede a través de estos pasos:
Crea o actualiza el
<om_resource_name>-db-configSecreto que contiene la configuración que el MongoDB Agent utiliza para iniciar el set 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 MongoDB Agent que inicia unmongoden su Pod. El secreto de configuración se monta en cada Pod.En implementaciones de clúster múltiple, el StatefulSet se denomina
<om_resource_name>-db-<cluster-idx>(por ejemplo,om-db-1).Crea o actualiza el
<om_resource_name>StatefulSet para la aplicación MongoDB Ops Manager. Cada réplica se conecta a la base de datos de la aplicación. La mayoría de los cambios activan una actualización rotativa. Habilitar TLS para la base de datos de la aplicación también activa un reinicio en secuencia porque la cadena de conexión cambia. Los cambios enspec.backupno activan una actualización rotativa.En implementaciones de clúster múltiple, el StatefulSet se denomina
<om_resource_name>-<cluster-idx>(por ejemplo,om-1).Crea un usuario administrador a través de la API de MongoDB Ops Manager y guarda las credenciales en el secreto
<om_resource_name>-admin-key. Este paso solo ocurre en la implementación inicial.Habilita la supervisión mediante la realización de una actualización continua del StatefulSet de la base de datos de la aplicación. Esto también ocurre solo en la implementación inicial.
Implementa el daemon de copia de seguridad si
spec.backup.enabledestrue. El StatefulSet se denomina<om_resource_name>-backup-daemon(o<om_resource_name>-backup-daemon-<cluster-idx>en implementaciones de varios clústeres).Configura la copia de seguridad a través de las API de Ops Manager para garantizar que la configuración de la copia de seguridad coincida con la definición de recurso personalizado.