Balanceador de carga Haproxy

Change History. 1

Table of Contents. 2

1.      Introduccion. 3

1.1         Objectivo. 3

2.      Requirimientos. 3

3.      Arquitectura. 4

4.      Instalacion HA Utilities Suse 11 SP3. 6

4.1         Corosync. 18

4.1.1          Definir recurso del
cluster Heartbeat IP. 21

4.1.2          Parar el cluster en
uno de los nodos. 22

4.1.3          Levantar el cluster
en uno de los nodos. 22

4.1.4          Eliminar resource. 23

4.1.5          Mover resource o
pararlo. 23

4.1.6          NFS. 24

4.1.7          Export de FS: 25

4.1.8          UNISON.. 29

5.      HAPROXY DMZ APACHE. 34

6.      HAPROXY TOMCAT. 37

= 1.
Introduccion =

## 1.1    Objectivo

En el presente documento,
se detalla el proceso de instalación y configuración para dar soporte de
infraestructura al entorno aplicativo “WCS”.

= 2.
Requirimientos =
Los
requerimientos establecidos por parte del proveedor de aplicación, son 2
balanceadores de carga y un recurso NFS en alta disponibilidad.

Uno de
los balanceadores de carga deberá de estar en la capa de presentación web, y el
segundo balanceador deberá de estar en la capa de aplicación.

Cada
uno de estos balanceadores estará en alta disponibilidad con una ip flotante y
uno será una copia exacta del otro, de manera que tendrán ambos la misma
configuración.

A esto
añadiremos la capa del recurso NFS, en la que ambos balanceadores de carga que
se encuentran en la capa de aplicacion publicaran a su vez un recurso NFS de
100gb.

Se ha
optado por el uso de discos independientes en vez de usar un mismo disco
clusterizado y con sistema de ficheros ocfs2.

= 3.
Arquitectura =
Los
servidores creados para la plataforma son los siguientes:

= 4.
Instalacion HA Utilities Suse 11 SP3 =
La
instalación de las aplicaciones que nos permiten generar recursos de cluster y
su gestión, se encuentran en un CD aparte de los propios de instalación del
sistema Suse 11 SP3, estos CDs están alojados en el Datastore de la plataforma **IOM-S4-FC-R5-14,** sus nombres son los
siguientes:

SLE-HA-11-SP3-x86\_64-GM-CD1.iso

SLE-HA-11-SP3-x86\_64-GM-CD2.iso

Los
mapearemos en las maquinas virtuales en las que se deban formar parte del
Cluster.

Instalación de HA
Resources Suse 11 SP3

Una vez que esten mapeados y montados en la maquina virtual, procederemos a
su inclusion como repositorio y a la instalacion de los productos, para ello
lanzaremos el gestor de configuracion de Suse “Yast”.

Y ejecutaremos Software Repositories.

En este punto deremos de especificar que lo que deseamos incluir como
repositorio de software es un CD (que hemos mapeado y montado previamente).

Aceptaremos el contrato
de licencia. Y continuaremos.

Tras la aceptacion del contrato de licencia, nos aparecerán el listado de
productos que tiene instalado la maquina, y en la sección de “Hight
Availability” veremos todos los paquetes de software necesarios, de entre todos
las herramientas los paquetes necesarios con “openais” y “corosync”.
Seleccionaremos todos, por si a futuro se desea incluir el soporte a alguna
otra funcionalidad con HA como el soporte para sistemas de ficheros ocfs2.

Tras las ventanas anteriores habremos comprobado que se han instalado todos
los productos de software que nos dan las funciones de hight availability.

== 4.1
Corosync ==
El software Corosync, nos añadre la posibilidad de creación de un cluster
entre X nodos, una vez tengamos configurado el software corosync y desplegado
en los X nodos, podremos generar X recursos que serán perfectamente movibles
entre los distintos nodos.

La instalación nos genera un fichero de configuración de ejemplo con el
cual podremos hacer una copia y modificarlo.

Editaremos este fichero de configuracion de ejemplo, y deberos de agregar
la configuracion correspondiente a la subred en la cual se encontraran todos
los nodos a clusterizar para que puedan encontrarse entre ellos mediante
broadcast.

