Laboratoires d’essai en ligne VMware - HOL-1903-01-NET


Présentation du laboratoire en ligne - HOL-1903-01-NET - Démarrer avec VMware NSX Data Center

Instructions concernant le déroulement du laboratoire


Remarque : il vous faudra peut-être plus de 90 minutes pour suivre ce laboratoire. Durant cette session, vous pourrez terminer un maximum de 2 ou 3 modules. Les modules sont indépendants. Vous pouvez donc commencer au début du module de votre choix, puis enchaîner les modules dans l’ordre qui vous convient. Utilisez le sommaire pour accéder au module choisi.

Le sommaire est disponible dans l’angle supérieur droit du manuel du laboratoire.

NSX Data Center pour vSphere est la plate-forme VMware de virtualisation de réseau destinée au Software-Defined Data Center (SDDC) qui fournit l’intégralité des fonctions réseau et de sécurité sous forme logicielle et qui est isolée de l’infrastructure physique sous-jacente.

Ce laboratoire vous présente les fonctionnalités clés de VMware NSX Data Center dans un environnement vSphere. Il vous offre une expérience pratique des services de commutation logique, de routage logique distribué, de routage dynamique et de réseau logique.

Liste des modules du laboratoire :

Responsables du laboratoire :

Vous pouvez télécharger ce manuel de laboratoire sur le site des documents du laboratoire d’essai en ligne, ici :

http://docs.hol.vmware.com

Ce laboratoire peut être disponible dans d’autres langues. Le document suivant vous aidera à définir vos préférences linguistiques et à déployer un manuel localisé pour votre laboratoire :

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Emplacement de la console principale

 

  1. La zone délimitée par un cadre ROUGE correspond à la console principale. Le manuel de laboratoire apparaît dans le volet affiché sur la droite de la console principale.
  2. Des consoles supplémentaires peuvent être utilisées pour certains laboratoires. Elles s’affichent alors dans des onglets distincts en haut à gauche. Vous pourrez, au besoin, être invité à ouvrir une console supplémentaire spécifique.
  3. Au début de votre laboratoire, le minuteur est réglé sur 90 minutes. Vous ne pouvez pas sauvegarder le laboratoire. Toutes les tâches doivent être effectuées durant la session de laboratoire.  Vous avez toutefois la possibilité de cliquer sur EXTEND pour obtenir un délai supplémentaire. Si vous effectuez ce laboratoire dans le cadre d’un événement VMware, vous avez droit à deux prolongations, pour un délai supplémentaire total de 30 minutes. Chaque clic vous donne droit à 15 minutes supplémentaires. En dehors des événements VMware, vous pouvez prolonger la durée du laboratoire jusqu’à 9 heures et 30 minutes. Chaque clic vous donne droit à une heure supplémentaire.

 

 

Méthodes alternatives à la saisie de données au clavier

Au cours de ce module, vous serez invité à saisir du texte dans la console principale. Outre la saisie directe au clavier, vous disposez de deux méthodes très utiles facilitant la saisie des données complexes.

 

 

Cliquer sur une partie du texte du manuel de laboratoire, puis le faire glisser dans la fenêtre active de la console

 
 

Vous pouvez également cliquer sur du texte et des commandes CLI (Command Line Interface) directement à partir du manuel du laboratoire, pour les faire glisser dans la fenêtre active de la console principale.  

 

 

Accès au clavier international en ligne

 

Vous pouvez également utiliser le clavier international en ligne proposé dans la console principale.

  1. Cliquez sur l’icône en forme de clavier dans la barre d’outils Lancement rapide de Windows.

 

 

Cliquer une fois sur la fenêtre active de la console

 

Cet exemple vous montre comment utiliser le clavier en ligne pour saisir le signe « @ » utilisé dans les adresses e-mail. Sur un clavier américain, le signe « @ » correspond à la combinaison Maj-2.

  1. Cliquez une fois dans la fenêtre de console active.
  2. Cliquez sur la touche Maj.

 

 

Cliquer sur la touche « @ »

 

  1. Cliquez sur la touche « @ ».

Vous remarquez que le signe « @ » a été saisi dans la fenêtre active de la console.

 

 

Invite ou filigrane d’activation

 

Au moment de démarrer le laboratoire, vous remarquerez peut-être sur le bureau un filigrane indiquant que Windows n’est pas activé.  

L’un des principaux avantages de la virtualisation réside dans la possibilité de transférer et d’exécuter une machine virtuelle sur n’importe quelle plate-forme. Les laboratoires d’essai en ligne tirent parti de cette capacité, qui nous permet de les exécuter depuis différents Data Centers. Cependant, ces Data Centers ne sont pas tous dotés des mêmes processeurs, ce qui a pour effet de déclencher un contrôle d’activation Microsoft via Internet.

Rassurez-vous, VMware et ses laboratoires d’essai en ligne sont en parfaite conformité avec les conditions de licence de Microsoft. Le laboratoire que vous suivez est un pod autonome ne disposant pas du plein accès à Internet dont Windows a besoin pour vérifier l’activation. L’absence d’un accès complet à Internet provoque l’échec de ce processus automatisé, d’où l’apparition du filigrane.

Ce problème superficiel est sans incidence sur votre laboratoire.  

 

 

Observer la partie inférieure droite de l’écran

 

Vérifiez que toutes les routines de démarrage ont été exécutées et que le laboratoire est prêt à démarrer. Si l’état affiché est différent de « Ready », patientez pendant quelques minutes.  Si le laboratoire n’est toujours pas à l’état « Ready » au bout de 5 minutes, demandez de l’aide.

 

 

Autoriser vmware-cip-launcher.exe

 

Il peut arriver que le laboratoire soit provisionné avec les paramètres par défaut de Chrome. Dans ce cas, une boîte de dialogue de confirmation telle qu’illustrée ci-dessus peut s’afficher. Pour permettre au lanceur de s’exécuter avec vSphere Web Client (Flash), procédez comme suit :

  1. Cliquez pour sélectionner Always open these types of links in the associated app.
  2. Cliquez pour sélectionner Open vmware-cip-launcher.exe.

Vous pouvez ensuite continuer le laboratoire normalement.

 

 

Réduire les tâches récentes et les objets récents dans vSphere Web Client

 

En raison de la résolution d’écran utilisée pour les laboratoires d’essai en ligne, l’affichage de certains composants de l’interface utilisateur NSX peut être limité ou incomplet dans le cadre de ce laboratoire. Afin de maximiser l’espace utilisable à l’écran, il est conseillé de minimiser les panneaux Recent Objects et Recent Tasks sur le vSphere Web Client (Flash). Pour ce faire, procédez comme suit :

  1. Cliquez sur l’icône en forme d’épingle dans le coin supérieur droit du panneau Recent Objects.
  2. Cliquez sur l’icône en forme d’épingle dans le coin supérieur droit du panneau Recent Tasks.

 

Module 1 - Installation et configuration de NSX Manager (15 minutes)

Introduction


VMware NSX Data Center est la plate-forme de virtualisation du réseau leader du marché qui déploie le modèle opérationnel des machines virtuelles sur le réseau. Tout comme la virtualisation des serveurs permet un contrôle flexible des machines virtuelles s’exécutant dans un pool de serveurs physiques, la virtualisation de réseau NSX Data Center fournit une API centralisée pour le provisionnement et la configuration de services de réseau virtuel isolés au sein d’un seul réseau physique.

Les réseaux logiques dissocient la connectivité et les services réseau des machines virtuelles du réseau physique. Les clients peuvent ainsi placer ou migrer des machines virtuelles n’importe où au sein du Data Center, tout en bénéficiant d’une connectivité de couche 2/3 et de services réseau de couches 4 à 7.

Dans ce module, nous utiliserons une simulation interactive afin de voir comment déployer NSX Data Center. Nous avons déjà procédé au déploiement au sein de l’environnement de laboratoire.

Au cours de la simulation interactive, vous découvrirez comment :


 

Composants de NSX

 

Notez que, même si la plate-forme de gestion du Cloud (CMP) n’est pas un composant de NSX, NSX assure l’intégration de pratiquement toutes les plates-formes CMP via l’API REST et une intégration prête à l’emploi avec les CMP VMware.

Les principaux composants de NSX sont répartis dans trois catégories :

Plan de gestion : le plan de gestion NSX est développé par NSX Manager, le composant de gestion du réseau centralisée de NSX. Il fournit un point de configuration unique et des points d’entrée pour les API REST.

Plan de contrôle : le plan de contrôle NSX s’exécute dans le cluster NSX Controller. NSX Controller est un système de gestion d’état distribué qui offre des fonctions de plan de contrôle pour les fonctions de commutation et de routage logiques NSX. Il constitue le point de contrôle central de tous les commutateurs logiques d’un réseau et gère les informations relatives à l’ensemble des hôtes, des commutateurs logiques (VXLAN) et des routeurs logiques distribués.

Plan de données : le plan de données NSX se compose du vSwitch NSX, qui repose sur le commutateur vSphere Distributed Switch (VDS), auquel s’ajoutent des composants destinés à la prise en charge des services. Les modules de noyau NSX, les agents d’espace utilisateur, les fichiers de configuration et les scripts d’installation sont inclus dans des VIB et exécutés dans le noyau de l’hyperviseur pour fournir des services tels que des pare-feu logiques et le routage distribué, et autorisent les capacités de pontage VXLAN.

 

Simulation interactive du laboratoire d’essai en ligne : Installation et configuration de NSX - Partie 1


Cette partie du laboratoire d’essai en ligne se présente sous forme de simulation interactive. Elle vous permet d’expérimenter des procédures dont l’exécution au sein de l’environnement de laboratoire en ligne demanderait trop de temps et de ressources. Dans cette simulation, vous pouvez utiliser l’interface logicielle comme si vous interagissiez avec un environnement en ligne.

*** REMARQUE ***    La simulation que vous allez effectuer se compose de deux parties. La première partie prend fin une fois que la configuration de NSX Manager est terminée. Pour continuer avec la seconde partie de la simulation, cliquez sur « Return to the lab » dans le coin supérieur droit de la fenêtre. Le manuel présente également les étapes à la fin de la configuration de NSX Manager.

  1. Cliquez ici pour ouvrir la simulation interactive. Une nouvelle fenêtre ou un nouvel onglet de navigateur s’affiche.
  2. Lorsque vous avez terminé, cliquez sur le lien « Return to the lab » pour revenir au laboratoire.

 


Simulation interactive du laboratoire d’essai en ligne : Installation et configuration de NSX - Partie 2


Cette partie du laboratoire d’essai en ligne se présente sous forme de simulation interactive. Elle vous permet d’expérimenter des procédures dont l’exécution au sein de l’environnement de laboratoire en ligne demanderait trop de temps et de ressources. Dans cette simulation, vous pouvez utiliser l’interface logicielle comme si vous interagissiez avec un environnement en ligne.

  1. Cliquez ici pour ouvrir la simulation interactive. Une nouvelle fenêtre ou un nouvel onglet de navigateur s’affiche.
  2. Lorsque vous avez terminé, cliquez sur le lien « Return to the lab » pour revenir au laboratoire.

 


Conclusion du module 1


Dans ce module, nous avons constaté à quel point il était facile d’installer et de configurer NSX afin de déployer des services des couches 2 à 7 sous forme logicielle.

Nous avons couvert l’installation et la configuration de l’appliance NSX Manager, notamment le déploiement, l’intégration avec vCenter, de même que la configuration de la journalisation et des sauvegardes. Nous avons ensuite abordé le déploiement d’instances NSX Controller et l’installation des packages VMware Infrastructure Bundles (VIB) qui sont des modules de noyau chargés dans l’hyperviseur afin de fournir les services NSX. Enfin, nous avons vu le déploiement automatisé de points limites de tunnel VXLAN (VTEP), ainsi que la création d’un pool d’identifiants de réseau VXLAN (VNI) et d’une zone de transport.


 

Vous avez terminé le module 1

Félicitations ! Vous avez terminé le module 1.

Si vous souhaitez en savoir plus sur le déploiement de NSX, rendez-vous dans le Centre de documentation NSX 6.4 via l’URL suivante :

Passez à n’importe lequel des modules suivants :

Liste des modules du laboratoire :

Responsables du laboratoire :

  • Modules 1 à 4 : Joe Collon, ingénieur système NSX, États-Unis

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 2 - Commutation logique (30 minutes)

Commutation logique - Présentation du module


Dans ce module, nous allons examiner les aspects suivants de VMware NSX :

  • Cluster NSX Controller. Grâce au cluster NSX Controller, la prise en charge du protocole de multidiffusion dans le fabric physique n’est plus requise. Ce composant offre en outre des fonctions telles que VTEP et la résolution d’adresses IP/MAC.
  • Création d’un commutateur logique et rattachement de deux VM à ce commutateur logique.
  • Évolutivité et haute disponibilité de la plate-forme NSX.

