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


Présentation du laboratoire en ligne - HOL-1925-01-NET - VMware NSX-v - Notions avancées - Consommation

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.

Dans ce laboratoire, les participants utiliseront l’API RESTful NSX pour exécuter les fonctions disponibles dans l’interface utilisateur et celles disponibles via l’API uniquement.  Ils examineront et configureront une solution NSX multisites.  Enfin, ils procèderont à la migration d’une pile d’applications entre deux sites.

Liste des modules du laboratoire :

 Responsable du laboratoire : 

  • Modules 1 à 5 : Brian Wilson, ingénieur système, États-Unis

 

Vous pouvez télécharger ce manuel de laboratoire depuis le site des documents de laboratoire d’essai en ligne accessible à l’adresse suivante :

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.  Vous devez effectuer toutes les tâches 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 allez être invité à saisir du texte dans la console principale. Outre la saisie directe au clavier, vous disposez de deux méthodes très utiles facilitant l’entrée des données complexes.

 

 

Vous pouvez cliquer sur un élément de texte dans le manuel de laboratoire pour le faire glisser dans la fenêtre de console active.

 
 

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éder 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 dans 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 la disposition de clavier US, 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 qui ne dispose pas d’un accès complet à 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.  

 

 

Observez 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 quelques minutes.  Si le laboratoire n’est toujours pas à l’état « Ready » au bout de 5 minutes, demandez de l’aide.

 

Topologie du laboratoire


Ce laboratoire se compose de deux sites distincts (appelés RegionA0 et RegionB0), chacun avec ses propres composants (instance vCenter, hôtes vSphere 6.5 dédiés, système de stockage et sous-réseaux). Les instances vCenter partagent un contrôleur PSC (Platform Services Controller) qui centralise la gestion des identités, la gestion des licences et l’interaction des applications entre les sites.

Le site Region A se compose de deux clusters :

Les deux clusters partagent un sous-réseau de gestion (192.168.110.0/24), ainsi qu’une instance vMotion (10.10.30.0/24) et un réseau de stockage IP (10.10.20.0/24).

Les réseaux dédiés aux VTEP NSX (points limites de tunnel VXLAN) varient en fonction du site. RegionA01 utilise 192.168.130.0/24. Les sous-réseaux VTEP sont routés ensemble par un routeur externe (vpodrouter).

Le site Region B se compose d’un seul cluster :

Region B dispose de son propre sous-réseau de gestion (192.168.210.0/24), ainsi que de réseaux séparés vMotion (10.20.30.0/24), de stockage IP (10.20.20.0/24) et VTEP (192.168.230.0/24).

Les réseaux de gestion, vMotion et VTEP sont routés entre les différents sites pour permettre une gestion commune, une migration Cross vCenter vMotion et une extensibilité du réseau (VXLAN).

Tous les réseaux VTEP sont configurés avec une unité de transmission maximale (MTU) de 1 600 octets pour permettre l’encapsulation du VXLAN.


 

Topologie de l’environnement virtuel

 

Le schéma illustre les hôtes vSphere et le placement des VM sur les différents clusters, ainsi que les commutateurs virtuels distribués (DVS). Les adresses IP VTEP associées aux hôtes s’affichent également.

Les clusters RegionA01-MGMT01 et RegionA01-COMP01 sont tous les deux gérés par l’instance vCenter Server A (vcsa-01a.corp.local) ; le cluster RegionB01-COMP01 est géré par l’instance vCenter Server B (vcsa-01b.corp.local). Les deux instances vCenter sont associées à un même contrôleur PSC (psc-01a.corp.local) qui réside dans le réseau de gestion du site Region A.

Dans le laboratoire, la configuration des zones de transport NSX est la suivante :

 

 

Topologie du réseau logique préconfigurée

 

Lorsque vous accédez au laboratoire pour la première fois, la topologie illustrée par le schéma suivant est déjà configurée. Cinq commutateurs logiques universels NSX sont configurés (Web_Tier_ULS, App_Tier_ULS, DB_Tier_ULS, RegionA01_Transit, RegionB01_Transit), ainsi qu’une application Web à 3 niveaux. Les commutateurs logiques sont rattachés à un routeur logique distribué universel (UDLR), lui-même associé à une passerelle de services Edge (ESG) NSX dans chaque région. Le routage dynamique BGP assure l’échange d’informations de routage entre les passerelles ESG et le routeur externe.

 

 

Topologie du réseau logique finale

 

Une fois les Modules 1,2,3 et 4 terminés, la topologie ci-dessous sera configurée dans le laboratoire :

 

Module 1 - API REST du Data Center VMware NSX (15 minutes)

API RESTful NSX


NSX est conçu dès le départ avec une API RESTful. Cette API peut être utilisée à la fois pour configurer NSX et pour provisionner les services du réseau logique NSX. Elle est appelée directement ou indirectement à partir de différents langages de programmation. Un grand nombre d’outils d’orchestration et d’automatisation, tels que vRealize Automation via vRealize Orchestrator, peuvent appeler l’API REST NSX pour exécuter l’orchestration et l’automatisation des réseaux des couches 2 à 7.

Pour illustrer les appels à l’API RESTful NSX, vous allez utiliser l’extension RESTClient associée au navigateur Mozilla Firefox. Débogueur dédié aux services Web RESTful, RESTClient est un outil précieux dans le cadre de l’utilisation de différentes API REST.

Dans ce module, vous allez effectuer les tâches suivantes :


 

Présentation des API REST

 

Une API REST (REpresentational State Transfer) définit un ensemble de principes simples appliqués librement dans la plupart des implémentations d’API.

REST exploite la puissance du protocole HTTP pour envoyer des données (en-têtes et corps) entre les clients et les serveurs.

Les identifiants URL (Uniform Resource Locator) et URI (Uniform Resource Identifier) peuvent être utilisés de manière interchangeable avec le transfert REST.

Les ressources (blocs constitutifs) sont reliées par des hyperliens intégrés dans les documents HTML ou références URI. Elles peuvent indiquer l’état via des représentations contenant à la fois des métadonnées (telles que la taille, le type de support ou l’ensemble de caractères) et du contenu (image binaire ou document texte).

 

 

Méthodes de requête REST

 

Les clients REST spécifient l’interaction souhaitée (message de requête HTTP tel que défini par la norme RFC 2616). Chaque méthode HTTP est associée à une sémantique spécifiquement définie selon le contexte d’un modèle de ressources d’API REST :

 

 

Codes d’état des réponses REST

 

Les API REST utilisent un message de réponse HTTP pour informer les clients du résultat de leur requête (conformément à la norme RFC 2616). Cinq catégories sont définies :

Message de réponse HTTP pour informer les clients du résultat de leur requête (conformément à la norme RFC 2616) :

 

 

En-têtes de requête HTTP pour l’API RESTful NSX

 

Voici une liste des principaux en-têtes de requête pour la configuration des API RESTful en vue du provisionnement des services NSX :

  1. Authorization : informations d’authentification (utilisateur et mot de passe) au format codé Base64.
  2. Content-Type : « application/xml ». Indique que le corps/la charge utile de la requête est au format xml.

 

 

Requêtes HTTP pour l’API RESTful NSX

 

  1. Method/Verb : GET/PUT/POST/DELETE : action sur la ressource.
  2. URL : ressource.
  3. Headers : Authorization et Content-Type.
  4. Body : charge utile XML.
  5. Status Code : 2xx pour Succès et 4xx et 5xx pour Échecs.

 

Présentation des cmdlests REST PowerShell


PowerShell inclut un client REST.  Voici une présentation du cmdlet Invoke-RestMethod.


 

Invoke-RestMethod

Le cmdlet PowerShell Invoke-RestMethod permet à un utilisateur d’accéder aux API RESTfull.  Ce cmdlet contient toutes les méthodes et options requises pour interagir avec NSX API.  Voici la syntaxe correspondant à la méthode.

Invoke-RestMethod [-Uri] <Uri> [-Body <Object> ] [-Certificate <X509Certificate> ] [-CertificateThumbprint <String> ] [-ContentType <String> ] [-Credential <PSCredential> ] [-DisableKeepAlive] [-Headers <IDictionary> ] [-InFile <String> ] [-MaximumRedirection <Int32> ] [-Method <WebRequestMethod> {Default | Get | Head | Post | Put | Delete | Trace | Options | Merge | Patch} ] [-OutFile <String> ] [-PassThru] [-Proxy <Uri> ] [-ProxyCredential <PSCredential> ] [-ProxyUseDefaultCredentials] [-SessionVariable <String> ] [-TimeoutSec <Int32> ] [-TransferEncoding <String> {chunked | compress | deflate | gzip | identity} ] [-UseBasicParsing] [-UseDefaultCredentials] [-UserAgent <String> ] [-WebSession <WebRequestSession> ] [ <CommonParameters>]

 

 

Accéder à vSphere Web Client

 

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

 

 

Réduire vSphere Web Client

 

  1. Réduisez vSphere Web Client.

 

 

Ouvrir l’exemple de script PowerShell

 

Ouvrez le fichier « REST Example.ps1 » dans le dossier API Module sur le bureau à l’aide de Notepad++.

  1. Double-cliquez sur le dossier API Module.
  2. Cliquez avec le bouton droit sur « REST Example.ps1 ».
  3. Sélectionnez Edit with Notepad++.

 

 

Vérifier le script

 

Ce script PowerShell va créer un commutateur logique.

  1. Initialisation du script.
  2. Définit les détails du commutateur logique.
  3. Appelle NSX Manager pour créer le commutateur logique.  

Notez l’utilisation de la requête Invoke-WebRequest à la place de la méthode Invoke-RestMethod.  Cette procédure a été exécutée pour valider les en-têtes HTTP après retour de l’appel.

 

 

Exécuter l’exemple de script

 

  1. Cliquez avec le bouton droit sur REST Example.ps1.
  2. Sélectionnez Run With PowerShell.
  3. Examinez le résultat.

 

 

Retourner à vSphere Web Client

 

 

  1. Dans Chrome, cliquez sur vSphere Web Client.

 

 

Accéder à l’onglet Networking & Security.

 

  1. Cliquez sur le bouton Home.
  2. Sélectionnez Networking & Security.

 

 

Vérifier la création du commutateur logique

 

  1. Cliquez sur Logical Switches.
  2. Vérifiez que le commutateur RestSwitch1 a bien été créé.

Notez que l’ID de segment et le numéro virtualwire peuvent être différents.

 

 

Retirer le commutateur RestSwitch1

 

  1. Cliquez avec le bouton droit sur RestSwitch1.
  2. Cliquez sur Remove.
  3. Cliquez sur Yes.

 

Créer plusieurs commutateurs logiques


Dans cette leçon, un script powershell va créer plusieurs commutateurs logiques via NSX API.


 

Ouvrir l’exemple de script

 

  1. Sur le bureau, double-cliquez sur le dossier API Module.
  2. Sur le bureau, cliquez avec le bouton droit sur le fichier Create Switches.ps1.
  3. Sélectionnez Open with Notepad++.

 

 

Examiner le script

 

Ce script s’appuie sur le précédent et utilise un ensemble de noms de commutateur pour créer plusieurs commutateurs.

  1. Définit l’ensemble $switches qui contient trois noms de commutateur : Web, App et DB.
  2. Exécute une boucle sur chaque valeur de l’ensemble $switches.  
  3. Le nom du commutateur est ajouté au corps de la requête à chaque boucle.

 

 

Exécuter le script Create Switches

 

  1. Cliquez avec le bouton droit sur le fichier Create Switches.ps1.
  2. Cliquez sur Run With PowerShell.

 

 

Examiner le résultat

 

Les commutateurs logiques Web, App et DB ont été créés et affectés aux ID virtualwire disponibles.  Les ID du laboratoire peuvent être différents.

Appuyez sur n’importe quelle touche pour continuer.

 

 

Retourner à vSphere Web Client

 

  1. Cliquez sur l’icône d’actualisation.
  2. Vérifiez que le commutateur App a bien été créé.
  3. Vérifiez que le commutateur DB a bien été créé.
  4. Vérifiez que le commutateur Web a bien été créé.

 

Créer un routeur distribué


Dans cette leçon, un script powershell va créer un routeur distribué via NSX API.


 

Ouvrir le script Create DLR

 

  1. Retournez au dossier API Module.
  2. Cliquez avec le bouton droit sur le fichier Create DLR.ps1.
  3. Cliquez sur Edit with Notepad++.

 

 

Examiner le script

 

  1. Examinez les champs requis pour un routeur distribué.
  2. Notez l’emplacement de l’URI.

 

 

Exécuter le script Create DLR.ps1

 

  1. Cliquez avec le bouton droit sur le fichier Create DLR.ps1.
  2. Cliquez sur Run With PowerShell.

Notez que l’exécution du script peut prendre entre 1 et 3 minutes.

Examinez le résultat.

Appuyez sur n’importe quelle touche pour fermer la fenêtre.

 

 

Examiner le routeur logique distribué dans vSphere Web Client

 

Retourner à vSphere Web Client

  1. Cliquez sur l’onglet NSX Edges.
  2. Vérifiez que le commutateur Distributed-Router a bien été créé.

Notez que les numéros Edge peuvent être différents dans votre laboratoire !

 

Configurer un seuil d’alarme pour le nombre de connexions par seconde au pare-feu distribué


Dans cette leçon, un script powershell va configurer des alarmes pour le nombre de connexions par seconde au pare-feu distribué.  Cette Configuration est disponible uniquement via l’API


 

Ouvrir le script DFW CPS.ps1

 

  1. Retournez au dossier API Module.
  2. Cliquez avec le bouton droit sur le fichier DFW CPS.ps1.
  3. Cliquez sur Edit with Notepad++.

 

 

Examiner le script

 

  1. Examinez les seuils d’alarme.
  2. Notez l’URI.

 

 

Exécuter le script DFW CPS

 

  1. Sur le bureau, cliquez avec le bouton droit sur le fichier DFW CPS.ps1.
  2. Cliquez sur Run With PowerShell.

Examinez le résultat du script.  Le pare-feu distribué générera désormais une alarme lorsque le nombre de connexions par seconde dépassera 10.

 

Restaurer l’environnement du laboratoire à l’issue du module


Une fois ce laboratoire terminé, les objets créés par l’API doivent être supprimés.


 

Supprimer les commutateurs logiques

 

Attention : supprimez uniquement les commutateurs logiques créés à l’aide de l’API.

Retourner à vSphere Web Client :

  1. Accédez à l’onglet Logical Switches.
  2. Cliquez sur le commutateur logique App.
  3. Cliquez sur Remove.
  4. Cliquez sur Yes.

Répétez la procédure pour les commutateurs logiques DB et Web.

 

 

Supprimer le routeur distribué

 

  1. Accédez à l’onglet NSX Edges.
  2. Cliquez sur Distributed-Router.
  3. Cliquez sur Delete.
  4. Cliquez sur Yes.

 

Conclusion du Module 1


Dans ce module, vous avez utilisé NSX API pour configurer plusieurs objets NSX.  NSX API fournit un outil puissant pour la configuration, le dépannage et la surveillance.  


 