ESDATA-WN003:/etc/corosync
# vi corosync.conf

 corosync.conf.5 manual page
 compatibility:
 whitetank
 aisexec {
 # Run as root - this is necessary to
 be able to manage
 # resources with Pacemaker
 user:           root
 group:          root
 }
 service {
 # Load the Pacemaker Cluster Resource
 Manager
 ver:            0
 name:           pacemaker
 use\_mgmtd:      yes
 use\_logd:       yes
 }
 totem {
 # The only valid version is 2
 version:        2
 # How long before declaring a token
 lost (ms)
 token:          5000
 # How many token retransmits before
 forming a new configuration
 token\_retransmits\_before\_loss\_const:
 10
 # How long to wait for join messages
 in the membership protocol (ms)
 join:           60
 # How long to wait for consensus to
 be achieved before starting
 # a new round of membership
 configuration (ms)
 consensus:      6000
 # Turn off the virtual synchrony
 filter
 vsftype:        none
 # Number of messages that may be sent
 by one processor on
 # receipt of the token
 max\_messages:   20
 # Limit generated nodeids to 31-bits
 (positive signed integers)
 clear\_node\_high\_bit: yes
 # Disable encryption
 secauth:        off
 # How many threads to use for
 encryption/decryption
 threads:        0
 # Optionally assign a fixed node id
 (integer)
 # nodeid:       1234

 interface {
**ringnumber:     0**
**# The following values need**
 to be set based on your environment
**bindnetaddr:    10.146.42.0**
**mcastaddr:      226.94.1.1**
**mcastport:      5405**

 }
 }
 logging {
 fileline:       off
 to\_stderr:      no
 to\_logfile:     no
 to\_syslog:      yes
 syslog\_facility: daemon
 debug:          off
 timestamp:      off
 }
 amf {
 mode: disabled
 }

Creamos en el nodo
primario la clave de autenticación de corosync y la copiamos a cada uno de los
nodos que conformen el cluster:

 corosync-keygen
 ESDATA-WN003:~#
 scp /etc/corosync/authkey ESDATA-WN004:/etc/corosync/authkey
 ESDATA-WN004:~#
 chmod 400 /etc/corosync/authkey

Reiniciaremos los
recursos de Cluster.

 service openais start
 Starting
 OpenAIS/Corosync daemon (corosync): starting... OK

Deberemos de ejecutar lo
siguiente para dejar configurado el cluster.

 error:
 unpack\_resources:     Resource start-up
 disabled since no STONITH resources have been defined
 error:
 unpack\_resources:     Either configure
 some or disable STONITH with the stonith-enabled option
 error:
 unpack\_resources:     NOTE: Clusters
 with shared data need STONITH to ensure data integrity
 Errors found during check: config not valid

ESDATA-WN001:/etc/default # crm configure
property stonith-enabled=false

ESDATA-WN001:/etc/default # crm\_verify -L –V

=== 4.1.1     Definir
recurso del cluster Heartbeat IP ===
Con el siguiente
commando, defeinirimos una ip balanceada entre los nodos del cluster.

 ClusterIP ocf:heartbeat:IPaddr2 params ip=10.146.41.23 cidr\_netmask=24 op
 monitor interval=30s

Una vez creado el recurso
la monitorizacion del mismo la podremos realizer con el comando “crm\_mon”.

Esto nos mostrara un status actualizado cada Segundo del estado de todos y
cada uno de los recursos del cluster.

 Last change: Mon Jan 19 13:43:18 2015 by root via
 cibadmin on ESDATA-WN001
 Stack: classic openais (with plugin)
 Current DC: ESDATA-WN002 - partition with quorum
 Version: 1.1.9-2db99f1
 2 Nodes configured, 2 expected votes
 1 Resources configured.
 Online: [ ESDATA-WN001 ESDATA-WN002 ]
 ClusterIP
 (ocf::heartbeat:IPaddr2):
 Started ESDATA-WN001

=== 4.1.2     Parar
el cluster en uno de los nodos. ===
ESDATA-WN001:/etc/default # service openais
stop

Stopping OpenAIS/corosync daemon
(corosync): .done OK

=== 4.1.3     Levantar
el cluster en uno de los nodos. ===
Si paramos el
cluster en el nodo primario el nodo secundario no pasa a ofrecer el recurso
directamente porque no hay cuórum en el cluster. El cuórum (quorum) es una
propiedad que utiliza pacemaker para tomar las decisiones apropiadas mediante
consultas consensuadas a todos los nodos, pero no tiene razón de ser en un
cluster de solo dos nodos, ya que sólo habrá quorum cuando los dos nodos estén
operativos, así que ignoramos las decisiones basadas en cuórum:

 no-quorum-policy=ignore

