Sitio para la difusión de conocimiento informático. 

Twitter RSS

Cluster de Alta Disponibilidad Open Source

Cluster de Alta Disponibilidad Open Source

Es este post veremos como armar un cluster de alta disponibilidad el cual estará formado por dos nodos y brindará alta disponibilidad y balanceo de carga a servicios tales como HTTP/HTTPS, SMTP, DNS, SMB, etc. Para esto dividiremos el proceso en dos etapas: 1) configuración de la alta disponibilidad de las IP’s virtuales, 2) configuración del balanceo de carga en ambos servidores. Las herramientas que utilizaremos para esto serán Pacemaker, corosync y openais para la primer etapa; y lvs + ldirector para la segunda etapa.

Antes de comenzar debemos configurar el sistema para que permite el forward de paquetes. Para esto editamos el archivo de configuración “/etc/sysctl.conf” y agregamos lo siguiente:
net.ipv4.ip_forward = 1
A continuación ejecutamos el comando “sysctl -p”, el cual leera el archivo y aplicará los cambios al kernel.

 

Primer etapa – Pacemaker
(http://clusterlabs.org/wiki/Documentation).

– Instalación: La instalación de este paquete en SO opensource la haremos utilizando los repositorios de nuestra distribución:
– Redhat/Centos/Fedora: yum install pacemaker corosync openais- Debain/Ubuntu: apt-get install pacemaker corosync openais
– OpenSuse, Suse Sless: yast -> software -> software management -> search -> pacemaker / corosync / openais -> install.

Configuración Corosync: En esta etapa mostraremos como modificar el archivo de configuración de “corosync”. Para esto editaremos el archivo “/etc/corosync/corosync.conf” y lo modificaremos de la siguiente manera:
1)  Generamos la Key con la que se identificaran los nodos de nuestro cluster para intercambiar información:
sudo corosync-keygen
scp /etc/corosync/authkey IP_otro_nodo
sudo chown root:root /etc/corosync/authkey
sudo chmod 400 /etc/corosync/authkey
2) Edito el archivo de configuración corosync.conf y lo dejo de la sigueinte manera:
compatibility: whitetank
aisexec {
user:           root
group:          root
}
service {
ver:            0
name:           pacemaker
use_mgmtd:      yes
use_logd:       yes
}
totem {
version: 2
token:          5000
token_retransmits_before_loss_const: 10
join:           60
consensus:      6000
vsftype:        none
max_messages:   20
clear_node_high_bit: new
secauth: on
threads: 0
interface {
member {
memberaddr: IP_Nodo_Uno
}
member {
memberaddr: IP_Nodo_Dos
}
ringnumber: 0
bindnetaddr: Dirección_de_mi_Red
mcastport: 5405
ttl: 1
}
transport: udpu
}

logging {
fileline: off
to_stderr: no
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: off
logger_subsys {
subsys: AMF
debug: off
}
}

3) Reinicio el servicio en ambos nodos: “/etc/init.d/openais restart”
Agrego openais al inicio automático del sistema: “Chkconfig openais on”

4) Configuramos Pacemaker con la herramienta CRM para crear una IP virtual que será parte del cluster, ej. 172.20.100.1.
Dado que nuestro cluster constará solo de dos nodos debemos ignorar el Quorum del Cluster, y deshabilitar stonith (Shut The Other Node In The Head)
También verán que elegimos el nombre de CIB “HA-Config”, y el nombre del recurso que estará asociado a la IP como “VIP-1”:
root# crm
crm(live)# cbi new HA-Config
crm(HA-Config)#  configure
crm(HA-Config)#  property stonith-enabled=false
crm(HA-Config)#  property no-quorum-policy=ignore
crm(HA-Config)#  primitive VIP-1 ocf:heartbeat:IPaddr params ip=172.20.100.1 op monitor interval=5s
crm(HA-Config)#  crm configure rsc_defaults resource-stickiness=”100″
crm(HA-Config)#  verify
crm(HA-Config)#  end
crm(live)# cib use live
crm(live)# cib commit HA-config
cmr(live)# exit
Configuro la VIP para que no vuelva en caso de failover:
root#  crm_resource –meta –resource VIP-1 –set-parameter target-role –parameter-value Started
root#  crm_resource –meta –resource VIP-1 –set-parameter migration-threshold –parameter-value 1
root#  crm_resource –meta –resource VIP-1 –set-parameter multiple-active –parameter-value stop_start
root#  crm_resource –meta –resource VIP-1 –set-parameter resource-stickiness –parameter-value 150
root#  crm configure property  no-quorum-policy=ignore

