VMware Hands-on Labs - HOL-1925-01-NET


Hands-on Lab im Überblick – HOL-1925-01-NET – Nutzung von VMware NSX-V für Fortgeschrittene

Anleitung für das Hands-on Lab


Hinweis: Dieses Hands-on Lab dauert möglicherweise länger als 90 Minuten. Sie werden wahrscheinlich nur zwei bis drei Module in einer Sitzung schaffen. Da die Module unabhängig voneinander sind, können Sie mit jedem beliebigen Modul beginnen. Über das Inhaltsverzeichnis gelangen Sie direkt zum Modul Ihrer Wahl.

Das Inhaltsverzeichnis können Sie rechts oben im Hands-on Lab-Handbuch aufrufen.

In diesem Hands-on Lab interagieren Sie mit der NSX RESTful API, um sowohl GUI- als auch ausschließlich über die API verfügbare Funktionen auszuführen. Zudem lernen Sie die standortübergreifende NSX-Lösung kennen und konfigurieren diese. Darüber hinaus migrieren Sie einen Anwendungs-Stack zwischen Standorten.

Liste der Hands-on Lab-Module:

Hands-on Lab-Dozenten: 

  • Module 1 – 5 – Brian Wilson, Staff Systems Engineer, USA

 

Das Handbuch für dieses Hands-on Lab kann unter der folgenden Adresse heruntergeladen werden:

http://docs.hol.vmware.com

Dieses Hands-on Lab ist möglicherweise auch in anderen Sprachen verfügbar. Informationen zum Einstellen Ihrer gewünschten Sprache und zum Abrufen eines übersetzten Hands-on Lab-Handbuchs finden Sie im folgenden Dokument:

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


 

Position der Hauptkonsole

 

  1. Der ROT umrahmte Bereich ist die Hauptkonsole. Das Hands-on Lab-Handbuch finden Sie auf der Registerkarte rechts neben der Hauptkonsole.
  2. Für bestimmte Hands-on Labs sind auf separaten Registerkarten links oben möglicherweise zusätzliche Konsolen verfügbar. Falls Sie eine andere Konsole öffnen müssen, erhalten Sie entsprechende Anweisungen.
  3. Für die Bearbeitung des Hands-on Lab haben Sie 90 Minuten Zeit. Das Hands-on Lab kann nicht gespeichert werden. Sie müssen alle Aufgaben während dieser Zeit erledigen. Sie können jedoch die verfügbare Zeit verlängern, indem Sie auf die Schaltfläche EXTEND klicken. Auf einer Veranstaltung von VMware können Sie die Zeit für Hands-on Labs zweimal um bis zu 30 Minuten verlängern. Mit jedem Klick erhalten Sie weitere 15 Minuten. Außerhalb von VMware-Veranstaltungen können Sie Ihre Zeit für das Hands-on Lab um bis zu 9 Stunden und 30 Minuten verlängern. Mit jedem Klick verlängert sich die Dauer um eine Stunde.

 

 

Alternativen zur Tastatureingabe

Im Verlauf des Moduls geben Sie Text in die Hauptkonsole ein. Neben der Tastatureingabe gibt es zwei weitere, äußerst hilfreiche Methoden, die die Eingabe komplexer Daten erleichtern.

 

 

Inhalte im Hands-on Lab-Handbuch anklicken und in das aktive Konsolenfenster ziehen

 
 

Sie können Text und Befehle in der Befehlszeilenschnittstelle (CLI) anklicken und direkt aus dem Hands-on Lab-Handbuch in das aktive Fenster der Hauptkonsole ziehen.  

 

 

Internationale Online-Tastatur aufrufen

 

Darüber hinaus können Sie die internationale Online-Tastatur in der Hauptkonsole verwenden.

  1. Klicken Sie auf das Tastatursymbol in der Windows-Schnellstartleiste.

 

 

Einmal in das aktive Konsolenfenster klicken

 

In diesem Beispiel verwenden Sie die Online-Tastatur zur Eingabe des in E-Mail-Adressen verwendeten Symbols @. Auf US-Tastaturen wird das @-Zeichen über die Umschalttaste (2) eingegeben.

  1. Klicken Sie einmal in das aktive Konsolenfenster.
  2. Klicken Sie auf die Umschalttaste.

 

 

Auf die @-Taste klicken

 

  1. Klicken Sie auf die @-Taste.

Das @-Zeichen wurde im aktiven Konsolenfenster eingegeben.

 

 

Aktivierungsaufforderung oder Wasserzeichen

 

Wenn Sie Ihr Hands-on Lab erstmals starten, sehen Sie möglicherweise ein Wasserzeichen auf dem Desktop, das angibt, dass Windows nicht aktiviert wurde.  

Einer der großen Vorteile von Virtualisierung ist, dass virtuelle Maschinen verschoben und auf jeder beliebigen Plattform ausgeführt werden können.  Die Hands-on Labs machen sich diesen Vorteil zunutze, d.h. sie können von mehreren Rechenzentren aus ausgeführt werden. Allerdings können sich die Prozessoren dieser Rechenzentren unterscheiden. Dies veranlasst Microsoft zu einer Aktivierungsprüfung über das Internet.

Sie können jedoch sicher sein, dass VMware und die Hands-on Labs die Lizenzierungsanforderungen von Microsoft uneingeschränkt erfüllen. Bei dem Hands-on Lab, mit dem Sie gerade arbeiten, handelt es sich um einen gekapselten Pod ohne Vollzugriff auf das Internet. Ein solcher Zugriff ist jedoch für die Windows-Aktivierungsprüfung erforderlich. Ohne Vollzugriff auf das Internet schlägt dieser automatisierte Prozess fehl und es wird dieses Wasserzeichen angezeigt.

Hierbei handelt es sich um ein kosmetisches Problem, das Ihr Hands-on Lab nicht beeinträchtigt.  

 

 

Info rechts unten auf dem Bildschirm

 

Überprüfen Sie, ob das Hands-on Lab alle Startroutinen abgeschlossen hat und gestartet werden kann. Falls etwas anderes als „Ready“ angezeigt wird, warten Sie einige Minuten.  Wenn der Status Ihres Hands-on Lab nach fünf Minuten immer noch nicht zu „Ready“ gewechselt hat, bitten Sie um Hilfe.

 

Hands-on Lab-Topologie


Dieses Hands-on Lab besteht aus zwei separaten Standorten („RegionA0“ und „RegionB0“), von denen jeder über eine eigene vCenter-Instanz, dedizierte vSphere 6.5-Hosts, Storage und Netzwerksubnetze verfügt. Die vCenter-Instanzen nutzen einen gemeinsamen Platform Services Controller (PSC) für einheitliche, standortübergreifende Identitätsverwaltung, Lizenzierung und Anwendungsinteraktionen.

Region A besteht aus zwei Clustern:

Die beiden Cluster teilen sich ein gemeinsames Managementsubnetz (192.168.110.0/24) sowie ein vMotion- (10.10.30.0/24) und ein IP-Storage-Netzwerk (10.10.20.0/24).

Pro Standort werden separate dedizierte Netzwerke für NSX-VTEPs (VXLAN-Tunnelendpunkte) eingesetzt; „RegionA01“ verwendet 192.168.130.0/24. Die VTEP-Subnetze werden zusammen von einem externen Router (vpodrouter) geroutet.

Region B besteht aus einem einzigen Cluster:

Region B verfügt über ein eigenes Managementsubnetz (192.168.210.0/24) sowie separate vMotion- (10.20.30.0/24), IP-Storage- (10.20.20.0/24) und VTEP-Netzwerke (192.168.230.0/24).

Für gemeinsames Management, Cross vCenter vMotion und Netzwerkerweiterbarkeit (VXLAN) werden Management-, vMotion- und VTEP-Netzwerke über die verschiedenen Standorte hinweg geroutet.

Für alle VTEP-Netzwerke ist eine MTU mit 1600 Byte für die VXLAN-Kapselung konfiguriert.


 

Virtuelle Umgebungstopologie

 

In der Abbildung werden die vSphere-Hosts, VM-Platzierungen in den verschiedenen Clustern sowie verteilte virtuelle Switches (Distributed Virtual Switches, DVS) dargestellt. Die mit den Hosts verknüpften VTEP-IP-Adressen werden ebenfalls angezeigt.

Die Cluster „RegionA01-MGMT01“ und „RegionA01-COMP01“ werden von vCenter Server A (vcsa-01a.corp.local) verwaltet; „RegionB01-COMP01“ wird von vCenter Server B verwaltet (vcsa-01b.corp.local). Beide vCenter-Instanzen sind mit einem gemeinsamen Platform Services Controller (psc-01a.corp.local) verbunden, der sich im Managementnetzwerk von Region A befindet.

Die Konfiguration der NSX-Transportzone (TZ) im Hands-on Lab besteht aus Folgendem:

 

 

Vorkonfigurierte logische Netzwerktopologie

 

