Avez-vous un compte?
Ce document décrit comment configurer et dépanner le Qualité de service (QoS) pour les virtual machine (VM) sur l'installation du Système d'informatique unifiée Cisco (UCS) et du Commutateur Cisco Nexus 1000V. QoS peut être commandé au Nexus 1000v et/ou au niveau UCS. Ce document explique les deux variations et leurs effets en résultant.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les sorties de commande dans ce document sont basées sur des ces logiciel et versions de matériel :
La version de logiciel n'est pas une limite pour la caractéristique expliquée de QoS. Cependant, les exemples dans ce document sont seulement valides pour des Cartes adaptateur Cisco.
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est vivant, assurez-vous que vous comprenez l'impact potentiel de n'importe quelle installation de commande ou de capture de paquet.
Dans cette installation, l'UCS est connecté au swtich de gamme de Nexus 5000 par l'intermédiaire du Port canalisé virtuel (vpc). Chaque lame de l'UCS a deux contrôleurs virtuels d'interface réseau (vNICs), un pour le vSwitch et l'autre pour le Nexus 1000v. Le système d'exploitation (OS) installé sur les deux serveurs est version 5.1 de VMware ESXi. Chaque hôte a une VM avec du l'Invité-SYSTÈME D'EXPLOITATION de Windows 2012.
Voici quelques détails au sujet de la configuration réseau :
Le vNIC pour le Nexus1000v sur le serveur 1/5 a un chemin primaire de matrice-Un, et le vNIC pour le Nexus1000v sur le serveur 1/6 a un chemin primaire de matrice-b. Par conséquent, le trafic à travers ces hôtes traverse par les Commutateurs en amont de Nexus 5000.
Voici la configuration QoS globale UCS :
Comme illustré dans l'image, n'importe quelle stratégie QoS avec une priorité d'argent a une valeur de Classe de service (Cos) de 2 et ceux avec une priorité d'or avoir une valeur CoS de 6.
Des stratégies QoS Milan et la florida sont créées pour les deux hôtes.
Que l'UCS contrôle le cos pour un vNIC ou pas strictement dépend de la zone de commande de Host Control de la stratégie QoS, qui est assignée à ce vNIC particulier.
La stratégie QoS de Milan a un Host Control de complètement, ainsi il signifie que la priorité d'or (le cos 6) est ignoré et la configuration du Nexus 1000v est de confiance.
La stratégie QoS de florida a un Host Control d'aucun, ainsi il signifie que tous les paquets sur ce vNIC sont remarqués avec la priorité argentée (cos 2) indépendamment des configurations du Nexus 1000v.
La stratégie QoS Milan est assignée au vNIC de la lame 1/6, qui héberge la VM - SJTAC. Par conséquent, n'importe quel trafic envoyé par SJTAC, marqué au Nexus 1000v, est de confiance et non modifié.
La florida de stratégie QoS est assignée au vNIC de la lame 1/5, qui héberge la VM - TEST. Par conséquent, n'importe quel trafic envoyé par le TEST est remarqué à l'UCS à la valeur 2 de cos
Sur le Nexus 1000v, deux policy-map sont créés pour chacune des VMs. Le gold_in_mark de stratégie place le cos à 4 et le silver_in_mark de stratégie place le cos à 5 comme affiché ici :
Cette configuration du Nexus 1000v est la configuration la plus commune vue pour les configurations de base de QoS.
VM SJTAC (le veth 3) est donné une stratégie QoS de gold_in_mark, et la VM de TEST (le veth 6) est donné une stratégie QoS de silver_in_mark.
Par conséquent, le trafic VM SJTAC est identifié par le cos 4 au Nexus 1000v. Puisque l'hôte correspondant (lame 1/6) a une stratégie QoS de Milan, cette le cos est non modifié à travers l'UCS et tous les paquets qui proviennent de SJTAC ont une configuration de QoS du cos 4.
Le trafic VM de TEST est au commencement identifié par le cos 5 sur le Nexus 1000v, mais on le remarque sur le vNIC UCS à une configuration de QoS du cos 2 parce que l'hôte correspondant (lame 1/5) a une stratégie QoS de florida avec une priorité d'argent.
Vérifiez les configurations sur l'UCS et montrez que le marquage de QoS/la remarque comme expliqué précédemment est vu réellement sur les captures de paquet.
Pour une configuration QoS plus détaillée sur l'UCS, référez-vous à configurer la qualité de service.
Pour une configuration QoS plus détaillée sur le Nexus 1000v, référez-vous au guide de configuration de qualité de service de Cisco Nexus 1000V, la version 4.2(1)SV2(2.1).
Vérifiez que les configurations UCS CLI ont été mises en application avec le GUI d'UCS Manager.
Cette sortie affiche les stratégies QoS correspondantes et leurs configurations de la priorité :
Cette sortie affiche le mappage de la priorité avec la valeur CoS :
Cette sortie affiche la confirmation de la stratégie QoS qui est appliquée à la lame 1/6 à un vNIC spécifique :
Cette sortie affiche la confirmation de la stratégie QoS qui est appliquée à la lame 1/5 à un vNIC spécifique :
Ceci affiche un ping continu initié à travers les deux VMs :
L'IP VM SJTAC est 172.16.16.224 et l'IP VM de TEST est 172.16.16.228
Des captures de paquet sont faites chez Fabric Interconnect afin de vérifier les configurations de QoS à travers l'hôte :
Capture 1 :
Capture 2 :
Comme vu dans la capture précédente, paquets que 172.16.16.228 provenu (VM de TEST) sont placés avec une valeur de QoS du cos 2 et des paquets que 172.16.16.224 provenu (VM SJTAC) sont placés avec la valeur de QoS du cos 4.
Ceci explique comment la zone de commande de Host Control dans l'UCS et les configurations de QoS sur le Nexus 1000v coexistent et modifient les paramètres de cos pour le trafic qui commence au niveau VM.
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.