En mi carrera profesional como ingeniero de soluciones, me ha tocado abordar el tema de recuperación de desastres y continuidad de negocios con múltiples clientes en toda la región de Centro América y Caribe.
A parte de los típicos temas de como definir la arquitectura a emplear, hay un aspecto que siempre genera un debate entre TI, los LOBs (Line of Business) y mi persona como arquitecto de la solución que se va a proponer. Este se basa en como definir el RTO y RPO óptimos para el ambiente a ser protegido en caso de una situación fortuita o un error humano del cual nadie esta exento.
En esta oportunidad me interesa enfocarme mas desarrollar todo lo relacionado con el RTO que con el RPO, donde este segundo depende mas de la tecnología de replicación que se emplee y de la cantidad de datos que el cliente este dispuesto perder en caso de una eventualidad en su infraestructura.
Cuando hablamos de RTO, en términos muy simples podríamos decir que es el tiempo en que se demora el sitio alterno después del iniciado la conmutación automática o failover, en tener todos los servicios activos, en línea y listos para ser promovidos como primarios durante el tiempo que se lleve subsanar la situación que haya dejado inoperante el sitio principal.
Asumiendo que ya se tiene claro y definido el RPO ideal y por ende que tecnología de replicación se va a emplear, voy a detallar en base a mi experiencia personal, los principales aspectos me he encontrado en múltiples proyectos, que influyen en que un RTO sea mas o menos eficiente una vez iniciado el proceso de failover:
- Arquitectura aplicacional: Sin importar que hablamos de aplicaciones tradicionales o de nuevas tecnologías basadas en contenedores y microservicios, tenemos que tener claro la forma apropiada y controlada de dar de alta estas aplicaciones, sin dejar de lado que primero debe de estar operando previamente todas aquellas dependencias del centro de datos como son el DNS, Active Directory, LDAPs, etc, ya que si éstas, las aplicaciones no estarán accesibles.
- Cantidad de aplicaciones críticas o de nivel 1: Si bien, siempre los clientes tienen la expectativa de tener el 100% de su ambiente replicado en el sitio alterno, basándose en un estudio de análisis de riesgo del negocio y/o seguridad, no siempre es posible, práctico o viable en términos técnicos y financieros. Dependiendo de cuantas aplicaciones de nivel 1 se tengan que iniciar, tendremos que considerar el ejercicio de medirlas con cronometro en mano para tener una expectativa del tiempo que debamos considerar.
- Procesos de ejecución manual: En DRP tradicionales, como por ejemplo estrategias de recuperación y continuidad “hechas en casa” o en escenarios donde el cliente adquirió solamente una herramienta para replicar, hay un alto número de procesos manuales a ser ejecutados por el personal de TI (Runbooks) para habilitar el ambiente alterno durante el proceso de failover. Esto no solo es puede resultar lento, si no también altamente propenso a error humano. A la lentitud de los procesos manuales, también hay que agregar la disponibilidad de los recursos humanos que realizan los mismos. No es lo mismo hacer una prueba de recuperación con todo el personal listo en sus puestos de trabajo, que tener que contactar a cada uno de ellos para que puedan acceder local o remotamente a los sistemas y ejecuten la recuperación.
- Reconfiguración a nivel de la red: Ya sea por costos, limitaciones de infraestructura o por distancia, no siembre es posible contar con una conexión L2 entre sitios, por ende, la reconfiguración y actualización del direccionamiento IP es un aspecto inevitable de abordar en estos casos. Al final, esto representa un peaje mas en términos de tiempo que debemos de sumarle a la variable del RTO.
En este punto, es donde como arquitecto de soluciones, comienzo mostrarles a mis clientes, como la “automatización” puede volverse un catalizador muy interesante de explorar en este tipo de estrategias de continuidad y recuperación de desastres. De los cuatro puntos mencionados anteriormente, tres de ellos son automatizables, dándole a la solución propuesta un RTO mucho mas expedito y predecible, donde el componente de error humano se puede ver minimizado o prácticamente eliminado de la ecuación.
Al diseñar la arquitectura, busco tener la capacidad de ejecutar planes de recuperación requeridos sin intervención humana, dándole espacio a que sea la automatización quien orqueste el proceso de llevar a cabo el failover entre sitios. Aquí es donde una herramienta como Site Recovery Manager o SRM, permite tener la capacidad de automatizar completamente la forma en que se ejecuta el o los planes de recuperación que sea han previamente definido como parte de la estrategia de resiliencia entre centros de datos.
En pruebas de concepto, así como en implementaciones finales, gracias a la capacidad de poder disponer de un orquestador que opera de forma totalmente automática los planes de recuperación, el RTO requerido para promover el sitio alterno como primario es mucho menor. Ahora bien, es valido preguntarse, es viable optimar aun mas esta estrategia de recuperación y continuidad de manera que se pueda lograr un tiempo de RTO aún mas pequeño. ¿Se puede?
En efecto se puede. Vale la pena mencionar que si bien el cuarto punto descrito anteriormente es algo que no necesariamente deba ser considerado si se cuenta con conectividad entre sitios a nivel de L2 o si se dispone de una topología de Cluster Extendido; (tema para otro blog), no siempre son estos los escenarios con los que debo de lidiar. En muchos de los proyectos he visto la necesidad de emplear conectividad L3 o incluso servicios como MPLS para interconectar las distintas localidades de una empresa, sin mencionar todos lo elementos de seguridad como firewalls, IDS, IPS, etc, así como dispositivos de enrutamiento que ineludiblemente deben de ser contemplados.
En estos escenarios, es donde podemos tomar ventaja de las nuevas bondades que la virtualización ofrece, nada mas que en este caso, específicamente estoy hablando de lo que la tecnología en redes virtualizadas nos puede aportar. En efecto estoy hablando de integrar las funcionalidades de las redes definidas por software en nuestra estrategia de recuperación de desastres, buscando hacer que nuestro plan de recuperación sea aún mas sencillo y automatizado dado que, aunque no cuente con una extensión de medios a nivel de L2, puedo obviar el hecho de tener que reconfigurar y remapear todos mis elementos activos de red a la hora de hacer un failover entre sitios. ¿Como se puede lograr eso?
Al incorporar a VMware NSX DataCenter dentro de la arquitectura propuesta, se abre un portafolio de mas de 38 casos de uso, donde unos de ellos es la capacidad de extender de redes entre sitios, haciendo posible la creación de zonas de transporte universales entregables a las cargas virtuales y físicas (L2VPN).
Esto nos permite resolver los temas de L2 y L3 al poder crear segmentos de red entre diferentes localidades sin necesidad de incorporar elementos de enrutamiento en medio y simplificando dramáticamente la forma en integro la seguridad, logrando hacer planes de recuperación mas simples a la hora de un failover. Dado que ya no es necesario que las máquinas virtuales dadas de alta en el sitio alterno tengan que se reconfiguradas en términos de conectividad, esto gracias a que los segmentos de red virtuales entre en el sitio alterno y el sitio principal son los mismos, hace posible lograr niveles de RTO hasta un 80% mas expeditos en los momentos en los que cada segundo apremia.
A manera de conclusión, deseo cerrar este tema mostrando la evidente mejora lograda con la integración de NSX DataCenter con Site Recovery Manager, lo cual crea una dupla perfecta en términos de automatización e infraestructura. Este binomio no solo nos permite simplificar de todos los procesos involucrados en una conmutación automática, si no que también indistintamente el RPO definido y la tecnología de replicación elegida, es viable mejorar el RTO a niveles que antes no era posible, gracias al aporte que la automatización ofrece, así como la simplificación lograda a nivel de infraestructura de redes empleando la tecnología de VMware NSX.
Autor:
