vendredi 25 novembre 2016

mercredi 9 novembre 2016

lundi 31 octobre 2016

[Stockage] PSP & SATP Dell pour baie Equallogic



J'ai récemment été confronté à l'installation et à la configuration du plugin de multipathing tiers pour baie iSCSI Equallogic de chez Dell : le MEM (Multipath Extension Module).
Ce plugin (PSP) vient enrichir la PSA (Pluggable Storage Architecture) de l'hôte ESXi et assurer une meilleure communication entre l'ESXi et le SAN Equallogic.


Profitons en pour rappeler ce que sont les PSA, NMP, SATP et PSP.

PSA (Pluggable Storage Architecture)

La PSA représente la couche du VMkernel qui est en charge de la gestion du multipathing stockage. C'est un ensemble dont les API sont ouverts aux développeurs tiers qui souhaitent proposer leurs propres plugins de failover et loadbalancing. Elle est en charge des chemins d'accès logiques à la baie de stockage.

NMP (Native Multipathing Plugin)

Le NMP est constitué de l'ensemble des plugins de failover et loadbalancing par défaut proposé par un ESXi. Le NMP est composé de 2 sortes de "sous plugin" : le PSP et le SATP. Ces derniers peuvent aussi bien être proposés par VMware (built-in) qu'avoir été développés par des sociétés tiers.

PSP (Path Selection Plugin)

Le PSP est en charge du choix du chemin physique par lequel passeront les I/O envoyées et reçues de la baie de stockage.
VMware NMP affecte un PSP par défaut pour chaque périphérique logique selon le SATP associé.
Les 3 PSP par défault proposés par VMware sont :
-  Round Robin
- MRU
- Fixed



-> Des PSP tiers peuvent être développés par les constructeurs de baies de stockage : c'est ce dont nous allons parler plus bas dans l'article.

SATP  (Storage Array Type Plug-Ins)

Le SATP est en charge des chemins physiques d'accès aux baies de stockage. Lorsque le PSP remonte l'information qu'un chemin physique d'accès à la baie n'est plus disponible, c'est le SATP qui lui indique quel nouveau chemin utiliser.

VMware fourni un grand nombre de SATP par défaut tous capables de discuter avec les baies présentes dans la HCL

Configuration iSCSI côté hôte ESXi

J'ai choisi d'utiliser 3 vmnic pour assurer la communication entre mes hôtes et la baie Equallogic.

(toutes les IP utilisées peuvent être dans un sous réseau non routé)

La configuration de chacun des PortGroup VMKernel iSCSI se fait de la façon suivante:
- Activer les MTU à 9000 (Jumbo Frames)


- Attribuer une carte physique VMNIC par PortGroup VMKernel iSCSI, et mettre les autres cartes en "unused"


Faire cette configuration des VMNICs pour chacun des 3 PortGroup VMKernel iSCSI.
Quant au Storage Heartbeat, laisser les 3 cartes actives et configurer le MTU à 9000 également.

Après avoir ajouté le Software Adapter, configurer  le VMKernel Port Binding comme ceci :



Puis du coté ESXi, ajouter les targets iSCSI du SAN, et du côté SAN, ajouter l'IQN de votre ESXi.


Installation du plugin

Vous avez 3 moyens d'installer le MEM:
- en créant une baseline UpdateManager
- en Powershell
- en direct shell sur l'ESXi : C'est la méthode que j'ai choisi. Après avoir copié le fichier "*.zip" sur le datastore local de l'ESXi, j'ai passé la commande suivante pour l' installer :

esxcli software vib install --depot /vmfs/volumes/Nom_datastore_local/dell-eql-mem-esx5-1.3.0_xxx.zip




=> Noter qu'il faudra rebooter l'hôte pour que les modifications s'appliquent.

Vérifiez que le plugin est bien installé sur votre ESXi avec la commande :
esxcli storage nmp psp list



Vos Datastores sont désormais accessibles au travers de ce nouveau PSP




Notez que des commandes ESXCLI sont disponibles



Penser à modifier le nombre de sessions maximum par volume. En effet, en configuration par défaut, seuls 2 des 3 PortGroups VMKernel iSCSI sont utilisés.

#esxcli equallogic param set -n MemberSessions -v 3




User guide du Dell MEM

Version 1.3 du Dell MEM ( pour vSphere 5.5 et 6.x)



jeudi 27 octobre 2016

mercredi 19 octobre 2016

mardi 30 août 2016

mardi 3 mai 2016

[vSphere] CPU Scheduling - Part 2

Pour les plus patients, voici enfin la suite de mon article sur le CPU Scheduling :)

Co-Scheduling

Le « co-scheduling » , de manière générale, permet d’exécuter un ensemble de threads ou processus d’un même groupe en parallèle sur plusieurs CPU afin d’avoir de meilleures performances.
Dans le cas de VMware, le but est de faire fonctionner plusieurs vCPU d’une VM en même temps.

Hyperthreading

