Architecture de références NSX-T
Dans le cadre du triptyque d’articles sur NSX-T, voici les architectures de référence glanées lors de l’EMPOWER à Lisbonne.
Installez-vous confortablement car il y a beaucoup d’informations sur les choix d’implémentation.
Les bases
Avant d’entrer dans le vif du sujet, je vous propose un petit glossaire des acronymes qui seront utilisés par la suite :
- LB : Load Balancer
- DR : Distributed Router
- BM : Bare Metal
- TOR : Top of Rack (Switch réseau en tête de rack)
Commençons par la VIP pour le cluster de managers NSX-T. Trois configurations possibles :
- Pas de VIP
- VIP gérée par le cluster de management (recommandé)
- VIP gérée par un Load Balancer externe (qui peut être porté par NSX-T
On retrouve ensuite un grand classique dans les architectures virtuelles : la répartition des flux sur plusieurs VSS / VDS / N-VDS en fonction du nombre d’interfaces réseau physiques disponibles par serveur.
Comme souvent, il est préférable de séparer les flux des VM des flux techniques vSphere (administration, stockage, vMotion).
Lorsque cela n’est pas possible ou difficile (ex : configurations à deux interfaces réseau), il faudra garder à l’esprit que les performances pourront être fortement dégradées en cas de congestion.
Rien à déclarer ? Edge NSX, le douanier
En route vers le monde merveilleux des Edge NSX, gardiens des frontières entre le virtuel et le physique ainsi que les différents Tenants.
Vous allez découvrir quelques éléments concernant leur configuration, placement et dimensionnement.
Edge Node en VM
Voici un exemple de configuration de deux VM Edge sur le même ESXi avec répartition des flux pour tirer le meilleur parti de chaque lien physique.
Il est recommandé de commencer avec des VM puis implémenter des Edges physiques si besoin de capacités et performances plus importantes.
Pour l’implémentation des Edges Tier-0 en active/standby, il faut s’assurer que chaque uplink est connecté à un TOR via un VLAN différent.
La convergence BGP peut être inférieure à la seconde avec un paramétrage de BFD sur BM.
Edge Node physique
Ci-dessous, deux propositions d’implémentation de Edge Bare Metal avec 2 puis 4 interfaces réseau.
Vous constaterez que nombre de propositions contiennent deux TEP-IP par nœud. Ceci permet de tirer parti de la bande passante de chaque interface sans configuration supplémentaire des LAG côté TOR (LACP ou Etherchannel) mais cela entraîne une surconsommation d’IP. A vous de voir ce qui est le plus pertinent dans votre cas.
Cluster de Edges
Pour la construction des clusters Edge, deux propositions sont présentées.
Première proposition d’implémentation de clusters Edge avec séparation des Tiers 0 et 1, un cluster (de Edge) par type de tiers.
Deuxième proposition d’implémentation de clusters Edge avec mutualisation des Tiers 0 et 1 sur chaque nœud Edge.
De base, on déploiera 4 nœuds Edge dans un cluster avec anti-affinité ESX afin d’héberger les Tiers 0 et 1 ainsi que leurs services de façon résiliente. L’extensibilité se fera par l’ajout de nouveaux nœuds ou le passage à des nœuds BM.
En synthèse, comment choisir votre implémentation Edge.
Voici quelques critères de choix pour l’implémentation des nœuds Edge.
J’ai un service à te demander…
Besoin de Firewall, Load Balancer ou faire du NAT ? NSX-T répond à vos besoins !
Le Firewall
Explication des différences d’usage entre Edge Firewall Tiers-0 et Tiers-1.
- Sur le Tier-0, il servira à la protection périmétrique et l’interconnexion avec le monde physique.
- Sur le Tier-1, il servira à la séparation inter-tenants.
Implémentation des Load Balancers par Tenant.
Sans surprise, les LB sont rattachés aux Tiers-1.
En fonction des performances attendues, la fonctionnalité Load Balancer peut être un élément décisif dans le choix du type de Edge (VM ou BM).
Le NAT
Explication des différences de placement des services NAT et évocation du « Reflexive NAT ».
Le Reflexive NAT est un mode qui permet d’avoir une communication asymétrique lorsque le flux transite par un cluster de routeurs de type actif/actif. Les paquets peuvent sortir par un nœud du cluster et revenir par l’autre.
Dernière ligne droite avec 3 exemples d’implémentation NSX-T
Courage, cet article consacré aux éléments d’architecture NSX-T touche à sa fin avec les trois exemples d’implémentation qui suivent.
Voici une implémentation hybride où tous les éléments vSphere et NSX-T cohabitent sur le même cluster (vSphere).
Exemple de cohabitation NSX-V et NSX-T, intéressant en phase de transition afin de limiter l’expansion matérielle.
Proposition d’implémentation avec PKS.
Une aspirine et du repos avant la migration et le DRP !
Si vous avez mal aux cheveux, c’est bon signe, vous avez été attentifs !
J’espère que ces quelques exemples vous permettront de mûrir vos réflexions sur votre future architecture NSX-T.
On se retrouve bientôt pour parler migration NSX-V vers NSX-T et plan de Disaster Recovery.
