Planifique su recurso de administrador de operaciones

Esta versión de la documentación está archivada y ya no se admite, y el operador de Kubernetes de MongoDB Enterprise está obsoleto. El nuevo El Operador de Controladores para Kubernetes de MongoDB reemplaza al Operador de Kubernetes Empresarial de MongoDB. La primera versión del Operador de Controladores para Kubernetes es funcionalmente equivalente a la última versión del Operador de Kubernetes Empresarial,1.33 v. Para obtener más información sobre este cambio y orientación sobre la migración al nuevo Operador, consulte las notas de la versión de la primera versión. No habrá futuras versiones del Operador de Kubernetes Empresarial de MongoDB. Cada versión alcanzará el final de su vida útil según el plazo de un año vigente. Política de soporte. Migre al operador de controladores para Kubernetes para obtener soporte continuo.

MongoDB Ops Manager es una aplicación empresarial que administra, realiza copias de seguridad y supervisa las implementaciones de MongoDB. Con Ops Manager, puede escalar y actualizar MongoDB, optimizar consultas, realizar restauraciones puntuales, recibir alertas de rendimiento y supervisar sus implementaciones. Para administrar y mantener Ops Manager y su base de datos subyacente, puede usar MongoDB Enterprise Kubernetes Operator 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 clúster múltiple de Kubernetes. Puede implementar varias instancias de Ops Manager y de la base de datos de aplicaciones en varios clústeres de Kubernetes. En este modo, el multiclúster de Ops Manager Los recursos admiten una implementación de la aplicación Ops Manager y la base de datos de la aplicación en múltiples clústeres de Kubernetes.

Antes de implementar un recurso de Ops Manager en uno o varios clústeres de Kubernetes, revise la Arquitectura de Ops Manager en Kubernetes y las consideraciones, y complete los requisitos previos.

Arquitectura

Para obtener detalles sobre la arquitectura de recursos de Ops Manager, consulte:

Implementaciones de clústeres individuales de Kubernetes de recursos de Ops Manager: Arquitectura de Ops Manager en Kubernetes.
Implementaciones de múltiples clústeres de Kubernetes de recursos de Ops Manager: arquitectura de Ops Manager de múltiples clústeres.

Considerations

Clave de cifrado

The Kubernetes Operator generates an encryption key to protect sensitive information in the Ops Manager Application Database. The Kubernetes Operator saves this key in a secret in the same namespace as the Ops Manager resource. The Kubernetes Operator names the secret <om-resource-name>-gen-key.

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puede migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en varios clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.

Si elimina el recurso de Ops Manager, la clave permanece almacenada en el secreto del clúster de Kubernetes. Si almacenó la base de datos de la aplicación en un volumen persistente y crea otro recurso de Ops Manager con el mismo nombre, el operador de Kubernetes reutiliza el secreto. Si crea un recurso de Ops Manager con un nombre diferente, el operador de Kubernetes crea un nuevo secreto y una base de datos de la aplicación, y el secreto anterior no se reutiliza.

Base de datos de la aplicación

Topología

Al crear una instancia de Ops Manager mediante el operador de Kubernetes en un único clúster de Kubernetes, la base de datos de la aplicación de Ops Manager se implementa como un conjunto de réplicas. No se puede configurar la base de datos de la aplicación como una base de datos independiente ni como un clúster fragmentado. Si tiene alguna duda sobre el rendimiento o los requisitos de tamaño de la base de datos de la aplicación, póngase en contacto con el soporte técnico de MongoDB.
Al crear una instancia de Ops Manager mediante el operador de Kubernetes en modo multiclúster, este puede configurar la base de datos de la aplicación de Ops Manager en varios clústeres. Para obtener más información, consulte Arquitectura de Ops Manager en varios clústeres.

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 no la administra. No se puede cambiar la configuración de la base de datos de la aplicación en Ops Manager.

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 la SCRAM-SHA-256 autenticación 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	`mongodb-ops-manager`
Base de datos de autenticación	`admin`
Roles	`readWriteAnyDatabase` `dbAdminAnyDatabase` `clusterMonitor`