Beim ersten Zugriff auf das Hands-on Lab ist die in der Abbildung dargestellte Topologie bereits implementiert. Fünf universelle logische NSX-Switches („Web_Tier_ULS“, „App_Tier_ULS“, „DB_Tier_ULS“, „RegionA01_Transit“, „RegionB01_Transit“) und eine dreischichtige Webanwendung sind konfiguriert. Die logischen Switches sind mit einem universellen verteilten logischen Router (Universal Distributed Logical Router, UDLR) verbunden, der wiederum mit einem NSX Edge Services Gateway (ESG) in jeder Region verbunden ist. Dynamisches BGP-Routing stellt den Routenaustausch zwischen den ESGs und dem externen Router sicher.

 

 

Endgültige logische Netzwerktopologie

 

Nach Abschluss der Module 1, 2, 3 und 4 wird die Topologie in der Abbildung wie folgt im Hands-on Lab konfiguriert:

 

Modul 1 – VMware NSX Data Center-REST-API (15 Minuten)

NSX RESTful API


NSX wurde von Grund auf mit einer RESTful-API entwickelt. Die NSX-REST-API kann sowohl zum Konfigurieren von NSX als auch zum Bereitstellen von logischen NSX-Netzwerkservices verwendet werden. Die NSX-REST-API lässt sich direkt oder indirekt aus verschiedenen Programmiersprachen aufrufen. Viele Orchestrierungs- und Automatisierungstools wie vRealize Automation über vRealize Orchestrator können die NSX-REST-API aufrufen, um Layer 2- bis Layer 7-Netzwerkorchestrierung und -automatisierung durchzuführen.

Um das Aufrufen der NSX RESTful API zu demonstrieren, verwenden Sie die RESTClient-Erweiterung für den Mozilla Firefox-Browser. RESTClient ist ein Debugger für RESTful-Webservices und ein nützliches Tool bei der Arbeit mit verschiedenen REST-APIs.

Im Laufe dieses Moduls werden folgende Themen behandelt:


 

Einführung in REST-APIs

 

Eine REpresentational State Transfer(REST)-API definiert eine Reihe einfacher Prinzipien, die von den meisten API-Implementierungen mehr oder weniger befolgt werden.

REST nutzt die Vorteile von HTTP, um Daten (Header und Body) zwischen Clients und Servern zu senden.

Die Begriffe URL (Uniform Resource Locator) und URI (Uniform Resource Identifier) sind bei der Arbeit mit REST austauschbar.

Ressourcen (Bausteine) sind durch eingebettete Hyperlinks in HTML-Dokumenten oder URI-Referenzen miteinander verknüpft. Ressourcen können den Status über Darstellungen anzeigen, die sowohl Metadaten (z.B. Größe, Medientyp oder Zeichensatz) als auch Inhalte (Binärbild oder Textdokument) enthalten.

 

 

REST-Anfragemethoden

 

REST-Clients geben die gewünschte Interaktion an (HTTP-Anfragenachricht gemäß RFC 2616). Jede HTTP-Methode besitzt im Kontext eines REST-API-Ressourcenmodells eine bestimmte, klar definierte Semantik:

 

 

REST-Antwortstatuscodes

 

REST-APIs verwenden eine HTTP-Antwortnachricht, um Clients über Anfrageergebnisse zu informieren (wie in RFC 2616 definiert). Fünf Kategorien wurden definiert:

HTTP-Antwortnachrichten, um Clients über Anfrageergebnisse zu informieren (wie in RFC 2616 definiert):

 

 

HTTP-Anfrage-Header für die NSX RESTful API

 

Beim Konfigurieren von RESTful-APIs zum Bereitstellen von NSX Services sind folgende Anfrage-Header von wesentlicher Bedeutung:

  1. Authorization: Die Anmeldeinformationen (Anwendername und Kennwort) im Base64-kodierten Format.
  2. Content-Type: „application/xml“: Besagt, dass Anfrage-Body/Nutzdaten im XML-Format vorliegen.

 

 

HTTP-Anfragen für die NSX RESTful API

 

  1. Methode/Verb: GET/PUT/POST/DELETE: Ressourcenaktion
  2. URL: Ressource
  3. Header: „Authorization“ und „Content-Type“
  4. Body: XML-Nutzdaten
  5. Statuscode: „2xx“ bei Erfolg sowie „4xx“ und „5xx“ bei Fehlern

 

Einführung in PowerShell-REST-Cmdlets


PowerShell umfasst einen REST-Client. Im Folgenden erhalten Sie eine Einführung in das Invoke-RestMethod-Cmdlet.


 

Invoke-RestMethod

Mit dem PowerShell-Cmdlet „Invoke-RestMethod“ können Anwender auf RESTful-APIs zugreifen. Dieses Cmdlet enthält alle für die Interaktion mit NSX API erforderlichen Methoden und Optionen. Nachfolgend finden Sie die Syntax für die Methode.

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>]

 

 

Auf vSphere Web Client zugreifen

 

  1. Starten Sie den vSphere Web Client über das Google Chrome-Symbol auf dem Desktop.

 

 

vSphere Web Client minimieren

 

  1. Minimieren Sie den vSphere Web Client.

 

 

PowerShell-Beispielskript öffnen

 

Öffnen Sie mit Notepad++ die Datei „REST Example.ps1“ im Ordner „API Module“ auf dem Desktop.

  1. Doppelklicken Sie auf den Ordner API Module.
  2. Klicken Sie mit der rechten Maustaste auf REST Example.ps1.
  3. Wählen Sie Edit with Notepad++ aus.

 

 

Skript

 

Mit diesem PowerShell-Skript wird ein logischer Switch erstellt.

  1. Das ist die Initialisierung des Skripts.
  2. In diesem Bereich werden die Details des logischen Switch festgelegt.
  3. Dieses Cmdlet ruft NSX Manager zur Erstellung des logischen Switch auf.  

Beachten Sie: Anstelle von „Invoke-RestMethod“ wird „Invoke-WebRequest“ verwendet. Dieses Cmdlet wurde gewählt, um HTTP-Header bei der Rückgabe des Aufrufs zu überprüfen.

 

 

Beispielskript ausführen

 

  1. Klicken Sie mit der rechten Maustaste auf REST Example.ps1.
  2. Wählen Sie Run with PowerShell aus.
  3. Sehen Sie sich die Ausgabe an.

 

 

Zu vSphere Web Client zurückkehren

 

 

  1. Wählen Sie das Fenster vSphere Web Client in Chrome aus.

 

 

Zur Registerkarte „Networking & Security“ navigieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Wählen Sie Networking & Security aus.

 

 

Erstellung des logischen Switch überprüfen

 

  1. Klicken Sie auf Logical Switches.
  2. Überprüfen Sie, ob der Switch RestSwitch1 erstellt wurde.

Hinweis: Segment-ID und virtualwire-Nummer können abweichen.

 

 

„RestSwitch1“ entfernen

 

  1. Klicken Sie mit der rechten Maustaste auf RestSwitch1.
  2. Klicken Sie auf Remove.
  3. Klicken Sie auf Yes.

 

Erstellen mehrerer logischer Switches


In dieser Lektion erstellen Sie mithilfe eines PowerShell-Skripts mehrere logische Switches über NSX API.


 

Beispielskript öffnen

 

  1. Doppelklicken Sie auf den Ordner API Module auf dem Desktop.
  2. Klicken Sie mit der rechten Maustaste auf die Datei Create Switches.ps1.
  3. Wählen Sie Edit with Notepad++ aus.

 

 

Skript

 

Dieses Skript baut auf dem vorangegangenen Skript auf. Es verwendet ein Array von Switch-Namen, um mehrere Switches zu erstellen.

  1. Hier wird das Array „$switches“ definiert, das drei Switch-Namen enthält: „Web“, „App“ und „DB“.
  2. Dieser Code durchläuft jeden Wert des $switches-Arrays.  
  3. Der Switch-Name wird dem Anfrage-Body bei jedem Durchlauf hinzugefügt.

 

 

„Create Switches“-Skript ausführen

 

  1. Klicken Sie mit der rechten Maustaste auf die Datei Create Switches.ps1.
  2. Klicken Sie auf Run with PowerShell.

 

 

Ausgabe

 

Die logischen Switches „Web“, „App“ und „DB“ wurden erstellt und verfügbaren virtualwire-IDs zugewiesen. Die IDs im Hands-on Lab können abweichen.

Drücken Sie auf eine beliebige Taste, um fortzufahren.

 

 

Zu vSphere Web Client zurückkehren

 

  1. Klicken Sie auf das Aktualisierungssymbol.
  2. Überprüfen Sie, ob der Switch App erstellt wurde.
  3. Überprüfen Sie, ob der Switch DB erstellt wurde.
  4. Überprüfen Sie, ob der Switch Web erstellt wurde.

 

Erstellen eines verteilten Routers


In dieser Lektion erstellen Sie mithilfe eines PowerShell-Skripts einen verteilten Router über NSX API.


 

„Create DLR“-Skript öffnen

 

  1. Kehren Sie zum Ordner API Module zurück.
  2. Klicken Sie mit der rechten Maustaste auf die Datei Create DLR.ps1.
  3. Klicken Sie auf Edit with Notepad++.

 

 

Skript

 

  1. Sehen Sie sich die erforderlichen Felder für einen verteilten Router an.
  2. Achten Sie auf den URI-Speicherort.

 

 

