Tu servicio web se cae sin motivo? Conoce la alta disponibilidad

dv-alta

Artículo escrito por Oscar Montero, CEO de Digital Valley.

¿Tu negocios web requieren alta disponibilidad, mayor velocidad, y escalabilidad?

No debemos amedrentarse con este tipo de palabras, lo importante es entenderlas y saber cómo pueden resolver problemas actuales o futuros con las tecnologías disponibles. Estas tres funcionalidades son esenciales para aquellos sitios web que necesitan minimizar o anular las caídas, un aumento de velocidad y la capacidad de poder expandirse y decrecer según las necesidades del negocio sin un coste elevado y sin cambios en la programación. ¿Por qué las necesito y cómo las consigo?

Alta disponibilidad.

Es un término muy de moda pero nada nuevo. Con alta disponibilidad nos referimos a los métodos de minimizar las caídas y conseguir una mayor redundancia de los sistemas. La alta disponibilidad absoluta no existe, salvo que sientas aprecio por los filósofos idealista alemanes.

Si alojas tu web en un servidor dedicado, y deseas lograr alta disponibilidad, la única solución disponible consiste en encender unas cuantas velas a tu santo preferido. En la arquitecturas monolíticas de los servidores dedicados, obtener alta disponibilidad es harto difícil. Hay tantos puntos de fallo que cuando se rompe algún eslabón, tu web cae y el teléfono de soporte estalla. Y más tarde o más temprano el disco duro o cualquier otro elemento físico o lógico se rompe. Lo importante no es que falle -que fallará- sino estar preparados para el jaleo que se va a montar, y reconocer los perjuicios que nos causa.

Hay varias formas de conseguir alta disponibilidad. Con la llegada de las tecnologías de virtualización y el cloud computing, la alta disponibilidad es un fenómeno que va haciéndose cada vez más asequible y real. La mayoría de virtualizadores admiten fail-over y pueden conseguir una cierta disponibilidad del nodo cuando se cuenta con almacenamiento compartido y un nodo libre para que éste tome el relevo del nodo en apuros. Sin embargo, esta alta disponibilidad no es tan eficiente como la de un cluster que tiene servicios distribuidos y orquestados en diferentes nodos redundados por balanceadores de carga que garantizan la continuidad del servicio. El esquema de abajo es un ejemplo de Digital Valley a la solución a este problema.

dv-alta1

En el esquena un balanceador de carga redundado distribuye las peticiones web a varios nodos web y de base de datos de manera que el tráfico se distribuye de manera inteligente a los diferentes nodos. En vez de mantener todos los servicios (web, base de datos, email, ftp…) en un único servidor dedicado, separamos los servicios y los repartimos en diferentes nodos o servidores de manera que si falla uno, siempre hay otro que automáticamente toma el relevo.

Pero no solo toma el relevo sino que el balanceador de carga se encarga de que un servidor o nodo no se sature de procesos. Éste redistribuye (depende de la configuración) de manera uniforme las peticiones entre los nodos disponibles equilibrando la carga de trabajo. Ya sólo con separar los servidores en nodos web y nodos de bases de datos se mejora significativamente el rendimiento y los problemas se minimizan. Siempre el punto más débil en este tipo de arquitecturas serán la base de datos. Si las mantenemos en nodos separados, aislaremos los problemas y no afectaremos al rendimiento de los nodos web.

Aumento de velocidad.

De nuevo, hay muchas formas de incrementar la velocidad de un sitio web tanto desde la arquitectura de la web como en la programación. En este caso, nuestro servicio emplea soluciones de web caching como Varnish y Memcached. Hace unos días escribí un artículo aquí de cómo implementar Varnish cache para aumentar hasta un 60% la velocidad de nuestra web. Son tecnologías fáciles de implementar, de bajo coste y muy eficaces a la hora de aumentar espectacularmente la velocidad de un sitio web.

En esencia, se trata de colocar uno de estos servidores delante del servidor web y almacenar en memoria los ficheros que los visitantes nos piden para que el servidor web y la base de datos no tenga que servirlos y hacer el trabajo por cada petición que nos llega. Es una solución fácil de implementar que traerá un aumento significativo de la velocidad y una reducción de la carga de trabajo web y base de datos.

Escalabilidad.

Que una web escale supone que toda o parte de su arquitectura puede ampliarse o reducirse según el tráfico y uso que se le de sin tener que hacer cambios significativos en la programación o sin emplear un pastizal de dinero en nueva infraestructura, algo que no sentará nada bien a los gestores cuando tengan que hacer los pagos por no haber pensado cómo crecer.

Esta función puede parecer prescindible pero no lo es en absoluto. Aquellos que han tenido la experiencia de ver crecer exponencialmente las visitas de su web sin haber planificado bien la escalabilidad de su arquitectura pueden morir de éxito o tener que cambiar radicalmente la programación o estructura de su web si no pueden escalar.

Se suele hablar de escalabilidad vertical y horizontal. El ejemplo más típico de cómo escalar verticalmente una web consiste en ampliar los recursos del servidor dedicado donde está alojado. Esta idea es algo peligrosa y poco recomendable si el proyecto crece bastante. Para empezar, no hay separación de servicios, y por lo tanto, si un servicio como la base de datos tiene problemas, afectará a todos los servicios en el mismo servidor (email, web, etc.). Y viceversa. Si hay un fallo en la programación o hay consultas mal realizadas a la base de datos, por mucho que escalemos verticalmente no vamos a arreglar el problema de raíz más fácilmente. Escalar verticalmente también supone sobre-dimensionar el servidor en recursos de RAM, CPU, etc. Este sobre-dimensionamiento no es gratuito. Tendremos que pagar por servidores más costosos cuando no los necesitamos.

Por ejemplo, conozco varios casos donde la web del cliente recibe cientos de miles de visitas en tan sólo unos minutos cuando lanzan su newsletter una vez a la semana. El resto de los días su web está infra-utilizada y pagan por un servidor enorme cuando podría realizar una gestión más eficiente con una arquitectura distribuida y balanceada. Además, su web se ha caído varias veces por no poder resistir la ingente cantidad de visitas que recibe. Hay muchos ejemplos parecidos. Si uno de nuestros videos o artículos sale en un blog importante, quizás nuestra web no resista las visitas. Es lo que suele sucederle incluso a periódicos cuando hay noticias o eventos importantes. No tienen capacidad de planificación para escalar. Es un error costoso.

Si quieres conocer la solución de alta disponibilidad de Digital Valley pincha aquí.