Replicado de datos en tiempo real bajo Linux

ArticleCategory: [Choose a category for your article]

System Administration

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author and translation history]

original in en Atif Ghaffar
en to es Quetzalcoatl Hernández Ortiz
en to es Javier Palacios

AboutTheAuthor:[A small biography about the author]

Atif es un camaleón. El cambia sus papeles, de administrador de sistemas, a programador, a maestro, a líder de proyecto, a lo que sea que se requiera para dejar el trabajo hecho.
Atif piensa que debe mucho a Linux, a la comunidad del software libre y a los proyectos en los que ha sido maestro
Mas acerca de el puede encontrarse en su página personal

Abstract:[Here you write a little summary]

En este articulo vamos a explorar la replicacion de datos en tiempo real bajo Linux sin usar costosos SANS (Área de Depósito en Red o Storage Area Network, por ejemplo GFS) o cualquier otro dispositivo de bloques en red.
Usaremos FAM e IMON para nuestro sistema de replicacion FAM (Monitor de Alteracion de Archivos o File Alteration Monitor ) e IMON (Monitor de Inodos o Inode Monitor) han sido desarrollados por SGI originalmente para IRIX.
Los muchachos de SGI han sido muy amables al portarlo a Linux y hacerlo open source.
Cuando el costo no es una preocupación, Yo me inclinaria por un GFS (Global File System) y soluciones basadas en SAN, pero cuando el costo es un factor, y el compartir datos es necesario no quedan muchas opciones para tomar. En este articulo las discutiremos y veremos sus ventajas/desventajas.

ArticleIllustration:[This is the title picture for your article]

ArticleBody:[The article body]

Por que replicar en lugar de compartir?

No se supone que los sistemas de archivos hacen los datos disponibles para los clientes?
Si, si lo hacen.

Si usamos un servidor que comparte archivos mediante NFS o SMB, entonces tenemos un cuello de botella y un Punto único de falla .

Si compartimos datos mediante GFS con un depósito compartido (SAN o SCSI multicanal), tenemos que la máquina depósito es el Punto único de falla y es muy caro *echar a andar* un sistema con esa configuracion.

Podemos usar NBD (Dispositivos de Bloque en Red o Network Block Devices) para *echar a andar* un espejo de red, pero no yo no estoy muy a gusto con eso. Los NBDs tienen sus limitaciones, son difíciles de *echar a andar* y administrar y con simplemente demasiado *bother*, cuando todo lo que necesitas es replicar datos de unos pocos servidores web a otros pocos servidores web.

Manteniendo la sencillez

Bien, tratemos de replicar.
He aquí un escenario:

Tu tienes 2 servidores web, uno es el servidor principal y el otro actua como reserva.
Tu haces todos los cambios en la máquina maestra y sincronizas los cambios mediante rsync con la segunda máquina.
Sencillo?

Pero ahora, como automatizarlo? Tus usuarios van entrar mediante FTP a la máquina maestra varias veces al dia. Que pasará si tiene lugar una falla en el servidor maestro y el servidor de reserva entra en acción?

Fácil. Tengo la respuesta para eso. Ellos no van a ver los cambios que han hecho, y van a estar bastante enojados. :)
Bueno, puedes usar "rsync -av --delete origen destino" desde CRON cada 5 segundos, pero entonces tu máquina no será realmente usable para nada mas, *o lo será*?

Aqui está otro escenario

Tu tienes un servidor FTP para subir los datos y
seis servidores web que responden en una forma de round robin.
De modo que los datos en cada máquina deben ser los mismos. Tu puedes hacer eso con NFS por algun tiempo si tienes suerte, pero no lo querras por mucho.

Ahora, que debemos hacer?
Yo creo que la respuesta es "copiar los datos a los servidores web únicamente si hay algun cambio en los archivos" y, si no hay cambio en los datos, no hacer nada.

Esto es exactamente lo que haremos usando "fam".

Manteniendo la elegancia

Así que como vamos a saber que hay algun cambio en los archivos?
Esta es una respuesta que yo esperaría de un desarrollador de M$ Windows.
Podemos explorar el directorio que queremos monitorear cada pocos segundos y comparar sus fechas y tamaños con la versión que tenemos en el caché.

Polling: vigilar las fechas/tamaños de los archivos y compararlos con la version antigua es costoso.
Imagina que tu máquina está corriendo "ls -lR /algundirectorio" cada 5 segundos en tu servidor web :)

La manera elegante es que el archivo nos diga cuando ha cambiado, así podemos tomar una acción al respecto.
Esto es exactamente lo que "IMON" va a hacer por nosotros.

Que es FAM?

fuente: http://oss.sgi.com/projects/fam/faq.html
fam, el Monitor de Alteracion de Archivos, provee un API que las aplicaciones pueden usar para ser notificadas cuando archivos o directorios específicos han cambiado. FAM viene en dos partes: fam, el *demonio* que escucha las peticiones y envia las notificaciones, y libfam, una libreria que la aplicacion cliente puede usar para comunicarse con FAM.

