/ /

Automatización

La Automatización de Ops Manager permite implementar, configurar y gestionar implementaciones de MongoDB con la Interfaz de Usuario de Ops Manager. La Automatización de Ops Manager depende de un MongoDB Agent, que debe instalarse en cada servidor de la implementación. Los MongoDB agentes realizan sondeos periódicos al servicio de Ops Manager para determinar el objetivo actual y reportan continuamente su estado a Ops Manager.

La automatización solo se ejecuta en arquitecturas de 64bits

Ops Manager solo proporciona descargas de 64bits del Agente MongoDB.

Usando hardware propio

Si implementa la automatización manualmente, asegúrese de tener un Agente MongoDB en cada servidor.
Si implementa el agente manualmente, debe crear MongoDB dbPath y el directorio para los binarios de MongoDB y garantizar que el usuario que ejecuta el agente sea el propietario de estos directorios.
Si instala con el paquete rpm, el agente se ejecuta como el usuario mongod; si usa el paquete deb, se ejecuta como el usuario mongodb. Si instala con el archivo tar.gz, puede ejecutar el agente como cualquier usuario.

Gestión de redes

Conectividad con los puertos de MongoDB

Todos los hosts deben permitir la comunicación entre los puertos de MongoDB. El valor predeterminado es 27017, pero puede configurar rangos de puertos alternativos en la interfaz de Ops Manager.

El agente MongoDB debe poder conectarse a Ops Manager en el puerto 8080 (HTTP) o el puerto 8443 (HTTPS). Para obtener más información sobre el acceso a los puertos y las direcciones IP, consulte Descripción general de seguridad.

Problema de conectividad dentro del clúster

Al realizar una actualización continua, el Agente MongoDB intenta evitar tiempos de inactividad. Necesita recopilar el estado de otros miembros del clúster. Un problema de conectividad (entre mongod mongosLos errores y), como la resolución del nombre de host o un firewall mal configurado, pueden impedir que el Agente MongoDB determine el estado de los procesos remotos y complete el cambio.

Para garantizar que todos los miembros del clúster puedan comunicarse entre sí:

Para un clúster no fragmentado:
1. Inicie sesión en mongod cada.
2. Desde ese host, inicie sesión en todos los demás miembros del conjunto de mongod réplicas.
Para un clúster particionado:
1. Inicie sesión en mongod cada.
2. Desde ese host, inicie sesión en todos los demás miembros del mongod fragmento.
3. Inicie sesión en mongos cada.
4. De ese mongos host:
  1. Inicie sesión en los otros hosts.mongos
  2. Inicie sesión con todos los demás miembros de cada fragmento.

Conexiones de automatización frecuentes

El Agente MongoDB recopila el estado de cada miembro del clúster cada 10 segundos para garantizar que el entorno se encuentre en el estado esperado. Como parte de esta evaluación, el Agente MongoDB crea una conexión, verifica ciertos archivos para determinar su estado y, a continuación, la cierra. Estas conexiones frecuentes y de corta duración forman parte de la actividad rutinaria del Agente MongoDB y no deberían afectar al rendimiento.

Configuración de automatización

Tras completar la configuración de la automatización, asegúrese de que el plan de implementación satisfaga las necesidades de su implementación. Compruebe los nombres de host y los puertos antes de confirmar la implementación.

Apresto

Asegúrese de proporcionar a los hosts suficiente espacio para ejecutar MongoDB y soportar los requisitos de su conjunto de datos.
Asegúrese de proporcionar una cantidad suficiente de hosts para ejecutar su implementación. Cada debe ejecutarse en su propio mongod host.

Tiempos de espera de conexión frecuentes

El agente MongoDB puede quedar frecuentemente sin conexión por uno o más de los siguientes motivos:

Tiempos de espera de conexión
Alta latencia de red
Alta carga del servidor
Claves SSL grandes
Velocidad de CPU insuficiente

De forma predeterminada, las conexiones expiran después de 40 segundos. MongoDB recomienda aumentar gradualmente el valor de la configuración del dialTimeoutSeconds Agente de MongoDB para evitar frecuentes tiempos de espera de conexión prematuros. Sin embargo, aumentar este valor también aumenta el tiempo necesario para implementar futuros cambios de configuración. Experimente con incrementos pequeños e incrementales hasta determinar el valor óptimo para su implementación.