ESDATA-WN001:/etc/default # service openais
start

Starting OpenAIS/Corosync daemon
(corosync): starting... OK

Ahora si paramos el
Cluster en uno de los nodos perderemos la ip y no saltara el recurso al otro
nodo, si probamos esto desde un ping con una maquina exterior comprobaremos que
se pierde tan solo un paquete de información.

=== 4.1.4     Eliminar
resource ===
En el caso de que
queramos eliminar un recurso del cluster lanzaremos el siguiente commando.
Aunque en el caso que nos ocupa tan solo hemos definitido un recurso que es la
ip balanceada.

 configure delete resourcename
 1.   primitive dlm ocf:pacemaker:controld \
 2.   primitive
 o2cb ocf:ocfs2:o2cb \
 3.   primitive sbd\_stonith stonith:external/sbd
 \

=== 4.1.5     Mover
resource o pararlo ===
Tambien
podremos mover los recursos de cluster de un nodo a otro, en el caso de que
queramos planificar un mantenimiento sobre uno de los nodos.

Esto
como en el caso de caída de uno de los nodos, provocara tan solo la perdida de
un paquete de información si realizamos la monitorización con un ping contra la
ip balanceada.

 ESDATA-WN003:/etc/haproxy # crm\_resource --resource ClusterIP
 --move --node **ESDATA-WN003**

Tambien podremos parar los recursos de
cluster, sin llegar a detener el demonio openais y pararlos de manera
individual, esto en cualquier caso sera siempre mejor opcion que parar
completamente los recursos de cluster mediante el commando “service openais
stop”.

 ClusterIP
 crm resource stop
 ClusterIP

### 4.1.6     NFS

La
plataforma por requerimiento de proveedor necesita un recurso NFS que exporte
un FS de 100gb y que estuviese en alta disponibilidad para que en caso de caída
de un nodo NFS pudiese tomar el control otro nodo.

La
instalación del propio NFSServer es la típica en cualquier Linux, hay que
instalar los paquetes de nfsserver en Linux que son los siguientes que podemos
ver aquí abajo:

Esta instalacion se puede
realizar a través de Yast, o mediante RPM usando el CD de instalación de Suse.

**yast2-nfs-client-2.17.17-0.7.71**
**nfs-doc-1.2.3-18.37.1**
**nfs-client-1.2.3-18.37.1**
**limal-nfs-server-1.5.3-0.2.11**
**limal-nfs-server-perl-1.5.3-0.2.11**
**nfsidmap-0.25-0.13.1**
**nfs-kernel-server-1.2.3-18.29.1**
**yast2-nfs-server-2.17.8-0.2.1**

Una vez instalado el
software de NFS este no esta configurado para que arranque automáticamente por
lo que se deberá de configurar para su arranque con el boot de la maquina.

La configuracion para que arranque en el level 3 y el level 5 es la
siguiente.

Una vez hechos los pasos anteriores comprobaremos que el nfs server
arrancara con el boot de los servidores.

Los servidores de la plataforma que poseen el NFS son los siguientes:

  ESDATA-WN004

Y los servidores cliente de este NFS son los siguientes:

  ESDATA-WS004

Estos servidores cliente, montaran la ip del cluster ya que ambos
servidores NFS publican el mismo recurso y uno es replica del otro.

=== 4.1.7     Export
de FS: ===
Como aparecia reflejado
anteriormente, el volume nfs es un disco de 100gb que esta mapeado a los
servidores:

  ESDATA-WN004

Cada una de estas
maquinas tiene presentado un volumen independiente de 100gb, el cual tendrá los
datos por duplicado.

Este volumen es un disco
normal generado mediante LVM y formateado en ext3.

