Virtualización: ¿Cómo VMotion mantiene las conexiones TCP en una migración de VM?

La respuesta corta es Sí, pero sin conocer su problema específico, es una guía general de cómo se supone que debe funcionar. VMware es una bestia compleja y requiere un amplio conocimiento y experiencia para configurar correctamente y DR es otro nivel de complejidad.

“En vMotion, los archivos que componen la VM no se copian ni se mueven, sino que permanecen en el almacén de datos. Lo que se copia a través de la red es el contenido de la memoria de la VM, en la VM oculta o” fantasma “en el host vSphere de destino. Una vez las dos máquinas virtuales están en el mismo estado de memoria, la fuente se apaga y se da de baja, y se inicia el destino. Todo esto sucede tan rápido que a menudo no se pierde ningún paquete cuando la máquina virtual se “mueve” de un host vSphere a otro.

Se inicia vMotion y se realiza una copia previa inicial, y se genera un archivo de registro, a veces denominado “mapa de bits de memoria”. Una vez que las dos máquinas virtuales están prácticamente en el mismo estado, el mapa de bits en el host de origen se transfiere al destino. En general, el mapa de bits de la memoria debe estar en un estado muy pequeño para que esto suceda, por lo que la transferencia tarda milisegundos en completarse. Para permitir la sincronización completa de los contenidos de la memoria, justo antes de que tenga lugar la transición de la VM de origen al host de destino, la VM en la fuente se pone en un estado inactivo que detiene temporalmente la actividad “.

vMotion debería mantener una conexión TCP y los usuarios no deberían notar ninguna desconexión real. En realidad, puede haber una desconexión menor, pero debido a los TTL de TCP / IP puede pasar desapercibido. Cuando usa tcpdump para analizar el tráfico de paquetes, ve que no se envía una solicitud RARP después de que la máquina virtual se haya movido a través de vMotion al host de destino, entonces puede deberse a una configuración incorrecta en su configuración de equilibrio de carga o tal vez la configuración de VLAN en el conmutador virtual en vCenter.

Una vez que la VM se ejecuta en el host de destino, el proceso VMotion activa un paquete RARP para actualizar las tablas en la red. Si bien la dirección MAC de la VM nunca cambia durante una VMotion, los paquetes destinados a ella se habrían dirigido al host de vSphere de origen en lugar de al destino sin que la red física amplia se alejara del cambio en la ubicación física. El tiempo que tardan en proliferar los paquetes RARP y los cachés de direcciones MAC para alcanzar su TTL pueden provocar la pérdida de uno o dos paquetes, pero no tan notable.

Además, la razón por la cual vMotion está moviendo máquinas virtuales entre hosts también tiene en cuenta la ecuación. Si es porque un host específico en el clúster ha fallado y está alojando un montón de máquinas virtuales altamente transaccionales en muchos LUN, puede haber un impacto negativo. Algunos pensamientos adicionales:

  • Siempre instale la última versión de las herramientas de VMware en su VM.
  • No almacene archivos de intercambio en hosts específicos localmente versus en un LUN.
  • No use servidores SQL en clúster en vMotion, ya que es posible que algunas instancias de SQL fallen y tengan que reiniciarse después de la transición de vMotion
  • Pruebe, pruebe y pruebe nuevamente en máquinas virtuales no críticas para identificar problemas con su configuración, cableado y conmutadores. Intente realizar migraciones en frío en vCenter para asegurarse de que el invitado funcionará en todos los hosts agrupados si es necesario.
  • Debe haber al menos 1 Gps de conectividad entre los hosts.

Consulte este artículo sobre este estándar de detalle de oro con respecto a la configuración de vMotion.

VMotion, Storage vMotion y Cold Migration

No mantiene la conexión tcp continuamente. Se desconecta durante algunos milisegundos durante el cambio del origen al destino. Una vez que se inicia la migración, vmotion conserva los detalles de la red virtual de la máquina. Una vez que el cambio ocurre desde el origen hasta el destino, vmotion suena y le dice al enrutador virtual que la máquina de destino está activa.

Realmente es más un tributo a lo robusto que es TCP.

Durante la transición, el procesamiento en la VM se detiene necesariamente. El host original deja de acceder a los discos de la máquina virtual y el nuevo host recoge la carga. El nuevo host también envía un ARP gratuito, indicando a los conmutadores de red que reenvíen las tramas al nuevo puerto de red.

TCP es bastante resistente, por lo que si se descartó algún paquete, la sesión de TCP simplemente lo detecta y retransmite los paquetes descartados.

He visto cargas de trabajo que son sensibles a la pérdida de paquetes, que no pueden recuperarse de una vmotion. En esos casos, la sesión TCP debe reiniciarse.