On continue la découverte de vCD 10 couplé au support réseau de NSX-T. Après ce premier billet en forme d’introduction et de “mise en bouche”, on va taper un peu plus dans le dur avec le déroulé d’un scénario vLab complet, histoire de vous montrer les menus généraux, mais aussi la logique et la relative simplicité d’accès du nouveau portail full web et l’intégration fonctionnelle de NSX-T au sein de vCloud Director.

Tout est affaire de maîtrise minimum des concepts de base d’un VDC made-by-vmware, mais dans l’ensemble j’espère que mes explications seront suffisamment compréhensibles ^^. On y va ? Alors go. Avant toute chose, commençons par connecter notre nouveau portail vCloud aux ressources dont il a besoin pour travailler : vCenter et NSX-T.

Configuration au vCenter et au NSX-T manager

Pour ces deux étapes, pas de trop de problème ni de détails conceptuels. Il faut connecter les deux instances respectives dans les sections ad-hoc. Cela se fait sans souci. A noter tout de même que comme on va utiliser exclusivement NSX-T, on ne renseigne pas la partie NSX-V. D’après ce que j’ai lu, vCloud est capable de gérer les deux technologies simultanéement ! pas mal si vous devez gérer dans le même portail des workloads “historiques” ainsi qu’une nouvelle plateforme VSAN/NSX-T, au hasard ^^.

Je ne détaille pas ici les préparatif à réaliser sur vSphere, qui ne sont pas différents des anciennes versions avec son utilisation des resourcePools ainsi que des Storage Policies. Tout doit être déjà prêt pour que vCloud puisse exploiter les resources de vCenter.

Création du Network Pool

Pour cette partie, on commence à utiliser les nouvelles fonctions NSX-T, puisqu’on va choisir un network pool basé sur GENEVE, le protocole d’encapsulation spécifique. Vous noterez ici qu’on est capable d’utiliser aussi les type de pool de réseau déjà connus depuis longtemps sur vCloud : VXLAN, VLAN backing et mapping avec des portGroups vSphere existants.

Création d’un External Network utilisant NSX-T

Il s’agit ici de configurer un réseau externe avec un range d’IP réservé, utilisable notamment pour du NAT/PAT. On connait ça depuis longtemps sur vCloud, la différence résidant maintenant dans l’utilisation de NSX-T/GENEVE pour s’interconnecter avec l’extérieur. Auparavant, on travaillait surtout avec un mapping vSphere/portGroup. Pour la première fois, il va falloir choisir notre routeur TIER0 de “sortie”. Ici, il n’y en a qu’un, mais on peut imaginer plusieurs type de TIER0 (ce qui est notre cas en production, chacun aiguillant le trafic vers des domaines réseau bien distincts).

Création du Provider VDC, avec NSX-T en backing réseau

Une fois les “fondamentaux” réalisés, Le provider VDC est une partie de plaisir, puisqu’il suffit de relier toutes les ressources de base pour construire un provider opérationnel.

Création du Virtual Data Center de notre organisation “The LAB Company”

On approche du but, l’objectif ici est de créer un virtual data center, au sens vCloud du terme bien sûr. Il va s’appuyer sur le ProviderVDC créé plus haut et être attaché à une organisation créée de toute pièce pour l’occasion, The LAB Company… swag comme nom ^^. Pour les besoins du vLab, je ne m’embête pas avec la QoS et le contrat de service, du Pay-As-You-Go avec aucune pré-réservation suffit amplement.

Création d’une “edge gateway” pour notre VDC, connectée à au réseau externe NSX-T

Ici, il s’agit de créer une Edge Gateway qui va nous servir de router périmétrique pour notre datacenter. La edge gateway va être connectée au réseau externe créé plus haut et on va lui attribuer un certain nombre d’IP dont elle pourra disposer pour du SNAT/DNAT, en fonction de ses besoins. vCloud va traduire cette demande en la création d’un router TIER1 connecté au TIER0 indiqué plus haut dans la déclaration du réseau externe. Logique. Mais, on le verra plus tard, il manque un point important pour que la connectivité se fasse complètement.

Du coté clair de la force : Création d’un catalogue, importation d’un template OVH de VM Linux Debian 10 et déploiement.

La on est encore une fois dans le “déjà vu”, même si c’est une étape quasi obligatoire pour déployer une VM facilement sur vCloud, il n’y a rien de spécifique à relever, sauf le fait que désormais tout se fait en HTML5, plus de flash … cétipabô ?

Création d’un segment réseau connecté à notre edge gateway “NSX-T”

Enfin, avant de déployer une VM et réaliser quelques tests, on finit par la création d’un segment de réseau routé, c’est à dire connecté à notre Edge Gateway, au sens vCloud. Derrière, il s’agit de réaliser la création d’un nouveau segment NSX avec les informations minimales de subnet réseau. Ledit segment se retrouve ensuite dans la section éponyme de NSX-T, avec les caractéristiques de base indiqués dans le wizard vCloud. Il est bien sûr connecté à notre “edge” TIER1.

Conclusion/Limites

Jusqu’à la création de vApp/VM, vous l’aurez compris, le workflow est très logique et utilise un espèce de “mapping” de concepts vCloud<>NSX-T. C’est à la fois une bonne chose mais aussi un effet pervers, surtout pour le moment. En effet, même si une grande partie des fonctions de base de NSX-T sont présentent, à leurs manières dans le portail vCloud Director 10, il reste encore du travail. En effet, deux choses retiennent mon attention :
– d’une part, l’absence de toute gestion de règles de micro-segmentation (flux Est-Ouest sous NSX) oblige soit à ne pas utiliser celle-ci pour les “bulles vCloud” et passer en mode “blacklist”, ce qui limite la sécurité interne des environnements, soit à réaliser a posteriori les règles dans NSX-T, une fois que la majorité des objets sont créés pour autoriser les flux de chaque VM/vApp.
– d’autre part, quelques paramètres manquent cruellement dans vCloud quand il s’agit de connecter les Edge Gateways (TIER1 en fait, vous l’aurez compris) à leur réseau externe (leur TIER0), notamment les options qui permettent d’annoncer les routes internes aux routeurs TIER0. En effet, sans ces précieuses options, impossible d’utiliser réellement le réseau construit par vCloud Director en mode pur routing, on reste contraint à l’utiliser exclusivement en mode NAT pour exposer les services internes du VDC.

Malgré tout, force est de constater que cette v10 inaugure un nouveau cycle pour vCloud Director résolument tourné vers NSX-T. D’un coté, c’est particulièrement rafraichissant et une très bonne nouvelle pour les clients historiques de ce produit, dont nous avons la chance de faire partie ; d’un autre coté, je ne comprends toujours pas la politique de VMware concernant vCloud : il continue d’évoluer de la bonne manière, s’adapte aux nouveaux produits et suit parfaitement les évolutions du reste du portfolio (vSphere en tête) … super, mais, pourquoi ? Il reste en marge de la stratégie globale de l’éditeur et son absence de réelle commercialisation “grand public” en fait un OVNI difficile à identifier ou intégrer globalement.

Bref, je dubite … même si technologiquement, j’applaudis des deux mains !

{{uname}}

{{meta.replies}} 条回复
写下第一个评论!

-----------到底了-----------