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:
Configura la
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 ponerlas 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 se establecen estos parámetros utilizando el archivo de configuración, se debe cambiar mms.remoteIp.header para que contenga la URL para el balanceador de carga y mms.centralUrl para que contenga la URL para el host y puerto del Ops Manager.
Los snapshots de sistema de archivos requieren un sistema de archivos compartido
Si configuras Ops Manager para que use varios servidores de aplicaciones Ops Manager detrás de un HTTP o HTTPS balanceador de carga y usas instantáneas del sistema de archivos, compatibilidad de características entre versiones 4.2 o posteriores, las tareas de instantáneas de copia de seguridad 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 aplicación de Ops Manager podría abrir y guardar diferentes compensaciones de los mismos archivos. Asegúrate de que el sistema de archivos compartido lo permita. De lo contrario, se encontrará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.
Set de réplicas para la base de datos de la aplicación Ops Manager
Despliega un set de réplicas en lugar de un autónomo para alojar la base de datos de la aplicación Ops Manager. Los sets de réplicas disponen de failover automático si el primario se vuelve inaccesible.
Si el set de réplicas tiene nodos en varias instalaciones, asegúrate de que una sola instalación tenga suficientes votos para elegir un primario si es necesario. Elige la instalación que aloja los sistemas principales de aplicaciones. Coloca la mayoría de los nodos votantes y todos los nodos que puedan llegar a ser primarios en esta sala. De lo contrario, las particiones de red podrían impedir que el conjunto pueda formar una mayoría. Para obtener detalles sobre cómo los sets de réplicas eligen primarios, consulta Elecciones de sets 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 Protege el archivo
gen.keycomo cualquier archivo confidencial. Cambia el propietario al usuario que ejecuta Ops Manager y establece el permiso de archivo para permitir solo la lectura y escritura por parte del 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 de 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 estar configurado para alta disponibilidad para no introducir un posible punto único de falla.Cualquier servidor de Ops Manager que no tenga instalado el archivo
gen.keyno puede conectarse a las bases de datos de respaldo ni convertirse en parte de una instancia HA de Ops Manager.Una vez que hayas generado el
gen.keypara tu instancia de Ops Manager en el primer servidor de Ops Manager, haz 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 colocado delante de los servidores de la aplicación de Ops Manager no debe devolver contenido en caché. El balanceador de carga debe tener la caché desactivada.
Para configurar múltiples Ops Manager aplicaciones con balanceo de carga:
Configura un balanceador de carga con el grupo de hosts de la aplicación 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 de Ops Manager o la base de datos de la aplicación parecen poco saludables. Si este endpoint 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.
Actualiza 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
Cambio el URL de Ops Manager a la URL del balanceador de carga en el archivo de configuración del Agente de 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 archivo gen.key en cada host de Ops Manager.
El archivo gen.key se encuentra en /etc/mongodb-mms/ para instalaciones desde un gestor de paquetes y en ${HOME}/.mongodb-mms/ para instalaciones desde un fichero.
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.