Redundancia, Contingencia, Continuidad, Resiliencia

Por Gabriel Marcos
Especialista en Datacenter y Seguridad
Global Crossing
A la vista de la creciente adopción del modelo de servicios Cloud Computing (computación en la nube), al cual paradójicamente una de las principales críticas que se le hace es la falta de estándares y protocolos en común entre fabricantes y empresas de servicios (los proveedores, a veces, tampoco se ponen de acuerdo ni hablan los mismos idiomas!), me parece importante arriesgar algunas definiciones sobre los términos que dan título a este artículo, y sobre los que día a día encuentro que aún existen múltiples significados en vigencia.

Voy a describir, uno por uno y en orden creciente de valor, cada uno de estos términos, con el objetivo de ofrecer definiciones que puedan funcionar de base para un esencial consenso que nos permita profundizar sobre las posibilidades de cada modelo, a partir de estar de acuerdo en éstas definiciones.

Redundancia

La redundancia implica, necesariamente, duplicar infraestructura. Quizás la forma más tradicional de implementar un modelo de redundancia es a través de los modelos de clusterización, en los cuales mediante algún protocolo de conmutación, hay dos equipos que funcionan coordinadamente, y se alternan de acuerdo a parámetros pre-definidos.

Los esquemas en este caso pueden ser Activo – Pasivo (sólo uno funciona al tiempo), o Activo – Activo (cuando ambos funcionan simultáneamente, debe existir algún mecanismo adicional de balanceo de carga).

Que este tipo de esquemas sea el primero de nuestro listado, no significa que su implementación sea sencilla ni que su funcionamiento sea trivial: una verdadera solución de redundancia requiere típicamente involucrar más componentes duplicados que solamente aquél sobre el que se desea obtener el beneficio.

Por ejemplo, los esquemas de firewall con redundancia, pueden requerir switches y routers duplicados, además de los propios firewalls, y en algunos casos incluso será necesario duplicar vínculos físicos para obtener una solución completa.

En la práctica, la estrategia preferida por las empresas es ubicar los esquemas de redundancia en Data Centers que, desde el punto de vista de la infraestructura, no contengan puntos únicos de falla; esto hace que encontremos soluciones con disponibilidad real del 100% durante años, en perfecto funcionamiento.

Sin embargo, en este tipo de arquitecturas, aún es posible encontrar puntos únicos de falla del lado del cliente; recuerdo una empresa que tuvo una sola persona encargada de los backups, ¡durante 15 años! No había procedimientos documentados, ni nadie más entrenado en cómo se hacía un restore. ¡Creo que el ejemplo es bastante ilustrativo!

Contingencia

Las soluciones de contingencia imponen algunos desafíos adicionales a las soluciones de redundancia, y podríamos generalizar diciendo que aquí se vuelve imprescindible la distribución geográfica de la solución: las arquitecturas en cluster no forman parte del espectro de los esquemas de contingencia. Bienvenidos a la replicación!

Si bien en los esquemas de redundancia existe una capa externa a los servicios en sí que permite la sincronización de la operación de todos los componentes de la infraestructura, en los esquemas de contingencia es necesaria una capa adicional que provea los servicios de replicación de datos, para asegurar que sea cual sea el nodo que se encuentre operando en cualquier momento, los datos sean siempre los mismos… o al menos estén lo más actualizados posible!

La separación geográfica es sinónimo de asincronía: ya no es posible “que todo suceda al tiempo”, sino que necesariamente existirán delays (retardos, demoras) adicionales por los que no deberíamos preocuparnos si se tratara de una arquitectura en cluster.

Por otro lado, la inestabilidad y el riesgo de las arquitecturas en cluster, aumentan proporcionalmente con la distancia física a la que se encuentran los componentes de la solución. Es por esta razón que ese tipo de arquitecturas tienen importantes limitaciones geográficas.

Cuando hablamos de contingencia, más que la disponibilidad general de la solución (que no siempre es automáticamente superior a una solución de redundancia, al menos desde el punto de vista teórico), nos interesa entender dos parámetros: RTO y RPO.

