RPO y RTO

Cuando se habla de la Gestión de la Continuidad del Negocio siempre hacemos referencia a los Planes de Continuidad del Negocio o BCP, que no sólo tratan de darle continuidad a la organización ante eventos catastróficos sino también controlar los picos de producción, accidentes, bajas de los empleados, end-of-life de productos y servicios, etc. Por otro lado, se encuentran los Planes de Recuperación ante Desastres o DRP que tienen una componente más técnica tratando de dar continuidad a los sistemas de información con el objetivo de minimizar la no disponibilidad ante cualquier problema.

A la hora de elaborar el Plan de Recuperación ante Desastres hay que tener en cuenta dos conceptos importantes que nos ayudan a decidir qué tecnologías implantar en la organización. Estos conceptos son el tiempo de tolerancia o RPO y el tiempo de recuperación o RTO.

El tiempo de tolerancia (RPO) es el que determina la cantidad de datos que estamos dispuestos a perder, es decir, si por ejemplo tan solo hacemos una copia de seguridad a la semana estamos dispuestos a perder el trabajo desarrollado durante la última semana. Según la imagen anterior, podemos ver que a menor RPO mayor exigencias en la replicación de datos, pasando de tener los datos redundados en tiempo real a realizar copias de seguridad en cintas para enviarlas a otro edificio.

El tiempo de recuperación (RTO) es el que determina la cantidad de tiempo de no disponibilidad que estamos dispuestos a asumir ante un problema, es decir, durante cuánto tiempo la organización puede permitirse tener los sistemas apagados sin afectar considerablemente a la continuidad del negocio. Según la imagen anterior, podemos ver que a menor RTO mayor exigencias en la disponibilidad de los servicios, pasando de tener los sistemas y aplicaciones en alta disponibilidad en modo activo/activo a disponer de sistemas de repuesto listos para su configuración y uso.

Aunque a todos nos gustaría tener tecnologías que nos permitan bajar los tiempos RPO y RTO, siempre debemos ser conscientes que a menor RPO y RTO mayor coste de adquisición y mantenimiento de los sistemas, ya que todo se duplica por dos o incluso tres. Ambos tiempos deberán ser definidos y aprobados por Dirección, y siempre alineados con los Acuerdos de Nivel de Servicio pactados con los clientes.

Gestionar plataformas exigentes en cuanto a disponibilidad, parece algo interesante y apasionante para todo ingeniero, sin embargo cuando surge un incidente dejando a los clientes sin servicio, cada minuto se hace eterno hasta que consigues encontrar la solución o una alternativa, mientras tanto nuestro corazoncito y salud va en detrimento. Por este motivo, si de verdad nos interesa la continuidad del negocio es aconsejable implantar los controles de la ISO 22301, que aunque no nos garantizará la disponibilidad 100% de los servicios, nos ayudará a prestar los servicios con mayor calidad.

Ciclo de vida de implantación de productos

Recuerdo durante mi estancia en la Universidad haber estudiado, una y otra vez, el ciclo de vida del desarrollo de software (SDLC). Exactamente tuve cuatro asignaturas (Análisis y Diseño de Sistemas, Ingeniería del software – Proyecto, Ingeniería del software – Especificación e Ingeniería del software – Diseño) donde estudié en profundidad las fases de desarrollo del software con la idea de que algún día pudiese desempeñar las tareas de Director de Proyectos o Analista. Sin embargo, mucho han cambiado las cosas, ya que desde que terminé la carrera de Ingeniería Informática no he participado en proyectos de desarrollo de software sino más bien en proyectos de implantación y soporte de productos de terceros. ¿Quiere decir que todo lo que estudié en estas asignaturas fue una pérdida de tiempo? En absoluto, tan solo hay que modificar las fases de diseño y desarrollo, permaneciendo todas las demás fases intactas, para llevar a cabo un proyecto de implantación de una solución desarrollada por un tercero.

A continuación veremos las fases del ciclo de vida para la implantación de un producto desarrollado por un tercero:

Fase 1 - Estudio de factibilidad: Consiste en determinar los beneficios estratégicos que se obtendrán al implantar el nuevo producto, ya sea para ahorrar costes, ganar productividad o para diferenciarse de la competencia. En cualquier caso también hay que tener en cuenta la preparación de los usuarios y la madurez del negocio. Si la justificación del nuevo sistema es factible pasaremos a la siguiente fase.

Fase 2 – Definición de requisitos: Se define el problema o las necesidades que debe cumplir el nuevo producto, además de las funcionalidades y los requisitos de calidad de la nueva solución. En esta fase es importante que el consultor o analista entienda los problemas y necesidades para buscar la solución tecnológica que se adapte a los requisitos definidos.

