Best Practice Nutanix et vDistributed Switch

 

Dans cet article, nous présentons les best practices d’un nœud Nutanix avec vDistributed Switch.

 

Créer le Distributed Switch :

Choisir la version 5.5 pour le DVS. Créer un switch distribué pour votre datacenter avec 2 uplinks car nous avons 2 uplinks de 10 Go par nœud Nutanix. Activer le Network I/O Control qui vous permettra de privilégier les ressources réseaux par type de traffic, nous ne reparlerons plus bas dans l’article. Ne pas créer de portgroup par défaut.

 

 

Éditer les paramètres du vDS. Si vos switchs physiques prennent en charge les Jumbo Frames, dans Advanced placer le MTU à 9216 sinon laissez à 1500 par défaut. Si le Cisco Discovery Protocol est activé sur équipement Cisco, activez-le en mode both. Le paramètre both est le plus bénéfique pour l’environnement vSphere et réseau. Si vos équipements ne sont pas du Cisco, utilisez Link Layer Discovery Protocol.

 

 

 

 

Network I/O Control :

Network I/O Control (NIOC) est une fonctionnalité de switch distribués de vSphere depuis la version 4.1. NIOC utilise les resource pools pour déterminer la bande passante éligible à chaque traffic réseau. Par défaut, plusieurs resource pools sont créés, ci-dessous la liste :

NFS Traffic, Management Traffic, vMotion Traffic, Virtaul SAN Traffic, vSphere Replication (VR) Traffic, iSCSI Traffic, Virtual Machine Traffic et Fault Tolerance (FT) Traffic.

Chaque traffic se voit attribué un share de 0 à 100. Le share va permettre de garantir la bande passante pour ce type de traffic en cas de contention et seulement en cas de contention. Lorsque votre réseau est peu utilisé, NIOC n’a aucune incidence. Il est également possible d’appliquer des limites par type de traffic. Nutanix recommande de ne pas utiliser les limites puisque ces limites s’appliquent même en cas de non contention du réseau.

Ci-dessous les recommandations Nutanix pour NIOC :

 

 

 

Le management traffic avec un share à 25 pour deux interfaces 10Gb équivaut à un minimum de 1,5Gbps en bande passante. C’est plus que le minimum requis par VMware qui est de 1Gbps.

 

Pour le vMotion traffic, Nutanix recommande un share de 50 sur les deux interfaces 10Gb, ce qui correspond environ à 3Gbps.

 

Fault Tolerance Traffic dépend du nombre de VM FT sur votre hôte. Ce traffic peut être assez élevé. Les VMs FT sont pour la plupart critique, il est donc important de garantir une bande passante en cas de contention. Nutanix recommande un share de 50 pour garantir 3Gbps.

 

Virtual Machine Traffic correspond au traffic de vos VMs. Si le traffic de vos VMs est impactés, cela impactera les utilisateurs et votre productivité. Il est important de garantir une bande passante sur ce type de traffic. Avec un share à 100, cela garantie une bande passante d’environ 6Gbps.

 

NFS Traffic est essentiel pour la plateforme Nutanix et les VMs. En effet, Nutanix fonctionne avec des montages NFS pour son système de fichier NDFS et donc tous les I/O passeront via ce type de traffic. Nutanix recommande donc un share à 100 qui garantit un minimum de 6 Gbps.

 

Nutanix Traffic correspond au traffic entre les CVM. Cette connectivité est utilisée pour la réplication notamment. Pour des performances optimales, Nutanix recommande un share de 100 pour garantir au minimum 6 Gbps.

 

Le traffic Nutanix est un resource pool à créer. Pour cela, cliquez sur le + vert. Renseignez les informations et sélectionnez le share High :

 

 

Il apparaitra dans la catégorie « User-defined network resource pools » :

 

 

Il faudra par la suite, associer le portgroup des CVM à ce resource pool afin que le share soit pris en compte pour le traffic.

 

Créer les portgroups :

Il faut dans notre cas, créer les portgroups nécessaires à toute infrastructure vSphere (Management, vMotion, Portgroup des VMs, etc …) mais il faut également créer le portgroup utilisé par les CVM.

Une fois que le portgroup CVM est créé, il faut associer le resource pool à ce portgroup. Pour cela, éditez le portgroup et sélectionnez Nutanix Traffic dans Network resource pool :

 

 

 

NIC Team Load Balancing

Il y a plusieurs options de NIC Team Load Balancing dans vSphere :

• Route based on originating virtual port
• Route based on IP hash
• Route based on source MAC hash
• Route based on physical NIC load – appelé Load based Teaming (LBT)
• Explicit failover order

 

Si vous utilisez les standard vswitch, Nutanix recommande d’utiliser Route based on originating virtual port.

Si vous utilisez les switchs distribués, Nutanix recommande d’utiliser LBT. Cette option est avantageuse car elle ne requière aucune configuration particulière sur les switchs physiques. Cette option permet de mettre en place une solution de load balancing automatique qui utilise un lien tant que la bande passante ne dépasse pas 75% et qui, lorsque la bande passante atteint 75% pendant plus de 30 secondes, bascule le traffic sur le deuxième lien pour équilibrer la charge.

 

 

 

Network Failover Detection :

vSphere propose deux solutions pour la détection de la perte d’un lien : Beacon Probing et Link status only.

Link status only détecte la perte d’un lien en observant le statut du lien. Il détecte un problème lors qu’une déconnexion du câble. Link status only ne détecte pas un problème de configuration du port.

