Diferencia entre revisiones de «Cluster de alta disponibilidad y espejo con Ubuntu 7.04»
Contenido eliminado Contenido añadido
Página reemplazada por « Game Over, estaba lleno de spam por todos lados y era un how to que no correspondía a wikipedia. Use gentoo fucking newbies». |
imported>AVBOT m BOT - Posible blanqueo de 190.64.7.184, revirtiendo hasta la edición 24870449 de Equi. ¿Hubo un error? |
||
Línea 1:
{{a Wikilibros}}
------------------------------------------------------------
'''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
| |||