La característica vMotion se actualiza en gran medida en vSphere 7, lo que resulta en migraciones en vivo más rápidas y al mismo tiempo reduce drásticamente el impacto en el rendimiento del guest durante el proceso vMotion, junto con una forma mucho más eficiente de cambiar la máquina virtual (VM) entre el host ESXi de origen y destino. vSphere 7 también introduce mejoras para el proceso de suspender y reanudar rápidamente (Fast Suspend and Resume, FSR).
FSR se usa cuando se migra en vivo el almacenamiento de VM con Storage vMotion , pero también para VM Hot Add. Hot Add es la capacidad de agregar vCPU, memoria y otros dispositivos de hardware seleccionados a una VM encendida. Cuando la VM está apagada, agregar recursos informáticos o dispositivos de hardware virtual es solo un cambio de archivo de configuración .vmx. FSR se usa para hacer lo mismo para máquinas virtuales en vivo.
Nota: el uso de vCPU Hot Add puede introducir un impacto en el rendimiento de la carga de trabajo como se explica en este artículo .
El proceso FSR
FSR tiene muchas similitudes con el proceso vMotion . La mayor diferencia es que FSR es una migración local en vivo, dentro del mismo host ESXi. Para vMotion necesitamos copiar los datos de la memoria del host ESXi de origen al destino. Con FSR, las páginas de memoria permanecen dentro del mismo host.
Cuando se inicia un Storage vMotion o cuando se utiliza Hot Add, se crea una VM de destino. Este nombre puede ser engañoso, es una VM ‘fantasma’ que se ejecuta en el mismo host ESXi donde se ejecuta la VM de origen. Cuando se crea la VM de «destino», el proceso FSR suspende la ejecución de la VM de origen antes de transferir el estado del dispositivo y los metadatos de la memoria. Debido a que la migración es local al host, no es necesario copiar páginas de memoria, sino solo los metadatos. Una vez hecho esto, la máquina virtual de destino se reanudará y la máquina virtual de origen se limpiará, apagará y eliminará.
Al igual que con vMotion, debemos mantener el tiempo entre la suspensión y la reanudación de la máquina virtual en <1 segundo para minimizar el impacto del SO del guest. Por lo general, eso nunca fue un problema para los tamaños de VM más pequeños. Sin embargo, con grandes cargas de trabajo (VM ‘Monster’), el impacto podría ser significativo dependiendo del tamaño de la VM y las características de la carga de trabajo.
¿Cómo se transfieren los metadatos de memoria?
Durante un proceso FSR, se consume la mayor parte del tiempo en la transferencia de los metadatos de la memoria. Puede ver los metadatos de la memoria como punteros para que la VM entienda dónde se ubican los datos en la memoria del sistema global. Los metadatos de la memoria utilizan marcos de página (PFrames), que proporcionan la asignación entre la VM, su memoria virtual y los números de página de la máquina (MPN), que identifica los datos en la memoria física.
Debido a que no es necesario copiar los datos de la memoria, FSR solo necesita copiar los metadatos (PFrames) a la VM de destino en el mismo host, diciéndole dónde buscar datos en la memoria del sistema.
En las versiones de vSphere anteriores a vSphere 7, la transferencia de los metadatos de la memoria es de un solo subproceso. Solo se reclama una vCPU y se usa para transferir los PFrames en lotes. Todas las demás vCPU están durmiendo durante la transferencia de metadatos, ya que la VM se suspende brevemente. Este método está bien para máquinas virtuales de menor tamaño, pero podría presentar un desafío para las máquinas virtuales grandes, especialmente con una gran huella de memoria.
La transferencia de un solo subproceso no se escala con configuraciones de VM grandes, lo que puede generar tiempos de conmutación de más de 1 segundo. Entonces, al igual que con vMotion en vSphere 7, es necesario reducir el tiempo de conmutación (también conocido como tiempo de aturdimiento) cuando se usa FSR.
FSR mejorado en vSphere 7
Entonces, ¿por qué no usar todas las máquinas virtuales y sus vCPU para transferir los PFrames? Recuerde que la VM se suspende durante la transferencia de metadatos, por lo que no tiene sentido dejar que las vCPU permanezcan inactivas. Pongámoslos a trabajar para acelerar la transferencia de los PFrames. La memoria de las máquinas virtuales se divide en segmentos y a cada vCPU se le asigna un segmento de metadatos de memoria para transferir.
En vSphere 7, la lógica FSR pasó de un método serializado a un modelo distribuido. La transferencia PFrames ahora se distribuye en todas las vCPU configuradas para la VM, y las transferencias se ejecutan en paralelo.
El efecto de aprovechar todas las vCPU
El resultado neto de aprovechar todas las vCPU para las transferencias de metadatos de memoria durante un proceso FSR, reduce drásticamente los tiempos de cambio. El equipo de rendimiento probó múltiples configuraciones de VM y cargas de trabajo con Storage vMotion y Hot Add. Al usar una VM configurada con 1 TB de memoria y 48 vCPU, experimentaron un tiempo de conmutación reducido de 7.7 segundos al usar 1 vCPU para la transferencia de metadatos, ¡a 500 milisegundos cuando se utilizan todas las vCPU!
Las mejoras FSR dependen en gran medida del tamaño de la máquina virtual y las características de la carga de trabajo. Con las versiones de vSphere hasta la 6.7, hubo un desafío con el SLA de 1 segundo al usar las operaciones Storage vMotion o Hot Add. Al ejecutar vSphere 7, los clientes pueden sentirse cómodos nuevamente utilizando estas capacidades debido a los tiempos de cambio reducidos.
Fuente:VMware
Si tienes alguna pregunta o necesitas apoyo inmediato en su versión de vSphere, no dudes en escribirnos por cualquiera de nuestros medios virtuales. Nos puedes dejar tus datos en el siguiente link y te contactaremos pronto. ¡Estamos para ayudarte!