Commutation logique


Dans cette section, nous effectuerons les opérations suivantes :

  1. Vérifier la configuration des hôtes.
  2. Vérifier l’état de préparation du réseau logique.
  3. Créer un nouveau commutateur logique.
  4. Rattacher le commutateur logique à la passerelle de services NSX Edge.
  5. Ajouter des VM au commutateur logique.
  6. Tester la connectivité entre les VM.

 

Accéder à vSphere Web Client (Flash)

 

  1. Ouvrez vSphere Web Client (Flash) à l’aide de l’icône Google Chrome située sur le bureau.

 

 

Connexion à vSphere Web Client (Flash)

 

Si vous n’êtes pas déjà connecté à vSphere Web Client :

(Normalement, la page d’accueil est celle de vSphere Web Client.  Si ce n’est pas le cas, cliquez sur l’icône vSphere Web (Flash) dans Google Chrome.)

  1. Dans le champ User name, saisissez administrator@vsphere.local.
  2. Dans le champ Password, saisissez VMware1!.
  3. Cliquez sur Login.

 

 

Accéder à la section « Networking & Security » de vSphere Web Client

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Afficher les composants déployés

 

  1. Cliquez sur Installation and Upgrade.
  2. Cliquez sur Host Preparation.
  3. Cliquez pour sélectionner un cluster dans la liste (RegionA01-COMP01 dans cet exemple) et afficher des informations sur l’état de NSX pour les hôtes de ce cluster.

Vous constaterez que les composants de virtualisation de réseau, également appelés « composants du plan de données », sont installés sur les hôtes des clusters. Ces composants comprennent des modules de noyau au niveau de l’hyperviseur pour la sécurité des ports, ainsi que des modules VXLAN, de pare-feu distribué et de routage distribué.

Les fonctions de pare-feu et VXLAN sont configurées et activées sur chaque cluster après l’installation des composants de virtualisation de réseau. Le module de sécurité des ports permet le fonctionnement du VXLAN, et le module de routage distribué est activé une fois la VM de contrôle du routeur logique NSX Edge configurée.

 

 

Topologie après la préparation de l’hôte avec les composants de chemin de données

 

 

 

Afficher la configuration des VTEP

 

  1. Dans la liste d’hôtes affichés, faites défiler la barre vers la droite jusqu’à laisser apparaître le lien VIEW DETAILS.
  2. Cliquez sur VIEW DETAILS pour afficher les informations relatives au port de noyau VTEP et à l’adresse IP de cet hôte.

La configuration du VXLAN se compose de trois étapes principales :

  • Configuration d’un point limite de tunnel VXLAN (VTEP) sur chaque hôte.
  • Configuration de la plage d’ID de segments pour créer un pool de réseaux logiques. Comme nous utilisons le mode Unicast (monodiffusion) dans ce laboratoire, il est inutile de définir une plage de multidiffusion. Autrement, cette étape pourrait nécessiter la configuration d’adresses de groupe de multidiffusion.
  • Configuration de la zone de transport pour définir l’étendue du réseau logique.

Comme illustré sur le diagramme, les hôtes ont été configurés avec des interfaces de point limite de tunnel VXLAN (VTEP). L’environnement utilise le sous-réseau 192.168.130.0/24 pour le pool VTEP.

 

 

Configuration des ID de segments et des adresses de groupe de multidiffusion

Par le passé, l’un des principaux inconvénients des déploiements VXLAN était qu’ils imposaient la prise en charge du protocole de multidiffusion au niveau des périphériques réseau physiques. La plate-forme NSX résout ce problème avec une implémentation VXLAN basée sur des contrôleurs, qui évite la configuration de la multidiffusion sur le réseau physique. NSX propose trois options pour le trafic BUM (Broadcast, Unknown et Multicast) : multidiffusion, monodiffusion et hybride.  Le paramétrage est appliqué de manière globale dans le cadre de la zone de transport, mais il peut également être défini explicitement au niveau de chaque commutateur logique.

Les trois modes de réplication disponibles dans NSX sont les suivants :

  • Multicast : NSX s’appuie sur la capacité de multidiffusion native des couches 2 et 3 du réseau physique pour s’assurer que le trafic BUM VXLAN encapsulé est transmis à tous les VTEP. Dans ce mode, une adresse IP de multidiffusion doit être associée à chaque segment VXLAN de couche 2 défini (commutateur logique). Avec cette configuration, la fonction de multidiffusion de couche 2 est utilisée pour répliquer le trafic vers tous les VTEP du segment local (adresses IP de VTEP appartenant au même sous-réseau IP). La fonction IGMP Snooping doit par ailleurs être configurée sur les commutateurs physiques pour optimiser l’acheminement du trafic de multidiffusion de couche 2.
  • Monodiffusion : le plan de contrôle est géré par l’instance NSX Controller, qui exploite la réplication de tête de réseau. Aucune adresse IP de multidiffusion ni aucune configuration réseau particulière ne sont nécessaires avec cette méthode de réplication.
  • Hybride : mode monodiffusion optimisé.  Il délègue la réplication du trafic local au réseau physique (en utilisant la multidiffusion de couche 2). Dans ce mode, la fonction IGMP Snooping doit être activée sur le commutateur local, mais il n’est pas nécessaire d’utiliser un protocole de routage multidiffusion tel que PIM.  Le mode hybride est recommandé pour les déploiements NSX à grande échelle.

 

 

Afficher la configuration des ID de segments

 

  1. Cliquez sur Logical Network Settings.
  2. Notez le pool d’ID de segments affecté à l’environnement. Les commutateurs logiques étant créés dans NSX, le prochain ID de segment non utilisé est alloué et affecté à chaque nouveau commutateur logique.
  3. Notez que le champ Multicast addresses est vide. En effet, comme indiqué précédemment, le mode de l’environnement de laboratoire par défaut est Unicast (monodiffusion) et il n’y a donc pas de conditions de multidiffusion.

 

 

Afficher les zones de transport

 

  1. Cliquez sur Transport Zones.
  2. Cliquez sur le bouton radio pour sélectionner la zone de transport RegionA0_Global_TZ.

Maintenant que nous avons examiné les différents composants NSX et la configuration du VXLAN, nous allons créer un commutateur logique NSX. Le commutateur logique NSX définit un domaine de diffusion logique, ou un segment réseau, auquel une application ou une machine virtuelle de locataire peut se connecter de manière logique. Un commutateur logique NSX fournit un domaine de diffusion de couche 2, similaire à un VLAN, mais sans la configuration de réseau physique habituellement associée à un VLAN.

 

 

Afficher les commutateurs logiques

 

  1. Cliquez sur Logical Switches dans la partie gauche de la fenêtre.

Notez qu’un certain nombre de commutateurs logiques sont déjà définis dans ce laboratoire. Les informations ont été pré-remplies et aideront à exécuter les divers modules fournis par le laboratoire. Dans un nouveau déploiement NSX, la liste des commutateurs logiques serait vide.

La prochaine étape est la création d’un nouveau commutateur logique. Une fois que ce commutateur est créé, nous allons migrer les VM existantes vers le réseau qui vient d’être créé et assurer leur connectivité avec l’environnement NSX.

 

 

Créer un nouveau commutateur logique

 

  1. Cliquez sur le signe plus vert pour créer un nouveau commutateur logique.
  2. Attribuez le nom Prod_Logical_Switch au commutateur logique.
  3. Confirmez que la zone de transport sélectionnée est RegionA0_Global_TZ .
  4. Confirmez que le mode de réplication sélectionné est Unicast.
  5. Confirmez que la case Enable IP Discovery est cochée. La fonction de détection d’IP, décrite ci-après, active la suppression ARP.
  6. Cliquez sur OK.

La sélection de l’option Enable IP Discovery active la suppression ARP (Address Resolution Protocol). Le protocole ARP sert à déterminer l’adresse MAC (Media Access Control) de destination à partir d’une adresse IP via l’envoi d’une requête de diffusion générale (broadcast) sur un segment de couche 2. Si un hôte ESXi doté de ce commutateur NSX Virtual Switch reçoit le trafic ARP d’une VM (machine virtuelle) ou d’une requête Ethernet, il envoie la requête à l’instance NSX Controller qui possède une table ARP. Si l’instance NSX Controller détient l’information recherchée dans sa table ARP, elle la renvoie à l’hôte, qui répond à son tour à la VM.

 

 

Rattacher le nouveau commutateur logique à la passerelle de services NSX Edge pour l’accès externe

 

  1. Cliquez pour sélectionner le Prod_Logical_Switch que nous venons de créer.
  2. Cliquez sur le menu Actions.
  3. Cliquez sur Connect Edge.

 

 

Connecter le commutateur logique à NSX Edge

 

NSX Edge peut être installé en tant que routeur logique (distribué) ou passerelle de services Edge.

  • La passerelle de services Edge, « Perimeter-Gateway-01 », fournit des services réseau tels que DHCP, NAT, l’équilibrage de charge, le pare-feu et le VPN. Elle comprend également des fonctions de routage dynamique.
  • Le routeur logique distribué, « Distributed-Router-01 », prend en charge le routage distribué et dynamique.

Nous aborderons plus en détail NSX Edge et le routage dans les prochains modules.

Pour le moment, nous allons connecter le commutateur logique à la passerelle de services NSX Edge, « Perimeter-Gateway-01 ». Cette opération assurera la connexion entre les VM reliées au commutateur logique et le reste de l’environnement.

  1. Cliquez sur le bouton radio à gauche de la passerelle Perimeter-Gateway-01 pour la sélectionner.
  2. Cliquez sur Next.

 

 

Rattacher le commutateur logique à NSX Edge

 

  1. Cliquez sur le bouton radio à gauche de vnic7 pour le sélectionner.
  2. Cliquez sur Next.

 

 

Attribuer un nom à l’interface

 

  1. EntrezProd_Interface dans. le champ Nom.
  2. Sélectionnez Connected.
  3. Cliquez sur le signe plus vert pour configurer l’adresse IP et les informations de sous-réseau propres à cette interface.

 

 

Attribuer une adresse IP à l’interface

 

  1. Saisissez 172.16.40.1 dans le champ Primary IP Address ne fournissez aucune adresse IP secondaire).
  2. Dans le champ Subnet Prefix Length, saisissez 24.
  3. Vérifiez que les paramètres sont corrects, puis cliquez sur Next.

 

 

Terminer la procédure d’édition de l’interface

 

  1. Cliquez sur Finish.

 

 

Rattacher web-03a et web-04a au nouveau commutateur Prod_Logical_Switch

 

  1. Cliquez pour sélectionner le Prod_Logical_Switch que nous venons de créer.
  2. Cliquez sur le menu Actions.
  3. Cliquez sur Add VM.

 

 

Ajouter les machines virtuelles au commutateur logique

 

  1. Recherchez les VM dont le nom contient le terme « web ».
  2. Sélectionnez web-03a.corp.local et web-04a.corp.local.
  3. Cliquez sur la flèche vers la droite pour ajouter les VM sélectionnées au commutateur logique.
  4. Cliquez sur Next.

 

 

Sélectionner la carte réseau virtuelle (vNIC) des machines virtuelles pour l’ajouter au commutateur logique

 

  1. Sélectionnez les vNIC des deux VM web.
  2. Cliquez sur Next.

 

 

Terminer l’ajout des VM au commutateur logique

 

  1. Cliquez sur Finish.

 

 

Topologie après la connexion de Prod_Logical_Switch à la passerelle de services NSX Edge

 

Vous avez configuré un nouveau commutateur logique et établi la connexion au réseau externe via la passerelle Edge GatewayPerimeter-Gateway-01. Vous avez également ajouté deux machines virtuelles au nouveau commutateur logique.

 

 

Tester la connectivité entre web-03a et web-04a

Nous allons maintenant tester la connectivité entre web-03a et web-04a.

 

 

Accéder à « Hosts and Clusters »

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Hosts and Clusters.

 

 

Développer les clusters

 

Développez les clusters RegionA01-COMP01 et RegionA01-COMP02. Les deux VM web-03a.corp.local et web-04a.corp.local devraient apparaître dans des clusters de calcul distincts. Notez que ces deux VM ont été ajoutées au commutateur logique lors des étapes précédentes.

 

 

Ouvrir PuTTY

 

  1. Cliquez sur le bouton Démarrer de Windows.
  2. Cliquez sur l’icône de l’application PuTTY dans le menu Démarrer.

Vous devez vous connecter à partir de la console principale située dans le sous-réseau 192.168.110.0/24. Le trafic transitera par le NSX Edge Perimeter-Gateway-01 avant d’être transmis au serveur Web.

 

 

