SDDC 2.0 : VMware présente son design de référence

Le VMworld 2016 US approche à grands pas et VMware en profite pour préparer sa future audience aux nombreuses conférences et annonces (vSphere 6.5 ?) qui auront lieu pendant cet événement incontournable de l’IT. En particulier, VMware dispose aujourd’hui de toutes les fonctions nécessaires à la construction du fameux “Software Defined DataCenter” dont on parle tant depuis plus de deux/trois ans maintenant.

Afin de présenter sa vision de l’organisation d’une production SDDC, VMware a publié récemment un document très intéressant qui résume en une grande plaquette, l’ensemble des composants et leur organisation permettant de constituer un SDDC complet et autonome. Le “VMware Validated Design for Software Defined Data Center 2.0” – c’est son nom – est proposé via le VMTN à cette adresse.

On y (re-) découvre pas mal d’informations que je vous propose de commenter.

Les concepts et briques logicielles

Le document repose sur des concepts forts vis à vis de l’architecture proposée. En premier lieu VMware base la plupart de ses schémas sur la notion de “région” avec une région A constituant l’environnement primaire de production et la région B assurant la fonction de PRA/PCA. On peut noter qu’une région n’est pas forcément “localisée” comme le serait un data center ou un site X, elle est juste une notion macro indiquant un ensemble cohérent de production primaire ou secondaire.

Les réseaux sont présentés avec des feuilles (leaf) portant les terminaisons vers les réseaux externes ou les serveurs, ainsi qu’avec des colonnes vertébrales (spine) constituant le cœur de commutation Ethernet du datacenter. Tout cela est en communication avec l’extérieur évidemment.

Au niveau compute, vous le verrez, chaque regroupement de serveurs constitue un “POD”. Il ne s’agit pas à proprement parler d’un cluster au sens ESXi, mais plutôt d’un ensemble managé par un vCenter donné, j’y reviendrai plus bas.

Coté logiciel, le document présente des synoptiques résumant dans les grandes lignes les best practice d’installation des briques fondamentales – VMware évidemment – composant l’ensemble d’administration et de gestion d’un SDDC : vSphere bien sûr, mais aussi NSX Manager, Automation, Operations, Orchestrator et Log Insight.

Enfin, et ce n’est pas une surprise, VMware met en avant l’architecture très modulaire de vSphere 6 avec la partie Platform Service Controller (pour plus d’info, rendez-vous ici).

Les grands principes

Un principe qui revient régulièrement dans ce document, c’est la séparation des environnements de production en fonction de leur utilisation : vous devez disposer d’un minimum de 3 PODs distincts : un POD pour tout le management VMware (les instances Log Insight, Automation, Orchestrator etc.), un POD pour les fonction “edge” c’est à dire les fonctions associées aux services réseau externes (DMZ, frontaux divers etc.) et un POD pour le compute classique.

Cela reprend peu ou prou les best practices habituels que l’on retrouve souvent quand on discute avec des intégrateurs mais ça va mieux en le rappelant officiellement : séparer vos workloads en fonction de leur niveau de sécurité et leur usage spécifique, c’est bien :)

Du coté du stockage, évidemment, VSAN est à l’honneur, en particulier sur les PODs de management et edge. En effet, l’intérêt principal de VSAN, vous le savez, c’est d’être totalement autonome et complètement intégré à vSphere. Concernant le POD compute généraliste, là, VMware ne prend pas parti et laisse le choix (mais peut proposer VSAN aussi, évidemment). J’ai tendance à penser qu’afin de prendre toutes les garanties nécessaires, disposer de deux systèmes de stockage reposant sur des technologies totalement différentes entre un POD d’admin et un POD de compute classique est une bonne idée. Si un bug survient sur l’admin, la prod continue à tourner et si un bug survient sur la prod, on a encore tous nos outils de gestion et d’administration à disposition pour travailler à la remise en route. C’est d’ailleurs face à ce principe que nous avons choisi de mettre en oeuvre un nouveau cluster d’administration chez nous (voir ici et ici). VMware insiste aussi beaucoup sur NFS pour le stockage d’appoint ou low cost : les templates, les archives Log Insight ou les backups. C’est une bonne idée, aux vues des progrès réalisés en matière de latence et de performance sur ce protocole depuis quelques années et en particulier sous l’impulsion des pure players de l’Hyperconvergé.

Au niveau réseau, là aussi VMware est très précis dans sa démarche et recommande une séparation absolue de tous les flux (Management, vMotion/FT, VSAN, etc.). De même, désormais, la connectivité réseau “normale” de toute machine repose sur une double adduction Ethernet à 10 Gbit/s. Evidemment, a chaque POD doit correspondre un Distributed vSwitch spécifique, histoire qu’une modification de configuration de l’un n’impact pas l’autre, entre autres.

Un beau guide d’implémentation

Alors, bien sûr, tout le monde n’aura pas forcément ni la nécessité ni les moyens de constituer un environnement SDDC aussi riche que celui présenté dans ce document. Pour autant, il peut tout à fait servir de guide de référence généraliste dans le cadre d’un projet de mise en oeuvre d’un environnement vSphere ou d’un chantier d’évolution. Sans être une véritable bible, celui-ci apporte des clefs et des orientations qui peuvent ensuite vous guider vers un choix d’implémentation adapté à vos besoins mais respectant peu ou prou tout ou partie de ces best-practices.

A garder sous le coude et à rappeler lors de réunions “archi” ou de discussions générales sur vos data centers.