![[Top bar]](../../common/images/Topbar-es.gif){kind=small}
![[Bottom bar]](../../common/images/Bottombar-es.gif){kind=small}
| Este artículo está disponible en los siguientes idiomas: English Castellano Deutsch Francais Nederlands Turkce |
![[Photo of the Author]](../../common/images/Atif-Ghaffar.jpg)
por Atif Ghaffar Sobre el autor:
Atif es un camaleón. Cambia su papel de administrador de sistemas a
programador, a formador, a jefe de proyecto, o a lo que haga falta
para hacer el trabajo. Contenidos:
|
Resumen:
A la hora de diseñar sistemas para misiones críticas, ya sea durante el desarrollo o mientras se construyen físicamente con procesadores, cables, etc., uno debe hacerse las siguientes preguntas:
Por otra parte, cuando me pregunto "¿Fallará el Sistema Operativo?" obtengo
siempre esta respuesta: No. No estamos ejecutando extensiones de
32 bits para un sistema parcheado para 16 bits de un sistema
operativo de 8 bits originalmente diseñado para un microprocesador de
4 bits, que no aguantaría una competición de 1 bit.
(obtuve esto del .sig de un correo)
Ahora abordaremos una discusión en profundidad.
Aunque confío en Linux ciegamente, no confío tanto en las empresas que hacen las máquinas, las fuentes de alimentación, las tarjetas de red, las placas base, etc., y siempre me preocupa porque, si alguno de ellos falla, mi sistema no será usable y, por tanto, sus servicios no estarán disponibles. Más aún, habré arrastrado todos los servicios de la compañía, aunque ellos no dependan directamente de mí. Por ejemplo
En una de las compañías para las que trabajé, el servidor NFS proporcionaba
datos a un servidor web corporativo, al servidor de intranet, al servidor
de bases de datos, y a muchos otros servicios que harían pararse la compañía.
In one of the companies I worked for, the NFS server was
feeding data to a corporate web server, Intranet server, database
server, and many other services that will bring the company to a
halt. Cierto que NFS era una mala elección, pero olvidemos eso para simplificar
el ejemplo. Este servidor proporcionaba alta disponibilidad usando la solución
para clusters de Sun, que te costaría ambos brazos y piernas. Y otro de los
servicios de mayor importancia era la intranet, usada por más de 1500 personas.
Discutamos en concepto con una cierta profundidad.
Alta Disponibilidad es aquello que tú digas que es. Algunas cosas que precisan alta disponibilidad son algunos servicios que hacen que tu empresa pueda funcionar:
Estos servicios pueden fallar por dos motivos
En este ejemplo vamos a construir un cluster Activo/Pasivo en el que corre un apache, que sirve la intranet. Para ello, usaremos una máquina potente, con montones de RAM y muchas CPU, y otra tan sólo con lo necesario para proporcionar el servicio en cuestión. La primera máquina será el nodo maestro, mientras que la segunda será el nodo de respaldo. El trabajo del nodo de respaldo es hacerse cargo de los servicios del nodo maestro si cree que dicha máquina no está respondiendo.
Pensemos como los usuarios acceden a la intranet. Escriben http://intranet/ en
su navegador web, y el servidor DNS los redirije hacia 10.0.0.100 (por ejemplo).
Podemos colocar dos servidores corriendo el servicio de intranet con diferentes
direcciones IP, y simplemente hacer que el servidor DNS redirija hacia el respaldo
si el nodo maestro se va abajo. Ciertamente esa es una posibilidad, pero hay
algunos detalles como los caches de los clilentes, los ficheros /etc, y que tal
vez quieras corres el mismo servidor DNS en alta disponibilidad.
Otra posibilidad es que, si el nodo maestro falla, el respaldo asuma su dirección
IP y pase a ser él quien atienda las peticiones. Este método se conoce como
IP takeover, y es el que usaremos en los ejemplos. De esa forma los
navegadores seguirán accediendo a http://intranet/, que será traducido a
10.0.0.100 si el nodo maestro falla, sin necesidad de hacer cambios en el DNS
¿Cómo pueden un nodo saber que su compañero ha fallado?
Cada uno de ellos habla con el otro a través de un cable serie y
mediante un cable ethernet (por redundancia, los cables pueden fallar)
y se comprueban mutuamente los latidos. Como los que tenemos todos)
Si el latido para, probablemente estás muerto. El programa que
monitoriza los latidos se llama, adivinemos ..., hearthbeat (latido en
inglés), y está accesible en http://www.linux-ha.org/download/
El programa que realiza la suplantación de IP (el IP takeover)
se llama fake, y está integrado dentro de hearthbeat.
Si no dispones de una tarjeta de red extra para colocar en ambas máquinas,
puedes ejecutar heartbeat únicamente sobre un cable serie (modem nulo).
Aunque las tarjetas de red son baratas, por lo que conviene instalarlas
para obtener redundancia.
Como dijimos más arriba, usaremos una máquina potente, y otra no tanto.
Ambas máquinas están equipadas con dos tarjetas de red cada una, y al menos
un puerto serie. Necesitaremos un enlace cruzado RJ45 (ethernet) de categoría 5
y un cable modem nulo (cable serie para enlace cruzado).
Usaremos la primera tarjeta de red en cada máquina para sus direcciones IP
(eth0), y la segunda para la red privada que se encargará del latido (eth1),
y daremos a cada máquina sus nombres y direcciones IP. Por ejemplo, eth0
será en cada nodo
clustnode1 con direccion IP 10.0.0.1
clustnode2 con direccion IP 10.0.0.2
Ahora reservaremos una dirección IP para uso flotante, que será la IP del servicio
del que hablábamos antes, y será 10.0.0.100 (con nombre intranet). De momento no
la asignaremos a ninguna máquina.
A continuación configuramos la tarjeta de red secundaria en ambas máquinas,
otorgándoles direcciones IP en un rango fuera de uso. Por ejemplo, usaremos como
máscara 255.255.255.0, y daremos a cada una de las tarjetas las direcciones
clustnode1 dirección IP 192.168.1.1
clustnode2 dirección IP 192.168.1.2
Continuamos conectando el cable serie a los puertos serie de las máquinas, y
asegurándonos de que se ven mutuamente. Si nos aseguramos de que lo conectamos
al mismo puerto en ambas máquinas todo será mucho más fácil.
Podemos consultar
http://www.linux-ha.org/download/GettingStarted.html
Instalar el software es bastante directo. heartbeat está disponible como paquete rpm y en formato tar.gz, tanto en forma binaria como en fuentes. Si experimentas problemas durante la instalación, entonces probablemente no debas asumira la responsabilidad de instalar un sistema de Alta Disponibilidad. Hay una excelente guía Primeros pasos con Linux-HA de modo que no voy a repetir aquí esa misma información.
Configurando el latido
Si tenemos los ficheros de configuración de heartbeat en /etc/ha.d, editamos
el fichero /etc/ha.d/authkeys con nuestro editor favorito
#/etc/ha.d/authkeys auth 1 1 crc #end /etc/ha.d/authkeys
debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 deadtime 10 serial /dev/ttyS3 #change this to appropriate port and remove this comment udp eth1 #remove this line if you are not using a second network card. node clustnode1 node clustnode2Y en /etc/ha.d/haresources
#masternode ip-address service-name clustnode1 10.0.0.100 httpdEsto define a clustnode1 como nodo maestro, de forma que si clustnode1 se va abajo clustnode2 tomará el servicio a su cargo, pero que cuando vuelva a estar disponible asumirá de nuevo el servicio. Este es el motivo por el cual usamos una máquina potente y otra de menor entidad (clustnode1 es la mejor). El segundo elemento define la dirección IP que se debe asumir para el servicio, y el tercero el nombre del servicio en cuestión. Cuando una máquina asume el servicio, intenta ejecutar
/etc/ha.d/httpd starty si no es posible intenta
/etc/rc.d/init.d/httpd startSi clustnode2 está dando el servicio, ejecutará
/etc/ha.d/httpd stopo bien
/etc/rc.d/init.d/httpd stopCuando acabamos la configuración de clustnode1 podemos copiar los ficheros al nodo de respaldo. En el directorio /etc/ha.d/rc.d encontraremos un script llamado ip-request, que hará el trabajo de asignar las direcciones IP y otras tareas. Ahora podemos arrancar /etc/rc.d/init.d/heartbeat en ambas máquinas.
Instalaremos una página de índice diferente en cada una de las máquinas que
harán de servidor http. Por ejemplo, en clustnode1
echo hello world from clustnode1 >/yourWwwDocRoot/index.html
y enclustnode2
echo hello world from clustnode2 >/yourWwwDocRoot/index.html
Debemos asegurarnos que en ninguno de los nodos se inicia el servidor http
al arrancar la máquina, eliminando los enlaces en los directorios rcN o,
mejor aún, moviendo los scripts de arranque "httpd" o "apache" de
/etc/rc.d/init.d/ a /etc/ha.d/rc.d/ en ambas máquinas.
Si todo se preparó correctamente y hearbeat está corriendo de forma correcta,
clustnode1 tendrá la dirección IP 10.0.0.100 y será el que responda a las
peticiones http. Podemos hacer un par de intentos para asegurarnos que
efectivamente lo hace. Si todo parece correcto, paramos clustnode1 y, en 10
segundos, clustnode2 asumirá el servicio y la dirección IP.
Es decir, el tiempo máximo fuera de servicio será 10 segundos.
Cuando el servicio httpd se mueve de un nodo a otro, no ve los mismos datos.
Pierdo todos los ficheros que estaba creando con los CGI's del httpd.
Hay dos respuestas para eso
Si dispones de un buen sistema de almacenamiento que permita acceso concurrente, resulta muy fácil construir un servidor activo/activo. Ejemplos son GFS y Fibrechannel. Si te bastan filesystems de red como NFS puedes usarlos, aunque yo no recomendaría hacerlo. En cualquier caso, siempre puedes eviar el servicio A a clustnode1 y el servicio B a clustnode2, como hace el fichero haresource
clustnode2 172.23.2.13 mysql clustnode1 172.23.2.14 ldap clustnode2 172.23.2.15 cyrusEn mi caso, usando GFS para almacenamiento, no existe problema con el acceso concurrente, y se pueden correr tantos servicios como sean capaces de manejar las máquinas. En la configuración anterior, clustnode2 es el master para mysql y cyrus, mientras que clustnode1 es el master para LDAP. Si clustnode2 cae, clustnode1 asume la dirección IP y los servicios.
|
|
Contactar con el equipo de LinuFocus
© Atif Ghaffar, FDL LinuxFocus.org Pinchar aquí para informar de algún problema o enviar comentarios a LinuxFocus |
Información sobre la traducción:
|
2001-07-02, generated by lfparser version 2.9