Ouvrir une session SSH vers l’hôte web-03a

 

  1. Faites défiler la liste Saved Sessions jusqu’à faire apparaître web-03a.corp.local.
  2. Cliquez sur web-03a.corp.local pour le sélectionner.
  3. Cliquez sur Load pour récupérer les informations de la session.
  4. Cliquez sur Open pour démarrer une session PuTTY sur la VM.

 

 

Se connecter à la VM

 

  • Si vous recevez une alerte de sécurité PuTTY, cliquez sur Yes pour accepter la clé hôte du serveur.
  • Si vous n’êtes pas automatiquement connecté, connectez-vous en tant qu’utilisateur root avec le mot de passe VMware1!.

Remarque : si vous avez des difficultés à vous connecter à web-03a.corp.local, vérifiez que vous avez correctement suivi les étapes précédentes.

 

 

Envoyer des requêtes ping au serveur web-04a.corp.local

 

Saisissez ping -c 2 web-04a pour envoyer deux requêtes ping plutôt qu’un ping en continu.

ping -c 2 web-04a

Remarque : l’adresse IP de web-04a.corp.local est 172.16.40.12. Au besoin, vous pouvez également lancer des requêtes ping par adresse IP.

La présence éventuelle de paquets DUP! est due à la nature de l’environnement de laboratoire VMware imbriqué. Ce problème ne se produira pas en environnement de production.

Ne fermez pas la session PuTTY. Réduisez la fenêtre en vue d’une utilisation ultérieure.

 

Évolutivité et disponibilité


Dans cette section, nous allons nous pencher sur l’évolutivité et la disponibilité des nœuds NSX Controller. Le cluster NSX Controller est le composant du plan de contrôle qui est chargé de gérer les modules de commutation et de routage sur les hyperviseurs. Il se compose de trois nœuds NSX Controller qui gèrent chacun des objets logiques spécifiques. La gestion des commutateurs logiques VXLAN à l’aide d’un cluster NSX Controller rend inutile la prise en charge de la multidiffusion par l’infrastructure réseau physique.

Pour des raisons de résilience et de performances, les déploiements en production doivent utiliser un cluster NSX Controller comprenant trois nœuds NSX Controller. Le cluster NSX Controller est un système distribué à évolutivité horizontale dans lequel un ensemble de rôles est attribué à chaque nœud NSX Controller. Le rôle assigné détermine les types de tâches exécutables par le nœud NSX Controller. La configuration prise en charge permet le partage de la charge entièrement actif ainsi que la redondance.

Pour renforcer l’évolutivité de l’architecture NSX, un mécanisme de « découpage » permet de s’assurer que tous les nœuds NSX Controller sont actifs en permanence.

La défaillance d’un ou de plusieurs nœuds NSX Controller est sans effet sur le trafic (des VM) du plan de données. Le trafic se poursuit puisque les informations du réseau logique ont déjà été transmises aux commutateurs logiques (le plan de données). En revanche, aucune opération d’édition (ajout/déplacement/modification) n’est possible sans le plan de contrôle (cluster NSX Controller).

En outre, NSX comprend désormais les fonctionnalités CDO (Controller Disconnected Operation). Le mode CDO crée un commutateur logique spécial que rejoignent tous les hôtes. Cela ajoute une couche supplémentaire de redondance à la connectivité du plan de données si les contrôleurs ne sont pas accessibles par les hôtes dans l’environnement NSX. Pour plus d’informations sur le mode CDO, utilisez le lien indiqué à la fin de ce module.


 

Évolutivité et disponibilité de NSX Controller

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

Conclusion du module 2


Dans ce module, nous avons examiné les avantages suivants de la plate-forme NSX :

  1. Agilité du réseau : elle concerne notamment la facilité de provisionnement et de configuration des routeurs logiques en vue de leur interfaçage avec des machines virtuelles et des réseaux externes.
  2. Évolutivité de l’architecture NSX : elle est due notamment à la zone de transport extensible à plusieurs clusters et à la capacité du cluster NSX Controller à fournir des services réseau sans avoir à reconfigurer le réseau physique.

 

Vous avez terminé le module 2

Félicitations ! Vous avez terminé le module 2.

Si vous souhaitez en savoir plus sur le déploiement de NSX, rendez-vous dans le Centre de documentation NSX 6.4 via l’URL suivante :

Pour obtenir plus d’informations sur le mode CDO (Controller Disconnected Operation) de NSX Controller, suivez le lien :

Passez à n’importe lequel des modules suivants :

Liste des modules du laboratoire :

Responsables du laboratoire :

  • Modules 1 à 4 : Joe Collon, ingénieur système NSX, États-Unis

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 3 - Routage logique (60 minutes)

Routage logique - Présentation du module


Dans le module précédent, nous avons vu à quel point il était facile de créer des commutateurs/réseaux logiques isolés en quelques clics seulement. Pour assurer la communication entre ces réseaux isolés de couche 2, la prise en charge du routage est essentielle. Dans la plate-forme NSX, le routeur logique distribué permet d’aiguiller intégralement le trafic entre les commutateurs logiques au sein de l’hyperviseur. En intégrant ce composant de routage logique, NSX peut reproduire des topologies de routage complexes dans l’espace logique. Par exemple, une application à trois niveaux sera connectée à trois commutateurs logiques, et le routeur logique distribué assurera le routage entre les niveaux.

Ce module vous aidera à comprendre certaines des fonctions de routage prises en charge par la plate-forme NSX et comment les exploiter lors du déploiement d’une application à trois niveaux.

Dans ce module, nous effectuerons les opérations suivantes :

  • Examiner le flux de trafic lorsque le routage est assuré par un routeur physique externe ou par la passerelle de services NSX Edge.
  • Configurer le routeur logique distribué et ses interfaces logiques (LIF) pour assurer le routage entre le niveau Web, le niveau applicatif et le niveau base de données de l’application à 3 niveaux.
  • Configurer les protocoles de routage dynamique sur le routeur logique distribué et la passerelle de services Edge, et voir comment contrôler l’annonce d’itinéraires internes au routeur externe en amont.
  • Faire évoluer et protéger la passerelle de services NSX Edge en utilisant les protocoles de routage et le routage ECMP (cheminement multiple à coût égal).

 

Instructions spéciales concernant les commandes CLI

 

Pour une grande partie des modules, vous devez saisir des commandes d’interface de ligne de commande (CLI).  Pour envoyer des commandes CLI au laboratoire, vous avez deux possibilités.

Premièrement, pour envoyer une commande CLI à la console du laboratoire :

  1. Mettez la commande CLI en surbrillance dans le manuel et appuyez sur Ctrl + C pour la copier dans le Presse-papiers.
  2. Cliquez sur l’élément de menu de la console SEND TEXT.
  3. Appuyez sur Ctrl + V pour coller le contenu du Presse-papiers dans la fenêtre.
  4. Cliquez sur le bouton SEND.

Deuxièmement, un fichier texte (README.txt) placé sur le Bureau de l’environnement vous permet de copier et coller facilement des commandes ou mots de passe complexes dans les utilitaires associés (CMD, Putty, console, etc). Certains caractères sont souvent absents des claviers à travers le monde.  Ce fichier texte est aussi fourni pour les dispositions de clavier qui ne présentent pas ces caractères.

Le fichier texte s’appelle README.txt et est accessible sur le Bureau.  

 

Routage dynamique et distribué


Un routeur logique distribué (DLR) est une appliance virtuelle qui comprend le plan de contrôle de routage et distribue le plan de données dans les modules de noyau à chaque hôte d’hyperviseur. Les fonctions du plan de contrôle du DLR utilisent le cluster NSX Controller pour envoyer des mises à jour de routage aux modules de noyau. Cela permet d’optimiser le routage est-ouest au sein de chaque hyperviseur local et évite ainsi de faire passer le trafic via un seul et même point du réseau.

Nous examinerons tout d’abord la configuration du routage distribué afin de voir les avantages du routage au niveau du noyau.


 

Examen de la topologie et du flux de paquets actuels

 

Le diagramme ci-dessus représente l’environnement du laboratoire. La VM d’application et la VM de base de données résident toutes deux sur le même hôte physique. Les flèches rouges désignent le flux de trafic entre les deux VM.

  1. La VM d’application envoie le trafic à l’hôte.
  2. Comme les VM d’application et de base de données ne sont pas hébergées dans le même sous-réseau, le trafic doit être transmis à un périphérique de couche 3. La passerelle de périmètre NSX Edge, située dans le cluster de gestion, remplit les fonctions d’une passerelle de couche 3. Le trafic est envoyé à l’hôte sur lequel est hébergée la passerelle de périmètre.
  3. Le trafic atteint la passerelle de périmètre.
  4. La passerelle de périmètre achemine le paquet et le renvoie à l’hôte du réseau de destination.
  5. Le trafic routé est renvoyé à l’hôte sur lequel est hébergée la VM de base de données.
  6. L’hôte livre le trafic à la VM de base de données.

À la fin de ce module, nous examinerons le diagramme de flux de trafic après la configuration du routage distribué. Il vous aidera à mieux comprendre l’impact positif du routage distribué sur le trafic réseau.

 

 

Accéder à vSphere Web Client (Flash)

 

  1. Ouvrez vSphere Web Client (Flash) à l’aide de l’icône Google Chrome située sur le Bureau.

 

 

Connexion à vSphere Web Client (Flash)

 

Si vous n’êtes pas déjà connecté à vSphere Web Client :

(Normalement, la page d’accueil est celle de vSphere Web Client.  Si ce n’est pas le cas, cliquez sur l’icône vSphere Web (Flash) dans Google Chrome.)

  1. Dans le champ User name, saisissez administrator@vsphere.local.
  2. Dans le champ Password, saisissez VMware1!.
  3. Cliquez sur Login.

 

 

Vérifier le fonctionnement de l’application à trois niveaux

 

  1. Ouvrez un nouvel onglet de navigateur.
  2. Cliquez sur le favori Customer DB App.

 

Avant de commencer la configuration de votre application pour le routage distribué, confirmons que l’application à trois niveaux fonctionne correctement. Les trois niveaux de l’application (Web, applicatif et base de données) sont hébergés sur des commutateurs logiques différents, avec une passerelle de services NSX Edge qui assure le routage entre ces niveaux.

  • Le serveur Web renverra une page avec les informations sur les clients qui sont stockées dans la base de données.

 

 

Supprimer les interfaces des niveaux applicatif et base de données de la passerelle de périmètre

 

Comme nous l’avons vu précédemment sur le diagramme de la topologie, les trois niveaux de l’application sont hébergés sur les commutateurs logiques spécifiques à chaque niveau qui sont acheminés par la passerelle de périmètre (NSX ESG). Nous allons mettre à jour cette topologie en supprimant les interfaces des niveaux applicatif et base de données de la passerelle de périmètre. Une fois ces interfaces supprimées, nous les migrerons vers le routeur distribué (NSX DLR). Pour gagner du temps, un routeur distribué a déjà été déployé.

  1. Cliquez sur l’onglet de navigateur vSphere Web Client.
  2. Cliquez sur l’icône Home.
  3. Cliquez sur Networking & Security.

 

 

Ajouter les interfaces des niveaux applicatif et base de données au routeur distribué

 

Nous allons commencer par configurer le routage distribué en ajoutant les interfaces des niveaux applicatif et base de données au routeur distribué (NSX Edge).

  1. Double-cliquez sur Distributed-Router-01.

 

 

Configurer le routage dynamique sur le routeur distribué

 

Retournez dans l’onglet de navigateur vSphere Web Client.

  1. Cliquez sur Routing.
  2. Cliquez sur Global Configuration.
  3. Pour modifier la configuration du routage dynamique, cliquez sur Edit en regard de Dynamic Routing Configuration.

 

 

Modifier la configuration du routage dynamique

 

  1. Dans le champ « Router ID », sélectionnez l’adresse IP de l’interface de liaison montante en tant qu’ID de routeur par défaut. Dans ce cas, l’interface de liaison montante est Transit_Network_01, et l’adresse IP 192.168.5.2.
  2. Cliquez sur OK.

Remarque : le paramètre « Router ID » (ID de routeur) est un identifiant de 32 bits se présentant sous forme d’adresse IP. Il s’agit d’un élément important pour le protocole OSPF, car il identifie chaque routeur de manière unique au sein d’un système autonome. Dans notre scénario de laboratoire, l’ID de routeur utilisé est identique à l’adresse IP de l’interface de liaison montante sur le dispositif NSX Edge. Vous revenez ensuite à la section Global Configuration de l’écran, qui contient à présent l’option Publish Changes.

Confirmez que le champ Router ID contient l’adresse IP associée au commutateur logique Transit_Network : 192.168.5.2. Si la modification de configuration n’a pas été appliquée correctement, ce champ reste vide. Dans ce cas, répétez les étapes 1 et 2 ci-dessus pour appliquer de nouveau l’ID de routeur.

 

 

Configurer les paramètres du protocole OSPF

 

