MongoDB Ops Manager es una aplicación empresarial que gestiona, realiza copias de seguridad y supervisa implementaciones de MongoDB. Con Ops Manager, usted puede escalar y actualizar MongoDB, optimizar consultas, realizar restauraciones a un punto específico del tiempo, recibir alertas de rendimiento y monitorear sus implementaciones. Para gestionar y mantener Ops Manager y su base de datos subyacente, puedes utilizar los MongoDB Controllers para el operador Kubernetes para ejecutar Ops Manager como un recurso implementado en un contenedor en Kubernetes.
Puede implementar recursos de Ops Manager de una de las siguientes maneras:
Modo de clúster único de Kubernetes. Puede implementar una sola instancia de Ops Manager para respaldar la implementación de recursos de MongoDB en su clúster único de Kubernetes.
Modo de múltiples clústeres de Kubernetes. Puede implementar varias instancias de Ops Manager y base de datos de la aplicación en varios clústeres de Kubernetes. En este modo, el clúster múltiple de
Ops Managerresources admite la implementación de la aplicación Ops Manager y la base de datos de la aplicación en varios clústeres de Kubernetes.
Antes de implementar un recurso de Ops Manager en uno solo o en varios clústeres de Kubernetes, revisa Arquitectura de Ops Manager en Kubernetes y consideraciones, y completar los requisitos previos.
Arquitectura
Para obtener detalles sobre la arquitectura de recursos de Ops Manager, consulte:
Implementaciones individuales de clústeres de Kubernetes de recursos de Ops Manager: Arquitectura de Ops Manager en Kubernetes.
Múltiples implementaciones de clústeres Kubernetes de recursos de Ops Manager: Arquitectura Multi-Cluster de Ops Manager.
Considerations
llave de cifrado
El Operador de Kubernetes genera una llave de cifrado para proteger información sensible en la base de datos de la aplicación de Ops Manager. El operador de Kubernetes guarda esta clave en un secreto en el mismo namespace que el recurso Ops Manager. El operador de Kubernetes nombra el secreto <om-resource-name>-gen-key.
Nota
Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.
Si remueves el recurso Ops Manager, la clave seguirá almacenada en el secreto en el clúster de Kubernetes. Si almacenaste la base de datos de la aplicación en un volumen persistente y creas otro recurso de Ops Manager con el mismo nombre, el operador de Kubernetes reutiliza el secreto. Si creas un recurso de Ops Manager con un nombre diferente, entonces el Operador de Kubernetes crea un nuevo secreto y una nueva base de datos de la aplicación, y el secreto antiguo no se reutiliza.
Base de datos de la aplicación
topología
Cuando creas una instancia de Ops Manager a través del Operador Kubernetes en un solo clúster de Kubernetes, la Base de Datos de la Aplicación de Ops Manager se implementa como un set de réplicas. No puedes configurar la base de datos de la aplicación como una base de datos autónoma o un clúster. Si tienes dudas sobre el desempeño o los requisitos de tamaño de la base de datos de la aplicación, ponte en contacto con Soporte de MongoDB.
Cuando creas una instancia de Ops Manager a través de Kubernetes Operator en un modo multiclúster, Kubernetes Operator puede configurar la Base de datos de la aplicación de Ops Manager en múltiples clústeres miembro. Para obtener más información, consulte Arquitectura de Multi-Clúster Ops Manager.
Monitoring
El operador de Kubernetes configura automáticamente Ops Manager para supervisar la base de datos de la aplicación que la respalda. El operador de Kubernetes crea un proyecto llamado <ops-manager-deployment-name>-db para que usted supervise la implementación de la base de datos de la aplicación.
Ops Manager supervisa la implementación de la base de datos de la aplicación, pero Ops Manager no la gestiona. No se puede cambiar la configuración de la base de datos de la aplicación en Ops Manager aplicación.
Importante
La interfaz de usuario de Ops Manager podría mostrar advertencias en el proyecto <ops-manager-deployment-name>-db que indican que los agentes de la base de datos de la aplicación están desactualizados. Puede ignorar estas advertencias sin problema.
Autenticación
El operador de Kubernetes aplica autenticación de SCRAM-SHA-256 en la base de datos de la aplicación.
El Operador de Kubernetes crea el usuario de base de datos que Ops Manager utiliza para conectarse a la base de datos de la aplicación. Este usuario de base de datos tiene los siguientes atributos:
Nombre de usuario |
|
Base de datos de autenticación |
|
Roles |
No puedes modificar el nombre de usuario y los roles de la base de datos de Ops Manager. Crear un secreto para establecer la contraseña del usuario de base de datos. Edita el secreto para actualizar la contraseña. Si no creas un secreto o eliminas un secreto existente, el Operador de Kubernetes genera una contraseña y la almacena.
Para obtener más información sobre otras opciones de almacenamiento de secretos, consulte Configurar el almacenamiento de secretos. Las implementaciones multiclúster no admiten el almacenamiento de secretos en HashiCorp Vault.
Implementaciones fuera de línea
El operador de Kubernetes requiere que se especifique la versión de MongoDB Enterprise para la base de datos de la aplicación para habilitar cualquier implementación de los recursos de Ops Manager, incluidas las implementaciones sin conexión.
Configuración optimizada
Después de implementar Ops Manager, es necesario configurarlo. El procedimiento regular implica configurar Ops Manager a través del asistente de configuración. Si configuras algunos ajustes esenciales en la especificación de tu objeto antes de implementarla, puedes omitir el asistente de configuración.
En el bloque spec.configuration de la especificación del objeto Ops Manager, se debe:
Añade mms.ignoreInitialUiSetup y ajústalo a
true.Agregue las configuraciones mínimas para permitir que la instancia de Ops Manager se inicie sin errores.
Ejemplo
Para deshabilitar el asistente de configuración de Ops Manager, configura los siguientes ajustes en tu bloque spec.configuration:
1 spec: 2 configuration: 3 mms.ignoreInitialUiSetup: "true" 4 automation.versions.source: "remote" 5 mms.adminEmailAddr: cloud-manager-support@mongodb.com 6 mms.fromEmailAddr: cloud-manager-support@mongodb.com 7 mms.mail.hostname: email-smtp.us-east-1.amazonaws.com 8 mms.mail.port: "465" 9 mms.mail.ssl: "true" 10 mms.mail.transport: smtp 11 mms.minimumTLSVersion: TLSv1.2 12 mms.replyToEmailAddr: cloud-manager-support@mongodb.com
Reemplace los valores de ejemplo con los valores que desea que utilice su Ops Manager.
Backup
El operador de Kubernetes habilita la copia de seguridad de forma predeterminada. Implementa un StatefulSet compuesto por un pod para alojar el servicio Daemon de copia de seguridad y, a continuación, crea una reclamación de volumen persistente y un volumen persistente para la base de datos principal del Daemon de copia de seguridad. Utiliza la API de Ops Manager para habilitar el Daemon de copia de seguridad y configurar la base de datos principal.
Importante
Para configurar Backup, debe crear los MongoDB recursos o MongoDBMultiCluster para el almacén de registros de operaciones y para uno de los siguientes:
tienda de oplog o 3 Almacén de registros de operaciones S. Si implementa tanto el almacén de 3 registros de operaciones como el S, Ops Manager elige uno al azar para usar como copia de seguridad.
S3 almacenamiento de snapshot or blockstore. Si despliegas tanto un S3 almacenamiento de snapshot como un almacenamiento en bloques, Ops Manager elige uno de forma aleatoria para realizar la copia de seguridad.
El recurso de Ops Manager permanece en un estado Pending hasta que se configuren estos recursos de copias de seguridad.
También puedes cifrar las tareas de copia de seguridad, pero se aplican limitaciones a las implementaciones en las que la misma instancia del operador de Kubernetes no administra tanto los recursos personalizados MongoDBOpsManager como MongoDB.
Almacenamiento Oplog
Debe implementar un conjunto de réplicas de tres miembros para almacenar sus porciones de registro de operaciones.
La base de datos Oplog solo admite el mecanismo de autenticación SCRAM. No se pueden habilitar otros mecanismos de autenticación.
Si activa la autenticación SCRAM en la base de datos oplog, debe:
Cree un recurso de usuario de MongoDB para conectar Ops Manager a la base de datos oplog.
Especifica el
namedel usuario en la definición del recurso de Ops Manager.
Tienda de Oplog S3
Para configurar un almacén de Oplog S3, debes crear una cubeta AWS S3 o una cubeta S3-compatible para almacenar la copia de seguridad de tu base de datos Oplog.
Puedes configurar el almacén de oplog tanto para el recurso MongoDB como para el recurso MongoDBMultiCluster, utilizando la configuración spec.backup.s3OpLogStores.mongodbResourceRef.name en la definición de recursos del Ops Manager.
Blockstore
Para configurar un almacén de bloques, debe implementar un conjunto de réplicas para almacenar instantáneas.
almacén de snapshots de S3
Para configurar un almacén de instantáneas S,3debe crear un depósito compatible con AWS S3 o S para almacenar3 las instantáneas derespaldo de su base de datos.
La configuración predeterminada almacena los metadatos de las instantáneas en la Base de Datos de la Aplicación. También puedes implementar un set de réplicas para almacenar los metadatos de los snapshots y luego configurarlo usando la spec.backup.s3Stores.mongodbResourceRef.name en la definición del recurso de Ops Manager.
Puedes configurar el almacén de snapshots de S3 tanto para el recurso MongoDB como para el recurso MongoDBMultiCluster.
Puedes actualizar cualquier configuración adicional S3 configuración que el Operador de Kubernetes no gestione a través de la aplicación Ops Manager.
Deshabilitar copia de seguridad
Para desactivar la copia de seguridad después de haberla habilitado:
Establece la configuración de Ops Manager Kubernetes objeto
spec.backup.enabledafalse.Desactivar copias de seguridad en la aplicación Ops Manager.
Elimina el Servicio Daemon de Copia de seguridad StatefulSet:
kubectl delete statefulset <metadata.name> -backup-daemon \ -n <metadata.namespace>
Importante
El Reclamo de Volumen Persistente y el Volumen Persistente para la base de datos principal del daemon de copias de seguridad no se eliminan cuando eliminas el Servicio de daemon de copias de seguridad StatefulSet. Puedes recuperar los datos almacenados antes de borrar estos recursos de Kubernetes.
Para aprender sobre la recuperación de Volúmenes Persistentes, ve la documentación de Kubernetes.
Configurar manualmente el cifrado de copia de seguridad KMIP
En las implementaciones donde la misma instancia de Kubernetes Operator no gestiona tanto el MongoDBOpsManager como los recursos personalizados de MongoDB, debe configurar manualmente la configuración del cliente de cifrado de copia de seguridad KMIP en Ops Manager utilizando el siguiente procedimiento. Si el operador de Kubernetes está gestionando ambos recursos, consulta Configura la encriptación de copia de seguridad KMIP para Ops Manager en su lugar.
Requisitos previos
Un servidor KMIP en ejecución.
Una instancia de Ops Manager en ejecución, configurada para usar KMIP.
Un secreto TLS que concatena la llave privada y el certificado de cliente KMIP en formato PEM.
Procedimiento
Monte el secreto TLS en el recurso personalizado MongoDBOpsManager. Por ejemplo:
apiVersion: mongodb.com/v1 kind: MongoDBOpsManager metadata: name: ops-manager-pod-spec spec: < ... omitted ... > statefulSet: spec: template: spec: volumes: - name: kmip-client-test-prefix-mdb-latest-kmip-client secretName: test-prefix-mdb-latest-kmip-client containers: - name: mongodb-ops-manager volumeMounts: - mountPath: /mongodb-ops-manager/kmip/client/test-prefix-mdb-latest-kmip-client name: kmip-client-test-prefix-mdb-latest-kmip-client readOnly: true ... Configure los ajustes de KMIP para su proyecto en Ops Manager siguiendo el procedimiento en Configurar su proyecto para usar KMIP.
Configurar Ops Manager para que se ejecute a través de HTTPS
Puede configurar su instancia de Ops Manager creada a través del operador de Kubernetes para que se ejecute mediante HTTPS en lugar de HTTP.
Para configurar tu instancia de Ops Manager para ejecutar sobre HTTPS:
Cree un secreto que contenga el certificado TLS y la clave privada.
Agregue este secreto al objeto de configuración de Ops Manager.
Para obtener instrucciones detalladas, consulta Implementar un recurso de Ops Manager.
Importante
Si tienes implementaciones existentes, debes reiniciarlas manualmente después de habilitar HTTPS. Para evitar reiniciar tus implementaciones, configura HTTPS antes de implementar tus recursos gestionados.
Para obtener más información,consulte HTTPS habilitado después de la implementación.
Acceso a la aplicación Ops Manager
De forma predeterminada, el operador de Kubernetes no crea un servicio de Kubernetes para enrutar el tráfico que se origina fuera del clúster de Kubernetes a la aplicación Ops Manager.
Para acceder a la aplicación de Ops Manager, puede:
Configure el operador de Kubernetes para crear un servicio de Kubernetes.
Cree un servicio de Kubernetes manualmente. MongoDB recomienda utilizar un servicio de Kubernetes
LoadBalancersi tu proveedor de nube lo admite.Si está utilizando OpenShift, utilice rutas.
Utilice un servicio de terceros, como Istio.
El método más sencillo es configurar el operador de Kubernetes para crear un servicio de Kubernetes que enrute el tráfico externo hacia la aplicación Ops Manager. El procedimiento de implementación de Ops Manager te indica que añadas los siguientes ajustes a la especificación objeto que configura el Operador de Kubernetes para crear un servicio:
spec.externalConnectivityspec.externalConnectivity.type
Además, para implementaciones en múltiples clústeres de Kubernetes, consulta Redes, balanceo de carga, malla de servicios.
Implementando Ops Manager en modo remoto o local
Puedes usar el Operador de Kubernetes para configurar un solo clúster de Ops Manager para que funcione en modo Local o Remoto si tu entorno impide que los hosts de tu clúster de Kubernetes tengan acceso a Internet. En estos modos, los demonios de copia de seguridad y los recursos gestionados de MongoDB descargan ficheros de instalación desde Ops Manager en lugar de hacerlo desde Internet:
Configurar un recurso de Ops Manager para usar el modo remoto: Ops Manager lee los archivos de instalación desde los puntos finales HTTP en un servidor web o un almacén de archivos compatible con S3 implementado en su clúster de Kubernetes.
Configurar un recurso de Ops Manager para usar el modo local: Ops Manager lee los archivos de instalación desde un volumen persistente que usted crea para Ops Manager StatefulSet.
Administración de implementaciones externas de MongoDB
Cuando implementa Ops Manager con el operador de Kubernetes, Ops Manager puede administrar los recursos de base de datos MongoDB implementados:
Al mismo clúster de Kubernetes que Ops Manager.
Fuera de los clústeres de Kubernetes.
Si Ops Manager gestiona recursos de base de datos de MongoDB implementados en diferentes clústeres de Kubernetes que Ops Manager o fuera de los clústeres de Kubernetes, debe:
Agregue la configuración
mms.centralUrlaspec.configurationen la especificación de recursos del Ops Manager.Establece el valor en el URL mediante el cual Ops Manager está expuesto fuera del clúster de Kubernetes:
spec: configuration: mms.centralUrl: https://a9a8f8566e0094380b5c257746627b82-1037623671.us-east-1.elb.example.com:8080/ Actualice los ConfigMaps referenciados por todos los recursos de base de datos MongoDB dentro del clúster de Kubernetes que implementó con el Kubernetes Operator.
Establece
data.baseUrlal mismo valor de la configuraciónspec.configuration.mms.centralUrlen la especificación del recurso de Ops Manager.Importante
Implementación de Ops Manager en varios clústeres
Consulte Arquitectura de Ops Manager de múltiples clústeres.
Almacenamiento secreto
Para evitar almacenar secretos en Kubernetes, migre todos los secretos que crea el operador de Kubernetes a una herramienta de almacenamiento de secretos. Las implementaciones multiclúster no admiten el almacenamiento de secretos en herramientas como HashiCorp Vault.
Requisitos previos
Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los
kubectlcomandos en el espacio de nombres que creó:kubectl config set-context $(kubectl config current-context) \ –-namespace <metadata.namespace> Nota
Si está implementando un recurso de Ops Manager en una implementación de MongoDB de un clúster de Kubernetes múltiple:
Defina
contextcomo el nombre del clúster operador, por ejemplo:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".Establece el
--namespaceen el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo:kubectl config --namespace "mongodb".
Instala los controladores de MongoDB para el operador de Kubernetes.
Asegúrate de que el host en el que deseas implementar Ops Manager tenga un mínimo de cinco gigabytes de memoria.
Cree un secreto de Kubernetes para un usuario administrador en el mismo namespace que el recurso Ops Manager. Si estás implementando Ops Manager en una implementación de MongoDB en un clúster multi-Kubernetes, utiliza el mismo namespace que configuraste para el alcance.de tu implementación de MongoDB en clúster multi-Kubernetes
Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.
Para conocer sus opciones para el almacenamiento de secretos, consulte Configurar almacenamiento de secretos.
Cuando implementas el recurso Ops Manager, Ops Manager crea un usuario con estas credenciales y le otorga el rol de
Global Owner. Utilice estas credenciales para iniciar sesión en Ops Manager por primera vez. Una vez que implemente Ops Manager, cambie la contraseña o remueva este secreto.Nota
La contraseña del usuario administrador debe cumplir con los requisitos de complejidad de contraseña de Ops Manager.
kubectl create secret generic <adminusercredentials> \ --from-literal=Username="<username>" \ --from-literal=Password="<password>" \ --from-literal=FirstName="<firstname>" \ --from-literal=LastName="<lastname>"
(Opcional) Para establecer la contraseña para el usuario de base de datos de Ops Manager, crea un secreto en el mismo namespace que el recurso Ops Manager.
Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.
El operador de Kubernetes crea el usuario de base de datos que Ops Manager utiliza para conectarse a la Base de Datos de la Aplicación Ops Manager. Puedes establecer la contraseña para este usuario de base de datos invocando el siguiente comando para crear un secreto:
kubectl create secret generic <om-db-user-secret-name> \ --from-literal=password="<om-db-user-password>" Nota
Si decides crear un secreto para el usuario de base de datos Ops Manager, debes especificar el
namedel secreto en la definición de recursos de Ops Manager. Por defecto, el operador de Kubernetes busca el valor de la contraseña en la clavepassword. Si almacenaste el valor de la contraseña en una clave diferente, también debes especificar ese nombrekeyen la definición del recurso de Ops Manager.Si no crea un secreto, el operador de Kubernetes genera automáticamente una contraseña y la almacena internamente. Para obtener más información,consulte Autenticación.
(Opcional). Paraconfigurar la copia de seguridad3en un almacén de instantáneas S, cree un secreto en el mismo espacio de nombres que el recurso Ops Manager.
Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.
Este secreto almacena sus credenciales de S3 para que el operador de Kubernetes pueda conectar Ops Manager a su bucket de AWS S3o compatible con S3. El secreto debe contener los siguientes pares clave-valor:
Clave
Valor
accessKeyIdentificador único del usuario de AWS que posee el bucket de S3 o S3compatible.
secretKeyClave secreta del usuario AWS que posee el S3 o el bucket compatible con S3.
Para crear el secreto, invoque el siguiente comando:
kubectl create secret generic <my-aws-s3-credentials> \ --from-literal=accessKey="<AKIAIOSFODNN7EXAMPLE>" \ --from-literal=secretKey="<wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY>" Para obtener más información sobre la gestión del almacenamiento de instantáneas de S3, consulte los prerrequisitos.