Uno de las preocupaciones más habituales de los usuarios que están subiendo su infraestructura a Cloud, es la configuración de la alta disponibilidad de los equipos, y la seguridad ante caídas del servicio.
Y en eso Azure, al igual que todas las nubes actuales, ofrecen sistemas automáticos de redundancia, que son complementados con configuraciones específicas.
Vamos a verlo.
Nivel regiones pareadas. El Disaster Recovery de Azure
Como ya sabes, Azure es una plataforma Cloud que está desplegada en Windows Cloud, en más de 36 regiones a lo largo y ancho del mundo. Y estás regiones, a su vez, están compuestas por múltiples centro de datos los cuales, a su vez, albergan miles de servidores en armarios.
El primer nivel de redundancia, más bien automático, son las regiones emparejadas. Es decir, dos grupos de centros de datos que están cableados físicamente entre ellos, que están dentro de la misma Zona geográfica (a excepción de Brasil), y que están situados (al menos) a 300 km. entre sí.
Para una información más detallada pásate por está página de Microsoft. Pero resumiendo, esté mecanismo es que utiliza internamente Microsoft para aplicar secuencialmente las actualizaciones de la plataforma, para dar soporte de alta disponibilidad frente a caídas a nivel de Región (un disaster recovery en toda la regla), y como almacenamiento secundario en la redundancia geográfica de algunos servicios.
Zonas de disponibilidad, fallos a nivel de CPD
A nivel de Región tenemos la nuevas Zonas de disponibilidad, que cubren los fallos a nivel de CPD (Centro de datos). Recuerda que casi cada región está compuesta por triadas de Data Centers, los cuales están comunicados por triadas.
Igual que las Regiones pareadas, cada una de las zonas está cableada directamente entre ellas con una red de alta velocidad (permite hacer comunicaciones más eficientes y directas entre CPDs), y aquí podremos configurar en donde queremos poner cada una de las copias de nuestra, por ejemplo, máquina virtual.
A nivel de Rack, Conjunto de disponibilidad
El siguiente nivel es un poquito más complejo, pero es imperativo si queremos que Azure nos cubra con un SLA del 99,95% de disponibilidad.
Primero tengo que explicar que estos conjuntos se pueden configurar en cualquier momento, pero las máquinas virtuales y las máquinas virtuales se deben asignar al conjunto, en su creación. Luego ya no se puede.
Luego, este servicio está diseñado para cubrir dos tipos de fallos. El primero es el fallo no planificado o Fault Domain (la rotura de un disco, el fallo de la alimentación eléctrica de un rack, etc); y el segundo son las paradas planificadas para la actualización de la plataforma de Azure o Update Domain.
Para el primer tipo de fallo, Azure nos permite escoger tres racks físicos diferentes en donde situar nuestras diferentes máquinas virtuales, formando algo similar a un cluster.
Para el segundo, voy a poder indicar el orden -hasta 20 máquinas virtuales- en que quiero que las apague, las actualice y las vuelva a poner en funcionamiento.
En ambos casos, estoy evitando que la caída o actualización en un Rack o máquina, me deje sin servicio.
Como he dicho antes, esto es obligatorio si quiero estar dentro del SLA de Azure. Lo cual es un fastidio porque me obliga a tener duplicadas o triplicadas cada máquina virtual (y más cuando vea la redundancia física que hay por debajo).
Sin embargo, desde hace un par de años, Azure ofrece un SLA un poquito menos potente, si utilizamos una cuenta de almacenamiento Premium. Y esto es así, porque ya no nos obliga a tener más de una VM, si no que se encarga la propia plataforma de tener una copia (de forma interna) para estos menesteres.
A nivel físico, redundancia de datos
Por último, a nivel físico nos encontramos con la redundancia que ofrece Azure, y que podemos mejorar por medio de la configuración.
Cuando creamos cualquier cuenta de almacenamiento en nuestra suscripción para almacenar un VHD, o un Blob de ficheros de imágenes, Azure almacena tres copias de dichos datos de forma local.
Dos copias las guarda en el mismo Rack, y la tercera la guarda en un segundo Rack dentro de un mismo CPD.
Sin embargo, puedo mejorar está disponibilidad si le digo que quiero hacer replicación de Zona de mis datos. Ya que, esa tercera copia que tenía en un segundo Rack, la voy a almacenar en un CPD de la Región pareada.
Por último, si lo veo necesario, puedo hacer una georeplicación, en donde el conjunto de las tres copias, en dos racks del mismo CPD, sea desplegado en una región lejana (fuera de mi Zona), configurando seis copias de mis datos.
Creo que con esto, está claro que perder datos en Azure es, prácticamente, imposible.
Espero que sea de utilidad.