Vous avez terminé le Module 1.

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

Pour plus d’informations sur NSX API, visitez la page ci-dessous et sélectionnez le guide NSX API:

Le guide sur l’API est également disponible sur le Bureau de la console principale.  Des informations supplémentaires sur Postman Rest Client sont aussi disponibles sur le Bureau de la console principale.  Des exemples supplémentaires de configuration de composants comme le routage et le pare-feu sont disponibles sur le Bureau dans le fichier Fast-Forward.ps1 qui sera utilisé plus loin dans ce laboratoire pour passer le Module 3.  

Passez à n’importe lequel des modules suivants ou terminez le laboratoire.

 Responsable du laboratoire :

  • Modules 1 à 5 : Brian Wilson, ingénieur système, États-Unis

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 2 - Examiner la solution multisites préconfigurée (30 minutes)

Instructions concernant le déroulement du module


Dans ce module, vous allez examiner les configurations de vSphere et NSX.  Ce laboratoire inclut de nombreuses configurations et de nombreux objets universels requis pour une configuration multisites en mode actif/actif.

Les configurations examinées sont les suivantes :

  • vCenter Enhanced Linked Mode.
  • Instances NSX Manager
  • Cluster de contrôleurs universels
  • Préparation du réseau logique
  • Préparation du réseau logique universel
  • Commutateurs logiques universels
  • Passerelles NSX Edge

 

Topologie préconfigurée

 

Le schéma topologique ci-dessus présente les objets préconfigurés dans ce laboratoire.

 

Examiner les configurations vCenter


Dans ce laboratoire, les deux instances vCenter Server ont été configurées en mode Enhanced Linked Mode.  Ces deux instances peuvent ainsi être gérées via la même session vSphere Web Client.  En mode Enhanced Linked Mode, les deux environnements NSX peuvent aussi être configurés dans la même session vSphere Web Client.  


 

Sélectionner Hosts and Clusters

 

  1. Cliquez sur le bouton Home.
  2. Cliquez sur Hosts and Clusters.

 

 

Vérifier la disponibilité des deux instances vCenter Server

 

Vérifiez que les deux instances vCenter Server s’affichent.

 

Examiner les configurations NSX Manager


Dans cette leçon, vous allez examiner les rôles affectés à NSX Manager.  L’instance NSX Manager enregistrée sur le site Region A aura le rôle principal.  L’instance NSX Manager enregistrée sur le site Region B aura le rôle secondaire.


 

Accéder à l’onglet Networking & Security.

 

  1. Cliquez sur le bouton Home.
  2. Sélectionnez Networking & Security.

 

 

Accéder à l’onglet Installation

 

Cliquez sur l’onglet Installation and Upgrade.

 

 

Vérifier les rôles NSX Manager

 

Dans ce laboratoire, deux instances NSX Manager ont été configurées.  Une instance Primary et une instance Secondary.  Vérifiez que les deux instances NSX Manager sont affectées à un rôle.

 

Examiner le cluster de contrôleurs universels


Dans cette leçon, vous allez examiner le cluster de contrôleurs universels NSX.  Le cluster de contrôleurs universels NSX gère le réseau logique entre les deux instances vCenter Server.  Il permet de configurer les commutateurs logiques universels, les routeurs logiques universels et les règles de pare-feu distribué universel.


 

Vérifier les contrôleurs sur l’instance NSX Manager principale

 

  1. Cliquez sur NSX Controller Nodes.

Vérifiez que controller-1 est connecté à l’instance NSX Manager principale.

Remarque : avec VMware NSX, il est recommandé de toujours disposer de trois contrôleurs dans un cluster de contrôleurs. Or, en raison de contraintes liées aux ressources de l’environnement du pod, nous n’avons déployé qu’un seul contrôleur. Cela n’affecte en rien la fonctionnalité du laboratoire.

 

 

Vérifier les contrôleurs sur l’instance NSX Manager secondaire

 

Vérifiez que controller-1 est connecté à l’instance NSX Manager secondaire.

Remarque : avec VMware NSX, il est recommandé de toujours disposer de trois contrôleurs dans un cluster de contrôleurs. Or, en raison de contraintes liées aux ressources de l’environnement du pod, nous n’avons déployé qu’un seul contrôleur. Cela n’affecte en rien la fonctionnalité du laboratoire.

 

Examiner la préparation du réseau logique universel


Dans cette leçon, vous allez examiner la préparation du réseau logique préconfiguré.


 

Examiner le pool d’ID de segments universels sur l’instance NSX Manager principale

 

Avant de configurer les commutateurs logiques universels, vous devez créer un pool d’ID de segments.  Ce pool d’ID de segments universels doit contenir une plage distincte des autres pools d’ID de segments utilisés sur les instances NSX Manager dans un environnement Cross vCenter.

  1. Sélectionnez Logical Network Settings.
  2. Sélectionnez l’instance NSX Manager Primary.
  3. Sélectionnez VXLAN Settings.
  4. Vérifiez le champ Segment ID pool.
  5. Notez la différence par rapport à la plage affichée dans le champ Universal Segment ID pool.

 

 

Remplacer l’instance NSX Manager principale par l’instance secondaire

 

Remplacez l’instance NSX Manager principale par l’instance secondaire comme suit :

  1. Cliquez sur le menu déroulant NSX Manager.
  2. Sélectionnez l’instance NSX Manager Secondary.

 

 

Examiner le pool d’ID de segments universels sur l’instance NSX Manager secondaire

 

L’instance NSX Manager secondaire doit aussi être configurée avec un pool d’ID de segments.  Les pools d’ID de segments configurés sur toutes les instances NSX Manager ne doivent pas se chevaucher. Le pool d’ID de segments universels est synchronisé avec l’instance NSX Manager principale :

  1. Vérifiez que le pool spécifié dans le champ Segment ID pool de l’instance NSX Manager secondaire ne chevauche pas celui spécifié dans le champ Segment ID pool de l’instance NSX Manager principale.
  2. Vérifiez que le champ Universal Segment ID pool est synchronisé.

 

 

Examiner les zones de transport universelles

 

Les zones de transport déterminent les clusters qui pourront utiliser un réseau logique.  Les zones de transport globales sont limitées à une seule instance vCenter Server.  Les zones de transport universelles peuvent englober plusieurs instances vCenter Server.  Vérifiez les clusters connectés à la zone de transport universelle :

  1. Sélectionnez Transport Zones.
  2. Cliquez sur le bouton radio en regard de Universal_TZ.
  3. Cliquez sur Connect Clusters.

 

 

Examiner les clusters connectés aux zones de transport universelles

 

Les zones de transport déterminent les clusters qui pourront utiliser un réseau logique.  Les zones de transport globales sont limitées à une seule instance vCenter Server.  Les zones de transport universelles peuvent englober plusieurs instances vCenter Server.  Vérifiez les clusters connectés à la zone de transport universelle :

  1. Vérifiez que le cluster RegionB01-COMP01 est connecté et que son état est Normal.
  2. Cliquez sur Cancel.

Passez à l’instance NSX Manager Primary et vérifiez la configuration de la zone Universal_TZ.  Vérifiez que les clusters RegionA01-COMP01 et RegionA01-MGMT01 sont connectés et que leur état est Normal.

 

Examiner les commutateurs logiques universels


Dans cette leçon, vous allez examiner les commutateurs logiques universels préconfigurés.


 

Vérifier les commutateurs logiques universels sur l’instance NSX Manager principale

 

Les commutateurs logiques universels sont configurés sur le même onglet que les commutateurs logiques globaux.  Vérifiez les cinq commutateurs logiques universels préconfigurés :

  1. Cliquez sur l’onglet Logical Switches.
  2. Sélectionnez l’instance NSX Manager Primary.
  3. Vérifiez que les cinq commutateurs logiques sont configurés avec une portée universelle.