Podemos gestionar nuestros recuros utilizando CRM dentro de la sección “resources”, y podemos ver los comandos para esto utilizando la ayuda “?”:
crm(live)# resources
crm(resources)# ?

A este punto tenemos nuestro recurso configurado en el Cluster de Pacemaker brindando alta disponibilidad al mismo. Procederemos a configurar el balanceo de carga.

 

Segunda Etapa – VLS + Ldirectord
(http://www.linuxvirtualserver.org/).

– Instalación: La instalación de este paquete en SOs opensource la haremos utilizando los repositorios de nuestra distribución:
– Redhat/Centos/Fedora: yum install ipvsadm ldirectord
– Debain/Ubuntu: apt-get install ipvsadm ldirectord
– OpenSuse, Suse Sless: yast -> software -> software management -> search ->ipvsadm / ldirectord -> install.

– Configuración: Editaremos el archivo de configuración de ldirectord el cual se encuentra en “/etc/ha.d/ldirectord.cf”. El mismo tiene un formato pre definido el cual configura automáticamente “ipvsadm”. Daremos lagunos ejemplos:

# vim /etc/ha.d/ldirectord.cf
checktimeout=10
checkinterval=2
autoreload=no
logfile=”/var/log/ldirectord.log”
quiescent=yes
#
# Comienza la configuración de nuestra VIP:
#
virtual=172.20.100.1:80
real=172.20.100.101:80 gate
real=172.20.100.102:80 gate
fallback=127.0.0.1:80 gate
#protocolo que se gestionará:
service=http
#Scheduler es el algoritmo usado para hacer el reparto de carga rr=RoundRObin, lc= least conections… etc (ver man ldirectrd)
scheduler=rr
protocol=tcp
#Checktype es la “prueba de vida” que hará el ldirectord para saber si el servidor real esta vivo, en este caso negotiate que comprobará una respuesta (hay otros por ej connection.). Si utilizamos “connection” no es necesario configurar el “request” y “recive”; esto podría aplicar a servicios tales como SMTP, MySQL, SMB, etc.
checktype=negotiate
#archivo que se solicitará en los servidores web para la prueba de vida, debe estar en DocumentRoot
request=”prueba/prueba-file.html”
#El archivo debe contener unicamente esta linea de texto para confirmar la validez del sitio web
receive=”HTTP OK!”

Con esto el ldirectord creará una IP virtual 172.20.100.1:80 que repartirá a los servidores reales por el método Direct Routing (gate).
Existen 3 métodos: NAT ,Direct Routing e IP Tunneling:
– NAT: Las peticiones entrantes llegan a la IP virtual y son reenviadas hacia los servidores reales cambiando la IP destino (NATeo). La respuesta de los servidores reales vuelve al balanceador quien de nuevo cambia la IP y reenvía al petcionario. Como todo el tráfico pasa por el balanceador suponde normalmente un cuello de botella para el cluster.
– IP Tunneling: LVS manda las peticiones a los servidores reales a través de un tunel IP y los servidores responde directamente al peticionario a través de sus tablas de enrutamiento (necesitan pues de gateway).
– Direct routing: Los paquetes del peticionario son enviados directamente a los servidores reales (forwarding). Como el paquete IP no es modificado los servidores reales para aceptarlo necesitan una interfaz virtual no-ARP ( para evitar conflictos de red al tener la misma IP que la virtual). La respuesta
se envía directamente al peticionario desde el servidor real.

De esta forma Ldirectord hace lo siguiente: Conecta cada 10 segundos (checkinterval) con cada servidor real y pide la prueba 172.20.100.1:80/prueba/prueba-file.html (request/receive). Si no recibe la cadena que pusimos en ese fichero (“HTTO OK””) en un tiempo de 2 segundos (checktimeout), eliminara ese servidor del “pool” de servidores disponilbles a los que mandar peticiones. Estará de nuevo disponible cuando el test sea exitoso.

Podemos verificar lo que está aplicando lvs mediante el comando “ipvsadm -nL”.

 

 

De esta forma tenemos armado un cluster de balanceo de carga y alta disponibilidad que atiene los servicios que requiera nuestro centro de cómputos.

 

 

 
Home Linux OS High Availability and Load Balancing Cluster de Alta Disponibilidad Open Source