Deuxième billet de ma série sur notre grand projet NSX-T, en cours actuellement (lire le premier ici). Au menu, aujourd’hui, je vous propose de vous présenter les choix d’implémentation décidés avec l’aide de VMware, des versions cibles ainsi que des chantiers “pré-requis” qui en découlent. C’est une étape crucial qui s’est jouée ces dernières semaines et nous avons, je crois, accouché d’un design qui correspond parfaitement à nos besoins.
NSX-T pour quoi faire ? Rappel des faits
Aujourd’hui nous assurons la fonction d’hébergeur de données de santé (avec l’agrément ministériel HDS associé bien sûr) et fournissons globalement de l’IAAS aux divers clients et organismes publics qui souhaitent faire appel à nous. Ce service est aujourd’hui possible grâce à vCloud Director (en version 9.1 actuellement), qui est en production depuis quasi 6 ans maintenant. Ce même vCloud fait appel aux fonctions “Edge Gateway” d’un NSX-V implanté coté vSphere. Avec l’arrivée des Groupements Hospitaliers de Territoire, cette demande déborde du cadre initial et nous devons désormais mettre à disposition des ressources pour nos établissements rattachés dont les besoins en puissance sont plus élevés. Justement, l’infrastructure technique sous-jacente commence à vieillir et ne repose pas sur des technologies vers lesquelles nous nous sommes déjà tourné pour d’autres besoins, internes ceux-là, à savoir le HCI et VSAN en particulier. Il était donc temps de faire évoluer ce modèle. Ici le modèle TIER0/TIER1 de NSX-T semble parfait pour répondre à la question.
D’autre part nous devons aussi répondre aux enjeux de sécurité/cloisonnement de plus en plus prégnants du coté interne avec une PSSI qui évolue et se dirige tout droit vers une protection générale de nos datacenters face aux menaces venues de l’intérieur (et, accessoirement, se conformer aux best-practices de notre secteur). Vous me voyez venir, la micro-segmentation peut nous aider à franchir cette grosse marche aujourd’hui.
Contraintes
Partant de ces deux besoins majeurs, nous avons fait le choix d’implanter NSX-T pour remplacer l’architecture historique HDS et en même temps tirer partie de nos récents investissements dans le HCI (si vous voulez un argumentaire technologique NSX-T/NSX-V, rendez-vous ici). Le projet, lancé il y a 3 semaines maintenant (nous sommes le 1er avril, à l’heure ou j’écris ces lignes ^^) est déjà bien avancé et il me semblait intéressant de vous en dire plus sur le design qui ressort de nos contraintes opérationnelles (nous ne partons pas d’un greenfield) !
A ce projet déjà structurant en lui-même vient se rajouter une contrainte supplémentaire : son implantation sur notre gros cluster généraliste VxRail (voir ici pour le détail du monstre). Autant dire que tout doit être parfaitement synchronisé pour que tout s’emboîte correctement.
De plus, nous sommes en parallèle et depuis quelques semaines maintenant en train de préparer notre mise à jour vSphere 6.7, qui en est à sa dernière ligne droite (après la mise à jour de tous les produits et infrastructures s’appuyant sur vCenter : sauvegarde, Citrix, vCloud Director, NSX-V etc.). Pour couronner le tout, nous nous sommes fixé d’être à l’état de l’art de la version NSX-T, tant qu’à faire, à savoir la nouvelle release majeure NSX-T 2.4 sortie il y a peu. Hors celle-ci exige les toutes dernières build de ESXi 6.5x et 6.7x de ce début d’année 2019.
Bref, autant dire que le planning, l’articulation globale et le chemin critique du projet SDN n’est pas simple.
Un projet stratégique et premiers use cases
Enfin, et pour terminer sur le contexte, ce projet s’inscrit aussi à l’intérieur d’un planning plus stratégique et applicatif (visibilité DSI/Direction Générale) nous obligeant à, dans la mesure du possible et sans faire n’importe quoi bien entendu, livrer des environnements s’appuyant sur le SDN au plus vite, c’est à dire, avant la fin du premier semestre (Juin 2019).
Les deux “Use Cases” qui ont une telle visibilité doivent donc être pris en compte dans le projet et feront l’objet d’un suivi tout particulier. Le premier use case va nous permettre en outre de mettre en oeuvre les bases de notre offre d’hébergement pour les 3/4 années à venir de nos besoins GHT. Le second, plus pragmatique, va nous aider à modifier nos procédures de déploiement actuelles “vCloud/Edge gateway” de notre offre contractuelle HDS en les adaptant à l’aire de NSX-T/VxRail.
Alors, z’avez fait quoi ? comment ?
J’y viens, j’y viens ! Il me paraissait important malgré tout de vous présenter la “big picture”. Nous avons travaillé d’arrache-pied avec VMware depuis 3 semaines maintenant. En tout, ce sont trois ateliers distincts qui sont quasi terminés : l’atelier de design NSX-T proprement dit, l’atelier spécifique de design Sécurité, et enfin l’atelier le plus récent, vRealize Network Insight. Dans ce billet, je ne vais parler que du premier, les deux seconds feront l’objet d’autres publications dans les jours qui viennent.
Design NSX-T : les choix
Petit alerte en préambule, je vais utiliser certains concepts spécifiques à NSX-T sans les re-définir : pour ceux qui sont déjà dans la partie ou qui ont des projets/avant-projets à ce sujet, cela sera, j’espère, assez clair ; pour les autres, allez faire un tour sur des présentations générales NSX-T et ensuite revenez me lire ^^
Afin de produire une offre répondant à nos besoins HDS et GHT, nous avons fait le choix d’utiliser une transportZone de type overlay GENEVE couplée à une architecture multi-tenant. Cela paraissait logique dès le départ, mais ça va mieux en le disant. Sachant que notre cluster de rattachement (celui sur lequel on déploie NSX-T) n’est connecté physiquement qu’au réseau datacenter (Cisco Nexus 7k/5), l’overlay GENEVE ne sera déployé que sur notre domaine de vlan DC. Coté Edge Cluster, nous allons utiliser notre cluster DMZ chargé de fournir du service à l’extérieur pour héberger les appliances, avec une connectivité réseau spécifique et isolée pour la partie Overlay (histoire qu’elles puissent discuter avec le cluster principal de l’intranet).
Notre “point de sortie” TIER0 pour ce premier use case sera tout simplement notre pare-feu périmétrique, étant donné que nous ne disposons pas actuellement de routeur de périmètre (ce qui aurait été l’idéal). Derrière nous déploierons des TIER1 dédiés à chaque demande (hébergements HDS, hébergements GHT). En somme rien de compliqué ni de spécifique, par rapport au mode d’implémentation habituel.
Pour le deuxième use-case, à savoir la sécurisation progressive de nos environnements virtualisés internes, nous avons choisi de déployer une transportZone de type VLAN (qui n’utilise pas GENEVE, mais est directement connecté aux VLAN historiques de notre DC). C’est un moyen simple et efficace pour pouvoir activer rapidement la politique de sécurité sur des environnements legacy. On est limité aux fonctions de micro-segmentation, certes, mais c’est déjà un pas énorme dans la bonne direction. Il sera toujours temps, à terme, de déployer une nouvelle transportZone overlay lorsque tout le monde sera prêt et que l’on ne fera que de la virtualisation. On peut aussi imaginer déployer du TEST isolé grâce à cette future transportZone.
Design NSX-T : les chantiers de mise en conformité avant déploiement
Comme je vous le disais en introduction, ils sont nombreux. Les voici, par ordre chronologique :
– Passage de nos différents vCenter 6.5 en 6.7u1b (ce la inclus nos deux PSC externes et au moins deux de nos vCenters)
– Passage de notre MTU à 9000 sur notre datacenter, pour assurer le transit GENEVE
– Passage de notre VxRail 4.5 en version 4.7.110 (première version officielle qui supporte NSX-T 2.4)
– Ajout de cartes réseau dédiées pour l’overlay sur le cluster DMZ hébergeant notre futur Edge Cluster
La mise à jour vCenter est, comme déjà dit, en cours depuis plusieurs semaines et nous sommes aujourd’hui à 24h de l’upgrade. Comme à chaque version “majeure” de vSphere, nous prenons le temps de valider et mettre à jour au fur et à mesure nos éléments d’infrastructure client de vCenter, ce qui prend plusieurs mois. Nous nous appuyons beaucoup sur les matrices de compatibilités de VMware, mais aussi des produits tiers. J’avoue qu’avec NSX-T en plus, cela devient un vrai sac de nœuds et j’espère qu’un jour on ne sera pas en situation de blocage ^^. Mais bon, touchons du bois, pour l’instant ce n’est pas le cas.
L’overlay GENEVE (tout comme VXLAN d’ailleurs) génère mécaniquement des trames plus grosses et doit donc disposer d’une infrastructure physique capable de les acheminer sans encombre. Chez nous, cela ne présente pas de difficulté majeure, la MTU à 9000 étant déjà activée sur nos cœurs de réseau. Il va falloir malgré tout vérifier les configurations et les ajuster au besoin, puis les tester avant déploiement.
VxRail a été plus difficile à préparer dans le sens où nous avons du solliciter Dell EMC pour obtenir une version “estampillée compatible” NSX-T 2.4. C’est un des sujets qui nécessite pas mal de coordination autant de notre coté que de celui de VMware et Dell EMC. Heureusement, disposant d’un TAM VMware, celui-ci nous a grandement simplifié le travail (merci à toi David !). Aujourd’hui, nous savons ce que nous avons à faire et les dates sont en train d’être calées pour un upgrade au plus tôt.
Enfin, sachant que nos futures Appliances Edge Node seront hébergées sur notre cluster VMware “externe”, nous devions mettre en place des canaux de communication dédiés et isolés entre les hyperviseurs et le VLAN overlay GENEVE. Nous avons fait le choix de spécialiser des nouvelles cartes réseau, qu’il faudra donc installer et relier sur le VLAN en question.
La suite
Voila notre première phase de préparation bien avancée. Nous sommes dans les temps ! Les premiers jours d’atelier ont été, je dois le dire, particulièrement intenses et assez difficiles pour quelques collaborateurs qui débutent dans l’intégration réseau et sécurité. Autant dire qu’un challenge comme ce projet NSX-T n’est pas une mince affaire et cela confirme qu’il va nous falloir du temps pour que le SDN rentre dans les mœurs et soit aussi évident et naturel que la virtualisation compute aujourd’hui.
Pour le coup, je tiens déjà, alors même que le projet est loin d’être terminé, à remercier Grégory, expert NSX-T, Arnaud, chef de projet, et David notre VTAM, tous trois de chez VMware, qui font preuve d’un professionnalisme et d’une compétence pour l’instant sans faille ! Merci à vous les gens !
Le prochain billet sera consacré à la partie sécurité et micro-segmentation.
A très vite et à votre disposition pour préciser certains points comme toujours.
5