Et oui, malgré les grandes annonces de vSphere 6.5 portant sur la sécurité et les phases d’installation et migration, il ne faut pas oublier le quotidien malgré tout, n’est-ce pas ? VMware ne nous a pas oublié sur ces aspects non plus. Ce billet vous propose de faire le point sur les nouveautés autour de vSphere HA, Fault Tolerance, DRS, SIOC et pour finir, the last but not the least, ENFIN une Content Library utilisable (si si)…
Allons-y, jetons-nous dans ce listing que je vous promet d’agrémenter de quelques exclamations ou remarques pas piquées des hannetons, afin d’éviter toute monotonie dans le discours :)
vSphere HA
Donc donc donc, commençons par vSphere HA. Une des fonctions de base qui ont fait le succès de notre éditeur favori, il faut bien le dire. De ce sujet, il faut retenir 4 grandes évolutions et nouveautés :
– Une refonte de l’ergonomie d’Admission-Control : comme pour VSAN, indiquez le nombre de hosts que vous tolérez de perdre sans baisse notable de performances et vCenter s’occupe du reste. Vous êtes également notifié d’une alerte si, en fonction des conditions d’utilisation, la capacité de votre cluster n’est plus suffisante pour assurer la tolérance au pannes indiqué.
– De nouvelles priorités dans les scénarios de redémarrage des VM : VMware a ajouté deux priorités supplémentaires à celles déjà existantes afin de donner plus de granularité dans les redémarrage sur déclenchement HA. De plus, si l’admission control est activé, celui-ci peut choisir le cas échéant de ne pas redémarrer certaines VM disposant de la priorité “Lowest”.
– La possibilité de décrire des scénarios complexes de redémarrage à l’aide de règles et groupes, un peu à la manière de DRS. La aussi, vous obtenez un contrôle beaucoup plus précis des conditions de redémarrage et de placement des VMs. Auparavant, seuls les fameuses règles should et must avaient une influence (voir ce billet).
– L’introduction d’une nouvelle fonctionnalité : “Proactive HA” : désormais, un serveur ESXi peut avoir trois états distincts permettant de déclencher préventivement sa mise en quarantaine (healthy, moderate degradation, severe degradation). En cas de panne mineure ou modérée, vous pouvez décider de faire réaliser préventivement des vMotion de vos VM pour éviter la coupure sèche.
Fault Tolerance
Ha, FT, le fameux FT que tout le monde adore dans les labs, mais que personne n’utilise ! Je plaisante bien sûr, mais c’est vrai que le coté “démonstration de savoir faire technologique” est vraiment présent au sein de cette fonction. C’est vrai aussi que les cas d’usages sont vraiment très particuliers et rarement rencontrés dans une production classique, même critique. Pour autant, VMware continue à améliorer de version en version le “mirroring temps réel” de VM et nous n’allons pas nous en plaindre.
Sur vSphere 6.5, les évolutions sont mesurées mais réelles. En substance, il est désormais possible d’agréger des liens réseaux pour booster encore plus la bande passante (assez monstrueuse, il faut bien le dire) nécessaire à la bonne marche d’une – et a forcieri plusieurs – VM en mode FT. De même, les temps de réponse réseau de chaque VM en mode FT est largement amélioré, de plusieurs facteurs, permettant une utilisation opérationnelle encore plus proche des VM classiques.
DRS (Distribtued Resource Scheduler pour les nouveaux au fond qui ne suivent pas)
Notre très cher DRS, si efficace et participant directement à l’équilibrage de charge de nos clusters vSphere, est de plus en plus intelligent, telle Algernon ! Avec vCenter 6.5, vous pouvez lui demander d’étaler au mieux les VM au sein d’un cluster (leur nombre autant que leur poids) pour éviter comme l’indique VMware, de mettre tous vos oeufs dans le même panier. Effectivement, il arrive quelque fois qu’au gré de la gestion de charge, beaucoup de “petites VM” se retrouvent sur un seul host, déséquilibrent le risque en cas de défaillance dudit host… avec ça, vous étalez le beurre de cacahouète sur toutes vos machines, ce n’est pas moi qui le dit, lisez les slides ci-dessous :D
DRS fait également attention à la bande passante réseau, en plus de la mémoire et du cpu. Bonne idée en effet, car même si, comme vous le savez sûrement, Network=CPU chez VMware, il arrive souvent qu’une bécane dont la consommation compute est raisonnable, génère des gigabits à elle toute seule (machine de réception de flux vidéos streamés par exemple).
Une bibliothèque enfin contente (attention, jeu de mot franglais un peu grossier)
Je l’ai dit lors des présentations bloggers sous NDA auxquelles j’ai participé, voila ENFIN une “Content Library” telle qu’elle aurait du être dès sa sortie. En effet, qui utilise aujourd’hui la Content Library… allez, comptez-vous, j’attends… pom pom pom… En fait, personne je crois :)
Plus sérieusement, la version 6.0 de la CL était bien trop limitée et bridée (voire frustrante) pour être réellement exploitable ou présenter assez d’intérêt pour justifier de migrer toutes ses ISOs et Templates en son sein. Pour le coup, VMware nous a évidemment écouté et présente une version qui semble vraiment utilisable, pratique et dont j’espère on pourra se servir vraiment au quotidien (il faudra juger de ses limites, si elles existes, une fois vSphere 6.5 entre nos mains).
Je vous laisse découvrir les évolutions en détail, même ne serait-ce que la possibilité de monter une ISO stockée dans la CL directement sur une VM lambda suffit à raviver mon intérêt personnel pour le composant de vCenter !
