Escrito por: Agustín Malanco, CTO Ambassador, VCDX #141
El día de hoy les voy a platicar como funciona Fault Tolerance para múltiples procesadores en la versión de vSphere 6.0. Como sabemos en versiones anteriores sólo se soportaba un Virtual CPU por máquina virtual que estuviera protegida con Faul Tolerance (FT), debido a esto, muchas cargas quedaban fuera de ser verdaderos candidatos para ser protegidas. Para tener un mejor entendimiento de cómo es que funciona FT en la versión de vSphere 6.0 vamos a revisar lo que era Fault Tolerance en versiones previas.
¿Cómo funcionaba Fault Tolerance en versiones previas de vSphere?
En versiones anteriores se tenía un mecanismo de “Record & Replay” lo cual básicamente era obtener la información y procesos que debían ser procesados en el origen (VM principal) y enviarlos a la MV secundaria para su procesamiento de manera síncrona, con esto se lograba tener una MV casi exactamente igual en temas de ejecución que la MV origen. En cuestión de almacenamiento se compartía acceso a un mismo disco duro virtual (VMDK) teniendo únicamente a la MV principal como “dueña” en términos de escritura al disco y la MV secundaría sólo con permisos de lectura. Esta manera de manejar dos MVs en sincronía representaba bastantes problemas, por ejemplo, si tuviéramos dos hosts ESXi con diferentes velocidades en cuestión de ciclos de CPU que forman parte del mismo cluster y en ambos se tenía a un miembro de un grupo de FT (MV Principal y secundaria) podría resultar en que una MV se ejecutara más rápido que la otra (esto también aplica en la carga de los hosts ESXi, configuración de gestión de energía en BIOS, etc). Si consideramos este tipo de situaciones que se presentaban con sólo 1 Virtual CPU ¡ahora imaginen múltiples Virtual CPUS! Debido a estos problemas FT nunca escaló a más de un vCPU en versiones anteriores.
¿Cómo funciona Fault Tolerance en vSphere 6.0?
En esta nueva arquitectura de Fault Tolerance sólo se tiene ejecución de procesos en la MV primaria, los resultados e información de esta MV primaría son enviados a través de la red de FT hacia la MV secundaria. Ahora se preguntaran: ¿Cómo es que se envían estos cambios?, ¿Qué mecanismo y/o tecnología está por detrás?… Para esto vamos a recordar de una de las tecnologías que hoy en día consideramos de lo más “básico”, el snapshot. El snapshot en vSphere funciona de tal manera que se toma una “fotografía” o punto en el tiempo del estado de una MV, en estos snapshots se incluye la memoria, estado de discos, dispositivos, etc, permitiéndonos así poder regresar a un punto específico de ejecución de dicha MV.
En el caso de esta nueva arquitectura de FT, se utiliza un mecanismo llamado “checkpoint” que básicamente podríamos considerar un snapshot sólo que éste envía exclusivamente los cambios desde el último checkpoint (deltas), se toman estos checkpoints de manera continúa con una diferencia de tiempo entre estos de milisegundos (aunque esto puede llegar a variar ya que se puede adaptar de manera dinámica basándose en la carga y comportamiento de la misma) con este nuevo mecanismo no requerimos de tener ejecución real de la MV secundaria puesto que todo el procesamiento es enviado desde la MV primaria a través de la red de FT mediante los checkpoints. Estos checkpoints nos permiten restaurar la MV en caso de falla incluso hasta su última operación de red. Es importante notar que al estar manejando múltiples Virtual CPUs y enviando los cambios entre MV principal y secundaria el requerimiento de red entre ambos hosts ESXi es alto, debido a esto, se requiere de 10Gbps para poder mantener la sincronía y evitar latencia que afectaría el tiempo para recibir un “ack” o acknowledge por parte de la MV secundaria confirmando que el checkpoint fue recibido y aplicado lo cual incrementaría el tiempo que le tomaría a los paquetes de red en salir (TX) de la MV principal ya que se requiere tener la confirmación para continuar con el funcionamiento de la MV principal a nivel red, en caso de no tener la confirmación por más de 2 segundos la MV principal continuará con su funcionamiento normal y se mostrara en un estado de “needSecondary” desencadenando un proceso de HA para reiniciar la MV secundaria en otro nodo.
Otro cambio importante en la arquitectura se encuentra en el almacenamiento, con vSphere 6.0 Fault Tolerance mantiene dos copias de los archivos de MV incluyendo discos duros, archivos de configuración, etc. Esto para poder tolerar fallas a nivel de almacenamiento.
Para obtener más información acerca de VMware, visite nuestros sitios web de Argentina, Chile, Colombia, México, Perú, Venezuela y otros países. También puede seguirnos en Facebook, Twitter y Youtube para enterarse de las últimas novedades.
Contacte VMware aquí.
