La disponibilidad de los sistemas se clasifica con la regla de los 9s:

Bonding es una t�nica utilizada en GNU/Linux para utilizar dos tarjetas de red como si fueran una.

Los datos son cr�ticos ya que sin ellos no se puede ofrecer el servicio. Existen dos t�cnicas para garantizar la alta disponibilidad en los sistemas de almacenamiento:

La replicaci�n de datos se puede hacer utilizando slony.

S�lo son necesarios en aquellas configuraciones que sean Activo / Activo y/o balanceo de carga.

La funci�n de los balanceadores, tambi�n conocidos como network dispatcher es redireccionar las peticiones a los servidores que las est�n atendiendo.

Es necesario un sistema que detecte cuando existen nodos en el cluster que no est�n disponibles para ofrecer el servicio. En este caso no se enviar�n peticiones para ser atendidas si el cluster es Activo / Activo o no se balancear� el servicio sobre ellos si es Activo / Pasivo.

Para detectar esta situaci�n se utilizan dos t�cnicas:

Es el servicio que se quiere clusterizar.

Son todos aquellos recursos necesarios para el servicio:

Cuando un nodo falla y no es capaz de ofrecer el servicio es necesario disponer un medio para reiniciarlo y que libere los recursos que pudiera tener ocupados.

NAT (Network Address Translation) es una t�cnica utilizada para que una m�quina reciba informaci�n dirigida a otra y esta pueda reenviarla a quien la solicit� inicialmente.

Para ello la m�quina que recibe la informaci�n, en forma de paquetes, deber� reescribir los paquetes sustituyendo su propia direcci�n con la de la m�quina que realiz� la petici�n (nos referimos a direcciones tanto f�sicas, MAC, como l�gicas, IP) una vez reescrito el paquete de la forma correcta el balanceador se encargar� de enviar los paquetes por la interface adecuada para que le lleguen al destino verdadero del paquete.

Cuando el balanceador reciba peticiones este sobreescribir� el paquete y pondr� la direcci�n de un servidor real, gracias a esto los servidores reales podr�n estar ejecutando cualquier sistema operativo que sea accesible v�a TCP/IP.

Cuando el servidor responda lo har� al balanceador y este reescribir� el paquete, otra vez, poniendo en los paquetes la direcci�n del cliente que solicit� la informaci�n.

LVS - NAT.

El balanceador guardar� los datos de todas las conexiones que balancee para luego devolver la respuesta al cliente adecuado.

Pero no todo son ventajas, esta sobreescritura de los paquetes trae consigo una carga de CPU que puede llegar a ser un cuello de botella. Adem�s tendremos que tener en cuenta cual es el ancho real de nuestra interface de red y tener presente que por el balanceador van a pasar tanto las peticiones hacia los servidores, como las respuestas de los servidores hacia los clientes.

Todos estos paquetes tendr�n que ser reescritos por el balanceador y aunque aumentemos la memoria o las capacidades de procesamiento del balanceador todav�a estaremos limitados por el ancho real de la interface ya que las respuestas de los servidores ocupar�n mas ancho de banda que las peticiones.

No suele ser muy recomendable esta opci�n ya que los costes necesarios para desplegar la infraestructura suelen ser mayores que los de implementar LVS con IP Tunneling o Direct Routing.

El balanceador deber� tener dos IP una de cara a los posibles clientes (DIP) y otra en la red de los servidores (VIP), es decir que el balanceador deber� hacer funciones de enrutado con lo cual el n�cleo deber� estar configurado para ello y tendremos que tener el enrutado habilitado y el n�cleo tendr� que estar compilado para poder sobreescribir paquetes.

Utilizando NAT ten�amos un cuello de botella en el balanceador ya que tiene que reescribir y distribuir los paquetes del cliente al servidor y viceversa.

Utilizando IP Tunneling el balanceador �nicamente tendr� que hacerse cargo de las peticiones de los clientes y enviarlas a los servidores, siendo estos mismos los que responder�n a los clientes. De esta forma el balanceador de carga puede manejar mas nodos, es decir el servicio es mas escalable.

LVS - IP Tunneling.

Una vez el balanceador de carga tiene el paquete determina si pertenece a uno de los servicios que tiene balanceados. De ser as� encapsula el paquete en otro paquete y se lo env�a al servidor de destino. Es este el que se encarga de responder al cliente directametne sin pasar por el balanceador.