Beacon probing, en plus de la détection du statut du lien, va également discuter avec le switch physique afin de détecter un problème de configuration ou de perte de packet. Beacon probing ne fonctionne qu’avec 3 liens minimum, c’est pourquoi Nutanix recommande d’utiliser Link status only.

 

Notify Switches :

Permet à l’ESXi de notifier le switch physique dans le cas d’un failover. Nutanix recommande de le positionner à Yes.

 

Failover Order :

Failover Order permet de positionner les uplinks dans les catégories Active, Standby ou Unused. Nutanix recommande de positionner les deux uplinks en active. Dans le cas où vous utilisez le multiple-NIC vMotion, sur un des vMotion vous positionnerez un uplink en active et l’autre standby et l’inverse sur le deuxième vMotion.

 

Failback :

Failback positionner à Yes permet de rebasculer le traffic sur la NIC originale lorsque celle-ci est de nouveau joignable suite à un problème. Le positionner à Yes peut poser quelques problèmes si le réseau est instable ou si vous rencontrez des symptômes du route flapping. Pour cela, Nutanix recommande de positionner Failback à No. Ce qui signifie, que lors d’une panne votre traffic sera redirigé vers le deuxième Uplink et restera sur celui-ci même au retour de premier Uplink.

Voici un aperçu des recommandations Nutanix :

 

 

 

Security :

 

Que ce soit avec un switch standard ou distribué, il y a 3 options dans la partie Security : promiscuous mode, MAC address changes et forged transmits.

Nutanix recommande de positionner Reject pour ces 3 paramètres.

Il y a plusieurs scénarios qui pourraient vous obliger à positionner Accept sur un des paramètres.

Pour en savoir plus : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006778

 

Chaque cluster Nutanix dispose d’un switch standard qui ne faut en aucun cas supprimer même si vous utilisez vDS.

 

 

Chaque CVM doit pouvoir avoir une carte réseau liée au portgroup CVM du DVS et l’autre carte sur ce switch standard pour discuter avec l’ESXi.

Dans le cas où vous l’avez supprimé, voici la procédure pour le recréer : http://vroomblog.com/reconfigurer-recreer-le-vswitch-nutanix/

 

Migrer vos ESXi de vSwitch vers DVS :

 

Pour éviter une déclaration fastidieuse de vos portgroups, vous pouvez utiliser le script PowerCli de l’article suivant : http://vroomblog.com/deployer-automatiquement-vos-dvportgroup-en-powercli/

 

Une fois vos portgroup créés, il va falloir préparer les portgroups management et CVM pour la migration du vSwitch vers le dvSwitch. Pour cela, configurer les portgroups management et CVM comme ci-dessous :

 

 

Pendant la migration du vSwitch vers le dvSwitch, il va arriver un moment où vous aurez sur vos ESXi, une carte active sur le vSwitch et une sur le dvSwitch. Celle active sur le dvSwitch correspondra à l’Uplink1.

Une fois cette configuration effectuée, depuis le vSwitch du premier ESXi, on va retirer une des deux cartes actives. Dans Manage, Networking et virtual switches, vous devez voir votre vSwitch 0 avec votre management et votre réseau CVM ainsi que le vSwitch Nutanix (auquel on ne touchera surtout pas). Nous voyons deux vmnic actives :

 

 

Dans Manage the physical adapter, retirer une des deux cartes. Dans notre cas la vmnic2 :

 

 

Votre vmnic n’est plus présente :

 

 

Depuis votre switch distribué, faites un clic droit puis Add and Manage Host :

 

 

Ajouter les ESXi dans New hosts :

 

 

Choisir Manage physical adapters, Manage VMkernel adapters et Migrate Virtual machine networking :

 

 

Pour chaque ESXi, choisir la vmnic retirée à l’étape précédente et cliquez sur Assign uplink :

 

 

Ensuite, sélectionnez le vmkernel correspondant au management de votre ESXi  et cliquez sur Assign port group. Choisir le dvPortGroup de management :

 

 

Ne surtout pas migrer le vmk1 utiliser par le vSwitchNutanix. Celui-ci doit rester dans le vSwitchNutanix.

Dans Migrate VM networking, choisir d’assigner le portgroup du réseau CVM pour les CVM de chaque ESXi et si vous avez d’autres VMs, associer leur les portgroups :

Faites attention pour chaque CVM de ne migrer que le portgroup correspondant au vlan de l’ESXi. Le portgroup svm-iscsi-pg doit rester sur le vSwitchNutanix.

 

 

Cliquez sur Finish. À la fin de la migration, vous devriez voir vos ESXi liés à votre vDS et votre carte lié au portgroup de Management dans votre dVS. Pareil pour vos CVM et VM, vous devriez les voir dans les portgroups du dVS.

Côté vSwitch, sur chaque ESXi, il doit ne rester que votre vmnic sans aucune VMs exceptée la CVM de l’ESXi quoi se trouver sur le vSwitch Nutanix (qui n’a aucune vmnic associée) :

 

 

 

 

Pour terminer la migration, depuis votre switch distribué, faites un clic droit puis Add and Manage Host, choisir votre ESXi à manager et manage physical adapters. Sélectionnez le vmnic du vSwitch et associer le au deuxième uplink du dVS :

 

 

 

Vous devez avoir quelque chose comme ça :

 

 

Une fois cela fait, passer les deux liens actifs sur vos portgroup management et CVM :

 

 

Depuis votre dVS vous devez voir toutes les vmnics de chaque ESXi :

 

 

Vos ESXi sont migrés du vSwitch vers le Distributed vSwitch. Effectuez ensuite des tests de perte de lien afin de voir comment se comporte le LBT.