Alta disponibilidad en un clúster de Nutanix

¿Sabías que, después de tener listo y funcionando tu clúster de Nutanix, varias de tus máquinas virtuales críticas o servicios en HA (High Availability) pueden estar ejecutándose en el mismo host físico?

Efectivamente, no serás el primero ni el último que su clúster de SQL Server o su pareja de balanceadores de carga se van al traste unos minutos si antes no haces nada para evitarlo. Si ese host físico tiene un problema, (error de hardware, pérdida de conexión,…) todas las VM’s que se ejecutan en él dejarán de funcionar y podrás sufrir varios minutos de caída de servicio hasta que se recuperen en otro host del clúster (y cruza los dedos para que ninguna BD o caché haya que reconstruirse. Si fuera así, ya nos iríamos hacia un buen downtime).

Y ya sabemos que a nadie le gusta que un servicio pensado para que siempre funcione lo deje de hacer ¿verdad? Ni tan siquiera unos minutos. ¿Todo nuestro buen hacer desde IT empañado por unos minutos de caída en pleno Black Friday o en el momento menos oportuno? Eso no lo permitiremos ?.

Vamos a ver cómo, dedicando unos minutos, puedes evitar tal caída de tus servicios más delicados de una forma muy sencilla y poner una check más en tu libreta de despreocupaciones…

Nutanix y su configuración por defecto del clúster

Una vez tienes tu clúster de Nutanix funcionando, si no haces nada y te limitas a desplegar máquinas virtuales (o clústeres de karbon) es el propio Nutanix que, en función del uso de recursos, reparte las máquinas en los hosts del clúster. Ante esta situación, nos podemos encontrar que servicios pensados en alta disponibilidad realmente se estén ejecutando en máquinas virtuales bajo el mismo host físico. Cuantos más hosts tengas en el clúster de Nutanix, menor probabilidad de que coincidan. No obstante, si no quieres arriesgarte, deberás de configurar unas simples reglas.

Básicamente con Nutanix tenemos dos opciones: jugar con las afinidades y las anti-afinidades.

• Con las afinidades forzaremos que las máquinas virtuales se ejecuten solo en los hosts que configuremos. De esta forma, en un servicio con alta disponibilidad unos miembros se ejecutarán solo en unos hosts y otros miembros en otros hosts físicos, siendo así el servicio ajeno a la caída de uno de éstos.
• Con las anti-afinidades forzaremos que las máquinas virtuales no se ejecuten en el mismo host, sin importar el host en el que estén. Dejaremos a Nutanix que las ejecute donde mejor crea conveniente para temas de Data Locality & cia….

Como ya debéis intuir, definir anti-afinidades para tener una alta disponibilidad es la solución más elegante, pero la mala noticia para muchos es que hoy en día solo se puede hacer por consola de comandos. No todo en Nutanix son dos clicks. Por ello, si quieres hacerlo desde Prism en un entorno web Fisher-Price, solo podrás en el primer de los casos.

Ambos son válidos, por ello a continuación explicaremos cómo ejecutar en cada caso y os dejamos a libre elección.

Relaciones de afinidades

Es la forma más sencilla y gráfica ya que solo necesitas un browser y el acceso web a Prism. Editando las preferencias de cada VM, podemos asignarle en que hosts queremos ejecutarlas, y para nuestros servicios en HA escogeremos que sea en distintos.

En el ejemplo que voy a mostrar lo haremos con dos DNS’ internos (dns01 y dns02) que se ejecutan en un clúster formado por seis hosts. Definiremos una afinidad para que dns01 se pueda ejecutar en los tres primeros hosts del clúster y dns02 lo haga en los tres últimos. De esta forma, ninguna de las dos VM’s coincidirá en el mismo host y, ante una posible caída, siempre nos aseguraremos de que, como mínimo, uno de los dos DNS’ funcione.

1.Abrimos Prism Elements con el browser, vamos a la vista de VM’s, seleccionamos la VM a editar (primero dns01 y luego dns02) y clickamos en Update.