El balanceador guarda una tabla de conexiones y cuando le llega un paquete determina si ya existe una conexi�n abierta y de ser as� que servidor real es el que est� sirviendola para enviarle el paquete.

Encapsulamiento IP en IP-Tunneling.

Los servidores deber�n estar configurados para trabajar con IP Tunneling (encapsulation) ya que cuando el balanceador recibe un paquete para uno de los servidores este lo encapsula en un datagrama IP y lo manda a uno de los servidores. Cuando el servidor lo recibe tend� que desencapsularlo y responder� directamente al cliente sin pasar por el balanceador con lo cual los servidores tendr�n que estar conectados tanto al balanceador como a los clientes (en NAT s�lo con el balanceador).

Al igual que en IP Tunneling el balanceador s�lo gestionar� las peticiones del cliente hac�a el servidor con lo cual es una soluci�n altamente escalable.

La direcci�n virtual (VIP) es compartida por el balanceador y los servidores. De esta manera el balanceador recibe las peticiones y las env�a a los servidores que procesan las peticiones y dan servicio directamente a los clientes.

LVS - Direct Routing.

En esta soluci�n es necesario que una de las interfaces del balanceador y los servidores est�n en el mismo segmento f�sico de red ya que el balanceador de carga cambiar� su direcci�n f�sica, MAC, en la trama por la direcci�n f�sica de uno de los servidores que tendr� un alias con la direcci�n VIP.

El balanceador guarda una tabla de conexiones y cuando le llega un paquete determina si ya existe una conexi�n abierta y de ser as� que servidor real es el que est� sirviendola para enviarle el paquete.

LVS - Direct Routing.

Cuando utilizamos Tunneling o Direct Routing tanto el balanceador como los servidores comparten una direcci�n IP (VIP) y esto puede traer consigo problemas si los balanceadores y los servidores est�n en la misma red.

El modelo OSI de la ISO consta de 7 capas, las tres primeras son la capa f�sica, la capa de enlace de datos y la capa de red.

Cuando un ordenador transmite datos empieza a encapsular en la capa de aplicaci�n, s�ptima capa. Cuando llega a la capa de red a�ade la informaci�n de red, direcciones IP y direcciones l�gicas (origen y destino). Acto seguido a�ade su direcci�n f�sica o MAC que es una direcci�n �nica que tiene cada tarjeta de red o NIC y que consta de dos partes una que identifica al fabricante de la tarjeta y la otra parte identifica a la tarjeta.

Despu�s en la capa f�sica se traduce toda la informaci�n a se�ales el�ctricas y se transmite por el medio. Adem�s de sus direcciones propias IP y MAC se a�aden las direcciones del destinatario y si el paquete fuera destinado a una red diferente de la de partida se pondr�a en el campo de la MAC de destino la MAC de gateway o del router por defecto y este se ir�a encargando de enrutar el paquete hasta que llegar� al �ltimo router o gateway el cual cambiar�a su MAC por la MAC del equipo que tuviera la IP de destino del paquete. Este �ltimo router mandar�a el paquete por la interface correspondiente y todos los equipos en esa red desencapsular�n el paquete hasta la segunda capa y s�lo aquel cuya MAC este en esa trama, como destino, tomar� el paquete y lo desencapsulara entero para hacer uso de el.

Cuando utilizamos Tunneling o Direct Routing tenemos que tener en cuenta que los clientes hacen las peticiones al balanceador, pero sin embargo las respuestas las reciben de los servidores.

Cuando llega una petici�n de un cliente para el servicio bajo LVS esta llegar� desde fuera de la red, con lo cual el router de esa red har� una petici�n ARP para obtener la MAC de la m�quina con la IP VIP.

En esa red podr�a haber varias m�quinas con la IP VIP (el balanceador y los servidores comparten dicha IP) con lo cual cualquiera de ellas podr�a, y de hecho lo har�, responder a la petici�n. Pero el paquete deber� ir destinado al balanceador no a los servidores.

El balanceador registrar� en sus tablas a que servidor le manda las peticiones y consecuentemente todas las peticiones de ese cliente ir�n al mismo servidor, bajo la conexi�n ya establecida. Si uno de los servidores respondiera a la petici�n ARP el router tendr�a en su tabla ARP la direcci�n f�sica del servidor y todos los paquetes se los enviar� directamente al servidor sin utilizar el balanceador.

Si en alg�n momento se cambiar� la entrada en la tabla ARP y el router actualizar� con la MAC de otra m�quina (el balanceador y el resto de servidores tienen una interface o alias con la IP VIP) entonces las peticiones de ese cliente iran a otro servidor en lugar de al servidor que originariamente estaban yendo. Si esto pasa dentro de una misma conexi�n cuando un servidor empiece a recibir las solicitudes de una conexi�n que el no ha iniciado (la realiz� el servidor que primero respondi� a la petici�n ARP) la conexi�n se cerrar� y habr� que volver a negociarla.

Este problema se presenta con n�cleos a partir de la serie 2.2.x y se soluciona haciendo que la interface que tiene la IP VIP no responda a peticiones ARP en los servidores y si en el balanceador de carga. De esta forma nos aseguramos que cuando el router haga una petici�n ARP para la VIP la �nica m�quina que responda sea el balanceador y de esta forma todos los paquetes para el LVS ser�n enviados al balanceador y este har� su trabajo.

Hemos estado haciendo referencia a que el balanceador distribuir� las peticiones entre los servidores. Pero para que esta distribuci�n sea efectiva ha de ser planificada de alguna forma. A la hora de compilar el n�cleo en el balanceador tendremos que escoger que algoritmos vamos a utilizar para hacer el balanceo de carga.

Los algoritmos m�s interesantes son los siguientes:

ipvsadm es una herramienta en espacio de usuario para interactuar con LVS.

Podemos ver el listado de conexiones:

[jadebustos@dedalo ~]# ipvsadm -Ln
IP Virtual Server version 1.2.0 (size=4096) 
Prot LocalAddress:Port Scheduler Flags 
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn 
TCP  172.16.0.207:443 wlc persistent 3600 
  -> 172.16.0.199:443             Route   1      5          0 
  -> 172.16.0.198:443             Route   1      2          0 
TCP  172.16.0.205:9085 wlc 
  -> 172.16.0.200:9085            Route   1      2          0 
  -> 172.16.0.201:9085            Route   1      2          0 
TCP  172.16.0.206:80 wlc 
  -> 172.16.0.197:80              Route   1      1          0 
  -> 172.16.0.195:80              Route   1      4          0 
  -> 172.16.0.196:80              Route   1      2          0 
TCP  172.16.0.207:80 wlc persistent 3600 
  -> 172.16.0.199:80              Route   1      1          0 
  -> 172.16.0.198:80              Route   1      1          0 
TCP  172.16.0.205:80 wlc 
  -> 172.16.0.200:80              Route   1      1          0 
  -> 172.16.0.201:80              Route   1      1          0
[jadebustos@dedalo ~]#

Podemos sacar estad�sticas:

[jadebustos@dedalo ~]# ipvsadm --list --stats --numeric
IP Virtual Server version 1.2.0 (size=4096) 
Prot LocalAddress:Port               Conns   InPkts  OutPkts  InBytes OutBytes 
  -> RemoteAddress:Port 
TCP  172.16.0.207:443                    7        169     292       x        y 
  -> 172.16.0.199:443                    5        113     214       x        y 
  -> 172.16.0.198:443                    2         56      78       x        y 
TCP  172.16.0.205:9085                   4         67      99       x        y 
  -> 172.16.0.200:9085                   2         34      45       x        y 
  -> 172.16.0.201:9085                   2         33      44       x        y 
TCP  172.16.0.206:80                     7        109     178       x        y 
  -> 172.16.0.197:80                     1         12      23       x        y 
  -> 172.16.0.195:80                     4         67     100       x        y 
  -> 172.16.0.196:80                     2         30      45       x        y 
TCP  172.16.0.207:80                     2         30      58       x        y 
  -> 172.16.0.199:80                     1         13      25       x        y 
  -> 172.16.0.198:80                     1         17      33       x        y 
TCP  172.16.0.205:80                     2         27      50       x        y  
  -> 172.16.0.200:80                     1         15      27       x        y 
  -> 172.16.0.201:80                     1         12      23       x        y 
[jadebustos@dedalo ~]#

Otras opciones que nos permite:

El balanceador es un punto de fallo cr�tico. Si el balanceador no est� disponible no habr� servicio aunque las m�quinas que den el servicio est�n en perfecto estado de funcionamiento.

Fallo en balanceador.

La alta disponibilidad se logr� garantizando que siempre haya un balanceador funcionando, resumiendo el servicio siempre tiene que estar disponible.

Balanceadores en Alta Disponibilidad.

