Command Center

Volver al Índice de Documentación Pandora FMS

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 (merging ) para usar el nuevo sistema de centralización y poder garantizar la integridad de los datos.

Al actualizar, todos los entornos de Metaconsola ya centralizados serán forzados a pasar por la nueva sección Merging tool localizada en Centralised managament para poder estar centralizados de nuevo de forma correcta.

El Merging tool hará una fusión de los distintos elementos de las bases de datos de los nodos y la Metaconsola (de aquellos que deban gestionarse desde la Metaconsola) de la siguiente forma: Se establecerá un orden de prioridad entre los nodos registrados en la Metaconsola y la propia Metaconsola, 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 la Metaconsola pero tenga configuraciones distintas. Por ejemplo, que los 2 nodos y la Metaconsola tuvieran el grupo “Databases”. Con este orden de prioridad se tomaría para todos la configuración del elemento más prioritario, en este ejemplo el grupo de la Metaconsola.

En otro caso, si por ejemplo solo los nodos 1 y 2 contasen con una política llamada “Windows”, para todos los nodos y la Metaconsola la configuración para esa política sería la del nodo 1 (se saltaría la Metaconsola porque no lo tendría).

El caso de las políticas sería el más particular de todos los elementos sincronizados por cómo se configuran, ya que cada módulo, alerta, plugin (complemento),… son tratados como elementos independientes y no como parte de la configuración de la política. Es decir, en el ejemplo anterior de la política y viéndolo solo con módulos, si tenemos:

El resultado de la fusión del Merging tool sería:

Esto permite que el resultado tenga el máximo posible de configuraciones distintas para que ya podamos gestionarlas desde la Metaconsola.

Los siguientes elementos son los que se centralizan desde el nuevo Merging tool:

• Usuarios: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo usuario los que tengan el mismo ID de usuario (siguiendo las reglas de prioridad descritas anteriormente).
• Perfiles de usuario: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo perfil los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Grupos de agentes: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo grupo los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).

• Colecciones de ficheros: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma colección las que tengan el mismo nombre corto (siguiendo las reglas de prioridad descritas anteriormente).
• Plantillas de alerta: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma plantilla las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Comandos de alerta: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo comando los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Acciones de alerta: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma acción las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Plugins de servidor: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo plugin los que tengan el mismo nombre y ejecución (siguiendo las reglas de prioridad descritas anteriormente).
• OS: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo OS los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Etiquetas de módulos: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma etiqueta las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Categorías de módulos: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma categoría las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Grupos de módulos: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo grupo los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Grupos de componentes: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo grupo los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Componentes de red: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo componente los que tengan el mismo nombre y OS (siguiendo las reglas de prioridad descritas anteriormente).
• Componentes locales: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo componente los que tengan el mismo nombre y OS (siguiendo las reglas de prioridad descritas anteriormente).
• Plantillas de componentes: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma plantilla las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Módulos de inventario: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo módulo los que tengan el mismo nombre y OS (siguiendo las reglas de prioridad descritas anteriormente).
• Políticas de monitorización: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. En el nodo se permitirá aplicar las políticas previamente gestionadas por la meta. Al unificar desde el Merging tool se considerarán la misma política las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Módulos de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo módulo los que tengan el mismo nombre dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Módulos de inventario de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo módulo los que tengan el mismo nombre y OS dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Plugins de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo plugin los que tengan la misma ejecución dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Colecciones de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma colección las que tengan el mismo nombre corto dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Alertas y alertas externas de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma alerta las que tengan la misma plantilla sobre el mismo nombre de módulo dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Acciones sobre alertas y alertas externas de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma acción las que tengan el mismo nombre sobre la misma plantilla sobre el mismo nombre de módulo dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
• Agentes dentro de las políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán agentes dentro de una misma política los que se encuentren dentro de políticas con el mismo nombre. Se descartarán los registros de agentes dentro de políticas de la Metaconsola y solo se tendrán en cuenta los registros de los nodos (que es donde se hace la aplicación efectiva).
• Agentes: Se permite la gestión de agentes en nodo, excepto su eliminación que debe hacerse desde la Metaconsola.

Las secciones donde se gestionan estos elementos de forma centralizada sólo pueden gestionarse desde la Metaconsola. 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 la Metaconsola correspondiente para la configuración de estos elementos.

Las siguientes tablas se sincronizan entre Metaconsola y nodos dentro del Merging tool (véase también “Tablas principales de la base de datos”):

• La Metaconsola debe poder conectarse a todas las bases de datos y a todas las APIs de los nodos. Hay que asegurarse de que la configuración de Consoles setup de la Metaconsola sea la correcta y que los indicadores estén en verde.