Les champs Segment ID des commutateurs logiques universels font partie de la plage du pool d’ID de segments universels.

 

 

Vérifier les commutateurs logiques universels sur l’instance NSX Manager secondaire

 

Une fois configurés, les commutateurs logiques universels sont synchronisés avec toutes les instances NSX Manager secondaires.  Vérifiez que tous les commutateurs sont disponibles sur l’instance NSX Manager secondaire et que leurs ID de segments correspondent à ceux de l’instance NSX Manager principale :

  1. Sélectionnez l’instance NSX Manager Secondary.
  2. Vérifiez que les commutateurs logiques universels correspondent à la configuration de l’instance NSX Manager principale.

Les champs Name, Transport Zone et Segment ID sont synchronisés sur toutes les instances NSX Manager.

 

 

Créer un commutateur logique universel

 

Les commutateurs logiques universels sont configurables uniquement sur l’instance NSX Manager principale.  Créez un commutateur logique universel sur l’instance NSX Manager principale :

  • Sélectionnez l’instance NSX Manager Primary.
  • Cliquez sur l’icône Add Logical Switch.

 

 

Vérifier le commutateur logique universel nouvellement créé

 

Vérifiez que le commutateur logique universel NSX_ULS a bien été créé, se trouve dans la zone de transport Universal_TZ et est configuré avec un ID de segment compris dans le pool d’ID de segments universels.  Passez à l’instance NSX Manager secondaire et vérifiez que le commutateur logique universel a été synchronisé :

  1. Sélectionnez l’instance NSX Manager Primary.
  2. Vérifiez le commutateur NSX_ULS.

 

 

Vérifier le commutateur logique universel nouvellement créé sur l’instance NSX Manager secondaire

 

Vérifiez que le commutateur logique universel NSX_ULS a été synchronisé sur l’instance NSX Manager secondaire.  

  1. Sélectionnez l’instance NSX Manager Secondary.
  2. Vérifiez le commutateur NSX_ULS.

 

Examiner les configurations NSX Edge


Dans ce laboratoire, les terminaux NSX Edge (ESG) fournissent la connectivité pour les communications nord-sud, mais aussi est-ouest.  Deux appareils NSX Edge sont préconfigurés pour la communication nord-sud.  Ces passerelles de périmètre sont configurées avec le routage dynamique basé sur le protocole BGP.  Les passerelles de périmètre utilisent le cheminement multiple à coût égal (ECMP, equal-cost-multipath) pour autoriser le trafic entrant et sortant sur les deux sites.  Une troisième passerelle ESG a été préconfigurée en tant que routeur logique distribué universel (ULDR).  Ce routeur a été configuré pour le cheminement ECMP et le trafic sortant local.


 

Trafic sortant local

 

Le trafic sortant local permet d’optimiser la sortie en fonction du site.  Le trafic est acheminé via la passerelle ESG sur le site d’origine.  Le trafic est-ouest utilise le routeur ULDR pour assurer l’optimisation entre les VM.  Cette configuration exige un routage dynamique entre le réseau physique et les passerelles ESG, ainsi qu’entre les passerelles ESG et le routeur ULDR.  Ce dernier annonce le réseau configuré aux deux passerelles ESG.  Ces dernières annoncent les réseaux du routeur ULDR au réseau physique des deux sites.  Cette configuration permet au réseau physique de transmettre et recevoir du trafic vers et depuis le même réseau sur les deux sites.

  1. Le trafic issu des VM du site RegionA0 est émis à partir du réseau logique via la passerelle ESG RegionA0.
  2. Le trafic issu des VM du site RegionB0 est émis à partir du réseau logique via la passerelle ESG RegionB0.
  3. Le trafic entre les VM utilise le routeur ULDR pour l’optimisation est-ouest.

 

 

Examiner les configurations de passerelle de périmètre

 

Pour consulter la configuration de la passerelle ESG RegionA0_Perimeter_GW :

  1. Accédez à l’onglet NSX Edges.
  2. Vérifiez que l’instance NSX Manager Primary est sélectionnée.
  3. Double-cliquez sur la passerelle ESG RegionA0_Perimeter_GW.

 

 

Examiner la configuration du routeur logique distribué universel

 

  1. Vérifiez que l’instance NSX Manager Primary est sélectionnée.
  2. Double-cliquez sur Universal_DLR_01.

 

Conclusion du Module 2


Dans ce module, vous avez examiné les objets universels préconfigurés.  Ces éléments ont été préconfigurés pour vous permettre de vous concentrer sur la configuration des blocs du routage universel du Module 3.


 

Vous avez terminé le Module 2.

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

Pour plus d’informations sur les configurations universelles NSX, visitez le site ci-dessous et sélectionnez le guide Cross-vCenter Installation :

Passez à n’importe lequel des modules suivants.

 Responsable du laboratoire :

  • Modules 1 à 5 : Brian Wilson, ingénieur système, États-Unis

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 3 - Création de blocs universels (30 minutes)

Instructions concernant le déroulement du module


Dans ce module, vous allez configurer le protocole BGP sur le routeur logique distribué universel (Universal Logical Distributed Router ou ULDR), ainsi que des règles de pare-feu distribué universel.

Voici les étapes de ce module :

  • Activation du protocole BGP sur le routeur ULDR du site RegionA
  • Activation du protocole BGP sur le routeur ULDR du site RegionB
  • Vérification de la connectivité des applications
  • Création de règles de pare-feu distribué universel

 

Topologie préconfigurée

 

Le laboratoire est préconfiguré avec la topologie de réseau virtuel présentée ci-dessus.  Les VM de passerelle de périmètre sont déjà configurées pour l’échange d’informations de routage avec le routeur vPod.

 

 

Configuration finale

 

À la fin de ce module, le protocole BGP sera configuré pour échanger des informations sur le routage dynamique entre les passerelles de périmètre et le routeur logique distribué universel.  L’optimisation du trafic sortant sera configurée de sorte de garantir que ce trafic issu de l’environnement de réseau logique utilise la passerelle de périmètre la plus proche de la VM.  Des règles de pare-feu distribué universel seront configurées pour activer la micro-segmentation de l’application à trois niveaux fournie dans le laboratoire.

 

Activer le protocole BGP sur le routeur logique universel du site RegionA0


Dans ce module, vous allez configurer le routeur logique distribué universel pour le routage dynamique, ainsi que le pare-feu distribué universel pour la micro-segmentation d’une application à trois niveaux.


 

Afficher l’ID de paramètres régionaux pour RegionA0

 

L’ID de paramètres régionaux est configuré par cluster.  Il permet au routeur ULDR de baser ses décisions de routage en fonction du site.

 

 

Configurer le routeur ULDR pour le routage dynamique

 

Pour configurer le routeur Universal_DLR :

  1. Accédez à l’onglet NSX Edges.
  2. Vérifiez que l’instance NSX Manager Primary est sélectionnée.
  3. Double-cliquez sur Universal_DLR_01.

 

 

Configurer le routeur ULDR pour le protocole BGP

 

Le protocole BGP doit être activé et la passerelle RegionA0_Perimeter_GW ajoutée en tant que voisin :

  1. Cliquez sur BGP.
  2. Sous BGP Configuration, cliquez sur Edit.

 

Activer le protocole BGP sur le routeur logique universel du site RegionB0


Dans cette leçon, vous allez configurer le routeur logique distribué universel du site RegionB0.


 

Afficher l’ID de paramètres régionaux

 

