- Cluster de alta disponibilidad y espejo con Ubuntu 7.04
-
Cluster de alta disponibilidad y espejo con Ubuntu 7.04
Cluster de alta disponibilidad y espejo con Ubuntu 7.04
Este proyecto fue realizado como un proyecto de comunicaciones I de la Universidad de El Salvador
La versión en que se vaso en ese momento fue Ubuntu 7.04 pero puede funcionar sin problemas en otras versiones.
- Contenido
- Instalaciones previas
- Configuración de Nodos Balanceadores
- - Habilitar IP Virtual Server
- - Instalación de Ultramonkey
- - Permitir la expedición de paquetes
- - Configuración de Hearbeat y LDirector
- Configuración de Nodos Apache
- - Instalación de LAMP
- - Configuración de la IP virtual
- - Configuración de pagina de prueba
- Pruebas de funcionamiento
- Pruebas de alta disponibilidad del cluster
-
-
- Instalaciones previas
-
- Software.- Todos los nodos del cluster deberán tener instalado la versión 7.04 de Ubuntu debido a que todas las configuraciones que se realizaran serán en base a esa distribución y esa versión específica, no significa que solo se pueda hacer en esa versión ya que el software es para cualquier distribución de Linux.
- Hardware
- - Cada computador debe tener una NIC instalada.
- - Los nodos balanceadores también deberán contar con un puerto serial macho de nueve pines.
- Armar topología tipo estrella
- Todos los nodos del cluster estarán concentrados en un mismo Switch.
-
- Configuración de Nodos Balanceadores
- Habilitar IP Virtual Server
- IPVS (IP Virtual Server) implementa una capa de transporte dentro del kernel Linux de los balanceadores de carga. Esta capa es conocida como capa de conmutación.
- Para llevar a cabo el proceso ejecutamos lo siguiente en consola como usuario root:
echo ip_vs_dh >> /etc/modules echo ip_vs_ftp >> /etc/modules echo ip_vs >> /etc/modules echo ip_vs_lblc >> /etc/modules echo ip_vs_lblcr >> /etc/modules echo ip_vs_lc >> /etc/modules echo ip_vs_nq >> /etc/modules echo ip_vs_rr >> /etc/modules echo ip_vs_sed >> /etc/modules echo ip_vs_sh >> /etc/modules echo ip_vs_wlc >> /etc/modules echo ip_vs_wrr >> /etc/modules modprobe ip_vs_dh modprobe ip_vs_ftp modprobe ip_vs modprobe ip_vs_lblc modprobe ip_vs_lblcr modprobe ip_vs_lc modprobe ip_vs_nq modprobe ip_vs_rr modprobe ip_vs_sed modprobe ip_vs_sh modprobe ip_vs_wlc modprobe ip_vs_wrr
- Instalación de Ultramonkey
- Ultramonkey es un paquete para implementar balanceadores de carga y servicios de alta disponibilidad en una red de área local, usando componentes de fuente abierta en el sistema operativo Linux.
- Este paquete provee Heartbeat, el software de alta disponibilidad a utilizar (usado por los balanceadores de carga para monitorizarse entre ellos y verificar cual de ellos esta activo) y ldirectord el actual balanceador de carga.
- Para instalar Ultramonkey se necesita editar el siguiente archivo: sources.list.
Para acceder a dicho archivo digitamos en consola como usuario root lo siguiente:
gedit /etc/apt/sources.list
Ahora agregamos las siguientes líneas al final del archivo.
deb http://www.ultramonkey.org/download/3/ sarge main deb-src http://www.ultramonkey.org/download/3 sarge main
Por ultimo en consola digitar lo siguiente para importar las llaves GPG:
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 03C0023E05410E97 gpg --armor --export 03C0023E05410E97 | apt-key add –
Después de haber hecho esto, siempre en consola digitamos lo siguiente:apt-get update
Instalamos el UltraMonkey (En consola como usuario root):
apt-get install ultramonkey
- Permitir la expedición de paquetes
Los balanceadores de carga necesitan ser capaces de dirigir o enrutar el tráfico para los nodos apache, por lo tanto debemos permitir la expedición de paquetes en los balanceadores de carga. Para ello debemos modificar el archivo sysctl.confPara acceder a dicho archivo digitamos en consola lo siguiente:
gedit /etc/sysctl.conf
Agregamos lo siguiente al archivo:# Enables packet forwarding net.ipv4.ip_forward = 1
Para probar la configuración digitamos lo siguiente en consola:
sysctl -p
Nos dará como respuesta:kernel.printk = 4 4 1 7 kernel.maps_protect = 1 fs.inotify.max_user_watches = 524288 vm.mmap_min_addr = 65536 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.ip_forward = 1
- Configuración de Hearbeat
- Ahora tenemos que crear tres archivos de configuración para heartbeat. Estos deben ser idénticos en ambos balanceadores de carga.
Para la creación de dichos archivos seguir los siguientes pasos: En consola digitar lo siguiente:
gedit /etc/ha.d/ha.cf
Digitar el siguiente contenido al archivo:
logfacility local0 bcast eth0 # Linux mcast eth0 225.0.0.1 694 1 0 auto_failback off node loadb1 node loadb2 respawn hacluster /usr/lib/heartbeat/ipfail apiauth ipfail gid=haclient uid=hacluster
En este caso el nombre de cada nodo es: loadb1 y loadb2 respectivamente para los balanceadores de carga 1 y 2Para el siguiente archivo digitamos en consola:
gedit /etc/ha.d/haresources
E introducimos el siguiente contenido al archivo:loadb1 \
ldirectord::ldirectord.cf \ LVSSyncDaemonSwap::master \ IPaddr2::192.168.1.105/24/eth0/192.168.1.255
El ejemplo aquí presentado es para el nodo balanceador de carga 1 “loadb1”, para el balanceador de carga 2 solamente se sustituye la primera línea por loadb2. El siguiente archivo se crea digitando en consola:
gedit /etc/ha.d/authkeys
Agregamos el siguiente contenido:auth 3 3 md5 somerandomstring
Este archivo debe ser legible solo por el administrador del sistema (root), por lo tanto digitamos el siguiente comando en consola para conceder los permisos apropiados.
chmod 600 /etc/ha.d/authkeysConfiguración de Ldirector Ldirectord es el actual balanceador de carga. Ahora configuraremos ambos balanceadores de carga para que funcionen en la modalidad activa/pasiva, que significa que tenemos un balanceador de carga activo y el otro en espera activa en caso de que el balanceador activo falle. Esto lo hacemos creando el archivo de configuración de ldirectord el cual debe ser idéntico en ambos balanceadores de carga. Para la creación de dicho archivo digitamos lo siguiente:
gedit /etc/ha.d/ldirectord.cfAgregamos el siguiente contenido al archivo:
checktimeout=10 checkinterval=2 autoreload=no logfile="local0" quiescent=yes virtual=192.168.1.105:80
real=192.168.1.101:80 gate real=192.168.1.102:80 gate fallback=127.0.0.1:80 gate service=http request="ldirector.html" receive="Test Page" scheduler=rr protocol=tcp checktype=negotiate
En la línea de “virtual” ponemos la dirección IP virtual en este caso la 192.168.1.105, y en “real” las direcciones IP correspondientes a cada uno de los balanceadores de carga, en “request” se pone el nombre del archivo que se encuentra en los nodos servidores web 1 y 2 al que se realizaran peticiones repetidamente para verificar si ambos servidores web están todavía activos. Luego creamos el sistema de enlaces de punto de partida para heartbeat y removemos estos de ldirectord porque ldirectord será iniciado por el demonio heartbeat. Para llevar a cabo esta acción digitamos lo siguiente en consola:
update-rc.d heartbeat start 75 2 3 4 5 . stop 05 0 1 6 . update-rc.d -f ldirectord remove
Finalmente iniciamos heartbeat: cd /etc/init.d/ ldirectord stop /etc/init.d/heartbeat start
-
- Configuración de Nodos Apache
- - Instalación de LAMP
Instalación del servicio web, utilizaremos LAMP server (Apache2, mysql,php) Para la instalación utilizaremos Synaptic.
> Sistema >Administración > Gestor de paquetes Synaptic
Luego dentro de synaptic > Editar > Marcar paquetes por tarea... Seleccionamos LAMP server Ahora buscamos phpmyadmin y lo seleccionamos. Después de esto solo le damos aplicar y ya tendremos instalado el servicio.
- - Configuración de la IP virtual
- Finalmente debemos configurar los nodos servidores con el servicio apache disponible de nuestro cluster que aceptaran las peticiones en que llegan a través de la dirección IP virtual.
Para llevar a cabo tal tarea seguimos los siguientes pasos en ambos nodos servidores, digitando en consola los comandos indicados a continuación:
apt-get install iproute
Ahora agregamos lo siguiente al archivo sysctl.conf, digitando en consola lo siguiente:gedit /etc/sysctl.conf
y copiar el siguiente contenido al archivo:
# Enable configuration of arp_ignore option net.ipv4.conf.all.arp_ignore = 1 # When an arp request is received on eth0, only respond if that address is # configured on eth0. In particular, do not respond if the address is # configured on lo net.ipv4.conf.eth0.arp_ignore = 1 # Ditto for eth1, add for all ARPing interfaces #net.ipv4.conf.eth1.arp_ignore = 1 # Enable configuration of arp_announce option net.ipv4.conf.all.arp_announce = 2 # When making an ARP request sent through eth0 Always use an address that # is configured on eth0 as the source address of the ARP request. If this # is not set, and packets are being sent out eth0 for an address that is on # lo, and an arp request is required, then the address on lo will be used. # As the source IP address of arp requests is entered into the ARP cache on # the destination, it has the effect of announcing this address. This is # not desirable in this case as adresses on lo on the real-servers should # be announced only by the linux-director. net.ipv4.conf.eth0.arp_announce = 2 # Ditto for eth1, add for all ARPing interfaces #net.ipv4.conf.eth1.arp_announce = 2
Para comprobar configuración digitamos lo siguiente:
sysctl –p
Agregar la siguiente sección para la dirección IP virtual a /etc/network/interfaces en ambos servidores, digitando la siguiente linea en consola:gedit /etc/network/interfaces
Agregamos el siguiente texto:auto lo:0 iface lo:0 inet static address 192.168.1.105 netmask 255.255.255.255 pre-up sysctl -p > /dev/null
Entonces ejecutamos lo siguiente en ambos servidores:
ifup lo:0
Configuración de pagina de prueba Finalmente debemos crear el archivo ldirector.html. en ambos nodos servidores. Este archivo es invocado repetidamente por ambos nodos balanceadores de carga de esta manera pueden ver si ambos nodos Apache están corriendo. Para crear el archivo digitamos lo siguiente en consola de ambos servidores apache:gedit /var/www/ldirector.html
y escribimos un texto de prueba:
Test Page
-
- Pruebas de funcionamiento
-
- Después de las configuraciones probaremos que tanto los balanceadores de carga como los servidores web estén funcionando correctamente.
- Pruebas de balanceadores de carga
Para las pruebas de funcionamiento de los balanceadores de carga lo aremos en base a valores esperados de comandos de comprobación del estado del servicio.
ip addr sh eth0
El balanceador de carga activo debe mostrar la lista de dirección IP virtual (192.168.1.105 en este caso) por ejemplo:
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:16:3e:40:18:e5 brd ff:ff:ff:ff:ff:ff inet 192.168.0.103/24 brd 192.168.0.255 scope global eth0 inet 192.168.0.105/24 brd 192.168.0.255 scope global secondary eth0
Balanceador de carga en espera-activa debe mostrar lo siguiente:
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:16:3e:50:e3:3a brd ff:ff:ff:ff:ff:ff inet 192.168.0.104/24 brd 192.168.0.255 scope global eth0
ldirectord ldirectord.cf status
La salida en el balanceador de carga activo debe ser: ldirectord for /etc/ha.d/ldirectord.cf is running with pid: 1455
La salida en el balanceador de carga en espera-activa: ldirectord is stopped for /etc/ha.d/ldirectord.cf
ipvsadm -l -n
La salida en el balanceador de carga activo tendría que ser: IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.105:80 rr
-> 192.168.1.101:80 Route 0 0 0 -> 192.168.1.102:80 Route 0 0 0 -> 127.0.0.1:80 Local 1 0 0
La salida en el balanceador de carga en espera-activa es: IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
/etc/ha.d/resource.d/LVSSyncDaemonSwap master status
La salida en el balanceador de carga es: master running (ipvs_syncmaster pid: 1591)
En el balanceador de carga en estado espera-activa seria: master stopped
Si después de las pruebas todas las salidas no han generado problemas los balanceadores de carga están trabajando correctamente
- Pruebas de Servidores WEB
La prueba de los servidores web se vuelve un poco más sencilla dado que solo se debe que comprobar que este escuchando la IP virtual por lo tanto al acceder a la IP virtual 192.168.1.105 desde el servidor debe mostrar su propia página predeterminada por apache.
- Pruebas de alta disponibilidad del cluster
-
- Para efectos de verificar en todo el tiempo cual de los servidores esta dando el servicio en la pagina de prueba estará reflejado en que servidor se esta ejecutando y desde el lado del el cliente se accederá al servicio siempre por la IP virtual 192.168.1.105.
1. Fallo de un servidor WEB
- Cuando falla un servidor WEB simplemente se sacara de la lista de servidores disponibles y el servicio quedara funcionando en el otro servidor WEB
2. Fallo de un balanceador de carga
- En el momento que falle el balanceador de carga activo el balanceador de carga pasivo tomara el rol de balanceador de carga activo siendo el que redirigirá el trafico de la IP virtual.
3. Fallo de un servidor WEB y un Balanceador de carga
- Se combinan las situaciones 1 y 2 por lo que se sacara el servidor WEB de la lista y al balanceador pasivo pasa a estado activo.
4. Fallo de los dos servidores WEB
- Al no quedar servidor WEB activo pasa el balanceador activo a tomar el papel de servidor WEB de respaldo y de nodo balanceador.
5. Fallo de los dos servidores WEB y un balanceador de carga
- Este es el punto crítico de la alta disponibilidad pues no existen más posibilidades de tolerancia a fallas pues solo queda el balanceador como servidor de respaldo
Categoría: Wikipedia:Trasladar a Wikilibros
Wikimedia foundation. 2010.