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.

mardi 12 avril 2016

[Veeam B&R v9] Veeam EndPoint Backup 2/2 [Restauration]


Nous avons vu comment sauvegarder un serveur physique avec VEB, nous allons voir maintenant comment le restaurer à partir de cette sauvegarde.

Nous allons partir du postula que le serveur source a crashé et qu'il faut le remonter.

REMARQUE: Il est de ce fait possible d'utiliser VEB pour restaurer la sauvegarde d'un serveur physique sur une VM !!

Restauration d'un serveur physique crashé

Il est possible de restaurer le serveur sur une VM en environnement vSphere (et ainsi faire du P2V).
Pour cela, il faut :
- Créer une VM "Custom"
- Lui donner le nom désiré et la configurer en RAM / CPU et en disque dur VMDK : faire attention à créer des volumes VMDK au moins aussi gros que les disques physiques d'origine d'une part, et d'autre part, créer autant de VMDK qu'il y avait de lecteur sur le serveur d'origine.
- Faire pointer le lecteur de CD-ROM de la VM sur le fichier ISO de boot
- Allumer la VM et suivre les opération décrites ci-dessous.








  • - Sélectionner "Network storage"






  • - Sélectionner "Veeam backup repository"






  • - Indiquer les coordonnées de connexion du serveur Veeam BR hébergeant la sauvegarde






  • - Sélectionner la sauvegarde qui nous intéresse





  • - Sélectionner la sauvegarde full






  • - Sélectionner "Entire computer"


REMARQUE: Il est  maintenant possible de sélectionner le volume que l'on souhaite restaurer et nous avons la possibilité de remapper les volumes sauvegardés sur d'autres volumes.






  • - Sélectionner "Restore"






  • - La progression de la restauration permet de suivre l'évolution des tâches







  • - Rebooter la VM et veiller à détacher l'ISO sur lequel le lecteur de CD-ROM est connecté





  • - Se loger sur le serveur ainsi restauré





lundi 11 avril 2016

[Veeam B&R v9] Veeam EndPoint Backup 1/2 [Sauvegarde]


1- Qu'est ce que c'est  ?

L'efficacité de Veeam BR n'est plus à faire pour ce qui est de la sauvegarde des Machines Virtuelles.

Veeam permet maintenant GRATUITEMENT de sauvegarder des serveurs et stations de travail Windows physiques avec Veeam EndPoint Backup et d'héberger cette sauvegarde sur un repository Veeam BR.
Il est alors possible de sauvegarder tout ou partie d'un serveur physique dans une coquille virtuelle.

Veeam EndPoint Backup est à télécharger ici gratuitement.

2- Installation de Veeam EndPoint Backup (VEB)


  • - Copier la source de VEB en local sur le serveur à sauvegarder










  • - L'exécuter en tant qu'administrateur et accepter le CLUF




  • - Laisser les composants s'installer (Veeam Endpoint Service / Veeam Endpoint SystemTray Service / Microsoft SQL Server 2012 Express LocalDB Edition )


3- Création d'un phériphérique de boot en cas de restauration

  • - Insérer (ou non) un périphérique USB sur lequel il faudra booter en cas de restauration



  • - Lancer le wizard de création de l'ISO de boot



  • - Laisser les options de création de l'ISO par défaut



  • - Indiquer l'emplacement de stockage du fichier ISO de boot (la clé USB citée ci-dessus, ou n'importe quel emplacement local ou réseau) 



  • - Laisser créer le fichier ISO



  • - Vérifier la présence du fichier ISO créé sur l'emplacement cible




4- Créer un job de sauvegarde complète d'un serveur physique


  • - Dans la zone de notification du serveur à sauvegarder, sur l'icone de VEB  sélectionner "Configure backup"






  • - Sélectionner "Entire computer"





  • - Sélectionner Veeam Backup & Replication Repository 

Remarque
: il est également possible d'indiquer en tant que cible de la sauvegarde un espace local au serveur ou un partage réseau (CIFS ou NAS)



  • - Indiquer les coordonnées du serveur VBR (@IP ou nom FQDN) et les crédentials pour s'y connecter



  • - Indiquer le repository sur lequel stocker la sauvegarde

Remarque : Un Scale Out Repository ne peut pas être utilisé comme Repository cible de VEB.



  • - Il est maintenant possible de planifier la sauvegarde afin de s'assurer d'avoir toujours une image sauvegardée proche de l'état du serveur.



  • - Exécuter le job de sauvegarde


- Sur votre serveur VBR, vous retrouvez votre serveur physique sauvegardé

Remarque : Il n'est pas possible d'initier une sauvegarde depuis le serveur VBR




=> Pour restaurer, c'est ici !

