Como te he mostrado en el artículo anterior de esta serie dedicada las cuentas de almacenamiento, la replicación es el mecanismo que utiliza y ofrece Azure para asegurar la disponibilidad de los datos; es decir la seguridad de no perderlos.
Pero como todo en esta Cloud, las cosas son un poquito más complejas y quiero resumirlas para poder tomar decisiones al diseñar una arquitectura.
¿Cómo protegen y debo proteger mis datos?
La replicación local -tres copias en un mismo «CPD»- es el mecanismo fundamental de Azure para conseguir, al menos, una disponibilidad del dato del 99,999999999999%.; en un sistema automático totalmente transparente para el usuario en casos de fallos o actualizaciones, sean previstas o no.
Además hay que tener muy en cuenta que esta es la única replicación que permite utilizar Azure tanto para los discos duros gestionados, como para todas las cuentas que sean Premium. Y en general, para todos los «sabores» de las cuentas de almacenamiento a excepción (por ahora) de los blobs de bloques.
Por lo cual, si «casca» uno de los «discos duros» de las tres réplicas, Azure se encarga de forma automática de hacer los cambios que tenga que hacer para que nosotros no nos demos ni cuenta.
Y si hay un incendio o inundación en el «CPD» donde están nuestras tres réplicas… pues vamos a perder nuestros datos. (mucho ojo con los discos duros de las máquinas virtuales).
¿Qué posibilidad hay que ocurra un fallo catastrófico? Realmente es ridículamente pequeña.
Subiendo el nivel de protección a Zonas
El siguiente nivel es la replicación por Zona, donde Azure va poner cada una de las tres réplicas en su propio «CPD» dentro de una misma región de Azure. Así que debería ocurrir una verdadera catástrofe como para que se llegue a perder una región y los datos que almacena.
Incluso en un caso similar al reciente fallo en la India en donde se había dejado sin enganchar al generador dos zonas completas en una caída general del servicio eléctrico, aún así tendríamos la copia de la tercera zona.
En esta configuración de replicación, también Microsoft se encarga de manera transparente de hacer los cambios necesarios para seguir accediendo a mis blobs de bloques; y aumenta la SLA de disponibilidad hasta llegar a los 16 nueves.
Tomando el control de nuestros datos
Para poder asegurar aún más mis datos, siendo la arquitectura que recomienda Azure, debo optar por las dos formas de replicación geográfica en donde voy a mandar tres copias de mis datos a una región secundaria que nos asignará Azure.
Así, si desaparece mi región primaria por una catástrofe, tengo un conjunto de copias a la que, incluso, puedo acceder en modo solo lectura.
En el momento de escribir estas líneas, Azure permite probar en modo preview la capacidad de poder lanzar de forma manual un failover que le indica a Azure que convierta la región secundaria en la principal, y así recuperar la funcionalidad completa de forma muy sencilla.
Ojo, que eso implica cambio de los DNS de los endpoint y mis aplicaciones deben ser capaces de soportar este cambio por medio de código, del uso de balanceadores de carga, y/o del patrón de Retry dentro de un Circuit Break.
¿Y qué hay acerca de la Resiliencia?
Para resumirlo, por defecto Azure utiliza la replicación local para proteger mis datos, y en la mayoría de los datos será más que suficiente. De hecho, nunca he conocido ni oído de perdida de datos en Azure a causa de la plataforma.
Cuanto más críticos sean mis datos, su accesibilidad y su disponibilidad, más potentes son los mecanismos que me ofrece Azure. Pero siempre teniendo muy presente que finalmente solamente yo soy el último responsable de mis datos.
Espero que sea de utilidad.