„Create DLR.ps1“-Skript ausführen

 

  1. Klicken Sie mit der rechten Maustaste auf die Datei Create DLR.ps1.
  2. Klicken Sie auf Run with PowerShell.

Hinweis: Die Ausführung des Skripts kann 1 – 3 Minuten dauern.

Sehen Sie sich die Ausgabe an.

Drücken Sie auf eine beliebige Taste, um das Fenster zu schließen.

 

 

DLR in vSphere Web Client

 

Kehren Sie zum vSphere Web Client zurück.

  1. Klicken Sie auf die Registerkarte NSX Edges.
  2. Überprüfen Sie, ob Distributed-Router erstellt wurde.

Hinweis: Die Edge-Nummern können in Ihrem Hands-on Lab abweichen.

 

Konfigurieren von Alarmschwellenwerten für DFW-Verbindungen pro Sekunde


In dieser Lektion konfigurieren Sie mithilfe eines PowerShell-Skripts Alarme für eine verteilte Firewall, die in Abhängigkeit der Verbindungen pro Sekunde ausgelöst werden. Diese Konfiguration ist nur über die API verfügbar.


 

Skript „DFW CPS.ps1“ öffnen

 

  1. Kehren Sie zum Ordner API Module zurück.
  2. Klicken Sie mit der rechten Maustaste auf die Datei DFW CPS.ps1.
  3. Klicken Sie auf Edit with Notepad++.

 

 

Skript

 

  1. Sehen Sie sich die Alarmschwellenwerte an.
  2. Achten Sie auf die URI.

 

 

„DFW CPS“-Skript ausführen

 

  1. Klicken Sie mit der rechten Maustaste auf die Datei DFW CPS.ps1.
  2. Klicken Sie auf Run with PowerShell.

Sehen Sie sich die Skriptausgabe an. Die verteilte Firewall gibt nun einen Alarm aus, wenn die Verbindungen pro Sekunde den Wert 10 überschreiten.

 

Modulbereinigung


Nach Abschluss dieses Hands-on Lab müssen die über die API erstellten Objekte entfernt werden.


 

Logische Switches löschen

 

Achten Sie darauf, nur die über die API erstellten logischen Switches zu entfernen.

Kehren Sie zum vSphere Web Client zurück:

  1. Navigieren Sie zur Registerkarte Logical Switches.
  2. Klicken Sie auf den logischen Switch App.
  3. Klicken Sie auf Remove.
  4. Klicken Sie auf Yes.

Wiederholen Sie diese Schritte für die logischen Switches DB und Web.

 

 

Verteilten Router löschen

 

  1. Navigieren Sie zur Registerkarte NSX Edges.
  2. Klicken Sie auf Distributed-Router.
  3. Klicken Sie auf das Symbol zum Löschen.
  4. Klicken Sie auf Yes.

 

Modul 1 – Fazit


In diesem Modul haben Sie mithilfe von NSX API mehrere NSX-Objekte konfiguriert. NSX API ist ein leistungsstarkes Tool für Konfiguration, Fehlerbehebung und Überwachung.  


 

Abschluss von Modul 1

Sie haben Modul 1 abgeschlossen.

Weitere Informationen zu NSX API können Sie unter der nachstehenden URL aufrufen. Dort finden Sie auch den NSX API-Leitfaden:

Sie können auch über den Desktop der Hauptkonsole auf den API-Leitfaden zugreifen. Falls Sie sich noch eingehender mit der API beschäftigen möchten, stehen Ihnen außerdem der API-Leitfaden sowie der Postman Rest Client auf dem Desktop der Hauptkonsole zur Verfügung. Für weitere Konfigurationsbeispiele von Komponenten wie Routing und Firewalling wird zu einem späteren Zeitpunkt im Hands-on Lab die Datei „Fast-Forward.ps1“ auf dem Desktop verwendet, um Modul 3 zu überspringen.  

Fahren Sie mit einem beliebigen Modul unten fort oder beenden Sie das Hands-on Lab.

Hands-on Lab-Dozent:

  • Module 1 – 5: Brian Wilson, Staff Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Modul 2 – Vorkonfigurierte, standortübergreifende Objekte (30 Minuten)

Anleitung für das Modul


In diesem Modul wird die Konfiguration von vSphere und NSX behandelt. Dieses Hands-on Lab enthält zahlreiche Konfigurationen und universelle Objekte, die Voraussetzung für eine standortübergreifende Aktiv-Aktiv-Konfiguration sind.

Folgende Konfigurationen werden beschrieben:

  • Erweiterter verknüpfter Modus in vCenter
  • NSX Manager
  • Universeller Controller-Cluster
  • Vorbereitung eines logischen Netzwerks
  • Vorbereitung eines universellen logischen Netzwerks
  • Universelle logische Switches
  • NSX Edges

 

Vorkonfigurierte Topologie

 

Im vorstehenden Topologiediagramm werden die vorkonfigurierten Objekte dieses Hands-on Lab dargestellt.

 

vCenter-Konfigurationen


Im Rahmen dieses Hands-on Lab wurden die zwei vCenter Server-Instanzen im erweiterten verknüpften Modus konfiguriert. Dadurch können beide vCenter Server-Instanzen in derselben vSphere Web Client-Sitzung verwaltet werden. Im erweiterten verknüpften Modus lassen sich auch beide NSX-Umgebungen in derselben vSphere Web Client-Sitzung konfigurieren.  


 

„Hosts and Clusters“ auswählen

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Hosts and Clusters.

 

 

Überprüfen, ob beide vCenter Server-Instanzen verfügbar sind

 

Vergewissern Sie sich, dass beide vCenter Server-Instanzen angezeigt werden.

 

NSX Manager-Konfigurationen


In dieser Lektion lernen Sie die Rollen kennen, die NSX Manager zugewiesen sind.  Der in Region A registrierte NSX Manager übernimmt die primäre Rolle. Der in Region B registrierte NSX Manager übernimmt die sekundäre Rolle.


 

Zur Registerkarte „Networking & Security“ navigieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Wählen Sie Networking & Security aus.

 

 

Zur Registerkarte „Installation and Upgrade“ navigieren

 

Klicken Sie auf die Registerkarte Installation and Upgrade.

 

 

NSX Manager-Rollen überprüfen

 

In diesem Hands-on-Lab wurden bereits zwei NSX Manager konfiguriert:  einer als Primary und der andere als Secondary.  Überprüfen Sie, ob beiden NSX Manager-Instanzen eine Rolle zugewiesen ist.

 

Universeller Controller-Cluster


In dieser Lektion lernen Sie den universellen Controller-Cluster von NSX kennen.  Der universelle Controller-Cluster von NSX verwaltet den logischen Netzwerkbetrieb zwischen beiden vCenter Server-Instanzen.  Dadurch ist die Konfiguration von universellen logischen Switches, universellen logischen Routern und universellen verteilten Firewall-Regeln möglich.


 

Controller im primären NSX Manager überprüfen

 

  1. Klicken Sie auf NSX Controller Nodes.

Vergewissern Sie sich, dass controller-1 mit dem primären NSX Manager verbunden ist.

Hinweis: Die Best Practice von VMware NSX besteht darin, stets drei Controller in einem Controller-Cluster zu verwalten. Aufgrund von Ressourcenbeschränkungen in der Pod-Umgebung wurde jedoch nur ein einziger Controller bereitgestellt. Dies hat keine negativen Auswirkungen auf die Funktionen des Hands-on Lab.

 

 

Controller im sekundären NSX Manager überprüfen

 

Vergewissern Sie sich, dass controller-1 mit dem sekundären NSX Manager verbunden ist.

Hinweis: Die Best Practice von VMware NSX besteht darin, stets drei Controller in einem Controller-Cluster zu verwalten. Aufgrund von Ressourcenbeschränkungen in der Pod-Umgebung wurde jedoch nur ein einziger Controller bereitgestellt. Dies hat keine negativen Auswirkungen auf die Funktionen des Hands-on Lab.

 

Vorbereitung eines universellen logischen Netzwerks


Diese Lektion beschäftigt sich mit der Vorbereitung eines vorkonfigurierten logischen Netzwerks.


 

Universeller Segment-ID-Pool im primären NSX Manager

 

Vor der Konfiguration von universellen logischen Switches muss ein universeller Segment-ID-Pool erstellt werden. Der universelle Segment-ID-Pool muss einen eindeutigen Bereich gegenüber allen anderen Segment-ID-Pools umfassen, die im Rahmen einer vCenter-übergreifenden Umgebung in NSX Manager-Instanzen verwendet werden.

  1. Wählen Sie Logical Network Settings aus.
  2. Wählen Sie den primären NSX Manager aus.
  3. Wählen Sie VXLAN Settings aus.
  4. Überprüfen Sie den Eintrag für Segment ID Pool.
  5. Achten Sie auf den unterschiedlichen Bereich für Universal Segment ID Pool.

 

 

Zum sekundären NSX Manager wechseln

 

Wechseln Sie zum sekundären NSX Manager. Gehen Sie dabei wie folgt vor:

  1. Klicken Sie auf das Dropdown-Menü NSX Manager.
  2. Wählen Sie den sekundären NSX Manager aus.

 

 

