Conceptos y mejores prácticas para vMotion

HCX es básicamente un proxy bidireccional de vMotion. Cada instancia de HCX emula un único VMware dentro del centro de datos vSphere, fuera de cualquier clúster. La instancia de HCX es un "frontal" para el componente de la flota de pasarela de nube (CGW). Aparece un host de proxy para cada sitio de HCX enlazado con el sitio visualizado actualmente. Cuando se inicia una vMotion a un host remoto, el host local de ESXi migra dicha VM al host ESXi del proxy local.

Se inicia una migración de vMotion desde el host de proxy ESXi remoto al host ESXi físico de vSphere de destino, mientras recibe datos del CGW de origen a través del túnel. Cuando se utiliza vMotion, a diferencia de la opción de migración masiva, solo se ejecuta una operación de migración de máquina virtual a la vez. Como resultado, para muchas máquinas virtuales a migrar, se recomienda utilizar vMotion sólo cuando el tiempo de inactividad no sea una opción o si existe el riesgo de reiniciar la máquina virtual. Sin embargo, como vMotion estándar, la máquina virtual puede estar en directo durante el proceso.

Un solo vMotion alcanza su límite máximo en torno a 1.7 Gbps en la LAN y 300 - 400 Mbps en la WAN a través del Optimizador WAN. Esto no implica que 1,7 Gbps en la LAN sean equivalentes a 400 Mbps en la WAN a través del optimizador de WAN, sino más bien que estos valores máximos se han observado en entornos específicos. Un entorno de este tipo constaba de una red vMotion LAN de 10 GB y un enlace ascendente de Internet de 1 GB, compartido con el tráfico web de producción.

Utilice vMotion en los casos siguientes:

• Si la máquina virtual es difícil de apagar, arrancar, o si el tiempo de actividad es largo y puede introducir riesgos al apagar la máquina virtual.
• Para cualquier aplicación de tipo cluster que requiera UUIDs de disco, como Oracle RAC clusters. vMotion no cambia los UUID de disco en el destino.
• Si desea mover una sola VM tan rápido como sea posible.
• Si no se necesita una migración planificada.

Conceptos y mejores prácticas para la migración masiva

La función de migración masiva de HCX utiliza la réplica de vSphere para migrar los datos de disco mientras vuelve a crear la máquina virtual en la instancia de HCX de vSphere de destino. La migración de una máquina virtual conlleva el siguiente flujo de trabajo:

• Creación de una nueva máquina virtual en el lado de destino y sus correspondientes discos virtuales.
• Réplica de los datos de la máquina virtual en la nueva máquina virtual. La replicación se inicia en cuanto finaliza el asistente, independientemente de la programación de la conmutación.
• Apagar la máquina virtual original.
• Durante el periodo de apagado, se produce la réplica final de cualquier cambio de datos.
• Encender la nueva máquina virtual en el lado de destino.
• Renombrar y mover la máquina virtual original a la carpeta en la nube a la que se haya movido.

A continuación se exponen las ventajas de la migración masiva sobre vMotion:

• Migración de varias máquinas virtuales simultáneamente.
• Uso de ancho de banda más coherente. vMotion puede generar fluctuaciones en el uso del ancho de banda que serían visibles como picos y valles dentro de las herramientas de supervisión de red o la interfaz de usuario de WAN Opt.
• Utilice la migración masiva para obtener un uso general de una capacidad de ancho de banda de red superior a si utiliza un solo vMotion.
• Planifique la migración masiva para cambiar a las máquinas virtuales recién migradas durante una ventana de parada planificada.
• Permitir la migración de máquinas virtuales que actualmente están utilizando características de CPU virtuales, que difieren del lado de la nube. La migración de vMotion puede fallar en estos casos.

A continuación se exponen los inconvenientes de la migración masiva sobre vMotion:

• Las máquinas virtuales a nivel individual se migran de forma mucho más lenta que con vMotion.
• La máquina virtual genera un breve tiempo de inactividad cuando la nueva máquina virtual de clon se lleva al lado de destino.
• Las máquinas virtuales que dependen del orden de los discos y de los UUID de disco (Oracle RAC) pueden generar problemas y tener discos que se muestren de forma diferente ya que se cambian los UUID, lo que puede cambiar las vías de acceso del sistema operativo a los dispositivos de disco virtual.

Clústeres de disco compartido

Los clústeres de Oracle RAC, MS Exchange y MS-SQL son ejemplos de aplicaciones en las cuales participan dos o más máquinas virtuales en un clúster que requiere un disco compartido en todas las máquinas virtuales o nodos de clúster. El distintivo de varios escritores de VMware® debe estar habilitado en todos los nodos de VM para discos que forman parte del clúster de aplicaciones (discos virtuales que no son del sistema operativo). Las máquinas virtuales con el indicador de multiescritura activado para cualquier disco virtual no son compatibles.