Para obtener más información, consulte en Configuración de conexión del agente dialTimeoutSeconds MongoDB.

Implementaciones

Una pancarta que muestra We have detected a potential problem while deploying... Aparece cuando se cumplen ciertas condiciones. Estos son algunos ejemplos.

El cambio de implementación no se pudo completar/no se pudo continuar

Si ha agregado o reiniciado una implementación y la implementación permanece en el estado In Progress durante varios minutos, se muestra el banner.

En este punto, tienes cuatro opciones:

Haga clic en View Diagnostics.
El modal View Diagnostics muestra cualquier error que pueda haber ocurrido durante la implementación.
Haga clic en View Status.
El modal Automation Status muestra los procesos de implementación, cuándo informaron su estado por última vez, qué tarea intentan completar y el estado de la implementación. Puede filtrar los resultados de las siguientes maneras:
- Escriba un nombre de host en la barra de búsqueda Filter processes.
- Seleccione uno o más tipos de procesos del menú desplegable Process Type.
- Seleccione uno o más estados de automatización del menú desplegable Automation State.
Para obtener más información sobre el estado de cualquiera de los procesos individuales, puede hacer clic en el ícono de puntos suspensivos y seleccionar View Details o View Agent Logs.
- View Details muestra cuál es el plan de implementación para el proceso y en qué etapa de ese plan se encuentra actualmente el Agente MongoDB.
- View Agent Logs Abre una nueva ventana del navegador con la pantalla Deployment > Agents > Agent Logs y el contenido del registro del agente de MongoDB se muestra de forma predeterminada. Haga clic en el menú View para seleccionar otro registro del agente.
Haga clic en View Agent Logs.
Se abre una nueva ventana del navegador con la pantalla Deployment > Agents > Agent Logs y el contenido del registro del Agente de MongoDB se muestra de forma predeterminada. Haga clic en el menú View para seleccionar otro registro del agente.
Haga clic en Allow Override & Edit Configuration.
Si diagnostica un error y necesita corregir la configuración de implementación, siga el procedimiento para editar la implementación.

Si apaga la implementación y aún no puede encontrar una solución, elimine la implementación de Ops Manager.

Los agentes de MongoDB están inactivos o no se comunican

Si el módulo de automatización del agente de MongoDB no puede comunicarse con la aplicación Ops Manager API endpoint o con los procesos del servidor MongoDB, Ops Manager muestra una advertencia en el proyecto. Puede solucionar esto de dos maneras, dependiendo de si espera o no que los agentes de MongoDB se comuniquen:

Los agentes de MongoDB necesitan comunicarse

Si los agentes de MongoDB deben comunicarse con el host de Ops Manager o las instancias de MongoDB, confirme lo siguiente para cada agente de MongoDB:

El agente está activo y funcionando en cada host.
El Agente y la Aplicación Ops Manager API endpoint pueden comunicarse.

Los agentes de MongoDB no necesitan comunicarse

Si el módulo de automatización de los agentes MongoDB debe comunicarse con la aplicación Ops Manager o con los API endpoint procesos del servidor MongoDB, confirme lo siguiente para cada implementación automatizada del servidor MongoDB:

Haga clic en el enlace Allow Editing & Override Current Configuration en el banner de advertencia.
Remover todos los procesos (mongod y mongos) que se estén ejecutando en los hosts que sirven a los agentes MongoDB no necesarios.

Permisos del agente de MongoDB

Un problema de permisos puede impedir que la automatización complete un cambio. Si View Status o View Diagnostics informan un error relacionado con los permisos (como open /data/db/mongod.lock: permission denied), asegúrese de que el usuario del Agente de MongoDB sea propietario y tenga permisos de lectura y escritura en los archivos dbpath y logpath.

Eliminar hosts problemáticos de MongoDB

Puedes usar la consola o la API para eliminar de la automatización hosts obsoletos, dañados o problemáticos. Esto puede incluir el caso en que no se pueda acceder al agente de MongoDB.

Para eliminar un host problemático mediante la consola:

Navega hasta tu proyecto.
Haga clic en Servers.
Encuentra tu host problemático.
Haga clic y Remove Server luego.
Ops Manager muestra el modal Are you sure you want to remove this server>.
Ingrese el nombre de host proporcionado en el campo Enter the host name y haga clic en Remove si desea eliminar este servidor.
Advertencia
Ops Manager elimina todos los datos de monitorización de este host al hacer clic en Remove. Ops Manager no confirma ni cancela esta acción.
Si no desea eliminar el servidor, haga clic en Cancel.
Haga clic en Review & Deploy para revisar sus cambios.
Ops Manager muestra los cambios propuestos.
- Si estás satisfecho, haz clic en Confirm & Deploy.
  Ops Manager elimina todos los procesos y agentes en este momento.
- Si desea realizar más cambios de configuración, haga clic en Cancel.

Para eliminar un host problemático mediante la API:

Obtenga la configuración de automatización actual.
Edite el archivo de JSON de configuración de la automatización.
Eliminar el nodo obsoleto de los procesos y conjuntos de réplicas.
Actualice el archivo de configuración de automatización.
Espere unos minutos.
Compruebe la vista Agents.
Confirme que el host ya no aparece en la lista de agentes.

Asegúrese de que los certificados TLS contengan un nombre alternativo del sujeto

Advertencia

El Agente de MongoDB a partir de la versión 11.12.0.7384 requiere que los certificados TLS incluyan un valor en el campo Nombre alternativo del sujeto. Antes de actualizar a la 11.12.0.7384 versión, asegúrese de que todos los certificados TLS utilizados en su implementación de MongoDB contengan una SAN. []1

[1]

MongoDB desarrolló el Agente de MongoDB en el lenguaje Go. Go 1.17 eliminó la posibilidad de usar el509 campo CommonName de X. como nombre de host.Cuando no existe SAN. Cuando los clientes validan certificados TLS, comprueban el nombre o los nombres de host a los que se aplican los certificados a partir de los valores de los campos SAN o Nombre Distinguido del Sujeto (DN) del certificado. Al crear certificados TLS, algunas personas usarían el campo Nombre Común del Sujeto (CN) para almacenar el nombre de host. Los CN tienen limitaciones que los convierten en una mala opción para almacenar nombres de host. Estas limitaciones incluyen una 64longitud máxima de caracteres y la falta de compatibilidad con Restricciones de Nombre. La RFC dejó obsoleto el uso de CN para almacenar nombres de host en mayo 2818 2000 de. Esta RFC requería que los clientes recurrieran al CN si el certificado no tenía valores en el campo SAN. La RFC 6125 eliminó el requisito en.2011 1Go.15 deshabilita la adhesión a la RFC y utiliza la 2818 práctica de la RFC 6125 de hacer que el CN sea opcional. En la práctica, este cambio requiere que agregue valores SAN o habilite el uso de CN. 1 Go.17 elimina la solución alternativa para usar el CN si no existe SAN. Con la versión actual del Agente MongoDB,debe usar SAN. Para obtener más información, consulte la publicación del blog de Fraser Tweedale sobre este tema.

Almacenar archivos de configuración en la memoria para clústeres existentes

Si usa la versión de Ops Manager 4.2 o las versiones 4.4.0 -,4.4.6 puede encontrar errores enableLocalConfigurationServer al true configurar en y reiniciar su Agente MongoDB.

Este problema solo afecta a los clústeres existentes donde se establece enableLocalConfigurationServer en true después de crear el clúster. Configurar este valor antes de crear el clúster no activa este problema.

Para cambiar de forma segura esta configuración para clústeres existentes:

Al final del archivo de configuración del agente MongoDB, agregue:
```
enableLocalConfigurationServer=true
```
Apague cada proceso gestionado por MongoDB Agent.
Reinicie el agente MongoDB ejecutando el siguiente comando:
```
service mongodb-mms-automation-agent restart
```
Reinicie los procesos de MongoDB que cerró.
Verifique que el automation-mongod.conf archivo tenga la directiva de __rest expansión.

Para obtener más información sobre cómo almacenar archivos de configuración en la memoria, consulte Configurar cómo el agente MongoDB administra los archivos de configuración y las contraseñas.

Volver

Autenticación

Monitoring