En ambos servidores se ha
definido el punto de montaje como /nfs y las características de este punto de
montaje son las siguientes.

 --- Volume group ---
 VG Name               vgnfs
 System ID
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  2
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                1
 Open LV               1
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               100.00 GiB
 PE Size               4.00 MiB
 Total PE              25599
 Alloc PE / Size       25599 / 100.00 GiB
 Free
 PE / Size       0 / 0
 VG UUID               HD2aOF-EbFy-3D7H-o0ZX-1b2o-Dwc1-ZwpgVo

 lvdisplay
 --- Logical volume ---
 LV Name                /dev/vgnfs/lvnfs
 VG Name                vgnfs
 LV UUID
 TsqLte-SXRl-oIdU-MEt9-es7z-ubas-M1MsHe
 LV Write Access
 read/write
 LV Creation host, time ESDATA-WN003,
 2015-02-04 08:35:00 +0100
 LV Status              available
 # open                 1
 LV Size                100.00 GiB
 Current LE             25599
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     1024
 Block device           253:7

 pvdisplay
 --- Physical volume ---
 PV Name               /dev/sdc1
 VG Name               vgnfs
 PV Size               100.00 GiB / not usable 3.00
 MiB
 Allocatable           yes (but full)
 PE Size               4.00 MiB
 Total PE              25599
 Free PE               0
 Allocated PE          25599
 PV UUID
 KSYs5f-33SI-D4Ai-JGUz-wq2J-bDdv-IfHCIN

 fdisk -l /dev/sdc
 Disk /dev/sdc:
 107.4 GB, 107374182400 bytes
 6 heads, 24
 sectors/track, 1456355 cylinders, total 209715200 sectors
 Units = sectors of
 1 \* 512 = 512 bytes
 Sector size
 (logical/physical): 512 bytes / 512 bytes
 I/O size
 (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier:
 0x0344219a
 Device Boot      Start         End      Blocks
 Id  System
 /dev/sdc1            2048   209715199
 104856576   83  Linux

En el caso de querer
ampliar a futuro fichero FS, ya que el VG esta creado sobre la particion de
disco sdc1, se debera de presenter un disco de mayor tamaño mover los datos y
cambiar el punto de montaje del /nfs.

La configuración del
fichero /etc/exports es la siguiente.

Como se puede observar esta
configurado para exportar a las 2 maquinas de aplicación de la plataforma.

**ESDATA-WS003**

**ESDATA-WS004**

Una vez editado los ficheros de configuracion, se lanzara el commando
exportfs y exportfs –a para que el demonio empiece a exportar estos recursos
NFS.

### 4.1.8     UNISON

Para poder
ofrecer el sistema de alta disponibilidad a nivel de NFS se evaluo y testeo el
uso de un mismo disco presentado a los 2 servidores ESDATA-WN00X y tener
montado el FS con ocfs2 para poder leer y escribir de manera concurrente, por
incompatibilidad con VMware+Suse no fue posible debido a que panicaban los
sistemas.

La
solución ofrecida es mediante un sistema de replica similar a rsync, pero en el
caso que nos ocupa es una replica a nivel bidireccional, de manera que si se
cae el nodo principal y toma el control el secundario en el momento que se
actualicen ficheros sobre el secundario, cuando este disponible el primario
serán replicados los FS, en el caso contrario realizara lo mismo.

La
instalación de Unison es mediante la instalación de un RPM. Y Sera como la
instalación de cualquier RPM sobre Linux.

**“rpm –i unison-2.40.63-7.1.x86\_64.rpm”**

==== 4.1.8.1
Configuración UNISON ====
Para
poder mantener la sincronía entre 2 equipos con Unison de manera bidireccional,
se deberá de generar una llave privada y transferirla al otro nodo implicado,

Una vez hecho esto,
deberemos de configurar un trabajo de unison, para que sepa cual es el otro
nodo a replicar, el directorio de trabajo de unison, esta dentro del home del
usuario y oculto.

/home/usuario/.unison/

Este directorio contiene un fichero con extension .prf donde se le
especificara la maquina remota y el FS a replicar.

 root =
 ssh://root@10.146.42.87//nfs
 auto = true
 batch = true
 perms = 0
 log = true

Si ejecutamos el binario de “unison” intentara ejecutar el trabajo que
exista en su path de usuario con nombre “default.prf”, en el caso de querer
ejecutar otro trabajo, con otro nombre como el que acabamos de crear, la
sentencia sera la siguiente:

/usr/bin/unison -batch nfs

Para poder mantener una
replica activa entre las maquinas se han configurado unas tareas de cron en
ambas nodos del cluster para poder tener la sincronía de los FS.

Los trabajos de cron son los
siguientes:

El contenido del script
de cron es el siguiente. Y a esto unido estaría el job de unison para el
trabajo de replica del NFS.

  #!/bin/bash
 SHELL=/bin/bash
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 MAILTO=root
 HOME=/root/
 /usr/bin/unison
 -batch nfs
 root =
 ssh://root@10.146.42.87//nfs
 auto = true
 batch = true
 perms = 0
 log = true

La programacion del tiempo de sincronizacion en el job de cron vendra
determinada por la experiencia de uso en la aplicacion y en el numero de
ficheros a sincronizar, para evitar que los trabajos de replica se solapen.

= 5.
HAPROXY DMZ APACHE =
El
cluster de servidores que se encuentra en la DMZ, es un cluster con un recurso
en el cluster a nivel de IP balanceada y cada nodo del cluster posee 2
instalaciones de Haproxy, que balancean el puerto 80 y 443 en modo pass trought
de manera que tan solo aplicara un balanceo a modo de round robin, pero sin
ningún tipo de lógica de persistencia de sesión etc.

  ESDATA-WN002

La
instalación de haproxy es mediante la instalación de un RPM en Linux, y se
realizara como cualquier otro Linux.

“rpm –i
haproxy-1.5.10-2.1.x86\_64.rpm”

Una vez instalado el
software comprobaremos que se arranca en los level de arranque que
correspondan, en nuestro caso runlevel 3 y 5.

Los
ficheros de configuración de haproxy se encuentran dentro del
/etc/haproxy/haproxy.cfg

La
configuración que nos aplicaría para este caso seria la marcada en negrita.

 log 127.0.0.1   local0
 log 127.0.0.1   local1 notice
 maxconn 4096
 chroot /var/lib/haproxy
 user haproxy
 group haproxy
 daemon
 #stats socket   /tmp/haproxy.sock
 #debug
 #quiet
 defaults
 log     global
 mode    http
 option  httplog
 option  dontlognull
 option redispatch
 retries 3
 maxconn 2000
 timeout connect 5000
 timeout client 50000
 timeout server 50000
**listen stats :8080**
**mode http**
**stats enable**
**stats hide-version**
**stats realm Haproxy\ Statistics**
**stats uri /**
**stats auth admin:passw0rd**
**listen bk\_http :80**
**mode tcp**
**option tcplog**
**balance roundrobin**
**server ESDATA-WS001 10.146.41.21:80**
 check
**server ESDATA-WS002 10.146.41.22:80**
 check
**listen bk\_https :443**
**mode tcp**
**option tcplog**
**balance roundrobin**
**server ESDATA-WS001 10.146.41.21:443**
 check
**server ESDATA-WS002 10.146.41.22:443**
 check

Dentro del fichero de
configuracion, la parte marcada en rojo, nos permitira consultar estadisticas
de uso y balanceo mediante un interface web.

= 6.
HAPROXY TOMCAT =
El
haproxy que se encuentra dentro de la red de servidores y por debajo de la DMZ
es un balanceo que se realiza hacia los puertos 8090 y 8091, para este balanceo
si se han solicitado balanceo a través de ip de origen, para tener esa
persistencia.

  ESDATA-WN004

El
fichero de configuración es el siguiente.

 log 127.0.0.1   local0
 log 127.0.0.1   local1 notice
 maxconn 4096
 chroot /var/lib/haproxy
 user haproxy
 group haproxy
 daemon
 #stats socket    /tmp/haproxy.sock
 #debug
 #quiet
 defaults
 log     global
 mode    http
 option  httplog
 option  dontlognull
 option redispatch
 retries 3
 maxconn 2000
 timeout connect 5000
 timeout client 50000
 timeout server 50000
 listen
 stats :8080
 mode http
 stats enable
 stats hide-version
 stats realm Haproxy\ Statistics
 stats uri /
 stats auth admin:passw0rd
**listen bk\_http**
  :8090
**mode tcp**
**option tcplog**
**balance source  ###BALANCEO IP DE ORIGEN###**
**server ESDATA-WS003 10.146.42.91:8090**
 check
**server ESDATA-WS004 10.146.42.92:8090**
 check
**listen bk\_http2**
  :8091
**mode tcp**
**option tcplog**
**balance source  ###BALANCEO IP DE ORIGEN###**
**server ESDATA-WS003 10.146.42.91:8091**
 check
**server ESDATA-WS004 10.146.42.92:8091**
 check