Universeller Segment-ID-Pool im sekundären NSX Manager

 

Der sekundäre NSX Manager muss ebenfalls mit einem Segment-ID-Pool konfiguriert werden. Die in allen NSX Manager-Instanzen konfigurierten Segment-ID-Pools dürfen sich nicht überschneiden. Der universelle Segment-ID-Pool wird über den primären NSX Manager synchronisiert:

  1. Vergewissern Sie sich, dass sich der Segment-ID-Pool im sekundären NSX Manager nicht mit dem Segment-ID-Pool im primären NSX Manager überschneidet.
  2. Überprüfen Sie, ob der universelle Segment-ID-Pool synchronisiert wurde.

 

 

Universelle Transportzonen

 

Transportzonen definieren, welche Cluster Teil eines logischen Netzwerks werden. Globale Transportzonen sind auf eine einzige vCenter Server-Instanz begrenzt. Universelle Transportzonen können sich über mehrere vCenter Server-Instanzen erstrecken. Überprüfen Sie die mit der universellen Transportzone verbundenen Cluster:

  1. Wählen Sie Transport Zones aus.
  2. Wählen Sie Universal_TZ aus.
  3. Klicken Sie auf Connect Clusters.

 

 

Mit universellen Transportzonen verbundene Cluster

 

Transportzonen definieren, welche Cluster Teil eines logischen Netzwerks werden. Globale Transportzonen sind auf eine einzige vCenter Server-Instanz begrenzt. Universelle Transportzonen können sich über mehrere vCenter Server-Instanzen erstrecken. Überprüfen Sie die mit der universellen Transportzone verbundenen Cluster:

  1. Vergewissern Sie sich, dass der Cluster RegionB01-COMP01 verbunden ist und den Status „Normal“ aufweist.
  2. Klicken Sie auf Cancel.

Wechseln Sie zum primären NSX Manager und sehen Sie sich die Konfiguration von Universal_TZ an. Vergewissern Sie sich, dass die Cluster RegionA01-COMP01 und RegionA01-MGMT01 verbunden sind und den Status „Normal“ aufweisen.

 

Universelle logische Switches


In dieser Lektion werden die vorkonfigurierten universellen logischen Switches behandelt.


 

Universelle logische Switches im primären NSX Manager überprüfen

 

Universelle logische Switches werden auf derselben Registerkarte wie globale logische Switches konfiguriert. Überprüfen Sie die fünf vorkonfigurierten universellen logischen Switches:

  1. Wählen Sie die Registerkarte Logical Switches aus.
  2. Wählen Sie den primären NSX Manager aus.
  3. Überprüfen Sie, ob fünf logische Switches mit universellem Gültigkeitsbereich konfiguriert sind.

Die Segment-IDs der universellen logischen Switches liegen innerhalb des Bereichs des universellen Segment-ID-Pools.

 

 

Universelle logische Switches im sekundären NSX Manager überprüfen

 

Nach der Konfiguration werden universelle logische Switches mit allen sekundären NSX Manager-Instanzen synchronisiert. Vergewissern Sie sich, dass alle Switches im sekundären NSX Manager verfügbar sind und dass ihre Segment-IDs mit dem primären NSX Manager übereinstimmen:

  1. Wählen Sie den sekundären NSX Manager aus.
  2. Überprüfen Sie, ob die universellen logischen Switches der Konfiguration im primären NSX Manager entsprechen.

Die Namen, Transportzonen und Segment-IDs werden in allen NSX Manager-Instanzen synchronisiert.

 

 

Universellen logischen Switch erstellen

 

Universelle logische Switches können nur im primären NSX Manager konfiguriert werden. Erstellen Sie einen universellen logischen Switch im primären NSX Manager:

  • Wählen Sie den primären NSX Manager aus.
  • Klicken Sie auf das Symbol zum Hinzufügen eines logischen Switch.

 

 

Neu erstellten universellen logischen Switch überprüfen

 

Vergewissern Sie sich, dass der universelle logische Switch „NSX_ULS“ erstellt wurde, sich in der Transportzone „Universal_TZ“ befindet und mit einer Segment-ID aus dem universellen Segment-ID-Pool konfiguriert wurde. Wechseln Sie zum sekundären NSX Manager und überprüfen Sie, ob der universelle logische Switch synchronisiert wurde:

  1. Wählen Sie den primären NSX Manager aus.
  2. Überprüfen Sie den Eintrag NSX_ULS.

 

 

Neu erstellten universellen logischen Switch im sekundären NSX Manager überprüfen

 

Überprüfen Sie, ob der universelle logische Switch „NSX_ULS“ mit dem sekundären NSX Manager synchronisiert wurde.  

  1. Wählen Sie den sekundären NSX Manager aus.
  2. Überprüfen Sie den Eintrag NSX_ULS.

 

NSX Edge-Konfigurationen


In diesem Hands-on Lab stellen NSX Edge-Geräte (ESGs) eine Verbindung für North-South- sowie East-West-Kommunikation bereit. Es gibt zwei vorkonfigurierte NSX Edge-Geräte für North-South-Kommunikation. Diese Perimeter-Gateways wurden mit dynamischem BGP-Routing konfiguriert. Die Perimeter-Gateways nutzen Equal Cost Multi-Pathing (ECMP), um ein- und ausgehenden Datenverkehr für beide Standorte zuzulassen. Ein drittes ESG wurde als universeller logischer verteilter Router (Universal Logical Distributed Router, ULDR) vorkonfiguriert. Dieser ULDR wurde für ECMP und lokalen Ausgang konfiguriert.


 

Lokaler Ausgang

 

Mit einem lokalen Ausgang ist eine Ausgangsoptimierung pro Standort möglich. Datenverkehr wird über das ESG an dem Standort geroutet, von dem der Datenverkehr stammt. East-West-Traffic nutzt den ULDR zur Optimierung zwischen VMs. Diese Konfiguration erfordert dynamisches Routing zwischen dem physischen Netzwerk und den ESGs sowie zwischen den ESGs und dem ULDR. Der ULDR bietet das konfigurierte Netzwerk beiden ESGs an. Die ESGs bieten die ULDR-Netzwerke dem physischen Netzwerk beider Standorte an. Durch diese Konfiguration kann das physische Netzwerk ein- und ausgehenden Datenverkehr im selben Netzwerk an beiden Standorten senden und empfangen.

  1. Datenverkehr von RegionA0-VMs verlässt das logische Netzwerk über das RegionA0-ESG.
  2. Datenverkehr von RegionB0-VMs verlässt das logische Netzwerk über das RegionB0-ESG.
  3. Datenverkehr zwischen VMs nutzt den ULDR zur East-West-Optimierung.

 

 

Perimeter-Gateway-Konfigurationen

 

So zeigen Sie die Konfiguration des ESG „RegionA0_Perimeter_GW“ an:

  1. Navigieren Sie zur Registerkarte NSX Edges.
  2. Vergewissern Sie sich, dass der primäre NSX Manager ausgewählt ist.
  3. Doppelklicken Sie auf das ESG RegionA0_Perimeter_GW.

 

 

Konfiguration des universellen logischen verteilten Routers

 

  1. Vergewissern Sie sich, dass der primäre NSX Manager ausgewählt ist.
  2. Doppelklicken Sie auf Universal_DLR_01.

 

Modul 2 – Fazit


In diesem Modul haben Sie die vorkonfigurierten universellen Objekte kennengelernt. Diese Elemente wurden vorkonfiguriert, damit Sie sich auf die Konfiguration universeller Routing-Konstrukte in Modul 3 konzentrieren können.


 

Abschluss von Modul 2

Sie haben Modul 2 abgeschlossen.

Weitere Informationen zu universellen NSX-Konfigurationen finden Sie im vCenter-übergreifenden Installationsleitfaden unter der folgenden URL:

Fahren Sie mit einem beliebigen Modul unten fort.

 Hands-on Lab-Dozent:

  • Module 1 – 5: Brian Wilson, Staff Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Modul 3 – Erstellung von universellen Konstrukten (30 Minuten)

Anleitung für das Modul


In diesem Modul konfigurieren Sie BGP für den universellen logischen verteilten Router (Universal Logical Distributed Router, ULDR) sowie universelle verteilte Firewall-Regeln.

Dieses Modul umfasst die folgenden Schritte:

  • Aktivieren von BGP für den ULDR in RegionA
  • Aktivieren von BGP für den ULDR in RegionB
  • Überprüfen der Anwendungskonnektivität
  • Erstellen universeller verteilter Firewall-Regeln

 

Vorkonfigurierte Topologie

 

Für dieses Hands-on Lab wurde die oben dargestellte virtuelle Netzwerktopologie vorkonfiguriert. Die Perimeter-Gateway-VMs wurden bereits für den Austausch von Routing-Informationen mit dem vPod-Router konfiguriert.

 

 

Endgültige Konfiguration

 

Am Ende dieses Moduls wird BGP für den Austausch von dynamischen Routing-Informationen zwischen den Perimeter-Gateways und dem universellen logischen verteilten Router konfiguriert. Zudem wird Ausgangsoptimierung konfiguriert. Damit stellen Sie sicher, dass von der logischen Netzwerkumgebung ausgehender Datenverkehr das Perimeter-Gateway verwendet, das der VM am nächsten ist. Universelle verteilte Firewall-Regeln werden konfiguriert, um Mikrosegmentierung für die dreischichtige Anwendung im Hands-on Lab bereitzustellen.

 