Nous utiliserons OSPF en tant que protocole de routage dynamique entre la passerelle de périmètre Perimeter-Gateway-01 et le routeur distribué Distributed-Router-01. Les deux routeurs échangeront ainsi des informations relatives aux routes connues.

  1. Cliquez sur OSPF.
  2. Pour modifier la configuration du protocole OSPF, cliquez sur Edit en regard de « OSPF Configuration ». La boîte de dialogue OSPF Configuration s’ouvre.

 

 

Configurer le routage OSPF sur la passerelle de périmètre

 

Nous allons à présent configurer le routage dynamique sur la passerelle de périmètre Perimeter-Gateway-01 (NSX Edge) pour rétablir la connexion à notre application à trois niveaux.

  1. Cliquez plusieurs fois sur Back pour revenir à la page récapitulative NSX Edges contenant la liste des dispositifs Edge.

 

 

Examen de la nouvelle topologie

 

La nouvelle topologie illustre l’appairage d’itinéraires entre le routeur distribué et la passerelle de périmètre (NSX Edge). Les itinéraires vers n’importe quel réseau connecté au routeur distribué sont transmis à la passerelle de périmètre (NSX Edge) via OSPF. Par ailleurs, nous distribuons également l’ensemble des routes issues de la passerelle de périmètre au routeur vPod du réseau physique via BGP.

Nous y reviendrons plus en détail dans la section suivante.

 

 

Vérifier la communication avec l’application à trois niveaux

 

Les informations de routage sont maintenant échangées entre le routeur distribué et la passerelle de périmètre. Une fois le routage entre les deux dispositifs NSX Edge établi, la connexion à l’application Web à trois niveaux est rétablie. Vérifions que le routage est fonctionnel en accédant à l’application Web à trois niveaux.

  1. Cliquez sur l’onglet de navigateur HOL - Customer Database (cet onglet s’est ouvert lors d’une étape précédente). Il se peut que la page affiche un message 504 Gateway Time-out résultant d’une tentative précédente.
  2. Cliquez sur Reload.

Remarque : comme le laboratoire est un environnement imbriqué, la propagation d’itinéraires peut prendre un moment.

 

 

Configuration du routage dynamique et distribué terminée

Dans cette section, nous avons configuré le routage dynamique et distribué. Dans la section suivante, nous examinerons le routage centralisé avec la passerelle de périmètre (NSX Edge).

 

Routage centralisé


Dans cette section, nous allons nous pencher sur différents éléments pour voir comment le routage est configuré vers le nord à partir de la passerelle de services NSX Edge (ESG). Nous verrons notamment comment le routage dynamique est contrôlé, mis à jour et propagé dans tout l’environnement NSX. Nous vérifierons que les routes sont échangées entre l’appliance ESG du périmètre NSX et l’appliance du routeur virtuel (vPod Router) qui exécute et route l’ensemble du laboratoire.

Remarque : sur le Bureau, vous trouverez un fichier nommé README.txt. Il contient les commandes CLI requises dans le cadre des exercices du laboratoire. Si vous ne pouvez pas taper ces commandes, vous pouvez les copier-coller dans les sessions PuTTY. Si vous voyez un nombre « entre accolades - {1} », cela vous indique de rechercher cette commande d’interface de ligne de commande pour ce module dans le fichier de texte.


 

Topologie actuelle du laboratoire

 

Le diagramme ci-dessus illustre la topologie actuelle, où le protocole OSPF est utilisé pour échanger les itinéraires entre la passerelle de périmètre et le routeur distribué. Il montre également la liaison vers le nord allant de la passerelle de périmètre au routeur vPod. Ces routeurs échangent des informations de routage via BGP.

 

 

Examen du routage OSPF sur la passerelle de périmètre

Nous commencerons par vérifier que l’application Web est fonctionnelle, puis nous nous connecterons à la passerelle de périmètre NSX pour afficher les voisins OSPF et voir les informations d’itinéraire de routage existantes. Nous verrons ainsi que la passerelle de périmètre apprend les itinéraires non seulement auprès du routeur distribué, mais également auprès du routeur vPod qui exécute également l’ensemble du laboratoire.

 

 

Vérifier le fonctionnement de l’application à trois niveaux

 

  1. Ouvrez un nouvel onglet de navigateur.
  2. Cliquez sur le favori Customer DB App.

 

 

Afficher les voisins BGP

 

Examinons les voisins BGP de la passerelle de périmètre Perimeter-Gateway-01.

  1. Saisissez show ip bgp neighbors.
show ip bgp neighbors

 

 

Examen des informations affichées concernant les voisins BGP

 

Examinons les informations sur les voisins BGP.

  1. BGP neighbor is 192.168.100.1 : ID routeur du routeur vPod à l’intérieur de l’environnement NSX.
  2. Remote AS 65002 : numéro de système autonome du réseau externe du routeur vPod.
  3. BGP state = Established, up  : cela signifie que l’établissement des relations de voisinage BGP est terminé et que les routeurs BGP enverront des paquets de mise à jour pour échanger les informations de routage.

 

 

Examen des itinéraires et de leur origine sur la passerelle de périmètre

 

Observez les itinéraires disponibles sur la passerelle de périmètre Perimeter-Gateway-01.

  1. Saisissez show ip route.
show ip route

 

 

Contrôle de la distribution d’itinéraires BGP

Vous pouvez avoir besoin que les itinéraires BGP soient distribués au sein de l’environnement virtuel, mais pas annoncés dans l’environnement physique. La distribution d’itinéraires peut être contrôlée et filtrée facilement à partir de la configuration NSX Edge.

 

Routage ECMP et haute disponibilité


Dans cette section, nous allons ajouter une deuxième passerelle de périmètre au réseau, puis utiliser le routage ECMP (Equal Cost Multipath) pour faire évoluer horizontalement la capacité de la passerelle et sa disponibilité.  Avec NSX, nous pouvons effectuer un ajout sur place d’un périphérique de périmètre et activer le routage ECMP.

La fonctionnalité de routage ECMP permet de transmettre les paquets par le biais de plusieurs chemins redondants. Ces chemins peuvent être ajoutés de manière statique ou à partir des calculs de mesures assurés par des protocoles de routage dynamique comme OSPF ou BGP. Une fois qu’un tronçon suivant a été sélectionné pour une paire d’adresses IP source et de destination, le cache d’itinéraires stocke le chemin sélectionné. Tous les paquets de ce flux sont acheminés vers le tronçon suivant sélectionné. Le routeur logique distribué tire parti d’un algorithme XOR pour déterminer le tronçon suivant à partir d’une liste de chemins ECMP possibles. Cet algorithme utilise les adresses IP source et de destination du paquet sortant en tant que sources d’entropie.

Dans ce module, nous allons configurer une nouvelle passerelle de périmètre, puis établir un cluster ECMP entre les passerelles de périmètre et le routeur logique distribué, en vue d’exploiter l’augmentation de la capacité et de la disponibilité.  Nous testerons la disponibilité en arrêtant l’une des passerelles de périmètre et en observant les chemins d’acheminement obtenus.


 

Accéder à NSX dans vSphere Web Client

 

  1. Cliquez sur l’onglet de navigateur vSphere Web Client.
  2. Cliquez sur l’icône Home.
  3. Cliquez sur Networking & Security.

 

 

Modifier la passerelle de périmètre Edge

 

Nous devons tout d’abord modifier la passerelle de périmètre NSX Edge existante pour supprimer l’adresse IP secondaire :

  1. Cliquez sur NSX Edges.
  2. Double-cliquez sur Perimeter-Gateway-01.

 

 

Modifier l’interface de liaison montante vNIC

 

  1. Cliquez sur Manage.
  2. Cliquez sur Settings.
  3. Cliquez sur Interfaces.
  4. Cliquez pour sélectionner vNIC 0.
  5. Cliquez sur l’icône crayon de modification.

 

 

Supprimer l’adresse IP secondaire

 

  1. Cliquez sur l’icône crayon de modification.
  2. Cliquez sur l’icône en forme de croix pour supprimer les adresses IP secondaires.

Nous allons utiliser temporairement cette adresse IP secondaire pour notre nouvelle passerelle de périmètre au cours des étapes suivantes.

 

 

Confirmer la modification

 

  1. Cliquez sur OK.

Remarque : si les boutons OK et Cancel ne sont pas visibles, vous devrez peut-être cliquer et faire glisser la boîte de dialogue Edit NSX Edge Interface pour la déplacer. En effet, la résolution d’écran disponible du laboratoire est limitée.

 

 

Revenir à NSX Edges

 

  1. Cliquez plusieurs fois sur Back pour revenir à la page récapitulative NSX Edges contenant la liste des périphériques Edge.

 

 

Ajouter une passerelle de périmètre Edge supplémentaire

 

 

 

Sélectionner et nommer la passerelle Edge

 

  1. Pour le paramètre « Install Type », sélectionnez Edge Services Gateway.
  2. Dans le champ « Name », saisissez Perimeter-Gateway-02.
  3. Cliquez sur Next.

 

 

Définir le mot de passe

 

  1. Saisissez VMware1!VMware1! dans le champ « Password ».
  2. Saisissez VMware1!VMware1! dans le champ « Confirm password ».
  3. Cochez la case Enable SSH access.
  4. Cliquez sur Next.

Remarque : les dispositifs NSX Edge exigent un mot de passe complexe comprenant au moins 12 caractères.

 

 

Ajouter l’appliance NSX Edge

 

  1. Cliquez sur le signe plus vert. La boîte de dialogue Add NSX Edge Appliance s’ouvre.
  2. Pour le paramètre « Cluster/Resource Pool », sélectionnez RegionA01-MGMT01.
  3. Pour le paramètre Datastore, sélectionnez RegionA01-ISCSI01-COMP01.
  4. Pour le paramètre « Host », sélectionnez esx-04a.corp.local.
  5. Cliquez sur OK.

 

 

Continuer le déploiement

 

  1. Cliquez sur Next.

 

 

Ajouter l’interface de liaison montante

 

  1. Cliquez sur le signe plus vert. La première interface est ajoutée.

 

 

Sélectionner le commutateur pour la connexion

 

Nous devons sélectionner l’interface de commutateur vers le nord (un groupe de ports distribués) pour cette passerelle de périmètre.

  1. Cliquez sur le lien Select à droite du champ Connected To.
  2. Cliquez sur Distributed Virtual Port Group.
  3. Cliquez sur le bouton radio à gauche de Uplink-RegionA01-vDS-MGMT pour le sélectionner.
  4. Cliquez sur OK.

 

 

Nommer l’interface et ajouter son adresse IP

 

  1. Dans le champ « Nom », saisissez Uplink.
  2. Pour le paramètre « Type », sélectionnez Uplink.
  3. Cliquez sur le signe plus vert.
  4. Dans le champ « Primary IP Address », saisissez 192.168.100.4.
  5. Dans le champ « Subnet Prefix Length », saisissez 24.
  6. Cliquez sur OK.

 

 

Ajouter l’interface de transit NSX Edge

 

  1. Cliquez sur le signe plus vert. La deuxième interface est ajoutée.

 

 

Sélectionner le commutateur pour la connexion

 

Nous devons sélectionner l’interface de commutateur vers le nord (commutateur logique reposant sur le VXLAN) pour cette passerelle de périmètre.

  1. Cliquez sur Select en regard de Connected To.
  2. Cliquez sur Logical Switch.
  3. Cliquez sur le bouton radio à gauche de Transit_Network_01 (5005) pour le sélectionner.
  4. Cliquez sur OK.

 

 

Nommer l’interface et ajouter son adresse IP

 

  1. Dans le champ « Name », saisissez Transit_Network_01.
  2. Pour le paramètre « Type », sélectionnez Internal.
  3. Cliquez sur le signe plus vert.
  4. Dans le champ « Primary IP Address », saisissez 192.168.5.4.
  5. Dans le champ « Subnet Prefix Length », saisissez 29.  Si vous ne spécifiez pas la valeur correcte (29), le laboratoire ne fonctionnera pas.
  6. Cliquez sur OK.

 

 

Continuer le déploiement

 

Vérifiez que les valeurs des colonnes IP Address et Subnet Prefix Length correspondent à celles figurant dans l’image ci-dessus.

  1. Cliquez sur Next.

 

 

Supprimer la passerelle par défaut

 

Nous supprimons la passerelle par défaut, car les informations sont reçues via le protocole OSPF.

  1. Décochez la case Configure Default Gateway.
  2. Cliquez sur Next.

 

 

Paramètres de pare-feu par défaut

 

  1. Cochez la case Configure Firewall default policy.
  2. Pour le paramètre « Default Traffic Policy », sélectionnez Accept.
  3. Cliquez sur Next.

 

 

Finaliser le déploiement

 

  1. Cliquez sur Finish. Le déploiement est lancé.

 

 

Déploiement du dispositif Edge

 