No se pueden modificar el nombre ni los roles del usuario de la base de datos de Ops Manager. Se crea un secreto para establecer la contraseña del usuario de la base de datos. Se edita el secreto para actualizar la contraseña. Si no se crea un secreto o se elimina uno 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 sin conexión

El operador de Kubernetes requiere que especifique la versión de MongoDB Enterprise para la imagen de la base de datos de la aplicación para habilitar cualquier implementación de recursos de Ops Manager, incluidas las implementaciones sin conexión.

Configuración optimizada

Tras implementar Ops Manager, debe configurarlo. El procedimiento habitual consiste en configurar Ops Manager mediante el asistente de configuración. Si configura algunos ajustes esenciales en la especificación del objeto antes de la implementación, puede omitir el asistente de configuración.

En el spec.configuration bloque de la especificación del objeto Ops Manager, debe:

Agregue mms.ignoreInitialUiSetup y configúrelo true en.
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, configure los siguientes ajustes en su spec.configuration bloque:

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 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 Almacén de instantáneas o almacén de bloques. Si implementa tanto un almacén de instantáneas S3como un almacén de bloques, Ops Manager elige uno al azar para la copia de seguridad.

El recurso Ops Manager permanece en un estado Pending hasta que configure estos recursos de respaldo.

También puede cifrar trabajos de respaldo, pero se aplican limitaciones a las implementaciones donde la misma instancia de operador de Kubernetes no administra tanto MongoDBOpsManager como los recursos personalizados de 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 habilita la autenticación SCRAM en la base de datos de oplog, debe:

Cree un recurso de usuario MongoDB para conectar Ops Manager a la base de datos oplog.
Especifica el name del usuario en la definición del recurso de Ops Manager.

Tienda de registros de operaciones S3

Para configurar un almacén de registros3 de operaciones S, debe crear un depósito compatible con AWS S3 o S3para almacenar el registro de operaciones de respaldo de su base de datos.

Puede configurar el almacén de registros de operaciones tanto para el MongoDB recurso como para el MongoDBMultiCluster recurso, utilizando la spec.backup.s3OpLogStores.mongodbResourceRef.name configuración en la definición de recurso de Ops Manager.

Blockstore

Para configurar un almacén de bloques, debe implementar un conjunto de réplicas para almacenar instantáneas.

Tienda de instantáneas 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 puede implementar un conjunto de réplicas para almacenar los metadatos de las instantáneas y luego configurarlo mediante spec.backup.s3Stores.mongodbResourceRef.name la configuración en la definición del recurso de Ops Manager.

Puede configurar el almacén de instantáneas S3 tanto para el MongoDB recurso como para el MongoDBMultiCluster recurso.

Puede actualizar cualquier configuración adicional de S3que Kubernetes Operator no administra a través de la aplicación Ops Manager.

Deshabilitar copia de seguridad

Para deshabilitar la copia de seguridad después de habilitarla:

Establezca la configuración spec.backup.enabled del objeto Kubernetes de Ops Manager false en.
Deshabilite las copias de seguridad en la aplicación Ops Manager.
Eliminar el conjunto de estado del servicio de demonio de copia de seguridad:
```
kubectl delete statefulset <metadata.name> -backup-daemon \
 -n <metadata.namespace>
```

Importante

La reclamación de volumen persistente y el volumen persistente de la base de datos principal del demonio de copia de seguridad no se eliminan al eliminar el conjunto de estado del servicio del demonio de copia de seguridad. Puede recuperar los datos almacenados antes de eliminar 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 la copia de seguridad de KMIP

Para las implementaciones donde la misma instancia de operador de Kubernetes no administra los recursos personalizados de MongoDBOpsManager y MongoDB, debe configurar manualmente los ajustes del cliente de cifrado de copia de seguridad de KMIP en Ops Manager mediante el siguiente procedimiento. Si el operador de Kubernetes administra ambos recursos,consulte Configurar el cifrado de copia de seguridad de KMIP para Ops Manager.

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 clave 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 su instancia de Ops Manager para que se ejecute a través de 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,consulte Implementar un recurso de Ops Manager.

Importante

Si tiene implementaciones existentes, debe reiniciarlas manualmente después de habilitar HTTPS. Para evitar reiniciar sus implementaciones, configure HTTPS antes de implementar sus recursos administrados.

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 Ops Manager, puede:

Configure el operador de Kubernetes para crear un servicio de Kubernetes.
Cree un servicio de Kubernetes manualmente. MongoDB recomienda usar un servicio de Kubernetes LoadBalancer si su proveedor de nube lo admite.
Si está utilizando OpenShift, utilice rutas.
Utilice un servicio de terceros, como Istio.

El método más sencillo consiste en configurar el operador de Kubernetes para crear un servicio de Kubernetes que enrute el tráfico externo a la aplicación Ops Manager. El procedimiento de implementación de Ops Manager le indica que agregue las siguientes configuraciones a la especificación del objeto que configura el operador de Kubernetes para crear un servicio:

spec.externalConnectivity
spec.externalConnectivity.type

Además, para implementaciones en múltiples clústeres de Kubernetes,consulte Redes, Equilibrio de carga, Service Mesh.

Implementación de Ops Manager en modo remoto o local

Puede usar el operador de Kubernetes para configurar un solo clúster de Ops Manager y que funcione en modo local o remoto si su entorno impide que los hosts de su clúster de Kubernetes accedan a Internet. En estos modos, los daemons de respaldo y los recursos administrados de MongoDB descargan los archivos 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 un3almacén de archivos compatible con S 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.centralUrl a spec.configuration en la especificación de recursos de Ops Manager.
Establezca el valor en la URL mediante la cual Ops Manager se expone fuera del clúster de Kubernetes:
```
spec:
  configuration:
    mms.centralUrl: https://a9a8f8566e0094380b5c257746627b82-1037623671.us-east-1.elb.example.com:8080/
```
Actualice los ConfigMaps a los que hacen referencia todos los recursos de base de datos MongoDB dentro del clúster de Kubernetes que implementó con el operador de Kubernetes.
Establece data.baseUrl al mismo valor de la configuración spec.configuration.mms.centralUrl en la especificación del recurso de Ops Manager.
Importante
Esto incluye los ConfigMaps a los que hacen referencia los recursos de base de datos MongoDB para los almacenes de registros de operaciones e instantáneas.

Implementación de Ops Manager en varios clústeres

Consulte Arquitectura de Multi-Cluster Ops Manager.

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 kubectl comandos en el espacio de nombres que creó:
```
kubectl config set-context $(kubectl config current-context) \
  -n <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:
- Establezca context en el nombre del clúster del operador, como por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".
- Establezca --namespace en el mismo ámbito que utilizó para su implementación de MongoDB en un clúster de Kubernetes múltiple, como porkubectl config --namespace "mongodb" ejemplo:.
Instalar el operador Kubernetes de MongoDB Enterprise.
Asegúrese de que el host en el que desea implementar Ops Manager tenga un mínimo de cinco gigabytes de memoria.

Cree un secreto de Kubernetes para un usuario administrador en el mismo espacio de nombres que el recurso de Ops Manager. Si va a implementar Ops Manager en una implementación de MongoDB con varios clústeres de Kubernetes, use el mismo espacio de nombres que configuró para el ámbito de la implementación de MongoDB con varios clústeres de Kubernetes.

Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

Para conocer más sobre sus opciones de almacenamiento secreto,consulte Configurar almacenamiento secreto.

Al implementar el recurso Ops Manager, este crea un usuario con estas credenciales y le asigna el Global Owner rol. Úselas para iniciar sesión en Ops Manager por primera vez. Una vez implementado, cambie la contraseña o elimine 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ñapara el usuario de la base de datos de Ops Manager, cree un secreto en el mismo espacio de nombres que el recurso de 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. Puede establecer la contraseña de 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 name del 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 clave password. Si almacenaste el valor de la contraseña en una clave diferente, también debes especificar ese nombre key en 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 compatible con AWS S3 o S. El secreto debe contener los siguientes pares clave-valor:3

Clave	Valor
`accessKey`	Identificador único del usuario de AWS que posee el depósito compatible con3 S3o S.
`secretKey`	Clave 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 cómo administrar el3 almacenamiento de instantáneas de S, consulte Requisitos previos.

Volver

Rendimiento

Implementar en varios clústeres

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