none
HyperV performance réseau RRS feed

 > 

  • Question

  • Question
    Connectez-vous pour voter
    3
    Connectez-vous pour voter

    Bonjour à tous,

    Symptôme : Les VMs d'un hote se partagent 1gbit/s, soit un lien physique. Quelque soit la méthode d'attachement (switch dependent/independent, IPaddress / HyperVport).
    Les drivers sont à jour, les cartes compatibles virtu (Intel i350-T4), les patchs et KB critiques passés.
    Pas de firewall, pas d'acl, du trunk allowed all.
    Load balancing sur l'infra réseau = scr-dst-ip (tests aussi effectué avec les @mac..).

    Test avec et sans VMQ, RSS, vérification SMB, offloadings....

    L'hote possède 4 interfaces Vnic, seule la patte de management à une passerelle par défaut...

    Dès qu'il s'agit de joindre une ressource "externe" (cad via le réseau physique constitués de Cisco 2960X et 4500X), le multiplexage ne fonctionne pas ou très rarement (bug??).
    Les tests sont effectués via IPerf, depuis 2 VMs, lancés en même temps.
    Environ 450 mbits/s par VMs.. soit environ 1Gbits/s sur la destination.

    Les tests "local" au Vswitch donne des scores de l'ordre de 3,5 Gbits/s par VM.

    J'ai dis "bug" car j'ai déjà réussi à voir le débit attendu.

    Peut être la configuration réseau de l'hote (4 interfaces Vnic, dont 2 routées (management et backup), mais seulement la patte de management à une passerelle) pose problème et ne permet de faire fonctionner le multiplexage correctement.

    je suis prêt à remettre en question le design réseau de l’hôte car à ce que je vois, les best practices ne parlent pas/plus de Vnic sur l'hote...

    Merci de m'éclairer de vos lumières!

    Stephane.

    lundi 8 décembre 2014 19:00
    |

