mes 2 cents sur vsphere 5.5 part 3

dans cette partie, je vais me focaliser sur les améliorations côté réseau. Là encore cette release apporte son lot de modifications importantes mais aussi introduit un nouveau produit, NSX. Je me suis laissé dire qu’à terme il remplacera DVS. Nous verrons bien !

en attendant une série d’amélioration concernant directement le DVS.  LACP : Lacp étant l’aggregation de liens réseau dynamique par CISCO, il était normal que vSphere le supporte. C’était déjà le cas depuis la 5.1.

  • supporte jusqu’à… tenez vous bien… (tenez vous mieux on voit tout là !) 64 groupes de liens par hosts (LAGs) et par DVS. Avant ? c’etait 1 🙂
  • Le nombre d’algorithme de load balancing passe de 1 (« route based on IP hash » si mes souvenirs sont bons) à… 22 !
  • Un template peut être généré afin d’accélérer la configuration qui se faisait par host précédemment…
  • La configuration est réalisée au niveau du DVS et non du port group
  • le support de liens 40 Gb est arrivé ! bon pour les riches geeks pour le coup 🙂
  • ACL : le traffic filtering basé sur des règles par : adresse IP, adresse MAC ou type (ICMP… etc)
  • QOS tagging : afin de prioriser finement le traffic (toujours dans l’optique de virtualiser les applications critiques), il y a maintenant possibilité de gérer des SLA, au niveau 3 (au niveau du header IP donc et non plus au niveau du header ethernet comme en 5.1), gestion de la bande passante, conservation du tag après passage sur un switch physique, donc gestion de la QoS de bout en bout.
  • SR-IOV : bon autant être honnête, on rentre maintenant dans les côté obscure de mes connaissances réseau ! mais enfin ceux qui sont intéressés : présenter une carte PCIe comme plusieurs matériels réseau était possible depuis la 5.1.
  • Maintenant la configuration a été simplifiée. De plus la configuration des ports groups (VSS comme DVS) est maintenant propagée à l’ensemble des « fonctions virtuelles » de la carte.
  • Enfin un nouvel outil, comparable à TCPDUMP de linux a été ajouté à l’ensemble des outils disponibles pour le « troubleshooting ».
  • NSX : l’achat de NICIRA en 2012 promettait du lourd et là il faut reconnaitre (bon j’ai pas testé encore) que ça va pulser ! un petit pas pour l’homme un grand pas pour le SDDC… En bref (ne rêvez pas en clair il faudra repasser) l’abstraction des couches réseau de la 2 à la 7 est effective !  Bon il reste la couche  1 là oui ça va être compliqué de la supprimer quand même 🙂  On passe donc au modèle d’hyperviseur réseau et là il va falloir que je révise beaucoup le sujet pour bien l’intégrer.

D’ors et déjà, on peut distinguer plusieurs composants :

  • le contrôleur NSX ou plutôt le cluster de contrôleurs en l’occurrence (un minimum de 3 est préconisé) qui partagent la partie… contrôle du traffic. Il peut se représenter par 1 VM si l’on est en environnement pur VM, ou sous la forme d’une appliance en cas d’environnement multi-hyperviseurs. Oui il y a déjà le support (au minimum) de KVM et XEN !
  • NSX virtual switch : en environnement full VMware, c’est tout simplement un agent (UW agent) qui va communiquer permettre la communication du DVS et du contrôleur. En environnement hétérogène, open vSwitch pour KVM et XEN et… NSX vswitch for ESXi, le nouveau vswitch ! (ça fait maintenant 3 VSS, DVS et NVS ? NVE ?)
  • NSX Gateway : classique, il faut bien pouvoir gérer les entrées sorties de l’environnement NSX, en attendant que le monde soit NSXisé du moins ;). la gateway apporte des fonctionnalités tant au niveau 2 qu’au niveau 3 et permet les échanges vers le monde physique et le monde virtuel, indifféremment. Là encore soit on est en full VMware et on peut utiliser un vapp NSX Edge (précédemment vShield Edge). Sinon il faut des appliances physiques (lesquelles… je dois encore creuser désolé).

