none
Problemas de red en máquinas virtuales RRS feed

  • Pregunta

  • Buenas,


    Tengo un problema que la verdad no sé cómo solucionarlo.


    El escenario es un cluster de Hyper-V con Windows 2008 R2 con 2 nodos y 6 interfaces de red (una tarjeta de 4 broadcom y otra de 2 intel). Para las pruebas tengo un equipo haciendo ping a la IP de la máquina virtual. Las máquinas virtuales se encuentran en otra VLAN diferente al PC de pruebas, no se etiqueta tráfico.


    El tema es que cuando migro en vivo una máquina virtual de un nodo a otro el ping de la máquina de pruebas funciona correctamente tantas veces como la migre.


    Al realizar una migración rápida, el ping de la máquina virtual deja de responder por un cierto tiempo aleatorio de varios minutos hasta que vuelve a funcionar. Como he comentado antes la máquina de pruebas está en otra vlan diferente a la máquina virtual. El caso es que este tiempo aletorio sin ping se reduce a unos pocos segundos si desde otra máquina que está en la misma vlan que la máquina virtual también hago ping, comenzando a responder el ping de la máquina de pruebas inmediatamente (como debería ser).


    Cuando provoco el fallo de un nodo para que las máquinas virtuales balanceen al otro ocurre lo mismo que con la migración rápida.
    En resumen la migración en vivo me funciona perfectamente, con una pérdida de red ínfima, pero la migración rápida o la caída de un nodo del clúster hacer que las máquinas virtuales no respondan peticiones de red por un tiempo aleatorio de normalmente varios minutos (excepto si también estoy haciendo ping a la máquina virtual desde otro equipo de su misma vlan)


    Todo esto me lleva a pensar que el problema está en el routing entre vlans o en la actualización de la tabla arp de los switches.


    Sobre la configuración de red tengo una interfaz dedicada a los discos csv y la comunicación del clúster, otra para la migración en vivo, otra para la administración de cada servidor y otra para las comunicaciones de las máquinas virtuales (en la configuración de hyper-v no se comparte con el sistema operativo). No utilizo ningún tipo de teaming ni agregación de enlaces. Cada servidor está conectado a un swich diferente.


    ¿A alguien más le ocurre lo mismo?


    Gracias.

    viernes, 17 de septiembre de 2010 10:42