RTO (Recovery Time Objective,), representa la cantidad de tiempo máximo que un servicio puede estar caído sin consecuencias importantes para la empresa o un proceso de negocio específico.

Este parámetro es clave porque no se debería pasar de un esquema de producción a uno de contingencia de forma automática. Es decir, asumimos que siempre va a existir algún tipo de indisponibilidad, lo importante es acotarla y asegurarnos que esa indisponibilidad resulta aceptable para el negocio.

Esto también implica que deberá existir algún proceso manual (como mínimo, un proceso de autorización para el ingreso a la contingencia) que incrementará los tiempos de respuesta de la solución y que debe estar incluido en el cálculo del RTO.

En la vida real, es posible observar RTOs tan bajos como tiempos menores a 5 minutos (en casos particulares), como los más habituales de alrededor de las 4 horas, y todos los que pueda imaginarse en el medio!

RPO (Recovery Point Objetive, en castellano: objetivo de punto de recuperación), implica cuánta información es aceptable perder al momento de entrar en contingencia, medido también en tiempo.

La mayoría de las soluciones de contingencia utilizan el método conocido como “replicación asincrónica”: esto significa que el sitio de producción opera de forma independiente a cómo se replican los datos, generando un RPO mayor pero ofreciendo más flexibilidad y mejor tiempo de respuesta a la aplicación en producción.

En el caso de la “replicación sincrónica”, esto implica que por cada modificación que se hace a los datos en el sitio de producción, se deberá esperar la confirmación de que el dato ha sido transferido y almacenado correctamente en el sitio de contingencia para poder volver a procesar otro dato; esta metodología implica un riesgo de pérdida de performance y de indisponibilidad proporcional a la cantidad de transacciones, y su distribución en el tiempo.

Es importante aclarar que “contingencia” no implica “duplicación de infraestructura”, y de hecho no debería implicarlo en la mayoría de los casos, ya que como se entiende que la situación de contingencia es temporal, uno debería poder funcionar con una performance menor (de forma acotada) por un período máximo de tiempo hasta el restablecimiento la infraestructura en producción. 

Continuidad

Tanto los modelos de redundancia como los de contingencia son, principalmente, soluciones básicamente tecnológicas. Pero cuando hablamos de continuidad del negocio, abrimos la puerta a un nuevo universo, que implica garantizar disponibilidad a procesos de negocio, considerando las tecnologías pero también las personas y las operaciones que éstas realizan, incluyendo las interacciones con clientes y proveedores.

Hay muchos ejemplos que demuestran la necesidad de soluciones de continuidad del negocio por sobre simplemente arquitecturas de redundancia o contingencia; por ejemplo, aún si usted posee una infraestructura de contingencia soportada en Data Centers y redes que siempre funcionan, si su empresa se incendia, nadie podrá acceder a los sistemas aunque éstos se encuentren disponibles.

Por supuesto, no es necesario que todos los procesos de una empresa se encuentren bajo esquemas de continuidad del negocio, como tampoco es cierto para todos los componentes de una infraestructura de TI y telecomunicaciones.

Justamente, la determinación de cuáles son los procesos y componentes que deberían formar parte del esquema de continuidad, es el primer paso de un proyecto de implementación y me atrevería a decir que es quizás el más importante.

Típicamente, al menos según las normas internacionales que tratan sobre este tema, la determinación de un esquema de contingencia comienza por un tipo particular de análisis de riesgo que se denomina BIA (Business Impact Analysis), cuyo resultado final es un documento que contiene el impacto económico y operativo de cada uno de los recursos (humanos y tecnológicos) en los principales procesos de negocio de la organización, con el objetivo de determinar cuáles son aquellos procesos críticos que deberán estar bajo el esquema de continuidad, y cuál es el nivel de riesgo que representan para la organización y en función del cual se justificarán y delinearán las inversiones necesarias.

No se asuste si solamente desarrollar el BIA para su organización le toma entre 2 y 3 meses: son tiempos normales para quien lo hace por primera vez; las futuras actualizaciones podrían demorar hasta un 50% menos, aunque en este tipo de proyectos siempre es preferible optar por la precisión antes que por la velocidad.

Resiliencia

