Procedimiento de configuracin Servicio de Alta Disponibilidad

Diagrama del problema:

cliente

cliente

cliente

cliente

INTERNET
VIP 222.22.2.100 VIP 222.22.2.100

IP 222.22.2.10

IP 222.22.2.11

VRRP LVS1
IP 192.168.0.10

LVS2
IP 192.168.0.11

sw

IP 192.168.0.120:80

IP 192.168.0.130:80

WS1

WS2

Para el diagrama anterior, slo se muestra servidores web en el esquema de alta disponibilidad. Aunque es posible incorporar ms servidores web como otros tipos de servidores. Las pruebas que se llevan a cabo para demostrar este esquema slo fueron basadas en servicios web apache. Es posible aplicar el mismo diagrama a servicios de correo, shell remota, etc. Otros servicios podran necesitar algunas caractersticas extras, como diversos sistemas de archivos, medios de almacenamiento pre configurados, etc. 1) Preparacin de los servicios: Debido a que los servidores web no estar expuestos directamente a los clientes, si no que sern ocultados por una direccin IP virtual y dispuestos en lo que se denomina una granja de servidores, es que ser necesario modificar los archivos log de estos servidores web. Dado que apache registra en el log cada cliente que solicita el servicio, se debe modificar el log para que lo que se registre no sea la conexin del balanceador de carga que llama al servicio, si no que se registre el cliente que desde internet pasa por el balanceador y, en definitiva, es el verdadero solicitante del servicio. Para esto se abre el archivo /etc/apache2/apache2.conf y modificamos el segundo LogFormat por:
LogFormat %{X-Forwarded-For}i %1 %u %t \%r\ %> %0 \%{Referer}i \ \%{User-Agent}i\ combined #Todo en una misma linea

De esta manera se ordena a apache a registrar en el log los datos pertenecientes al cliente remoto y no a alguna de las mquinas pertenecientes a la solucin de alta disponibilidad. Esta configuracin se debe realizar en todas las mquinas que sern parte de la granja de servidores. Como es recomendable, los servidores requieren una configuracin esttica de red. La siguiente ser la configuracin para los servidores web. Aqu podra tratarse de servidores con cualquier sistema operativo. Pero para el caso particular de esta prueba los servidores web estarn implementados sobre Debian 6:
#WS1 iface eth0 inet static address 192.168.0.120 netmask 255.255.255.0 gateway 192.168.0.1 broadcast 192.168.0.255 network 192.168.0.0

En WS2:
#WS2 iface eth0 inet static address 192.168.0.130 netmask 255.255.255.0 gateway 192.168.0.1 broadcast 192.168.0.255 network 192.168.0.0

2) Preparacin de los componentes de Alta Disponibilidad: a) Configuracin de red con direcciones estticas en todas las mquinas. LVS1:
#LVS1 #/etc/sysconfig/network-script/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static HWADDR=XX:XX:XX:XX:XX:XX IPADDR=222.22.2.110 NETMASK=255.255.255.0 NM_CONTROLLED=yes ONBOOT=yes type=Ethernet UUID=AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA #LVS1 #/etc/sysconfig/network-script/ifcfg-eth1 DEVICE=eth1 BOOTPROTO=static HWADDR=II:II:II:II:II:II IPADDR=192.168.0.10 NETMASK=255.255.255.0 NM_CONTROLLED=yes ONBOOT=yes type=Ethernet UUID=BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB

LVS2:
#LVS2 #/etc/sysconfig/network-scrip/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static HWADDR=YY:YY:YY:YY:YY:YY IPADDR=222.22.2.111 NETMASK=255.255.255.0 NM_CONTROLLED=yes ONBOOT=yes type=Ethernet UUID=CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC #LVS2 #/etc/sysconfig/network-script/ifcfg-eth1 DEVICE=eth1 BOOTPROTO=static HWADDR=JJ:JJ:JJ:JJ:JJ:JJ IPADDR=192.168.0.11 NETMASK=255.255.255.0 NM_CONTROLLED=yes ONBOOT=yes type=Ethernet UUID=DDDDDDDD-DDDD-DDDD-DDDD-DDDDDDDDDDDD

Se asume que ambos nodos pueden resolver nombre o tienen acceso a Internet para descargar el software necesario. Si esto no es as, configure y revise lo necesario. b) Descarga de kernel de linux 2.6.39.4 con soporte lvs en LVS1 y LVS2.
# wget http://www.kernel.org/pub/linux/v2.6/linux-2.6.39.4.tar.gz

c) Configuracin e instalacin del kernel descargado.

# yum -y install make gcc perl ncurses-devel # tar zxvf linux-2.6.39.4.tar.gz # cd linux linux-2.6.39.4.tar.gz linux-2.6.39.4.tar.gz]# make menuconfig linux-2.6.39.4.tar.gz]# make modules_install linux-2.6.39.4.tar.gz]# make install

d) Arranque con el nuevo kernel. e) Descarga de servicio Keepalived en los servidores Linux Virtual Server
# yum -y install keepalived