Le déploiement du dispositif NSX Edge demande quelques minutes.

  1. Pendant le déploiement de la passerelle de périmètre Perimeter-Gateway-02, la section « NSX Edges » indique 1 Installing.
  2. La passerelle de périmètre Perimeter-Gateway-02 présente l’état Busy. Cela signifie que le déploiement est en cours.
  3. Cliquez sur l’icône d’actualisation de vSphere Web Client pour mettre à jour l’état du déploiement de la passerelle de périmètre Perimeter-Gateway-02.

Une fois que la passerelle de périmètre Perimeter-Gateway-02 présente l’état Deployed, nous pouvons passer à l’étape suivante.

 

 

Configurer le routage sur le nouveau dispositif Edge

 

Pour pouvoir activer le routage ECMP, nous devons configurer le protocole OSPF sur la passerelle de périmètre Perimeter-Gateway-02 (NSX Edge).

  1. Double-cliquez sur Perimeter-Gateway-02.

Remarque : si le nom complet de la passerelle n’est pas visible, pointez la souris sur le nom pour afficher une info-bulle.

 

 

Activer le routage ECMP

 

Nous allons maintenant activer le routage ECMP sur le routeur distribué et les passerelles de périmètre.

  1. Cliquez plusieurs fois sur Back pour revenir à la page récapitulative NSX Edges contenant la liste des dispositifs Edge.

 

 

Présentation de la topologie

 

Voici la topologie du laboratoire à ce stade.  Celle-ci inclut la nouvelle passerelle de périmètre qui a été ajoutée, le routage configuré et le routage ECMP activé.

 

 

Vérifier le fonctionnement du routage ECMP à partir du routeur distribué

 

Accédons maintenant au routeur distribué pour nous assurer que le protocole OSPF communique et que le routage ECMP fonctionne.

  1. Cliquez sur l’icône Home.
  2. Cliquez sur VMs and Templates.

 

 

Vérifier le fonctionnement du routage ECMP à partir du routeur vPod

 

Remarque : pour libérer le curseur de la fenêtre, appuyez sur les touches Ctrl + Alt.

Nous allons à présent examiner le routage ECMP à partir du routeur vPod, qui simule un routeur physique sur votre réseau.

  1. Cliquez sur l’icône PuTTY dans la barre des tâches.

 

 

Arrêter la passerelle de périmètre 01

 

Nous allons simuler le passage hors ligne d’un nœud en arrêtant la passerelle de périmètre Perimeter-Gateway-01.

Retournez dans l’onglet de navigateur vSphere Web Client.

  1. Développez RegionA01.
  2. Cliquez avec le bouton droit sur Perimeter-Gateway-01-0.
  3. Cliquez sur Power.
  4. Cliquez sur Shut Down Guest OS.

 

 

Tester la haute disponibilité avec le routage ECMP

 

Avec le routage ECMP et les protocoles BGP et OSPF configurés dans l’environnement, nous pouvons changer dynamiquement les itinéraires en cas de défaillance sur un chemin spécifique.  Nous allons à présent simuler l’indisponibilité de l’un des chemins et la redistribution d’itinéraires qu’elle entraîne.

  1. Cliquez sur l’icône représentant l’invite de commande dans la barre des tâches.

 

 

Accéder à la console de la machine virtuelle du routeur logique distribué

 

  1. Cliquez sur l’onglet de navigateur Distributed-01-0.

Lorsque la console de la machine virtuelle est lancée dans l’onglet de navigateur, elle s’affiche sous la forme d’un écran noir. Cliquez à l’intérieur de l’écran noir et appuyez sur Entrée plusieurs fois pour faire apparaître la console de la machine virtuelle à partir de l’écran de veille.

 

 

Démarrer la passerelle de périmètre 01

 

Retournez dans l’onglet de navigateur vSphere Web Client.

  1. Développez RegionA01.
  2. Cliquez avec le bouton droit sur Perimeter-Gateway-01-0.
  3. Cliquez sur Power.
  4. Cliquez sur Power On.

 

 

Revenir au test ping

 

  • Dans la barre des tâches, revenez à l’invite de commande qui exécute le test ping.

 

 

Accéder à la console de la machine virtuelle du routeur logique distribué

 

  1. Cliquez sur l’onglet de navigateur Distributed-01-0.

Lorsque la console de la machine virtuelle est lancée dans l’onglet de navigateur, elle s’affiche sous la forme d’un écran noir. Cliquez à l’intérieur de l’écran noir et appuyez sur Entrée plusieurs fois pour faire apparaître la console de la machine virtuelle à partir de l’écran de veille.

 

Avant de passer au module 4 - Effectuez les étapes de nettoyage suivantes


Si vous prévoyez d’accomplir un autre module de ce laboratoire après avoir terminé le module 2, vous devez effectuer les étapes ci-dessous, faute de quoi le laboratoire ne fonctionnera pas correctement par la suite.


 

Supprimer le deuxième périphérique de périmètre Edge

 

Retournez dans l’onglet de navigateur vSphere Web Client.

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Supprimer la passerelle de périmètre Perimeter-Gateway-02

 

Nous devons supprimer la passerelle de périmètre Perimeter-Gateway-02 que nous avons créée.

  1. Cliquez sur NSX Edges.
  2. Cliquez pour sélectionner Perimeter-Gateway-02.
  3. Cliquez sur la croix rouge pour supprimer Perimeter-Gateway-02.

 

 

Confirmer la suppression

 

  1. Cliquez sur Yes.

 

 

Désactiver le routage ECMP sur le routeur logique distribué et la passerelle de périmètre 01

 

  1. Double-cliquez sur Distributed-Router-01.

 

 

Désactiver le routage ECMP sur le routeur distribué

 

  1. Cliquez sur Manage.
  2. Cliquez sur Routing.
  3. Cliquez sur Global Configuration.
  4. Cliquez sur Stop.

 

 

Publier les modifications

 

  1. Pour que le changement de configuration prenne effet, cliquez sur Publish Changes.

 

 

Retourner aux périphériques de périmètre Edge

 

  1. Cliquez plusieurs fois sur Back pour revenir à la page récapitulative NSX Edges contenant la liste des dispositifs Edge.

 

 

Accéder à la passerelle de périmètre 01

 

  1. Double-cliquez sur Perimeter-Gateway-01.

 

 

Désactiver le routage ECMP sur la passerelle de périmètre 01

 

  1. Cliquez sur Manage.
  2. Cliquez sur Routing.
  3. Cliquez sur Global Configuration.
  4. Cliquez sur Stop.

 

 

Publier les modifications

 

  1. Pour que le changement de configuration prenne effet, cliquez sur Publish Changes.

 

 

Activer le pare-feu sur la passerelle de périmètre 01

 

  1. Cliquez sur Manage.
  2. Cliquez sur Firewall.
  3. Cliquez sur Start.

 

 

Publier les modifications

 

  1. Pour mettre à jour la configuration sur la passerelle de périmètre Perimeter-Gateway-01 (NSX Edge), cliquez sur Publish Changes.

 

Conclusion du module 3


Dans ce module, nous avons couvert les fonctionnalités de routage du routeur logique distribué NSX (DLR) et des passerelles de services Edge (ESG) en effectuant les tâches suivantes :

  1. Migration des commutateurs logiques de la passerelle de services Edge (ESG) au routeur logique distribué (DLR).
  2. Configuration du routage dynamique entre la passerelle de services Edge et le routeur logique distribué via OSPF.
  3. Examen des fonctionnalités de routage centralisé de la passerelle de services Edge, notamment l’appairage du routage dynamique.
  4. Démonstration de l’évolutivité et de la disponibilité de la passerelle de services Edge en déployant une deuxième passerelle de services Edge et en établissant un appairage d’itinéraires entre elles via la configuration du routage ECMP (cheminement multiple à coût égal).
  5. Suppression de la deuxième passerelle de services Edge et des configurations du routage ECMP.

 

Vous avez terminé le module 3

Félicitations ! Vous avez terminé le module 3.

Si vous souhaitez en savoir plus sur le déploiement de NSX, rendez-vous dans le Centre de documentation NSX 6.4 via l’URL suivante :

Passez à n’importe lequel des modules suivants :

Liste des modules du laboratoire :

Responsables du laboratoire :

  • Modules 1 à 4 : Joe Collon, ingénieur système NSX, États-Unis

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 4 - Passerelle de services Edge (60 minutes)

Passerelle de services Edge - Présentation du module


La passerelle de services NSX Edge (ESG) offre la sécurité en périphérie et les services de routage à l’intérieur et en dehors de l’environnement virtualisé. Comme nous l’avons démontré dans les modules précédents, la passerelle de services Edge présente un certain nombre d’options de distribution du trafic nord-sud de manière évolutive et résiliente.

Le routeur logique distribué NSX Edge assure un routage est-ouest optimisé basé sur le noyau dans l’environnement NSX. Le routage distribué permet aux charges de travail qui se trouvent dans l’environnement NSX de communiquer directement entre elles sans avoir à faire passer le trafic via une interface de routage traditionnelle.

Outre ses fonctionnalités de routage, la passerelle de services NSX Edge fournit également de nombreux services de passerelle avancés, tels que : DHCP, un VPN, NAT, l’équilibrage de charge et un pare-feu traditionnel de couche 3. Pour exploiter ces fonctionnalités, il suffit de les activer dans la configuration de la passerelle de services Edge.

Dans ce module, nous allons découvrir certains des services fournis par la passerelle de services Edge. À la fin du module, vous aurez eu l’occasion d’effectuer les tâches suivantes :

  • Déployer une nouvelle passerelle de services Edge
  • Configurer l’équilibrage de charge sur la passerelle de services Edge
  • Vérifier la configuration de l’équilibreur de charge
  • Configurer le pare-feu de couche 3 de la passerelle de services Edge
  • Configurer le relais DHCP
  • Configurer un VPN de couche 2

Pour obtenir une description complète de ces fonctionnalités et d’autres fonctionnalités de la passerelle de services Edge, suivez le lien à la fin de ce module.


Déployer la passerelle de services Edge pour l’équilibrage de charge


La passerelle de services NSX Edge fournit une fonctionnalité d’équilibrage de charge. La mise en œuvre d’un équilibreur de charge offre de nombreux avantages, notamment une utilisation efficace des ressources, ainsi qu’un haut niveau d’évolutivité et de résilience au niveau de l’application. Il peut ainsi en résulter une réduction des temps de réponse pour les applications, la possibilité de faire évoluer une application au-delà des capacités d’un seul serveur, mais également la réduction de la charge d’un serveur principal via l’utilisation du déchargement HTTPS.

Le service d’équilibrage de charge est capable d’équilibrer la charge TCP ou UDP au niveau de la couche 4, et la charge HTTP ou HTTPS au niveau de la couche 7.

Dans cette section, nous allons déployer et configurer une nouvelle appliance NSX Edge en tant qu’équilibreur de charge en mode « manchot ».


 

Vérifier que le laboratoire est prêt

 

  • L’état du laboratoire est affiché sur le Bureau de la machine virtuelle Windows de la console principale.

Des contrôles de validation permettent de s’assurer que tous les composants du laboratoire sont correctement déployés, et une fois la validation terminée, l’état s’affiche en vert avec la mention « Ready ». Le déploiement d’un laboratoire peut échouer en raison d’un manque de ressources dans l’environnement.

 

 

Gagner de l’espace à l’écran en réduisant le volet des tâches de droite

 

En cliquant sur les épingles, vous pouvez réduire les volets de tâches afin de bénéficier d’un espace d’affichage plus important dans le volet principal.  Vous pouvez également réduire le volet de gauche pour optimiser l’espace disponible.

 

 

Accéder à la section « Networking & Security » de vSphere Web Client

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Création d’une nouvelle passerelle de services Edge

 

Nous allons configurer le service d’équilibrage de charge sur une nouvelle passerelle de services Edge. Pour commencer le déploiement d’une nouvelle passerelle de services Edge, procédez comme suit :

  1. Cliquez sur NSX Edges.
  2. Cliquez sur le signe plus vert.

 

 

Définition du nom et du type

 

  1. Dans le champ « Name », saisissez OneArm-LoadBalancer.
  2. Cliquez sur Next.

 

 

Configuration d’un compte d’administration

 

  1. Saisissez VMware1!VMware1! dans le champ « Password ».
  2. Saisissez VMware1!VMware1! dans le champ « Confirm password ».
  3. Cochez la case Enable SSH access.
  4. Cliquez sur Next.

Remarque : les dispositifs NSX Edge exigent un mot de passe complexe comprenant au moins 12 caractères.

 

 

Définition de la taille de la passerelle et du placement des machines virtuelles

 