Aktivieren von BGP für den universellen logischen Router in „RegionA0“


In diesem Modul konfigurieren Sie den universellen logischen verteilten Router für dynamisches Routing sowie die universelle verteilte Firewall für die Mikrosegmentierung einer dreischichtigen Anwendung.


 

Regions-ID für „RegionA0“

 

Die Regions-ID wird pro Cluster konfiguriert. Mit der Regions-ID kann der ULDR Routing-Entscheidungen anhand des Standorts treffen.

 

 

ULDR für dynamisches Routing konfigurieren

 

So konfigurieren Sie „Universal_DLR“:

  1. Navigieren Sie zur Registerkarte NSX Edges.
  2. Vergewissern Sie sich, dass der primäre NSX Manager ausgewählt ist.
  3. Doppelklicken Sie auf Universal_DLR_01.

 

 

ULDR für BGP konfigurieren

 

BGP muss aktiviert und „RegionA0_Perimeter_GW“ als Nachbar hinzugefügt werden:

  1. Wählen Sie den Abschnitt BGP aus.
  2. Klicken Sie unter BGP Configuration auf Edit.

 

Aktivieren von BGP für den universellen logischen Router in „RegionB0“


In dieser Lektion konfigurieren Sie den universellen logischen verteilten Router in „RegionB0“.


 

Regions-ID anzeigen

 

Die Regions-ID wird pro Cluster konfiguriert. Mit der Regions-ID kann der ULDR Routing-Entscheidungen anhand des Standorts treffen.

 

 

ULDR für dynamisches Routing konfigurieren

 

So zeigen Sie die Konfiguration des ULDR in „RegionB0“ an:

  1. Navigieren Sie zur Registerkarte NSX Edges.
  2. Vergewissern Sie sich, dass der sekundäre NSX Manager ausgewählt ist.
  3. Doppelklicken Sie auf Universal_DLR_01.

 

 

ULDR für BGP konfigurieren

 

BGP muss aktiviert und „RegionB0_Perimeter_GW“ als Nachbar hinzugefügt werden:

  1. Wählen Sie den Abschnitt BGP aus.
  2. Klicken Sie unter „BGP Configuration“ auf Edit.

 

Überprüfen der Anwendungskonnektivität


In dieser Lektion überprüfen Sie, ob die dreischichtige Anwendung in „RegionA0“ funktioniert.


 

Neue Registerkarte öffnen

 

Klicken Sie auf die Schaltfläche für eine neue Registerkarte.

 

 

Dreischichtige Anwendung öffnen

 

Klicken Sie auf das Lesezeichen webapp.corp.local.

 

 

Dreischichtige Anwendung überprüfen

 

Überprüfen Sie, ob die Hands-on Lab-Seite mit der Multi-Tier-Anwendung geladen wird und Daten abgerufen werden.  

 

 

Ping-Test für Anwendungs-VMs

 

Öffnen Sie eine Eingabeaufforderung auf der Hauptkonsole.

 

Erstellen universeller verteilter Firewall-Regeln


In dieser Lektion erstellen Sie universelle verteilte Firewall-Regeln für die dreischichtige Anwendung des Hands-on Lab. Universelle verteilte Firewall-Regeln dürfen nur IP-Adressen, IP-Sätze, MAC-Nummern oder MAC-Sätze enthalten.


 

Zu vSphere Web Client navigieren

 

Navigieren Sie zur Registerkarte vSphere Web Client.

 

 

Zur Registerkarte „Networking & Security“ navigieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Wählen Sie Networking & Security aus.

 

 

Zur Registerkarte „Firewall“ navigieren

 

Klicken Sie auf die Registerkarte Firewall.

 

 

Sicherstellen, dass der primäre NSX Manager ausgewählt ist

 

Für die Erstellung von universellen Firewall-Regeln muss der primäre NSX Manager ausgewählt sein. Alle für die universelle Synchronisierung gekennzeichneten Regeln werden automatisch auf den sekundären NSX Manager verteilt.

 

 

Abschnitt zum Firewall-Regelsatz hinzufügen

 

Klicken Sie auf die Schaltfläche Add Section.

 

 

Abschnitt erstellen

 

  1. Nennen Sie den Abschnitt Three Tier App.
  2. Aktivieren Sie für diesen neuen Abschnitt die Option Universal Synchronization.
  3. Klicken Sie auf Add.

 

 

Universelle Regel hinzufügen

 

  1. Aktivieren Sie das Kontrollkästchen Three Tier App.
  2. Klicken Sie auf Add Rule.

 

 

Universelle Standardregel konfigurieren

 

In diesem Schritt konfigurieren Sie eine universelle Standardregel. Diese Regel wird als Standardablehnung festgelegt, sobald alle Anwendungsregeln definiert wurden.  

  1. Vergewissern Sie sich, dass der Abschnitt Three Tier App vollständig eingeblendet wird.
  2. Klicken Sie auf Enter rule name.

 

 

Regel für Webserver-Zugriff konfigurieren

 

Klicken Sie auf die Schaltfläche Add Rule.

 

 

Regel für den Webzugriff auf den Anwendungsserver konfigurieren

 

In diesem Schritt wird eine Regel konfiguriert, die über die Webschicht in Tomcat Zugriff auf die Anwendungsschicht gewährt:

  1. Vergewissern Sie sich, dass der Abschnitt Three Tier App vollständig eingeblendet wird.
  2. Klicken Sie auf Add Rule.
  3. Klicken Sie auf das Feld Enter rule name, um die Regel zu benennen.

 

 

Regel für den Anwendungszugriff auf den Datenbankserver konfigurieren

 

In diesem Schritt wird eine Regel konfiguriert, die über die Anwendungsschicht in MySQL Zugriff auf die Datenbankschicht gewährt:

  1. Vergewissern Sie sich, dass der Abschnitt Three Tier App erweitert wurde.
  2. Klicken Sie auf Add Rule.
  3. Klicken Sie auf das Feld Enter rule name, um die Regel zu benennen.

 

 

Ablehnungsregel konfigurieren

 

Klicken Sie auf das Bearbeitungssymbol in der Spalte Action.

 

 

Änderungen veröffentlichen

 

Klicken Sie auf Publish Changes, um die universellen Firewall-Regeln zu veröffentlichen. Regeln werden erst durchgesetzt, nachdem die Änderungen veröffentlicht wurden.

 

 

Anwendungskonnektivität überprüfen

 

Klicken Sie auf die Schaltfläche für eine neue Registerkarte.

 

 

Ping-Test für Anwendungs-VMs

 

Öffnen Sie eine Eingabeaufforderung auf der Hauptkonsole, um die Ablehnungsregel zu überprüfen.

 

Modul 3 – Fazit


In diesem Modul haben Sie dynamisches Routing und lokalen Ausgang für den universellen logischen verteilten Router an zwei Standorten konfiguriert. Mit dieser Konfiguration sind Aktiv-Aktiv-Konfigurationen für virtuelle Rechenzentren möglich.


 

Abschluss von Modul 3

Sie haben Modul 3 abgeschlossen.

Weitere Informationen zu universellen NSX-Konfigurationen finden Sie im vCenter-übergreifenden Installationsleitfaden unter der folgenden URL:

Fahren Sie mit einem beliebigen Modul unten fort.

 Hands-on Lab-Dozent:

  • Module 1 – 5: Brian Wilson, Staff Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Modul 4 – Standortübergreifende Aktiv-Aktiv-Konfiguration (15 Minuten)

Anleitung für das Modul


In diesem Modul migrieren Sie einen Anwendungs-Stack mithilfe von vMotion auf einen sekundären Standort.  

Dieses Modul umfasst Folgendes:

  • Cross vCenter vMotion
  • Überprüfung des lokalen Ausgangs

Falls Sie Modul 3 noch nicht abgeschlossen haben, führen Sie die nachfolgenden Schritte zur Konfiguration der Umgebung durch. Sollten Sie Modul 3 bereits abgeschlossen haben, fahren Sie mit der nächsten Lektion fort:


 

Hands-on Lab-Topologie

 

In diesem Modul verwenden Sie die oben dargestellte logische Netzwerktopologie. Mithilfe von vMotion migrieren Sie alle mit der dreischichtigen Anwendung verknüpften VMs auf einen sekundären Standort. Darüber hinaus überprüfen Sie den lokalen Ausgang von Datenverkehr sowie die Anwendungsverfügbarkeit.

 

 

vSphere Web Client minimieren

 

  1. Minimieren Sie den vSphere Web Client.

 

 

„Fast Forward“-Skript ausführen

 

  1. Klicken Sie mit der rechten Maustaste auf die Datei Fast-Forward.ps1 auf dem Desktop.
  2. Wählen Sie Run with PowerShell aus.

Mithilfe dieses Skripts konfigurieren Sie die Umgebung mit den Voraussetzungen von Modul 4. Warten Sie, bis das Skript vollständig ausgeführt wurde. Das Fenster wird nach Beendigung des Vorgangs geschlossen.

 

 

