Fehlerbehebung bei internen Verbindungen zwischen VMs
Dieses Dokument enthält Schritte zur Fehlerbehebung bei Verbindungsproblemen zwischen Compute Engine-VMs, die sich im selben Virtual Private Cloud-Netzwerk (VPC oder eigenständiges VPC) oder in zwei VPC-Netzwerken befinden, die mit VPC-Netzwerk-Peering verbunden sind. Es wird davon ausgegangen, dass die VMs über die internen IP-Adressen der jeweiligen virtuellen Netzwerkschnittstellen-Controller (vNICs) kommunizieren.
Die Schritte in dieser Anleitung gelten sowohl für Compute Engine-VMs als auch für Google Kubernetes Engine-Knoten.
Wenn Sie bestimmte zusätzliche Szenarien für die Fehlerbehebung sehen möchten, klicken Sie bitte unten auf der Seite auf den Link Feedback geben und teilen Sie uns dies mit.
Die folgenden VM- und VPC-Konfigurationen gelten für diese Anleitung:
- VM-zu-VM-Verbindungen mit internen IP-Adressen in einem einzelnen VPC-Netzwerk
- VM-zu-VM-Verbindungen mit internen IP-Adressen in einem freigegebenen VPC-Netzwerk
- VM-zu-VM-Verbindungen mit internen IP-Adressen in verschiedenen VPC-Netzwerken, die über VPC-Netzwerk-Peering verbunden sind
Die in dieser Anleitung verwendeten Befehle sind für alle von Google bereitgestellten Betriebssystem-Images verfügbar. Wenn Sie ein eigenes Betriebssystem-Image verwenden, müssen Sie die Tools möglicherweise installieren.
Problem quantifizieren
- Wenn Sie davon ausgehen, dass ein vollständiger Paketverlust vorliegt, lesen Sie die Informationen unter Vollständigen Verbindungsausfall beheben.
- Wenn Latenz, nur ein teilweiser Paketverlust oder eine Zeitüberschreitung bei der Verbindung auftritt, lesen Sie den Abschnitt Durchsatzprobleme bei Netzwerklatenz oder -verlust beheben.
Vollständigen Verbindungsausfall beheben
In den folgenden Abschnitten finden Sie Schritte zur Behebung eines vollständigen internen Verbindungsausfalls zwischen VMs. Wenn Sie jedoch eine erhöhte Latenz oder periodische Verbindungszeitüberschreitungen feststellen, fahren Sie mit Durchsatzprobleme bei Netzwerklatenz oder -verlust beheben fort.
Verbindungswerte bestimmen
Sammeln Sie zuerst die folgenden Informationen:
- Erfassen Sie auf der Seite VM-Instanzen Folgendes für beide VMs:
- VM-Namen
- VM-Zonen
- Interne IP-Adressen für die kommunizierenden VNICs
Ermitteln Sie in der Konfiguration der Zielserversoftware die folgenden Informationen:
- Layer-4-Protokoll
- Zielport
Wenn Ihr Ziel beispielsweise ein HTTPS-Server ist, ist das Protokoll TCP und der Port ist in der Regel
443, aber in Ihrer spezifischen Konfiguration wird möglicherweise ein anderer Port verwendet.
Wenn bei mehreren VMs Probleme auftreten, wählen Sie eine einzelne Quell-VM und eine einzelne Ziel-VM aus, bei denen Probleme auftreten, und verwenden Sie diese Werte. Im Allgemeinen sollten Sie den Quellport der Verbindung nicht benötigen.
Sobald Sie diese Informationen haben, fahren Sie mit Probleme mit dem zugrunde liegenden Google-Netzwerk untersuchen fort.
Probleme mit dem zugrunde liegenden Google-Netzwerk untersuchen
Wenn es sich um eine bestehende Einrichtung handelt, die sich in letzter Zeit nicht geändert hat, liegt das Problem möglicherweise beim zugrunde liegenden Google-Netzwerk. Prüfen Sie das Dashboard zur Leistungsüberwachung im Network Intelligence Center auf Paketverlust zwischen den VM-Zonen. Wenn der Paketverlust zwischen den Zonen während des Zeitraums der Netzwerkzeitüberschreitungen zunimmt, kann dies darauf hindeuten, dass das Problem auf das physische Netzwerk zurückzuführen ist, das Ihrem virtuellen Netzwerk zugrunde liegt. Prüfen Sie das Google Cloud-Status-Dashboard auf bekannte Probleme, bevor Sie eine Supportanfrage einreichen.
Wenn das Problem offenbar nicht beim zugrunde liegenden Google-Netzwerk liegt, fahren Sie mit Auf falsch konfigurierte Firewallregeln in Google Cloud prüfen fort.
Auf falsch konfigurierte Firewallregeln in Google Cloud prüfen
Konnektivitätstests analysieren die VPC-Netzwerkpfadkonfiguration zwischen zwei VMs und zeigen, ob die programmierte Konfiguration den Traffic zulassen sollte oder nicht. Wenn der Traffic nicht zugelassen ist, zeigen die Ergebnisse an, ob eine Google Cloud-Firewallregel für eingehenden oder ausgehenden Traffic den Traffic blockiert oder keine Route verfügbar ist.
Konnektivitätstests können den Pfad auch dynamisch testen, indem Pakete zwischen den Hypervisoren der VMs gesendet werden. Wenn diese Tests ausgeführt werden, werden die Ergebnisse dieser Tests angezeigt.
Konnektivitätstests prüfen nur die Konfiguration des VPC-Netzwerks. Die Firewall des Betriebssystems, die Betriebssystemrouten und die Serversoftware der VM werden nicht getestet.
Beim folgenden Verfahren werden Konnektivitätstests über die Google Cloud Console ausgeführt. Weitere Möglichkeiten zum Ausführen von Tests finden Sie unter Konnektivitätstests ausführen.
Gehen Sie folgendermaßen vor, um einen Test zu erstellen und auszuführen:
Rufen Sie in der Google Cloud Console die Seite Konnektivitätstests auf.
Bestätigen Sie im Drop-down-Menü des Projekts, dass Sie sich im richtigen Projekt befinden, oder geben Sie das richtige an.
Klicken Sie auf Konnektivitätstest erstellen.
Geben Sie einen Namen für den Test ein.
Geben Sie Folgendes an:
- Protokoll
- IP-Adresse des Quellendpunkts
- Quellprojekt und VPC-Netzwerk
- IP-Adresse des Zielendpunkts
- Zielprojekt und VPC-Netzwerk
- Zielport
Klicken Sie auf Erstellen.
Der Test wird sofort ausgeführt. Klicken Sie zum Aufrufen des Ergebnisdiagramms in der Spalte Ergebnisdetails auf Anzeigen.
- Wenn die Ergebnisse ergeben, dass die Verbindung durch eine Google Cloud-Firewallregel unterbrochen wird, sollten Sie prüfen, ob die beabsichtigte Sicherheitskonfiguration die Verbindung zulassen sollte. Wenden Sie sich an Ihren Sicherheits- oder Netzwerkadministrator, um weitere Informationen zu erhalten. Wenn der Traffic zugelassen sein sollte, prüfen Sie Folgendes:
- Prüfen Sie die Liste Permanent blockierter Traffic. Wenn der Traffic von Google Cloud blockiert wird, wie in der Liste „Permanent blockierter Traffic“ beschrieben, funktioniert Ihre vorhandene Konfiguration nicht.
- Rufen Sie die Seite der Firewall-Richtlinien auf und prüfen Sie Ihre Firewallregeln. Wenn die Firewall falsch konfiguriert ist, erstellen oder ändern Sie eine Firewallregel, um die Verbindung zuzulassen. Bei dieser Regel kann es sich um eine VPC-Firewallregel oder eine hierarchische Firewallrichtlinien-Regel handeln.
- Wenn eine korrekt konfigurierte Firewallregel diesen Traffic blockiert, wenden Sie sich an Ihren Sicherheits- oder Netzwerkadministrator. Wenn die Sicherheitsanforderungen Ihrer Organisation bedeuten, dass die VMs sich nicht gegenseitig erreichen sollen, müssen Sie unter Umständen die Einrichtung neu gestalten.
- Wenn die Ergebnisse darauf hinweisen, dass keine Probleme mit dem VPC-Konnektivitätspfad vorliegen, kann eines der folgenden Probleme vorliegen:
- Probleme mit der Konfiguration des Gastbetriebssystems, z. B. Probleme mit der Firewallsoftware
- Probleme mit den Client- oder Serveranwendungen, z. B. wenn die Anwendung einfriert oder dafür konfiguriert ist, den falschen Port zu überwachen
Im weiteren Verlauf werden Sie durch die Betrachtung dieser beiden Möglichkeiten geführt. Fahren Sie mit TCP-Konnektivität von innerhalb der VM testen fort.
TCP-Konnektivität von innerhalb der VM testen
Wenn Ihr VM-VM-Konnektivitätstest kein Problem mit der VPC-Konfiguration erkannt hat, können Sie mit dem Testen der Konnektivität zwischen Betriebssystemen beginnen. Mit den folgenden Schritten können Sie Folgendes ermitteln:
- Ob ein TCP-Server den angegebenen Port überwacht
- Ob die serverseitige Firewallsoftware Verbindungen von dieser Client-VM zu diesem Port zulässt
- Ob die clientseitige Firewallsoftware Verbindungen zu diesem Port auf dem Server zulässt
- Ob die serverseitige Routentabelle ordnungsgemäß für die Weiterleitung von Paketen konfiguriert ist
- Ob die clientseitige Routingtabelle ordnungsgemäß für die Weiterleitung von Paketen konfiguriert ist
Sie können den TCP-Handshake mit curl unter Linux oder Windows 2019 oder mit dem Befehl New-Object System.Net.Sockets.TcpClient mit Windows PowerShell testen. Der Workflow in diesem Abschnitt sollte zu einem der folgenden Ergebnisse führen: Verbindung erfolgreich, Zeitüberschreitung der Verbindung oder Verbindung zurückgesetzt.
- Erfolg: Wenn der TCP-Handshake erfolgreich abgeschlossen wird, blockiert eine Betriebssystem-Firewallregel die Verbindung nicht, das Betriebssystem leitet Pakete korrekt weiter und ein Server überwacht die Zielport. Wenn dies der Fall ist, könnte das Problem durch die Anwendung selbst verursacht werden. Weitere Informationen zur Prüfung finden Sie unter Server-Logging auf Informationen zum Serververhalten prüfen.
- Zeitüberschreitung: Wenn das Zeitlimit für die Verbindung überschritten wird, hat dies in der Regel ein der folgenden Ursachen:
- An dieser IP-Adresse ist kein Computer vorhanden.
- Ihre Pakete werden von einer Firewall unbemerkt verworfen.
- Das Betriebssystem-Paketrouting sendet die Pakete an ein Ziel, das diese nicht verarbeiten kann, oder asymmetrisches Routing sendet das Rückgabepaket auf einem ungültigen Pfad.
Zurücksetzen: Wenn die Verbindung zurückgesetzt wird, bedeutet dies, dass die Ziel-IP-Adresse Pakete empfängt, aber ein Betriebssystem oder eine Anwendung die Pakete ablehnt. Das kann eines der folgenden Dinge bedeuten:
- Die Pakete kommen am falschen Computer an und sind nicht so konfiguriert, dass sie an diesem Port auf dieses Protokoll reagieren.
- Die Pakete kommen am richtigen Computer an, aber kein Server überwacht diesen Port.
- Die Pakete kommen am richtigen Computer und am richtigen Port an, aber die Protokolle auf höherer Ebene (z. B. SSL) schließen ihren Handshake nicht ab.
- Eine Firewall setzt die Verbindung zurück. Dies ist weniger wahrscheinlich als eine Firewall, die unbemerkt die Pakete verwirft, es kann aber passieren.
Linux
Rufen Sie in der Google Cloud Console die Seite der Firewall-Richtlinien auf.
Achten Sie darauf, dass eine Firewallregel vorhanden ist, die SSH-Verbindungen von IAP zu Ihrer VM zulässt, oder erstellen Sie eine neue Regel.
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Suchen Sie Ihre Quell-VM.
Klicken Sie in der Spalte SSH für diese VM auf SSH.
Führen Sie in der Befehlszeile des Clientcomputers den folgenden Befehl aus. Ersetzen Sie DEST_IP:DEST_PORT durch Ihre Ziel-IP-Adresse und Ihren Zielport.
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Suchen Sie Ihre Quell-VM.
Verwenden Sie eine der unter Verbindung zu Windows-VMs herstellen beschriebenen Methoden, um eine Verbindung zur VM herzustellen.
Führen Sie über die Befehlszeile des Clientcomputers folgendes aus:
- Windows 2019:
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- Windows 2012 oder Windows 2016 PowerShell:
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019:
Verbindung erfolgreich
Die folgenden Ergebnisse geben einen erfolgreichen TCP-Handshake an. Wenn der TCP-Handshake erfolgreich abgeschlossen wurde, hängt das Problem nicht mit einer Zeitüberschreitung oder einem Zurücksetzen der TCP-Verbindung zusammen. Stattdessen tritt die Zeitüberschreitung in den Anwendungsebenen auf. Wenn Sie eine erfolgreiche Verbindung erhalten, fahren Sie mit Server-Logging auf Informationen zum Serververhalten prüfen fort.
Linux und Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
Die Zeile "Verbunden mit" zeigt einen erfolgreichen TCP-Handshake an.
Expire in 0 ms for 6 (transfer 0x558b3289ffb0) Expire in 5000 ms for 2 (transfer 0x558b3289ffb0) Trying 192.168.0.4... TCP_NODELAY set Expire in 200 ms for 4 (transfer 0x558b3289ffb0) Connected to 192.168.0.4 (192.168.0.4) port 443 (#0) > GET / HTTP/1.1 > Host: 192.168.0.4:443 > User-Agent: curl/7.64.0 > Accept: */* > Empty reply from server Connection #0 to host 192.168.0.4 left intact
Windows 2012 und 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
Ergebnis "Verbindung erfolgreich". Die Zeile "Connected: True" ist relevant.
Available : 0 Client : System.Net.Sockets.Socket Connected : True ExclusiveAddressUse : False ReceiveBufferSize : 131072 SendBufferSize : 131072 ReceiveTimeout : 0 SendTimeout : 0 LingerState : System.Net.Sockets.LingerOption NoDelay : False
Zeitüberschreitung der Verbindung
Die folgenden Ergebnisse geben an, dass die Verbindung das Zeitlimit überschritten hat. Wenn Ihre Verbindung das Zeitlimit überschreitet, fahren Sie mit Server-IP-Adresse und Port prüfen fort.
Linux und Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Ergebnis "Zeitüberschreitung der Verbindung":
Trying 192.168.0.4:443... Connection timed out after 5000 milliseconds Closing connection 0
Windows 2012 und 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
Ergebnis "Zeitüberschreitung der Verbindung":
New-Object: Exception calling ".ctor" with "2" argument(s): "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 192.168.0.4:443"
Verbindung zurückgesetzt
Ein Zurücksetzen tritt auf, wenn ein Gerät ein RST-Paket an den Client zurücksendet und den Client darüber informiert, dass die Verbindung beendet wurde. Die Verbindung kann aus einem der folgenden Gründe zurückgesetzt werden:
- Der empfangende Server wurde nicht so konfiguriert, dass er Verbindungen für dieses Protokoll an diesem Port akzeptiert. Das könnte daran liegen, dass das Paket an den falschen Server oder den falschen Port gesendet wurde oder die Serversoftware falsch konfiguriert war.
- Die Firewallsoftware hat den Verbindungsversuch abgelehnt.
Wenn die Verbindung zurückgesetzt wurde, fahren Sie mit Prüfen, ob Sie auf die richtige IP-Adresse und den richtigen Port zugreifen fort.
Linux und Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
Ergebnis "Verbindung zurückgesetzt":
Trying 192.168.0.4:443... connect to 192.168.0.4 port 443 failed: Connection refused Failed to connect to 192.168.0.4 port 443: Connection refused Closing connection 0
Windows 2012 und 2016
PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)
Ergebnis "Verbindung zurückgesetzt":
New-Object: Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it. 192.168.0.4:443"
IP-Adresse und Port des Servers prüfen
Führen Sie einen der folgenden Befehle auf Ihrem Server aus. Sie geben an, ob ein Server den erforderlichen Port überwacht.
Linux
$ sudo netstat -ltuvnp
Die Ausgabe zeigt, dass ein TCP-Server eine Ziel-IP-Adresse (0.0.0.0) an Port 22 überwacht, wobei Verbindungen von jeder Quelladresse (0.0.0.0) und jeden Quellport (*) akzeptiert werden. Die Spalte PID/Program name gibt die ausführbare Datei an, die an den Socket gebunden ist.
Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 588/sshd tcp6 0 0 :::22 :::* LISTEN 588/sshd udp 0 0 0.0.0.0:68 0.0.0.0:* 334/dhclient udp 0 0 127.0.0.1:323 0.0.0.0:* 429/chronyd udp6 0 0 ::1:323 :::* 429/chronyd
Windows
PS C:\> Get-NetTcpConnection -State "LISTEN" -LocalPort DEST_PORT
Die Ausgabe zeigt Ergebnisse des Befehls an, wobei DEST_PORT auf 443 gesetzt ist.
Diese Ausgabe zeigt, dass ein TCP-Server eine Adresse (0.0.0.0) an Port 443 überwacht, wobei Verbindungen von jeder Quelladresse (0.0.0.0) und jedem Quellport (0) akzeptiert werden. Die Spalte OwningProcess gibt die Prozess-ID des Prozesses an, der den Socket überwacht.
LocalAddress LocalPort RemoteAddress RemotePort State AppliedSetting OwningProcess ------------ --------- ------------- ---------- ----- -------------- ------------- :: 443 :: 0 Listen 928 0.0.0.0 443 0.0.0.0 0 Listen 928
Wenn Sie feststellen, dass der Server nicht an den richtigen Port oder die richtige IP-Adresse gebunden ist oder dass das Remote-Präfix nicht mit Ihrem Client übereinstimmt, lesen Sie die Serverdokumentation oder wenden Sie sich an den Serveranbieter, um das Problem zu beheben. Der Server muss an die IP-Adresse einer bestimmten Schnittstelle oder an 0.0.0.0 gebunden sein und Verbindungen vom richtigen Client-IP-Präfix oder von 0.0.0.0 akzeptieren.
Wenn der Anwendungsserver an die richtige IP-Adresse und den richtigen Port gebunden ist, kann es sein, dass der Client auf den falschen Port zugreift, dass ein höheres Protokoll (häufig TLS) aktiv die Verbindung ablehnt oder dass eine Firewall die Verbindung ablehnt.
Prüfen Sie, ob Client und Server dieselbe TLS-Version und dieselben Verschlüsselungsinformationen verwenden.
Prüfen Sie, ob der Client auf den richtigen Port zugreift.
Wenn das Problem durch die oben genannten Schritte nicht behoben wird, fahren Sie mit Firewall auf Client und Server auf Verwerfen von Paketen prüfen fort.
Firewall auf Client und Server auf Verwerfen von Paketen prüfen
Wenn der Server von der Client-VM aus nicht erreichbar ist, aber den richtigen Port überwacht, führt eine der VMs möglicherweise eine Firewallsoftware aus, die mit der Verbindung verknüpfte Pakete verwirft. Prüfen Sie die Firewall auf den Client- und Server-VMs mit den folgenden Befehlen.
Wenn eine Regel Ihren Traffic blockiert, können Sie die Firewallsoftware aktualisieren, um den Traffic zuzulassen. Wenn Sie die Firewall aktualisieren, sollten Sie bei der Vorbereitung und Ausführung der Befehle vorsichtig vorgehen, da eine falsch konfigurierte Firewall unerwarteten Traffic blockieren kann. Erwägen Sie, den Zugriff der seriellen VM-Konsole einzurichten, bevor Sie fortfahren.
Linux-iptables
Prüfen Sie die Anzahl der für jede installierte iptables-Kette und -Regel verarbeiteten Pakete. Durch Vergleich der Quell- und Ziel-IP-Adressen und -Ports mit den durch iptables-Regeln angegebenen Präfixen und Ports ermitteln Sie, anhand welcher DROP-Regeln abgeglichen wird.
Wenn in einer abgeglichen Regel zunehmende Verwerfungen mit Zeitüberschreitungen von Verbindungen angezeigt werden, lesen Sie die iptables-Dokumentation, um die richtige allow-Regel auf die entsprechenden Verbindungen anzuwenden.
$ sudo iptables -L -n -v -x
Dieses Beispiel einer INPUT-Kette zeigt, dass Pakete von einer beliebigen IP-Adresse, die den Ziel-TCP-Port 5000 verwendet, von der Firewall verworfen werden.
Die Spalte "pkts" gibt an, dass die Regel 10.342 Pakete verworfen hat. Wenn Sie beispielsweise Verbindungen erstellen, die von dieser Regel verworfen werden, wird der Zähler für "pkts" erhöht und das Verhalten bestätigt.
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 10342 2078513 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000
Mit den folgenden Befehlen können Sie eine Regel für eingehenden oder ausgehenden Traffic zu iptables hinzufügen:
Regel für eingehenden Traffic:
$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT
Regel für ausgehenden Traffic:
$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT
Windows-Firewall
Prüfen Sie in Windows-Firewall, ob für die Verbindung ausgehender Traffic vom Client und eingehender Traffic zum Server zugelassen ist. Wenn eine Regel Ihren Traffic blockiert, nehmen Sie die erforderlichen Korrekturen in Windows-Firewall vor, um die Verbindungen zuzulassen. Sie können auch das Windows-Firewall-Logging aktivieren.
Das standardmäßige DENY-Verhalten von Windows-Firewall besteht darin, abgelehnte Pakete unbemerkt zu verwerfen, was zu Zeitüberschreitungen führt.
Dieser Befehl prüft den Server. Ändern Sie den Wert -match in Outbound, um die Regeln für ausgehenden Traffic auf der Client-VM zu prüfen.
PS C:\> Get-NetFirewallPortFilter | `
>> Where-Object LocalPort -match "PORT" | `
>> Get-NetFirewallRule | `
>> Where-Object {$_.Direction -match "Inbound" -and $_.Profile -match "Any"}
Name : {80D79988-C7A5-4391-902D-382369B4E4A3}
DisplayName : iperf3 udp
Description :
DisplayGroup :
Group :
Enabled : True
Profile : Any
Platform : {}
Direction : Inbound
Action : Allow
EdgeTraversalPolicy : Block
LooseSourceMapping : False
LocalOnlyMapping : False
Owner :
PrimaryStatus : OK
Status : The rule was parsed successfully from the store. (65536)
EnforcementStatus : NotApplicable
PolicyStoreSource : PersistentStore
PolicyStoreSourceType : Local
Mit den folgenden Befehlen können Sie neue Firewallregeln zu Windows hinzufügen.
Regel für ausgehenden Traffic:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT
Regel für eingehenden Traffic:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT
Drittanbieter-Software
Anwendungsfirewalls oder Antivirensoftware von Drittanbietern können auch Verbindungen unterbrechen oder ablehnen. Lesen Sie dazu die Dokumentation Ihres Anbieters.
Wenn Sie ein Problem mit Firewallregeln finden und es beheben, testen Sie die Verbindung noch einmal. Wenn Firewallregeln nicht das Problem zu sein scheinen, fahren Sie mit Betriebssystem-Routingkonfiguration prüfen fort.
Betriebssystem-Routingkonfiguration prüfen
Probleme beim Betriebssystem-Routing können in den folgenden Situationen auftreten:
- Routingprobleme sind am häufigsten auf VMs mit mehreren Netzwerkschnittstellen wegen der zusätzlichen Routingkomplexität.
- Bei einer in Google Cloud mit einer einzelnen Netzwerkschnittstelle erstellten VM treten Routingprobleme normalerweise nur auf, wenn jemand die Standardroutingtabelle manuell geändert hat.
- Auf einer VM, die vom lokalen Standort migriert wurde, kann die VM Routing- oder MTU-Einstellungen übertragen, die lokal benötigt wurden, aber Probleme im VPC-Netzwerk verursachen.
Wenn Sie eine VM mit mehreren Netzwerkschnittstellen verwenden, müssen Routen so konfiguriert sein, dass ausgehender Traffic an den richtigen vNIC und das richtige Subnetz gesendet wird. Beispielsweise können für eine VM Routen so konfiguriert sein, dass Traffic für interne Subnetze an einen vNIC gesendet wird, das Standardgateway (Ziel 0.0.0.0/0) jedoch auf einen anderen vNIC konfiguriert ist, der eine externe IP-Adresse oder Zugriff auf Cloud NAT hat.
Sie können Routen prüfen, indem Sie einzelne Routen einzeln prüfen oder die gesamte VM-Routingtabelle betrachten. Wenn bei beiden Ansätzen Probleme mit der Routingtabelle auftreten, lesen Sie die Schritte unter Routingtabellen bei Bedarf aktualisieren.
Alle Routen prüfen
Listen Sie alle Routen auf, um zu ermitteln, welche Routen bereits auf der VM vorhanden sind.
Linux
$ ip route show table all
default via 10.3.0.1 dev ens4 10.3.0.1 dev ens4 scope link local 10.3.0.19 dev ens4 table local proto kernel scope host src 10.3.0.19 broadcast 10.3.0.19 dev ens4 table local proto kernel scope link src 10.3.0.19 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 ::1 dev lo proto kernel metric 256 pref medium fe80::/64 dev ens4 proto kernel metric 256 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fe80::4001:aff:fe03:13 dev ens4 table local proto kernel metric 0 pref medium multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium
Windows
PS C:\> Get-NetRoute
ifIndex DestinationPrefix NextHop RouteMetric ifMetric PolicyStore ------- ----------------- ------- ----------- -------- ----------- 4 255.255.255.255/32 0.0.0.0 256 5 ActiveStore 1 255.255.255.255/32 0.0.0.0 256 75 ActiveStore 4 224.0.0.0/4 0.0.0.0 256 5 ActiveStore 1 224.0.0.0/4 0.0.0.0 256 75 ActiveStore 4 169.254.169.254/32 0.0.0.0 1 5 ActiveStore 1 127.255.255.255/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.1/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.0/8 0.0.0.0 256 75 ActiveStore 4 10.3.0.255/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.31/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.1/32 0.0.0.0 1 5 ActiveStore 4 10.3.0.0/24 0.0.0.0 256 5 ActiveStore 4 0.0.0.0/0 10.3.0.1 0 5 ActiveStore 4 ff00::/8 :: 256 5 ActiveStore 1 ff00::/8 :: 256 75 ActiveStore 4 fe80::b991:6a71:ca62:f23f/128 :: 256 5 ActiveStore 4 fe80::/64 :: 256 5 ActiveStore 1 ::1/128 :: 256 75 ActiveStore
Einzelne Routen prüfen
Wenn ein bestimmtes IP-Präfix das Problem zu sein scheint, prüfen Sie, ob für die Quell- und Ziel-IP-Adressen in den Client- und Server-VMs geeignete Routen vorhanden sind.
Linux
$ ip route get DEST_IP
Gutes Ergebnis:
Eine gültige Route wird angezeigt. In diesem Fall gegen die Pakete von der Schnittstelle ens4 aus.
10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000 cache
Schlechtes Ergebnis:
Dieses Ergebnis bestätigt, dass Pakete verworfen werden, da es keinen Pfad zum Zielnetzwerk gibt. Prüfen Sie, ob Ihre Routentabelle einen Pfad zur richtigen Schnittstelle für ausgehenden Traffic enthält.
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
Gutes Ergebnis:
IPAddress : 192.168.0.2 InterfaceIndex : 4 InterfaceAlias : Ethernet AddressFamily : IPv4 Type : Unicast PrefixLength : 24 PrefixOrigin : Dhcp SuffixOrigin : Dhcp AddressState : Preferred ValidLifetime : 12:53:13 PreferredLifetime : 12:53:13 SkipAsSource : False PolicyStore : ActiveStore Caption : Description : ElementName : InstanceID : ;:8=8:8:9<>55>55:8:8:8:55; AdminDistance : DestinationAddress : IsStatic : RouteMetric : 256 TypeOfRoute : 3 AddressFamily : IPv4 CompartmentId : 1 DestinationPrefix : 192.168.0.0/24 InterfaceAlias : Ethernet InterfaceIndex : 4 InterfaceMetric : 5 NextHop : 0.0.0.0 PreferredLifetime : 10675199.02:48:05.4775807 Protocol : Local Publish : No State : Alive Store : ActiveStore ValidLifetime : 10675199.02:48:05.4775807 PSComputerName : ifIndex : 4
Schlechtes Ergebnis:
Find-NetRoute : The network location cannot be reached. For information about network troubleshooting, see Windows Help.
At line:1 char:1
+ Find-NetRoute -RemoteIpAddress "192.168.0.4"
+ ----------------------------------------
+ CategoryInfo : NotSpecified: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [Find-NetRoute], CimException
+ FullyQualifiedErrorId : Windows System Error 1231,Find-NetRoute
Dieser Befehl bestätigt, dass Pakete verworfen werden, da kein Pfad zur Ziel-IP-Adresse vorhanden ist. Prüfen Sie, ob ein Standardgateway vorhanden ist und das Gateway auf den richtigen vNIC und das richtige Netzwerk angewendet wird.
Routingtabellen aktualisieren
Bei Bedarf können Sie der Routentabelle Ihres Betriebssystems eine Route hinzufügen. Bevor Sie einen Befehl zum Aktualisieren der Routingtabelle der Routing-VM ausführen, sollten Sie sich mit den Befehlen vertraut machen und ein Verständnis der möglichen Auswirkungen entwickeln. Eine nicht ordnungsgemäße Verwendung von Routenaktualisierungsbefehlen kann zu unerwarteten Problemen oder einer Trennung der VM führen. Erwägen Sie, den Zugriff der seriellen VM-Konsole einzurichten, bevor Sie fortfahren.
Eine Anleitung zum Aktualisieren von Routen finden Sie in der Dokumentation Ihres Betriebssystems.
Wenn Sie ein Problem mit den Routen haben und es beheben, testen Sie die Verbindung noch einmal. Wenn Routen offenbar nicht das Problem sind, fahren Sie mit Schnittstellen-MTU prüfen fort.
MTU prüfen
Die Schnittstellen-MTU einer VM sollte mit der MTU des VPC-Netzwerks übereinstimmen, mit dem sie verbunden ist. Idealerweise haben VMs, die miteinander kommunizieren, auch übereinstimmende MTUs. Nicht übereinstimmende MTUs sind bei TCP meist kein Problem, können aber eins bei UDP sein.
Prüfen Sie die MTU der VPC. Wenn sich die VMs in zwei verschiedenen Netzwerken befinden, prüfen Sie beide Netzwerke.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Prüfen Sie die MTU-Konfiguration für Ihre Client- und Server-Netzwerkschnittstellen.
Linux
$ netstat -i
Die lo-Schnittstelle (Loopback) hat immer die MTU 65536 und kann für diesen Schritt ignoriert werden.
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
Loopback-Pseudoschnittstellen haben immer die MTU 4294967295 und können für diesen Schritt ignoriert werden.
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
Wenn die Schnittstellen- und Netzwerk-MTUs nicht übereinstimmen, können Sie die Schnittstellen-MTU neu konfigurieren. Weitere Informationen finden Sie unter Einstellungen für VMs und MTU. Wenn sie übereinstimmen und Sie die Schritte zur Fehlerbehebung bis hierher ausgeführt haben, liegt das Problem wahrscheinlich beim Server selbst. Informationen zur Behebung von Serverproblemen finden Sie unter Server-Logging auf Informationen zum Serververhalten prüfen.
Server-Logging auf Informationen zum Serververhalten prüfen
Wenn das Problem durch die vorherigen Schritte nicht behoben wird, verursacht die Anwendung möglicherweise die Zeitüberschreitungen. Prüfen Sie die Server- und Anwendungslogs auf ein Verhalten, das erklären würde, was Sie sehen.
Logquellen, die geprüft werden sollten:
- Cloud Logging für die VM
- Serielle VM-Logs
- Syslog und kern.log unter Linux oder Windows-Ereignisanzeige
Wenn weiterhin Probleme auftreten
Sollten weiterhin Probleme auftreten, finden Sie unter Support Informationen zu den nächsten Schritten. Die Ausgabe der oben beschriebenen Schritte zur Fehlerbehebung ist für die Freigabe für andere Mitbearbeiter nützlich.
Durchsatzprobleme bei Netzwerklatenz oder -verlust beheben
Probleme bezüglich Netzwerklatenz oder -verlust werden in der Regel durch Ressourcenmangel oder Engpässe bei VM- oder Netzwerkpfaden verursacht. Gelegentlich kann ein Netzwerkverlust zu vorübergehenden Verbindungszeitüberschreitungen führen. Ursachen wie vCPU-Mangel oder vNIC-Sättigung führen zu einer erhöhten Latenz und einem Paketverlust, was zu einer geringeren Netzwerkleistung führt.
Bei der folgenden Anleitung wird davon ausgegangen, dass die Verbindungszeitüberschreitungen nicht konsistent auftreten und es Probleme mit begrenzter Kapazität oder Leistung gibt. Wenn ein vollständiger Paketverlust auftritt, finden Sie weitere Informationen unter Vollständigen Verbindungsausfall beheben.
Kleine Latenzunterschiede, z. B. Latenzunterschiede von einigen Millisekunden, sind normal. Latenzen variieren aufgrund der Netzwerklast oder wegen Warteschlangen in der VM.
Verbindungswerte bestimmen
Sammeln Sie zuerst die folgenden Informationen:
- Erfassen Sie auf der Seite VM-Instanzen Folgendes für beide VMs:
- VM-Namen
- VM-Zonen
- Interne IP-Adressen für die kommunizierenden VNICs
- Ermitteln Sie in der Konfiguration der Zielserversoftware die folgenden Informationen:
- Layer-4-Protokoll
- Zielport
Wenn bei mehreren VMs Probleme auftreten, wählen Sie eine einzelne Quell-VM und eine einzelne Ziel-VM aus, bei denen Probleme auftreten, und verwenden Sie diese Werte. Im Allgemeinen sollten Sie den Quellport der Verbindung nicht benötigen.
Sobald Sie diese Informationen haben, fahren Sie mit Probleme mit dem zugrunde liegenden Google-Netzwerk untersuchen fort.
Probleme mit dem zugrunde liegenden Google-Netzwerk untersuchen
Wenn es sich um eine bestehende Einrichtung handelt, die sich in letzter Zeit nicht geändert hat, liegt das Problem möglicherweise beim zugrunde liegenden Google-Netzwerk. Prüfen Sie das Dashboard zur Leistungsüberwachung im Network Intelligence Center auf Paketverlust zwischen den VM-Zonen. Wenn der Paketverlust zwischen den Zonen während des Zeitraums der Netzwerkzeitüberschreitungen zunimmt, kann dies darauf hindeuten, dass das Problem auf das physische Netzwerk zurückzuführen ist, das Ihrem virtuellen Netzwerk zugrunde liegt. Prüfen Sie das Google Cloud-Status-Dashboard auf bekannte Probleme, bevor Sie eine Supportanfrage einreichen.
Wenn das Problem offenbar nicht auf das zugrunde liegende Google-Netzwerk zurückzuführen ist, fahren Sie mit Handshake-Latenz prüfen fort.
Handshake-Latenz prüfen
Alle verbindungsbasierten Protokolle verursachen eine gewisse Latenz, während sie ihren Handshake zur Verbindungseinrichtung ausführen. Jeder Protokoll-Handshake erhöht den Aufwand. Bei SSL/TLS-Verbindungen muss beispielsweise der TCP-Handshake abgeschlossen sein, bevor der SSL/TLS-Handshake gestartet werden kann. Anschließend muss der TLS-Handshake abgeschlossen sein, bevor Daten übertragen werden können.
Die Handshake-Latenz in derselben Google Cloud-Zone ist in der Regel vernachlässigbar, aber die Handshakes zu weit entfernten Standorten kann bei der Einleitung von Verbindungen zu längeren Verzögerungen führen. Wenn Sie Ressourcen in entfernten Regionen haben, können Sie prüfen, ob die angezeigte Latenz auf einen Protokoll-Handshake zurückzuführen ist.
Linux und Windows 2019
$ curl -o /dev/null -Lvs -w 'tcp_handshake: %{time_connect}s, application_handshake: %{time_appconnect}s' DEST_IP:PORT
tcp_handshake: 0.035489s, application_handshake: 0.051321s
- tcp_handshake ist die Dauer ab dem Zeitpunkt, zu dem der Client das erste SYN-Paket sendet, bis zu dem Zeitpunkt, zu dem der Client die Bestätigung des TCP-Handshakes sendet.
- application_handshake ist die Zeit vom ersten SYN-Paket des TCP-Handshakes bis zum Abschluss des TLS-Handshakes (in der Regel).
- Zusätzliche Handshake-Zeit = application_handshake - tcp_handshake
Windows 2012 und 2016
Nicht mit standardmäßigen Betriebssystem-Tools verfügbar. Die ICMP-Umlaufzeit kann als Referenz verwendet werden, wenn Firewallregeln dies zulassen.
Wenn die Latenz größer ist als die Handshakes erklären, fahren Sie mit Maximalen Durchsatz des VM-Typs bestimmen fort.
Maximalen Durchsatz des VM-Typs bestimmen
Der Durchsatz der VM-Netzwerke für ausgehenden Traffic wird durch die CPU-Architektur der VM und die Anzahl der vCPUs begrenzt. Ermitteln Sie die potenzielle Bandbreite Ihrer VM für ausgehenden Traffic auf der Seite Netzwerkbandbreite.
Wenn Ihre VM nicht Ihre Anforderungen an ausgehenden Traffic erfüllt, sollten Sie ein Upgrade auf eine VM mit höherer Kapazität in Betracht ziehen. Eine Anleitung hierzu finden Sie unter Maschinentyp einer Instanz ändern.
Wenn Ihr Maschinentyp eine ausreichende Bandbreite für ausgehenden Traffic zulassen soll, prüfen Sie, ob die Persistent Disk-Nutzung Ihren ausgehenden Netzwerk-Traffic beeinträchtigt. Persistent Disk-Vorgänge dürfen bis zu 60 % des gesamten Netzwerkdurchsatzes einer VM in Anspruch nehmen. Informationen dazu, ob Persistent Disk-Vorgänge den Netzwerkdurchsatz beeinträchtigen können, finden Sie unter Leistung von Persistent Disk prüfen.
Eingehender Netzwerk-Traffic zu einer VM ist nicht durch das VPC-Netzwerk oder den VM-Instanztyp begrenzt. Stattdessen wird er durch die Paketwarteschlangen und Paketverarbeitungsleistung des VM-Betriebssystems oder der Anwendung bestimmt. Wenn die Bandbreite für ausgehenden Traffic ausreicht, jedoch Probleme beim eingehenden Traffic auftreten, lesen Sie den Abschnitt Server-Logging auf Informationen zum Serververhalten prüfen.
Schnittstelle MTU prüfen
Die MTU eines VPC-Netzwerks ist konfigurierbar. Die MTU der Schnittstelle auf der VM sollte mit dem MTU-Wert für das VPC-Netzwerk übereinstimmen, mit dem sie verbunden ist. Bei einem VPC-Netzwerk-Peering können VMs in verschiedenen Netzwerken unterschiedliche MTUs haben. Wenn dieses Szenario auftritt, wenden Sie den kleineren MTU-Wert auf die zugehörigen Schnittstellen an. Nicht übereinstimmende MTUs sind bei TCP meist kein Problem, können aber eins bei UDP sein.
Prüfen Sie die MTU der VPC. Wenn sich die VMs in zwei verschiedenen Netzwerken befinden, prüfen Sie beide Netzwerke.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
Prüfen Sie die MTU-Konfiguration für Ihre Netzwerkschnittstelle.
Linux
Die lo-Schnittstelle (Loopback) hat immer die MTU 65536 und kann für diesen Schritt ignoriert werden.
$ netstat -i
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
Loopback-Pseudoschnittstellen haben immer die MTU 4294967295 und können für diesen Schritt ignoriert werden.
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
Wenn die Schnittstellen- und Netzwerk-MTUs nicht übereinstimmen, können Sie die Schnittstellen-MTU neu konfigurieren. Eine Anleitung zum Aktualisieren der MTU für Windows-VMs finden Sie unter Einstellungen für VMs und MTU. Wenn sie übereinstimmen, wird das Problem wahrscheinlich durch die Serververfügbarkeit verursacht. Der nächste Schritt besteht darin, Logs darauf zu prüfen, ob eine VM neu gestartet, beendet oder live migriert wurde, um festzustellen, ob während der relevanten Zeit etwas mit Ihrer VM passiert ist.
Logs darauf prüfen, ob eine VM neu gestartet, beendet oder live migriert wurde
Während des Lebenszyklus einer VM kann eine VM vom Nutzer neu gestartet werden, für die Google Cloud-Wartung live migriert werden oder in seltenen Fällen verloren gehen und neu erstellt werden, wenn ein Fehler im physischen Host der VM auftritt. Diese Ereignisse können zu einer kurzen Erhöhung der Latenz oder zu Zeitüberschreitungen bei den Verbindungen führen. Wenn eines dieser Dinge mit der VM geschieht, wird das Ereignis protokolliert.
So rufen Sie Logs für Ihre VM auf:
Rufen Sie in der Google Cloud Console die Seite Logging auf.
Wählen Sie den Zeitraum aus, in dem die Latenz aufgetreten ist.
Verwenden Sie die folgende Logging-Abfrage, um festzustellen, ob ein VM-Ereignis nahe dem Zeitraum aufgetreten ist, in dem die Latenz aufgetreten ist:
resource.labels.instance_id:"INSTANCE_NAME" resource.type="gce_instance" ( protoPayload.methodName:"compute.instances.hostError" OR protoPayload.methodName:"compute.instances.OnHostMaintenance" OR protoPayload.methodName:"compute.instances.migrateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.terminateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.stop" OR protoPayload.methodName:"compute.instances.reset" OR protoPayload.methodName:"compute.instances.automaticRestart" OR protoPayload.methodName:"compute.instances.guestTerminate" OR protoPayload.methodName:"compute.instances.instanceManagerHaltForRestart" OR protoPayload.methodName:"compute.instances.preempted" )
Wenn VMs während der entsprechenden Zeit nicht neu gestartet oder migriert wurden, kann das Problem mit einem Ressourcenmangel zusammenhängen. Zur Überprüfung fahren Sie mit Netzwerk- und Betriebssystemstatistiken auf verworfene Pakete wegen Ressourcenmangel prüfen fort.
Netzwerk- und Betriebssystemstatistiken auf verworfene Pakete wegen Ressourcenmangel prüfen
Ressourcenmangel ist ein allgemeiner Begriff, der bedeutet, dass eine Ressource auf der VM, z. B. die Bandbreite für ausgehenden Traffic, mehr als möglich verarbeiten soll. Ein Ressourcenmangel kann dazu führen, dass Pakete verworfen werden, was zu Verbindungslatenz oder Zeitüberschreitungen führt. Diese Zeitüberschreitungen sind möglicherweise nicht beim Client- oder Serverstart sichtbar, können jedoch im Laufe der Zeit auftreten, wenn ein System seine Ressourcen aufbraucht.
Im Folgenden finden Sie eine Liste von Befehlen, die Paketzähler und Statistiken anzeigen. Bei einigen dieser Befehle werden die Ergebnisse anderer Befehle dupliziert. In solchen Fällen können Sie den Befehl verwenden, der für Sie besser geeignet ist. Lesen Sie die Hinweise in den einzelnen Abschnitten, um das beabsichtigte Ergebnis des Befehls zu verstehen. Es kann nützlich sein, die Befehle zu verschiedenen Zeiten auszuführen, um zu sehen, ob Verwerfungen oder Fehler gleichzeitig mit dem Problem auftreten.
Linux
Verwenden Sie den Befehl
netstat, um Netzwerkstatistiken aufzurufen.$ netstat -sTcpExt: 341976 packets pruned from receive queue because of socket buffer overrun 6 ICMP packets dropped because they were out-of-window 45675 TCP sockets finished time wait in fast timer 3380 packets rejected in established connections because of timestamp 50065 delayed acks sent
Der Befehl "netstat" gibt Netzwerkstatistiken aus, die Werte für verworfene Pakete nach Protokoll enthalten. Verworfene Pakete können die Folge eines durch die Anwendung oder Netzwerkschnittstelle verursachten Ressourcenmangels sein. Sehen Sie sich den Zählergrund an, um zu erfahren, warum ein Zähler erhöht wurde.
Prüfen Sie kern.log auf Logs, die mit
nf_conntrack: table full, dropping packetübereinstimmen.Debian:
cat /var/log/kern.log | grep "dropping packet"CentOS:
sudo cat /var/log/dmesg | grep "dropping packet"Dieses Log gibt an, dass die Tabelle für das Verbindungs-Tracking für die VM die maximale Anzahl von Verbindungen erreicht hat, die verfolgt werden können. Weitere Verbindungen zu und von dieser VM können zu einer Zeitüberschreitung führen. Wenn "conntrack" aktiviert war, finden Sie die maximale Anzahl der Verbindungen mit
sudo sysctl net.netfilter.nf_conntrack_max.Sie können den Wert für die maximale Anzahl verfolgter Verbindungen erhöhen, indem Sie sysctl
net.netfilter.nf_conntrack_maxändern oder eine VM-Arbeitslast auf mehrere VMs verteilen, um die Last zu reduzieren.
Windows-Benutzeroberfläche
Perfmon
- Suchen Sie im Windows-Menü nach "perfmon" und öffnen Sie das Programm.
- Wählen Sie im Menü auf der linken Seite Leistung > Überwachungstools > Leistungsüberwachung aus.
- Klicken Sie in der Hauptansicht auf das grüne Pluszeichen (+), um dem Überwachungsdiagramm Leistungszähler hinzuzufügen. Die folgenden Zähler sind von Interesse:
- Netzwerkadapter
- Ausgabewarteschlangenlänge
- Ausgehende Pakete, verworfen
- Ausgehende Pakete, Fehler
- Empfangene Pakete, verworfen
- Empfangene Pakete, Fehler
- Empfangene Pakete, unbekannt
- Netzwerkschnittstelle
- Ausgabewarteschlangenlänge
- Ausgehende Pakete, verworfen
- Ausgehende Pakete, Fehler
- Empfangene Pakete, verworfen
- Empfangene Pakete, Fehler
- Empfangene Pakete, unbekannt
- Netzwerkschnittstellenkarten-Aktivität pro Prozessor
- Empfangsanzeigen mit geringen Ressourcen pro Sekunde
- Empfangene Pakete mit geringen Ressourcen pro Sekunde
- Prozessor
- Interruptzeit (%)
- Privilegierte Zeit (%)
- Prozessorzeit (%)
- Benutzerzeit (%)
- Netzwerkadapter
Mit Perfmon können Sie die oben genannten Zähler in einem Zeitachsendiagramm darstellen. Dies kann hilfreich sein, wenn Tests stattfinden oder ein Server betroffen ist. Spitzen in CPU-bezogenen Zählern wie "Interruptzeit" und "Privilegierte Zeit" können auf Sättigungsprobleme hinweisen, wenn die VM die CPU-Durchsatzgrenzen erreicht. Pakete und Fehler können auftreten, wenn die CPU gesättigt ist, wodurch Pakete verloren gehen, bevor sie von den Client- oder Server-Sockets verarbeitet werden. Schließlich wird die Ausgabewarteschlangenlänge während der CPU-Sättigung zunehmen, da mehr Pakete zur Verarbeitung in die Warteschlange gestellt werden.
Windows Powershell
PS C:\> netstat -s
IPv4 Statistics Packets Received = 56183 Received Header Errors = 0 Received Address Errors = 0 Datagrams Forwarded = 0 Unknown Protocols Received = 0 Received Packets Discarded = 25 Received Packets Delivered = 56297 Output Requests = 47994 Routing Discards = 0 Discarded Output Packets = 0 Output Packet No Route = 0 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0
Der Befehl "netstat" gibt Netzwerkstatistiken aus, die Werte für verworfene Pakete nach Protokoll enthalten. Verworfene Pakete können die Folge eines durch die Anwendung oder Netzwerkschnittstelle verursachten Ressourcenmangels sein.
Wenn Ressourcenmangel auftritt, können Sie versuchen, die Arbeitslast auf mehr Instanzen zu verteilen, die VM auf eine mit mehr Ressourcen zu aktualisieren, das Betriebssystem oder die Anwendung an bestimmte Leistungsanforderungen anzupassen, die Fehlermeldung in eine Suchmaschine einzugeben, um mögliche Lösungen zu finden, oder mit einer der Methoden, die unter Wenn weiterhin Probleme auftreten beschrieben werden, um Unterstützung zu bitten
Wenn Ressourcenmangel nicht das Problem zu sein scheint, liegt es möglicherweise an der Serversoftware selbst. Eine Anleitung zur Behebung von Problemen mit der Serversoftware finden Sie unter Server-Logging auf Informationen zum Serververhalten prüfen.
Server-Logging auf Informationen zum Serververhalten prüfen
Wenn die obigen Schritte kein Problem aufzeigen, können die Zeitüberschreitungen durch das Anwendungsverhalten wie Verarbeitungsstopps verursacht werden, die wiederum durch vCPU-Mangel verursacht werden. Prüfen Sie die Server- und Anwendungslogs auf Hinweise zum aufgetretenen Verhalten.
Beispielsweise kann ein Server, der aufgrund eines vorgelagerten Systems, z. B. einer überlasteten Datenbank, eine erhöhte Latenz aufweist, eine übermäßige Anzahl von Anfragen in die Warteschlange stellen, was zu einer erhöhten Arbeitsspeichernutzung und längeren CPU-Wartezeiten führen kann. Diese Faktoren können zu fehlgeschlagenen Verbindungen oder zum Überlauf des Socket-Zwischenspeichers führen.
TCP-Verbindungen verlieren gelegentlich ein Paket. Bei selektiver Bestätigung und wiederholter Paketübertragung werden verlorene Pakete jedoch in der Regel wiederhergestellt, wodurch Zeitüberschreitungen bei Verbindungen vermieden werden. Stattdessen können Zeitüberschreitungen dadurch verursacht werden, dass der Anwendungsserver ausgefallen ist oder neu bereitgestellt wird, was zu einem vorübergehenden Fehler bei den Verbindungen führt.
Wenn Ihre Serveranwendung auf eine Verbindung zu einer Datenbank oder einem anderen Dienst angewiesen ist, prüfen Sie, ob gekoppelte Dienste gut funktionieren. Diese Messwerte werden möglicherweise von Ihrer Anwendung erfasst.
Wenn weiterhin Probleme auftreten
Sollten weiterhin Probleme auftreten, finden Sie unter Support Informationen zu den nächsten Schritten. Die Ausgabe der beschriebenen Schritte zur Fehlerbehebung ist für die Freigabe für andere Mitbearbeiter nützlich.
Nächste Schritte
- Falls weiterhin Probleme auftreten, lesen Sie die Informationen auf der Seite der Ressourcen.