Respuestas

  • Si no te he entendido mal, es normal lo que cuentas. La migración en vivo (LiveMigration) no supone una perdida de servicio (realmente sí, de un paquete o dos de ping) mientras que la migración rápida (QuickMigration) sí provoca pérdida de servicio, pues el proceso es el siguiente:
     
    - Se guarda el estado de la maquina virtual (en ese momento deja de prestar servicio)
    - Se mueve el almacenamiento al nodo de destino, tanto el de la máquina virtual como el de sus discos.
    - Se restaura el estado de la máquina virtual, ya en el nodo de destino.
    - Una vez restaurado el estado de la máquina virtual, ésta ya da de nuevo servicio.
     
    El tiempo que se tarde en hacer esta operación depende de la cantidad de memoria RAM de la máquina virtual, principalmente.

    --

    Un saludo
     
    Fernando Reyes
    freyes@ya.com
     
     

    Buenas,


    Tengo un problema que la verdad no sé cómo solucionarlo.


    El escenario es un cluster de Hyper-V con Windows 2008 R2 con 2 nodos y 6 interfaces de red (una tarjeta de 4 broadcom y otra de 2 intel). Para las pruebas tengo un equipo haciendo ping a la IP de la máquina virtual. Las máquinas virtuales se encuentran en otra VLAN diferente al PC de pruebas, no se etiqueta tráfico.


    El tema es que cuando migro en vivo una máquina virtual de un nodo a otro el ping de la máquina de pruebas funciona correctamente tantas veces como la migre.


    Al realizar una migración rápida, el ping de la máquina virtual deja de responder por un cierto tiempo aleatorio de varios minutos hasta que vuelve a funcionar. Como he comentado antes la máquina de pruebas está en otra vlan diferente a la máquina virtual. El caso es que este tiempo aletorio sin ping se reduce a unos pocos segundos si desde otra máquina que está en la misma vlan que la máquina virtual también hago ping, comenzando a responder el ping de la máquina de pruebas inmediatamente (como debería ser).


    Cuando provoco el fallo de un nodo para que las máquinas virtuales balanceen al otro ocurre lo mismo que con la migración rápida.
    En resumen la migración en vivo me funciona perfectamente, con una pérdida de red ínfima, pero la migración rápida o la caída de un nodo del clúster hacer que las máquinas virtuales no respondan peticiones de red por un tiempo aleatorio de normalmente varios minutos (excepto si también estoy haciendo ping a la máquina virtual desde otro equipo de su misma vlan)


    Todo esto me lleva a pensar que el problema está en el routing entre vlans o en la actualización de la tabla arp de los switches.


    Sobre la configuración de red tengo una interfaz dedicada a los discos csv y la comunicación del clúster, otra para la migración en vivo, otra para la administración de cada servidor y otra para las comunicaciones de las máquinas virtuales (en la configuración de hyper-v no se comparte con el sistema operativo). No utilizo ningún tipo de teaming ni agregación de enlaces. Cada servidor está conectado a un swich diferente.


    ¿A alguien más le ocurre lo mismo?


    Gracias.


    Un saludo

    Fernando Reyes [MS MVP]
    MCSA 2000/2003
    MCSE 2000/2003
    MCITP EnterpriseAdministrator
    Web: http://freyes.svetlian.com
    Blog: http://urpiano.wordpress.com
    RSS: http://urpiano.wordpress.com/feed/
    freyes.champú@champú.mvps.org
    (Aclárate la cabeza si quieres escribirme)
    • Marcado como respuesta Ismael Borche jueves, 28 de abril de 2011 20:52
    lunes, 20 de septiembre de 2010 13:14

