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 y prediction.
  • Balanceo de Carga en la BBDD.
  • Balanceo y HA de los servidores de reconocimiento.
  • Balanceo y HA de la consola de Pandora FMS.

1.1.1 Balanceo y HA del Servidor de Datos

Este es el escenario más complejo, ya que a nivel de Pandora FMS no es necesario saber nada especial sobre la instalación del servidor, y en cambio se necesita emplear otra herramienta para implementar HA y el balanceo de carga, herramientas hardware comerciales que implementen HA y balanceo, o mediante soluciones OpenSource como vrrpd, LVS o Keepalive.

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 y si es necesario un servidor SSH/FTP, con el correspondiente trabajo de copiar las llaves de cada máquina en el servidor (SSH). Con Tentacle es más sencillo ya que basta replicar la configuración. Cada máquina tendrá una dirección IP diferente, y el balanceador proveerá (al igual que con el clúster MySQL) una única dirección IP a la que los agentes se conectarán para enviar sus datos. El balanceador se encargará de enviar los datos al servidor que corresponda.

Si uno 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.


Otra forma de implementar la HA es mediante el envío desde los agentes, a dos servidores diferentes, uno de ellos de reserva (HA Activo/Pasivo) en caso de que falle el principal, o los dos a la vez, replicando datos en dos instancias independientes de Pandora FMS. Esto se descibe a continuación como "Balanceo en los agentes Software".

Al final del capítulo se describe el mecanismo para implementar HA y balanceo de carga con LVS y Keepalive sobre un servicio TCP que puede ser el puerto de Tentacle (41121) o el puerto SSH, FTP o cualquier otro. El mismo procedimiento se puede emplear para clusterizar dos o más sistemas sirviendo la consola Web de Pandora FMS mediante un Apache.



Ha2.png



1.1.1.1 Balanceo 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.1.2 Balanceo y HA de los servidores de Red, WMI,. plugin, web y prediction

Esto es más sencillo. 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.1.2.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.1.3 Balanceo de Carga en la BBDD

Es posible configurar un clúster de la base de datos para implementar a la vez HA y balanceo de carga. La base de datos es el componente más critico de toda la arquitectura, por lo que un clúster es una solución óptima. Sólo se necesita convertir el esquema DB en tablas compatibles de un clúster MySQL. Este escenario ha sido probado y funciona bien, pero es necesario un conocimiento avanzado en administración de clusters con MySQL5 y que los nodos dispongan de mucha memoria RAM. Un mínimo de 2GiB en un escenario de dos nodos para un máximo de 5000 módulos (en total).

En este caso no es necesaria una configuración especial de Pandora FMS.



Ha5.png



1.1.4 Balanceo y HA de los servidores de reconocimiento

En la consola de reconocimiento la redundancia es tan sencilla de aplicar como instalar dos servidores de reconocimiento con tareas alternas. De forma que si cae uno, el otro siga ejecutando la misma tarea.

1.1.5 Balanceo y HA de la consola de Pandora FMS

En este caso tampoco es necesaria una configuración especial de Pandora FMS. Es fácil, 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. El procedimiento de balanceo implementando LVS y la HA empleando KeepAlived se describe más adelante.

1.2 Anexo 1: Implementación de HA y balanceo de carga con LVS y Keepalived

Para el balanceo de carga se propone usar Linux Virtual Server (LVS). Para gestionar la Alta Disponibilidad (HA) entre los servicios (en este caso SSH), se propone Keepalived.

LVS

Actualmente, la labor principal del proyecto LVS es desarrollar un sistema IP avanzado de balanceo de carga por software (IPVS), balanceo de carga por software a nivel de aplicación y componentes para la gestión de clúster de servicios.

IPVS

Sistema IP avanzado de balanceo de carga por software implementado en el propio kernel de Linux y ya incluido en las versiones 2.4 y 2.6.

Keepalived

Se usa para manejar el LVS. Keepalived está siendo usado en el clúster para controlar que los servidores SSH, tanto de Nodo-1 como de Nodo-2 están vivos, si alguno de ellos cae, Keepalived indicará a LVS que uno de los dos nodos ha caído y debe redirigir las peticiones al nodo vivo.

Se ha escogido Keepalived como servicio de HA dado que permite mantener una persistencia de sesión entre los servidores. Es decir si uno de los nodos cae, los usuario que estén trabajando en dicho nodo, serán encaminados al otro nodo vivo, pero éstas continuarán exactamente en el mismo sitio donde estaban antes, haciendo así la caída totalmente transparente a su trabajo y a sus sesiones (en el caso de SSH no funcionará debido a la lógica del cifrado del SSH, pero en sesiones TCP simples, como Tentacle sin SSL o FTP, funcionaría sin problemas). En el caso de Tentacle/SSL se reintentaría la comunicación y no se perdería la información del paquete de datos.