Toutes les réponses

  • Question
    Connectez-vous pour voter
    4
    Connectez-vous pour voter

    Bonjour,

    Si vous n'avez qu'un seul lien physique, la méthode de teaming importe peu, puisqu'il n'y a pas de répartition de charge avec un autre port réseau. Préférez toutefois, si vous n'avez pas configuré de LACP sur le switch physique, en switch-independant / Dynamic (bon encore une fois, avec 1 seule interface, ça ne fait pas sens).

    Ceci étant dit, avec plusieurs VMs utilisant le même lien physique, vous ne pourrez pas faire passer plus d'1 Gbps sur un lien Gigabit (moins les entêtes...). Donc vos résultats sont loin d'être mauvais.

    Vous pouvez éventuellement activer le jumbo frame  si tous vos éléments réseau entre ces machines sont configurés en conséquence, mais ça ne vous fera pas dépasser le débit maximal.

    Concernant les débits "internes" au vSwitch, vous ne dépassez pas les 3,5GB/s car vous êtes limités par le CPU. Si vous avez Hyper-V 2012R2 et des VMs avec le même OS, vous pouvez configurer les processeurs du VMQ sur votre hôte physique et les processeurs du vRSS sur vos guest OS pour utiliser plusieurs coeurs CPU afin de passer outre cette limitation et atteindre les 10GB/s en interne.

    Enfin, la configuration réseau du management (IP/routage) de l'hôte n'a aucune incidence sur les performances des guest, ils ne sont pas liés. Vous pourriez retirer toute configuration réseau IP du serveur Hyper-V, les VMs pourront continuer à communiquer selon leur configuration propre. Par contre si vous partagez les ports physiques entre le management et les VMs, pensez à utiliser la QoS.

    Bon courage !

    Guillaume http://www.vinfra.ch

    mardi 9 décembre 2014 10:42
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Merci de votre réponse.

    Il y a évidemment un teaming LBFO constitué des 4 cartes physiques.
    Le seul Vswitch y est rattaché.

    Je ne suis pas en R2, donc pas de mode Dynamic.
    Concernant VMQ, il est désactivé par défaut sur des carte 1Gbit.

    Lorsque 2 VMs communiquent à travers leur hote attaché avec un teaming, leur sessions TCP respectives sont censées être multiplexées sur 2 carte physique (1 par carte), n'est ce pas?

    Sinon quel interet de faire du teaming?

    Merci de votre participation :)

    mardi 9 décembre 2014 15:03
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour,

    Réponse de consultant: ça dépend ! ça dépend d'un certain nombre d'éléments, liés, rapidement, à la configuration du teaming, du mode de load-balancing, du mode de communication (TCP ou UDP) et du nombre de ports.

    J'imagine que dans votre test, le serveur de destination est également une machine virtuelle sur un autre hôte Hyper-V ?

    Si c'est le cas, sur Hyper-V 2012, en switch independant, vous ne pouvez recevoir que sur un port physique du teaming (pour TOUTES les VM sur cet Hyper-V), quelque soit le mode de load-balancing, puisque celui-ci officie uniquement pour les flux sortant de l'Hyper-V. Si vous configurez le teaming en LACP (switch dependant), c'est le switch qui va faire le travail de load-balancing sur tous les ports physiques, et donc l'aggrégation de bande-passante.

    En 2012 R2, en mode de load-balancing Dynamic, Hyper-V sait désormais gérer plusieurs ports pour les flux entrants et attribuer un port physique à chaque VM, mais ne peut pas faire d'aggrégation en entrée tant que l'on utilise pas LACP.

    Pour plus de détails, je vous invite à lire les articles suivants où j'ai imagé les différents flux en fonction du mode de load-balancing pour comprendre plus facilement:

    Bien cordialement,

    Guillaume http://www.vinfra.ch

    • Proposé comme réponse Boris Ivanov _ vendredi 12 décembre 2014 14:02
    vendredi 12 décembre 2014 10:09
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour Guillaume,

    merci pour vos ressources, je vais les consulter.

    Mes tests sont effectués depuis 2 VMs vers un hote physique attaché en LACP.
    Le screenshot plus haut est un test entre hôtes physique.

    Merci de l'aide!


    • Modifié Stef_Dub vendredi 12 décembre 2014 10:24
    vendredi 12 décembre 2014 10:23
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Attention toutefois, l'algorithme de load-balancing du teaming LACP sur le switch physique est propre à chaque constructeur, et ne veut pas forcément dire qu'il fait de l'aggrégation de bande-passante ;-)

    (ça pourrait être si simple :-)

    Bon courage !

    Guillaume http://www.vinfra.ch

    vendredi 12 décembre 2014 10:37
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Pour info, voici les lignes du script réseau qui m'interpellent :
    set-VMSwitch -VMSwitch $vswitch -DefaultFlowMinimumBandwidthWeight 10

    Set-VMNetworkAdapter -ManagementOS -Name "Admin" -MinimumBandwidthWeight 10

    Set-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -MinimumBandwidthWeight 10

    Set-VMNetworkAdapter -ManagementOS -Name "CSV" -MinimumBandwidthWeight 10

    Set-VMNetworkAdapter -ManagementOS -Name "BACKUP" -MinimumBandwidthWeight 10

    que donne cette politique "de poids"? Qu'en pensez vous?

    Toute les interfaces, y compris celle des VMs auront un poid de 10 garanti?

    vendredi 12 décembre 2014 13:47
    |
  • Question
    Connectez-vous pour voter
    3
    Connectez-vous pour voter

    La somme des poids de tous les types d'interface qui vont être sur votre vSwitch (y compris les VMs) ne doit pas dépasser 100 (c'est un pourcentage)

    Avec votre configuration, chaque interface aura, en cas de contention des ports, la même priorité. Vous pouvez d'ailleurs remplacer 10 par 1 cela donnera la même chose.

    Personnellement, je reprend les poids que j'adapte selon les besoins et qui marchent bien avec des cartes...10Gbps:

    VM Low bandwidth: 1
    VM Medium: 3
    VM High: 5
    Host Management: 10
    Cluster (votre CSV): 10
    LiveMigration: 35-40
    iSCSI/SMB (qui peut être backup): 35-40

    (en adaptant en fonction du nombre de teams que j'ai sur les hôtes, 1 full converged ou 1 dédié réseau et l'autre stockage)

    Ces poids dans votre configuration (4*1GBps) permet aux VM de se partager de 40 à 200Mbps minimum (entre elles), l'interface de management et de cluster environ 400Mbps chacune, et le liveMigration et le backup environ 1,4Gbps chacune, quand, bien entendu, tout le monde veut discuter en même temps à ces débits au minimum ce qui arrive rarement !

    Il également faut garder à l'esprit que le LiveMigration doit être une opération qui doit se faire rapidement (évacuation d'un hyper-V, répartition de charge) et donc va prendre beaucoup de bande passante sur une très courte période si on ne veut pas que le transfert d'une VM de 4GB de ram prenne 1/2 journée quand on a besoin d'évacuer le serveur Hyper-V pour faire les mises à jour du mois.


    Guillaume http://www.vinfra.ch


    • Modifié Guigui38 vendredi 12 décembre 2014 15:13
    vendredi 12 décembre 2014 15:11
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Merci pour ces précisions, je comprend bien toute cette pondération.
    Celle constatée sur le script est donc peu pertinente concernant ces minimum garantis.

    Mais cela n'explique pas le "bridage" constaté.
    C'est comme si il ne se passait aucun multiplexage. Malgré des flux TCP différents (IP, Mac, Port) lancés en concurrence.

    Je suis dans l'attente d'un retour de MS concernant ce pb et de Bull (Hote) pour avoir des précisions sur le hardware (matrice de compatibilité, image spécifique comme pour ESX..?).

    Bon week end!


    • Modifié Stef_Dub vendredi 12 décembre 2014 18:52
    vendredi 12 décembre 2014 18:51
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour,

    Petite question, est-ce que le problème est le même dans les 2 sens ? 

    Pouvez-vous confirmer que le problème n'est pas présent de serveur physique à physique ?

    Avez-vous une petite idée de mode de load balancing configuré sur le Cisco attaché au serveur physique ?

    Est-ce qu'en lançant le test sur une seule machine vous avez le plein débit en sortie (1GB en mode de LB Hyper-V Port) ? Est-ce qu'il y a plus en mode LB IP Address ?

    Bien cordialement,

    Guillaume http://www.vinfra.ch

    lundi 15 décembre 2014 14:53
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour,

    Le multiplexagequi  m'interresse est surtout en sortie.
    En mode LACP HyperV port, une VM--un port phyisique.
    Donc normalement 2 VMs qui transfèrent en même temps = 2x1gbits/s.

    Oui cela fonctionne très bien entre hôtes physique.
    La chaine de switchs (accès, routage) est configurée avec des agrégats LACP (mode active sur Cisco et load balancing = scr-dst-ip).

    J'ai bien le plein débit d'une interface Gigabit quand je n'ai qu'un transfert.
    J'ai bien +de 2,5 Gbits/s quand ce sont des transferts locaux au Vswitch (entre VMs du même subnet et sur le même hôte, entre VM et leur hote si dans le même subnet).

    C'est comme si le Vswitch produisait le trafic via toujours le même Hash... comme s'il ne tenait pas compte de l'algorithme de répartition (4tuple par défaut je crois)...

    Merci de votre participation!

    lundi 15 décembre 2014 15:28
    |
  • Question
    Connectez-vous pour voter
    3
    Connectez-vous pour voter

    Bonjour,

    On va faire différemment pour voir si la répartition de charge se fait correctement à la source ou s'il utilise une seule interface:

    Sur le serveur Hyper-V (ou un serveur de management si vous êtes en mode core),

    • ouvrez un perfmon.
    • Choisissez le compteur Network Adapter > Bytes Total/sec puis sélectionnez uniquement les interfaces physique du team (Dans mon cas, uniquement 2 interfaces
    • Cliquez sur Add puis OK. Vous devriez voir la répartition totale.
    • Vous pouvez également recommencer avec uniquement les Bytes Send/sec pour voir si en sortie la répartition se fait correctement, puis Received/sec pour voir si le LACP fonctionne correctement.
    • Je vous invite à faire de même sur le serveur physique en réception d'Iperf.
    • Choisissez histogram bar pour une meilleur visualisation.

    Bien cordialement,

    Guillaume http://www.vinfra.ch

    mardi 16 décembre 2014 09:29
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour,

    je n'ai pas pu faire d'installation fraiche encore.

    Par contre j'ai reconfigurer l'agrégat (de 7 interfaces) et comme par miracle j'ai du multiplexage :

    Et 3 flux conséquent :

    Tests = transferts IPerf simultané de 3 VMs vers un hote physique.

    Qu'en conclure?
    Que le mécanisme de hashing pose un problème coté VSwitch, ou que lors de la désactivation de VMQ il faut aussi reseter la config LACP coté switch pour que tout remonte correctement (Hashing, Mac@...).

    Je vous ferai part des éclaircissements, et je suis toujours preneur d'éventuelles remarques!


    • Modifié Stef_Dub mardi 16 décembre 2014 15:26
    mardi 16 décembre 2014 15:25
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour,

    Lorsque vous changez de configuration du VMQ, essayez de redémarrer la carte réseau physique (Restart-NetAdapter), pas toutes en même temps si possible. Je ne sais plus si c'est obligatoire, je le fais systématiquement, ça ne mange pas de pain.

    Par contre la configuration du switch physique ne -devrait- pas être impactée par le changement VMQ puisqu'il cette technologie n'agit qu'en interne sur votre serveur Hyper-V.

    Je ne comprend pas pourquoi vous désactivez le VMQ, les cartes Intel ne sont pas réputés pour avoir des problèmes avec cette feature (ce ne sont pas des  $@#%! d'Emulex :-). Correctement configuré, VMQ permet de répartir la charge processeur sur tous les coeurs de votre/vos processeurs. Lorsque vous le désactivez, toute la charge est concentrée sur 1 seul coeur du processeur qui peut rapidement arriver à saturation et brider votre débit réseau. En moyenne, sur les processeurs actuels, le débit est limité à environ 3-5GBps, peut-être un peu plus sur les processeurs les plus récents (j'obtiens au mieux 2-3.5GBps sur des AMD Opteron qui ont 2 ans sans VMQ, et les +10GBps avec VMQ correctement configuré).

    Vous pouvez facilement le vérifier: lorsque vous faites vos tests de charge, lancez le taskmgr et mettez le graphe de performance en Logical processors pour tous les voir, vous devriez voir un coeur qui est beaucoup plus chargé que les autres si vous avez une limitation à ce niveau là.

    Bien cordialement,

    Guillaume http://www.vinfra.ch

    mercredi 17 décembre 2014 11:19
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour,

    effectivement je redémarre les interfaces histoire d'être sûr.
    Les seuls tests concluant l'ont été avec VMQ désactivé.

    Surement influencé par les pb rencontrés chez Broadcom ou Emulex...

    Cela dit il me semble que les VMQ ne sont pas activées par défaut sur des interfaces 1G.

    Un consultant est passé aujourd'hui et n'a pas trouvé la cause du pb.
    La répartition de traitement pourrait être un problème mais elle ne "briderait" pas précisemment les flux réseau à 1Gbits/s je pense.

    Ce que j'ai remarqué c'est quand le problème se pose, toute les interfaces sont activés en même temps, ensemble, dans le perfmon... (bug??) :


    La seule solution étant de "resetter" la config LACP/Agrégat, pour retrouver un multiplexage sur les interfaces disponibles....

    Quelques KB nous ont été conseillées, je les mettrai par la suite, merci de votre participation.
    Je repasse dès que j'ai du nouveau.

    mercredi 17 décembre 2014 16:39
    |