Pandora: Documentation es: HA

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Alta disponibilidad

1.1 Introducción

Pandora FMS es una aplicación muy estable (gracias a las pruebas y mejoras introducidas en cada versión y a los cientos de fallos abiertos por los usuarios y que han sido corregidos), no obstante, en entornos críticos y/o con mucha carga, es posible que sea necesario repartir la carga en varias máquinas y tener la seguridad de que si algún componente de Pandora FMS falla, el sistema no se viene abajo.

Pandora FMS ha sido diseñado para que sea muy modular, y que cualquiera de sus módulos pueda funcionar de forma independiente. Pero también esta diseñado para trabajar en colaboración con otros componentes y ser capaz de asumir la carga de aquellos componentes que han caído.

Un diseño estándar de Pandora FMS podría ser el que se ve en la siguiente ilustración.



Ha1.png



Evidentemente, los agentes no son redundables. Si un agente cae, no tiene sentido ejecutar otro ya que la única causa de que un agente caiga es que no se puedan obtener datos porque algún modulo está fallando su ejecución —lo que no se podría subsanar con otro agente corriendo en paralelo— o porque el sistema está incomunicado o se ha colgado. La solución obvia es redundar los sistemas críticos —independientemente de que tengan corriendo agentes de Pandora FMS o no— y así redundar la monitorización de dichos sistemas.

Se puede hablar de utilizar HA en varios escenarios:

  • Balanceo y HA del Servidor de datos.
  • Balanceo y HA de los servidores de Red, WMI, plugin, web, prediction, recon, y similares
  • Balanceo y HA en la BBDD.
  • Balanceo y HA de la consola de Pandora FMS.

1.2 Alta disponibilidad del Servidor de Datos

Lo más sencillo es utilizar la propia HA implementada en los agentes (que permiten contactar con un servidor alternativo si el principal no contesta). Sin embargo, dado que el servidor de datos atiende por el puerto 41121 y es un puerto TCP estándar, es posible usar cualquier solución comercial que permita balancear o clusterizar un servicio TCP ordinario.

Para el servidor de datos de Pandora FMS necesitará montar dos máquinas con un Pandora FMS data server configurado (y diferente hostname y nombre del servidor). Habrá que configurar un servidor Tentacle en cada uno de ellos. Cada máquina tendrá una dirección IP diferente. Si vamos a utilizar un balanceador externo, éste proveerá una única dirección IP a la que los agentes se conectarán para enviar sus datos.

Si estamos usando un balanceador externo, y uno de los servidores falla, el mecanismo de HA «promueven» uno de los servidores activos disponibles y los agentes de Pandora FMS seguirán conectándose con la misma dirección que hacían antes, sin notar el cambio, pero en este caso, el balanceador de carga ya no enviará los datos al servidor que ha fallado, sino a otro servidor activo. No hay necesidad de cambiar nada en cada servidor de datos de Pandora FMS, incluso cada servidor puede mantener su propio nombre, útil para saber si se ha caído alguno en la vista de estado de servidores. Los módulos de datos de Pandora FMS pueden ser procesados por cualquier servidor sin que sea necesaria una preasignación. Está diseñado precisamente así para poder implementar HA de una forma más fácil.

En el caso de usar el mecanismo de HA de los agentes, existirá un pequeño retardo en el envio de datos, ya que a cada ejecución del agente, este intentará conectar con el servidor primario, y si no contesta, lo hará contra el secundario (si se ha configurado así). Esto se descibe a continuación como "Balanceo en los agentes Software".

Si se quieren utilizar dos servidores de datos y que ambos manejen políticas, colecciones, y configuraciones remotas, habrá que compartir por NFS los siguientes directorios para que todas las instancias del data server puedan leer y escribir sobre dichos directorios. Las consolas también deberán tener acceso a dichos directorios compartidos por NFS.

  • /var/spool/pandora/data_in/conf
  • /var/spool/pandora/data_in/collections
  • /var/spool/pandora/data_in/md5



Ha2.png



1.3 Alta disponibilidad en los agentes software

Desde los agentes software es posible realizar un balanceo de servidores de Datos ya que es posible configurar un servidor de datos master y otro de backup. En el fichero de configuración del agente pandora_agent.conf se debe configurar y descomentar la siguiente parte del archivo de configuración del agente:

# Secondary server configuration
# ==============================
# If secondary_mode is set to on_error, data files are copied to the secondary
# server only if the primary server fails. If set to always, data files are
# always copied to the secondary server
secondary_mode on_error
secondary_server_ip localhost
secondary_server_path /var/spool/pandora/data_in
secondary_server_port 41121
secondary_transfer_mode tentacle
secondary_server_pwd mypassword
secondary_server_ssl no
secondary_server_opts

