Die NSX-Befehlszeilenschnittstelle kann detaillierte Verfolgungsprotokolle bieten, Pakete erfassen und die Metriken für die Fehlerbehebung des Lastausgleichsdiensts überprüfen.
Problem
Das Load Balancing lässt sich nicht wie gewünscht durchführen.
Lösung
- Aktivieren Sie SSH für die virtuelle Appliance oder prüfen Sie, ob dies möglich ist. Beim Edge-Dienst-Gateway handelt es sich um eine virtuelle Appliance, bei der während der Bereitstellung die Option zur Aktivierung von SSH besteht. Wenn Sie SSH aktivieren müssen, wählen Sie die gewünschte Appliance aus. Klicken Sie dann im Menü Aktionen (Actions) auf Ändern der CLI-Anmeldedaten (Change CLI Credentials).
- Das Edge-Dienst-Gateway bietet mehrere Anzeigebefehle, mit denen Sie den Laufzeit- und den Konfigurationsstatus einsehen können. Mit diesen Befehlen können Sie Informationen zur Konfiguration und zu Statistiken anzeigen.
nsxedge> show configuration loadbalancer nsxedge> show configuration loadbalancer virtual [virtual-server-name] nsxedge> show configuration loadbalancer pool [pool-name] nsxedge> show configuration loadbalancer monitor [monitor-name] nsxedge> show configuration loadbalancer profile [profile-name] nsxedge> show configuration loadbalancer rule [rule-name]
- Damit das Load-Balancing und NAT ordnungsgemäß funktionieren, müssen Sie die Firewall aktivieren. Führen Sie den Befehl #show firewall aus. Wenn dieser Befehl keine hilfreiche Ausgabe bewirkt, finden Sie weitere Informationen im Abschnitt Überprüfung der Load-Balancer-Konfiguration und Fehlerbehebung über die Benutzeroberfläche.
- Damit der Load Balancer ordnungsgemäß funktioniert, ist NAT erforderlich. Führen Sie den Befehl show nat aus. Wenn dieser Befehl keine hilfreiche Ausgabe bewirkt, finden Sie weitere Informationen im Abschnitt Überprüfung der Load-Balancer-Konfiguration und Fehlerbehebung über die Benutzeroberfläche.
- Die Firewall sollte also aktiviert sein und für den Load Balancer sollten NAT-Regeln vorliegen. Außerdem sollten Sie sicherstellen, dass der Load-Balancing-Prozess aktiviert ist. Mit dem Befehl show service loadbalancer können Sie den Status der Load-Balancer-Engine überprüfen (L4/L7).
nsxedge> show service loadbalancer haIndex: 0 ----------------------------------------------------------------------- Loadbalancer Services Status: L7 Loadbalancer : running ----------------------------------------------------------------------- L7 Loadbalancer Statistics: STATUS PID MAX_MEM_MB MAX_SOCK MAX_CONN MAX_PIPE CUR_CONN CONN_RATE CONN_RATE_LIMIT MAX_CONN_RATE running 1580 0 2081 1024 0 0 0 0 0 ----------------------------------------------------------------------- L4 Loadbalancer Statistics: MAX_CONN ACT_CONN INACT_CONN TOTAL_CONN 0 0 0 0 Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn- Verwenden Sie den show service loadbalancer session-Befehl, um die Sitzungstabelle des Lastausgleichsdiensts anzuzeigen. Wenn im System Datenverkehr vorhanden ist, werden Sitzungen angezeigt.
nsxedge> show service loadbalancer session ----------------------------------------------------------------------- L7 Loadbalancer Statistics: STATUS PID MAX_MEM_MB MAX_SOCK MAX_CONN MAX_PIPE CUR_CONN CONN_RATE CONN_RATE_LIMIT MAX_CONN_RATE running 1580 0 2081 1024 0 0 0 0 0 -----------------L7 Loadbalancer Current Sessions: 0x2192df1f300: proto=unix_stream src=unix:1 fe=GLOBAL be=<NONE> srv=<none> ts=09 age=0s calls=2 rq[f=c08200h, i=0,an=00h,rx=20s,wx=,ax=] rp[f=008000h,i=0,an=00h,rx=,wx=,ax=] s0=[7,8h,fd=1,ex=] s1=[7,0h,fd=-1,ex=] exp=19s ----------------------------------------------------------------------- L4 Loadbalancer Statistics: MAX_CONN ACT_CONN INACT_CONN TOTAL_CONN 0 0 0 0 L4 Loadbalancer Current Sessions: pro expire state source virtual destination
- Überprüfen Sie den show service loadbalancer-Befehl, um Schicht-7-Status verfügbarer Tabellen des Lastausgleichsdiensts anzuzeigen. Beachten Sie, dass in dieser Tabelle keine Informationen zu beschleunigten virtuellen Servern angezeigt werden.
nsxedge> show service loadbalancer table ----------------------------------------------------------------------- L7 Loadbalancer Sticky Table Status: TABLE TYPE SIZE(BYTE) USED(BYTE)
- Verwenden Sie den show service loadbalancer session-Befehl, um die Sitzungstabelle des Lastausgleichsdiensts anzuzeigen. Wenn im System Datenverkehr vorhanden ist, werden Sitzungen angezeigt.
- Wenn alle erforderlichen Dienste ordnungsgemäß ausgeführt werden, prüfen Sie die Routing-Tabelle. Es muss eine Route zum Client und zu den Servern vorliegen. Mit den Befehlen show ip route und show ip forwarding können Sie anzeigen, welche Routen zu den Schnittstellen vorliegen.
- Stellen Sie sicher, dass es einen ARP-Eintrag für die Systeme, z. B. das Gateway oder den nächsten Hop, und die Backend-Server gibt. Prüfen können Sie dies mit dem Befehl show arp.
- Anhand der Informationen aus den Protokollen lässt sich Datenverkehr identifizieren, der bei der Diagnostizierung von Problemen hilfreich sein kann. Mit den Befehlen show log oder show log follow können Sie das Protokoll verfolgen, mit dem Sie den Datenverkehr identifizieren können. Beachten Sie, dass für die Ausführung des Load Balancers Protokollierung (Logging) aktiviert und auf Info oder Debug festgelegt werden muss.
nsxedge> show log 2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpuset 2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpu 2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpuacct ... - Nachdem sichergestellt wurde, dass die grundlegenden Dienste mit den korrekten Pfaden zu den Clients ausgeführt werden, sehen wir uns an, was in der Anwendungsschicht abläuft. Mit dem Befehl show service loadbalancer pool können Sie die Poolstatus des Lastausgleichsdiensts (L4/L7) anzeigen. Ein Poolmitglied muss aktiv sein, um die Inhalte zu unterstützen. Für gewöhnlich sind mehrere Mitglieder vonnöten, da das Anforderungsvolumen die Kapazität einer einzelnen Arbeitslast überschreitet. Wenn die Zustandsüberwachung durch eine interne Prüfung des Systemzustands erfolgt, zeigen die Ausgabe last state change time (Zeitpunkt der letzten Statusänderung) und failure reason (Grund für Fehler) an, wenn die Prüfung des Systemzustands fehlschlägt. Wenn die Zustandsüberwachung durch einen Überwachungsdienst erfolgt, wird neben den oben genannten zwei Ausgaben auch last check time (Zeitpunkt der letzten Prüfung) angezeigt.
nsxedge> show service loadbalancer pool ----------------------------------------------------------------------- Loadbalancer Pool Statistics: POOL Web-Tier-Pool-01 | LB METHOD round-robin | LB PROTOCOL L7 | Transparent disabled | SESSION (cur, max, total) = (0, 0, 0) | BYTES in = (0), out = (0) +->POOL MEMBER: Web-Tier-Pool-01/web-01a, STATUS: UP | | HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK | | | LAST STATE CHANGE: 2016-05-16 07:02:00 | | SESSION (cur, max, total) = (0, 0, 0) | | BYTES in = (0), out = (0) +->POOL MEMBER: Web-Tier-Pool-01/web-02a, STATUS: UP | | HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK | | | LAST STATE CHANGE: 2016-05-16 07:02:01 | | SESSION (cur, max, total) = (0, 0, 0) | | BYTES in = (0), out = (0) - Überprüfen Sie den Status der Dienstüberwachung (OK, WARNUNG, KRITISCH), um den Zustand aller konfigurierten Backend-Server einzusehen.
nsxedge> show service loadbalancer monitor ----------------------------------------------------------------------- Loadbalancer Health Check Statistics: MONITOR PROVIDER POOL MEMBER HEALTH STATUS built-in Web-Tier-Pool-01 web-01a default_https_monitor:L7OK built-in Web-Tier-Pool-01 web-02a default_https_monitor:L7OKFür den Befehl show service load balancer monitor werden drei Arten von Zustandsüberwachungswerten in der Ausgabe der Befehlszeilenschnittstelle angezeigt:- Integrated (integriert): Die Zustandsprüfung ist aktiviert und wird von der L7-Engine (HA-Proxy) ausgeführt.
- Monitor Service (Überwachungsdienst): Die Zustandsprüfung ist aktiviert und wird von der Überwachungsdienst-Engine (NAGIOS) ausgeführt. Den Ausführungsstatus des Überwachungsdienstes können Sie mit den Befehlen
show service monitorundshow service monitor servicein der Befehlszeilenschnittstelle überprüfen. Das Feld Status sollte den Wert OK, WARNUNG oder KRITISCH enthalten. - Not Defined (nicht definiert): Die Zustandsprüfung ist deaktiviert.
Tabelle 1. Systemzustand mit Beschreibung Systemzustand Beschreibung Built-in - UNK: Unbekannt
- INI: Wird initialisiert
- SOCKERR: Socket-Fehler
- L4OK: Prüfung auf Schicht 4 bestanden, Prüfungen für höhere Schicht nicht aktiviert
- L4TOUT: Zeitüberschreitung bei Schicht 1–4
- L4CON: Verbindungsproblem bei Schicht 1–4. Beispiel: „Verbindung abgelehnt“ (tcp rst) oder „Keine Route zum Host“ (icmp)
- L6OK: Prüfung auf Schicht 6 bestanden
- L6TOUT: Zeitüberschreitung bei Schicht 6 (SSL)
- L6RSP: Ungültige Antwort auf Schicht 6 – Protokollfehler. Dies kann folgende Ursachen haben:
- Der Backend-Server unterstützt nur „SSLv3“ oder „TLSv1.0“ oder
- das Zertifikat des Backend-Servers ist ungültig oder
- die Verschlüsselungsverhandlung ist fehlgeschlagen, etc.
- L7OK: Prüfung auf Schicht 7 bestanden
- L7OKC: Prüfung auf Schicht 7 bedingt bestanden. Beispiel: 404 mit disable-on-404
- L7TOUT: Zeitüberschreitung bei Schicht 7 (HTTP/SMTP)
- L7RSP: Ungültige Antwort auf Schicht 7 – Protokollfehler
- L7STS: Antwortfehler bei Schicht 7. Beispiel: HTTP 5xx
KRITISCH - SSL-Protokoll Version 2 wird von Ihrer SSL-Bibliothek nicht unterstützt.
- Nicht unterstützte Version des SSL-Protokolls
- SSL-Kontext kann nicht erstellt werden.
- SSL-Verbindung kann nicht hergestellt werden.
- SSL-Handshake kann nicht initiiert werden.
- Serverzertifikat kann nicht abgerufen werden.
- Zertifikatsbetreff konnten nicht abgerufen werden.
- Falsches Zeitformat im Zertifikat
- Zertifikat „<cn>“ am <expire time of certificate> abgelaufen
- Zertifikat „<cn>“ heute <expire time of certificate> abgelaufen
WARNUNG/KRITISCH Zertifikat „<cn>“ läuft in <days_left/expire time of certificate> Tag(en) ab
ICMP - Netz nicht erreichbar
- Host nicht erreichbar
- Protokoll nicht erreichbar
- Port nicht erreichbar
- Quellroute fehlgeschlagen
- Quellhost isoliert
- Unbekanntes Netzwerk
- Unbekannter Host
- Netzwerk verweigert
- Host verweigert
- Ungültiger Diensttyp für das Netzwerk
- Ungültiger Diensttyp für den Host
- Durch Filter verboten
- Verstoß gegen Hostvorrang
- Vorranggrenze. Für den Vorgang erforderlicher Mindestvorrang
- Ungültiger Code
UDP/TCP - Fehler bei Socket-Erstellung
- Verbindung mit Adresse xxxx und Port xxx: [Weitere Informationen finden Sie unter Linux-Fehlercode.]
- Keine Daten vom Host empfangen
- Unerwartete Antwort vom Host/Socket
HTTP/HTTPS - HTTP UNBEKANNT: Fehler bei Arbeitsspeicherzuteilung
- HTTP KRITISCH: TCP-Socket kann nicht geöffnet werden (Socket-Erstellung oder Verbindung mit Server ist fehlgeschlagen).
- HTTP KRITISCH: Fehler beim Empfang von Daten
- HTTP KRITISCH: Keine Daten vom Host empfangen
- HTTP KRITISCH: Ungültige HTTP-Antwort von Host empfangen: <status line> (falsches Format der erwarteten Statuszeile)
- HTTP KRITISCH: Ungültige Statuszeile <status line=> (Statuscode besteht nicht aus 3 Ziffern: XXX)
- HTTP KRITISCH: Ungültiger Status <status line> (Statuscode >= 600 oder < 100)
- HTTP KRITISCH: Zeichenfolge nicht gefunden
- HTTP KRITISCH: Muster nicht gefunden
- HTTP WARNUNG: Seitengröße <page_length> zu groß
- HTTP WARNUNG: Seitengröße <page_length> zu klein
- Beim Fehlercode „L4TOUT/L4CON“ bestehen in der Regel Verbindungsprobleme im zugrunde liegenden Netzwerk. Duplicate IP tritt häufig als Hauptursache mit diesem Grund auf. Führen Sie bei diesem Problem folgende Fehlerbehebung durch:
- Überprüfen Sie den Hochverfügbarkeitsstatus von Edges, wenn die Hochverfügbarkeit mit dem Befehl show service highavailability auf beiden Edges aktiviert wurde. Überprüfen Sie, ob der Hochverfügbarkeits-Link DOWN (nicht verfügbar) und alle Edges Active sind, damit es keine doppelte Edge-IP im Netzwerk gibt.
- Überprüfen Sie mit dem Befehl show arp die Edge-ARP-Tabelle und prüfen Sie, ob der ARP-Eintrag des Backend-Servers zwischen den beiden MAC-Adressen geändert wird.
- Überprüfen Sie die Backend-Server-ARP-Tabelle oder überprüfen Sie mit dem Befehl arp-ping, ob ein anderer Rechner dieselbe IP-Adresse aufweist wie der Edge.
- Überprüfen Sie die Statistiken der Load-Balancer-Objekte (VIPs, Pools, Mitglieder). Überprüfen Sie, ob alle Mitglieder des spezifischen Pools aktiv sind und ausgeführt werden. Überprüfen Sie, ob der Transparent-Modus aktiviert ist. Wenn dies der Fall ist, sollte sich das Edge-Dienst-Gateway inline zwischen Client und Server befinden. Überprüfen Sie, ob sich die Sitzungsanzahl der Server erhöht.
nsxedge> show service loadbalancer pool Web-Tier-VIP-01 TIMESTAMP SESSIONS BYTESIN BYTESOUT SESSIONRATE HTTPREQS 2016-04-27 19:56:40 00 00 00 00 00 2016-04-27 19:55:00 00 32 100 00 00nsxedge> show service loadbalancer pool Web-Tier-VIP-01 | MEMBER +—> POOL MEMBER: TENANT-1-TCP-POOL-80/SERVER-1, STATUS: UP +—> POOL MEMBER: TENANT-1-TCP-POOL-80/SERVER-2, STATUS: UP
- Überprüfen Sie, ob beim virtuellen Server ein Standardpool vorhanden und dieser an den Server gebunden ist. Wenn Sie Pools über Anwendungsregeln verwenden, müssen Sie sich die einzelnen Pools wie im Befehl #show service loadbalancer pool gezeigt ansehen. Geben Sie den Namen des virtuellen Servers an.
nsxedge> show service loadbalancer virtual Web-Tier-VIP-01 ----------------------------------------------------------------------- Loadbalancer VirtualServer Statistics: VIRTUAL Web-Tier-VIP-01 | ADDRESS [172.16.10.10]:443 | SESSION (cur, max, total) = (0, 0, 0) | RATE (cur, max, limit) = (0, 0, 0) | BYTES in = (0), out = (0) +->POOL Web-Tier-Pool-01 | LB METHOD round-robin | LB PROTOCOL L7 | Transparent disabled | SESSION (cur, max, total) = (0, 0, 0) | BYTES in = (0), out = (0) +->POOL MEMBER: Web-Tier-Pool-01/web-01a, STATUS: UP | | HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK | | | LAST STATE CHANGE: 2016-05-16 07:02:00 | | SESSION (cur, max, total) = (0, 0, 0) | | BYTES in = (0), out = (0) +->POOL MEMBER: Web-Tier-Pool-01/web-02a, STATUS: UP | | HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK | | | LAST STATE CHANGE: 2016-05-16 07:02:01 | | SESSION (cur, max, total) = (0, 0, 0) | | BYTES in = (0), out = (0) - Wenn alle Konfigurationen in Ordnung zu sein scheinen und der Fehler dennoch fortbesteht, müssen Sie Datenverkehr erfassen, um herauszufinden, wo das Problem liegt. Es gibt zwei Verbindungen: vom Client zum virtuellen Server und vom Edge-Dienst-Gateway zum Backend-Pool (mit oder ohne Transparent-Konfiguration auf der Poolebene). Der Befehl #show ip forwarding führt die vNIC-Schnittstellen auf. Diese Daten können Sie nutzen.
Nehmen wir beispielsweise an, der Clientcomputer befindet sich auf vNic_0 und der Server auf vNic_1. Sie verwenden die Client-IP-Adresse 192.168.1.2, die VIP-IP-Adresse 192.168.2.2, ausgeführt auf Port 80. Die IP-Adresse für die Load-Balancer-Schnittstelle ist 192.168.3.1 und die IP-Adresse des Backend-Servers 192.168.3.3. Es gibt zwei unterschiedliche Befehle für die Paketerfassung. Einer davon zeigt die Pakete an, der andere erfasst die Pakete in einer Datei, die Sie herunterladen können. Erfassen Sie die Pakete, um den abnormalen Fehler des Load Balancers zu erkennen. Sie können Pakete aus zwei Richtungen erfassen:
- Erfassen Sie die Pakete vom Client.
- Erfassen Sie die zum Backend-Server gesendeten Pakete.
#debug packet capture interface interface-name [filter using _ for space]- creates a packet capture file that you can download #debug packet display interface interface-name [filter using _ for space]- outputs packet data to the console #debug show files - to see a list of packet capture #debug copy scp user@url:path file-name/all - to download the packet capture
Beispiel:- Erfassung auf vNIC_0:
debug packet display interface vNic_0
- Erfassung auf allen Schnittstellen:
debug packet display interface any
- Erfassung auf vNIC_0 mit einem Filter:
debug packet display interface vNic_0 host_192.168.11.3_and_host_192.168.11.41 - Eine Paketerfassung aus dem Datenverkehr vom Client zum virtuellen Server:
#debug packet display|capture interface vNic_0 host_192.168.1.2_and_host_192.168.2.2_and_port_80 - Eine Paketerfassung aus dem Datenverkehr zwischen dem Edge-Dienst-Gateway und dem Server, auf dem sich der Pool im Transparent-Modus befindet:
#debug packet display|capture interface vNic_1 host 192.168.1.2_and_host_192.168.3.3_and_port_80 - Eine Paketerfassung aus dem Datenverkehr zwischen dem Edge-Dienst-Gateway und dem Server, auf dem sich der Pool nicht im Transparent-Modus befindet:
#debug packet display|capture interface vNic_1 host 192.168.3.1_and_host_192.168.3.3_and_port_80
