Cloud Manager automatización te permite implementar, configurar y gestionar implementaciones de MongoDB con la IU de Cloud Manager. La Automatización de Cloud Manager se basa en un MongoDB Agent, que debe instalarse en cada servidor de la implementación. Los agentes de MongoDB son inspeccionados periódicamente por el servicio de Cloud Manager para determinar el objetivo actual y comunicar continuamente su estado a Cloud Manager.
La automatización solo se ejecuta en arquitecturas de 64 bits
Cloud Manager ofrece solo descargas de 64 bits del MongoDB Agent.
Uso de hardware propio
Si implementa automatización manualmente, asegúrese de tener un MongoDB Agent en cada servidor.
Si implementa el agente manualmente, debe crear MongoDB
dbPathy el directorio para los binarios de MongoDB y garantizar que el usuario que ejecuta el agente sea el propietario de estos directorios.Si se instala usando el paquete
rpm, el agente se ejecuta como el usuariomongod; si se utiliza el paquetedeb, el agente se ejecuta como el usuariomongodb. Si instala usando el archivo comprimidotar.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 por defecto es 27017, pero puede configurar rangos de puertos alternativos en la interfaz de Cloud Manager.
El agente MongoDB debe poder conectarse a cloud.mongodb.com en el puerto 443 (HTTPS). Para más información sobre el acceso a puertos y direcciones IP, consulta
Descripción general de seguridad.
Problema de conectividad intra-clúster
Al realizar una actualización progresiva, el Agente de MongoDB intenta evitar interrupciones. Debe recopilar estado de otros miembros del clúster. Un problema de conectividad (entre mongods y mongoses), como la resolución de nombres de host o un firewall mal configurado, puede impedir que el Agente de MongoDB determine el estado de los procesos remotos y complete el cambio.
Para garantizar que todos los nodos del clúster puedan comunicarse entre sí:
Para un clúster sin fragmentación:
Para un clúster particionado:
Automatización frecuente de conexiones
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
Después de completar la configuración de automatización, asegúrate de que el plan de implementación satisfaga las necesidades de tu implementación. Verifique los nombres de host y los puertos antes de confirmar la implementación.
Dimensionamiento
Asegúrate de aprovisionar hosts con suficiente espacio para ejecutar MongoDB y soportar los requerimientos de tu conjunto de datos.
Asegúrese de proporcionar una cantidad suficiente de hosts para ejecutar su implementación. Cada debe ejecutarse en su propio
mongodhost.
Tiempo de espera frecuente de conexión
El agente de MongoDB puede quedarse sin conexión frecuentemente por una o más de las siguientes razones:
Tiempos de espera de conexión
Alta latencia de red
Alta carga del servidor.
Claves SSL grandes
Velocidad de CPU insuficiente
Por defecto, las conexiones se agotan después de 40 segundos. MongoDB recomienda aumentar gradualmente el valor de la configuración del dialTimeoutSeconds MongoDB Agent para prevenir tiempos de espera de conexión prematuros y frecuentes. Sin embargo, aumentar este valor también aumenta el tiempo requerido para implementar futuros cambios de configuración. Experimenta con incrementos pequeños e incrementales hasta determinar el valor óptimo para tu implementación.
Para aprender más, consulta dialTimeoutSeconds en Configuración de Conexión de MongoDB Agent.
Implementaciones
Un banner que muestra We have detected a potential problem while deploying... aparece cuando se aplican ciertas condiciones. Estos son algunos ejemplos.
Cambio de implementación sin poder completarse / No procede
Si ha añadido o reiniciado una implementación y la implementación permanece en el estado In Progress durante varios minutos, se mostrará el banner.
En este punto, tienes cuatro opciones:
Haga clic en View Diagnostics.
El modal View Diagnostics muestra los errores que pudieron haber ocurrido durante la implementación.
Haga clic en View Status.
El modal Automation Status muestra los procesos de implementación, la última vez que informaron de su estado de implementación, qué tarea intentan completar y el estado de implementación. Puedes filtrar los resultados de las siguientes maneras:
Escribe un nombre de host en la barra de búsqueda Filter processes.
Selecciona uno o más tipos de procesos del menú desplegable Process Type.
Selecciona uno o varios estados de automatización desde el menú desplegable Automation State.
Para aprender más sobre el estado de cualquiera de los procesos individuales, puedes 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 MongoDB Agent.
View Agent Logs abre una nueva ventana del navegador con la pantalla Deployment > Agents > Agent Logs mostrada y el contenido del registro del agente de MongoDB mostrado por defecto. Haz clic en el menú View para seleccionar un registro distinto 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 cierra la implementación y aún no puede encontrar una solución, elimine la implementación de Cloud Manager.
Los agentes de MongoDB están inactivos o no se comunican
Si el módulo de automatización del agente MongoDB no puede comunicarse con API endpoint de Cloud Manager o los procesos del servidor MongoDB, Cloud Manager muestra una advertencia en el banner del Proyecto. Puedes resolver esto de dos formas, dependiendo de si esperas o no que los agentes de MongoDB estén comunicando:
Los agentes de MongoDB necesitan comunicarse
Si los agentes de MongoDB deben comunicarse con el host de Cloud Manager o las instancias de MongoDB, confirme lo siguiente para cada agente de MongoDB:
El agente está en funcionamiento en cada host.
El agente y el punto final de la API de Cloud Manager pueden comunicarse.
Los agentes de MongoDB no necesitan comunicarse
Si el módulo de automatización de los agentes de MongoDB debe comunicarse con el API endpoint de Cloud Manager o con los procesos del servidor de MongoDB, confirme lo siguiente para cada implementación automatizada del servidor de MongoDB:
Haz clic en el enlace Allow Editing & Override Current Configuration en la barra de advertencia.
Remover todos los procesos (
mongodymongos) que se estén ejecutando en los hosts que sirven a los agentes MongoDB no necesarios.
Permisos de MongoDB Agent
Un problema de permisos puede impedir que la automatización complete un cambio. Si View Status o View Diagnostics informan de un error relacionado con permisos (como open /data/db/mongod.lock:
permission denied), asegúrate de que el usuario del MongoDB Agent sea el propietario y tenga permisos de lectura y guardar en los archivos dbpath y logpath.
Remover hosts problemáticos de MongoDB
Puedes utilizar la consola o la API para eliminar hosts obsoletos, rotos o problemáticos de la automatización. Esto puede incluir la circunstancia en la que el MongoDB Agent no puede ser alcanzado.
Para remover un host problemático usando la consola:
En MongoDB Cloud Manager, ir a la página Processes del proyecto.
Si aún no se muestra, seleccione la organización que contiene su proyecto deseado en el menú Organizations de la barra de navegación.
Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Processes en la sección Database.
Se muestra la página Procesos.
Eliminar el host.
Encuentra tu host problemático.
Haz clic en , luego en Remove Server.
Cloud 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
Cloud Manager remueve todos los datos de supervisión de este host cuando haces clic en Remove. El Cloud Manager no proporciona ninguna confirmación ni cancelación para esta acción.
Si no desea eliminar el servidor, haga clic en Cancel.
Haga clic en Review & Deploy para revisar sus cambios.
Cloud Manager muestra tus cambios propuestos.
Si estás satisfecho, haz clic en Confirm & Deploy.
Cloud Manager elimina todos los procesos y agentes en este momento.
Si deseas realizar más cambios de configuración, haz clic en Cancel.
Para remover un host problemático utilizando la API:
Edite el archivo de JSON de configuración de la automatización.
Elimine el nodo desactualizado de procesos y sets de réplicas.
Espera unos minutos.
En MongoDB Cloud Manager, ve a la página Agents de tu proyecto.
Si aún no se muestra, seleccione la organización que contiene su proyecto deseado en el menú Organizations de la barra de navegación.
Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Agents en la sección Database.
Se muestra la página Agentes.
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 MongoDB de la versión 11.11.0.7349-1 requiere que los certificados TLS incluyan un valor en el campo Nombre Alternativo del Sujeto. Antes de actualizar a MongoDB Agent 11.11.0.7355 o posterior, asegúrese de que todos los certificados TLS utilizados en su implementación de MongoDB contengan un SAN. [1]
| [1] | MongoDB creó el MongoDB Agent en el lenguaje Go. Go 1.17 eliminó la capacidad de usar el campo X.509 CommonName como nombre de host cuando no existe SAN. Cuando los clientes validan los certificados TLS, el cliente verifica el nombre de host o los nombres de host a los que se aplican los certificados a partir de los valores en los campos SAN o Nombre Distinguido del Sujeto (DN) del certificado. Al crear certificados TLS, algunas personas utilizaban el campo Common Name (CN) de Subject para almacenar el nombre de host. Los CN tienen limitaciones que los convierten en una mala elección para almacenar nombres de host. Estos límites incluyen una longitud máxima de 64caracteres y no admiten las Restricciones de nombre. RFC 2818 desaprobado el uso de CN para almacenar nombres de host en mayo 2000. Esta RFC requiere que los clientes recurran a la CN si el certificado no tiene valores en el campo SAN. RFC 6125 eliminó el requisito en 2011.Ve a 1.15 desactiva la adhesión al RFC 2818 y utiliza el RFC 6125 la práctica de hacer que CN sea opcional. En la práctica, este cambio requiere que agregues valores SAN o habilites el uso de CNs. Ve 1.17 elimina la solución alternativa de usar el CN si no existe SAN.Con la versión actual del MongoDB Agent, debes usar SAN.Para obtener más información, consulta la entrada del blog de Fraser Tweedale sobre este tema |
Almacenar archivos de configuración en la memoria para clústeres existentes
Si utiliza Cloud 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 enableLocalConfigurationServer está configurado en true después de que se crea el clúster. Establecer este valor antes de crear el clúster no desencadena 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 detuvo.
Verifica que el archivo
automation-mongod.conftenga la directiva de expansión__rest.
Para obtener más información sobre cómo almacenar archivos de configuración en memoria, consulta Configura cómo el MongoDB Agent gestiona archivos de configuración y contraseñas.