L’ID de paramètres régionaux est configuré par cluster.  Il permet au routeur ULDR de baser ses décisions de routage en fonction du site.

 

 

Configurer le routeur ULDR pour le routage dynamique

 

Pour consulter la configuration du routeur ULDR RegionB0 :

  1. Accédez à l’onglet NSX Edges.
  2. Vérifiez que l’instance NSX Manager Secondary est sélectionnée.
  3. Double-cliquez sur Universal_DLR_01.

 

 

Configurer le routeur ULDR pour le protocole BGP

 

Le protocole BGP doit être activé et la passerelle RegionB0_Perimeter_GW ajoutée en tant que voisin :

  1. Cliquez sur BGP.
  2. Sous BGP Configuration, cliquez sur Edit.

 

Vérifier la connectivité des applications


Dans cette leçon, vous allez vérifier le bon fonctionnement de l’application à trois niveaux dans RegionA0.


 

Ouvrir un nouvel onglet

 

Cliquez sur le bouton d’ouverture d’un nouvel onglet.

 

 

Ouvrir l’application à trois niveaux

 

Cliquez sur le favori webapp.corp.local.

 

 

Vérifier l’application à trois niveaux

 

Vérifiez que la page de l’application n-tiers du laboratoire d’essai en ligne s’affiche avec des données.  

 

 

Exécuter une commande ping sur les machines virtuelles de l’application

 

Ouvrez une invite de commande dans la console principale.

 

Créer des règles de pare-feu distribué universel


Dans cette leçon, vous allez créer des règles de pare-feu distribué universel pour l’application à trois niveaux fournie dans le laboratoire.  Les règles de pare-feu distribué universel ne doivent contenir que des adresses IP, des ensembles d’adresses IP, des adresses MAC ou des ensembles d’adresses MAC.


 

Accéder à vSphere Web Client

 

Ouvrez l’onglet vSphere Web Client.

 

 

Accéder à l’onglet Networking & Security.

 

  1. Cliquez sur le bouton Home.
  2. Sélectionnez Networking & Security.

 

 

Accéder à l’onglet Firewall

 

Cliquez sur l’onglet Firewall.

 

 

Vérifier que l’instance NSX Manager Primary est sélectionnée

 

Pour pouvoir créer des règles de pare-feu distribué universel, l’instance NSX Manager Primary doit être sélectionnée.  Toutes les règles sélectionnées pour la synchronisation universelle doivent être distribuées automatiquement aux instances NSX Manager secondaires.

 

 

Ajouter une section à l’ensemble de règles de pare-feu

 

Cliquez sur le bouton Add Section.

 

 

Créer une section

 

  1. Nommez la section « Three Tier App ».
  2. Activez l’option Turn on Universal Synchronization pour cette nouvelle section.
  3. Cliquez sur Add.

 

 

Ajouter une règle universelle

 

  1. Cochez la case en regard de la section Three Tier App.
  2. Cliquez sur l’icône Add Rule.

 

 

Configurer une règle universelle par défaut

 

Au cours de cette étape, vous allez configurer une règle universelle par défaut.  Cette règle sera modifiée en règle de refus par défaut une fois toutes les règles de l’application définies.  

  1. Vérifiez que la section Three Tier App est développée.
  2. Cliquez sur Enter rule name.

 

 

Configurer une règle d’accès au serveur Web

 

Cliquez sur le bouton Add Rule.

 

 

Configurer une règle d’accès entre les serveurs Web et d’application

 

Au cours de cette étape, vous allez configurer une règle autorisant l’accès au niveau application à partir du niveau Web sur Tomcat :

  1. Vérifiez que la section Three Tier App est développée.
  2. Cliquez sur l’icône Add Rule.
  3. Cliquez sur le champ Enter rule name pour nommer la règle.

 

 

Configurer une règle d’accès entre les serveurs d’application et de base de données

 

Au cours de cette étape, vous allez configurer une règle autorisant l’accès au niveau base de données à partir du niveau application sur MySQL :

  1. Vérifiez que la section Three Tier App est développée.
  2. Cliquez sur l’icône Add Rule.
  3. Cliquez sur le champ Enter rule name pour nommer la règle.

 

 

Configurer la règle de refus

 

Cliquez sur l’icône Edit dans la colonne Action.

 

 

Publier les modifications

 

Pour publier les règles de pare-feu distribué, cliquez sur Publish Changes.  Aucune règle ne sera appliquée avant la publication des changements.

 

 

Vérifier la connectivité de l’application

 

Cliquez sur le bouton d’ouverture d’un nouvel onglet.

 

 

Exécuter une commande ping sur les machines virtuelles de l’application

 

Pour vérifier la règle de refus, ouvrez une invite de commande sur la console principale.

 

Conclusion du Module 3


Dans ce module, vous avez configuré le routage dynamique et le trafic sortant local pour le routeur logique distribué universel sur les deux sites.  Cette configuration autorise les configurations de Data Center virtuel en mode actif/actif.


 

Vous avez terminé le Module 3.

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

Pour plus d’informations sur les configurations universelles NSX, visitez le site ci-dessous et sélectionnez le guide Cross-vCenter Installation :

Passez à n’importe lequel des modules suivants.

 Responsable du laboratoire :

  • Modules 1 à 5 : Brian Wilson, ingénieur système, États-Unis

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 4 - Multisites actif/actif (15 minutes)

Instructions concernant le déroulement du module


Dans ce module, vous allez effectuer une migration vMotion d’une pile d’applications vers un site secondaire.  

Ce module inclut :

  • Migration Cross vCenter vMotion
  • Vérification du trafic sortant local

Si vous n’avez pas encore suivi le Module 3, configurez l’environnement conformément à la procédure ci-dessous.  Si vous avez déjà suivi le Module 3, passez à la leçon suivante :


 

Topologie du laboratoire

 

Dans ce module, vous allez utiliser la topologie de réseau logique présentée ci-dessus.  Vous allez exécuter une migration vMotion de toutes les VM associées à l’application à trois niveaux vers un site secondaire.  Vous allez vérifier la sortie locale du trafic et la disponibilité de l’application.

 

 

Réduire vSphere Web Client

 

  1. Réduisez vSphere Web Client.

 

 

Exécuter le script d’avance rapide

 

  1. Sur le Bureau, double-cliquez sur le fichier Fast-Forward.ps1.
  2. Sélectionnez Run with PowerShell.

Ce script va permettre de configurer l’environnement avec les prérequis du Module 4.  Attentez la fin de l’exécution.  La fenêtre se ferme une fois l’opération terminée.

 

 

Retourner à vSphere Web Client

 

  1.  Dans Chrome, cliquez sur vSphere Web Client.

 

Vérifier le trafic sortant local


Dans cette leçon, vous allez vérifier le fonctionnement du trafic sortant local.


 

Se connecter au routeur vPod

 

Lancez PuTTY.

 

 

Établir une connexion avec le routeur vPod

 

  1. Dans le champ Saved Session, sélectionnez vPod Router BGP.
  2. Cliquez sur Open.

 

 

Se connecter

 

  1. Saisissez le mot de passe VMware1!.

 

 

Vérifier la table de routage

 

Affichez la table de routage.  Vérifiez qu’il existe deux itinéraires actifs par réseau de VM :

  1. Saisissez :
show ip bgp
  1. Vérifiez les itinéraires.
  2. Une fois l’opération terminée, fermez la session ssh.

 

 

Accéder à vSphere Web Client et sélectionner Hosts and Clusters

 

  1. Cliquez sur le bouton Home.
  2. Cliquez sur Hosts and Clusters.

 

 

Vérifier l’emplacement de l’application

 