El fichero de configuración y ordenes de uso de KeepAlived está en el Apéndice 2.

Algoritmo de balanceo de carga

Los dos algoritmos más usados hoy en día son: «Round Robin» y «Weight Round Robin» ambos son muy similares y se basan en una asignación de trabajos por turnos.

En el caso del algoritmo de «Round Robin», es uno de los algoritmos de planificación de procesos más simples dentro de un sistema operativo que asigna a cada proceso una porción de tiempo equitativa y ordenada, tratando a todos los procesos con la misma prioridad.

Por otro lado, el algoritmo de «Weight Round Robin», permite asignar peso a las máquinas dentro del clúster para que un número de peticiones determinadas vayan a un nodo u a otro, en función de su peso dentro del clúster.

Esto no tiene sentido en la topología que nos ocupa, ya que ambas máquinas tienen exactamente las mismas características de hardware. Por ello se ha decidido usar «Round Robin» como algoritmo de balanceo de carga.

1.2.1 Actuación ante la caída de un nodo

Keepalived detectará si uno de los servicios cae, de ocurrir, eliminaría de la lista de nodos activos de LVS al nodo que ha fallado, de tal forma que todas las peticiones al nodo que ha fallado serían redirigidas al nodo activo.

Una vez se solucione el posible problema con el servicio que haya caído, se deberá reiniciar keepalived:

/etc/init.d/keepalived restart

Con este reinicio del servicio, se volverán a insertar los nodos en la lista de nodos disponibles de LVS.

Si uno de los nodos cae, no habrá que realizar una inserción manual de los nodos usando ipvsadm, ya que Keepalived es el que lo hará una vez sea reiniciado y comprobado que los servicios de los que se supone deben prestar un servicio de HA están corriendo y son accesibles por sus «HealthCheckers».

1.3 Anexo 2. Configuración del balanceador LVS

Uso de ipvsadm: Instalación del Linux Director con ipvsadm:

ipvsadm -A -t ip_cluster:22 -s rr

Las opciones son:

  • A añadir servicio
  • t Servicio TCP con el formato IP:puerto
  • s Planificador, en este caso se ha de pasar el parámetro "rr" (round robin)

Se instalan los nodos (servidores reales) a los que van a ser redirigidas las peticiones al puerto 22

ipvsadm-a -t ip_cluster:22 -r 192.168.1.10:22 -m ipvsadm -a -t ip_cluster:22 -r 192.168.1.11:22 -m

La situación de ipvsadm sin conexiones activas es la siguiente:

Prot LocalAddress:Port Scheduler Flags 
 -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP cluster:www rr 
 -> nodo-2:ssh                    Masq    1         0        0
 -> nodo-1:ssh                    Masq    1         0        0

Usando el algoritmo de «Round Robin», ambas máquinas tiene el mismo peso dentro del clúster. Por tanto se repartirán las conexiones. Aquí se ve un ejemplo de LVS balanceando conexiones contra el clúster:

Usando el algoritmo de «Round Robin», ambas máquinas tiene el mismo peso dentro del clúster. Por tanto se repartirán las conexiones. Aquí se ve un ejemplo de LVS balanceando conexiones contra el clúster:

Prot LocalAddress:Port Scheduler Flags 
 -> RemoteAddress:Port      Forward Weight ActiveConn InActConn

TCP cluster:ssh rr 
 -> nodo-2:ssh              Masq     1         12        161
 -> nodo-1:ssh              Masq     1         11        162

1.4 Anexo 3. Configuración de KeepAlived

Keepalived es el que se encarga de verificar que los servicios indicados en su fichero de configuración (/etc/keepalived/keepalived.conf) están vivos, y mantener los diferentes hosts dentro del cluster de balanceo Si uno de esos servicios se cae, saca el host del cluster de balanceo.

Para arrancar Keepalived:

/etc/init.d/keepalived start

Para parar Keepalived:

/etc/init.d/keepalived stop

El fichero de configuración usado para el clúster es el siguiente:

 # Configuration File for keepalived
  global_defs {
      notification_email {
          email@valido.com
      }
      notification_email_from keepalived@domain
      smtp_server 127.0.0.1
      smtp_connect_timeout 30
      lvs_id LVS_MAIN
 }
 
 virtual_server 192.168.1.1 22 {
        delay_loop 30
        lb_algo rr
        lb_kind NAT
        protocol TCP
        real_server 192.168.1.10 22 {
              weight 1
               TCP_CHECK {
                        connect_port 22
                        connect_timeout 3
                        nb_get_retry 3
                        delay_before_retry 1
                }
        }
        real_server 192.168.1.11 22 {
              weight 1
              TCP_CHECK {
                        connect_port 22
                        connect_timeout 3
                        nb_get_retry 3
                        delay_before_retry 1
              }
        }
 }

Volver a Indice de Documentacion Pandora FMS