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 64 bits
Ops Manager solo proporciona descargas de 64 bits del Agente MongoDB.
Usando hardware propio
Si implementa la automatización manualmente, asegúrese de tener un Agente MongoDB en cada servidor.
If you deploy the agent manually, you must create MongoDB's
dbPathand the directory for the MongoDB binaries and ensure that the user running the agent owns these directories.Si instala con el paquete
rpm, el agente se ejecuta como el usuariomongod; si usa el paquetedeb, se ejecuta como el usuariomongodb. Si instala con el archivotar.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.
The MongoDB Agent must be able to connect to Ops Manager on port 8080 (HTTP) or port 8443 (HTTPS). For more information on access to ports and IP addresses, see
Security Overview.
Problema de conectividad dentro del clúster
When performing a rolling update, the MongoDB Agent tries to avoid downtime. It needs to collect state from other members of the cluster. A connectivity issue (between mongods and mongoses), such as hostname resolution or misconfigured firewall, may prevent the MongoDB Agent from determining the remote processes state and completing the change.
Para garantizar que todos los miembros del clúster puedan comunicarse entre sí:
Para un clúster no fragmentado:
Para un clúster particionado:
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
mongodhost.
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 a los 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
A banner that displays We have detected a potential problem while deploying... appears when certain conditions apply. These are some examples.
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 opens a new browser window with the Deployment > Agents > Agent Logs screen shown and the contents of the MongoDB Agent log displayed by default. Click the View menu to select a different agent log.
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 (
mongodymongos) 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.
Remove Problematic MongoDB Hosts
You can use the console or the API to remove stale, broken, or problematic hosts from automation. This may include the circumstance when the MongoDB Agent can't be reached.
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.
To remove a problematic host using the API:
Edite el archivo de JSON de configuración de la automatización.
Eliminar el nodo obsoleto de los procesos y conjuntos de réplicas.
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 versión 11.12.0.7384, asegúrese de que todos los certificados TLS utilizados en su implementación de MongoDB contengan un SAN. [1]
| [1] | MongoDB wrote the MongoDB Agent the Go language. Go 1.17 removed the ability to use X.509 CommonName field as a hostname when no SAN exists.When clients validate TLS certificates, the client checks the hostname or hostnames to which the certs apply from the values in the cert's SAN or Subject Distinguished Name (DN) fields. When creating TLS certificates, some people would use the Subject Common Name (CN) field to store the hostname. CNs have limitations that make them a poor choice to store hostnames. These limits include a 64-character maximum length and no support for Name Constraints. RFC 2818 deprecated using CN to store hostnames in May 2000. This RFC required clients to fall back to the CN if the certificate had no values in the SAN field. RFC 6125 removed the requirement in 2011.Go 1.15 disables adherence to RFC 2818 and uses the RFC 6125 practice of making CN optional. In practice, this change requires you to either add SAN values or enable the use of CNs.Go 1.17 removes the workaround to use the CN if no SAN exists.With the current version of the MongoDB Agent, you must use SAN.To learn more, see Fraser Tweedale's blog post on this topic |
Almacenar archivos de configuración en la memoria para clústeres existentes
Si utiliza Ops Manager versión 4.2 o versiones 4.4.0 - 4.4.6, es posible que encuentre 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.confarchivo tenga la directiva de__restexpansió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.