In diesem Kapitel werden typische Fehlerszenarien und deren Auswirkungen auf die Komponenten des NSX-Routing-Subsystems beschrieben.

NSX Manager

Tabelle 1. NSX Manager: Fehlermodi und -auswirkungen
Fehlermodus Fehlerauswirkungen
Verlust der Netzwerkkonnektivität mit der NSX Manager-VM
  • Kompletter Ausfall aller NSX Manager-Funktionen, einschließlich der CRUD-Vorgänge für das NSX-Routing/-Bridging
  • Kein Verlust von Konfigurationsdaten
  • Kein Ausfall der Datenebene oder Steuerungskomponenten
Verlust der Netzwerkkonnektivität zwischen NSX Manager und ESXi-Hosts oder RabbitMQ-Serverfehler
  • Wenn eine DLR-Kontroll-VM oder ein ESG auf den betroffenen Hosts ausgeführt wird, scheitern die CRUD-Vorgänge
  • Das Erstellen und Löschen von DLR-Instanzen auf betroffenen Hosts scheitert
  • Kein Verlust von Konfigurationsdaten
  • Kein Ausfall der Datenebene oder Steuerungskomponenten
  • Alle dynamischen Routing-Updates werden weiterhin durchgeführt
Verlust der Netzwerkkonnektivität zwischen NSX Manager und den Controllern
  • Das Erstellen, Aktualisieren und Löschen für verteiltes NSX-Routing und Bridging scheitert
  • Kein Verlust von Konfigurationsdaten
  • Kein Ausfall der Datenebene oder Steuerungskomponenten
NSX Manager-VM wurde entfernt (Datenspeicherfehler)
  • Kompletter Ausfall aller NSX Manager-Funktionen, einschließlich der CRUD-Vorgänge für das NSX-Routing/-Bridging
  • Gefahr, dass eine Teilmenge von Routing/Bridging-Instanzen verwaist, wenn NSX Manager auf einer älteren Konfiguration wiederhergestellt wird und eventuell eine manuelle Bereinigung bzw. eine manueller Abgleich erforderlich ist
  • Kein Ausfall der Datenebene oder Steuerungskomponenten, sofern kein Abgleich erforderlich ist

Controller-Cluster

Tabelle 2. NSX Controller: Fehlermodi und -auswirkungen
Fehlermodus Fehlerauswirkungen
Controller-Cluster verliert Netzwerkkonnektivität mit ESXi-Hosts
  • Kompletter Ausfall der Funktionen der DLR-Steuerungskomponente (Erstellen, Aktualisieren und Löschen von Routen, einschließlich dynamischer Routen)
  • Ausfall der Funktionen der DLR-Verwaltungskomponente (Erstellen, Aktualisieren und Löschen von LIFs auf Hosts)
  • Die VXLAN-Weiterleitung wird beeinträchtigt, wodurch der End-to-End-Weiterleitungsvorgang (L2+L3) scheitern kann
  • Die Datenebene funktioniert weiterhin auf der Basis des letzten bekannten Status
Ein oder zwei Controller verlieren die Konnektivität mit den ESXi-Hosts
  • Wenn der betroffene Controller nach wie vor andere Controller in diesem Cluster erreicht, treten für alle DLR-Instanzen, die von diesem Controller gesteuert werden, die oben beschriebenen Auswirkungen auf. Andere Controller übernehmen die Aufgaben nicht automatisch
Ein Controller verliert die Netzwerkkonnektivität mit anderen Controllern (oder vollständig)
  • Zwei noch vorhandene Controller übernehmen die VXLANs und DLRs, die vom isolierten Controller gesteuert wurden
  • Der betroffene Controller wechselt in den schreibgeschützten Modus, verwirft seine Sitzungen auf den Hosts und verweigert die Annahme neuer Sitzungen
Controller verlieren die gegenseitige Konnektivität
  • Alle Controller wechseln in den schreibgeschützten Modus, trennen ihre Verbindungen mit den Hosts und verweigern die Herstellung neuer Verbindungen
  • Das Erstellen, Aktualisieren und Löschen für alle DLR-LIFs und Routen (einschließlich dynamischer Routen) scheitert
  • Die NSX-Routing-Konfiguration (LIFs) kann eventuell zwischen NSX Manager und Controller-Cluster nicht mehr synchronisiert werden, sodass ein manueller Eingriff zur Neusynchronisierung erforderlich wird
  • Hosts werden weiterhin auf der Basis des letzten bekannten Status der Steuerungskomponenten betrieben
Eine Controller-VM ist verloren gegangen
  • Controller-Cluster verliert Redundanz
  • Verwaltungs-/Steuerungskomponenten funktionieren weiterhin normal