3) Configuracin de Keepalived: Este servicio se configur de forma muy similar en dos servidores, de los cuales uno ser un servidor primario o MASTER y otro, un secundario o BACKUP, de esta manera el servidor Master entregar el servicio a los clientes y balancear la carga dentro de la granja de servidores, pero si llega a haber algn fallo, el servidor Backup tomar el rol de Master, hasta que este vuelva a funcionar. Para configurar Keepalived se debe acceder a su archivo de configuracin en /etc/keepalived/keepalived.conf tanto en el servidor que har de Master como en el que har de Backup y se establecer la siguiente configuracin:
global_defs { notification_email { armin.vera@gmail.com } notification_email_from armin.vera@gmail.com smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_1 } vrrp_sync_group VG1 { group { VI_1 VI_2 } } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51

priority 100 advert_int 1 lvs_sync_daemon_interface eth0 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 222.22.2.100 } } vrrp_instance VI_2 { state MASTER interface eth1 virtual_router_id 51 priority 100 advert_int 1 lvs_sync_daemon_interface eth1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.0.1 } } virtual_server 222.22.2.100 80 { delay_loop 6 lb_algo rr lb_kind NAT protocol TCP real_server 192.168.0.120 80 { weight 1 TCP_CHECK { connect_timeout 3 connect_port 80 } } real_server 192.168.0.130 80 { weight 1 TCP_CHECK { connect_timeout 3 connect_port 80 } } }

Esta configuracin debe ser aplicada en ambos servidores LVS, salvo que en servidor Backup debe variar en los valores de router_id y priority. La documentacin tambin plantea que el atributo STATE debera de BACKUP en el servidor de respaldo, pero en la prctica, el valor menor en priority marca la diferencia entre un servidor primario y uno secundario. 4) Configuracin Firewall Iptables: Dada la capa de seguridad de Linux, es necesario configurar Iptables para permitir el trfico desde internet hacia el balanceo de carga y la comunicacin de keepalived. El archivo /etc/sysconfig/iptables/ debe quedar de la

siguiente manera, en ambos servidores:

*nat :PREROUTING ACCEPT [22:3266] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [30:1800] :POSTROUTING ACCEPT [12:720] -A POSTROUTING -o eth0 -j MASQUERADE COMMIT *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [54:4300] -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p vrrp -j ACCEPT -A INPUT -d 224.0.0.0/8 -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A FORWARD -i eth1 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT

De esta manera se logra enmascarar el trafico que viene desde la LAN, en este caso perteneciente a la granja de servidores web, as el cliente siempre ver una comunicacin entre la IP o URL que escribi en el navegador y nunca sabr que est siendo atendido por un cluster de servidores web. Tambin se permite la comunicacin entre el servidor Master y el Backup mediante el protocolo VRRP, se permite el trfico de paquetes multicast usados por Keepalived para conocer la salud de los nodos involucrados. Obviamente se necesita mantener la escucha del puerto 80 para recibir requerimientos web y por ltimo el reenvo de paquetes que entran en los LVS desde la interfaz eth1 expuesta la granja de servidores hacia la interfaz eth0 que ser expuesta a Internet. 5) Configuraciones finales: Dado que se establece una direccin ip virtual que ser expuesta a los clientes, es necesario poner un flag en el archivo /etc/sysconf.ctl
net.ipv4.ip_nonlocal_bind = 1

As, permitiremos que se comparta una direccin de red sin que est asociada a un dispositivo fsico. Adems es necesario decirle al kernel que reenvie paquetes entre las interfaces fsicas. Dentro del mismo archivo ubicar el siguiente atributo y establecerlo en 1:
net.ipv4.ip_forward = 1

Aplicamos sysctl -p para parsear este archivo sin la necesidad de reiniciar el sistema. Iniciamos Keepalived en el servidor Master y luego en el servidor Backup. Mediante el comando ip se puede comprobar el funcionamiento de los servidores. En el servidor Master escribimos ip addr list y nos mostrar la lista de direcciones y las interfaces a las cuales se encuentran asociadas:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:84:a4:c2 brd ff:ff:ff:ff:ff:ff inet 222.22.2.110/24 brd 222.22.2.255 scope global eth0 inet 222.22.2.100/32 scope global eth0 inet6 fe80::a00:27ff:fe84:a4c2/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:4d:ef:1c brd ff:ff:ff:ff:ff:ff inet 192.168.0.10/24 brd 192.168.0.255 scope global eth1 inet 192.168.0.1/32 scope global eth1 inet6 fe80::a00:27ff:fe4d:ef1c/64 scope link valid_lft forever preferred_lft forever

Las direcciones IP destacadas estn asociadas a interfaces fsicas, siendo el caso de la interfaz eth0 quien posee su direccin real 222.22.2.110 definida en la configuracin de la red y la direccin virtual 222.22.2.100 establecida en keepalived.conf expuesta a internet. Luego, la interfaz eth1 mantiene su direccin real 192.168.0.10 igualmente definida en la configuracin de red y la direccin 192.168.0.1 definida por Keepalived. Esta ltima direccin es la puerta de enlace a la que deben apuntar las mquinas dentro de la granja de servidores. Cuando el servido keepalived es detenido por alguna razn, o simplemente el servidor primario o Master deja de funcionar, el servidor Backup asume el control, pasando a ser Master y su configuracin pasa a ser la misma que el servidor cado, proveyendo de alta disponibilidad al conjunto. Si se detiene Keepalived en el nodo Master, el comando ip del nodo Backup debe arrojar la misma salida. De esta manera, si todo ha sido bien configurado, se tiene un servicio bsico de Alta Disponibilidad.