Fault Tolerance 6.0, una solución integral

Entre las más de 650 novedades que incorpora la nueva versión de virtualización de escritorios de VMware, vSphere 6.0, destaca VMware Fault Tolerance 6.0. Se trata, sin duda, de una de las características que más interés despertará entre los clientes y usuarios del producto por su capacidad para minimizar el tiempo de downtime en una máquina virtual (VM) en caso de fallo del hipervisor.

De Fault Tolerance 4.0 a Fault Tolerance 6.0

Para toparnos con la primera versión de VMware Fault Tolerance (FT) hay que remontarse a 2009. Concretamente, a la versión VMware vSphere 4.0. Desde el inicio, esta opción despertó el interés de los usuarios que apreciaban la oportunidad que les brindaba: reducir a prácticamente cero el downtime a nivel de sistema operativo virtual. Sin embargo, el hecho de estar limitado a VM’s con un solo procesador (un solo core) provocó que su nivel de implementación en cliente final fuera residual. Habitualmente, aquellos sistemas críticos que serían candidatos a hacer uso de FT precisan de más de una vCPU para trabajar.

En estos seis años transcurridos desde el lanzamiento de vSphere 4.0 hasta su última versión, vSphere 6.0 , VMware ha ido aportando mejoras y perfeccionando FT -se amplió la lista de VM compatibles, por ejemplo-, pero no ha podido atajar el problema de la escasa implementación. Durante la VMworld 2013 se realizó un Technical Preview de Fault Tolerance para VM multiprocesador, que supuso el despegue definitivo de esta opción.

La versión definitiva con soporte para VM’s multiprocesador (4 vCPU) fué finalmente liberada el pasado mes de enero, junto con vSphere 6.0. En la siguiente imagen se puede ver una comparativa entre la versión Fault Tolerance 6.0 y su versión anterior FT 5.5:

Cómo funciona FT

La base sobre la que se apoya FT es VMware vLockStep. Esta tecnología es capaz de:

• Capturar todos los inputs y operaciones que tienen lugar en una máquina virtual (origen) y enviarlos a una segunda máquina virtual (destino), que permanece inactiva.
• Discernir entre los cambios u operaciones de CPU que son relevantes y los que no. Eso permite optimizar esta replicación. El resultado es que tenemos una réplica entre dos máquinas virtuales en tiempo real.

Una protección integral

Fault Tolerance replica en caliente los cambios que suceden a nivel de CPU y memoria en la VM de origen. Por lo tanto, nos protegerá en caso de ocurrir un problema a nivel de host ESX (hardware o software) que implique que la VM origen deje de estar online.

Gracias a las nuevas API de vSphere Storage 6.0, Fault Tolerance se integra ahora con vSphere Replication. Esta combinación permite que la VM de destino resida en un datastore distinto, incluso en otra ubicación, añadiendo protección también contra fallo del almacenamiento en la VM principal. En resumen, Fault Tolerance nos puede ayudar frente a cualquier fallo a nivel de infraestructura.

También nos permite mantener snapshots de las VM protegidas, cosa que puede ser de ayuda contra fallos a nivel de SO virtual, aunque no son su cometido. Para esto, deberíamos hacer uso de de MS Cluster Services.

Claves para entender Fault Tolerance 6.0

1.¿Cuál es el tiempo de retardo en la replicación entre la VM origen y la de destino?

El único retardo viene dado por la latencia a nivel de red que haya entre las dos VM’s.
vLockstep ejecuta las mismas instrucciones en ambas VM’s, pero al estar habitualmente en diferentes hosts podría haber una pequeña latencia (pocos milisegundos).

¿Qué sucede en caso de fallo?

Cuando falla el host que ejecuta la máquina virtual origen se produce de forma automática una conmutación a la máquina virtual destino correspondiente. Durante este proceso no hay pérdida de datos ni interrupción del servicio notable. El cambio es lo suficientemente rápido como para que no se pierdan las sesiones TCP. Las conexiones de red no se interrumpen.

Paralelamente, VMware restaura automáticamente la redundancia iniciando una nueva máquina virtual secundaria en otro host (una nueva réplica), por si el host que ejecuta la VM en producción actual sufre también un fallo.

¿Hay algún impacto en el rendimiento de la VM de origen?

Sí. El hecho de replicar los cambios a nivel de CPU hacia otra VM/host en tiempo real supone una pequeña carga adicional de trabajo para la VM de origen. Este hecho puede producir un impacto que puede variar,
según el fabricante, entre un 10% y un 30% en el rendimiento a nivel de CPU.

¿Está mi infraestructura preparada para implementar Fault Tolerance?

A pesar de que la compatibilidad a nivel de CPU y SO se ha ido incrementando con el paso del tiempo: es recomendable antes de tomar ninguna decisión que verifiquemos si nuestra infraestructura va a permitirnos poner FT en marcha. Para verificar la compatibilidad a nivel de CPU podemos utilizar esta herramienta de VMWare, que hará el chequeo y nos dará la información.

Podemos encontrar la información extendida en la documentación del fabricante.