Zu vSphere Web Client zurückkehren

 

  1.  Wählen Sie das Fenster vSphere Web Client in Chrome aus.

 

Überprüfen des lokalen Ausgangs


In dieser Lektion überprüfen Sie, ob der lokale Ausgang funktioniert.


 

Beim vPod-Router anmelden

 

Starten Sie PuTTY.

 

 

Verbindung zum vPod-Router herstellen

 

  1. Wählen Sie die gespeicherte Sitzung vPod Router BGP aus.
  2. Klicken Sie auf Open.

 

 

Anmelden

 

  1. Geben Sie das Kennwort VMware1! ein.

 

 

Routing-Tabelle überprüfen

 

Zeigen Sie die Routing-Tabelle an. Überprüfen Sie zwei aktive Routen pro VM-Netzwerk:

  1. Geben Sie folgenden Befehl ein:
show ip bgp
  1. Überprüfen Sie die Routen.
  2. Schließen Sie danach die SSH-Sitzung.

 

 

Zu vSphere Web Client wechseln und „Hosts and Clusters“ auswählen

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Hosts and Clusters.

 

 

Standort der Anwendung überprüfen

 

Vergewissern Sie sich, dass sich die VMs web-01a.corp.local, web-02a.corp.local, app-01a.corp.local und db-01a.corp.local im Rechenzentrum RegionA01 befinden.

 

 

Zur Registerkarte „Networking & Security“ navigieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Wählen Sie Networking & Security aus.

 

 

Universelle Ablehnungsregel deaktivieren

 

  1. Klicken Sie auf die Registerkarte Firewall.
  2. Vergewissern Sie sich, dass die primäre NSX Manager-Instanz ausgewählt ist.
  3. Vergewissern Sie sich, dass der Abschnitt Three Tier App vollständig eingeblendet wird.
  4. Klicken Sie auf die grüne Umschaltfläche, um Regel 4 zu deaktivieren.
  5. Klicken Sie auf Publish.

 

 

Auf Veröffentlichung der Firewall-Regeländerung warten

 

Warten Sie, bis die Änderung veröffentlicht wurde.

 

 

Bei „web-01a.corp.local“ anmelden

 

Starten Sie PuTTY.

 

 

Verbindung zu „web-01a.corp.local“ herstellen

 

  1. Wählen Sie die gespeicherte Sitzung web-01a.corp.local aus.
  2. Klicken Sie auf Open.

 

 

Lokalen Ausgang mithilfe des „Tracepath“-Befehls überprüfen

 

  1. Führen Sie den „Tracepath“-Befehl für den vPod-Router aus:
tracepath 192.168.100.1 -m2 -n
  1. Beachten Sie den Ausgang über 192.168.5.1. Das ist die Schnittstelle von RegionA01-Perimeter_GW.

 

 

Web-VM mithilfe von vMotion auf „RegionB0“ migrieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Hosts and Clusters.

 

 

Alle ausgeblendeten Elemente anzeigen

 

Zeigen Sie alle ausgeblendeten Elemente an, indem Sie auf den jeweiligen Pfeil klicken.

 

 

Web-VM mit vMotion migrieren

 

  1. Klicken Sie mit der rechten Maustaste auf web-01a.corp.local.
  2. Klicken Sie auf Migrate.

 

 

Migrationstyp auswählen

 

  1. Wählen Sie Change both compute resource and storage aus.
  2. Klicken Sie auf Select compute resource first.
  3. Klicken Sie auf Next.

 

 

Computing-Ressource auswählen

 

  1. Wählen Sie den Cluster RegionB01-COMP01 aus. Wählen Sie den Host esx-02b.corp.local aus.
  2. Klicken Sie auf Next.

 

 

Storage auswählen

 

  1. Wählen Sie RegionB01-ISCSI01-COMP01 aus.
  2. Klicken Sie auf Next.

 

 

Ordner auswählen

 

  1. Wählen Sie Discovered virtual machine aus.
  2. Klicken Sie auf Next.

 

 

 

Netzwerk auswählen

 

  1. Wählen Sie „universalwire“ Web_Tier_ULS aus.
  2. Klicken Sie auf Next.

Möglicherweise müssen Sie bei der Netzwerkauswahl rechts nach unten scrollen, um die Namen des universellen logischen Switch anzuzeigen.

 

 

vMotion-Priorität auswählen

 

Klicken Sie auf Next.

 

 

Einstellungen überprüfen

 

Überprüfen Sie die Auswahl und klicken Sie auf Finish.

 

 

Zur Ansicht „Tasks“ wechseln

 

  1. Klicken Sie auf das Haussymbol.
  2. Wählen Sie die Registerkarte Tasks aus.

 

 

Warten, bis vMotion-Vorgang abgeschlossen wurde

 

Warten Sie, bis die vMotion-Aufgaben abgeschlossen wurden.

 

 

Zu vSphere Web Client wechseln und „Hosts and Clusters“ auswählen

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Hosts and Clusters.

 

 

„web-01a“-Konsole starten

 

Stellen Sie eine Konsolenverbindung zu „web-01a“ her.

  1. Wählen Sie web-01a.corp.local aus.
  2. Wählen Sie die Registerkarte Summary aus.
  3. Wählen Sie den Bildschirmabschnitt zum Starten der Konsole aus.

 

 

Neuen Ausgang mithilfe des „Tracepath“-Befehls überprüfen

 

Verwenden Sie die Konsole, um den lokalen Ausgang zu überprüfen:

  1. Login: root
  2. Password: VMware1!
tracepath 192.168.100.1 -n -m 2

Überprüfen Sie den Ausgang durch 192.168.5.9. Das ist die Schnittstelle von RegionB01-Perimeter_GW.

 

Migration des Anwendungs-Stacks auf den sekundären Standort


In dieser Lektion migrieren Sie einen Anwendungs-Stack auf einen sekundären Standort.


 

Anwendungstopologie

 

In diesem Diagramm werden die Speicherorte der virtuellen Maschinen sowie der Datenverkehrsfluss dargestellt.

 

 

Neue Registerkarte öffnen

 

Klicken Sie auf die Schaltfläche für eine neue Registerkarte.

 

 

Dreischichtige Anwendung öffnen

 

Klicken Sie auf das Lesezeichen webapp.corp.local.

 

 

Dreischichtige Anwendung überprüfen

 

Überprüfen Sie, ob die Hands-on Lab-Seite mit der Multi-Tier-Anwendung geladen wird und Daten abgerufen werden.

 

 

Verbleibende Anwendungs-VMs mit vMotion auf „RegionB0“ migrieren

 

  1. Klicken Sie auf das Haussymbol.
  2. Klicken Sie auf Hosts and Clusters.

 

 

Alle ausgeblendeten Elemente anzeigen

 

Zeigen Sie alle ausgeblendeten Elemente an, indem Sie auf den jeweiligen Pfeil klicken.

 

 

Anwendungs-VM mit vMotion migrieren

 

  1. Klicken Sie mit der rechten Maustaste auf app-01a.corp.local.
  2. Klicken Sie auf Migrate.

 

 

Migrationstyp auswählen

 

  1. Wählen Sie Change both compute resource and storage aus.
  2. Klicken Sie auf Select compute resource first.
  3. Klicken Sie auf Next.

 

 

Computing-Ressource auswählen

 

  1. Wählen Sie den Cluster RegionB01-COMP01 aus.
  2. Klicken Sie auf Next.

 

 

Storage auswählen

 

  1. Wählen Sie RegionB01-ISCSI01-COMP01 aus.
  2. Klicken Sie auf Next.

 

 

Ordner auswählen

 

  1. Wählen Sie Discovered virtual machine aus.
  2. Klicken Sie auf Next.

Möglicherweise müssen Sie bei der Netzwerkauswahl rechts nach unten scrollen, um die Namen des universellen logischen Switch anzuzeigen.

 

 

Netzwerk auswählen

 

  1. Wählen Sie „universalwire“ App_Tier_ULS aus.
  2. Klicken Sie auf Next.

Möglicherweise müssen Sie bei der Netzwerkauswahl rechts nach unten scrollen, um die Namen des universellen logischen Switch anzuzeigen.

 

 

vMotion-Priorität auswählen

 

Klicken Sie auf Next.

 

 

Einstellungen überprüfen

 

Überprüfen Sie die Auswahl und klicken Sie auf Finish.

 

 

VM „web-01a“mit vMotion migrieren

 

  1. Klicken Sie mit der rechten Maustaste auf web-01a.corp.local.
  2. Klicken Sie auf Migrate.

HINWEIS: Migrieren Sie NICHT „web-02a.corp.local“. Aufgrund der Hands-on Lab-Struktur und zur Vermeidung einer Neukonfiguration des Lastausgleichs sollten Sie „web-02a.corp.local“ nicht migrieren.

 

 

Migrationstyp auswählen

 

  1. Wählen Sie Change both compute resource and storage aus.
  2. Klicken Sie auf Select compute resource first.
  3. Klicken Sie auf Next.

 

 

Computing-Ressource auswählen

 

  1. Wählen Sie den Cluster RegionB01-COMP01 aus.
  2. Klicken Sie auf Next.

 

 