NSX fourni des services sur 5 fonctionnalités essentielles :

  • switching,
  • routage,
  • firewalling,
  • load balancing et
  • VPN (bon il va falloir que je bascule en anglais si ça continue là…).

Je n’irais pas plus avant car il faut maintenant que je mette les mains dans le cambouis ! comptez sur moi pour m’y mettre sérieusement dès Barcelone 🙂 et il y aura d’autres billets sur ce sujet, sur de sur.  J’ai certainement oublié beaucoup de choses sur ces 3 parties cependant il me semble que l’essentiel est là. N’hésitez cependant pas à commenter si il y a eu un trou dans la raquette !

mes 2 cents sur vsphere 5.5 part 2

Une bonne partie des nouvelles annonces concerne le stockage. C’est bien naturel quand on voit toutes les annonces autours du stockage ces derniers temps. Dire que le SSD est en train de révolutionner l’infrastructure est tout sauf un « bulshit » marketing ! honnêtement il y a maintenant énormément de technologies, d’évolution qui découlent de ces petites boites qui envoient de l’IO…Je vous invite à suivre les blog du fameux chad aka @sakacc ou de cormac hoggan aka @vmwarestorage, mes guru sur le sujet. Très clairement,  vmware ne pouvait pas laisser passer le train sur le sujet. Surtout pas avec son positionnement sur le SDDC ! De très bonnes choses dans cette mouture donc :

  1. Vsphere flash read cache :en voilà une fonctionnalité qu’elle est bonne !!! vSphere disposait déjà de la possibilité de disposer d’un cache SSD pour la partie hôte, la version 5.5 apporte un read cache pour la partie VM ! et ce cache est compatible avec les fonction de haute disponibilité, de continuité d’activité… Concrètement, un pool de ressource flash va être configuré en prenant tout ou partie SSD des ESXi elligibles. Une nouveau système de fichier a été implémenté, VFFS  Ensuite, ces ressources peuvent être réparties entre « host swap cache » (pour… on s’en doute ! gérer le SWAP mémoire) et du « VM read memory cache »… seul point noir à l’horizon pour moi, il faut gérer le VM read cache par VM ! un peu de conf en perspective donc. A voir ce que ça va donner dans les faits, la techno étant encore récente.
  2. VSAN :tiens ça fait quoi  ça ? Un module kernel qui utilise le stockage local d’un pool d’esxi en mode hybride exclusivement (1ssd + 1 hdd par esxi minimum) OMG ! pour le coup le nom San pour désigner un pool de disque locaux est bizarre mais la technologie c’est bon ! Pas nouveau mais bon car forcément pleinement intégré à l’interface (uniquement l’ihm Web au passage) et pilotable par le client (Web…).  On nous annonce des policies qui vont simplifier l’administration et augmenter la Qos.
    Bien évidemment,  VSAN travaille au niveau du cluster et s’intégrera parfaitement avec les fonctionnalités de HA / DRS / SDRS qui font toute la qualité d’une infra vmware. L’intégration du compute et du storage prend tout son sens, et on voit bien qu’il ne s’agit pas d’un repackaging de VIRSTO ou de VSA mais bien d’une nouvelle solution. Le cluster a pour l’instant des limitations fortes : 3 à 8 hôtes possédant 1 HDD et 1 SDD pour la partie stockage. Ensuite certains hôtes pourront consommer des ressources stockage sans en apporter ça c’est pour le côté dynamique… J’attends fébrilement de pouvoir tester tout cela,  d’en voir le prix cependant cela promet de bonnes choses,  de nouvelles pistes pour les clients et…  Nous 🙂

On A donc un accélérateur de « read io »  et une solution de stockage partagé pour la « write io. A voir comment tout cela va pouvoir s’intégrer avec les solutions de stockage existantes et pourquoi pas virsto (VSA me semble hors sujet et dédié à de petites structures voir… Voué à disparaître ?) La dernière partie concernera la dernière brique de l’édifice SDDC : le réseau ! Avec ces technologies de stockage le réseau devient on ne peut plus central puisqu’il intègre aussi la partie « control pane »  du stockage !