Il existe quatre tailles d’appliance différentes pour la passerelle de services Edge. Les spécifications correspondantes sont les suivantes :

  • Compact : 1 vCPU, 512 Mo de RAM
  • Large : 2 vCPU, 1 024 Mo de RAM
  • Quad Large : 4 vCPU, 2 Go de RAM
  • X-Large : 6 vCPU, 8 Go de RAM

Pour cette nouvelle passerelle de services Edge, nous sélectionnerons la taille « Compact », mais notez que les passerelles de services Edge peuvent être reconfigurées avec n’importe quelle taille après le déploiement. Pour continuer la création de la nouvelle passerelle de services Edge :

  1. Cliquez sur le signe plus vert. La fenêtre contextuelle Add NSX Edge Appliances s’ouvre.

 

 

Placement du cluster/de la banque de données

 

  1. Pour le paramètre « Cluster/Resource Pool », sélectionnez RegionA01-MGMT01.
  2. Pour le paramètre « Datastore », sélectionnez RegionA01-ISCSI01-COMP01.
  3. Pour le paramètre « Host », sélectionnez esx-05a.corp.local.
  4. Cliquez sur OK.

 

 

Configurer le déploiement

 

  1. Cliquez sur Next.

 

 

Placement d’une nouvelle interface réseau sur le dispositif NSX Edge

 

Comme il s’agit d’un équilibreur de charge en mode « manchot », il n’a besoin que d’une seule interface réseau.

  1. Cliquez sur le signe plus vert.

 

 

Configuration de la nouvelle interface réseau pour le dispositif NSX Edge

 

Nous allons configurer la première interface réseau pour ce nouveau dispositif NSX Edge.  

  1. Dans le champ « Name », saisissez WebNetwork.
  2. Pour le paramètre « Type », sélectionnez Uplink.
  3. Cliquez sur Select.

 

 

Sélection du réseau pour l’interface du nouveau dispositif Edge

 

L’interface de l’équilibreur de charge en mode « manchot » se trouvera sur le même réseau que les deux serveurs Web auxquels elle fournira des services d’équilibrage de charge.

  1. Cliquez sur Logical Switch.
  2. Cliquez sur le bouton radio à gauche du commutateur logique Web_Tier_Logical_Switch (5006) pour le sélectionner.
  3. Cliquez sur OK.

 

 

Configuration de sous-réseaux

 

  1. Cliquez sur le signe plus vert. Vous pouvez ainsi configurer l’adresse IP de cette interface.

 

 

Configuration de l’adresse IP et du sous-réseau

 

Pour ajouter une nouvelle adresse IP à cette interface :

  1. Dans le champ « Primary IP Address », saisissez 172.16.10.10.
  2. Dans le champ « Subnet Prefix Length », saisissez 24.
  3. Cliquez sur OK.

 

 

Vérifier la liste des interfaces

 

Vérifiez que les valeurs des colonnes IP Address et Subnet Prefix Length correspondent aux informations figurant dans l’image ci-dessus.

  1. Cliquez sur Next.

 

 

Configuration de la passerelle par défaut

 

  1. Dans le champ « Gateway IP », saisissez 172.16.10.1.
  2. Cliquez sur Next.

 

 

Configuration des options de pare-feu et de haute disponibilité

 

  1. Cochez la case Configure Firewall default policy.
  2. Pour le paramètre « Default Traffic Policy », sélectionnez Accept.
  3. Cliquez sur Next.

 

 

Vérifier l’ensemble des paramètres et terminer la configuration

 

  1. Cliquez sur Finish pour commencer le déploiement.

 

 

Surveillance du déploiement

 

Le déploiement du dispositif NSX Edge peut demander quelques instants.

  1. Pendant le déploiement du dispositif OneArm-LoadBalancer, la section « NSX Edges » indique 1 Installing.
  2. Le dispositif OneArm-LoadBalancer présente l’état Busy. Cela signifie que le déploiement est en cours.
  3. Cliquez sur l’icône d’actualisation de vSphere Web Client pour mettre à jour l’état du déploiement du dispositif OneArm-LoadBalancer.

Une fois que le dispositif OneArm-LoadBalancer présente l’état Deployed, vous pouvez passer à l’étape suivante.

 

Configurer la passerelle de services Edge pour l’équilibrage de charge


Maintenant que la passerelle de services Edge est déployée, nous allons configurer les services d’équilibrage de charge.


 

Configurer le service d’équilibreur de charge

 

Le diagramme ci-dessus illustre la topologie finale pour l’équilibreur de charge fourni par la nouvelle passerelle de services NSX Edge OneArm-LoadBalancer. Une fois configurée, cette passerelle résidera sur le commutateur logique Web_Tier_Logical_Switch existant. La connexion de la passerelle au commutateur logique est fournie à la passerelle de services Edge Perimeter-Gateway-01 existante.

Le service d’équilibrage de charge de cette passerelle de services Edge acceptera les connexions au client entrantes sur une adresse IP du serveur virtuel de 172.16.10.10. Lorsqu’il reçoit une nouvelle demande de connexion entrante, l’équilibreur de charge associe la demande à un serveur interne d’une liste de membres du pool prédéfinis. Dans cet exemple, il y a deux membres du pool : web-01a.corp.local (172.16.10.11) et web-02a.corp.local (172.16.10.12).

L’équilibreur de charge peut ainsi fournir un point d’accès unique aux clients entrants, tout en distribuant de manière transparente ces connexions à plusieurs serveurs Web internes. En cas d’échec ou d’indisponibilité d’un serveur Web, l’équilibreur de charge détecte le problème et supprime le serveur de sa liste de membres du pool actif.  Les moniteurs de service permettent de vérifier périodiquement l’intégrité de tous les membres du pool et, une fois que le serveur défaillant est remis en service, il est réintégré dans les membres du pool actif.

 

 

Configurer la fonction d’équilibreur de charge sur le dispositif OneArm-LoadBalancer

 

  1. Double-cliquez sur OneArm-LoadBalancer.

 

 

Accéder au nouveau dispositif NSX Edge

 

  1. Cliquez sur Manage.
  2. Cliquez sur Load Balancer.
  3. Cliquez sur Global Configuration.
  4. Pour modifier la configuration globale de l’équilibreur de charge, cliquez sur Edit en regard de « Load balancer global configuration ».

 

 

Modifier la configuration globale de l’équilibreur de charge

 

Pour activer le service d’équilibreur de charge :

  1. Cochez la case Enable Load Balancer.
  2. Cliquez sur OK.

 

 

Création d’un nouveau profil d’application

 

Un profil d’application permet de définir le comportement d’un type caractéristique de trafic réseau. Ces profils sont appliqués à un serveur virtuel, qui gère le trafic en fonction des valeurs spécifiées dans le profil d’application.  

L’utilisation de profils peut réduire le risque d’erreur pour les tâches de gestion du trafic et augmenter l’efficacité de ces dernières.  

  1. Cliquez sur Application Profiles.
  2. Cliquez sur le signe plus vert. La fenêtre New Profile s’ouvre.

 

 

Configuration du protocole HTTPS pour le nouveau profil d’application

 

Pour le nouveau profil d’application, configurez les paramètres suivants :

  1. Dans le champ « Name », saisissez OneArmWeb-01.
  2. Pour le paramètre « Type », sélectionnez HTTPS.
  3. Cochez la case Enable SSL Passthrough. Le service d’équilibrage de charge est ainsi configuré pour transmettre les connexions HTTPS via l’équilibreur de charge non inspectées, pour aboutir au serveur du pool.
  4. Cliquez sur OK.

 

 

Définir le moniteur de service HTTPS

 

Les moniteurs permettent de s’assurer que les membres du pool fournissant des services à un serveur virtuel fonctionnent correctement. Le moniteur HTTPS par défaut utilise une requête HTTP GET de base (« GET / »). Nous allons définir un moniteur personnalisé qui effectuera un bilan d’intégrité pour l’URL spécifique d’une application. Il vérifie que le serveur Web répond aux connexions et que notre application fonctionne correctement.

  1. Cliquez sur Service Monitoring.
  2. Cliquez sur le signe plus vert pour définir un nouveau moniteur.

 

 

Définir le nouveau moniteur

 

Entrez les informations suivantes pour définir le nouveau moniteur :

  1. Entrez custom_https_monitor dans le champ Name.
  2. Pour le paramètre Type, sélectionnez HTTPS.
  3. Dans le champ URL, saisissez /cgi-bin/app.py.
  4. Cliquez sur OK.

 

 

Créer un nouveau pool

 

Un groupe de serveurs de pool est l’entité qui représente les nœuds vers lesquels la charge du trafic est équilibrée. Nous allons ajouter les deux serveurs Web web-01a et web-02a à un nouveau pool. Pour créer le nouveau pool :

  1. Cliquez sur Pools.
  2. Cliquez sur le signe plus vert. La fenêtre contextuelle « New Pool » s’ouvre.

 

 

Configuration du nouveau pool

 

Pour les paramètres de ce nouveau pool, configurez les valeurs suivantes :

  1. Dans le champ « Name », saisissez Web-Tier-Pool-01.
  2. Pour le paramètre « Monitors », sélectionnez default_https_monitor.
  3. Cliquez sur le signe plus vert.

 

 

Ajouter des membres au pool

 

  1. Dans le champ « Name », saisissez web-01a.
  2. Dans le champ « IP Address / VC Container », saisissez 172.16.10.11.
  3. Dans le champ « Port », saisissez 443.
  4. Dans le champ « Monitor Port », saisissez 443.
  5. Cliquez sur OK.

Répétez la procédure ci-dessus pour ajouter le second membre du pool avec les informations suivantes :

  • Name : web-02a
  • IP Address : 172.16.10.12
  • Port : 443
  • Monitor Port : 443

 

 

Enregistrer les paramètres du pool

 

  1. Cliquez sur OK.

 

 

Créer un nouveau serveur virtuel

 

Un serveur virtuel est l’entité qui accepte les connexions entrantes provenant du « front-end » d’une configuration équilibrée en charge. Le trafic utilisateur est dirigé vers l’adresse IP du serveur virtuel, puis est redistribué vers les membres du pool côté « back-end » de l’équilibreur de charge. Pour configurer un nouveau serveur virtuel sur cette passerelle de services Edge et terminer la configuration de l’équilibrage de charge, procédez comme suit :

  1. Cliquez sur Virtual Servers.
  2. Cliquez sur le signe plus vert. La fenêtre contextuelle « New Virtual Server » s’ouvre.

 

 

Configurer le nouveau serveur virtuel

 

Pour les paramètres de ce nouveau serveur virtuel, configurez les valeurs suivantes :

  1. Dans le champ « Name », saisissez Web-Tier-VIP-01.
  2. Dans le champ « IP Address », saisissez 172.16.10.10.
  3. Pour le paramètre « Protocol », sélectionnez HTTPS.
  4. Sélectionnez Web-Tier-Pool-01.
  5. Cliquez sur OK.

 

Équilibreur de charge de la passerelle de services Edge - Vérifier la configuration


Maintenant que nous avons configuré les services d’équilibrage de charge, nous allons en vérifier la configuration.


 

Tester l’accès au serveur virtuel

 

  1. Ouvrez un nouvel onglet de navigateur.
  2. Cliquez pour développer la liste de favoris.
  3. Cliquez pour sélectionner le favori 1-Arm LB Customer DB.
  4. Cliquez sur Advanced.

 

 

Ignorer l’erreur SSL

 

  1. Cliquez sur Proceed to 172.16.10.10 (unsafe).

 

 

Tester l’accès au serveur virtuel

 

Vous devriez pouvoir accéder sans problème à l’équilibreur de charge en mode « manchot ».

  1. Cliquez sur l’icône d’actualisation. Vous pouvez ainsi voir la distribution des connexions aux deux membres du pool par l’équilibreur de charge.

Remarque : en raison de la mise en cache dans Chrome, les réactualisations ultérieures peuvent ne pas apparaître pour l’utilisation des deux serveurs.

 

 

Afficher les statistiques du pool

 

Retournez dans l’onglet de navigateur vSphere Web Client.

Pour afficher l’état des membres individuels du pool :

  1. Cliquez sur Pools.
  2. Cliquez sur Show Pool Statistics.
  3. Cliquez sur pool-1. L’état actuel de chaque membre s’affiche.
  4. Fermez la fenêtre en cliquant sur le bouton X.

 

 

Amélioration des réponses du moniteur (bilan d’intégrité)

 

Pour faciliter la résolution des problèmes, les commandes « show ...pool » de l’équilibreur de charge NSX permettent d’obtenir des informations détaillées sur les défaillances des membres du pool. Nous allons provoquer deux défaillances différentes et examiner la réponse en utilisant des commandes « show » sur la passerelle Edge Gateway OneArm-LoadBalancer-0.

  1. Dans la zone de recherche, saisissez loadbalancer. La zone de recherche est située dans le coin supérieur droit de vSphere Web Client.
  2. Cliquez sur OneArm-LoadBalancer-0.

 

 