Storage auswählen

 

  1. Wählen Sie RegionB01-ISCSI01-COMP01 aus.
  2. Klicken Sie auf Next.

 

 

Ordner auswählen

 

  1. Wählen Sie Discovered virtual machine aus.
  2. Klicken Sie auf Next.

Möglicherweise müssen Sie bei der Netzwerkauswahl rechts nach unten scrollen, um die Namen des universellen logischen Switch anzuzeigen.

 

 

Netzwerk auswählen

 

  1. Wählen Sie „universalwire“ Web_Tier_ULS aus.
  2. Klicken Sie auf Next.

Möglicherweise müssen Sie bei der Netzwerkauswahl rechts nach unten scrollen, um die Namen des universellen logischen Switch anzuzeigen.

 

 

vMotion-Priorität auswählen

 

Klicken Sie auf Next.

 

 

Einstellungen überprüfen

 

Überprüfen Sie die Auswahl und klicken Sie auf Finish.

 

 

Verbleibende Anwendungs-VMs migrieren

 

Wiederholen Sie die Schritte, um db-01a.corp.local zu migrieren. Ändern Sie die Netzwerkauswahl in DB_Tier_ULS.

Überprüfen Sie nach Abschluss der DB-VM-Migration, ob die Webseite mit der dreischichtigen Anwendung geladen wird. Im Topologiediagramm wird der Speicherort der VMs nach der Migration angezeigt.

HINWEIS: MIGRIEREN SIE NICHT „web-02a.corp.local“. Aufgrund der Hands-on Lab-Struktur und zur Vermeidung einer Neukonfiguration des Lastausgleichs sollten Sie „web-02a.corp.local“ nicht migrieren.

 

 

Dreischichtige Anwendung testen

 

Klicken Sie auf die Schaltfläche für eine neue Registerkarte.

 

 

Dreischichtige Anwendung öffnen

 

Da „web-01a.corp.local“ auf Standort B migriert wurde, muss für den Zugriff auf diesen spezifischen Server eine andere URL verwendet werden.  

Fügen Sie die folgende URL in den Browser ein:

 

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

HINWEIS: Beim Laden der Website wird möglicherweise eine Zertifikatswarnung angezeigt. Ignorieren Sie diese Meldung und rufen Sie die Website auf.  

HINWEIS: Sie können auch „web-02a.corp.local“ direkt mit der folgenden URL testen: https://web-02a/cgi-bin/app.py.

 

Modul 4 – Fazit


In diesem Modul haben Sie einen Anwendungs-Stack von einem Standort auf einen anderen migriert. Der lokale Ausgang des Datenverkehrs wurde überprüft, um ein optimales Muster für ausgehenden Datenverkehr zu gewährleisten. Mit dieser Konfiguration kann eine Aktiv-Aktiv-Rechenzentrumskonfiguration realisiert werden. Dadurch ist es möglich, Maschinen nach Bedarf in einer Umgebung zu migrieren.


 

Abschluss von Modul 4

Sie haben Modul 4 abgeschlossen.

Weitere Informationen zu universellen NSX-Konfigurationen finden Sie im vCenter-übergreifenden Installationsleitfaden unter der folgenden URL:

Fahren Sie mit einem beliebigen Modul unten fort.

 Hands-on Lab-Dozent:

  • Module 1 – 5: Brian Wilson, Staff Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Modul 5 – VPN-Konfiguration (15 Minuten)

Anleitung für das Modul


In diesem Modul konfigurieren Sie das NSX Edge Gateway für L2-VPN-Services. NSX Edge unterstützt mehrere VPN-Typen. Mit SSL-VPN-Plus können Remote-Anwender auf private Unternehmensanwendungen zugreifen. IPSec-VPN bietet Standort-zu-Standort-Konnektivität zwischen einer NSX Edge-Instanz und Remote-Standorten. Mithilfe von L2-VPN lässt sich das Rechenzentrum erweitern, indem virtuelle Maschinen ihre Netzwerkkonnektivität über geografische Grenzen hinweg beibehalten. 

Dieses Modul umfasst Folgendes:

  • L2-VPN-Services

-VPN-Konfiguration


 

Hands-on Lab-Topologie

 

In diesem Modul verwenden Sie die oben dargestellte logische Netzwerktopologie. Sie konfigurieren eine L2-VPN-Verbindung zwischen zwei logischen Switch-Segmenten. Jedes Segment enthält eine virtuelle Maschine im selben Subnetzadressraum. Mithilfe von L2-VPN erstellen Sie einen Tunnel zwischen beiden logischen Remote-Switches, sodass ein einziges, durchgehendes L2-Segment entsteht. Sie überprüfen außerdem die Konnektivität zwischen den beiden VMs über die VPN-Verbindung.

 

 

VPN-Typen: SSL-VPN im Überblick

 

Vor der Konfiguration von L2-VPN erhalten Sie im Folgenden einen Überblick über die verschiedenen VPN-Services von NSX. Mit SSL-VPN-Plus können Remote-Anwender eine sichere Verbindung zu privaten Netzwerken hinter einem NSX Edge Gateway herstellen. Sie können damit auf Server und Anwendungen in privaten Netzwerken zugreifen.

 

 

VPN-Typen: IPsec-VPN im Überblick

 

NSX Edge unterstützt Standort-zu-Standort-IPSec-VPN zwischen einer NSX Edge-Instanz und Remote-Standorten. IPSec gewährleistet VPN-Interoperabilität zwischen NSX Edge-Geräten und VPN-Geräten von Drittanbietern. Zwischen der NSX Edge-Instanz und Remote-VPN-Routern werden Zertifikatauthentifizierung, Pre-Shared Key(PSK)-Modus und IP-Unicast-Datenverkehr unterstützt. Dynamische Routing-Protokolle werden nicht unterstützt.

Hinter jedem Remote-VPN-Router können mehrere Subnetze für die Verbindung zum internen Netzwerk hinter einer NSX Edge-Instanz über IPSec-Tunnel konfiguriert werden.

 

 

L2-VPN im Überblick

 

Mit L2-VPN können Sie einen Tunnel zwischen zwei Standorten konfigurieren. Virtuelle Maschinen bleiben im selben Subnetz, auch wenn sie zwischen diesen Standorten verschoben werden. Damit lässt sich Ihr Rechenzentrum erweitern. Eine NSX Edge-Instanz an einem Standort kann alle Services für virtuelle Maschinen am anderen Standort bereitstellen.

L2-VPN kann verwendet werden, um VLAN mit VLAN, VXLAN mit VLAN und/oder VXLAN mit VXLAN zu verbinden.

In diesem Hands-on Lab konfigurieren Sie L2-VPN zwischen zwei VXLAN-Segmenten (zwei logischen NSX-Switches). 

 

Aktivieren des VPN-Servers


In dieser Lektion erstellen Sie einen VPN-Server.


 

L2-VPN-Server hinzufügen

Der L2-VPN-Server ist die NSX Edge-Quellinstanz, mit der das L2-VPN verbunden werden soll.

Voraussetzungen: L2-VPN-Server und -Client müssen unterschiedliche interne IP-Adressen zugewiesen sein. Sie können sich jedoch im selben Subnetz befinden.

 

 

Auf vSphere Web Client zugreifen

 

  1. Starten Sie den vSphere Web Client über das Google Chrome-Symbol auf dem Desktop.

 

 

„Networking & Security“ auswählen

 

  1. Klicken Sie auf das Haussymbol.
  2. Scrollen Sie nach unten und wählen Sie Networking & Security aus.

 

 

„NSX Edges“ auswählen

 

  1. Wählen Sie NSX Edges aus.

 

 

Primäre NSX Manager-Instanz überprüfen

 

  1. Überprüfen Sie, ob für NSX Manager die Einstellung 192.168.110.42 (Role: Primary) festgelegt ist.

 

 

Perimeter-Router auswählen

 

  1. Doppelklicken Sie auf den Router RegionA0_Perimeter_GW.

 

 

L2-VPN-Trunk-Schnittstelle konfigurieren

 

  1. Wählen Sie Manage aus.
  2. Wählen Sie Interfaces aus.
  3. Wählen Sie vNIC-Schnittstelle Nr. 2 aus.
  4. Klicken Sie auf das Bearbeitungssymbol.

 

 

Trunk-Konfiguration fortsetzen

 

  1. Nennen Sie die neue Schnittstelle L2VPN Trunk.
  2. Wählen Sie unter „Type“ Trunk aus.
  3. Klicken Sie neben der Option „Connected To“ auf Select.
  4. Wählen Sie im neuen Fenster Distributed Virtual Port Group aus.
  5. Wählen Sie VM-RegionA01-VDS-MGMT aus.
  6. Klicken Sie auf OK.

 

 

 

Subschnittstelle konfigurieren

 

Klicken Sie zum Hinzufügen der Subschnittstelle auf das Pluszeichen.

 

 

Einstellungen für die Subschnittstelle

 

  1. Nennen Sie die Subschnittstelle Sub-VPN-Logical-SW-A.
  2. Verwenden Sie die Tunnel-ID 101.
  3. Wählen Sie unter „Backing Type“ Network aus.
  4. Klicken Sie neben „Network“ auf Select.
  5. Wählen Sie den logischen Switch VPN_Logical_SW_A aus.
  6. Klicken Sie auf OK.

 

 