2. Bajamos hasta el final de las propiedades de la VM y allí encontraremos “VM Host Affinity”. En nuestro caso no tenemos ninguna afinidad existente y, por tanto, la crearemos seleccionando los hosts y guardando los cambios:

3. Marcamos los tres primeros hosts del clúster para dns01 y repitiendo el mismo procedimiento con la VM dns02. Marcaremos en ella los tres últimos:

Para comprobar que las afinidades están bien definidas y se han guardado los cambios podemos hacer Update en la VM y comprobarlo si vamos a la sección de VM Host Affinity. En la captura podemos ver cómo están definidas las afinidades en dns02:

Y nada más, así de simple. En función de las VM’s que formen el servicio que quieres proteger y el número de hosts de tu clúster, debes jugar con ellas.

Punto importante en Relaciones de Afinidad

Antes de pasar al siguiente punto, nota MUY importante. Si no tienes ninguna afinidad definida en tu VM, cuando empieces el proceso nunca le des a Save. Por defecto, Prism le asigna afinidad al host donde se está ejecutando la VM en ese momento (en vez de no asignarla a ninguno, el comportamiento lógico). Por ello, al clickar en Save, lo que harías es crear una afinidad a un único host.

Esta captura es de una VM que no tiene ninguna afinidad y, al intentar crear una nueva cómo puedes ver ya, le ha asignado una al host C01-AHV06. Si le doy a Save y no a Close, la estaré enjaulando a dicho host.

Relaciones de anti-afinidades

Es la forma – a nuestro parecer – más elegante para hacer que las máquinas virtuales no se ejecuten bajo un mismo host, al no tener ningún tipo de ataduras y afectando lo mínimo a Nutánix. Dejamos entonces que Nutanix utilice todos los hosts del clúster para todas las VM’s. Pero con solo una condición: que las VM’s que decidas no deben de ejecutarse en el mismo host.

Vamos a utilizar las mismas máquinas de antes (dns01 y dns02) deshechas las asociaciones anteriores creadas. En el ejemplo mostraremos como elaborar un grupo, añadir las máquinas a dicho grupo y configurar una política para que no coincidan:

1. Conéctate por consola a una de las CVM’s del clúster de Nutanix y crea un grupo de VM’s. En nuestro caso, nos conectamos por SSH a la CVM que está haciendo de Master (la IP de Prism Elements): acli vm_group.create nombre-del-grupo

2. Añadimos las VM’s al grupo que hemos creado: acli vm_group.add_vms nombre-del-grupo vm_list=»nombre-vm01″,»nombre-vm02″

3. Asignamos la policy de anti-afinidad al grupo: acli vm_group.antiaffinity_set nombre-del-grupo

Y voilà. dns01 y dns02 no se ejecutarán en el mismo host dándonos igual dónde estén.

Como ya hemos comentado, el hándicap de este sistema es que no es muy visual y Nutanix está pensado para serlo. Somos muchos los enfermos que nos sentimos más cómodos en consolas y no en navegadores, pero deberás aprender a tener a mano los comandos sencillos para una fácil gestión de grupos de VM’s vía consola. Te indicamos a continuación los más útiles.

Comandos sencillos para una fácil gestión de grupos de VM’s vía consola en el clúster de Nutanix

• Listar grupos existentes: acli vm_group.list
• Listar VMs de un grupo: acli vm_group.list_vms nombre-del-grupo
• Deshacer anti-afinidad: acli vm_group.antiaffinity_unset nombre-del-grupo
• Quitar VMs de un grupo: acli vm_group.remove_vms nombre-del-grupo vm_list=»nombre-vm01″,»nombre-vm02″
• Eliminar un grupo: acli vm_group.delete nombre-del-grupo

Información ampliada de todas los opciones de vm_group en este enlace. Y como siempre, mil y un agracias por haber llegado hasta aquí. Nos vemos en el próximo post.