Alta disponibilidad y recuperación ante desastres

01

Las fallas van a ocurrir: cifras de disponibilidad y puntos únicos de error

La disponibilidad es la proporción del tiempo en que tu servicio se pudo usar. Un 99.9% suena bastante alto, pero en un año significa unas 8 horas y 45 minutos sin servicio. Cada 9 que agregas reduce a la décima parte la inactividad permitida, y el costo y el diseño se complican en la misma medida.

En cadena baja; en paralelo sube

Un servicio está hecho de varios componentes encadenados. Si una respuesta tiene que pasar por un servidor web, luego por un servidor de aplicaciones y luego por una base de datos, los tres tienen que estar funcionando. Por eso la disponibilidad total es el producto de la disponibilidad de cada componente. Si encadenas tres componentes de 99.9%, bajas a cerca de 99.7%. En cambio, si pones dos servidores iguales uno al lado del otro, esa capa solo cae si caen los dos, y sube hasta 99.9999% (suponiendo que las fallas de los dos son independientes). En la escena de abajo, prueba a duplicar cada capa.

Un punto que, si se detiene, detiene todo se llama punto único de error (SPOF). Diseñar para la alta disponibilidad es buscar los puntos únicos de error y eliminarlos uno por uno. Y no solo los servidores: una base de datos, un equilibrador de carga, una ruta de red e incluso «la única persona que sabe cómo está configurado este servidor» pueden ser un punto único de error.

Un SLA no es una garantía, sino una promesa de compensación

Cada servicio en la nube promete un tiempo de actividad mensual en su SLA (acuerdo de nivel de servicio). Aquí viene lo que confunde a mucha gente: un SLA no garantiza que «va a funcionar sí o sí este porcentaje», sino que promete que «si no lo cumplimos, te devolvemos una parte de la factura en créditos». No cubre lo que pierdes mientras estás sin servicio, así que la disponibilidad de tu propio servicio tiene que salir de tu diseño. Incluso para el mismo servicio, el SLA es más alto cuando lo repartes en varias zonas que cuando usas un solo servidor.

Para eliminar un punto único de error, pasaste de un servidor a dos. Pero ¿y si esos dos están en el mismo edificio?

02

El tamaño de una falla: servidores, zonas y regiones

Las fallas tienen distintos tamaños. A veces se estropea el disco de un servidor. A veces un centro de datos entero se detiene por un corte de energía, un incendio o una falla de red. Y, de vez en cuando, toda un área geográfica se detiene por un desastre natural o una caída a gran escala. El alcance que tiene una sola falla se llama radio de impacto (blast radius).

La nube te muestra ese alcance dividido en zonas de disponibilidad y regiones. Una región es un área geográfica, como Seúl o Tokio, y dentro de ella hay varias zonas de disponibilidad: grupos de centros de datos, cada uno con energía, refrigeración y red independientes. Las zonas están lo bastante cerca para permitir la replicación síncrona (unos pocos milisegundos de latencia), pero lo bastante lejos para que un desastre en una no se extienda a otra.

La mayoría de los servicios en producción usan varias zonas como base. Como están en la misma región, la latencia es lo bastante baja para replicar la base de datos de forma síncrona, y aguantas la falla de una zona. Solo te extiendes a varias regiones cuando también tienes que aguantar la falla de una región (por leyes y normativas, o en servicios muy grandes), y cómo hacerlo son las estrategias de recuperación ante desastres del capítulo 7.

Para decidir cuánto tienes que aguantar, primero necesitas un objetivo. ¿Cuánto tiempo puedes permitirte estar sin servicio y cuántos datos puedes permitirte perder?

03

Qué proteger y cuánto: RTO y RPO

Cuando diseñas la recuperación ante desastres, hay dos números que se deciden antes que nada. El RPO (objetivo de punto de recuperación) es «cuántos datos puedes permitirte perder cuando algo falla», expresado en tiempo. El RTO (objetivo de tiempo de recuperación) es «cuánto tiempo puedes permitirte estar sin servicio».

Se entiende mejor si pones el momento de la falla en el centro. Hacia atrás, todo lo que hay desde el último punto en que protegiste tus datos (la última copia de seguridad o replicación) son los datos que pierdes: ese es el RPO. Hacia adelante, todo el tiempo hasta que el servicio vuelve a abrir es tu inactividad: ese es el RTO. En la escena de abajo, prueba a cambiar cómo proteges los datos y cómo recuperas.

Estos dos objetivos los fija el negocio, no la tecnología. Un sistema de pedidos pierde mucho aunque esté caído un solo minuto y no puede perder ni un pedido, mientras que un sistema interno de informes quizá aguante un día sin servicio. Cuanto más ajustado es el objetivo, más alto es el costo, así que para cada sistema pones en la balanza las pérdidas y el costo. Si recuperar cuesta más de lo que te haría perder la falla, pusiste el objetivo demasiado alto.

Ya tienes los objetivos; ahora toca evitar que se detenga. Empecemos por cómo hacer que los servidores aguanten cuando las solicitudes llegan de golpe.