vCloud Director 10 et NSX-T (1/2) : si seulement VMware le vendait encore …

Quel dommage ! Depuis des années, l’excellent Lab Manager, devenu entre temps vCloud Director, a petit à petit perdu son leadership de portail “cloud privé” au profit de vCloud Automation/vRealize Automation (issu du rachat de Dynamic Ops en 2012 je crois). A tel point qu’il est venu un moment où, malgré ses grandes qualités, vCD a finalement disparu du portfolio commercial de VMware, littéralement. Pourtant, celui-ci, que beaucoup croyaient déjà mort et enterré, a continué à vivre et évoluer, en grande partie sous la pressions des dizaines de cloud providers, les fameux vCPP, qui n’étaient pas prêts à lâcher un bon outil aussi facilement (surtout comparé à la lourdeur de vRA à l’époque). C’est ainsi qu’aujourd’hui, vCloud Director 10, sorti il y a peu, offre toujours, à mon sens, une des meilleures plateformes de cloud privée alors même que VMware ne le vent plus !

Donc, oui, et plutôt deux fois qu’une : quel dommage, quand on sait que le rythme de développement de vCloud Director n’a que peut changé depuis plus de 4 ans avec une release majeure tous les ans, en gros ! Quel dommage quand vCloud Director 10, en 2019, s’est enfin débarrassé de Flash au profit d’une interface désormais full HTML5, qu’il intègre enfin tout ce qu’il faut pour prendre en charge les fonctions de base de NSX-T 2.5 (il n’est d’ailleurs compatible qu’avec cette version 2.5), en plus de NSX-V, toujours là bien sûr. Quel dommage aussi quand il est fourni maintenant en virtual appliance et que sa base de donnée maitresse est PostgreSQL ! Quel dommage enfin quand, pour l’avoir entretenu et suivi durant toutes ces années chez nous, je ne peut que louer sa simplicité de mise à jour, sa grande fiabilité et la richesse de son API (il en a fait du chemin le petit, depuis le temps où il fallait “préparer” les ESXi avant de pouvoir déployer des workloads vCD… ce n’est plus le cas aujourd’hui, vous installez, vous paramétrez et vous consommez).

Bref, vous l’aurez compris, je ne comprend toujours pas pourquoi VMware ne le vend plus, tant il aurait encore à offrir, même aujourd’hui à l’heure du cloud public et des containers, pour produire de l’IAAS efficacement. Mais, pas besoin de me croire sur parole après tout. Je vous propose de suivre avec moi une installation de vCloud Director 10. Vous allez voir, c’est simple, c’est beau, et c’est opérationnel en 30 minutes !

Déploiement initial

vCD est fourni sous forme d’OVF et un assistant vSphere d’installation, comme quasi tous les produits de VMware aujourd’hui. Pour Autant, je préfère, étant en mode vLab, utiliser le bon vieux OVFTool, histoire de pouvoir facilement reproduire l’install si je suis amené à tout casser et tout reconstruire rapidement. vCD est, depuis le début, basé sur une base de données relationnelle, dont on doit assurer la disponibilité, mais également de “cellules” qui chacune discutent entre elles pour fournir le service. Chacune de ces cellules exécute une “copie” de vCloud (son portail et l’application d’ordonnancement et de gestion des accès API) et peut être accédée via un load balancing quelconque, la cohérence générale étant, quant à elle, assurée par des mécanismes internes et deux ressources communes : la bdd et un share NFS monté sur chaque cellule.

L’OVF vous permet d’installer trois type de VM : une VM “primaire” où va tourner la base de donnée et une cellule, une VM “secondaire” où une copie de la bdd en standby ainsi qu’une cellule, ou tout simplement une cellule seule, sans bdd. Pour notre exemple, comme toujours, on va prendre le plus simple, une VM primaire. Voici la ligne ovftool que j’utilise pour déployer cela “en une seule fois” et en 1 à 2 minutes.

Je ne vais pas détailler l’ensemble des paramètres, mais il faut malgré tout noter que vCD 10 utilise par défaut deux carte ethernet : l’eth0 est réservé à l’accès au portail lui-même ainsi que le “console proxy”, qui écoute sur la même IP frontale mais via un port différent (le 8443) ; l’eth1 est réservée au “back-end” en quelque sorte et expose l’accès à la base de données PostgreSQL. Ainsi, vous assurez une rupture protocolaire et une isolation logique entre le front et le back. Historiquement, les instances vCloud reposaient plutôt sur une seule carte réseau gérant la plupart des flux. Chaque cellule disposait de deux IP distinctes : une pour le portail et une pour le console proxy (qui écoutait aussi sur le 443, du coup).

