Docs Menu
Docs Home
/ /
Opciones avanzadas

Configurar una aplicación Ops Manager de alta disponibilidad

La aplicación Ops Manager proporciona alta disponibilidad mediante el uso de múltiples servidores de la aplicación Ops Manager detrás de un balanceador de carga y mediante el uso de un conjunto de réplicas para alojar la aplicación. Base de datos de la aplicación Ops Manager.

Los componentes de la aplicación Ops Manager no tienen estado entre solicitudes. Cualquier servidor de la aplicación Ops Manager puede gestionar solicitudes siempre que todos los servidores lean de la misma base de datos. Si una aplicación Ops Manager deja de estar disponible, otra procesa las solicitudes.

Para aprovechar esta alta disponibilidad, configure un balanceador de carga de su elección para equilibrar el grupo de hosts de la aplicación Ops Manager. Para ello, en Ops Manager, realice las siguientes acciones:

La aplicación Ops Manager utiliza la dirección IP del cliente para auditar, registrar y configurar una lista de acceso para la API.

Una vez configurado e iniciado el balanceador de carga, no debe iniciar sesión en la aplicación Ops Manager desde sus URL de host individuales.

Nota

Para prohibir el acceso a cada servidor de aplicaciones de Ops Manager, configure sus reglas de firewall según corresponda.

Ejemplo

Si tiene dos hosts de Ops Manager que brindan servicio a las siguientes URL:

  • ops1.example.com

  • ops2.example.com

y colóquelos detrás de un balanceador de carga en la siguiente URL:

  • opsmanager.example.com

Después de configurar e iniciar el balanceador de carga, no debe iniciar sesión en ops1.example.com. Inicie sesión en opsmanager.example.com.

Nota

Si configura estos parámetros mediante el archivo de configuración, cambie mms.remoteIp.header a la URL del balanceador de carga y mms.centralUrl a la URL del host y el puerto de Ops Manager.

Si configura Ops Manager para usar varios servidores de aplicaciones de Ops Manager tras un balanceador de carga HTTP o HTTPS y usa instantáneas del sistema de archivos, lastareas de instantáneas 4 de2 copia de seguridad de FCV. o posteriores se ejecutan en paralelo en uno o más servidores. Asegúrese de tener un sistema de archivos compartido montado en cada servidor de Ops Manager. El servidor de aplicaciones de Ops Manager podría abrir y escribir diferentes desplazamientos de los mismos archivos. Asegúrese de que el sistema de archivos compartido lo permita. De lo contrario, se producirán errores de acceso.

Para darle tiempo a su archivo de diagnóstico de Ops Manager para generarse, configure HTTP idle timeout parámetro para el balanceador de carga a 180 segundos.

Cualquier dispositivo de equilibrio de carga debe ser compatible con la capa (la 7 capa de aplicación) del modelo OSI.

Implemente un conjunto de réplicas en lugar de uno independiente para alojar la base de datos de la aplicación Ops Manager. Los conjuntos de réplicas tienen conmutación por error automática si el conjunto principal deja de estar disponible.

Si el conjunto de réplicas tiene miembros en varias instalaciones, asegúrese de que una sola instalación tenga suficientes votos para elegir un primario si es necesario. Seleccione la instalación que aloja los sistemas de aplicación principales. Coloque la mayoría de los miembros con derecho a voto y todos los miembros que puedan convertirse en primarios en esta instalación. De lo contrario, las particiones de red podrían impedir que el conjunto forme una mayoría. Para obtener más información sobre cómo los conjuntos de réplicas eligen a los primarios, consulte Elecciones de Conjuntos de Réplicas.

Puede realizar una copia de seguridad del conjunto de réplicas mediante instantáneas del sistema de archivos. Estas instantáneas utilizan herramientas a nivel de sistema para crear copias del dispositivo que contiene los archivos de datos del conjunto de réplicas.

Para implementar el conjunto de réplicas que aloja la base de datos de la aplicación Ops Manager, consulte la instancia de respaldo de MongoDB.

gen.key El archivo es un archivo binario de 24 bytes que se utiliza para encriptar y desencriptar las bases de datos de respaldo y las credenciales de usuario de Ops Manager. Un archivo idéntico gen.key debe almacenarse en cada servidor que forme parte de una implementación de Ops Manager altamente disponible.

El archivo gen.key se puede generar automáticamente o manualmente.

Para que Ops Manager genere el archivo:
Inicie un servidor de Ops Manager. Ops Manager creará un gen.key archivo si no existe ninguno.
Para crear el archivo manualmente:

Generar un archivo binario de 24bytes.

Ejemplo

Lo siguiente crea el archivo gen.key usando openssl:

openssl rand 24 > /<keyPath>/gen.key

Proteja el archivo gen.key como cualquier archivo confidencial. Cambie el propietario al usuario que ejecuta Ops Manager y configure el archivo como de lectura y escritura exclusivo para el propietario.

Una vez que tenga el gen.key archivo (creado automáticamente o manualmente), antes de iniciar los otros servidores de Ops Manager, copie el archivo al directorio apropiado en el servidor actual y al directorio apropiado en los otros servidores de Ops Manager:

  • /etc/mongodb-mms/ para instalaciones RPM o Ubuntu

  • ${HOME}/.mongodb-mms/ para instalaciones de archivos de almacenamiento (.tar)

Importante

  • Cualquier recurso de almacenamiento compartido que almacene el archivo gen.key debe configurarse para alta disponibilidad a fin de no introducir un posible punto único de falla.

  • Cualquier servidor de Ops Manager que no tenga el archivo gen.key instalado no puede conectarse a las bases de datos de respaldo y convertirse en parte de una instancia de HA Ops Manager.

  • Una vez que haya generado el gen.key para su instancia de Ops Manager en el primer servidor de Ops Manager, haga una copia de seguridad del archivo gen.key en una ubicación segura.

Si tiene una instalación de Ops Manager con más de un host de Ops Manager que apunta a la misma base de datos de aplicaciones, puede actualizar Ops Manager a una versión más reciente con solo un breve periodo de inactividad de monitorización. Tras completar la actualización de un host de Ops Manager de una implementación de Ops Manager de alta disponibilidad, dicha implementación entra en un estado conocido como modo de actualización. En este estado, Ops Manager está disponible durante una actualización. Las ventajas de este modo son que, durante el proceso de actualización:

  • Las alertas y el monitoreo funcionan

  • Las instancias de Ops Manager permanecen activas

  • Se puede acceder a la aplicación Ops Manager en modo de solo lectura

  • Las Ops Manager APIs que guardan o borran datos están deshabilitadas

Su instancia de Ops Manager permanece en modo de actualización hasta que todos los hosts de Ops Manager se hayan actualizado y reiniciado. No debe actualizar más de un host de Ops Manager a la vez.

Implemente el conjunto de réplicas que sirve a la base de datos de la aplicación Ops Manager. Para implementar un conjunto de réplicas, consulte "Implementar un conjunto de réplicas" en el manual de MongoDB.

El siguiente procedimiento asume que generaste el primer gen.key utilizando uno de los hosts de la aplicación Ops Manager. Si en cambio creas tu propio gen.key, distribúyelo a los hosts de Ops Manager antes de iniciar cualquiera de las aplicaciones de Ops Manager.

Importante

El balanceador de carga ubicado delante de los servidores de aplicaciones de Ops Manager no debe devolver contenido almacenado en caché. El balanceador de carga debe tener el almacenamiento en caché deshabilitado.

Para configurar varias aplicaciones de Ops Manager con equilibrio de carga:

1

Configure el balanceador de carga para realizar una verificación de estado en cada punto final de la API de estado de Ops Manager:

http://<OpsManagerHost>:<OpsManagerPort>/monitor/health

Ops Manager responde con uno de dos códigos HTTP:

HTTP Status Code
Estado de salud

200

El host de Ops Manager y la base de datos de la aplicación parecen estar en buen estado.

500

El host o la base de datos de la aplicación de Ops Manager parecen no estar en buen estado.

Si este punto final devuelve HTTP 500 con frecuencia, revise la sección Solución de problemas.

El balanceador de carga no debe devolver contenido almacenado en caché.

2
  1. En Ops Manager, haga clic en Admin, luego en la pestaña General y luego en Ops Manager Config.

  2. Establece la propiedad URL to Access Ops Manager para que apunte a la URL del balanceador de carga.

  3. Establezca la propiedad en Load Balancer Remote IP Header el nombre del campo de encabezado HTTP que utiliza el balanceador de carga para identificar la dirección IP del cliente.

    Una vez que se configura, Ops Load Balancer Remote IP Header Manager habilita los siguientes encabezados HTTP:

    EncabezadoHTTP
    Reenvía al gerente de operaciones

    Host original que el cliente solicitó en el encabezado de solicitud HTTP Host.

    Protocolo utilizado para realizar la solicitud HTTP.

    Nombre de host del servidor proxy.

    EstadoHTTPS de una solicitud.

3

En cada host, edite el conf-mms.properties archivo para establecer la mongo.mongoUri propiedad en la cadena de conexión de la base de datos de la aplicación Ops Manager.Debe especificar al menos 3 hosts en la cadena de mongo.mongoUri conexión.

mongo.mongoUri=mongodb://<mms0.example.net>:<27017>,<mms1.example.net>:<27017>,<mms2.example.net>:<27017>/?maxPoolSize=100
4

Complete los siguientes pasos en el host de cada agente MongoDB.

  1. Abra el archivo de configuración del agente MongoDB.

    vi /path/to/configurationFile.config

    La ubicación del archivo de configuración de Automatización depende de su plataforma:

    /path/to/install/local.config
    /etc/mongodb-mms/automation-agent.config
    /etc/mongodb-mms/automation-agent.config
    /path/to/install/local.config
  2. Edite la propiedad para que apunte al balanceador de carga y guarde los mmsBaseUrl cambios.

    mmsBaseUrl=<LOAD-BALANCER-URL>:<PORT>
  3. Reinicie el agente MongoDB.

5

Ejemplo

Si instaló la aplicación Ops Manager con un paquete rpm o deb, emita lo siguiente:

service mongodb-mms start
6

El archivo gen.key se encuentra en /etc/mongodb-mms/ para las instalaciones desde un administrador de paquetes y en ${HOME}/.mongodb-mms/ para las instalaciones desde un archivo.

Copia el archivo gen.key desde el host de la aplicación en ejecución de Ops Manager al directorio correspondiente en los otros hosts de la aplicación de Ops Manager.

7

Para obtener información sobre cómo hacer que Ops Manager Backup sea de alta disponibilidad, consulte Configurar un servicio de Ops Manager Backup de alta disponibilidad.

Volver

Permitir la supervisión de bases de datos