• Las consolas de los nodos deben poder conectarse a la base de datos de la Metaconsola. Normalmente esto no será un problema, a no ser que se tengan las consolas en equipos distintos a los servidores de Pandora. Hay que asegurarse de que los parámetros de la configuración de ►Setup → Enterprise para la Metaconsola en los nodos sean los correctos.

• Los servidores de todos los nodos deben poder conectarse al API de la Metaconsola. Se recomienda configurar la URL pública en la Metaconsola.

• Los servidores de todos los nodos deben tener su configuración del API correcta en 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

• Cada nodo debe poder conectarse a su propia base de datos de histórico.

• Todos los nodos y la Metaconsola se deben encontrar en la misma versión.
• Todos los nodos y la Metaconsola se deben encontrar en el mismo MR.

• Todos los nodos y la Metaconsola deben tener configurado el mismo tamaño máximo de colección en el Setup.

• Para evitar errores, todos los nodos y la Metaconsola deben tener configurado el parámetro 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.
• Todos los nodos deben tener un valor para el parámetro post_max_size de php.ini que sea mayor o igual al valor configurado para el mismo parámetro en la Metaconsola. 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 la Metaconsola, al de upload_max_filesize.
• Todos los nodos deben tener un valor para el parámetro upload_max_filesize de php.ini que sea mayor o igual al valor configurado para el mismo parámetro en la Metaconsola. Este valor debe ser al menos tan grande como el tamaño de la colección de ficheros más pesada que se tenga.
• Todos los nodos y la Metaconsola deben contar con espacio suficiente en el disco que aloje su directorio “attachment” para poder realizar los backups (respaldo de datos) de la base de datos y colecciones.

• Todos los nodos y la Metaconsola deben tener la fecha y hora del equipo correctamente configurada (se recomienda el uso de servidores NTP).

Auque no son requisitos para el proceso de unificación de las bases de datos, se recomienda encarecidamente realizar también las siguientes acciones:

• Detener los servidores de todos los nodos y la Metaconsola mientras dure el proceso. Como se van a cambiar elementos fundamentales como grupos, sus IDs se pueden modificar, y no es recomendado tener el proceso del servidor incluyendo nuevas referencias al entorno mientras este dure. No obstante, el servidor en ejecución no debería ser un problema en la mayoría de los casos.
• Detener el proceso de pandora_db del cron temporalmente mientras dure el proceso, por los mismos motivos que el servidor.

El proceso de fusión tiene 2 fases diferenciadas, una primera fase para sincronizar los distintos elementos gestionables desde la Metaconsola 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 la Metaconsola. Se trata del proceso de fusión como tal y se subdivide en otras 2 fases, cada una con su barra de progreso:

• Initialize: Comprueba todos los requisitos anteriores, genera los backups correspondientes (si se cumplen los requisitos) por si alguna parte del proceso falla, y genera en memoria el resultado de la fusión de las bases de datos. Si este proceso falla por algún motivo las bases de datos aún no se habrán modificado, por lo que no hará falta restaurar backups. Los backups se almacenan en cada nodo/Metaconsola dentro de su directorio “attachment” en attachment/merge_backups.
• Apply: Si la fase de inicialización anterior ha tenido éxito, se empezará a aplicar la fusión en todos los nodos y la Metaconsola. Este proceso es secuencial en orden de prioridad, de modo que cuando termine con uno empezará con el siguiente.

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

• Sincronización cancelada:

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.

• Base de datos principal: Como los eventos son un gran volumen de información que también se ve afectado, este proceso de actualización se realiza en paralelo con el funcionamiento normal del entorno ya fusionado. En este punto el servidor y 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.
• Base de datos de histórico: Sería la continuación del punto anterior, actualizando los eventos en la base de datos de histórico bajo las mismas características ya indicadas.

Ya terminada la fase 1, el entorno se considerará centralizado, y a partir de ahí podremos gestionar todo desde la Metaconsola. 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 la Metaconsola.

Esto funciona de la siguiente forma: cuando en la Metaconsola 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 la Metaconsola 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 la Metaconsola 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.

Si en un entorno ya centralizado agregamos un nuevo nodo, editamos alguno o rehabilitamos uno ya existente que se hubiera quedado fuera de la fusión, será necesario pasar de nuevo por el Merging tool.

Se mostrará un mensaje avisando al administrador de que haga esta tarea. Mientras no se haga el nodo permanecerá bloqueado e inaccesible, en estado “Pending to merge”. No se le asignarán los cambios realizados ni se tendrá acceso a la consola hasta que no pase el proceso de merge.

Volver al Índice de Documentación Pandora FMS