Por Gabriel Marcos Global Crossing 

Por: Gabriel Marcos Marketing Specialist Datacenter & Security
Global Crossing Colombia.S.A.

Llegó la hora de derribar un mito: es cierto que quienes estamos en el ambiente de las tecnologías y la seguridad de la información solemos regodearnos de lo constructiva que puede ser una conversación con alguien que comparte nuestros mismos gustos y áreas de especialización o preferencia, que muchas veces necesitamos adaptar nuestro lenguaje para hacernos entender por fuera del ambiente y que esto no siempre nos agrada o nos resulta sencillo, que disfrutamos de investigar y compartir lo que sabemos con nuestros compañeros y amigos, entre muchas otras aseveraciones similares que podría formular y que Ud. seguramente ya conoce… pero también debemos reconocer que entre nosotros, no siempre hablamos el mismo idioma!

Quizás esto pueda pasar desapercibido para quienes no conocen las sutilezas del lenguaje técnico y la infinidad de acrónimos y abreviaturas con significados varios que se manejan habitualmente, pero entre nosotros es una verdad de esas que todos conocen pero nadie se anima a explicitar: no siempre estamos de acuerdo en qué significan esos términos sobre los que discutimos.

Esto es fácil de explicar: la tecnología avanza más rápido que nuestra capacidad de asimilar y aprender, y mucho más rápido aún que nuestras habilidades innatas para comunicarnos y ponernos de acuerdo.
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.

Es importante aclarar que “redundancia” no es equivalente en forma automática a “disponibilidad 100%”; esta es quizás la principal confusión que existe acerca de este modelo, ya que de todos los que estamos repasando, es probablemente el que menor disponibilidad teórica ofrece.

La razón es que en los modelos de redundancia, siempre existe un punto único de falla, por definición: Ud. puede duplicar vínculos y equipos, pero si utiliza una sola ubicación física, ahí tiene su punto único de falla. A partir de aquí, es posible seguir el ejemplo.

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!

En los esquemas de redundancia nos interesa poder garantizar un nivel de disponibilidad mínimo para la solución, y es básicamente el único parámetro relevante que podemos extraer de este tipo de arquitecturas.

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, en castellano: objetivo de tiempo de recuperación), 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.
Pongamos un ejemplo: si el sitio productivo dejó de funcionar a las 10:00 AM, un RPO de 5 minutos, implica que todos los datos fueron replicados y actualizados en el sitio de contingencia, de acuerdo a la información que estaba almacenada en el sitio de producción hasta las 9:55 AM.

Es posible observar que en esquemas altamente transaccionales, un RPO bajo puede llegar a ser muy difícil de alcanzar, ya que mientras más cantidad de transacciones sean almacenadas en el sitio de producción, más rápido deberá funcionar el esquema de replicación para asegurar que esas transacciones son almacenadas en el sitio de contingencia.

Por esta razón es que 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.

En los casos en los que los RPO y RTO pueden soportar valores de tiempo más altos, se pueden utilizar esquemas de replicación manual, basados por ejemplo en la restauración de backups; este tipo de esquemas requiere que no haya una variación importante de los datos en cualquier período de tiempo, de forma de optimizar los ciclos de toma de backup.

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

Hasta aquí, espero haber sido capaz de demostrar los principales ítems sobre la complejidad subyacente de las soluciones de redundancia y contingencia, porque ésa fue la parte sencilla del artículo… ahora comienzan las complicaciones de verdad!

Es que tanto los modelos de redundancia como los de contingencia son, principalmente, soluciones básicamente tecnológicas. Si bien en los esquemas de contingencia es necesaria la implementación de procesos de operación que garanticen el funcionamiento, la mayor carga de responsabilidades está todavía sobre los componentes tecnológicos… si es que se me permite la licencia de asignarle responsabilidades al hardware y al software, lo cual no es una concesión que deba pasar desapercibida!

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 Ud. 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.

Creo que el ejemplo es básico pero representativo: la empresa no solamente necesita tecnologías que funcionen, sino también que la gente pueda hacer uso de ellas, hablar por teléfono, recibir correos, recibir órdenes de compra, administrar el stock, entre tantas otras operaciones que forman parte de lo que se conoce bajo el nombre de “procesos críticos del negocio”, o dicho de otra forma: aquellas actividades que significan que la compañía sigue en movimiento a pesar de todo.

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, en castellano: análisis de impacto en el negocio), 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.

La realización de un BIA es una tarea compleja, que típicamente requiere de ayuda externa por parte de especialistas que ya hayan transitado este tipo de procesos más de una vez.
La experiencia, el conocimiento técnico y normativo, y los buenos instintos pueden ayudarnos a diseñar infraestructuras de continuidad del negocio, pero sin duda la forma correcta de hacerlo (y la única que puede ofrecer garantías en la organización) es comenzando por el desarrollo de un BIA hecho a consciencia.

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

Hasta el momento, hemos sabido demostrar que para cada uno de los términos presentados, el nivel de complejidad en la comprensión e implementación ha ido en aumento; en este punto, si se me permite, quisiera agregar un nuevo ingrediente para hablar de resiliencia, y se trata ni más de menos de un toque de mística.
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!

Si tenemos en cuenta que en el ámbito de la filosofía y la psicología todavía no existe un acuerdo sobre qué es una persona “sana” o una persona “normal” (recomiendo los trabajos de Georges Canguilhem al respecto de la normatividad en general), qué podíamos esperar de qué significa en TI el funcionamiento aceptable de un sistema, para lo cual es necesario lograr el acuerdo de toda una organización, incluyendo clientes y proveedores.

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.

Tengamos en cuenta que la resiliencia se analiza a nivel de sistema: ya no importa tanto saber cuál es el ambiente productivo y la contingencia, dónde se encuentran, a qué servidor me estoy conectando, dónde están los datos… lo importante es obtener garantías de servicio sobre qué capacidad de trabajo tendrán disponibles los usuarios, durante la mayoría del tiempo.

El diseño de infraestructuras sistémicas con alto nivel de resiliencia es un campo muy fértil sobre el cual todavía no se han presentado las mejores ideas, y donde hay un gran espacio abierto a la innovación y la generación de conocimiento. Es muy probable que durante los próximos 5 años veamos aparecer varias alternativas tanto en el campo de las ideas como en el del hardware y el software.

Conclusiones

A través de la presentación de estos cuatro términos, hemos omitido intencionalmente hablar de “alta disponibilidad”, esperando que llegara el momento de las conclusiones para hacerle justicia a otro de los términos sin duda más vapuleados de las TI.

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 presentemos 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.