Bitácora de PSI.: Alta Disponibilidad et al.

No entraré en cuestiones que quedan muy bonitas en la teoría pero que para nuestra operativa profesional no nos van a aportan muchas soluciones, como lo que pueda ser o dejar de ser un sistema tolerante a fallos o un sistema de alta disponibilidad, así como sus sutiles diferencias. En pocas palabras, la Alta Disponibilidad, High Availability (HA), hace referencia a las instalaciones pensadas para "garantizar" un servicio eficiente durante los 525600 minutos del año. Como nota adjunta, señalar la posibilidad de mantener las conexiones y recuperar las sesiones en entornos de alta disponibilidad con persistencia.

Cuando hablamos de clusters siempre pensamos en un grupo o "pandilla" de equipos que, por un motivo u otro, tienen una cierta e "íntima" relación. En cuanto a pandillas, las hay de muchos tipos.

Los clusters para procesamiento de datos constituyen una potente herramienta en tareas que requieren de una gran potencia de cálculo. Aunque en un primer momento se podría pensar en temas de edición de vídeo y rendering, cálculo científico intensivo, etc., en nuestro caso iríamos más bien hacía el cómputo al servicio de los ataques por (pseudo)fuerza bruta. Entre las soluciones disponibles para este tipo de clusters destacar el proyecto Beowulf y Mosix, aunque no tienen un gran interés en nuestro ámbito de actuación.

Otro tipo de clusters estaría orientado a la redundancia de máquinas proporcionando el mismo servicio. Recuerda que la redundancia es un mecanismo de seguridad. De esta forma, nos protegeremos contra posibles fallos del servicio y, o, máquina, además de incrementar la potencia en la prestación del servicio.

En este tipo de instalaciones deberemos plantearnos una serie de tareas, como el control de los computadores del cluster, la monitorización de servicios y su replicación, las comunicaciones y, pensando en sistemas que proporcionan un mismo servicio, la forma de compartir el almacenamiento.

En cuanto al almacenamiento existen varias posibilidades que, en gran medida, estarán en función de los €s disponibles. No debemos olvidar que el factor económico tiene que ser uno de los principales en toda toma de decisión y que bajo ningún concepto "debemos matar usuarios a cañonazos", aunque siempre habrá capullos dispuestos a "matar hippies en la Cíes". El actual despliegue de cañones en nuestra profesión empieza a apestar. Sin duda alguna es el momento de volver al camino de la búsqueda de la sencillez para evitar ???. Recuerdo la semana que pasé impartiendo clase en cierta universidad de un pequeño pero gran país en el que un joven con una creatividad asombrosa proporcionaba servicio de correo electrónico y web a toda la organización con un único PC. De vuelta al contexto de nuestro desarrollo, se podría plantear desde servidores de disco en red sobre NFS (Network File System) o Samba, hasta soluciones de almacenamiento SAN (Storage Area Networks). También otras alternativas como la mera sincronización de dispositivos de almacenamiento, por ejemplo con un rsync (dependiente del entorno de trabajo), el exportado de disco cifrado mediante sshfs (Secure Shell File System), o el uso de sistemas de ficheros distribuidos como GFS (Global File System) o MogiFS.

Por su parte, la detección de servicios deberá encargarse de identificar si están "caídos". De la misma forma habrá que monitorizar si un determinado host está o no operativo. Aunque hay distintas soluciones únicamente incluiremos en este punto mon, para la monitorización de servicios, y heartbeat para la interrogación entre hosts. El proceso de monitorización deberá hacerse en la capa 7 por razones obvias (si, esas con las que nos han torturado a tantos y tantos estudiantes de informática a lo largo de los años). Y, dado que estamos en PSI, sería muy aconsejable que toda comunicación estuviese cifrada adecuadamente. También podremos incluir redundancia parcial en nuestros equipos, por ejemplo de fuente de alimentación, tarjetas de red, controladoras de disco, etc.

En cuanto a soluciones, aunque existen varias, únicamente incluiré el Proyecto Linux Virtual Server (LVS). De forma resumida, instalaremos un conjunto de sistemas en el que un balanceador de carga, que podría redundarse según las necesidades, constituirá el elemento de interacción con cualquier petición de servicios. El balanceador deberá re-direccionar las peticiones a los servidores según unos criterios que "parezcan" medianamente inteligentes (carga de los servidores, anchos de banda, con persistencia, o por cualquier ecuación que pueda integrar de una forma más o menos ponderada diversos parámetros característicos de carga, entre otras). Los servidores podrán atender directamente las peticiones o utilizar el balanceador como un proxy. Recuerda que los "cuellos de botella" son nuestros enemigos. Señalar en este punto la existencia de dispositivos orientados al balanceo de carga. Aunque no soy muy amigo de refernciar soluciones comerciales, en este caso haré una excepción con los balanceadores de carga barracuda para que el alumno tenga referencia de la existencia de este tipo de productos. Obviamente existen otras muchas alternativas.

Sobre la naturaleza del balanceo, podrá plantearse a nivel IP, característico del LVS, o a nivel de aplicación-servicio, mediante el uso por ejemplo de reverse-proxy (cuyo nombre es autoexplicativo). Apache dispone de distintos módulo para implementar reverse proxy.

El servicio de DNS (Domain Name System) nos puede proporcionar una alternativa básica al balanceo de carga y que no requiere "grandes" desplieges. En pequeñas instalaciones esta podría ser una opción aceptable. Los servidores DNS de nuestro dominio responderán a las peticiones hacia el servidor de referencia con una relación de IPs, normalmente mediante un round-robin. Como es obvio, esta solución no contemplará la carga de los servidores, ni el ancho de banda estimado entre el cliente y los servidores que pueden atender su petición (de interés en el caso de clusters distribuidos geográficamente). En el caso de un servicio web, la dirección www.[nuestro-dominio] se resolvería cíclicamente mediante un round-robin sobre varias IPs. Como es obvio, será necesario incluir algún mecanismo que permita retirar una resolución ante una caída de un servidor. ¿Y si está "cacheada" en uno o más clientes?. La implementación en el caso de bind únicamente requerirá de varias entradas CNAME, por ejemplo.:

server1 IN A 193.144.48.10

server2 IN A 193.144.51.16

server3 IN A 193.144.63.83

www IN CNAME server1

IN CNAME server2

IN CNAME server3

Unido a la multitud de referencias en internet sobre configuración de clusters de HA, con o sin NAT, a nivel 2 o 3, etc., para los amantes de la literatura técnica en papel, esa que debería tender a su desaparición completa, señalar por ejemplo el artículo "Replicación y alta disponibilidad con pgpool II de PostgreSQL" del número 108 de la publicación Mundo Linux.

Entre las diversas herramientas con las que podremos "jugar", considerando que jugar es la mejor técnica para aprender, señalar ldirectord (para monitorización de servicios HTTP y HTTPS), heartbeat (para monitorización de equipos), o el entorno gráfico lvs-gui (para configurar un cluster LVS). Existen muchas otras opciones de HA y load balancing aunque esta entrada no tiene como objetivo tal revisión.

Al finalizar la clase se analiza la evolución en nuestros sistemas de información y servidores, desde los monoservidores, pasando por soluciones redundantes con o sin balanceo de carga a las configuraciones de servidores basados en la virtualización y para-virtualización. Finalmente vemos que las posibilidades que nos ha proporcionado el mundo de la virtualización y su aportación en el salto a lo que hoy se conoce como computación en la nube (ver por ejemplo simulador del IBMSmartCl​oud).
Juega aprendiendo y aprende jugando,