La aplicación Ops Manager ofrece 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 set de réplicas para alojar la Base de datos de la aplicación Ops Manager.
Considerations
Balanceador de carga
Los componentes de la aplicación Ops Manager son independientes entre solicitudes. Cualquier servidor de la aplicación de Ops Manager puede gestionar solicitudes, siempre y cuando todos los servidores lean desde la misma base de datos de la aplicación de Ops Manager. Si una aplicación de Ops Manager se vuelve inaccesible, otra procesa las solicitudes.
Para aprovechar esto y lograr una alta disponibilidad, configure un balanceador de carga de su elección para repartir la carga entre el conjunto de hosts de la aplicación del Gestor de Operaciones. Para hacer esto en Ops Manager, realiza las siguientes acciones:
Establezca el
URL to Access Ops Managerpropiedad al balanceador de carga URL.Establece la
Load Balancer Remote IP Headerpropiedad aX-Forwarded-For, que es el campo de encabezado de HTTP que el balanceador de carga utiliza para identificar la dirección IP del cliente de origen.Nota
Si estás usando un balanceador de carga de Capa-4 que no admite
X-Forwarded-Forde forma por defecto, habilitaX-Forwarded-Foro utiliza Proxy Protocol.
La aplicación Ops Manager utiliza la dirección IP del cliente para realizar auditorías, guardar registros y establecer una lista de acceso para la API.
Después de configurar e iniciar el balanceador de carga, no debes iniciar sesión en la Aplicación Ops Manager desde las URLindividuales del host.
Nota
Para prohibir el acceso a cada servidor de la aplicación Ops Manager, configura tus reglas de firewall en consecuencia.
Ejemplo
Si tienes dos hosts de Ops Manager que sirven las siguientes URL:
ops1.example.comops2.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 ese balanceador de carga, no debes iniciar sesión en ops1.example.com. Iniciar sesión en opsmanager.example.com en su lugar.
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.
Los snapshots de sistema de archivos requieren un sistema de archivos compartido
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.
Fichero de Diagnóstico
Para dar tiempo a que se genere el fichero de diagnóstico de Ops Manager, establezca la HTTP idle timeout parámetro para el balanceador de carga a 180 segundos.
Soporte de la capa de red del dispositivo
Cualquier appliance de balanceo de carga debe admitir Capa 7 (la capa de aplicación) del modelo OSI.
Conjunto de réplicas para la base de datos de la aplicación Ops Manager
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.
Puedes respaldar el set de réplicas utilizando snapshots del sistema de archivos. Los snapshots del sistema de archivos utilizan herramientas a nivel de sistema para crear copias del dispositivo que contiene los archivos de datos del set de réplicas.
Para implementar el set de réplicas que aloja la base de datos de la aplicación Ops Manager, consulta instancia de respaldo de MongoDB.
El archivo gen.key
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 del Ops Manager. Ops Manager creará un archivo
gen.keysi no existe ninguno. - Para crear el archivo manualmente:
Genere un archivo binario de 24 bytes.
Ejemplo
Lo siguiente crea el archivo
gen.keyutilizandoopenssl:openssl rand 24 > /<keyPath>/gen.key Proteja el archivo
gen.keycomo 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 se tenga el archivo gen.key (ya sea creado automáticamente o manualmente), antes de iniciar los demás servidores de Ops Manager, se debe copiar el archivo al directorio correspondiente en el servidor actual y al directorio correspondiente en los demás servidores de Ops Manager:
/etc/mongodb-mms/para instalaciones RPM o Ubuntu${HOME}/.mongodb-mms/para instalaciones de fichero de archivo (.tar)
Importante
Cualquier recurso de almacenamiento compartido que almacene el archivo
gen.keydebe 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.keyinstalado 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.keypara su instancia de Ops Manager en el primer servidor de Ops Manager, haga una copia de seguridad del archivogen.keyen una ubicación segura.
Modo de actualización
Si tienes una instalación de Ops Manager con más de un host de Ops Manager apuntando a la misma Base de Datos de Aplicación, puedes actualizar Ops Manager a una versión más reciente con solo un breve tiempo de inactividad en la supervisión. Después de completar la actualización de un host Ops Manager en una implementación altamente disponible de Ops Manager, dicha implementación entra en un estado conocido como Modo de actualización. En este estado, Ops Manager está disponible durante una actualización. Los beneficios de este modo son que durante todo el proceso de actualización:
Las alertas y la supervisión funcionan
Las instancias de Ops Manager permanecen activas
La aplicación Ops Manager puede ser accedida en modo de solo lectura
Las Ops Manager APIs que guardan o borran datos están deshabilitadas
La instancia de Ops Manager permanece en Modo de actualización hasta que todos los hosts de Ops Manager hayan sido actualizados y reiniciados. No debe actualizar más de un host de Ops Manager a la vez.
Rendimiento en implementaciones multiregión
La distribución geográfica de la base de datos de la aplicación y las instancias de Ops Manager podría afectar el rendimiento de la Aplicación de Ops Manager.
Rendimiento de la Base de Datos de la Aplicación Multiregión
Si tienes planeado replicar la Base de Datos de la Aplicación en varias regiones, ten en cuenta que muchas de las operaciones de carga de trabajo de escritura de Ops Manager utiliza w:2 nivel de confirmación de escritura (write concern), que requieren el reconocimiento del miembro primario y de un miembro secundario del conjunto de réplicas para cada operación de escritura.
Por lo tanto, tener un nodo de réplica secundaria de la base de datos de la aplicación en la misma región que el miembro principal puede conducir a un mejor rendimiento de lectura y escritura.
Por ejemplo, implementar tres sets de réplicas de base de datos de la aplicación en tres regiones de forma 1-1-1 podría resultar en un peor rendimiento en comparación con implementar tres sets de réplicas de base de datos de la aplicación en dos regiones de forma 2-1, donde una región alberga dos sets de réplicas de base de datos de la aplicación y otra región alberga el tercer set de réplicas.
Desempeño de la interfaz de usuario de Ops Manager
La Interfaz de Usuario de Ops Manager es más eficiente si te conectas a la instancia de la aplicación de Ops Manager implementada en la misma región que el miembro principal del set de réplicas de la base de datos de la aplicación.
En otras palabras, puede lograr una mejor experiencia de usuario conectándose a la instancia de la aplicación Ops Manager alojada en la misma región que el miembro principal de la base de datos de la aplicación del set de réplicas, en lugar de conectarse a una instancia más cercana de la aplicación Ops Manager donde la instancia misma debe conectarse a un miembro principal del set de réplicas de la base de datos de la aplicación alojado en una región diferente y distante con una alta latencia.
Requisitos previos
Implemente el set de réplicas que presta servicio a la Base de datos de aplicaciones de Ops Manager. Para implementar un set de réplicas, consulta Implementar un set de réplicas en el manual de MongoDB.
Procedimiento
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 múltiples Ops Manager aplicaciones con balanceo de carga:
Configure un equilibrador de carga con el grupo de hosts de aplicaciones de Ops Manager.
Configura el balanceador de carga para realizar una verificación de estado en cada endpoint API de salud 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 |
El balanceador de carga no debe devolver contenido en caché.
Configura Ops Manager para usar el balanceador de carga.
En Ops Manager, haz clic en Admin, luego en la pestaña General y luego en Ops Manager Config.
Establece la propiedad
URL to Access Ops Managerpara que apunte a la URL del balanceador de carga.Establece la propiedad
Load Balancer Remote IP Headeral nombre del HTTP campo de encabezado que el balanceador de carga utiliza para identificar la dirección IP del cliente.Una vez que
Load Balancer Remote IP Headerestá configurado, Ops Manager habilita los siguientes encabezados HTTP:HTTP HeaderRedirecciona a Ops ManagerHost original que el cliente solicitó en el encabezado de solicitud Host HTTP.
Protocolo utilizado para realizar la solicitud HTTP.
Nombre de host del servidor proxy.
Estado HTTPS de una solicitud.
Actualice cada host de la aplicación Ops Manager con la información de los hosts de replicación.
En cada host, edita el archivo conf-mms.properties para establecer la propiedad mongo.mongoUri en la cadena de conexión de la base de datos de la aplicación Ops Manager. Debe especificar al menos hosts 3 mongo.mongoUri en la cadena de conexión.
mongo.mongoUri=mongodb://<mms0.example.net>:<27017>,<mms1.example.net>:<27017>,<mms2.example.net>:<27017>/?maxPoolSize=100
Cambie la URL de Ops Manager a la URL de Load Balancer en el archivo de configuración del Agente MongoDB.
Complete los siguientes pasos en cada host del MongoDB Agent.
Abre el MongoDB Agent archivo de configuración.
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 Edita la propiedad
mmsBaseUrlpara que apunte al balanceador de carga y guarda los cambios.mmsBaseUrl=<LOAD-BALANCER-URL>:<PORT> Reinicie el MongoDB Agent.
Copie el gen.key archivo en cada host de Ops Manager.
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.
Información Adicional
Para obtener información sobre cómo hacer que la copia de seguridad de Ops Manager sea de alta disponibilidad, consulte Configurar un servicio de copia de seguridad de Ops Manager altamente disponible.