Todas las respuestas

  • Si no te he entendido mal, es normal lo que cuentas. La migración en vivo (LiveMigration) no supone una perdida de servicio (realmente sí, de un paquete o dos de ping) mientras que la migración rápida (QuickMigration) sí provoca pérdida de servicio, pues el proceso es el siguiente:
     
    - Se guarda el estado de la maquina virtual (en ese momento deja de prestar servicio)
    - Se mueve el almacenamiento al nodo de destino, tanto el de la máquina virtual como el de sus discos.
    - Se restaura el estado de la máquina virtual, ya en el nodo de destino.
    - Una vez restaurado el estado de la máquina virtual, ésta ya da de nuevo servicio.
     
    El tiempo que se tarde en hacer esta operación depende de la cantidad de memoria RAM de la máquina virtual, principalmente.

    --

    Un saludo
     
    Fernando Reyes
    freyes@ya.com
     
     

    Buenas,


    Tengo un problema que la verdad no sé cómo solucionarlo.


    El escenario es un cluster de Hyper-V con Windows 2008 R2 con 2 nodos y 6 interfaces de red (una tarjeta de 4 broadcom y otra de 2 intel). Para las pruebas tengo un equipo haciendo ping a la IP de la máquina virtual. Las máquinas virtuales se encuentran en otra VLAN diferente al PC de pruebas, no se etiqueta tráfico.


    El tema es que cuando migro en vivo una máquina virtual de un nodo a otro el ping de la máquina de pruebas funciona correctamente tantas veces como la migre.


    Al realizar una migración rápida, el ping de la máquina virtual deja de responder por un cierto tiempo aleatorio de varios minutos hasta que vuelve a funcionar. Como he comentado antes la máquina de pruebas está en otra vlan diferente a la máquina virtual. El caso es que este tiempo aletorio sin ping se reduce a unos pocos segundos si desde otra máquina que está en la misma vlan que la máquina virtual también hago ping, comenzando a responder el ping de la máquina de pruebas inmediatamente (como debería ser).


    Cuando provoco el fallo de un nodo para que las máquinas virtuales balanceen al otro ocurre lo mismo que con la migración rápida.
    En resumen la migración en vivo me funciona perfectamente, con una pérdida de red ínfima, pero la migración rápida o la caída de un nodo del clúster hacer que las máquinas virtuales no respondan peticiones de red por un tiempo aleatorio de normalmente varios minutos (excepto si también estoy haciendo ping a la máquina virtual desde otro equipo de su misma vlan)


    Todo esto me lleva a pensar que el problema está en el routing entre vlans o en la actualización de la tabla arp de los switches.


    Sobre la configuración de red tengo una interfaz dedicada a los discos csv y la comunicación del clúster, otra para la migración en vivo, otra para la administración de cada servidor y otra para las comunicaciones de las máquinas virtuales (en la configuración de hyper-v no se comparte con el sistema operativo). No utilizo ningún tipo de teaming ni agregación de enlaces. Cada servidor está conectado a un swich diferente.


    ¿A alguien más le ocurre lo mismo?


    Gracias.


    Un saludo

    Fernando Reyes [MS MVP]
    MCSA 2000/2003
    MCSE 2000/2003
    MCITP EnterpriseAdministrator
    Web: http://freyes.svetlian.com
    Blog: http://urpiano.wordpress.com
    RSS: http://urpiano.wordpress.com/feed/
    freyes.champú@champú.mvps.org
    (Aclárate la cabeza si quieres escribirme)
    • Marcado como respuesta Ismael Borche jueves, 28 de abril de 2011 20:52
    lunes, 20 de septiembre de 2010 13:14
  • Buenas,

    Tal vez me haya explicado mal. Si espero que se corte el servicio con la migración rápida pero no tanto tiempo como lo que me está sucediendo. El tema es que al migrar una máquina virtual mediante QuickMigration la máquina deja de responder por un tiempo aleatorio de entre segundos hasta varios minutos (siempre es la misma máquina virtual con una instalación limpia de Windows 2003)

    Como he comentado la máquina virtual se encuentra en otra VLAN diferente de la máquina de pruebas. Al hacer un ping perpetuo desde la máquina de pruebas a la máquina virtual esta no responde, pero si lo hago desde otra máquina que se encuentra en la misma VLAN de la máquina virtual, el ping responde correctamente y al instante el ping a la máquina virtual responde desde la máquina de pruebas.

    Saludos.

     

    martes, 21 de septiembre de 2010 9:14
  • Hola Admin, Fernando tiene razón en lo que te comenta en su respuesta, déjame complementarla y ponerla más en contexto:

    Cuando Microsoft lanzó Windows Server 2008 con la posibilidad de agregar el rol de virtualización (Hyper-V) al configurar este en un cluster de alta disponibilidad para VMs, sólo se podía mover una VM de un nodo a otro mediante "Quick Migration", como bien menciona Fernando al realizar un Quick Migration se guarda el estado de la VM y esta se apaga para moverse de un nodo a otro (justamente cuando se guarda el estado de la VM, se apaga y se mueve a otro nodo, es cuando detectas que la VM deja de responder).

    Posteriormente Microsoft lanza Windows Server 2008 R2 que entre sus nuevas funcionalidades incluye la de "Live Migration" la cual permite mover una VM de un nodo a otro sin que esta tenga que apagarse, es decir, lo hace en vivo por eso el termino de LIVE y es por eso que en esta no detectas que la VM deje de responder.

    Ahora, que se llame Quick Migration, no quiere decir que sea más rápida o mejor que Live Migration, sólo le pusieron en su momento ese nombre, en escenarios de cluster casi no se utiliza por la limitante de que apaga la VM para poder moverla de nodo y lo que se busca en un cluster es la alta disponibilidad y continuidad de los servicios prestados por las VMs.

    Saludos.

     

    martes, 21 de septiembre de 2010 15:50