Ouvrir la console de l’équilibreur de charge

 

  1. Cliquez sur Summary.
  2. Cliquez sur la console de la machine virtuelle.

 

 

Connexion à OneArm-LoadBalancer-0

 

  1. Connectez-vous en tant qu’admin.
  2. Saisissez VMware1!VMware1! dans le champ « Password ».

 

 

Examiner l’état du pool avant la défaillance

 

  1. Saisissez show service loadbalancer pool.
show service loadbalancer pool

Remarque : les membres du pool, web-01a et web-02a, présentent l’état « UP » (Actif).

 

 

Démarrer PuTTY

 

  1. Cliquez sur PuTTY dans la barre des tâches.

 

 

Accéder à web-01a.corp.local via le protocole SSH

 

  1. Faites défiler la liste vers le bas jusqu’à web-01a.corp.local.
  2. Sélectionnez web-01a.corp.local.
  3. Cliquez sur Load.
  4. Cliquez sur Open.

 

 

Arrêter le service Nginx

 

Nous allons arrêter le protocole HTTPS pour simuler la première condition de défaillance.

  1. Saisissez systemctl stop nginx.
systemctl stop nginx

 

 

Console de l’équilibreur de charge

 

  1. Saisissez show service loadbalancer pool.
show service loadbalancer pool

Comme le service est indisponible, les détails de la défaillance indiquent que l’écran de contrôle de l’intégrité de l’équilibreur de charge n’a pas pu établir de session SSL.

 

 

Démarrer le service NGINX

 

Revenez à la session SSH Putty du serveur web-01a.

1. Saisissez systemctl start nginx.

systemctl start nginx

 

 

Arrêter le serveur web-01a

 

Retournez dans l’onglet de navigateur vSphere Web Client.

  1. Dans la zone de recherche, saisissez web-01a. La zone de recherche est située dans le coin supérieur droit de vSphere Web Client.
  2. Cliquez sur web-01a.

 

 

Mettre le serveur web-01a hors tension

 

  1. Cliquez sur Actions.
  2. Cliquez sur Power.
  3. Cliquez sur Power Off.
  4. Cliquez sur Yes pour confirmer.

 

 

Vérifier l’état du pool

 

  1. Saisissez show service loadbalancer pool.
show service loadbalancer pool

Comme la machine virtuelle est actuellement indisponible, les détails de la défaillance indiquent que le client n’a pas pu établir de connexion de couche 4, à la différence de l’étape précédente, où il n’avait pas pu établir de connexion de couche 7 (SSL).

 

 

Mettre le serveur web-01a sous tension

 

Retournez dans l’onglet de navigateur vSphere Web Client.

  1. Cliquez sur Actions.
  2. Cliquez sur Power.
  3. Cliquez sur Power On.

 

 

Conclusion

Dans le cadre de ce laboratoire, nous avons déployé et configuré une nouvelle passerelle de services Edge et activé les services d’équilibrage de charge pour l’application 1-Arm LB Customer DB.

La leçon sur l’équilibreur de charge de la passerelle de services Edge est maintenant terminée. Dans la section suivante, nous nous pencherons sur le pare-feu de la passerelle de services Edge.

 

Pare-feu de la passerelle de services Edge


Le pare-feu NSX Edge surveille le trafic nord-sud afin de fournir des fonctionnalités de sécurité périmétrique. À l’inverse sur le pare-feu distribué NSX, les règles s’appliquent au niveau de la carte d’interface réseau virtuelle de chaque VM.

Le pare-feu Edge vous permet de répondre aux principales exigences en matière de sécurité périmétrique, notamment par le développement de zones DMZ basées sur des constructions réseau IP/VLAN, l’isolation des locataires dans des Data Centers virtuels mutualisés, et l’application des règles de pare-feu classique aux terminaux physiques incompatibles avec les solutions de pare-feu distribué.


 

Utilisation des règles du pare-feu NSX Edge

La passerelle de services Edge et le routeur logique présentent tous deux un onglet dédié à la configuration du pare-feu, mais les conditions d’application des règles correspondantes diffèrent sensiblement de l’un à l’autre. Les règles de pare-feu appliquées à un routeur logique sont appliquées à la machine virtuelle de contrôle du routeur logique et ne sont pas un composant du plan de données. Pour protéger le trafic du plan de données, les règles de pare-feu logique (distribué) peuvent être utilisées pour la protection est-ouest au niveau de la carte d’interface réseau virtuelle ; les règles au niveau de la passerelle de services NSX Edge peuvent quant à elles s’appliquer à la protection nord-sud, ou lors du routage entre les groupes de ports physiques reposant sur un VLAN.

Les règles créées dans l’interface utilisateur de pare-feu NSX qui sont applicables à une passerelle NSX Edge Gateway sont affichées sur le dispositif Edge en mode lecture seule. Lorsque les règles sont présentes dans plusieurs sites, elle sont affichées et appliquées dans l’ordre suivant :

  1. Règles définies par l’utilisateur de l’interface utilisateur de pare-feu (lecture seule).
  2. Règles configurées automatiquement (règles créées automatiquement qui permettent la circulation du trafic de contrôle pour les services Edge).
  3. Règles définies par l’utilisateur dans l’interface utilisateur du pare-feu NSX Edge.
  4. Règle par défaut.

 

 

Ouvrir la section « Network & Security »

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Ouvrir un dispositif NSX Edge

 

  1. Cliquez sur NSX Edges.
  2. Double-cliquez sur Perimeter-Gateway-01.

 

 

Ouvrir l’onglet « Manage »

 

  1. Cliquez sur Manage.
  2. Cliquez sur Firewall.
  3. Cliquez pour sélectionner Default Rule.
  4. Cliquez sur l’icône en forme de crayon sous la colonne Action.
  5. Sélectionnez Deny dans le champ Action.

Remarque : avec NSX, les trois options suivantes sont applicables à une règle de pare-feu :

  • Accept : le trafic qui suit la règle est transmis normalement.
  • Deny : le trafic qui suit la règle est éliminé, et aucune notification n’est fournie à la source du trafic.
  • Reject : le trafic qui suit la règle est également éliminé, mais un message ICMP Unreachable est envoyé à l’adresse IP source du paquet d’origine.

 

 

Publier les modifications

 

Nous n’allons pas apporter de modifications définitives à la configuration du pare-feu de la passerelle de services Edge.

  1. Pour annuler les modifications, cliquez sur Revert.

 

 

Ajouter une règle au pare-feu de la passerelle de services Edge

 

Maintenant que vous savez comment modifier une règle existante du pare-feu de la passerelle de services Edge, nous allons ajouter une nouvelle règle de pare-feu Edge pour bloquer l’accès de Control Center à l’application Customer DB.

  1. Pour ajouter une nouvelle règle de pare-feu, cliquez sur le signe plus vert.
  2. Placez le curseur de la souris dans l’angle supérieur droit de la colonne Name, puis cliquez sur l’icône en forme de crayon.
  3. Dans le champ « Rule Name », saisissez Main Console FW Rule.
  4. Cliquez sur OK.

 

 

Spécifier la source

 

Placez le curseur de la souris dans l’angle supérieur droit de la colonne Source, puis cliquez sur l’icône en forme de crayon.

  1. Dans le menu déroulant Object Type, sélectionnez IP Sets.
  2. Cliquez sur le lien hypertexte New IP Set....
  3. Dans le champ « Name », saisissez Main Console.
  4. Dans le champ « IP Address », saisissez 192.168.110.10.
  5. Cliquez sur OK.

 

 

Spécifier la source

 

  1. Dans la liste Object Type, sélectionnez IP Sets.
  2. Dans la liste Available Objects, cliquez pour sélectionner Main Console.
  3. Cliquez sur la flèche vers la droite. L’objet est déplacé dans la liste Selected Objects.
  4. Vérifiez que Main Console figure dans la liste Selected Objects et cliquez sur OK.

 

 

Spécifier la destination

 

Placez le curseur de la souris dans l’angle supérieur droit de la colonne Destination, puis cliquez sur l’icône en forme de crayon.

  1. Dans la liste Object Type, sélectionnez Logical Switch.
  2. Dans la liste Available Objects, cliquez pour sélectionner Web_Tier_Logical_Switch.
  3. Cliquez sur la flèche vers la droite. L’objet est déplacé dans la liste Selected Objects.
  4. Vérifiez que Web_Tier_Logical_Switch figure dans la liste Selected Objects et cliquez sur OK.

 

 

Configurer l’action

 

  1. Cliquez sur l’icône en forme de crayon sous la colonne Action.
  2. Sélectionnez Reject dans le champ Action.
  3. Cliquez sur OK.

Remarque : l’option Reject a été préférée à Deny pour accélérer l’échec de la connexion Web dans les étapes qui suivent. Si l’option Deny est sélectionnée, le flux est abandonné et arrive finalement à expiration. Du fait que l’option Reject a été choisie, un message ICMP signalant immédiatement au système d’exploitation l’échec de la connexion est envoyé à la console principale lors d’une tentative de connexion. Pour des raisons de sécurité, il est recommandé d’utiliser l’option Deny.

 

 

Publier les modifications

 

  1. Pour mettre à jour la configuration sur la passerelle de périmètre Perimeter-Gateway-01 (NSX Edge), cliquez sur Publish Changes.

 

 

Tester la nouvelle règle de pare-feu

 

Maintenant que nous avons configuré une nouvelle règle de pare-feu qui bloquera l’accès de Control Center au commutateur logique de niveau Web, effectuons un test rapide :

  1. Ouvrez un nouvel onglet de navigateur.
  2. Cliquez sur le favori Customer DB App.

Vérifiez que la console principale ne peut pas accéder à l’application Customer DB App. Une page de navigateur indiquant que le site Web est inaccessible devrait s’afficher. Maintenant, modifions la règle de pare-feu de manière à autoriser la console principale à accéder à l’application Customer DB App.

 

 

Définir la règle de pare-feu « Main Console FW Rule » sur « Accept »

 

Retournez dans l’onglet de navigateur vSphere Web Client.

  1. Cliquez sur l’icône en forme de crayon sous la colonne Action de la règle de pare-feu Main Console FW Rule.
  2. Sélectionnez Accept dans le champ Action.
  3. Cliquez sur OK.

 

 

 

Publier les modifications

 

  1. Pour mettre à jour la configuration sur la passerelle de périmètre Perimeter-Gateway-01 (NSX Edge), cliquez sur Publish Changes.

 

 

Vérifier que l’accès à l’application Customer DB App est autorisé

 

Retournez dans l’onglet de navigateur Customer DB App.

  1. Cliquez sur l’icône d’actualisation.

Comme la règle de pare-feu Main Console FW Rule a été définie sur « Accept », la console principale peut maintenant accéder à l’application Customer DB App.

 

 

Supprimer la règle de pare-feu « Main Console FW Rule »

 

  1. Cliquez pour sélectionner Main Console FW Rule.
  2. Cliquez sur la croix rouge pour supprimer la règle de pare-feu sélectionnée.
  3. Cliquez sur OK pour confirmer.

 

 

Publier les modifications

 

  1. Pour mettre à jour la configuration sur la passerelle de périmètre Perimeter-Gateway-01 (NSX Edge), cliquez sur Publish Changes.

 

 

Conclusion

Dans ce laboratoire, nous avons appris à modifier une règle existante du pare-feu de la passerelle de services Edge et à configurer une nouvelle règle bloquant l’accès externe à l’application Customer DB App.

La leçon sur le pare-feu de la passerelle de services Edge est maintenant terminée. Dans la section suivante, nous aborderons la gestion des services DHCP sur la passerelle de services Edge.

 

Relais DHCP


Dans un réseau qui présente seulement des segments de réseau uniques, les clients DHCP communiquent directement avec leur serveur DHCP. Les serveurs DHCP peuvent également fournir des adresses IP pour plusieurs réseaux, y compris ceux qui ne se trouvent pas sur le même segment que le serveur lui-même. En raison du type de diffusion de DHCP, lorsque le serveur DHCP fournit des adresses IP pour des plages d’adresses extérieures à son réseau local, il n’est pas en mesure de communiquer directement avec les clients adressant les demandes.

Dans ces situations, un agent de relais DHCP est utilisé pour relayer la demande DHCP diffusée par les clients. Pour ce faire, la demande de diffusion est dirigée sous forme de paquet à destination unique vers un serveur DHCP désigné. Le serveur DHCP sélectionne une étendue DHCP en fonction de la plage d’adresses dont est issu le paquet à destination unique. Le paquet de réponse DHCP est fourni à l’adresse du relais, puis rediffusé sur le réseau d’origine au client.