Fase 3 – Elección y adquisición de la solución: Basándonos en los requisitos definidos, debemos pedir oferta de varios fabricantes a distintos proveedores. Además de valorar los requisitos técnicos y funcionales del producto, deberíamos valorar el soporte, la experiencia, facilidad de pago y viabilidad financiera de los proveedores y fabricantes. La elección del proveedor correcto con las habilidades adecuadas y del producto que cumpla con las necesidades de la organización serán cruciales para el éxito del proyecto.

Fase 4 – Diseño y Configuración: Consiste en diseñar la integración del nuevo sistema con los existentes y su posterior configuración para adaptarlo a las necesidades de la organización.

Fase 5 – Implantación y Pruebas: Comenzaremos documentando el proceso de implantación y las pruebas a realizar para validar la instalación. Una vez implantado el nuevo sistema, realizadas las pruebas y pasado a producción es conveniente analizar la efectividad de la solución, realizar un análisis de riesgos y proveer de los controles internos necesarios que nos alerten si el nuevo sistema implantado deja de cumplir con los objetivos marcados por la organización.

Fase 6 – Post-implantación: Además de mantener el nuevo sistema, hay que analizar si la implantación del nuevo producto cumple con el ahorro de coste, el aumento de producción o la mejora de competitividad esperada. También es interesante quedar reflejadas las lecciones aprendidas, deficiencias y recomendaciones para futuros proyectos.

Tanto si vamos a implantar un nuevo producto, como si vamos a realizar una auditoría de los sistemas de información, es importante conocer el ciclo de vida de los sistemas de información para hacer cumplir y comprobar que se están siguiendo cada una de las fases adecuadamente sin boicotear la estrategia de la organización alejándonos de los objetivos marcados por Dirección.

Global Server Load Balancing

Cuando el principal foco de negocio de una organización se encuentra en Internet, donde en tan solo unos minutos de no disponibilidad de sus servicios puede llegar a suponer pérdidas monetarias, reputación, imagen, confianza, credibilidad, etc haciéndoles perder clientes, la disponibilidad de sus servicios para mantener los clientes, cumplir los acuerdos de nivel de servicio (SLA) y mejorar la competitividad es una clave fundamental para la continuidad del negocio.

Los balanceadores de carga nos permiten crear cluster de servidores proporcionando alta disponibilidad ante un fallo hardware en uno de los nodos del cluster. Sin embargo, al encontrarse todos los nodos del cluster en el mismo CPD o depender de una base de datos o SAN determinada, nos limita la alta disponibilidad ante una catástrofe, un fallo eléctrico, errores de mantenimiento o actos terroristas. Además, si proporcionamos los servicios desde un CPD compartido entre varias empresas, ante un Ataque DDoS a cualquiera de las empresas, puede llegar a saturarse el ancho de banda o sobrecargarse los routers de core del proveedor, teniendo como resultado la no disponibilidad de todos los servicios alojados en el CPD. Pocos CPDs son capaces de soportar un ataque smurf de 300Gbps como el que sufrió spamhaus el año pasado.

Una solución sería replicar el CPD proporcionando alta disponibilidad y balanceo de carga entre distintos CPDs, para ello podemos utilizar Global Server Load Balancing (GSLB) en modo Activo/Pasivo o Activo/Activo. La finalidad de una solución GSLB es asegurar la continuidad del negocio proporcionando alta disponibilidad incluso cuando un CPD no esté disponible, además de mejorar la experiencia de usuario ya que la solicitud la procesa el CPD más cercano disminuyendo considerablemente los tiempos de respuesta. Podemos diferencia cuatro escenarios de despliegue de GSLB:

Balanceo de carga basándonos en el DNS: La mayoría de soluciones de GSLB utilizan esta técnica manejando la resolución de nombres DNS, dependiendo del origen de la solicitud y de la carga de los nodos (CPDs), el servidor DNS devolverá la IP de un CPD u otro. Para ello será necesario bajar el TTL, así la cache de los servidores de DNS de Internet olvidarán inmediatamente el par Nombre-IP y todas las solicitudes siempre serán redirigidas a nuestro servidor DNS. Como inconveniente tenemos que el tráfico de DNS contra nuestros servidores se verá incrementado.

Redirección a nivel de aplicación: Protocolos como HTTP permiten redirigir las solicitudes, por ejemplo si queremos acceder a www.davidromerotrejo.com se nos puede redirigir a us.davidromerotrejo.com balanceando la carga a un CPD alternativo.

Triangulación: Con esta técnica un CPD recibe la petición y la reenvía a otro CPD, existiendo dos escenarios:

• Balanceo en capa 4: Un CPD recibe la petición y se lo reenvía a otro CPD, este último es el que responde al cliente, por lo que se producen tres saltos.
• Balanceo en capa 7: Un CPD recibe la petición, se lo reenvía a otro CPD y este último se lo vuelve a reenviar al primero que es el encargado de contestar al cliente, por lo que se producen cuatro saltos.