Si los archivos monitoreas estan montados en una máquina remota, el fam local tratará de contactar al fam de la otra máquina, y pasará las peticiones al fam remoto
fam puede también notificar a sus clientes cuando un archivo inicia y termina su ejecución. (El Escritorio Interactivo de IRIX usa esto para cambiar el ícono de un programa cuando está corriendo, por ejemplo).
fam fué originalmente escrito para IRIX en 1989 por Bruce Karsh, y fué reescrito en 1995 por Bob Miller. Esta *open-source release* de fam está construida y corre en ambos Linux e IRIX, y es el mismo fam que fué incluido en IRIX 6.5.8.

Que es IMON?

fuente: http://oss.sgi.com/projects/fam/faq.html
imon, el Monitor de Inodos , es la parte del kernel que le dice a fam cuando un archivo ha cambiado. Cuando las aplicaciones le dicen a fam que estan interesadas en archivos o directorios, fam pasa esos intereses a imon. Cuando operaciones de archivos son *performed* a los archivos monitorizados por imon, el kernel le dice a imon, imon le dice a fam, y fam notifica a las aplicaciones interesadas en los archivos.
imon fué originalmente escrito para el kernel de IRIX en 1989 por Wiltse Carpenter; el porte a Linux fué hecho por Roger Chickering. La implementacion en linux del parche al kernel es similar a la implementacion en IRIX en *most* formas, pero esto *hooks* en el código de lsistema de archivos del kernel diferente.

Instalando FAM e IMON

Tanto FAM como IMON estan disponibles en el sitio web de SGI (ver en recursos). IMON es un parche que hay que aplicar al kernel, y que hace posible que nuestro kernel pueda monitorizar inodos. Para parchear el kernel, cambia al directorio con las fuentes del kernel, y aplica el parche

cd /usr/src/linux
patch -pi < patchfile

para luego ejecutar make config o make menuconfig, recordando seleccionar Inode Monitor (imon) support (EXPERIMENTAL) en la seccion de Sistemas de Ficheros. Luego compilamos el kernel y rebotamos (no hay mas remedio).

Compilar FAM es bastante simple. Cambiamos al directorio con las fuentes de fam y, como siempre, ./configure && make all install
Voila! Ya está instalado.
Lo siguiente que instalaremos ser'a un modulo perl llamado SGI::FAM, para construir nuestro propio gestor de eventos en perl.

Instalando el módulo perl SGI::FAM

No creer'iais que 'ibamos a hablar de escribir c'odigo C/C++, '?verdad?
No se vosotros, pero yo soy demasiado perezoso e impaciente, por lo que escribire mi manejador para replicaciones en perl. Descargamos e instalamaos SGI::FAM, de Jesse N. Glick. Para instalarlos, simplemente ejecutamos

perl -MCPAN -e shell
install SGI::FAM

con lo que obtenemos tango el SGI::FAM como todos sus requisitos.

Replicaci'on con fam_mirror

fam_mirror es un script que escrib'i para automatizar la replicaci'on. Puedes verlo o descargarlo. Puedes editarlo y modificar $replicaHosts para adaptarlo a tus necesidades, chambiar $rsh por el comando que uses para ejecutar de forma remota, al igual que $rsync.

Volvamos al escenario 1
2 m'aquinas corriendo servidores web (web1, web2), uno de ellos como master (web1) y el otro como esclavo (web2). El servidor FTP primario es web1. web2 no corre ningun tipo de FTP, ya que de otra forma los usuarios podrian intentar escribir incluso cuando el sistema esta en modo backup. El document root en ambas m'aquinas es /var/www, y rsh o ssh estan disponibles en ambas m'aquinas. web2 debe permitir a web1 ejecutar comandos remotos sin password. Yo suelo a'nadir mi clave ssh al authorized_keys de la m'aquina de r'eplica. Sincronizamos todos los datos de web1 a web2:
rsync -avz /var/www/ web2:/var/www/
Editamos fam_mirror y cambiamos replicaHosts a @replicaHosts=qw(web2) y ejecutamos fam_mirror en web1:
fam_mirror /var/www &
Y ya podemos cambiar ficheros en web1. Todos los cambios seran realizados tambi'en en web2.

Now to scenario 2 (A farm of webservers)
Hosts "linuxweb1", "linuxweb2", "linuxweb3" and "linuxweb4" runs as webservers
Host "linuxftp1" runs as ftp server (main fileserver)
web hosts do not allow FTP to users.
install fam, imon, SGI::FAM and fam_mirror on host "linuxftp1"
Setup rsh or ssh between the machines.
hosts linuxweb[1-4] should allow linuxftp1 to run remote commands without prompting for a password.
Edit fam_mirror and set @replicaHosts to
@replicaHosts=qw(linuxweb1 linuxweb2 linuxweb3 linuxweb4);
Change $rsh and $rsync if neccessary. Assuming that web document root is /var/www on all machines.
run on linuxftp1
INIT_MIRROR=1 fam_mirror /var/www &

Now all changes on linuxftp1 should be visible on linuxweb[1-4]

Recursos

Problemas conocidos

Descubr'i que la soluci'on que presentamos aqu'i tiene un peque'no problema: no funciona con directorios grandes (con 4000-5000 subdirectorios). El kernel se queja de problemas con kmalloc y otras cosas. Estoy intentando sortear el problema, y una vez que lo consiga, a'nadir'e la informaci'on a este art'iculo.
Si alguien conoce una soluci'on para este problema, que me avise.