Existen las siguientes opciones (para más información, consultar el capítulo de configuración de los agentes).

  • secondary_mode: Modo en el que debe estar el servidor secundario. Puede tener dos valores:
    • on_error: Envía datos al servidor secundario solo si no puede enviarlas al primario.
    • always: Siempre envía datos al servidor secundario, independientemente si puede contactar o no con el servidor principal.
  • secondary_server_ip: IP del servidor secundario.
  • secondary_server_path: Ruta donde se copian los XML en el servidor secundario, habitualmente /var/spool/pandora/data_in
  • secondary_server_port: Puerto por el que se copiaran los XML al servidor secundario, en tentacle 41121, en ssh 22 y en ftp 21.
  • secondary_transfer_mode: modo de transferencia que se usará para copiar los XML al servidor secundario, tentacle, ssh, ftp, ...
  • secondary_server_pwd: Opción de password para la transferencia por FTP
  • secondary_server_ssl: Se pondra yes o no según se quiera usar ssl para transferir los datos por tentacle.
  • secondary_server_opts: En este campo se pondrán otras opciones necesarias para la transferencia.

1.4 Alta disponibilidad en la BBDD

La BBDD es el componente más crítico de Pandora, y por ello, el tema es más complejo. Actualmente proponemos una solución software basada en DRBD que permite clusterizar MySQL via software , y Pandora FMS también puede trabajar con diferentes soluciones hardware o virtualizadas, que permiten clusterizar cualquier aplicación standard como MySQL.

Estamos trabajando para ofrecer una solución integrada en Pandora FMS que permita implementar una herramienta nativa de HA en Pandora, basada en MySQL.

Puede consultar la documentación disponible sobre DRBD y MySQL: [1]

1.5 Alta disponibilidad de los servidores de Red, WMI, plugin, web, prediction y similares

Necesita instalar múltiples servidores, de red. WMI, Plugin, Web o prediction, en varias máquinas de la red (todas con la misma visibilidad de cara hacia los sistemas que se quieran monitorizar) y que todas estén en el mismo segmento (para que los datos de latencia de la red sean coherentes).

Los servidores se pueden marcar como primarios. Esos servidores automáticamente recogerán los datos de todos los módulos asignados a un servidor que esté marcado como «caído». Los propios servidores de Pandora FMS implementan un mecanismo para detectar que uno de ellos se ha caído a través de una verificación de su última fecha de contacto (server threshold x 2). Basta que exista un sólo servidor de Pandora FMS activo para que pueda detectar la caída del resto. Si se caen todos los servidores de Pandora FMS, no existe forma de detectar o implementar HA.

La forma evidente de implementar HA y un balanceo de carga, en un sistema de dos nodos es asignar el 50% de los módulos a cada servidor y marcar ambos servidores como maestros (Master). En el caso de haber más de dos servidores maestros y un tercer servidor caído con módulos pendientes de ejecutar, el primero de los servidores maestros que ejecute el módulo se «autoasigna» el módulo del servidor caído. En caso de recuperación de uno de los servidores caídos, se vuelven a asignar automáticamente los módulos que se habían asignado al servidor primario.



Ha3.png



El balanceo de carga entere los distintos servidores se realiza en la parte de administración del agente en el menú “setup”.



Ha4.png



En el campo “server” hay un combo donde se elige el servidor que realizará los chequeos.

1.5.1 Configuración en los servidores

Un Servidor de Pandora FMS puede estar corriendo en dos modos diferentes:

  • Modo maestro.
  • Modo no maestro.

Si un servidor se cae, sus módulos serán ejecutados por el servidor maestro de modo que no se pierdan datos.

En un momento dado sólo puede haber un servidor maestro, que se elige entre los servidores que tengan la opción de configuración master en /etc/pandora/pandora_server.conf con un valor mayor que 0:

master [1..7]

Si el servidor maestro actual se cae, se elige un nuevo maestro. Si hay más de un candidato, se elige aquel que tengan un valor mas alto en master.

Template warning.png

Tenga cuidado al deshabilitar servidores. Si un servidor con módulos de red se cae y el Servidor de Red del servidor maestro está deshabilitado, esos módulos no se ejecutarán.

 


Por ejemplo, si tiene tres servidores de Pandora FMS Servers con maestro a 1, se elegirá un servidor maestro de forma aleatoria y los otros dos se ejecutarán en modo no maestro. Si el servidor maestro se cae, se elegirá un nuevo maestro de forma aleatoria.

1.6 Alta disponibilidad de la consola de Pandora FMS

Sólo hay que instalar otra consola. Cualquiera de ellas podrá usarse de forma simultánea desde diferentes ubicaciones por diferentes usuarios. Utilizando un balanceador Web delante de las consolas, se podrá acceder a las mismas sin saber realmente a cuál se está accediendo ya que el sistema de sesiones se gestiona mediante cookies y ésta queda almacenada en el navegador. En el caso de estar utilizando configuración remota, tanto los servidores de datos, como las consolas deben compartir (NFS) el directorio de datos de entrada (/var/spool/pandora/data_in) para la configuración remota de los agentes, las colecciones y otros directorios.