Keepalived es un demonio que se encarga de que siempre haya un balanceador balanceanado el servicio (failover). En realidad es un interface a LVS.

Adem�s tambi�n se encarga de que no se env�en peticiones a servidores que en ese momento no puedan atenderlas (health-checking).

Keepalived se instala en los balanceadores. Uno de ellos ser� el MASTER y el resto ser�n denominados de BACKUP. Cuando el MASTER deje de estar operativo entrar� en funcionamiento el balanceador BACKUP de m�s alta prioridad y continuar� balanceando hasta que el MASTER vuelva a estar operativo o hasta que tenga alg�n problema, entonces lo sustituir� otro balanceador de BACKUP, el siguiente de m�s alta prioridad. De esta forma siempre estar� balanceando el balanceador de m�s alta prioridad. En el momento que un balanceador de m�s alta prioridad que el activo vuelva al servicio asumir� el balanceo.

Keepalived utiliza el protocolo VRRP (rfc 2338). Keepalived formar� un balanceador virtual formado por un balanceador MASTER y varios balanceadores BACKUP funcionando de la manera ant�s descrita.

Para el health-checking de los servicios balanceados keepalived puede realizar la comprobaci�n de varias formas:

El fichero de configuraci�n de keepalived normalmente en /etc/keepalived.conf consta de tres partes:

Un ejemplo t�pico del fichero /etc/keepalived.conf para una configuraci�n Direct Routing:

# Configuration File for keepalived

# Configuracion Global

global_defs {
   notification_email {
     alertas@midominio.com
   }
   notification_email_from balanceador1@midominio.com
   smtp_server 192.168.1.10
   smtp_connect_timeout 30
   lvs_id LVS_DEVEL
}

vrrp_instance wasIntranet {
    state MASTER
    interface eth1
    virtual_router_id 50
    priority 100
    advert_int 1
    wdog-vrrp 1
    virtual_ipaddress {
        172.16.0.205
	172.16.0.206
	172.16.0.207
    }
}

virtual_server 172.16.0.205 80{ 
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    persistence_timeout 3600
    protocol TCP

    real_server 172.16.0.200 80 {
        weight 1
        TCP_CHECK {
            connect_port 80
            connect_timeout 30
        }
        delay_before_retry 3
    }
    real_server 172.16.0.201 80 {
        weight 1
        TCP_CHECK {
            connect_port 80 
            connect_timeout 30
        }
        delay_before_retry 3
    }
}

virtual_server 172.16.0.205 9085 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    persistence_timeout 3600
    protocol TCP

    real_server 172.16.0.200 9085 {
        weight 1
        TCP_CHECK {
           connect_port 9085
           connect_timeout 30
        }
        delay_before_retry 3
    }
    real_server 172.16.0.201 9085 {
        weight 1
        TCP_CHECK {
           connect_port 9085
           connect_timeout 30
        }
        delay_before_retry 3
    }
}

virtual_server 172.16.0.206 80 { 
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    persistence_timeout 3600
    protocol TCP

    real_server 172.16.0.195 80 {
        weight 1
        TCP_CHECK {
            connect_port 80
            connect_timeout 30
        }
        delay_before_retry 3
    }
    real_server 172.16.0.196 80 {
        weight 1
        TCP_CHECK {
            connect_port 80
            connect_timeout 30
        }
        delay_before_retry 3
    }
    real_server 172.16.0.197 80 {
        weight 1
        TCP_CHECK {
            connect_port 80
            connect_timeout 30
        }
        delay_before_retry 3
    }
}

virtual_server 172.16.0.207 80 { 
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    persistence_timeout 3600
    protocol TCP

    real_server 172.16.0.198 80 {
        weight 1
        TCP_CHECK {
            connect_port 80
            connect_timeout 30
        }
        delay_before_retry 3
    }
    real_server 172.16.0.199 80 {
        weight 1
        TCP_CHECK {
            connect_port 80
            connect_timeout 30
        }
        delay_before_retry 3
    }
}

virtual_server 172.16.0.207 443 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    persistence_timeout 3600
    protocol TCP

    real_server 172.16.0.198 443 {
         weight 1
         TCP_CHECK {
            connect_port 443
            connect_timeout 30
         }
         delay_before_retry 3
    }
    real_server 172.16.0.199 443 {
         weight 1
         TCP_CHECK {
             connect_port 443
             connect_timeout 30
         }
         delay_before_retry 3
    }
}