EDIT : Mise à jour concernant les problèmes d’installation de certificats SSL sur NSX Manager
Je vous avais présenté notre projet de mise en place de Deep Security sur NSX il y a quelques semaine déjà (voir ici). Au départ nous avions envisagé de mettre en place un nouveau cluster au sein de notre vCenter existant, après sa mise à jour en vSphere 6. Or, entre temps, nous en avons parlé avec VMWare et il s’est avéré que c’était plus compliqué que prévu.
En effet, nous disposons aussi, vous le savez sans doute, d’une instance vCloud Director, connectée au vCenter de production. Or, on nous a confirmé en fin d’année que nous ne pouvions pas faire cohabiter vShield (utilisé actuellement par vCloud) et NSX au sein d’un même vCenter. Cette mise en place “intégrée” nous aurait donc obligé à réaliser une phase d’upgrade vShield vers NSX qui complexifiait beaucoup le chantier technique.
Du coup, nous avons pris la décision de créer un nouvel ensemble de production complet autonome : vCenter, Deep Security et NSX, bien entendu. Cela présente finalement de nombreux avantages : on dé-corréle la mise à jour vSphere 6 de notre production historique par rapport à ce chantier, on prend donc moins de risques avec nos VM et on peut vraiment tester et valider sereinement la nouvelle infrastructure avant sa mise en production réelle. Evidemment, l’inconvénient principal est la multiplicité des vCenter, mais avec un Linked-mode amélioré en vSphere 6, on devrait s’en sortir sans trop de peine.
Dans ce contexte, je vous propose de vous retracer rapidement la mise en ordre de marche de ce vCenter avec NSX que nous avons réalisé la semaine dernière.
Installation de base
Nous avons basé notre nouvelle plateforme sur les dernières versions en date de vCenter et ESXi : 6.0 update 1b. Quitte à monter un tout nouveau vCenter, autant choisir la solution VCSA : son déploiement est simplifié, tout comme son administration, la base PostgreSQL est tout à fait suffisante pour l’environnement cible et le support VMWare est totalement autonome en cas de souci.
Malheureusement, Update Manager n’est pas encore directement livré en virtual appliance, du coup, nous avons mis en place une deuxième VM sous Windows 2012R2 pour ce composant et installé celui-ci en mode SQL Server Express. La aussi, le souci de simplicité et le périmètre de production nous a guidé dans ce choix.
Au sein de ce vCenter, nous avons ajouté un nouveau cluster constitué de deux serveurs ESXi récupérés de notre production historique et réinstallés en 6.0. Je vous passe les détails sur les patchs divers via Update Manager, la construction et application de la configuration via les Host Profiles ou encore l’intégration à notre Active Directory. Ce sont des opérations qui sont connues de la plupart des administrateurs vSphere aujourd’hui je pense. Au final, nous étions fin prêts à nous lancer dans l’installation de NSX !
Installation de la couche NSX
Etant donné que nous n’étions pas “aidés” par un prestataire ayant déjà réalisé cette opération (mais notre ingénieur réseau a suivi une formation NSX), nous nous sommes basé à la lettre sur la documentation d’installation, histoire de respecter le timing et les pré-requis. La première étape consistait à déployer NSX Manager, le composant de la suite SDN qui s’occupe de discuter avec vCenter, qui pilote l’ensemble des contrôleurs et fournit les fonctions nécessaire au Plug-in NSX pour vSphere Web Client. Pas de souci majeur de ce coté là. Après l’import de l’OVA et le paramétrage réseau initial, la VM démarre et présente son portail “NSX Manager”, prèt à l’emploi.
Ensuite, il a fallut connecter le NSX Manager au nouveau vCenter. Vous avez deux services à connecter, le Lookup Service et le vCenter lui-même. Là non plus, pas de problème, en tout cas vis à vis de l’interface NSX Manager (voir plus loin).
Lors de la connexion sur le Web Client vSphere, ça se complique un peu. En effet, le plug-in s’est correctement installé et on voyait bien la hiérarchie “Networking & Security”, mais impossible de “voir” le NSX Manager ajouté précédemment, toutes les sections étaient vierges et nous affichaient un message “No NSX Managers available. Verify current user has role assigned on NSX Manager”.
Après pas mal de tests divers sans trop de succès, il semble qu’en reconnectant le lookup service avec le FQDN du vCenter plutôt que son IP ainsi qu’utiliser l’administrateur local du SSO (administrato@vsphere.local), ce soit passé. Le problème reste très nébuleux et sa résolution aussi d’ailleurs. VMWare indique sur son site qu’il faut effectivement reconnecter le Lookup service et la partie vCenter (voir ce KB). En googlant un peu, nous sommes d’ailleurs tombés sur des cas similaires, sans être tout à fait équivalents. Si jamais cela vous arrive lors d’une prochaine installation, pas de panique, au pire, appelez la hotline VMWare qui pourra sans doute vous aider ;)
D’autre part, nous n’avons pas pu non plus intégrer un certificat officiel issu de notre PKI interne, malgré tous nos efforts. Celui-ci n’est pas reconnu, quels que soient nos tests : le format .pem que nous avons tenté d’injecter (que ce soit le certificat lui-même ou l’ensemble des certificats de notre hiérarchie) a toujours refusé d’être pris en compte, avec un message sibyllin “Invalid certificate chain”. Nous avons évidemment tenté divers permutation dans l’ordre des certificats présentés dans le ficier pem en question… sans succès. En désespoir de cause, nous sommes resté sur l’auto-signé, en attendant mieux.
En définitive, cela nous a permis de découvrir aussi plus en détail l’intégration vSphere/NSX et en particulier de constater que les droits d’accès spécifiques à NSX ne se trouvent pas au niveau de la gestion des users et group coté vCenter, mais dans une section dédiée au sein de l’interface de gestion NSX elle-même. Bon à savoir !
Une fois ce problème résolu, le reste est strictement conforme à la documentation : déploiement des contrôleurs, préparation des serveurs ESXi (au passage, pas besoin de reboot des machines, bonne nouvelle !) et configuration VXLAN. Etant équipés de cœurs de réseau Nexus 5500, nous ne pouvons pas utiliser les VXLAN en mode Unicast (A cause de l’absence de support VTEP… Merci Cisco !!!!) mais seulement en mode multicast. Dont acte, nous avons mis en place ce mode de communication pour les flux inter-hyperviseurs.
Nous allons attaquer les premiers tests internes ainsi que l’intégration OSPF avec nos cœurs de réseau physiques actuels. Cette phase va durer une bonne semaine, normalement. A partir de la deuxième quinzaine de Janvier, on rentrera dans le vif du sujet avec la mise en place de Deep Security sur cette infrastructure toute neuve. A suivre !
Pour terminer ce billet, je vous conseille fortement d’aller lire (à tête reposé, les articles sont denses !) l’excellent blog “Network Inferno” qui présente, notamment, un grand nombre de billets au sujet de NSX, sa philosophie, son architecture et ses possibilités, ainsi que son déploiement progressif. Extrêmement instructif et riche d’enseignements : https://networkinferno.net/nsx-compendium