Vérifiez que les VM web-01a.corp.local,web-02a.corp.local, app-01a.corp.local et db-01a.corp.local figurent bien dans le Data Center RegionA01.

 

 

Accéder à l’onglet Networking & Security.

 

  1. Cliquez sur le bouton Home.
  2. Sélectionnez Networking & Security.

 

 

Désactiver la règle de refus universelle

 

  1. Cliquez sur l’onglet Firewall.
  2. Vérifiez que l’instance NSX Manager Primary est sélectionnée.
  3. Vérifiez que la section Three Tier App est développée.
  4. Cliquez sur le bouton bascule vert pour désactiver la règle 4.
  5. Cliquez sur Publish.

 

 

Attendre la fin de la publication de la règle de pare-feu

 

Attendez que l’opération de publication se termine.

 

 

Se connecter à web-01a.corp.local

 

Lancez PuTTY.

 

 

Établir une connexion avec web-01a.corp.local

 

  1. Dans le champ Saved Session, sélectionnez web-01a.corp.local.
  2. Cliquez sur Open.

 

 

Commande tracepath pour vérifier le trafic sortant local

 

  1. Exécutez la commande tracepath suivante sur le routeur vPod :
tracepath 192.168.100.1 -m2 -n
  1. Observez le trafic sortant via 192.168.5.1.  Il s’agit de l’interface de la passerelle RegionA01-Perimeter_GW.

 

 

Exécuter une migration vMotion de la VM Web vers RegionB0

 

  1. Cliquez sur le bouton Home.
  2. Cliquez sur Hosts and Clusters.

 

 

Développer tous les éléments réduits

 

Développez tous les éléments réduits en cliquant sur la flèche vers le bas.

 

 

Exécuter une migration vMotion de la VM Web

 

  1. Cliquez avec le bouton droit sur web-01a.corp.local.
  2. Cliquez sur Migrate.

 

 

Sélectionner le type de migration

 

  1. Sélectionnez l’option Change both computer resource and storage.
  2. Cliquez sur Select compute resource first.
  3. Cliquez sur Next.

 

 

Sélectionner une ressource de calcul

 

  1. Sélectionnez le cluster RegionB01-COMP01. Sélectionnez l’hôte esx-02b.corp.local.
  2. Cliquez sur Next.

 

 

Sélectionner un système de stockage

 

  1. Sélectionnez RegionB01-ISCSI01-COMP01.
  2. Cliquez sur Next.

 

 

Sélectionner un dossier

 

  1. Cliquez sur Discovered virtual machine.
  2. Cliquez sur Next.

 

 

 

Sélectionner un réseau

 

  1. Sélectionnez le commutateur universalwire Web_Tier_ULS.
  2. Cliquez sur Next.

Vous devrez peut-être faire défiler la liste de sélection du réseau vers la droite pour afficher le nom complet des commutateurs logiques universels.

 

 

Sélectionner la priorité vMotion

 

Cliquez sur Next.

 

 

Vérifier les paramètres

 

Vérifiez les sélections et cliquez sur Finish.

 

 

Passer à la vue Tasks

 

  1. Cliquez sur le bouton Home.
  2. Cliquez sur l’onglet Tasks.

 

 

Attendre que la migration vMotion se termine

 

Attendez que les tâches de migration se terminent.

 

 

Accéder à vSphere Web Client et sélectionner Hosts and Clusters

 

  1. Cliquez sur le bouton Home.
  2. Cliquez sur Hosts and Clusters.

 

 

Lancer la console Web-01a

 

Établissez une connexion avec la console Web-01a.

  1. Sélectionnez web-01a.corp.local.
  2. Cliquez sur l’onglet Summary.
  3. Sélectionnez la zone de l’écran sur laquelle lancer la console.

 

 

Exécuter une commande tracepath pour vérifier le nouveau trafic sortant

 

Utilisez la console pour vérifier le trafic sortant local :

  1. Pour Login, saisissez root
  2. Pour Password, saisissez VMware1!
tracepath 192.168.100.1 -n -m 2

Vérifiez le trafic sortant via 192.168.5.9. Il s’agit de l’interface de la passerelle RegionB01-Perimeter_GW.

 

Migrer la pile d’applications vers le site secondaire


Dans cette leçon, vous allez migrer une pile d’applications vers un site secondaire.


 

Vérification de la topologie de l’application

 

Ce diagramme présente les emplacements des machines virtuelles, ainsi que le flux du trafic.

 

 

Ouvrir un nouvel onglet

 

Cliquez sur le bouton d’ouverture d’un nouvel onglet.

 

 

Ouvrir l’application à trois niveaux

 

Cliquez sur le favori webapp.corp.local.

 

 

Vérifier l’application à trois niveaux

 

Vérifiez que la page de l’application n-tiers du laboratoire d’essai en ligne s’affiche avec des données.

 

 

Exécuter une migration vMotion des VM d’application restantes vers RegionB0

 

  1. Cliquez sur le bouton Home.
  2. Cliquez sur Hosts and Clusters.

 

 

Développer tous les éléments réduits

 

Développez tous les éléments réduits en cliquant sur la flèche vers le bas.

 

 

Exécuter une migration vMotion de la VM App

 

  1. Cliquez avec le bouton droit sur app-01a.corp.local.
  2. Cliquez sur Migrate.

 

 

Sélectionner le type de migration

 

  1. Sélectionnez Change both compute resource and storage.
  2. Cliquez sur Select compute resource first.
  3. Cliquez sur Next.

 

 

Sélectionner une ressource de calcul

 

  1. Sélectionnez le cluster RegionB01-COMP01.
  2. Cliquez sur Next.

 

 

Sélectionner un système de stockage

 

  1. Sélectionnez RegionB01-ISCSI01-COMP01.
  2. Cliquez sur Next.

 

 

Sélectionner un dossier

 

  1. Cliquez sur ULSDiscovered virtual machine.
  2. Cliquez sur Next.

Vous devrez peut-être faire défiler la liste de sélection du réseau vers la droite pour afficher le nom complet des commutateurs logiques universels.

 

 

Sélectionner un réseau

 

  1. Sélectionnez le commutateur universalwire App_Tier_ULS.
  2. Cliquez sur Next.

Vous devrez peut-être faire défiler la liste de sélection du réseau vers la droite pour afficher le nom complet des commutateurs logiques universels.

 

 

Sélectionner la priorité vMotion

 

Cliquez sur Next.

 

 

Vérifier les paramètres

 

Vérifiez les sélections et cliquez sur Finish.

 

 

Exécuter une migration vMotion de la VM Web-01a

 

  1. Cliquez avec le bouton droit sur web-01a.corp.local.
  2. Cliquez sur Migrate.

REMARQUE : NE MIGREZ PAS LA VM web-02a.corp.local.  De par la structure du laboratoire et afin d’éviter d’avoir à reconfigurer l’équilibreur de charge, ne migrez pas la VM web-02a.corp.local.

 

 

Sélectionner le type de migration

 

  1. Sélectionnez Change both compute resource and storage.
  2. Cliquez sur Select compute resource first.
  3. Cliquez sur Next.

 

 

Sélectionner une ressource de calcul

 

  1. Sélectionnez le cluster RegionB01-COMP01.
  2. Cliquez sur Next.

 

 

Sélectionner un système de stockage

 

  1. Sélectionnez RegionB01-ISCSI01-COMP01.
  2. Cliquez sur Next.

 

 

Sélectionner un dossier

 

  1. Cliquez sur ULSDiscovered virtual machine.
  2. Cliquez sur Next.

Vous devrez peut-être faire défiler la liste de sélection du réseau vers la droite pour afficher le nom complet des commutateurs logiques universels.

 

 