Les points abordés dans ce laboratoire sont les suivants :

  • Créer un nouveau segment de réseau dans NSX
  • Activer l’agent de relais DHCP sur le nouveau segment de réseau
  • Utiliser une étendue DHCP sur un serveur DHCP qui nécessite un relais DHCP
  • Démarrer une machine virtuelle vierge sur le réseau (via l’environnement d’exécution de préamorçage) à l’aide des options d’étendue DHCP

Pour ce laboratoire, les éléments suivants ont été préconfigurés :

  • Serveur DHCP basé sur Windows Server, avec l’étendue et les options d’étendue DHCP appropriées définies.
  • Serveur TFTP pour les fichiers de démarrage de l’environnement d’exécution de préamorçage. Ce serveur a été installé et configuré, et les fichiers de système d’exploitation chargés.

 

Topologie du laboratoire

 

Ce diagramme présente la topologie finale qui sera créée et utilisée dans ce module de laboratoire.

 

 

Accéder à NSX via vSphere Web Client

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Créer un nouveau commutateur logique

 

Nous devons tout d’abord créer un nouveau commutateur logique qui exécutera notre nouveau réseau 172.16.50.0/24.

  1. Cliquez sur Logical Switches.
  2. Cliquez sur le signe plus vert pour créer un commutateur logique.

 

 

Connecter le commutateur logique à la passerelle de périmètre

 

Nous allons maintenant connecter le commutateur logique à une interface sur la passerelle de périmètre.  Cette interface sera la passerelle par défaut pour le réseau 172.16.50.0/24, avec l’adresse 172.16.50.1.

  1. Cliquez sur NSX Edges.
  2. Double-cliquez sur Perimeter-Gateway-01.

 

 

Configurer le relais DHCP

 

En restant dans la passerelle de périmètre, nous devons procéder à la configuration globale du relais DHCP.

  1. Cliquez sur Manage.
  2. Cliquez sur DHCP.
  3. Cliquez sur Relay.
  4. Cliquez sur Edit.

 

 

Créer une machine virtuelle vierge pour le démarrage via l’environnement d’exécution de pré-amorçage

 

Nous allons maintenant créer une machine virtuelle vierge qui démarrera via l’environnement d’exécution de pré-amorçage à partir du serveur DHCP de destination du relais.

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Hosts and Clusters.

 

 

Accéder à la machine virtuelle nouvellement créée

 

Nous allons maintenant ouvrir une console pour cette machine virtuelle et observer le démarrage de cette dernière à partir de l’image de l’environnement d’exécution de pré-amorçage. Ces informations sont reçues via le serveur DHCP distant que nous avons configuré précédemment.

  1. Cliquez sur PXE VM.
  2. Cliquez sur Summary.
  3. Cliquez sur la console de la machine virtuelle.

 

 

Vérifier le bail DHCP

 

Pendant que la machine virtuelle démarre, nous pouvons vérifier l’adresse utilisée dans les baux DHCP.

  1. Accédez au bureau de la console principale et double-cliquez sur l’icône DHCP.

 

 

Accéder à la machine virtuelle démarrée

 

  1. Cliquez sur l’onglet de navigateur PXE VM.

 

 

Vérifier l’adresse et la connectivité

 

Le widget situé dans le coin supérieur droit de la machine virtuelle affiche les statistiques, ainsi que l’adresse IP de la machine virtuelle. Celle-ci doit correspondre à l’adresse IP affichée précédemment dans la section DHCP.

 

 

Conclusion

Dans cette section, nous avons créé un nouveau segment de réseau, puis relayé les requêtes DHCP de ce réseau vers un serveur DHCP externe. Ce faisant, nous avons pu accéder aux options de démarrage supplémentaires de ce serveur DHCP externe et effectuer un démarrage dans un système d’exploitation Linux via l’environnement d’exécution de pré-amorçage.

Dans la section suivante, nous nous pencherons sur les services de VPN de couche 2 de la passerelle de services Edge.

 

Configuration d’un VPN de couche 2


Dans cette section, nous allons exploiter les fonctionnalités de VPN de couche 2 de la passerelle NSX Edge Gateway pour étendre une limite de couche 2 entre deux clusters vSphere distincts. Pour démontrer cette capacité, nous déploierons un serveur VPN de couche 2 NSX Edge sur le cluster RegionA01-MGMT01 et un client VPN de couche 2 NSX Edge sur le cluster RegionA01-COMP01. Ensuite, nous testerons l’état du tunnel afin de vérifier que la configuration a réussi.


 

Ouvrir Google Chrome et accéder à vSphere Web Client

 

  1. Ouvrez le navigateur Web Google Chrome à partir du bureau (s’il n’est pas déjà ouvert).

 

 

Accéder à la section « Networking & Security » de vSphere Web Client

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Création d’une passerelle NSX Edge Gateway pour le serveur VPN de couche 2

 

Pour créer le service de serveur VPN de couche 2, nous devons d’abord déployer une passerelle NSX Edge Gateway pour l’exécution du service.  

  1. Cliquez sur NSX Edges.
  2. Cliquez sur le signe plus vert.

 

 

Configuration d’une nouvelle passerelle NSX Edge Gateway : L2VPN-Server

 

  1. Dans le champ Name, saisissez L2VPN-Server.
  2. Cliquez sur Next.

 

 

Configurer les paramètres de la nouvelle passerelle NSX Edge Gateway : L2VPN-Server

 

  1. Saisissez VMware1!VMware1! dans le champ « Password ».
  2. Saisissez VMware1!VMware1! dans le champ « Confirm password ».
  3. Cochez la case Enable SSH access.
  4. Cliquez sur Next.

 

 

Préparation de la passerelle NSX Edge L2VPN-Server pour les connexions VPN de couche 2

Avant de configurer NSX Edge que vous venez de déployer pour les connexions de VPN de couche 2, vous devez suivre les étapes suivantes :

  1. ajouter une interface trunk à la passerelle Edge Gateway de serveur L2VPN ;
  2. ajouter une sous-interface à la passerelle Edge Gateway de serveur L2VPN ;
  3. configurer le routage dynamique (OSPF) sur la passerelle Edge Gateway de serveur L2VPN.

 

 

Configurer l’ID Routeur pour cette instance de NSX Edge

 

Nous allons maintenant configurer le routage dynamique sur cette passerelle Edge Gateway.

  1. Cliquez sur Routing.
  2. Cliquez sur Global Configuration.
  3. Pour modifier la configuration du routage dynamique, cliquez sur Edit en regard de « Dynamic Routing Configuration ».

 

 

Configurer le protocole OSPF sur le serveur de VPN de couche 2 de NSX Edge

 

  1. Cliquez sur OSPF.
  2. Sous « Area to Interface Mapping », cliquez sur le signe plus vert.

 

 

Activer la distribution d’itinéraires OSPF

 

  1. Cliquez sur Route Redistribution.
  2. Pour modifier l’état de la redistribution d’itinéraires, cliquez sur Edit en regard de « Route Redistribution Status ».
  3. Cochez la case OSPF.
  4. Cliquez sur OK.

 

 

Configurer le service de VPN de couche 2 sur le serveur de VPN de couche 2 de NSX Edge

L’adresse 172.16.10.1 appartient à la passerelle Edge Gateway du serveur de VPN de couche 2 et les routes sont distribuées de manière dynamique via OSPF. Configurez ensuite le service de VPN de couche 2 sur cette passerelle Edge Gateway afin qu’Edge fasse office de serveur sur la connexion L2VPN.

 

 

Déployer le client VPN de couche 2 NSX Edge Gateway

Maintenant que le côté serveur du VPN de couche 2 est configuré, déployons une nouvelle passerelle NSX Edge Gateway qui fera office de client VPN de couche 2. Avant de déployer le client VPN de couche 2 de la passerelle NSX Edge Gateway, vous devez configurer les groupes de ports distribués de liaison montante et de trunk au niveau du commutateur virtuel distribué.

 

 

Configurer le client VPN de couche 2 sur NSX Edge Gateway

 

  1. Double-cliquez sur L2VPN-Client.

 

Création de ponts native


Grâce à la création de ponts logiciels de couche 2 intégrés dans le noyau de NSX, les organisations peuvent connecter de manière transparente les charges traditionnelles qui s’exécutent sur les VLAN legacy à des réseaux virtualisés en utilisant VXLAN. Les ponts de couche 2 sont couramment utilisés dans les environnements existants pour simplifier l’introduction de réseaux logiques, ou lorsque les systèmes physiques nécessitent une connectivité de couche 2 aux machines virtuelles s’exécutant sur un commutateur logique NSX.

Ce module vous guide le long des étapes de configuration d’une instance de pontage de couche 2 entre un VLAN traditionnel et un commutateur logique Access NSX.


 

Instructions spéciales concernant les commandes CLI

 

Pour une grande partie des modules, vous devez saisir des commandes d’interface de ligne de commande (CLI).  Pour envoyer des commandes CLI au laboratoire, vous avez deux possibilités.

Premièrement, pour envoyer une commande CLI à la console du laboratoire :

  1. Mettez la commande CLI en surbrillance dans le manuel et appuyez sur Ctrl + C pour la copier dans le Presse-papiers.
  2. Cliquez sur l’élément de menu de la console SEND TEXT.
  3. Appuyez sur Ctrl + V pour coller le contenu du Presse-papiers dans la fenêtre.
  4. Cliquez sur le bouton SEND.

Deuxièmement, un fichier texte placé sur le Bureau de l’environnement vous permet de copier et coller facilement des commandes ou mots de passe complexes dans les utilitaires associés (CMD, Putty, console, etc). Certains caractères sont souvent absents des claviers à travers le monde.  Ce fichier texte est aussi fourni pour les dispositions de clavier qui ne présentent pas ces caractères.

Le fichier texte s’appelle README.txt et est accessible sur le Bureau.  

 

 

Accéder à vSphere Web Client

 

  • Utilisez l’icône sur le Bureau intitulée Chrome pour ouvrir vSphere Web Client.

 

 

Vérifier la configuration initiale

 

Vérifions maintenant la configuration initiale comme décrit dans l’image ci-dessus. L’environnement de laboratoire comporte un groupe de ports nommé « Bridged-Net-RegionA01-vDS-MGMT » dans le cluster Management & Edge. Les VM du serveur Web, web-01a et web-02a, sont rattachées au commutateur logique Web-Tier-01. Ce dernier est isolé du réseau ponté.

 

 

Migrer Web-01a vers le cluster RegionA01-MGMT01

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur VMs and Templates.

 

 

Afficher les VM connectées

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking.

 

 

Migrer le commutateur logique Web_Tier_Logical_Switch sur le routeur logique distribué

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Network & Security.

 

 

Configurer le pontage de couche 2 NSX

 

Activons le pontage de couche 2 NSX entre le réseau VLAN 101 et le commutateur logique Web-Tier-01 afin de permettre à web-01a.corp.local de communiquer avec le reste du réseau. Cette configuration permet d’utiliser un pont de couche 2 et une interface de routeur logique distribué sur le même commutateur logique Web-Tier.

 

 

Vérifier le pontage de couche 2

Le pontage de couche 2 NSX est désormais configuré. Vous devez ensuite vérifier la connectivité de couche 2 entre la VM web-01a qui est associée au réseau VLAN 101 et la VM web-02a qui est associée au commutateur logique Web_Tier_Logical_Switch.

 

 

Nettoyage du pontage de couche 2 au niveau du module

Si vous souhaitez continuer avec d’autres modules de ce laboratoire d’essai en ligne, assurez-vous de suivre la procédure ci-dessous afin de supprimer le pontage de couche 2. En effet, la configuration utilisée dans cet environnement peut entrer en conflit avec d’autres sections (par exemple, L2VPN).

 

 

Migrer Web-01a vers le cluster RegionA01-COMP01

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur VMs and Templates.

 

Conclusion du module 4


Dans ce module, nous avons abordé les fonctionnalités avancées de la passerelle de services NSX Edge :

  1. nous avons déployé une nouvelle passerelle de services Edge (ESG), que nous avons configurée comme équilibreur de charge en mode « manchot » ;
  2. nous avons modifié et créé des règles de pare-feu au niveau de l’ESG existant ;
  3. nous avons configuré le relais DHCP via ESG ;
  4. nous avons configuré le VPN de couche 2 via ESG.

 

Vous avez terminé le module 4

Félicitations ! Vous avez terminé le module 4.

Si vous souhaitez en savoir plus sur le déploiement de NSX, rendez-vous dans le Centre de documentation NSX 6.4 via l’URL suivante :

Passez à n’importe lequel des modules suivants :

Liste des modules du laboratoire :

Responsables du laboratoire :

  • Modules 1 à 4 : Joe Collon, ingénieur système NSX, États-Unis

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Conclusion

Merci d’avoir participé aux laboratoires d’essai en ligne VMware. Visitez le site http://hol.vmware.com/ pour poursuivre ce laboratoire en ligne.

SKU du laboratoire: HOL-1903-01-NET

Version: 20181106-094615