[Veeam B&R v9] Scale-Out Backup Repository



Veeam propose une nouvelle génération de repository cible pour les sauvegardes: le Scale-Out Backup Repository.

Quel en est le principe ?

Il s'agit de ne proposer aux jobs de sauvegardes qu'un seul et unique espace de stockage constitué d'un "agrégat"  de Repository. Une couche d'abstraction est positionnée au dessus des périphériques de sauvegarde afin de proposer un pool de stockage virtuel unique et évolutif.



Quel en est l’intérêt ?

Sa taille est évolutive et il peut être composé d'éléments de stockages hétérogènes. 
De plus, alors qu'il était nécessaire de créer un grand nombre de tâches de sauvegardes vers autant de Repository cibles que nécessaire, il sera maintenant possible d'en diminuer drastiquement le nombre.
Il n'est ainsi plus nécessaire de monitorer le remplissage de chacun de ces repositorys afin d'éviter qu'ils ne soient complètement pleins ( car un Repository full fait planter un job) : lorsque le scale-out repository est "trop" rempli, il suffit d'ajouter un nouveau repository qui apportera un nouvel espace immédiatement consommable.

Comment le créer?


  • Créer un "Backup Repository" sur chaque cible de destination (créer autant de "Backup Repository" que nécessaire).





  • Se placer sur "Scale-out Repositories"



  • Sélectionner l'ensemble des Repository que l'on souhaite ajouter au cale-out. Notez qu'il sera toujours possible d'ajouter d'autres Repository ultérieurement


Attention : La licence Entreprise de Veeam Backup & Replication est limitée à 3 Scale-Out Repository. Si vous avez besoin de créer un Scale-Out Repository avec plus de 3 Repositorys, il faudra une licence Entrprise plus.

=> Noter également qu'un Repository utilisé dans un Scale-Out Repository ne peut plus être utilisé en tant que cible directe.


  • Les repositorys membres du Scale-Out sont listés dans la fenêtre ci dessous






  • Il faut maintenant choisir si on désire stocker les sauvegardes incrémentales avec les sauvegardes full (Data Locality) ou sur un Scale Out Repository différent pour plus de performance (Performance)





  • L’opération est maintenant terminée ......




  • ..... et le Scale Out Repository peut être utilisé comme cible des sauvegardes






lundi 4 avril 2016

[Tool] RVTools 3.8

RV Tools, outils indispensable d'inventaire des environnements virtuels vient de sortir en version 3.8 .
Il couvre aussi bien les éléments virtuels de l'infrastructure (VMs, vCPU, vDisks, Datastores, vSwitchs, version des hôtes ESXi, snapshots ....) que les éléments physiques (cartes réseaux, cartes HBA...)

En voici les dernières nouveautés de cette version :



Disponible en téléchargement ici !

jeudi 31 mars 2016

[ vSphere 6.0 U2] What's new : vSphere Host Client

vSphere 6.0 U2 est enfin disponible depuis le 15 mars 2016!
Avec cette mise à jour, de nombreuses nouveautés. Voici le lien vers la release note :
Dans ce post, nous allons découvrir le nouveau client HTML5 embarqué sur ESXi.

Donc fini le Flash ! Enfin :) 

Et il n’est donc plus nécessaire d’installer le client C# historique pour gérer un serveur ESXi standalone.

Commençons par ouvrir une page Web en HTTPS sur le nom ou l’adresse IP de votre serveur ESXi, puis accepter le certificat de sécurité :

Cliquer sur "Open the VMware Host Client":


Vous arrivez alors sur la page de login, indiquer le compte « root » et le mot de passe :


Décocher la case si vous ne souhaitez pas participer au programme d’amélioration, puis cliquer sur « OK » :



Vous arrivez alors sur le client Web permettant d’effectuer les tâches de bases d’un serveur ESXI standalone :
  • -          Arrêter/redémarrer le serveur ESXi
  • -          Créer une VM
  • -          Editer les paramètres d’une VM
  • -          Ouvrir une console vidéo sur une VM
  • -          Ajouter un datastore
  • -          Ajouter un vSwitch ou un portgroup
  • -          Etc…


Ce client ressemble fortement au client Web que l’on connaissait déjà, cependant cette version HTML5 semble légèrement plus réactive. Cette impression est à confirmer dans le temps et n’hésitez pas à me faire part de votre ressenti J

Une nouveauté dans ce client que je trouve appréciable pour nos clients est de pouvoir choisir la langue !


Vous pouvez également choisir la fréquence de rafraîchissement de vos objets (ESXi, VMs, datastores,…)

Si vous avez des retours clients sur ce nouveau client Web, n’hésitez pas à partager J