A partir de la versión 756 de Pandora FMS se ha rediseñado desde cero el sistema de sincronización para entornos con modo centralizado, haciéndolo más rápido y eficiente, ya que los cambios se replicarán a los nodos de forma automática sin necesidad de la sincronización manual que se hacía hasta ahora.
Este cambio deja en desuso el sistema anterior por lo que en entornos en los que estuviera activo, se deberá pasar por el sistema automático de fusionado para usar el nuevo sistema de centralización y poder garantizar la integridad de los datos.
Al actualizar, todos los entornos de Command Center ya centralizados serán forzados a pasar por la nueva sección Merging tool localizada en Centralised managment para poder estar centralizados de nuevo de forma correcta.
Solo se tienen en cuenta para el proceso de fusión los nodos configurados en el Command Center que no estén deshabilitados.
El Merging tool hará una fusión de los distintos elementos de las bases de datos de los nodos y el Command Center (de aquellos que deban gestionarse desde el Command Center) de la siguiente forma: Se establecerá un orden de prioridad entre los nodos registrados en el Command Center ubicando en la parte superior de la lista los elementos más prioritarios y en la inferior los menos.
Por ejemplo:
Esta lista de prioridad sirve para casos en los que un mismo elemento exista en los distintos nodos o el Command Center pero tenga configuraciones distintas.
En el caso de las políticas de monitorización, los módulos, alertas y demás elementos de la política se consideran elementos aparte e independientes a la política y por lo tanto se fusionarán también.
Ejemplo solamente con módulos:
Los siguientes elementos son los que se centralizan desde el nuevo Merging tool:
En resumen de todo lo anterior:
Asegúrese de ajustar el parámetro autocreate_group
de los ficheros de configuración de los servidores pandora_server.conf
por un ID de grupo válido tras unificar desde el Merging tool.
Los siguientes elementos se centralizan en Command Center, siguiendo las reglas de prioridad descritas anteriormente, por medio de Merging tool:
Elemento | ID | Perfil | Nombre | Grupo | Eje.1) | OS |
Usuarios | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Perfiles de usuario | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Grupos de agentes | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Colecciones de ficheros | ❌ | ❌ | ✅ 2) | ❌ | ❌ | ❌ |
Plantillas de alerta | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Comandos de alerta | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Acciones de alerta | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Plugins de servidor | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ |
OS | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Etiquetas de módulos | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Categorías de módulos | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Grupos de módulos | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Grupos de componentes | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Componentes de red | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
Componentes locales | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
Plantillas de componentes | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Módulos de inventario | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
Políticas de monitorización | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Módulos de políticas | ❌ | ❌ | ✅ 3) | ❌ | ❌ | ❌ |
Módulos de inventario de políticas | ❌ | ❌ | ✅ 4) | ❌ | ❌ | ✅ |
Plugins de políticas | ❌ | ❌ | ✅ 5) | ❌ | ✅ 6) | ❌ |
Colecciones de políticas | ❌ | ❌ | ✅ 7) | ❌ | ❌ | ❌ |
Alertas y alertas externas de políticas | ❌ | ❌ | ✅ 8) | ❌ | ❌ | ❌ |
Acciones sobre alertas y alertas externas de políticas | ❌ | ❌ | ✅ 9) | ❌ | ❌ | ❌ |
Agentes dentro de las políticas | ❌ | ❌ | ✅ 10) | ❌ | ❌ | ❌ |
Agentes 11) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Las secciones donde se gestionan estos elementos de forma centralizada sólo pueden gestionarse desde el Command Center. En caso de acceder a estos elementos desde los nodos, solo podremos listarlos, desapareciendo las opciones de edición y creación. También se mostrará un aviso que indicará que el entorno se encuentra en modo centralizado, con un enlace que llevará al administrador a la sección de el Command Center correspondiente para la configuración de estos elementos.
Las siguientes tablas se sincronizan entre Command Center y nodos dentro del Merging tool:
pandora_server.conf
o su configuración de URL pública en el Setup de la consola. Si no se tiene configurado, los servidores deberán alojarse en las mismas máquinas en las que se encuentren sus consolas.console_api_url http://localhost/pandora_console/include/api.php console_api_pass pandora
memory_limit
de php.ini
a -1
, es decir, sin límite, pero solo para el proceso de fusión de las bases de datos. Tras terminarlo se recomienda volver a ajustarlo al valor anterior. Esto es así ya que se utiliza bastante memoria para hacer la fusión de los nodos, y en entornos muy grandes (con muchos elementos distintos) se puede usar bastante memoria, y de esta forma nos aseguramos de que el sistema pueda usar toda la memoria disponible. Si esto no se cumple y se alcanza el límite de memoria especificado, el Merging tool fallará por un error inesperado y en los logs de la consola y/o de apache se verá la línea que indique el exceso de memoria alcanzado.post_max_size
de php.ini
que sea mayor o igual al valor configurado para el mismo parámetro en la Command Center. Este valor debe ser al menos tan grande como el tamaño de la colección de ficheros más pesada que se tenga. Además se debe tener en cuenta que este parámetro debe tener un valor mayor o igual, tanto en los nodos como en el Command Center, al de upload_max_filesize
.upload_max_filesize
de php.ini
que sea mayor o igual al valor configurado para el mismo parámetro en la Command Center. Este valor debe ser al menos tan grande como el tamaño de la colección de ficheros más pesada que se tenga.Si no se cumplen todos esos requisitos, no se realizará la fusión de nodos y se arrojará un error. Si se consultan los errores del resultado, dará un mensaje de los requisitos aún pendientes.
Es importante una vez realizada la unificación de bases de datos, que se vuelva a poner el valor correspondiente el parámetro memory_limit
del fichero de configuración php.ini
. Recordar que para que el cambio tenga efecto se debe reiniciar el servicio de apache httpd
.
Aunque no son requisitos para el proceso de unificación de las bases de datos, se recomienda encarecidamente realizar también las siguientes acciones:
pandora_db
del cron temporalmente mientras dure el proceso, por los mismos motivos que el servidor.
Cuando se inicia el proceso de fusión tanto los nodos como el Command Center entran en un modo de mantenimiento para los usuarios estándar (no para los administradores). El propósito de esto es el mismo que la recomendación de detener los servidores y el pandora_db
, evitar que un usuario modifique elementos durante el proceso y eso provoque errores o incongruencias.
El proceso de fusión tiene 2 fases diferenciadas, una primera fase para sincronizar los distintos elementos gestionables desde el Command Center y una segunda fase para actualizar las referencias que haya en los eventos a esos elementos centralizados. Este proceso se hace de esta forma para permitir que la consola sea accesible de nuevo lo antes posible, dado que la actualización de los eventos es la parte del proceso que más tiempo puede tomar al tratarse por lo general del mayor volumen de información. Ambas fases se encuentran a su vez divididas en otras 2 subfases diferenciadas en 2 barras de progreso.
En esta fase se sincronizan los elementos encontrados en las bases de datos de todos los nodos que sean gestionables desde el Command Center. Se trata del proceso de fusión como tal y se subdivide en otras 2 fases, cada una con su barra de progreso:
attachment/merge_backups
.Si se producen errores durante este proceso (por ejemplo, perdida de conexión con alguna base de datos), el propio proceso tratará de restaurar los backups generados (se verá una tercera barra de progreso roja que marcará el progreso en la restauración).
Si el motivo del fallo impidiese que se recuperasen los backups, la recuperación se deberá hacer manualmente.
En ocasiones se pueden producir errores inesperados, por ejemplo la perdida de conexión momentánea entre el Command Center y la base de datos de un nodo o la imposibilidad de crear un backup por no tener espacio suficiente en el disco, por lo que es posible que el mensaje de error mostrado sea genérico. Si es el caso y lo necesita, póngase en contacto con el equipo de soporte de Pandora FMS para recibir asistencia.
En esta fase se actualizarán las referencias existentes en los eventos a los distintos elementos que se hayan sincronizado (por ejemplo a grupos). La fase se subdivide en la actualización de los eventos de la base de datos principal y la actualización de los eventos de la base de datos de histórico, y solo afectará a los eventos que existiesen antes de lanzar el proceso de fusión. Los nuevos eventos que se generen habiendo ya centralizado el entorno tendrán todas las referencias correctamente y no será necesario actualizarlos.
pandora_db
se pueden volver a iniciar normalmente, y los usuarios estándar son capaces de volver a acceder a la consola. Eso sí, verán en la vista de eventos la barra de progreso de actualización de todos los eventos, por lo que para esa parte aún podrán tener incongruencias (respecto a filtros por ejemplo) solo para los eventos que hubiese antes de la fusión. Los nuevos eventos se generarían de forma normal. Esta fase y proceso es lanzado por cada uno de los nodos, mediante una tarea específica del cron de la consola. Por el volumen de información puede ser una tarea pesada y que tome bastante tiempo, por lo que en la medida de lo posible cuanta menos carga tenga el entorno en ese momento mejor.
Ya terminada la fase 1, el entorno se considerará centralizado, y a partir de ahí podremos gestionar todo desde el Command Center. La sincronización de elementos también se ha cambiado, siendo ahora el pandora_ha
de cada nodo el que se encarga de sincronizar su base de datos con la de el Command Center.
Esto funciona de la siguiente forma: cuando en el Command Center hacemos algún cambio (por ejemplo, crear un usuario) esto encola para los nodos las consultas necesarias a la base de datos (INSERTS
, UPDATES
, etc.) las cuales el pandora_ha
lee de forma ordenada de la base de datos de el Command Center y va ejecutando cada server_threshold. Esto asegura que si un servidor está detenido durante un tiempo, cuando se inicie de nuevo pueda ponerse al día de forma correcta.
Esta lista de consultas pendientes se podrá ver desde el Command Center en la sección de “Consoles setup”. Si por algún motivo alguna consulta falla, el nodo no seguirá con las demás, podremos ver un error en “Consoles setup” y será necesario tratarlo manualmente por un administrador. En la mayoría de los casos se debería de poder solucionar lanzando de nuevo el proceso de fusión en el Merging tool.
Para agregar un nuevo nodo a un entorno centralizado se debe ir en el Command Center a Setup → Metasetup → Consoles setup y pulsar en el botón New node. Se deberán rellenar todos los campos para lograr la conexión y al momento de guardar dependerá de si es un nodo completamente nuevo, sin dato alguno, se agregará con el botón Register empty node, de lo contrario se utilizará el botón Register node with data to merge.
Presione Ok si está seguro y el nodo nuevo será centralizado.