Alta disponibilidad en Azure (Virtual Machines)

Subir algo a la nube (independientemente de cuál ésta sea), no significa que de inmediato tendremos alta disponibilidad. Especialmente si hablamos de IaaS.

La alta disponibilidad en este contexto hace referencia a la capacidad que tiene un despliegue en la nube de seguir proveyendo los servicios que supone su implementación, aún cuando existan situaciones planeadas o no que afecten al hardware, al sistema operativo, a las comunicaciones o al propio software desplegado.

Si bien en la mayoría de casos, patchs de seguridad y actualizaciones y demás son aplicados automáticamente a las máquinas virtuales en Azure sin que se afecte su operación, en otras ocasiones un reinicio de las mismas es necesario. Otras veces fallos de red o hardware requieren que las VMs defectuosas sean restauradas en otras VMs, cosa que también genera un reinicio que si no tiene respaldo ocasionará un tiempo de discontinuidad de servicio.

Siendo algo muy obvio y no por ello menos relevante, el tener redundancia en los servidores es la alternativa por excelencia para proveer alta disponibilidad; fácil: si un servidor falla, el otro está allí para respaldarlo, mientras se reinicia el que falló (o el que se está actualizando si es que se trata de un mantenimiento programado)

Y Azure acoge éste hecho suministrando la infraestructura necesaria para optimizar esta redundancia de servidores en los despliegues de máquinas virtuales, a través de lo que se conoce como Availability Sets (conjuntos de disponibilidad).

En Azure, las máquinas virtuales se agrupan en VM Cloud Services (No confundir con los Azure Cloud Services de PaaS, conformados por Web y Worker Roles). Como usuarios podemos crear VM Cloud Services para agrupar VMs en términos de visibilidad de comunicación directa entre ellas. Entonces, las VMs que pertenecen al mismo VM Cloud Service se pueden comunicar entre sí sin necesidad de establecer una VPN y también pueden ser objeto de balanceo de carga interno. Pero lo más importante para este artículo, es que pueden ser ubicadas dentro del mismo Availability Set.

Esto nos indica que un Availability Set es un subconjunto de un VM Cloud Service. A su vez un Availability Set (AS) se divide en 5 Update Domains (UD) y en 2 Failure Domains (FD). Dentro de un Availability Set, Azure sólo reinicia las máquinas que estén en un UD particular, al mismo tiempo. Y sólo las máquinas que estén en el mismo FD comparten fuentes de poder, red y otros dispositivos físicos.

Supongamos que creamos el AS1 para nuestro despliegue. Y luego creamos la VM1 que tiene un servidor web. Ahora asignamos VM1 a AS1. De inmediato Azure se encarga de asignar esta VM a el UD1 y al FD1. Pero hasta aquí no tenemos alta disponibilidad. De hecho, cuando en un AS solo hay una VM, Azure claramente indica que el SLA de 99.95% no se garantiza. Es más, Azure se reserva el hecho de actualizar esa VM con operaciones que requieren reinicio sin previo aviso. OJO: Cuando solo usamos una VM dentro de un AS, Azure NO NOS AVISA cuándo van a haber mantenimientos programados. Estos mantenimientos solo se avisan, si tenemos dos o más VMs dentro de un AS, a través de correos que llegan a la cuenta administrativa con antelación.

Entonces para hablar de Alta Disponibilidad necesitamos crear un respaldo para VM1 llamado VM2, y lo asignaremos al mismo AS1 para obtener alta disponibilidad. Cuando lo hacemos, Azure también lo asigna a UD2 y al FD2.

Y en este punto ya tendremos alta disponibilidad automática. Por qué? Pues porque como VM1 y VM2 están en distintos UD, cuando algún UD reinicie sus máquinas, estaremos seguros que los otros cuatro UDs dentro del AS no se reiniciarán. Y de esa manera nos protegemos de los mantenimientos programados, pues siempre habrán servidores listos para atender. Y si hablamos de fallas inesperadas que generalmente ocurren por fallos de hardware, sabremos que solo fallarán en este caso las máquinas que pertenecen a un FD, mientras que las que están en el otro continúan respondiendo.

De esta manera si asignáramos más VMs al AS1, por ejemplo la VM3 iría al UD3 y al FD1 nuevamente. La VM4 en UD4 y FD2. VM5 iría en UD5 y FD1; pero VM6 volvería a UD1 y quedaría en FD2. De manera pues que si por actualizaciones Azure puede determinar que ya es hora de reiniciar las máquinas de UD1 reiniciaría al tiempo VM1 y VM6, mientras VM2, VM3, VM4 y VM5 seguirían activas.

Una conclusión de esta metodología que no es fácil de ver a primera vista, es que servidores de distintos tiers no deberían ubicarse en el mismo AS. Por qué?

Imaginemos por un momento que además de las máquinas anteriores, tenemos VM7 con un servidor de bases de datos. VM7 sería ubicado en UD2. Pero cuando UD2 sea reiniciado, se reiniciará el único servidor de DB y quedaremos sin servicio por unos minutos. Esto se soluciona poniendo más servidores de DB en el AS; pero al estar mezclando tiers en el mismo AS puede ocurrir que todos los servidores de DB nos queden en el mismo UD, de manera que pondremos en riesgo nuestra operación. Sumando esto a que no representa un costo adicional y que además es más fácil de administrar, lo que recomiendo es que cada tier tenga su propio AS.

Finalmente, si combinamos la creación de un AS por cada tier de nuestra solución, con VMs redundantes dentro de cada uno de ellos y el balanceo de carga interno de Azure (No confundir con Traffic Manager), tendremos una solución muy robusta. El balanceo de carga interno permite por ejemplo detectar que una VM no está disponible y entonces se redirige el tráfico a máquinas en otros UD distintos al que se está reiniciando en un momento dado, o en otros FD si es que el FD actual sufrió alguna falla física.

Así, ya que hemos entendido la teoría detrás de la alta disponibilidad para VMs en Azure, en este artículo se puede ver un paso a paso de cómo crear Availability Sets y como adicionar VMs a estos.

Comments

• Anonymous
  September 19, 2018
  muy Buenas explicación