Docs Menu
Docs Home
/ /

Automatización

Cloud Manager Automation le permite implementar, configurar y administrar implementaciones de MongoDB con la interfaz de usuario de Cloud Manager. Cloud Manager Automation se basa en un agente de MongoDB, que debe estar instalado en cada servidor de la implementación. Los agentes de MongoDB consultan periódicamente el servicio Cloud Manager para determinar el objetivo actual e informan continuamente de su estado a Cloud Manager.

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

  • 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.

Todos los hosts deben permitir la comunicación entre los puertos de MongoDB. El valor predeterminado es 27017, pero puedes 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 obtener más información sobre el acceso a los puertos y direcciones IP, consulte Descripción general de seguridad.

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 miembros del clúster puedan comunicarse entre sí:

  1. 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.

  2. 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.

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.

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.

  • 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.

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.

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

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:

  1. Haga clic en View Diagnostics.

    El modal View Diagnostics muestra cualquier error que pueda haber ocurrido durante la implementación.

  2. 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.

  3. 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.

  4. 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.

Si el módulo de automatización del agente de MongoDB no puede comunicarse con Cloud Manager API endpoint ni con los procesos del servidor MongoDB, Cloud 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:

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:

  1. El agente está activo y funcionando en cada host.

  2. El agente y el punto final de la API de Cloud Manager pueden comunicarse.

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

  1. Haga clic en el enlace Allow Editing & Override Current Configuration en el banner de advertencia.

  2. Remover todos los procesos (mongod y mongos) que se estén ejecutando en los hosts que sirven a los agentes MongoDB no necesarios.

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.

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:

1
  1. 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.

  2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

  3. En la barra lateral, haz clic en Processes en la sección Database.

Se muestra la página Procesos.

2
  1. Encuentra tu host problemático.

  2. Haga clic y Remove Server luego.

    Cloud Manager muestra el modal Are you sure you want to remove this server>.

  3. 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 elimina todos los datos de monitorización de este host al hacer clic en Remove. Cloud Manager no ofrece confirmación ni cancelación para esta acción.

    Si no desea eliminar el servidor, haga clic en Cancel.

  4. Haga clic en Review & Deploy para revisar sus cambios.

    Cloud Manager muestra los cambios propuestos.

    • Si estás satisfecho, haz clic en Confirm & Deploy.

      Cloud 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:

  1. Obtenga la configuración de automatización actual.

  2. Edite el archivo de JSON de configuración de la automatización.

  3. Eliminar el nodo obsoleto de los procesos y conjuntos de réplicas.

  4. Actualice el archivo de configuración de automatización.

  5. Espere unos minutos.

  6. En MongoDB Cloud Manager, ve a la página Agents de tu proyecto.

    1. 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.

    2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

    3. En la barra lateral, haz clic en Agents en la sección Database.

    Se muestra la página Agentes.

  7. Confirme que el host ya no aparece en la lista de agentes.

Advertencia

El Agente MongoDB de la versión 11.11.0.7349a1 requiere que los certificados TLS incluyan un valor en el campo Nombre Alternativo del 1111 Sujeto. Antes de actualizar al Agente MongoDB...07355 o posterior, 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.

Si usa la versión de Cloud Manager 4.2 o las versiones 4.4.0 -,4.4.6 puede encontrar errores enableLocalConfigurationServer al true configurar a 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:

  1. Al final del archivo de configuración del agente MongoDB, agregue:

    enableLocalConfigurationServer=true
  2. Apague cada proceso gestionado por MongoDB Agent.

  3. Reinicie el agente MongoDB ejecutando el siguiente comando:

    service mongodb-mms-automation-agent restart
  4. Reinicie los procesos de MongoDB que cerró.

  5. 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