Zwei Controller-VMs sind verloren gegangen
  • Die übrigen Controller wechseln in den schreibgeschützten Modus. Die Auswirkungen sind identisch mit jenen beim Verlust der gegenseitigen Konnektivität von Controllern (siehe weiter oben). Es ist vermutlich eine manuelle Cluster-Wiederherstellung erforderlich

Hostmodule

netcpa benötigt den SSL-Schlüssel und das Zertifikat des Hosts sowie die SSL-Fingerabdrücke, um eine sichere Kommunikation mit den Controllern einzurichten. Diese werden vom NSX Manager über den Nachrichtenbus (von vsfwd bereitgestellt).

Wenn der Zertifikataustausch scheitert, kann netcpa keine Verbindung mit den Controllern herstellen.

Hinweis: Dieser Abschnitt enthält keine Erläuterungen zu Fehlern von Kernelmodulen. Bei diesen handelt es sich um schwerwiegende PSOD-Fehler, die selten auftreten.

Tabelle 3. Hostmodule: Fehlermodi und -auswirkungen
Fehlermodus Fehlerauswirkungen
vsfwd verwendet die Benutzername/Kennwort-Authentifizierung für den Zugriff auf den Nachrichtenbusserver, die zeitlich begrenzt sein kann
  • Wenn ein vsfwd-Vorgang auf einem neu vorbereiteten ESXi-Host den NSX Manager nicht innerhalb von zwei Stunden erreichen kann, laufen die temporären, bei der Installation vergebenen Anmeldedaten ab und der Nachrichtenbus ist auf diesem Host nicht mehr funktionsfähig
Die Auswirkungen von Fehlern des Nachrichtenbus-Client (vsfwd) sind vom entsprechenden Zeitpunkt abhängig
Bei einem Scheitern, bevor andere Elemente der NSX-Steuerungskomponente einen stabilen Ausführungsstatus erreicht haben
  • Das verteilte Routing auf dem Host wird angehalten, da der Host nicht mehr mit den Controllern kommunizieren kann
  • Der Host ruft keine DLR-Instanzen vom NSX Manager ab
Bei einem Scheitern, nachdem der Host einen stabilen Status erreicht hat
  • ESGs und DLR-Kontroll-VMs, die auf dem Host ausgeführt werden, können keine Konfigurations-Updates empfangen
  • Der Host ruft neue DLRs nicht ab und kann vorhandene DLRs nicht löschen
  • Der Datenpfad des Hosts wird weiterhin auf der Basis der Konfiguration des Hosts zum Zeitpunkt des Fehlers verwendet
Tabelle 4. netcpa: Fehlermodi und -auswirkungen
Fehlermodus Fehlerauswirkungen
Die Auswirkungen von Fehlern des Steuerungskomponenten-Agenten (netcpa) sind vom entsprechenden Zeitpunkt abhängig
Bei einem Scheitern, bevor die NSX-Datenpfad-Kernelmodule einen stabilen Ausführungsstatus erreicht haben
  • Das verteilte Routing auf dem Host wird angehalten
Bei einem Scheitern, nachdem der Host einen stabilen Status erreicht hat
  • Die DLR-Kontroll-VMs, die auf dem Host ausgeführt werden, können die Updates ihrer Weiterleitungstabellen nicht an die Controller senden
  • Der Datenpfad für das verteilte Routing empfängt keine LIF- oder Routen-Updates von Controllern, wird aber auf der Basis des Status vor dem Fehlerzeitpunkt weiterhin verwendet

DLR-Kontroll-VM

Tabelle 5. DLR-Kontroll-VM: Fehlermodi und -auswirkungen
Fehlermodus Fehlerauswirkungen
DLR-Kontroll-VM ist verloren gegangen oder ausgeschaltet
  • Das Erstellen, Aktualisieren und Löschen für diese DLR-LIFs und Routen scheitert
  • Dynamische Routen-Updates werden nicht an die Hosts gesendet (einschließlich Entnahme von Präfixen, die über eine jetzt aufgehobene Nachbarschaft empfangen wurden)
DLR-Kontroll-VM verliert die Konnektivität mit NSX Manager und Controllern
  • Es hat die gleichen Auswirkungen, mit einer Ausnahme: Wenn die DLR-Kontroll-VM und ihre Routing-Nachbarschaften noch aktiv sind, ist der Datenverkehr zu und von zuvor abgerufenen Präfixen nicht betroffen
DLR-Kontroll-VM verliert die Konnektivität mit NSX Manager
  • Die NSX Manager-Vorgänge zum Erstellen, Aktualisieren und Löschen dieser DLR-LIFs und Routen scheitern und werden nicht erneut vorgenommen
  • Dynamische Routing-Updates werden weiterhin übermittelt
DLR-Kontroll-VM verliert die Konnektivität mit den Controllern
  • Alle Routing-Änderungen (statische oder dynamische) für diesen DLR werden nicht an die Hosts übermittelt