Sélectionner un réseau

 

  1. Sélectionnez le commutateur universalwire Web_Tier_ULS.
  2. Cliquez sur Next.

Vous devrez peut-être faire défiler la liste de sélection du réseau vers la droite pour afficher le nom complet des commutateurs logiques universels.

 

 

Sélectionner la priorité vMotion

 

Cliquez sur Next.

 

 

Vérifier les paramètres

 

Vérifiez les sélections et cliquez sur Finish.

 

 

Migrer les VM d’application restantes

 

Répétez la procédure pour migrer db-01a.corp.local.  Remplacez la valeur figurant dans le champ Network Selection par DB_Tier_ULS.

Une fois la VM DB migrée, vérifiez que la page Web de l’application à trois niveaux s’affiche.  Le diagramme topologique présente l’emplacement des VM après la migration.

REMARQUE : NE MIGREZ PAS LA VM web-02a.corp.local.  De par la structure du laboratoire et afin d’éviter d’avoir à reconfigurer l’équilibreur de charge, ne migrez pas la VM web-02a.corp.local.

 

 

Tester l’application à trois niveaux

 

Cliquez sur le bouton d’ouverture d’un nouvel onglet.

 

 

Ouvrir l’application à trois niveaux

 

Parce que nous avons migré la VM web-01a.corp.local vers le Site B, nous devons utiliser une autre adresse URL pour accéder à ce serveur spécifique.  

Copiez-collez l’adresse URL suivante dans votre navigateur :

 

https://web-01a/cgi-bin/app.py

REMARQUE : à l’ouverture de la page, vous recevrez peut-être un message d’avertissement lié au certificat. Ignorez ce message et poursuivez.  

REMARQUE : vous pouvez aussi tester la VM web-02a.corp.local directement en utilisant l’adresse URL suivante :  https://web-02a/cgi-bin/app.py

 

Conclusion du Module 4


Dans ce module, vous avez migré une pile d’applications entre deux sites.  Vous avez vérifié la sortie locale du trafic afin de garantir un modèle de trafic sortant optimal.  Avec cette configuration, vous pouvez profiter d’une configuration de Data Center en mode actif/actif.  Vous pouvez ainsi migrer des machines selon les besoins au sein d’un environnement.


 

Vous avez terminé le Module 4.

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

Pour plus d’informations sur les configurations universelles NSX, visitez le site ci-dessous et sélectionnez le guide Cross-vCenter Installation :

Passez à n’importe lequel des modules suivants.

 Responsable du laboratoire :

  • Modules 1 à 5 : Brian Wilson, ingénieur système, États-Unis

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 5 - Configuration du VPN (15 minutes)

Instructions concernant le déroulement du module


Dans ce module, vous allez configurer la passerelle NSX Edge pour des services VPN de couche 2. NSX Edge prend en charge plusieurs types de VPN. Avec SSL VPN-Plus, les utilisateurs distants peuvent accéder aux applications privées de l’entreprise. Le VPN IPSec offre une connectivité de site à site entre une instance NSX Edge et des sites distants. Le VPN de couche 2 étend le Data Center en permettant aux machines virtuelles de conserver leur connectivité réseau au-delà des limites géographiques. 

Ce module inclut :

  • Services VPN de couche 2


 

Topologie du laboratoire

 

Dans ce module, vous allez utiliser la topologie de réseau logique présentée ci-dessus.  Vous allez configurer la connexion du VPN de couche 2 entre deux segments de commutation logique. Chaque segment contient une machine virtuelle dans le même espace d’adressage de sous-réseau. Grâce au VPN de couche 2, vous allez créer un tunnel entre les deux commutateurs logiques à distance pour les regrouper de manière efficace en un seul segment de couche 2 continu. Vous allez vérifier la connectivité entre les deux VM sur la liaison VPN.

 

 

Examiner les types de VPN : présentation du VPN SSL

 

Avant de configurer le VPN de couche 2, examinons rapidement les différents services VPN offerts par NSX. Avec SSL VPN-Plus, les utilisateurs distants peuvent se connecter de manière sécurisée aux réseaux privés derrière une passerelle NSX Edge Gateway. Les utilisateurs distants peuvent accéder à des serveurs et applications sur les réseaux privés.

 

 

Examiner les types de VPN : présentation du VPN IPSEC

 

NSX Edge est compatible avec le VPN IPSec site à site entre une instance NSX Edge et des sites distants. IPSEC offre l’interopérabilité VPN entre les terminaux NSX Edge et les terminaux de VPN tiers. L’authentification des certificats, le mode clé prépartagée, le trafic de monodiffusion IP sont pris en charge entre l’instance NSX Edge et les routeurs VPN distants, mais aucun protocole de routage dynamique n’est pris en charge.

Derrière chaque routeur VPN distant, il est possible de configurer plusieurs sous-réseaux et de les connecter au réseau interne derrière une instance NSX Edge via des tunnels IPSec.

 

 

Présentation du VPN de couche 2

 

 Le VPN de couche 2 permet de configurer un tunnel entre deux sites. Les machines virtuelles restent sur le même sous-réseau même si elles sont déplacées entre ces sites, ce qui vous permet d’étendre votre Data Center. Une instance NSX Edge sur un site peut fournir tous les services aux machines virtuelles de l’autre site.

Le VPN de couche 2 permet des connexions VLAN à VLAN, VXLAN à VLAN et VXLAN à VXLAN.

Dans ce laboratoire, vous allez configurer un VPN de couche 2 entre deux segments VXLAN (deux commutateurs logiques NSX). 

 

Activer le serveur VPN


Dans cette leçon, vous allez créer le serveur VPN.


 

Ajouter un serveur VPN de couche 2

Le serveur VPN de couche 2 correspond à l’instance NSX Edge source à laquelle le VPN de couche 2 sera connecté.

Prérequis : l’adresse IP interne affectée au serveur VPN de couche 2 doit être différente de celle du client. Ces adresses IP peuvent se trouver sur un même sous-réseau.

 

 

Accéder à vSphere Web Client

 

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

 

 

Cliquer sur Networking and Security

 

  1.  Cliquez sur l’icône Home.
  2. Faites défiler le menu et sélectionnez Networking and Security.

 

 

Sélectionner NSX Edges

 

  1. Sélectionnez NSX Edges.

 

 

Vérifier l’instance NSX Manager Primary

 

  1. Vérifiez que Role Primary: 192.168.110.42 est sélectionné dans le champ NSX Manager.

 

 

Sélectionner le routeur de périmètre

 

  1. Double-cliquez sur le routeur RegionA0_Perimeter_GW.

 

 

Configurer l’interface Trunk du VPN de couche 2

 

  1. Sélectionnez Manage.
  2. Sélectionnez Interface.
  3. Cliquez sur le numéro d’interface NIC 2
  4. Cliquez sur l’icône Edit.

 

 

Poursuivre la configuration trunk

 

  1. Saisissez le nom L2VPN Trunk pour la nouvelle interface.
  2. Dans le champ Type, sélectionnez Trunk.
  3. Cliquez sur Select en regard du champ Connected to.
  4. Dans la nouvelle fenêtre, cliquez sur Distributed Virtual Port Group.
  5. Sélectionnez VM-RegionA01-VDS-MGMT.
  6. Cliquez sur OK.

 

 

 

Configurer la sous-interface

 

Cliquez sur le signe ADD pour ajouter la sous-interface.

 

 

Paramètres de la sous-interface

 

  1. Nommez la sous-interface Sub-VPN-Logical-SW-A.
  2. Champ Tunnel ID :  101
  3. Champ Backing Type : Network
  4. Cliquez sur Select en regard de Network.
  5. Dans la section Logical Switch, sélectionnez VPN_Logical_SW_A.
  6. Cliquez sur OK.

 

 