Pour assurer de meilleures performances, l’ordonnanceur va distribuer les vCPU d’une VM sur différents pCPU, surtout avec de l’hyperthreadingRappelons que lorsque l’hyperthreading est activé sur un serveur ESXi, le nombre de cœurs logiques est égal au double du nombre de cœurs physiques. 


Cependant il y a une contrainte, à chaque instant un seul thread peut s’exécuter sur un cœur. Si on positionne les 2 vCPU d’une VM sur les 2 threads d’un même cœur, alors à chaque cycle de temps CPU, un seul vCPU pourra s’exécuter. Si cette VM a une forte activité CPU, elle ne profitera pas de ses 2 vCPU puis qu’elle s’exécute sur un seul cœur. L’ordonnanceur va donc rediriger chaque vCPU sur des cœurs différents.

Seconde contrainte: un OS traditionnel exige que ses processeurs travaillent de manière synchrone. L’ensemble de ses processeurs doivent répondre dans un délai spécifique, sinon l’OS risque de crasher (kernel panic ou Blue Screen).

Pour répondre à cette problématique, VMware a d’abord mis au point le « Strict Co-Scheduling » avec ESX 2.0. Puis il y eu un changement majeur avec le « Relaxed Co-Scheduling » apparu dans la version ESX 3.0. Depuis le « Relaxed Co-Scheduler » est amélioré à chaque nouvelle version majeure :
Source de l’image : http://houseofbrick.com/wp-content/uploads/2014/10/ESX_Timeline.png 


De base, l’ordonnanceur essaie de schéduler tous les vCPU d’une VM en même temps. S’il n’y a pas assez de cœurs physiques disponibles, l’implémentation du co-scheduling permet à un ESXi quelques flexibilités : il schédule uniquement les vCPU qui doivent exécuter des instructions tout en maintenant l’illusion que les vCPU d’une VM sont synchrones. 

Pour cela, l’ESXi maintient un « skew » (retard) par vCPU. Ce skew  augmente lorsque le vCPU ne travaille pas tandis que les autres vCPU de la VM travaillent. Lorsque le skew atteint un certain seuil, le comportement change en fonction du mécanisme utilisé : Strict co-scheduling ou Relaxed Co-Scheduling

Strict co-scheduling


De manière simple, le skew est cumulatif pour chaque vCPU. Un vCPU, qui n’est pas exécuté alors qu’il a des tâches à faire, cumule du skew. Si ce skew dépasse une certaine limite, on déschedule la VM entièrement (on dit qu’elle est Co-stoppée). 

Dans le calcul du skew, on ne prend pas en compte le temps qu’un vCPU passe en IDLE. Par exemple, si une VM avec 4 vCPU exécute une application mono-thread, elle n’a besoin que d’un seul pCPU et ne sera jamais co-stoppée. La métrique Co-Stop indique donc le pourcentage de temps que la VM est Co-Stoppée et attend d’avoir autant de pCPU libres que de vCPU.


La VM sera ensuite "co-startée" uniquement lorsqu'il y aura assez de pCPU disponibles pour exécuter tous les vCPU simultanément. La VM repassera alors en mode READY et pourra ainsi être schédulée (Dispatch).

Ce type de co-scheduling introduit de la fragmentation CPU. Par exemple, si vous avez une VM avec 4 vCPU, et que seulement 3 pCPU sont libres, celle-ci va commencer à exécuter ses différents threads puis va rapidement être co-stoppée et ne pourra plus s’exécuter tant qu’un 4e pCPU ne sera pas disponible.

Relaxed Co-Scheduling

Avec la nouvelle version « Relaxed Co-Scheduling », lorsque le skew dépasse la limite, seuls les vCPUs de la VM qui sont trop en avances, sont placés en mode COSTOP. La VM n’est donc pas entièrement figée et continue de travailler.

On traque toujours le vCPU le plus en retard grâce au « Skew ». Si le skew dépasse une limite, le vCPU qui est en avance, passe de lui-même en mode COSTOP pour attendre les autres. Une fois que le vCPU le plus lent a rattrapé son retard, les autres vCPU peuvent d’eux même se « co-starter ». Ils repassent donc dans le mode READY et peuvent être exécutés si un pCPU est disponible.

Par exemple, une VM avec 8 vCPU peut avancer dans ses tâches même s’il n’y a que 4 pCPU de disponibles. Cela améliore donc grandement le taux d’utilisation des pCPU. Par contre, si 8 pCPU sont disponibles, alors l’ESXi va faire en sorte d’exécuter les 8 vCPUs en même temps.

Depuis vSphere 5.X, de nombreuses améliorations ont été apportées afin de supporter jusqu’à 64 vCPUs par VM en version 5.5 et 128 vCPUs par VM en version 6.0.

Nous venons donc répondre à la question initiale qui a lancé ce topic :)

Dans une prochaine partie, nous pousserons le sujet un peu plus loin et nous aborderons le Load Balacing, NUMA et vNUMA.