Hogar  |  Mapa  |  Indice  |  Busqueda

Convert to GutenPalm or to PalmDoc por Atif Ghaffar <atif(at)developer.ch> Sobre el autor: 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 Taducido al español por: Quetzalcoatl Hernández Ortiz <quetzalcoatl(at)quetzalcoatl.org.mx> Javier Palacios <javier.pb(at)linuxfocus.org> Contenidos: Por que replicar en lugar de compartir? Manteniendo la sencillez Manteniendo la elegancia Que es FAM? Que es IMON? Instalando FAM e IMON Instalando el módulo perl SGI::FAM Replicación con fam_mirror Recursos Problemas conocidos Formulario de "talkback" para este artículo

Replicado de datos en tiempo real bajo Linux

Resumen:

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.

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?

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

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?

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

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á un modulo perl llamado SGI::FAM, para construir nuestro propio gestor de eventos en perl.

Instalando el módulo perl SGI::FAM

No creeríais que íbamos a hablar de escribir código 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

Replicación con fam_mirror

fam_mirror es un script que escribí para automatizar la replicación. 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áquinas 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áquinas es /var/www, y rsh o ssh estan disponibles en ambas máquinas. web2 debe permitir a web1 ejecutar comandos remotos sin password. Yo suelo añadir mi clave ssh al authorized_keys de la máquina de réplica. 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én 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

• El sitio web de fam en SGI
• El módulo perl SGI::FAM
• Replicacion de datos en tiempo real (WEBD y SLIM) para IRIX
• fam_mirror

Problemas conocidos

Descubrí que la solución que presentamos aquí tiene un pequeño 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ñadiré la información a este artículo.
Si alguien conoce una solución para este problema, que me avise.

Formulario de "talkback" para este artículo

2002-05-07, generated by lfparser version 2.21

mirror server hosted at Truenetwork, Russian Federation.