Au final, il s’agit donc de définir deux IPs sur des subnets différents. Si vous ne déployez, comme moi, qu’une instance primaire, le réseau back-end n’est pas utilisé, donc vous pouvez choisir un peu ce que vous voulez, mais pour les autres, suivez la documentation, très bien faite je trouve, à ce sujet. A lire ici.

Après quelques minutes, l’instance vCloud primaire est démarrée et vous pouvez commencez à la configurer. Si vous avez des soucis au départ, rendez-vous dans le répertoire /opt/vmware/var/log/vcd , vous y trouverez tous les logs d’installation. Cela m’a pas mal servi au départ dans mon vLab, j’avais des petits soucis de NFS, ce qui bloquait le lancement initial.

Configuration SSL, avant toute chose

La première chose que je fais en général, c’est modifier les certificats SSL utilisés, histoire de ne pas avoir de comportements étrange, notamment sur les uploads/download dans l’interface Web. vCloud est un produit qui se veut très secure, forcément, donc il est assez pénible avec cela. Je vous conseille de commencer par ça aussi, en utilisant votre PKI interne, même si vous restez en PoC. Il faut générer un nouveau “keystore” complet intégrant la clef privée et le certificat associé au portail ainsi qu’au service console proxy, sans oublier de rajouter les certificats root et intermédiaires de votre PKI. Enfin, vous allez indiquer à vCloud d’utiliser ce keystore. Pour l’exemple, j’ai utilisé ces divers commandes pour arriver à mes fins. Connectez-vous sous root pour réaliser ces manipulations.

Les deux premières lignes OpenSSL permettent de convertir une source de certificats/clef privée du format PEM au format PKCS12. Au final vous obtenez deux fichiers P12 à intégrer dans votre keystore. Les deux commande suivantes “keytool” permettent de le faire. Pas besoin de créer le keystore, c’est réalisé automatiquement lors de la première commande. Enfin, les deux commande suivantes permettent d’intégrer directement les certificats racine et intermédiaire de la PKI que j’utilise (une petite CA OpenSSL tout ce qu’il y a de plus simple. Très pratique au quotidien, je vous le recommande. Rendez-vous ici si vous êtes intéressé).

Enfin, la dernière commande “cell-management-tool” permet d’indiquer à la cellule vCD de prendre en compte ce nouveau keystore à la place de l’ancien. Le Keystore est copié dans la hiérarchie de fichiers vCloud et intégré à la configuration. Il vous faudra redémarrer la cellule en question pour qu’elle prenne en charge ces nouveaux certificats et clefs privées.

Connexion au portail, découverte

On peut maintenant commencer à découvrir le portail HTML de vCloud Director 10. Ca change du bon vieux “flex”, vous allez le constater ^^. L’URL d’accès à la partie administration centrale, dites “provider” est au format https://fqdn-cellule/provider mais à la première connexion, si vous voulez éviter les problèmes d’affichage, utilisez directement l’IP https://x.x.x.x/provider. Ensuite, on se dirige très vite vers la section “Public Addresses” pour positionner les FQDN, justement :

Voila, notre vCloud Director est près à être utilisé ! Bon, je triche un peu, il faut aussi préparer toute la partie “VDC provider”, mais globalement, vous êtes déjà en bonne place pour fournir de l’IAAS d’ici une petite heure ^^. Le paramètrage en question est, comme souvent, très dépendant de l’infrastructure sous-jacente. Par contre, les différentes étapes sont la plupart du temps a réaliser dans un ordre similaire. Celui que j’ai utilisé vous donnera un petit guide de travail :
– Préparation vCenter : création d’un pool de ressources dédié “vCloud” dans le cluster compute que vous comptez utiliser
– Préparation vCenter : création d’un tag et d’une catégorie “storage”, qu’on va utiliser pour tagguer les datastores que vCloud pourra utiliser
– Création sous vCenter d’une storage policy, à base de tag
– Sous vCD : Connexion au vCenter cible
– Sous vCD : Connexion au manager NSX-T
– Sous vCD : Création d’un “network-pool” basé sur la transportZone NSX “Geneve” (il y plein d’autres possibilités évidemment)
– Sous vCD : Création du “provider VDC” qui associe toutes les ressources préparées précédemment

Voici quelques copies d’écran qui présentent certaines des étapes décrites plus haut :

Je vais m’arrêter là pour ce premier article. Le prochain sera consacré à l’utilisation de NSX-T à travers vCD et la manière dont il exploite le concept de edge gateway, qui n’a pas disparu pour autant. A très vite !

Sources pour cet article :
– un billet sur vCD 10 par Tom Fojta , à lire ici.
– la doc vCD 10, et oui, RTFM, ça marche, des fois ^^, à lire à partir d’ici.