Revise la siguiente información sobre la migración de un clúster habilitado para disco virtual multigrabador:

• Se utiliza vMotion, ya que el disco de la VM original y las correlaciones de UUID se mantienen.
• El clúster permanece activo en un estado degradado (nodo único) durante la migración.
• El clúster genera tiempo de inactividad antes de iniciar la migración y una vez completada la migración para volver a ensamblar la configuración de varios escritores entre las máquinas virtuales del clúster.

Para migrar un clúster habilitado para discos multigrabador, siga estos pasos:

1. Apague el clúster y todos los nodos para la práctica recomendada de la aplicación.
2. Tome nota del orden de discos, si la aplicación lo requiere, en cada máquina virtual de nodo para los discos virtuales configurados de varios escritores.
3. Para Oracle y cualquier otra aplicación que utilice la característica de UUID de disco virtual, inicie sesión en un host ESXi y ejecute el mandato vmkfstools -J getuuid /vmfs/volumes/datastore/VM/vm.vmdk. Este mandato obtiene el UUID de cada archivo de disco virtual que requiere el distintivo de multigrabador (multi-writer) establecido para el clúster. Este paso es necesario si la recomendación se ajusta a los pedidos de disco en cuanto a la forma en que se muestra la vía de acceso en el sistema operativo. vMotion puede reordenar los discos (disk1, disk2, disk3) pero los UUID siguen siendo los mismos. Cuando se haya completado la migración, utilice el UUID anotado para correlacionar la información de disco para volver a crear el orden de denominación de discos y el ID de SCSI, si es necesario. Esta información puede ser útil para la resolución de problemas cuando una instancia de Oracle tiene muchos discos virtuales correlacionados.
4. Elimine los discos virtuales de todas las máquinas virtuales del clúster, excepto el que se considera primario.
5. Elimine el indicador de multiescritura de la máquina virtual del clúster principal (la única que posee los discos del clúster).
6. Encienda el clúster primario, si es necesario para que el tiempo de inactividad sea mínimo.
7. Migre todos los nodos de clúster con vMotion. Migre el clúster primario en primer lugar. Migre los demás nodos después de que se hayan apagado.
8. Cuando el nodo propietario del disco primario complete la migración, apáguelo.
9. Si es necesario, vuelva a correlacionar el orden de disco con el UUID de disco y el ID de SCSI adecuados. No es necesario realizar ningún reajuste para que la aplicación funcione.
10. Vuelva a habilitar el distintivo de varios escritores en el nodo primario.
11. Arranca el nodo primario y verifica el funcionamiento.
12. Correlacione el disco o habilite el distintivo multi-writer en todas las demás VM del clúster y enciénelas.
13. Verifique otras funciones del clúster.

Máquinas virtuales generales

Una vez que se ha generado confianza alrededor de la función de HCX, se debe utilizar la migración masiva. La migración masiva es necesaria para las aplicaciones redundantes. Por ejemplo, los servidores web y cuando se van a migrar varios cientos o miles de máquinas virtuales.

Máquinas virtuales que utilizan NAS de conexión directa

NFS suele utilizarse para compartir datos entre muchos servidores, como el contenido del servidor web. iSCSI se puede emplear en nodos de máquina virtual que constan de un clúster de aplicaciones como, por ejemplo, correo electrónico o RDBMS y suele ser más sensible a la latencia que NFS.

En cualquier caso, si la latencia puede mantenerse baja respecto al centro de datos de IBM Cloud (< ~ 7 ms para iSCSI y lo que la aplicación tolere para NFS) y permitir que la aplicación pueda funcionar con un ancho de banda de ~ 1 Gbps o menos, la red NAS se puede extender con HCX en una ubicación de IBM Cloud. Después, las VM se pueden migrar o trasladar con vMotion con HCX.

Después de la migración, los volúmenes de iSCSI se pueden duplicar con el sistema operativo en otra solución de almacenamiento en nube local y los datos de NFS se pueden replicar en cualquier solución de nube. Revise las siguientes consideraciones:

• Latencia (iSCSI o tolerancia de aplicaciones para NFS)
• Ancho de banda (~ 1 Gbps por red extendida)
• Ancho de banda de enlace subyacente

Después del ciclo de vida de la migración, pruebe las aplicaciones de desarrollo o transferencia antes de intentarlo en producción. Se puede utilizar la calidad de servicio para el tráfico de túnel subyacente (UDP 500/4500) entre los dispositivos L2C HCX que admitan redes L2 extendidas sensibles a la latencia.