La técnica de triangulación, balancea la carga pero no mejora los tiempos de respuesta, además consume mucho ancho de banda.

Modificando la tabla de rutas BGP: Podemos mover bloques de direcciones IPs de un CPD a otro. Para ello se requiere la intervención del ISP para que proporcione mecanismos de failover. Esta última opción suele ser la más costosa.

Para afrontar un proyecto de continuidad del negocio, además de redactar las políticas y procedimientos y disponer de un CPD alternativo, hay que tener muchas otras cosas en cuenta como la sincronización de los datos y el balanceo de carga entre CPDs o GSLB.

¿Te puedes permitir apagar el CPD? ¿durante cuanto tiempo?

Balanceadores de Carga

Cada vez existen más servicios en Internet y la demanda de estos por parte de todos nosotros continúa creciendo. La disponibilidad y la rapidez en la respuesta de un determinado servicio depende de muchos factores, sin embargo uno de ellos es la capacidad y disponibilidad de los servidores finales encargados de procesar la petición y responder con la mayor brevedad posible. Para garantizar la fiabilidad de los servicios a veces es necesario formar cluster de servidores que permitan balancear la carga del servicio utilizando balanceadores de carga dedicados para tal fin. De esta manera por ejemplo ayudaríamos a prevenir el colapso de nuestros servicios ante una gran demanda de solicitudes, evitando titulares como que la web porno de Marc Dorcel se colapsó en 45 segundos.

Aunque ya tenía experiencia en balanceadores F5 y Radware AppDirector, en estos últimos meses he tenido la oportunidad de conocer y profundizar los balanceadores de carga FortiADC y Radware Alteon. El estudio de estos últimos ha sido hasta tal punto que he obtenido la certificación “Radware Certified Application Specialist on Alteon (RCAS-AL)”, acreditando que tengo los conocimientos para instalar y mantener equipos Radware Alteon utilizando la CLI así como la interfaz de usuario GUI, además de conocer los mecanismos de balanceo de protocolos de capa 4 a capa 7, realizar instalaciones y mantener equipos en standalone o en alta disponibilidad mediante VRRP, crear escenarios de SSL Offloading instalando y actualizando certificados SSL, además de poseer los conocimientos para realizar debbuging en los equipos.

Aparte de aprender a utilizar los equipos Alteon desde la CLI y la GUI, creo que lo más interesante que he aprendido es a reforzar mis conocimientos sobre los distintos tipos de diseño de despliegue de equipos balanceadores, independientemente del fabricante que sea. En un breve resumen podemos destacar los siguientes diseños:

Modo Route: Es el escenario más común, para ello la red debe ser segmentada en capa 3 diferenciando el segmento clientes de servidores. El balanceador puede hacer funciones de proxy inverso para securizar las aplicaciones, descargar a los servidores reales del cifrado/descifrado de datos, etc. Para su correcto funcionamiento es indispensable que la puerta de enlace de los servidores reales sea el propio balanceador.

Modo Transparente: En este escenario la red debe ser segmentada en capa 2 diferenciando el segmento de clientes y servidores. Aunque todas la comunicación (ida y vuelta) pase por el balanceador, éste no puede actuar como proxy inverso, sin embargo este diseño no requiere cambiar la puerta de enlace de los servidores, es decir, se puede mantener como puerta de enlace el router.

Modo One-arm: Es un escenario adecuado en entornos de demo ya que no requiere ningún cambio en el diseño de la red original. Para ello el balanceador realiza la función de Proxy IP cambiando la IP origen de las peticiones por la suya propia, es decir NAT en origen, de esta manera los servidores reales le contestan al balanceador sin tener que cambiarles la puerta de enlace. Como inconveniente perdemos la IP origen de las peticiones, aunque se puede subsanar incorporando el atributo x-forwarded-for en la cabecera HTTP.

Modo Direct Server Return (DSR): Es un escenario adecuado en redes de altas exigencias, ya que la respuesta de la petición balanceada no pasa por el balanceador, descargando al balanceador de dicha tarea. No es necesario segmentar la red y el balanceador perderá las funcionalidades de Proxy, ya que no tiene la posibilidad de analizar la comunicación completa entre el cliente y los servidores reales. A continuación podemos ver un ejemplo del despliegue DSR:

 

Además de lo comentado anteriormente, he podido probar en el laboratorio los distintos algoritmos de balanceo (roundrobin, leastconns, response time, bandwidth, etc), persistencia de sesiones (cookie, sslid), balanceo de carga basado en el contenido de la petición (URL, tipo de navegador, etc), además de otros aspectos como técnicas de ofuscación o DoS para proteger los servidores, vDirect para levantar máquinas virtuales bajo demanda, ADC-VX para gestionar balanceadores virtuales o GSLB para balancear servicios basándose en la proximidad del cliente o para balancear servicios entre distintos CPDs.

Y eso es todo amigos.