Ajouter un sous-réseau à l’interface

 

  1. Cliquez sur l’icône ADD.
  2. Dans le champ Primary IP Address, saisissez 172.16.101.1.
  3. Dans le champ Subnet Prefix Length, saisissez 24.
  4. Cliquez sur OK.

 

 

Terminer la configuration trunk

 

Cliquez sur OK.

 

 

Configurer le serveur VPN de couche 2

 

  1. Cliquez sur l’onglet VPN.
  2. Cliquez sur L2 VPN.
  3. Cliquez sur Change.

 

 

Configurer l’écouteur

 

  1. Champ Listener IP : 192.168.100.3 Primary
  2. Champ Listener Port : 443
  3. Dans la liste Encryption Algorithm, sélectionnez AES128-GCM-SHA256.
  4. Cliquez sur OK.

 

 

Activer le service du serveur VPN de couche 2

 

  1. Cliquez sur Start.
  2. Cliquez sur Publish Changes.

 

 

Ajouter une nouvelle configuration de site

 

  1. Pour ajouter une nouvelle configuration de site, cliquez sur le signe plus vert.

 

 

Modifier les détails de la configuration de site

 

  1. Cochez la case Enable Peer Site.
  2. Dans le champ Name:, saisissez RegionB-L2VPN.
  3. Dans le champ User ID:, saisissez vpn-user.
  4. Dans le champ Password:, saisissez VMware1!VMware1! (le mot de passe doit contenir plus de 10 caractères).
  5. Dans le champ Confirm Password:, saisissez à nouveau VMware1!VMware1! .
  6. Cliquez sur Select Sub Interfaces.

 

 

Sélectionner une sous-interface

 

  1. Sélectionnez Sub-VPN-Logical-SW-A.
  2. Cliquez sur la flèche vers la droite.
  3. Cliquez sur OK.
  4. Cliquez sur OK.

 

 

Publier les modifications

 

Cliquez sur Publish Changes.

 

Activer le client VPN


Dans cette leçon, vous allez créer le client VPN.


 

Ajouter un client VPN de couche 2

Le client VPN de couche 2 correspond à l’instance NSX Edge source qui initie la communication avec la passerelle Edge de destination (serveur VPN de couche 2).

 

 

Cliquer sur Networking and Security

 

  1.  Cliquez sur l’icône Home.
  2. Faites défiler le menu et sélectionnez Networking and Security.

 

 

Sélectionner NSX Edges

 

  1. Sélectionnez NSX Edges.

 

 

Vérifier l’instance NSX Manager Secondary

 

  1. Dans le champ NSX Manager, sélectionnez Role Secondary: 192.168.210.42.

 

 

Sélectionner le routeur de périmètre

 

  1. Double-cliquez sur le routeur RegionB0_Perimeter_GW.

 

 

Configurer l’interface Trunk du VPN de couche 2

 

  1. Cliquez sur le numéro d’interface NIC 2.
  2. Cliquez sur l’icône Edit.

 

 

Poursuivre la configuration trunk

 

  1. Saisissez le nom L2VPN Trunk pour la nouvelle interface.
  2. Dans le champ Type, sélectionnez Trunk.
  3. Cliquez sur Select en regard du champ Connected to.
  4. Dans la nouvelle fenêtre, cliquez sur Distributed Virtual Port Group.
  5. Sélectionnez VM-RegionB01-vDS-COMP.
  6. Cliquez sur OK.

 

 

 

Configurer la sous-interface

 

Cliquez sur le signe ADD pour ajouter la sous-interface.

 

 

Paramètres de la sous-interface

 

  1. Nommez la sous-interface Sub-VPN-Logical-SW-B.
  2. Champ Tunnel ID :  101
  3. Champ Backing Type : Network
  4. Cliquez sur Select en regard de Network.
  5. Dans la section Logical Switch, sélectionnez VPN_Logical_SW_B.
  6. Cliquez sur OK.

 

 

Ajouter un sous-réseau à l’interface

 

  1. Cliquez sur l’icône ADD.
  2. Dans le champ Primary IP Address, saisissez 172.16.101.2.
  3. Dans le champ Subnet Prefix Length, saisissez 24.
  4. Cliquez sur OK.

 

 

Terminer la configuration trunk

 

Cliquez sur OK.

 

 

Configurer le client VPN de couche 2

 

  1. Cliquez sur l’onglet VPN.
  2. Cliquez sur L2 VPN.
  3. Sélectionnez Client.
  4. Cliquez sur Change.

 

 

Configurer les paramètres du client

 

  1. Champ Server Address : 192.168.100.3
  2. Champ Server Port : 443
  3. Dans la liste Encryption Algorithm, sélectionnez AES128-GCM-SHA256.
  4. Cliquez sur Select Sub Interfaces.

 

 

Sélectionner une sous-interface

 

  1. Sélectionnez Sub-VPN-Logical-SW-B.
  2. Cliquez sur la flèche vers la droite.
  3. Cliquez sur OK.

 

 

Terminer le paramétrage du client

 

  1. Dans le champ User ID:, saisissez vpn-user.
  2. Dans le champ Password:, saisissez VMware1!VMware1! (le mot de passe doit contenir plus de 10 caractères).
  3. Dans le champ Confirm Password:, saisissez à nouveau VMware1!VMware1! .
  4. Cliquez sur OK.

 

 

Activer le service du serveur VPN de couche 2

 

  1. Cliquez sur Start.
  2. Cliquez sur Publish Changes.

 

Vérifier la connexion VPN


Dans cette leçon, vous allez vérifier la connexion VPN.


 

Afficher les statistiques du VPN de couche 2

Vous pouvez afficher les statistiques du VPN de couche 2, tels que l’état du tunnel, le nombre d’octets envoyés et reçus, etc. pour l’instance NSX Edge.

 

 

 

Vérifier l’état du tunnel

 

  1. Cliquez sur la flèche vers le bas en regard du champ Tunnel Status pour le développer.
  2. Vérifiez que l’état du tunnel est bien UP.

 

 

Sélectionner Host and Clusters

 

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

 

 

Se connecter à la VM sur le commutateur VPN de couche 2

 

  1. Sélectionnez vpn-sv-01a.corp.local.
  2. Cliquez sur l’onglet Summary.
  3. Cliquez sur cette zone pour lancer la console.

 

 

Vérifier l’adjacence de niveau 2 avec vpn-sv-02a

 

Dans le nouvel onglet Web

Cliquez et saisissez

Pour Login, saisissez root

Pour Password, saisissez VMware1!

Pour pouvoir tester la connectivité sur le tunnel VPN établi, exécutez une commande ping sur vpn-sv-02a.

ping vpn-sv-02a 

 

La commande ping a connu une issue favorable. Vous étendez le sous-réseau 172.16.101.0/24 entre les sites sur un réseau de couche 3.

 

Conclusion du Module 5


Dans ce module, vous avez configuré un VPN de couche 2 entre des commutateurs logiques locaux (segments VXLAN). Les segments étaient situés dans un Data Center différent et n’étaient pas reliés par des blocs universels. Le VPN de couche 2 permet aux deux VM de communiquer via l’encapsulation L2 sur L3 sans avoir à étendre un réseau VXLAN sur les deux sites.   


 

Vous avez terminé le Module 5.

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

Pour plus d’informations sur la configuration du VPN de couche 2 NSX, visitez le site suivant :

Passez à n’importe lequel des modules suivants.

 Responsable du laboratoire :

  • Modules 1 à 5 : Brian Wilson, ingénieur système, É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-1925-01-NET

Version: 20190301-153132