Peering-Verbindungen

Auf dieser Seite finden Sie eine Übersicht über die Verwaltung von VPC-Netzwerk-Peering-Verbindungen.

Peering-Verbindung

Eine Peering-Verbindung verbindet zwei VPC-Netzwerke (Virtual Private Cloud). Zum Herstellen einer Peering-Verbindung erstellt jede Seite separat eine Peering-Konfiguration, die auf das andere Netzwerk verweist.

Sie initiieren die Anfrage zum Herstellen einer Verbindung zu einem anderen VPC-Netzwerk, indem Sie eine Peering-Konfiguration erstellen. Nachdem auch das andere Netzwerk eine entsprechende Konfiguration für das Peering mit Ihrem Netzwerk hat, wird die Peering-Verbindung hergestellt und der Peering-Status wechselt in beiden Netzwerken zu ACTIVE. Der Peering-Status bleibt INACTIVE, wenn das andere Netzwerk keine entsprechende Peering-Konfiguration hat. Das bedeutet, dass Ihr Netzwerk nicht mit dem anderen verbunden ist.

Durch das Erstellen einer Peering-Verbindung werden Ihnen keine IAM-Rollen (Identity and Access Management) im anderen VPC-Netzwerk zugewiesen. Wenn Sie beispielsweise die Rolle „Compute-Netzwerkadministrator“ (roles/compute.networkAdmin) oder die Rolle „Compute-Sicherheitsadministrator“ (roles/compute.securityAdmin) für ein Netzwerk haben, werden Sie kein Netzwerkadministrator oder Sicherheitsadministrator für das andere Netzwerk.

Nachdem die Peering-Verbindung hergestellt wurde, tauschen die beiden VPC-Netzwerke immer IPv4-Subnetzrouten aus, die private IPv4-Adressbereiche verwenden. Weitere Informationen zu den Optionen für den Routenaustausch finden Sie unter:

Verbindungsmodus

Der Verbindungsmodus bestimmt, wie eine Peering-Verbindung verwaltet wird. VPC-Netzwerk-Peering unterstützt zwei Verbindungsmodi:

Bei Standardbereitstellungen wird im Allgemeinen der unabhängige Modus bevorzugt. Bei Bereitstellungen, die einen kritischen Dienst unterstützen, bei dem das versehentliche Löschen der Peering-Verbindung zu einem Dienstausfall führen würde, empfehlen wir jedoch die Verwendung des Konsensmodus. Dieser Modus erfordert die Zustimmung beider Netzwerke und verhindert einseitige Änderungen am effektiven Status der Peering-Verbindung.

Beim Erstellen einer Peering-Verbindung muss in beiden Peering-Konfigurationen derselbe Verbindungsmodus angegeben werden: entweder unabhängig oder Konsens.

Wenn Sie den Peering-Modus einer bestehenden Verbindung von unabhängig in Konsens ändern möchten, müssen beide Peering-Konfigurationen aktualisiert werden. Das Ändern des Verbindungsmodus von Konsens in unabhängig wird nicht unterstützt.

Unabhängiger Modus

Wenn sich eine Peering-Verbindung im unabhängigen Modus (Standard) befindet, kann jedes Netzwerk die Verbindung jederzeit aktualisieren oder löschen. Optional können Sie dieses Verhalten einschränken, indem Sie den Verbindungsmodus in Konsens ändern.

Konsensmodus

Der Konsensmodus verhindert versehentliche, einseitige Änderungen am Netzwerkverhalten. Wenn sich eine Peering-Verbindung im Konsensmodus befindet, erfordert jede Anfrage zum Aktualisieren oder Löschen der Peering-Verbindung die Zustimmung beider Netzwerke.

Konsensmodus für eine Verbindung konfigurieren

Sie können eine neue oder vorhandene Peering-Verbindung so konfigurieren, dass der Konsensmodus verwendet wird, indem Sie den Parameter update_strategy festlegen:

  • Neue Verbindung : Beide Netzwerke müssen die Aktualisierungsstrategie auf CONSENSUS festlegen. Wenn die Aktualisierungsstrategie nicht angegeben ist, wird die Verbindung im unabhängigen Modus erstellt.

  • Vorhandene Verbindung : Beide Netzwerke müssen die Aktualisierungsstrategie in CONSENSUS ändern. Solange die beiden Werte nicht übereinstimmen, bleibt die effektive Aktualisierungsstrategie INDEPENDENT und einseitige Aktualisierungs- und Löschanfragen sind zulässig.

    Ausstehende Anfragen zum Aktualisieren des Verbindungsmodus führen nicht zu Ausfallzeiten. Die Verbindung bleibt aktiv, während die Anfrage verarbeitet wird.

Außerdem muss für die Konfiguration des Konsensmodus für eine Verbindung jede Option für den Routenaustausch in Ihrer Konfiguration denselben Wert haben wie das entsprechende Flag in der Peer-Konfiguration. Wenn die Werte für die folgenden Flags nicht übereinstimmen, wird die Anfrage zum Erstellen oder Aktualisieren der Verbindung abgelehnt.

Lokales Flag Ergänzendes Peer-Flag
import_custom_route export_custom_route
export_custom_route import_custom_route
import_subnet_routes_with_public_ip export_subnet_routes_with_public_ip
export_subnet_routes_with_public_ip import_subnet_routes_with_public_ip
stack_type stack_type

Wenn Ihr Netzwerk beispielsweise benutzerdefinierte Routen importiert, muss das Peer-Netzwerk benutzerdefinierte Routen exportieren. Wenn einer dieser Werte für eine bestehende Verbindung nicht übereinstimmt, kann jedes Netzwerk sie vor oder beim Ändern des Verbindungsmodus aktualisieren.

Wenn Sie eine ausstehende Anfrage zum Konfigurieren des Konsensmodus für eine bestehende Verbindung abbrechen möchten, muss das anfragende Netzwerk die Aktualisierungsstrategie auf INDEPENDENT zurücksetzen.

Weitere Informationen finden Sie unter Peering-Verbindung im Konsensmodus erstellen und Verbindung in den Konsensmodus ändern
modus.

Verbindung im Konsensmodus aktualisieren

Jede Seite einer Peering-Verbindung kann eine Aktualisierungsanfrage senden. Eine ausstehende Aktualisierungsanfrage führt nicht zu Ausfallzeiten. Die Verbindung bleibt aktiv. Wenn eine Löschanfrage verarbeitet wird, werden alle Aktualisierungsanfragen abgelehnt. Das gilt auch für das Annehmen oder Abbrechen einer ausstehenden Aktualisierungsanfrage.

Wenn Sie eine Peering-Verbindung aktualisieren möchten, die mit dem Konsensmodus konfiguriert wurde, muss der lokale Netzwerkadministrator zuerst die lokale Konfiguration aktualisieren. Anschließend muss der Netzwerkadministrator des Peers eine entsprechende Aktualisierung an der Peer-Konfiguration vornehmen. Wenn Sie beispielsweise das Flag --export-custom-routes auf true setzen, muss das Peer-Netzwerk das Flag --import-custom-routes auf true setzen. Der effektive Status der Peering-Verbindung ändert sich erst, wenn das Peer-Netzwerk die entsprechende Konfiguration aktualisiert.

Nachdem die lokale Peering-Konfiguration aktualisiert wurde, kann keine Seite der Verbindung weitere Aktualisierungsanfragen senden, bis die ursprüngliche Aktualisierung angenommen oder abgebrochen wurde. Teilweise Aktualisierungen werden nicht unterstützt. Wenn eine Anfrage mehrere Parameter aktualisiert, müssen alle angenommen oder abgebrochen werden. Wenn Sie eine Aktualisierung abbrechen möchten, setzt das anfragende Netzwerk jeden geänderten Parameter auf seinen vorherigen Wert zurück.

Das folgende Diagramm zeigt, wie sich der Status einer Peering-Verbindung ändert, wenn eine Aktualisierungsanfrage gesendet wird.

Peering-Verbindung im Konsensmodus aktualisieren
Peering-Verbindung im Konsensmodus aktualisieren (zum Vergrößern klicken)

Im vorherigen Diagramm ändert sich der Aktualisierungsstatus der Verbindung, nachdem Netzwerk A die Aktualisierungsanfrage gesendet hat, in der lokalen Konfiguration von IN_SYNC zu PENDING_PEER_ACKNOWLEDGMENT und in der Peer-Konfiguration zu PENDING_LOCAL_ACKNOWLEDGMENT.

Damit der Status wieder IN_SYNC lautet, muss Netzwerk B die entsprechende Änderung vornehmen oder Netzwerk A muss die Anfrage abbrechen. Weitere Informationen zu diesen Verbindungsstatus finden Sie unter Verbindungsstatus.

Informationen zum Aktualisieren einer Peering-Verbindung finden Sie unter Verbindung aktualisieren (Konsensmodus).

Verbindung im Konsensmodus löschen

Wenn Sie eine Peering-Verbindung im Konsensmodus löschen möchten, müssen beide Seiten der Verbindung eine Löschanfrage senden. Sie können eine Löschanfrage abbrechen , bevor oder nachdem sie vom Peer-Netzwerk angenommen wurde.

Für Löschanfragen gelten die folgenden Bedingungen:

  • Wenn eine Aktualisierungsanfrage aussteht, können Sie die Peering-Verbindung trotzdem löschen.
  • Wenn eine Löschanfrage aussteht, werden alle Aktualisierungsanfragen abgelehnt. Das gilt auch für das Annehmen oder Abbrechen einer ausstehenden Aktualisierung. Wenn Sie eine ausstehende Aktualisierung abschließen möchten, müssen Sie zuerst die Löschanfrage abbrechen.

Weitere Informationen finden Sie unter Verbindung löschen (Konsensmodus).

Verbindungsstatus

Mit dem gcloud compute networks describe Befehl werden sowohl der effektive Status einer Peering-Verbindung als auch Ihre lokale Peering-Konfiguration angezeigt.

Sie können den effektiven Verbindungsstatus im Feld peerings.connectionStatus sehen. In der folgenden Tabelle werden die verfügbaren Konfigurationsstatus beschrieben. Das Häkchen gibt an, dass das Feld verfügbar ist.

Feld Unabhängiger Modus Konsensmodus Beschreibung
trafficConfiguration Zeigt die effektiven Optionen für den Routenaustausch der Peering-Verbindung.
updateStrategy Zeigt den effektiven Verbindungsmodus an: entweder INDEPENDENT oder CONSENSUS.
consensusState.deleteStatus
  • UNSPECIFIED: Für diese Peering-Verbindung sind keine requestRemovePeering -Anfragen ausstehend. Das deleteStatus Feld wird in der Ausgabe nicht angezeigt wenn der Status UNSPECIFIED ist.
  • LOCAL_DELETE_REQUESTED: Der Inhaber dieses Peerings hat das Löschen der Peering-Verbindung angefordert.
  • PEER_DELETE_REQUESTED: Der Inhaber des entsprechenden Peerings hat das Löschen der Peering-Verbindung angefordert.
  • DELETE_ACKNOWLEDGED: Beide Inhaber dieses Peerings haben das Löschen der Peering-Verbindung angefordert. Nachfolgende removePeering Anfragen sind für beide Peerings erfolgreich.
  • LOCAL_CANCEL_REQUESTED: Die Peering-Verbindung hatte den Status DELETE_ACKNOWLEDGED aber das lokale Netzwerk hat das Löschen abgebrochen.
  • PEER_CANCEL_REQUESTED: the peering connection was in the state, but the peer network has canceled the deletion.DELETE_ACKNOWLEDGED
consensusState.updateStatus
  • IN_SYNC: Keiner der Peering-Inhaber hat ausstehende Aktualisierungen.
  • PENDING_PEER_ACKNOWLEDGMENT: Der lokale Peering-Inhaber hat eine Änderung vorgenommen, aber der entsprechende Peering-Inhaber hat die entsprechenden Änderungen nicht auf sein Peering angewendet.
  • PENDING_LOCAL_ACKNOWLEDGMENT: Der entsprechende Peering Inhaber hat eine Änderung vorgenommen, aber der lokale Peering-Inhaber hat die entsprechenden Änderungen nicht auf dieses Peering angewendet.

Informationen zum Auflisten aller Peering-Konfigurationen in einem Google Cloud Projekt finden Sie unter Peering-Verbindungen auflisten.

Nächste Schritte