Subnetz zu Schnittstelle hinzufügen

 

  1. Klicken Sie auf das Pluszeichen.
  2. Geben Sie die primäre Adresse 172.16.101.1 ein.
  3. Geben Sie unter „Subnet Prefix Length“ den Wert 24 ein.
  4. Klicken Sie auf OK.

 

 

Trunk-Konfiguration abschließen

 

Klicken Sie auf „OK“.

 

 

L2-VPN-Server einrichten

 

  1. Wählen Sie die Registerkarte VPN aus.
  2. Wählen Sie L2 VPN aus.
  3. Klicken Sie auf Change.

 

 

Listener konfigurieren

 

  1. Listener IP: 192.168.100.3 (Primary)
  2. Listener Port: 443
  3. Wählen Sie unter „Encryption Algorithm“ AES128-GCM-SHA256 aus.
  4. Klicken Sie auf OK.

 

 

L2-VPN-Service aktivieren

 

  1. Klicken Sie auf Start.
  2. Klicken Sie auf Publish Changes.

 

 

Neue Standortkonfiguration hinzufügen

 

  1. Klicken Sie auf das grüne Pluszeichen, um eine neue Standortkonfiguration hinzuzufügen.

 

 

Details der Standortkonfiguration bearbeiten

 

  1. Aktivieren Sie das Kontrollkästchen „Enable Peer Site“.
  2. Geben Sie RegionB-L2VPN in das Feld „Name“ ein.
  3. Geben Sie vpn-user in das Feld „User Id“ein.
  4. Geben Sie unter „Password“ VMware1!VMware1! ein (Kennwort muss mindestens zehn Zeichen umfassen).
  5. Geben Sie im Feld „Confirm Password“ nochmals VMware1!VMware1! ein.
  6. Klicken Sie auf Select Sub Interfaces.

 

 

Subschnittstelle auswählen

 

  1. Wählen Sie „Sub-VPN-Logical-SW-A“ aus.
  2. Klicken Sie auf den Rechtspfeil.
  3. Klicken Sie auf „OK“.
  4. Klicken Sie auf „OK“.

 

 

Änderungen veröffentlichen

 

Klicken Sie auf „Publish Changes“.

 

Aktivieren des VPN-Clients


In dieser Lektion erstellen Sie einen VPN-Client.


 

L2-VPN-Client hinzufügen

Der L2-VPN-Client ist die NSX Edge-Quellinstanz, die die Kommunikation mit dem Ziel-Edge (L2-VPN-Server) initiiert.

 

 

„Networking & Security“ auswählen

 

  1. Klicken Sie auf das Haussymbol.
  2. Scrollen Sie nach unten und wählen Sie Networking & Security aus.

 

 

„NSX Edges“ auswählen

 

  1. Wählen Sie NSX Edges aus.

 

 

Sekundäre NSX Manager-Instanz überprüfen

 

  1. Wählen Sie die NSX Manager-Instanz mit der Einstellung 192.168.210.42 (Role: Secondary) aus.

 

 

Perimeter-Router auswählen

 

  1. Doppelklicken Sie auf den Router RegionB0_Perimeter_GW.

 

 

L2-VPN-Trunk-Schnittstelle konfigurieren

 

  1. Wählen Sie vNIC-Schnittstelle Nr. 2 aus.
  2. Klicken Sie auf das Bearbeitungssymbol.

 

 

Trunk-Konfiguration fortsetzen

 

  1. Nennen Sie die neue Schnittstelle L2VPN Trunk.
  2. Wählen Sie unter „Type“ Trunk aus.
  3. Klicken Sie neben der Option „Connected To“ auf Select.
  4. Wählen Sie im neuen Fenster Distributed Virtual Port Group aus.
  5. Wählen Sie VM-RegionB01-vDS-COMP aus.
  6. Klicken Sie auf OK.

 

 

 

Subschnittstelle konfigurieren

 

Klicken Sie zum Hinzufügen der Subschnittstelle auf das Pluszeichen.

 

 

Einstellungen für die Subschnittstelle

 

  1. Nennen Sie die Subschnittstelle Sub-VPN-Logical-SW-B.
  2. Verwenden Sie die Tunnel-ID 101.
  3. Wählen Sie unter „Backing Type“ Network aus.
  4. Klicken Sie neben „Network“ auf Select.
  5. Wählen Sie den logischen Switch VPN_Logical_SW_B aus.
  6. Klicken Sie auf OK.

 

 

Subnetz zu Schnittstelle hinzufügen

 

  1. Klicken Sie auf das Pluszeichen.
  2. Geben Sie die primäre Adresse 172.16.101.2 ein.
  3. Geben Sie unter „Subnet Prefix Length“ den Wert 24 ein.
  4. Klicken Sie auf OK.

 

 

Trunk-Konfiguration abschließen

 

Klicken Sie auf OK.

 

 

L2-VPN-Client einrichten

 

  1. Wählen Sie die Registerkarte VPN aus.
  2. Wählen Sie L2 VPN aus.
  3. Wählen Sie Client aus.
  4. Klicken Sie auf Change.

 

 

Client-Einstellungen konfigurieren

 

  1. Server Address: 192.168.100.3
  2. Server Port: 443
  3. Wählen Sie unter „Encryption Algorithm“ AES128-GCM-SHA256 aus.
  4. Klicken Sie auf Select Sub Interfaces.

 

 

Subschnittstelle auswählen

 

  1. Wählen Sie Sub-VPN-Logical-SW-B aus.
  2. Klicken Sie auf den Rechtspfeil.
  3. Klicken Sie auf OK.

 

 

Client-Einstellungen abschließen

 

  1. Geben Sie vpn-user in das Feld „User Id“ein.
  2. Geben Sie unter „Password“ VMware1!VMware1! ein (Kennwort muss mindestens zehn Zeichen umfassen).
  3. Geben Sie im Feld „Confirm Password“ nochmals VMware1!VMware1! ein.
  4. Klicken Sie auf OK.

 

 

L2-VPN-Service aktivieren

 

  1. Klicken Sie auf Start.
  2. Klicken Sie auf Publish Changes.

 

Überprüfen der VPN-Verbindung


In dieser Lektion überprüfen Sie die VPN-Verbindung.


 

L2-VPN-Statistiken anzeigen

Sie können L2-VPN-Statistiken, z.B. Tunnelstatus, gesendete und empfangene Byte usw., für die NSX Edge-Bereitstellung anzeigen.

 

 

 

Tunnelstatus überprüfen

 

  1. Klicken Sie auf den Pfeil nach unten, um die Ansicht „Tunnel Status“ zu erweitern.
  2. Vergewissern Sie sich, dass der Tunnelstatus Up lautet.

 

 

„Hosts and Clusters“ auswählen

 

  1. Klicken Sie auf das Haussymbol.
  2. Wählen Sie Hosts and Clusters aus.

 

 

Bei VM auf dem L2-VPN-Switch anmelden

 

  1. Wählen Sie vpn-sv-01a.corp.local aus.
  2. Wählen Sie die Registerkarte Summary aus.
  3. Klicken Sie in den Bildschirmbereich, um die Konsole aufzurufen.

 

 

L2-Nachbarschaft mit „vpn-sv-02a“ überprüfen

 

Gehen Sie in der neuen Web-Registerkarte wie folgt vor:

Klicken Sie in den Konsolenbereich und geben Sie Folgendes ein:

Login: root

Password: VMware1!

Führen Sie für „vpn-sv-02a“ einen Ping-Test durch, um die Konnektivität über den eingerichteten VPN-Tunnel zu testen.

ping vpn-sv-02a 

 

Der Ping-Test ist erfolgreich. Sie dehnen das Subnetz 172.16.101.0/24 zwischen Standorten und über ein L3-Netzwerk aus.

 

Modul 5 – Fazit


In diesem Modul haben Sie L2-VPN zwischen lokalen logischen Switches (VXLAN-Segmenten) konfiguriert. Jedes Segment befand sich in einem anderen Rechenzentrum und war nicht über universelle Konstrukte verbunden. Mit L2-VPN können die beiden VMs mittels „Layer 2 over Layer 3“-Kapselung kommunizieren, wobei sich VXLAN nicht über beide Standorte erstrecken muss.   


 

Abschluss von Modul 5

Sie haben Modul 5 abgeschlossen.

Weitere Informationen zu NSX-L2-VPN-Konfigurationen finden Sie unter der nachstehenden URL:

Fahren Sie mit einem beliebigen Modul unten fort.

 Hands-on Lab-Dozent:

  • Module 1 – 5: Brian Wilson, Staff Systems Engineer, USA

 

 

Hands-on Lab beenden

 

Klicken Sie auf die Schaltfläche END, wenn Sie Ihr Hands-on Lab beenden möchten.  

 

Schlussbemerkung

Vielen Dank für Ihre Teilnahme an den VMware Hands-on Labs. Besuchen Sie http://hol.vmware.com/ um an weiteren Online-Labs teilzunehmen.

Lab SKU: HOL-1925-01-NET

Version: 20190301-152924