En términos sencillos, la resiliencia es la capacidad de una solución continuar funcionando (dentro de parámetros aceptables) ante distintos tipos de problemas.

El componente místico reside en que la resiliencia es una característica inherente al modelo de servicios de Cloud Computing, pero muy poca gente ha podido vivenciar qué significa esta propiedad, y muy pocos creen que sea realmente posible.

Por otro lado, el concepto de resiliencia tiene aplicación en áreas tan disímiles como la física de materiales, la biología y la psicología, por nombrar solamente algunas, además del uso que estamos analizando aquí, referido a las tecnologías de la información.

Para entrar en detalle, conviene hacer varias aclaraciones…

La resiliencia es una propiedad medible, y por lo tanto, finita: es fundamental dejar de lado el concepto (errado) de que “resiliencia” significa “funcionamiento continuo a toda costa”; es decir, que parafraseando a nuestros padres, todo tiene un límite.

En los últimos meses hemos sido testigos de cómo las infraestructuras mundiales con mayores niveles de resiliencia disponibles para el público en general han sufrido caídas masivas de servicio, y esto no debería extrañarnos: así como es matemáticamente imposible asegurar el funcionamiento de cualquier pieza de software, no podemos crear sistemas con resiliencia infinita fuera del ámbito teórico o imaginativo.

Es por esto que cuando nos referimos a la propiedad de resiliencia de una determinada infraestructura, tiene más sentido hablar en términos de “grado” o “nivel” que de valores absolutos.

Sin embargo, una solución con un alto grado de resiliencia debe ofrecernos algo más que una solución de continuidad del negocio; parámetros típicos del modelo de servicios de Cloud Computing como la independencia de la ubicación física, la infraestructura compartida y el crecimiento por demanda son algunas de las pistas que podemos vislumbrar acerca de por qué el mundo de las tecnologías de la información tiende a migrar hacia este tipo de esquemas.

La posibilidad de que un sistema (en este caso, este término es mucho más acertado que el concepto de “solución” o de “infraestructura”) ofrezca características de resiliencia es directamente proporcional a la capacidad de medir entre qué parámetros se desarrolla la operación normal; este punto está lejos de ser trivial.

Lo cierto es que el concepto de resiliencia nos obliga a mudar todas nuestras concepciones acerca de lo que creíamos que eran parámetros aceptables de servicio: acostumbrados a hablar en términos de figuras absolutas como la disponibilidad, el RTO y el RPO, nos movemos hacia áreas más grises como la experiencia del usuario, los tiempos de respuesta (delay) y su variación (jitter), la performance, y demás indicadores que hacen mucho más sentido en este contexto.

En la práctica, uno puede hablar de alta disponibilidad como propiedad y como concepto; en el caso de su uso como propiedad, generalmente se utiliza como sinónimo de redundancia y contingencia indistintamente, es decir que cuando alguien le informe que tal o cual servicio tiene características de alta disponible, le recomiendo que solicite aclaraciones.

Cuando la alta disponibilidad se utiliza conceptualmente, hace referencia al mejoramiento de una infraestructura de funcionamiento básico, es decir stand alone (en solitario).

En este sentido, los cuatro conceptos que presentamos contribuyen al concepto de alta disponibilidad en el sentido de que a una infraestructura básica necesaria para el funcionamiento de un proceso de negocio (por ejemplo, lo que uno podría probar en un laboratorio para certificar el uso de una aplicación), se le considera de alta disponibilidad cuando se incorporan al diseño características de redundancia, contingencia, continuidad y/o resiliencia.

También me gustaría completar la presentación con la buena noticia de que los esquemas que revisamos no son excluyentes: podemos combinarlos hasta donde nuestro presupuesto alcance, y los análisis de riesgos sean capaces de justificarlo.

Uno siempre debería tratar de encontrar la mejor solución en términos de ROI (Return of Investments, en castellano: retorno de la inversión), con todas las herramientas de las que dispone, y la combinación de técnicas de continuidad con arquitecturas de contingencia y redundancia para diseñar soluciones con alto grado de resiliencia no solamente está permitido, sino que es deseable que ocurra.