h1

Un clúster virtualizado

01/23/2009

Wizdoc [Icon By Buuf]

 Tips & Tricks.

Una aplicación web con alto índice de usuarios concurrentes está trabajando desde hace poco más de dos años en el ambiente productivo. Como parte de una actualización tecnológica, se realizó el upgrade de unas máquinas así como de los componentes de software – base de datos, java/j2ee y los servidores web y de aplicaciones – para que una nueva versión de la aplicación fuera liberada. El objetivo de esta renovación era preparar a la aplicación para soportar un ambiente con alta disponibilidad, redundancia y en general una mejor calidad en el servicio proporcionado al usuario final, pues ahora se sumaría casi el doble de carga sobre esta aplicación.

El detalle en este caso es la arquitectura:

La arquitectura actual de la aplicacion

Arquitectura actual de la aplicación: Diagramas físico y de bloques. Nótese que no existe una redundancia de ninguno de los elementos de hardware salvo el arreglo de discos (configurado con RAID5 o espejeo de volúmenes).

Aunque se han configurado la base de datos y los servidores web y de aplicaciones en forma de clúster (con varias instancias lógicas) y existe un arreglo de discos externo para salvaguardar la información de las tablas de la base de datos, el sistema en su conjunto sigue teniendo un sólo punto de falla: en caso de caída de alguno de los dos equipos se pierde el servicio en su totalidad.

La solución más obvia pareciera ser incluir una redundancia por cada uno de los componentes de hardware presentes, pero eso nos convertiría nuestra arquitectura en una pesadilla de administración, por no decir muy costosa pues cada uno de los servidores están en el rango de los US$75,000, y un buen balanceador de carga vale al menos US$30,000:

Una posible arquitectura redundante y de alta disponibilidad

Una posible arquitectura redundante y de alta disponibilidad; diagramas físico y de bloques. Las "referencias circulares" en algunas de las conexiones de los nodos implican el balanceo de cargas o el failover. Nótese que se requerirían de al menos cuatro servidores. En el caso del balanceo, éste puede ser implementado por un solo balanceador de 8 puertos y su correspondiente redundancia.

Aunque pareciera que tenemos que contentarnos con una arquitectura plana y sin redundancias o una de alta disponibilidad pero muy costosa, existe una solución a este tipo de problemas: la virtualización y el uso de un clúster.

Aunque esta solución está acotada a las proyecciones de crecimiento de la plataforma y la capacidad individual de los equipos involucrados, es posible crear dos instancias virtuales del servidor, instalando y configurando en cada una de ellas las aplicaciones que corresponden a la capa lógica de la arquitectura. Con ello, estamos manejando lógicamente cuatro máquinas, pero físicamente estamos ocupando los recursos – fuentes de energía, nodos de red – de sólo dos servidores:

Una arquitectura redundante y de alta disponibilidad

Una arquitectura redundante y de alta disponibilidad gracias a la ayuda de la virtualización de los servidores y la clusterización de los mismos mediante un middleware empresarial. (Dar click en imagen para ver en mayor tamaño).

De este tipo de arquitectura se desprenden dos tipos de configuraciones: Una con 2 capas, donde cada servidor tiene las instancias virtualizadas de la misma capa. La otra configuración implica que cada máquina contará con las dos capas, dejando la arquitectura como "unicapa" con su correspondiente redundancia.

Ambas configuraciones tienen sus beneficios y particularidades:

• La configuración de dos capas (a la izquierda, en el diagrama anterior) simplifica la tarea del sysadmin y del área de soporte al sólo dejar un mismo tipo de aplicación en las instancias de un servidor; también se tiene un cálculo de crecimiento de uso de memoria y CPU más heterogéneo, facilitando proyecciones de crecimiento más certeras. Sin embargo, esto nos remite de nueva cuenta al problema inicial: aunque si una instancia se cae no se afectará la otra, en caso de que el equipo falle en su totalidad se pierde la disponibilidad de toda la plataforma.

• La configuración de una sola capa con redundancia (a la derecha, en el diagrama anterior) robustece en gran medida la plataforma y agiliza la velocidad de algunas aplicaciones – por ejemplo, si se requiere uso intensivo de red – pero al tener en una misma máquina las dos capas, se puede presentar un riesgo de seguridad donde se podría tener acceso total al sistema y su información en caso de un ingreso no autorizado.

Por otro lado, sin importar cuál de las dos opciones de virtualización se seleccione, la arquitectura es lo suficientemente escalable para permitir incrementar tanto horizontalmente como verticalmente su capacidad.

Reflexionando

Resulta que la configuración inicial es real y las opciones de virtualización son algo que estaremos discutiendo con uno de nuestros clientes durante las próximas semanas. El problema surgió como producto de una definición inexistente de arquitectura por parte suya. Nosotros también tenemos en parte la culpa, pues no supimos desde un principio para qué querían esas máquinas – el típico caso de: necesito dos maquinones y un par de licencias de application server – y no investigamos el objetivo real detrás de esa compra. De haber comprendido realmente para qué se necesitaban, hubiésemos podido mejorar esta arquitectura desde un principio y no tener que incluir temas de virtualización y clusters – conceptos que aterran a nuestro cliente y le implicarán un gasto adicional por la novedad de la tecnología.

La moraleja de la historia: no sólo sigamos los requerimientos de un cliente al pie de la letra; mejor busquemos comprender el contexto de sus necesidades para saber si lo que está pidiendo es lo mejor. Eso es justamente el trabajo de consultoría que puede hacer la diferencia entre "automatizar sandeces" o dar un valor agregado en nuestros servicios.

En fin, realizando un poco de "devanado de sesos" hemos llegado a un par de ideas que podemos presentar y que ayudarán a resolver los problemas de nuestro cliente… mientras por supuesto, significan un buen ingreso para nosotros.

One comment

  1. Excelente artículo.!!!!!



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

A %d blogueros les gusta esto: