Probleme mit der Netzwerklatenz beheben
Informationen dazu, wie Sie die Verbindungslatenz zwischen Prozessen in Google Cloud verbessern und die Latenz von TCP-Verbindungen verringern können, finden Sie unter TCP-Optimierung für höhere Netzwerkleistung in Google Cloud und Hybridszenarien.
Fehlerbehebung bei unterbrochenem Netzwerktraffic
Compute Engine lässt nur Netzwerktraffic zu, dem die Firewallregeln Ihres Projekts ausdrücklich das Erreichen Ihrer Instanz erlauben. Alle Projekte erhalten automatisch ein Standardnetzwerk, das bestimmte Arten von Verbindungen zulässt. Wenn Sie jeglichen Traffic standardmäßig ablehnen, werden auch SSH-Verbindungen und der gesamte interne Traffic abgelehnt. Weitere Informationen finden Sie auf der Seite Firewallregeln.
Zusätzlich müssen möglicherweise die TCP-Keep-Alive-Einstellungen angepasst werden, um die standardmäßige zehnminütige Zeitüberschreitung bei inaktiven Verbindungen zu umgehen. Weitere Informationen finden Sie unter Kommunikation zwischen Instanzen und dem Internet.
Fehlerbehebung bei Firewallregeln oder Routen einer Instanz
Die Google Cloud Console stellt Netzwerkdetails für jede Netzwerkschnittstelle einer Instanz bereit. Sie können sich alle Firewallregeln oder Routen, die für eine Schnittstelle gelten, oder nur die von der Schnittstelle verwendeten Regeln und Routen ansehen. In beiden Fällen können Sie feststellen, welche Firewallregeln und Routen für die Instanz gelten und welche tatsächlich verwendet werden (wenn Prioritäten und Verarbeitungsreihenfolgen andere Regeln oder Routen überschreiben).
Siehe dazu auch die Informationen zur Fehlerbehebung in der Dokumentation zu Virtual Private Cloud:
- Firewallregeln für eine Netzwerkschnittstelle auflisten
- Routen für eine Netzwerkschnittstelle auflisten
Fehlerbehebung bei der Protokollweiterleitung für private Weiterleitungsregeln
In den folgenden Abschnitten erfahren Sie, wie Sie häufige Probleme im Zusammenhang mit der Protokollweiterleitung für private Weiterleitungsregeln beheben.
Beschränkung auf die Region
Die Protokollweiterleitung für private Weiterleitungsregeln ist ein regionales Produkt. Alle Clients und Zielinstanz-VMs müssen sich in derselben Region befinden.
Fehlermeldung: "An internal target instance can only be the target of one forwarding rule" (Eine interne Zielinstanz kann nur das Ziel einer Weiterleitungsregel sein)
Wenn die Fehlermeldung An internal target instance can only be the target
of one forwarding rule angezeigt wird, konfigurieren Sie möglicherweise zwei Weiterleitungsregeln, die auf dieselbe Zielinstanz verweisen. Es können nicht mehrere Weiterleitungsregeln auf dieselbe Zielinstanz verweisen.
Fehlerbehebung bei Latenz auf Compute Engine-VMs beim Verarbeiten hoher Paketraten
Wenn das Verarbeiten hoher Paketraten eine niedrige Latenz, verworfene Pakete oder Neuübertragungen bei der VM verursacht, sind auf der Netzwerkschnittstelle (NIC), die diese Pakete verarbeitet, möglicherweise nicht genügend Empfangswarteschlangen (Receive Queues, RX) oder Übertragungswarteschlangen (Transmit Queues, TX) vorhanden.
Informationen zum Beheben dieser Probleme finden Sie unter Empfangs- und Übertragungswarteschlangen. Hier wird beschrieben, wie Compute Engine RX- und TX-Warteschlangen zuweist.
Fehlerbehebung bei Überbelegungen für benutzerdefinierte NIC-Warteschlangen
Bei einer Warteschlangen-Überbelegung beträgt die maximale Anzahl der Warteschlangen für die VM:
[maximum queue count per VM] * [number of NICs]
Sie müssen jedoch die unter Benutzerdefinierte Zuweisung von Warteschlangen beschriebenen Bedingungen erfüllen. Wenn Sie beispielsweise für eine der für die VM konfigurierten NICs keine benutzerdefinierte Warteschlangenanzahl angegeben haben, wird ein Fehler ähnlich dem folgenden ausgegeben:
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Invalid value for field 'resource.networkInterfaces': ''. The total networking queue number is more than the number of vCPUs. Please specify the queue count for all of the interfaces.
Projekte wurden zu zonalem DNS migriert, aber VMs im neuen Projekt verwenden globales DNS
Wenn Sie die Migration Ihrer vorhandenen Projekte von der Verwendung des globalen DNS zur Verwendung des zonalen DNS abgeschlossen haben, aber Sie feststellen, dass VMs in einem neu erstellten Projekt globale DNS-Namen haben, haben Sie die boolesche Organisationsrichtlinie constraints/compute.setNewProjectDefaultToZonalDNSOnly auf Organisations- oder Ordnerebene nicht erzwungen. Mit dieser Richtlinie wird die Standard-DNS-Einstellung überschrieben, sodass neu erstellte Projekte standardmäßig das interne zonale DNS verwenden.
Eine Anleitung zum Erzwingen dieser Richtlinie finden Sie unter Zonales DNS standardmäßig nur für neue Projekte erzwingen.
Wenn Sie keine Organisationsrichtlinie verwenden, sondern stattdessen den Metadateneintrag VmDnsSetting=ZonalOnly für Projekte oder VMs verwenden, prüfen Sie den Metadatenwert für die VM. Wenn in den Metadaten der VM VmDnsSetting=GlobalDefault konfiguriert ist, wird dieser Wert über den Metadatenwert auf Projektebene hinweggeschrieben.
Informationen zum Festlegen von Werten für Projekt- oder MV-Metadaten finden Sie unter Benutzerdefinierte Metadaten festlegen.