Windows Azure: Para comprender la solución, hay que entender el problema

Tal como señala el título, es conveniente revisar el problema en cuestión, su naturaleza y características, para poder comprender mejor porqué un determinado diseño o arquitectura representa una solución razonable a dicho problema.

Es frecuente que, cuando me veo en la necesidad de explicar un concepto complejo, encuentro útil recurrir a una analogía de la vida cotidiana para facilitar dicha explicación.

En este caso, voy a recurrir a la analogía de un automóvil como un ejemplo de sistema que guarda determinadas relaciones con un sistema informático.

A muchos de nosotros nos ha pasado aprender que, en un automóvil, muchas cosas distintas pueden fallar y dejarnos sin solución. Algo similar sucede con los sistemas informáticos: muchas partes distintas del sistema pueden fallar y dejarnos sin solución.

En un automóvil, al igual que en un sistema, es grave cuando la pieza o parte que falla se caracteriza por ser un punto único de falla: es alguna pieza o parte crucial del automóvil o del sistema que, si falla, nos deja completamente sin solución, por la simple y sencilla razón que el sistema solo cuenta con una pieza de ese tipo!.

En este punto, es conveniente hacernos la pregunta de rigor:

¿ Cómo podemos diseñar un sistema para que sea fault-tolerant ?

Antes que nada, es útil tener una definición operativa de fault-tolerant, aunque no sea una definición académica.

Un sistema fault-tolerant es aquel que es capaz de seguir brindando su servicio a pesar que un determinado subconjunto de sus partes ha fallado.

La solución general de diseño para un sistema fault-tolerant es conceptualmente sencilla: redundancia.

El sistema debe evitar puntos únicos de falla a través de diversas redundancias en sus partes, aunado con un sistema de monitoreo del grado de salud de cada parte o componente del sistema, y con la capacidad de redireccionar la provisión de la función afectada por la falla hacia una pieza redundante equivalente ante la detección del problema.

Para poder seguir con este análisis, debemos orientar nuestra atención a un subconjunto importante de quality attributes (QAs) de un sistema informático.

En este punto solamente me concentraré en los QAs que son relevantes para esté análisis, dado que hay otros QAs que son importantes en general, pero no forman parte de nuestro scope.

Los QAs en cuestión son:

Performance

Escalabilidad

Seguridad

Disponibilidad

El orden de presentación no es relevante, más bien es práctico.

Vamos a dar algunas definiciones operativas de estos conceptos, aunque no sean académicas.

Performance es la capacidad de completar una tarea en un intervalo de tiempo y con un consumo/ocupación de recursos conveniente desde el punto de vista económico.

Escalabilidad es la capacidad de poder atender cantidades crecientes de solicitudes concurrentes de ejecución de una tarea, conservando la performance dentro de un umbral cercano al nivel nominal (el necesario para realizar una sola tarea), de tal forma que mantiene o conserva la conveniencia económica.

Seguridad es la capacidad de garantizar que en un sistema al que acceden muchas personas distintas, cada persona solamente tiene acceso a la información estrictamente necesaria para cumplir con sus objetivos y responsabilidades, ni más, ni menos.

Disponibilidad es la capacidad de un sistema de seguir adelante con la provisión de sus servicios básicos a pesar que un determinado subconjunto de sus partes o piezas ha fallado.

El orden o grado de disponibilidad de un sistema se mide en %, de tal forma que cuanto más cercano al 100% es la disponibilidad del sistema, más conveniente desde el punto de vista económico-financiero es el mismo.

Una forma práctica de entender el orden o grado de disponibilidad es como el cociente entre la cantidad total real de tiempo de operación del sistema durante un intervalo de tiempo (por ejemplo, un año) y la cantidad total nominal de tiempo de operación del sistema durante el mismo intervalo de tiempo, expresado en %.

Un sistema fault-tolerant debe ser capaz de conservar estos cuatro QAs dentro de un nivel económicamente conveniente, a pesar que un subconjunto de sus partes o piezas ha fallado.

Para comprender el problema y su solución, veremos alternativas de fallas cruciales y como la conservación de los niveles aceptables de los QAs mencionados informan cómo debería ser el diseño.

Veamos la escalabilidad. Una forma sencilla de mantener la escalabilidad es usar un server más grande y veloz, con más capacidad de procesamiento, más memoria, más discos, etc.

En realidad, esta no es una brillante idea, dado que estamos permitiendo que exista un punto único de falla.

Esta opción, llamada Scale Up, no es buena, más bien es mejor la opción que permite escalar con un conjunto de servers, llamada Scale Out.

Los clusters de servers con Network Load Balancers (NLBs) apuntan a la opción Scale Out de servers de aplicación.

Sin embargo, los clusters y los NLBs no resuelven el problema de una falla en el servicio de repositorio de datos (en general, bases de datos).

Para ofrecer una solución útil y a la vez, coordinada con el Scale out de servers de aplicación, es necesario tener un diseño que permita un Scale Out de servers de bases de datos que actualice en forma concurrente y distribuida y que soporte failover automático, es decir, la capacidad de detectar que el server primario no responde y es necesario redireccionar la provisión del servicio a un server secundario que ya está actualizado con la misma información, en forma concurrente.

Desde el punto de vista de la seguridad, es más fácil dar seguridad a un esquema Scale Up que a un esquema Scale Out, pero la combinación seguridad + escalabilidad del Scale Out es mucho mejor que la combinación del Scale Up.

En el caso del orden o grado de disponibilidad, es importante considerar como afecta a este factor las paradas programadas y las no programadas.

Es fácil de comprender que se puede hacer mucho por mitigar el impacto que tienen las paradas programadas sobre la disponibilidad, en particular si aumentamos el grado de redundancia de tal forma de tener servers adicionales para hacer las paradas programadas con rotación de servers en operación.

Windows Azure ofrece todas estas capacidades, incluyendo failover automático a un site remoto (ante una catástrofe que afecte al site en su conjunto), más provisión elástica de capacity, más costos variables según consumo.

Advertisements

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