15 de Noviembre, 2008

Alta disponibilidad y balanceo de carga

Me ha tocado reimplementar un proyecto de alta disponibilidad con balanceo de carga para un cluster de un cliente, que aloja una plataforma de e-learning. En la primera aproximación que realizó un compañero no ha dado buenos resultados, y como ahora el responsable de sistemas de ese proyecto está desplazado a un cliente, soy yo el nuevo responsable ;).

Consideraciones aparte sobre marrones heredados, me he encontrado con muchas cosas nuevas. Nuevas porque nunca había trabajado con heartbeat versión 2, y nunca había tenido que enfrentarme a un problema de alta disponilidad activo/activo.

Alta disponibilidad

Diseño de dos niveles
Diseño del cluster

El concepto de alta disponibilidad de un servicio se refiere a la implementación mediante dos o más máquinas de dicho servicio de forma que aseguremos, mediante mecanismos de monitorización, que el trabajo no se interrumpa en caso de fallo.

La idea del diseño inicial, que he decidido mantener, es tener dos niveles:

  • Frontales: que sirven la aplicación, en este caso web.
  • Almacenamiento: que mantiene la base de datos.

Es una configuración muy habitual: tenemos dos máquinas con servidores Apache como frontales, y dos máquinas con MySQL preparados como maestro/esclavo para que el secundario replique las operaciones que se lleva a cabo en el principal.

La parte del almacenamiento tiene sus propias particularidades, pero en general se soluciona con los mecanismos de replicación de MySQL, y además hablamos de una estrategia activo/pasivo (resumiendo: hay un servicio principal y otro que se encarga de replicar contenido para tomar su lugar en caso de fallo).

Nuestro principal problema han sido los frontales, que son activo/activo, es decir: ambos son servicios principales y uno se vigila al otro para tomar el control cuando sea necesario.

En el caso de la aplicación que estamos sirviendo (la plataforma de e-learning Dokeos), tenemos un problema con el esquema activo/activo: si ambos frontales están sirviendo datos a la vez, es posible que se modifiquen ficheros en ambas máquinas, produciendo inconsistencias.

Por lo tanto es necesario implementar algún tipo de replicación de almacenamiento para el disco que almacena la web, de forma que los dos frontales cuenten con una copia perfectamente sincronizada de los datos.

La primera aproximación de mi compañero fue emplear GlusterFS, que en el papel tiene muy buena pinta y hay diferentes casos de éxito interesantes. Pero algo en nuestra implementación no debe funcionar bien, porque el acceso a disco del directorio compartido es muy lento (y es lo que ha hecho que yo tenga que reimplementar cosas :P).

No hemos llegado a sacar una conclusión que me guste y que explique de forma inequívoca dónde está nuestro problema, pero algunas pistas podrían ser:

  • El disco compartido es muy grande: hablamos de 130GB, y puede que eso afecte al rendimiento de gluster. Pero puede que no.
  • En un principio (parece) que no trabajábamos con el módulo de fuse parcheado expresamente para gluster, y algunas llamadas POSIX al sistemas de ficheros no se comportaban como se esperaba. Con el módulo correcto, ejecutar du sobre el disco compartido con 3.5GB en datos tarda 1m26.452s, en un directorio local con el mismo contenido tarda solo 0m0.366s.
  • Del punto anterior se puede desprender que, al trabajar con muchos ficheros pequeños (¡es una web!), fuse no nos está dando un buen rendimiento (sí, gluster se implementa con fuse :S).

En realidad ya tiene poca importancia, porque hemos decidido desechar gluster por esta vez.

Heartbeat + DRBD + NFS = HA activo/activo

Esta es la fórmula que me ha tenido un par de días muy entretenido :D.

Mi propuesta es usar heartbeat para la monitorización, DRBD para replicar el almacenamiento y NFS para esquivar una limitación de DRBD que no nos permite tener acceso al disco compartido en los dos frontales. Con esto conseguimos alta disponibilidad (aka HA) con ambos frontales activos.

Esta solución se implementa con cierta frecuencia, y está muy probada (DRBD es un proyecto bastante maduro).

Voy a intentar ordenar un poco mis ideas para poder explicar en los próximos días todo lo que he aprendido y cómo ha quedado al final el invento :), que aún me falta hacer pruebas antes del paso a producción.

Anotación por Juan J. Martínez, clasificada en: linux.

Hay 1 comentario

Gravatar

hola,
yo implemente algo parecido
te recomiendo como sistema de Archivos
OCFS (Oracle cluster file system).
Yo utilize
S.O Debian Sarge.
BD Mysql 4.x
OCFS como sistema de Archivo
DRBD para la replicacion
Saludos.

por Alexis, en 2008-11-17 16:51:12

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.

Algunas anotaciones relacionadas: