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


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.conf

Para 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 2

Para 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/authkeys

Configuració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.cf

Agregamos 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

Wikimedia foundation. 2010.

Игры ⚽ Поможем сделать НИР

Compartir el artículo y extractos

Link directo
Do a right-click on the link above
and select “Copy Link”