General

Recapitulando escenarios de clusterización en Linux

Por allá en 2005, durante mi tiempo como consultor independiente, tuve mis primeras experiencias clusterizando servicios en Linux. Uno de los problemas que tuve para vender servicios clusterizados era la falta de experiencias documentadas en el área de servicios, y las percepciones sobre Linux siendo más capaz en el ámbito de clusterización de cómputo a nivel académico que en otros aspectos.

En 2006, cuando asumí una serie de responsabilidades en Electrificación del Caroní, ahora Corporación Eléctrica Nacional, tuve que ponerme la camiseta y empezar a evaluar ciertos escenarios de clusterización, que al final resultaron en un esquema geográficamente distribuido de servicios, tolerante a fallas y que provee servicios de calidad a una población de 8 mil usuarios y creciendo a varias decenas de miles con la integración a CORPOELEC.

Estos aprendizajes me permitieron luego, como CTO de una consultora inteacional, implementar modelos de clusterización adaptado a las necesidades de negocio de clientes en toda la región. Recientemente, un compañero de la comunidad de Linux de Paraguay me contactó pidiéndome mis opiniones sobre como hacer un cluster, y decidí recapitular aquí las alteativas.

Características del cluster

Lo primero que hay que preguntar es para qué se necesita el cluster, porque hay varias necesidades que se pueden cubrir sin necesidad de hacer un cluster. Por ejemplo, mucha gente quiere tener balanceo de carga en una aplicación Web, necesidad que se puede cubrir hoy en día con granjas de servidores y proxies reversos (para lo cual recomiendo nginx) a nivel del protocolo.

Otras personas pueden descubrir que el balanceo de carga más sencillo se logra con DNS round-robin, donde básicamente se agregan múltiples registros A para un host name, con el objeto de dejar en la pila de resolución DNS del sistema operativo de los clientes el trabajo de resolver y decidir a cuál equipo enviar las consultas.

Considere las siguientes características, y si realmente las necesita todas, entonces un cluster puede ser su solución:

  • Alta disponibilidad
  • Tolerancia a fallos
  • Balanceo de carga
  • Capacidad de cómputo distribuida
  • Almacenamiento compartido

Alta disponibilidad y tolerancia a fallos

Cuando se construye un cluster, se suele evitar que existan puntos únicos de falla. Estos puntos pueden estar presentes en el hardware o en el software, y en elementos activos o pasivos. Por ejemplo, un punto único de falla puede ser una conexión a fibra con un solo cable por cada servidor. O también puede ser un feature (o un bug) de la aplicación a clusterizar para manejar automáticamente casos de borde.

Un producto que suelo utilizar para cubrir esta necesidad es heartbeat. Es un producto maduro y estable, fácil de comprender y de configurar, que se encarga de mantener 2 o más servidores comunicados (idealmente a través de un canal independiente, como por ejemplo cables cross-over, o una red basada en Etheet con sus propios switches y múltiples cables) y de manejar servicios que los administradores del cluster han definidos como “altamente disponibles”.

Heartbeat incorpora características deseables como STONITH, que me permite hablar directamente con un regulador de voltaje, una toma multipuntos o incluso un UPS con el objetivo de “matar” a los nodos fallidos de forma definitiva (ya que solo hay algo peor que un cluster donde fallen los nodos, y eso sería un cluster donde fallen los nodos y vuelvan a la vida intermitentemente) y por supuesto Heartbeat se encarga de la parte sucia como hacer quorum entre los miembros para determinar si uno de los servidores está definitivamente desactivado.

Una estrategia para reducir puntos únicos de falla en la capa de red es utilizar channel bonding. Se trata de cargar un módulo del keel con parámetros para indicar el comportamiento deseado del bonding, y de configurar una nueva interfaz de red que se constituye de las interfaces “esclavas” tradicionales. Por ejemplo, bond0 puede ser una unión en failover de eth0 y eth1, o puede ser un agregado de ambos canales. El primer escenario, obviamente, es el que contribuye a la alta disponibilidad.

En cuanto a fibra óptica, que podemos utilizar usualmente para mirar los volumenes que presenta un arreglo de discos o una SAN, podemos utilizar multipath para garantizar que llegamos al dispositivo por múltiples caminos (múltiples cables, múltiples puertos)

Balanceo de carga y capacidad de cómputo distribuida

Además del mecanismo básico de DNS round-robin, hay veces donde no podemos confiar en que la resolución DNS del cliente sea óptima, o cuando tenemos alguna aplicación malvada que no soporta resolución DNS y debemos usar IPs directamente.

Aquí, Linux Virtual Server me ha ayudado muchísimo. Con LVS se pueden configurar “entry points” al cluster, que a su vez pueden ser otros LVS o usar DNS round-robin, o quizás distribución geográfica. Esos entry points distribuyen la carga a servicios UDP y TCP en múltiples servidores usando algoritmos que los administradores del cluster pueden seleccionar. También ofrecen herramientas para monitorizar la salud de la clusterización del servicio.

Una técnica interesante que he utilizado es la de “vistas” del DNS. BIND 9, de ISC, soporta esto. Con las vistas puedo tomar una misma zona (por ejemplo, empresa.int) y devolver respuestas distintas dependiendo del origen de la consulta. En una gran empresa, esto significa que puedo usar un mismo nombre de dominio en las aplicaciones (por ejemplo, correo.empresa.int) y que el DNS me devuelva los resultados correspondiente a los servidores lógicamente más cercanos (por ejemplo, caracas.correo.empresa.int, si la consulta vino de la subred de Caracas)

Obviamente, los servicios de LVS, así como los servicios finales que se van a clusterizar (OpenLDAP, Postfix, Apache, Dovecot, lo que usted quiera), pueden ser gestionados por Heartbeat.

Concurrencia y almacenamiento compartido

Sin embargo, no todas las aplicaciones son fácilmente clusterizables. Por ejemplo, una galería de fotos es fácil de clusterizar ya que puedo clusterizar HTTP (con Apache, por ejemplo) y puedo mantener manualmente al día la galería en ambos servidores. Pero esto me agrega complejidades administrativas, y no es cierto para todas las aplicaciones — imagine por ejemplo una aplicación Web con un servidor de bases de datos. Clusterizar la aplicación Web generará rápidamente inconsistencias en la base de datos.

Clusterizar bases de datos es un terreno específico y autocontenido, pero el estado del arte ha mejorado mucho en los últimos 5 años que empecé a tocar estos temas. Tanto PostgreSQL como MySQL ya tienen mecanismos avanzados en capa de aplicación para hacerlo (antes solo Postgres, y ha evolucionado mucho) y recomendaría considerar cosas como Slony en Postgres, o inclusive soluciones lógicas como rubyrep en bases de datos no muy complejas.

Lo que es más común es clusterizar el almacenamiento. Aquí hay tres escuelas: las que usan SAN, las que usan NAS, y las que usan el almacenamiento de cada servidor. En este último caso hay que recurrir a algún mecanismo de sincronización, que casi siempre es rsync. Es una solución realmente artesanal. SAN y NAS ofrecen distintas ventajas. Por ejemplo en SAN, es posible que yo cree sistemas de archivos que sean conscientes de que pertenecen a un cluster, como puede ser el Global File System de Red Hat, y es más elegante (nuevamente, es mi percepción) ya que, por ejemplo, utilizando fibra óptica (y multipath) puedo ver directamente los dispositivos de bloques en Linux, aunque tengo la certeza de que hay clusterización a nivel de bloque.

NAS, por otro lado, puede resultar mucho más sencillo de administrar. Simplemente elijo un protocolo, que usualmente es SMB/CIFS o NFS (y casi siempre se elige NFS) y empiezo a escribir allí. El aparato se
encarga de hacer arreglos de discos, manejar la redundancia, resistencia a fallos, entre otros. Obviamente, soluciones avanzadas en SAN y NAS me ayudan a evitar puntos únicos de falla en los discos, pero suele ser bastante costoso. Además, NFS no es “cluster aware”, por lo que necesito configurar locking para evitar que varios nodos escriban los mismos archivos al mismo tiempo. Esta situación es aun más grave si consideramos que se puede estar usando ese almacenamiento compartido para bases de datos.

Leyendo a Hardy Beltrán de Bolivia, me acordé de DRBD. En su momento evalué GFS junto a otros sistemas de archivos para SAN, como OCFS2, y finalmente nos decidimos por GFS. Pero en un proyecto de clusterización de servicios de red y directorio que ejecuté posteriormente utilizamos DRBD, que puede definirse como RAID-1 por red, siendo especialmente útil en escenarios de dos equipos. Este cluster corría DNS, DHCP, IPP (CUPS), LDAP, bases de datos MySQL y Apache en alta disponibilidad.

Productizando el cluster

Según mi experiencia, si planea utilizar Global File System para el almacenamiento compartido, vale la pena que considere toda la solución de Red Hat Cluster Suite, y que la ejecute en un sistema derivado de RHEL, como puede ser CentOS. Yo he implementado todo en Debian, y solamente GFS, pero genera más carga administrativa.

De otra forma, yo recomiendo considerar Heartbeat y Linux Virtual Server, y revisar alteativas de NAS. Si bien el objetivo es siempre evitar los puntos únicos de falla, en ocasiones las empresas tienen que hacer compromisos y normalmente eso ocurre en el espacio de almacenamiento. Si bien un punto único de falla romperá las expectativas del cluster (always on) al menos tener sanas políticas de respaldo ayudará a minimizar los tiempos de caída.

Finalmente, todo lo expuesto aquí cubre clusteres de servicios. Hacer clusteres de cómputo (Beowulf and the like) es otra disciplina, sobre la cual, si están interesados, les recomendaría consultar con mi amigo Julio César Ortega, una de las personas en Venezuela que tiene más experiencia en ambos modelos..

Standard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s