En la era del BigData donde todo el mundo parece necesitar clústers inmensos de MongoDB, Spark o Hadoop para poder procesar la ingente cantidad de datos que se generan, la realidad es que en muchos casos los problemas derivados se pueden solucionar con tecnologías tradicionales y un poco de fontanería. A todos nos gustan las nuevas tecnologías pero a veces el cambio que supone para los desarrolladores es demasiado elevado como para no proponer alguna solución alternativa. Hoy veremos una de éstas soluciones alternativas, que se ha implementado de forma satisfactoria en dos clientes diferentes.

A pesar de que no es algo que se requiera habitualmente, es posible usar HAProxy para balancear la carga de trabajo entre diferentes instancias de SQL Server. De todas formas, a pesar de que es posible hacerlo, por motivos evidentes no es válido para todos los casos. Os paso la configuración que usamos nosotros, y posteriormente os explicaré para en qué escenarios se podría usar.

Instalación en Debian®

La instalación en Debian® es muy sencilla. Podemos usar el siguiente comando.

sudo apt-get install haproxy

Es posible que en función de la versión que exista en nuestro repositorio la instalación que se realice con este método no sea la más reciente. Para un manual un poco más avanzado sobre la instalación de HAProxy en Debian® podéis visitar este link.

Configuración

Con el editor que prefiramos editamos el siguiente fichero

sudo nano /etc/haproxy/haproxy.cfg

La configuración es muy sencilla. En este fichero de configuración de ejemplo balancearemos las peticiones que se reciban en el puerto 1433 (el puerto estándar del Microsoft SQL Server) del nodo del HAProxy a los puertos 1433 de tres instancias diferentes de SQL Server que se encuentran en los servidores con direcciones IP que van de la 192.168.1.11 a la 192.168.1.13. Enviaremos las conexiones al nodo remoto que menos conexiones tenga. Además, comprovaremos que el servicio remoto está activo cada segundo (1000 ms).

listen sql-db
    bind *:1433
    mode tcp
    balance leastconn
    option log-health-checks
    server DB-1 192.168.1.11:1433 check port 1433 inter 1000
    server DB-2 192.168.1.12:1433 check port 1433 inter 1000
    server DB-3 192.168.1.13:1433 check port 1433 inter 1000

Se puede restringir el acceso a los clientes añadiendo una lista blanca. En este caso, el fichero de configuración nos quedaría de la siguiente forma.

listen sql-db
    bind *:1433
    mode tcp
    balance leastconn
    option log-health-checks
    acl db_white_list src 192.168.1.100 192.168.1.101 192.168.1.102
    tcp-request connection reject if !db_white_list
    server DB-1 192.168.1.11:1433 check port 1433 inter 1000
    server DB-2 192.168.1.12:1433 check port 1433 inter 1000
    server DB-3 192.168.1.13:1433 check port 1433 inter 1000

Aquí se explica una arquitectura que quedaría de la siguiente forma.

simple HAProxy

Aunque no se explique en este artículo es evidente que esta arquitectura no es la más recomendable para un uso de alta disponibilidad, y en realidad debería montarse una arquitectura más parecida a la siguiente:

keepalived HAProxy

Donde tenemos más de un nodo realizando las funciones de proxy, y con otro software como keealived, Corosync o similar controlar una IP virtual que es la que en realidad usen los clientes.

Posibles usos

Es evidente que esta arquitectura no se puede usar para cualquier tipo de aplicaciones, pero hay ciertos casos en los que nos puede ser útil. Vamos a verlas.

Datawarehouse

Supongamos que las aplicaciones sencillamente instertan datos estadísticos que deberán ser procesados posteriormente. Si sólo tenemos un almacén de datos en el que escribir y el número de clientes es muy elevado, es posible que, por la latencia de escritura en disco y en función del volumen de datos a escribir la instancia SQL Server de destino acabe suponiendo un cuello de botella. Balanceando la escritura de disco  entre varios servidores evitamos el cuello de botella y es fácilmente escalable, ya que sencillamente tenemos que añadir más servidores detrás del proxy. En caso de caída de un nodo, las escrituras se derivarían al resto de nodos, y por lo tanto no tendríamos caída de servicio. A la hora de procesar los datos sólo tendríamos que tener en cuenta que éstos no están en un sólo servidor sino en varios, y tendríamos que agruparlos.

Separación de las lecturas de las escrituras

En el caso anterior es evidente que los datos no puede tener ningún tipo de relación referencial, ya que los datos se encuentran en servidores que nada saben el uno del otro. En caso de que se quiera usar con integridad referencial se pueden (en según qué caso!!!! se debería evaluar de forma induvidual cada caso) separar las lecturas de las escrituras. Las aplicaciones deberían conocer de la arquitectura (en realidad dos instancias, una para escritura y otra para lectura, y balancearíamos las lecturas). El esquema quedaria de la siguiente forma.

simple HAProxy RW

 

Estas dos arquitecturas se usaron para dos casos particulares y funcionaron de forma satisfactoria, evitando tener que reprogramar gran parte del sistema.  Además esta arquitectura se puede usar con cualquier motor de base de datos, no sólo con SQL Server. Sencillamente se modifican los puertos afectados y listos.

Como desventaja me gustaría advertir que a pesar de que parezca que este sistema es escalable de forma indefinida, no es así. Si bien el HAProxy no suele consumir muchos recursos, en el caso de que se quiera usar como proxy SQL y siempre en función de los datos que se transfieran a través de él, el consumo de recursos de CPU, red y memoria se verán incrementados, por lo tanto, hay que evaluar cada caso para ver si se puede implementar y los problemas que se pueden derivar.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s