18 Mar 21
“Solo quería felicitaros por lo bien que os ha funcionado la alta disponibilidad porque no hemos notado nada 🙂 Buen trabajo. Tengo varios proveedores grandes que están mordiendo el polvo”.
Este mensaje llegó a Transparent Edge en un email de un cliente el mismo día en el que uno de los centros de datos de uno de los proveedores de hosting más grandes de Europa, OVH, había ardido en Estrasburgo en un incendio declarado por causas aún desconocidas. Afortunadamente no hubo que lamentar daños personales, pero muchas páginas y servicios en Internet que dependían de este proveedor quedaron fuera de combate. Según declaró ese mismo día en Twitter el propio Octave Klaba, fundador de OVH, era imposible acceder a la zona incendiada, por lo que el rescate de datos o el reinicio de los servidores no podía contemplarse aún. Muchos usuarios quedaron desconcertados preguntándose qué hacer.
Entre esos usuarios -ya lo has visto- no estaba el cliente con cuyo email comenzábamos este post. Tampoco ninguno de los demás clientes de CDN de Transparent Edge. ¿Te imaginas por qué no? Vamos a contártelo.
Tras informar en Twitter de que el incendio impedía el rescate de datos y el reinicio de los servidores, Octave Klaba, el fundador de OVH, recomendó en un tuit posterior activar el Disaster Recovery Plan. Pero, ¿qué es esto?
Un DRP (abreviatura de Disaster Recovery Plan, Plan de Recuperación ante Desastres) es un procedimiento de recuperación de activos informáticos, siendo estos tanto hardware como software y datos. Su principal misión es recomenzar las operaciones normales de la empresa cuanto antes en caso de una catástrofe, ya sea esta un desastre natural o un desastre por causas humanas. La premisa principal es “desear lo mejor, pero planificar lo peor”, de manera que cualquier inconveniente posible a nivel informático debería estar contemplado para intentar recuperar la actividad lo antes posible, sea cual sea el problema.
A pesar de que es imposible tener previsto todo lo que pueda pasar, hay que hacer un ejercicio de imaginación ante los eventos que pueden surgir, así como las medidas para minimizar los riesgos más comunes.
Entre otros factores, algunos de los más importantes son la redundancia de sistemas, las copias de seguridad (siempre en ubicaciones distintas tanto físicas como lógicas), la comunicación a clientes para minimizar el pánico y la comunicación de procesos a nivel interno para asignar las tareas de recuperación de la manera más veloz y eficiente posible.
Si Transparent Edge trabaja con OVH, ¿por qué no nos caímos? En este punto entra uno de los factores anteriormente comentados, la redundancia de sistemas, y un concepto íntimamente ligado a ella: la HA o alta disponibilidad (High Availability). Podemos definirlo como un diseño del sistema resiliente ante caídas o indisponibilidad de un subsistema concreto, de manera que el servicio continúe sin afectación de cara al cliente.
En Transparent Edge contamos con varios sistemas de HA en nuestra CDN, que garantizan que la caída de un nodo (¡o un datacenter completo!) no afecta al servicio, ya que las máquinas afectadas se sustituyen en segundos por otro nodo no afectado en una ubicación cercana para que el usuario final pueda seguir navegando por la web sin notar nada.
En círculos de toma de decisiones, frecuentemente no relacionados con IT, se suele decir que estos sistemas son caros puesto que se basan en tener elementos duplicados o una arquitectura sobredimensionada a las necesidades reales. Como hemos visto con el incendio en OVH, lo realmente caro es no tenerlos.