Nur-Proxy-Subnetze für Envoy-basierte Load-Balancer

Auf dieser Seite wird gezeigt, wie Sie Nur-Proxy-Subnetze verwenden, die von Envoy-basierten Load-Balancern verwendet werden. Ein Nur-Proxy-Subnetz bietet einen Pool von IP-Adressen, die ausschließlich für Envoy-Proxys reserviert sind, die von Load-Balancern von Google Cloud verwendet werden. Es kann nicht für andere Zwecke verwendet werden.

Die Proxys beenden eingehende Verbindungen und entscheiden dann anhand der URL-Zuordnung, der Sitzungsaffinität des Backend-Dienstes, des Load-Balancing-Modus jeder Backend-Instanzgruppe oder NEG und anderer Faktoren, wohin eine Anfrage gesendet wird.

  1. Ein Client stellt eine Verbindung zur IP-Adresse und zum Port der Weiterleitungsregel des Load-Balancers her.

  2. Jeder Proxy überwacht die IP-Adresse und den Port, die in der Weiterleitungsregel des entsprechenden Load-Balancers angegeben sind. Einer der Proxys empfängt und beendet die Netzwerkverbindung des Clients.

  3. Der Proxy stellt eine Verbindung zur entsprechenden Backend-VM oder zum entsprechenden Backend-Endpunkt einer Netzwerk-Endpunktgruppe her. Dies richtet sich nach der URL-Zuordnung und den Backend-Diensten des Load-Balancers.

Jedem Proxy des Load-Balancers wird eine interne IP-Adresse zugewiesen. Pakete, die von einem Proxy an eine Backend-VM oder einen Backend-Endpunkt gesendet wird, hat eine Quell-IP-Adresse aus dem Nur-Proxy-Subnetz.

Das Nur-Proxy-Subnetz kann nicht für andere Zwecke verwendet werden. Die IP-Adresse für die Weiterleitungsregel des Load Balancers stammt nicht aus dem Nur-Proxy-Subnetz. Auch die IP-Adressen der Backend-VMs und -Endpunkte kommen nicht aus dem Nur-Proxy-Subnetz.

Unterstützte Load-Balancer

Die folgenden Envoy-basierten Load-Balancer erfordern Nur-Proxy-Subnetze:

Nur-Proxy-Subnetze in der Load-Balancer-Architektur

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für einen regionalen internen Application Load Balancer erforderlich sind.

Nummerierte Komponenten eines regionalen internen Application Load Balancers.
Nummerierte Komponenten eines regionalen internen Application Load Balancers (zum Vergrößern klicken)

Wie in den Diagrammen dargestellt, sind für die Bereitstellung eines Envoy-basierten Load-Balancers mindestens zwei Subnetze erforderlich:

  • Die Backend-VMs und Backend-Endpunkte des Load-Balancers verwenden ein einzelnes Subnetz mit dem primären IP-Adressbereich 10.1.2.0/24 (in diesem Beispiel). Dieses Subnetz ist nicht das Nur-Proxy-Subnetz. Sie können für Ihre Backend-VMs und -Endpunkte mehrere Subnetze verwenden. Die Subnetze müssen sich dazu in derselben Region wie der Load-Balancer befinden. Bei internen Application Load Balancern kann sich die IP-Adresse des Load-Balancers, der der Weiterleitungsregel zugeordnet ist, auch in diesem Subnetz befinden. Dies muss jedoch nicht sein.
  • Das Nur-Proxy-Subnetz ist 10.129.0.0/23 (in diesem Beispiel).

Empfehlungen zur Nur-Proxy-Subnetzgröße

Ein Nur-Proxy-Subnetz muss mindestens 64 IP-Adressen bereitstellen. Das entspricht einer Präfixlänge von maximal /26. Wir empfehlen, mit einem Nur-Proxy-Subnetz mit dem Präfix /23 (512 Nur-Proxy-Adressen) zu beginnen und die Größe zu ändern, wenn sich Ihr Traffic ändert.

Proxys werden auf VPC-Ebene und nicht auf Load-Balancer-Ebene zugewiesen. Sie müssen in jeder Region eines VPC-Netzwerks, in dem Sie Envoy-basierte Load-Balancer verwenden, ein Nur-Proxy-Subnetz anlegen. Wenn Sie mehrere Load-Balancer in derselben Region und im selben VPC-Netzwerk bereitstellen, nutzen sie dasselbe Nur-Proxy-Subnetz für das Load-Balancing.

Envoy-basierte Load Balancer skalieren die Anzahl der verfügbaren Proxys automatisch, um Ihren Traffic bedarfsgerecht zu verwalten. Die Gebühr pro Proxy-Instanz hängt von der Anzahl der Proxy-Instanzen ab, die für die Trafficanforderungen benötigt werden. Für jeden zusätzlichen Proxy fällt gemäß den Preisen in der vorangegangenen Tabelle eine zusätzliche Stundengebühr an.

Die Anzahl der Ihrem Proxy zugewiesenen Proxys wird auf der Grundlage der gemessenen Kapazität berechnet, die erforderlich ist, um Ihren Traffic über einen Zeitraum von zehn Minuten zu verwalten. Während dieses Zeitraums wird der größere der folgenden Faktoren ermittelt:

  • Die Anzahl der für die Bandbreitenanforderungen Ihres Traffics erforderlichen Proxys. Jede Proxy-Instanz kann pro Sekunde 18 MB verarbeiten. Die insgesamt erforderliche Bandbreite wird ermittelt und der Gesamtwert durch die Bandbreite geteilt, die eine Proxy-Instanz unterstützen kann.
  • Die zur Verwaltung von Verbindungen und Anfragen erforderliche Anzahl von Proxys. Die folgenden Ressourcen werden gezählt und jeder Wert durch die Menge geteilt, die eine Proxy-Instanz unterstützen kann:
    • 600 (HTTP) oder 150 (HTTPS) neue Verbindungen pro Sekunde
    • 3.000 aktive Verbindungen
    • 1.400 Anfragen pro Sekunde*

* Eine Proxy-Instanz kann 1.400 Anfragen pro Sekunde verwalten, wenn Cloud Logging deaktiviert ist. Wenn Sie Logging aktivieren, kann eine Proxy-Instanz weniger Anfragen pro Sekunde verwalten. Wenn z. B. 100 % der Anfragen geloggt werden, nimmt die Kapazität eines Proxys für die Verwaltung von Anfragen auf 700 Anfragen pro Sekunde ab. Sie können Logging so einstellen, dass ein kleinerer Prozentanteil des Traffics erfasst wird. So können Sie Ihre Kontrollanforderungen erfüllen und gleichzeitig die Kosten steuern.

Ein detailliertes Beispiel für die Abrechnung von Nur-Proxy-Subnetzen finden Sie in der Dokumentation zu Cloud Load Balancing unter Gebühren für Proxy-Instanzen.

Nur-Proxy-Subnetz erstellen

Nur-Proxy-Subnetze für Envoy-basierte Load Balancer müssen unabhängig davon erstellt werden, ob Ihr Netzwerk im automatischen oder im benutzerdefinierten Modus arbeitet. Das Erstellen eines Nur-Proxy-Subnetzes erfolgt im Wesentlichen wie beim Erstellen eines Subnetzes, mit dem einzigen Unterschied, dass einige Flags hinzugefügt werden.

Bei einem Nur-Proxy-Subnetz muss --purpose entweder auf REGIONAL_MANAGED_PROXY oder GLOBAL_MANAGED_PROXY festgelegt sein, je nach Load Balancer.

Sie können ein vorhandenes Subnetz nicht als Nur-Proxy-Subnetz wiederverwenden. In jeder Region, die einen Envoy-basierten Load-Balancer hat, müssen Sie ein neues Subnetz erstellen. Das liegt zum Teil daran, dass mit dem Befehl subnets update das Feld --purpose eines Subnetzes nicht geändert werden kann.

Damit Sie Weiterleitungsregeln für Ihre regionalen Load-Balancer erstellen können, müssen Sie vorher für die Proxys der Load-Balancer ein Nur-Proxy-Subnetz einrichten. Wenn Sie versuchen, einen Load-Balancer zu konfigurieren, ohne zuvor ein Nur-Proxy-Subnetz für die Region erstellt zu haben, schlägt das Erstellen des Load-Balancers fehl.

Console

  1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
    Zur Seite "VPC-Netzwerke"
  2. Klicken Sie auf den Namen des freigegebenen VPC-Netzwerks, dem Sie ein Nur-Proxy-Subnetz hinzufügen möchten.
  3. Klicken Sie auf Subnetz hinzufügen.
  4. Geben Sie einen Namen ein.
  5. Region auswählen:
  6. Legen Sie für Zweck einen der folgenden Werte fest:
    • Für regionale Load Balancer: Regional verwalteter Proxy
    • Für regionenübergreifende Load Balancer: Regionenübergreifender verwalteter Proxy
    • Geben Sie einen IP-Adressbereich ein.
    • Klicken Sie auf Hinzufügen.

gcloud

Ein Nur-Proxy-Subnetz wird mit dem Befehl gcloud compute networks subnets create erstellt.

gcloud compute networks subnets create SUBNET_NAME \
    --purpose=SUBNET_PURPOSE \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

Die Felder sind so definiert:

  • SUBNET_NAME ist der Name des Nur-Proxy-Subnetzes.
  • SUBNET_PURPOSE ist der Zweck des Subnetzes. Setzen Sie dies auf, entweder REGIONAL_MANAGED_PROXY oder GLOBAL_MANAGED_PROXY, je nach Ihrem Load-Balancer.
  • REGION ist die Region des Nur-Proxy-Subnetzes.
  • VPC_NETWORK_NAME ist der Name des VPC-Netzwerks, das das Subnetz enthält.
  • CIDR_RANGE ist der primäre IP-Adressbereich des Subnetzes. Die Subnetzmaske darf maximal 26 lang sein, damit mindestens 64 IP-Adressen für Proxys in der Region verfügbar sind. Als Länge der Subnetzmaske wird /23 empfohlen.

Ein vollständiges Konfigurationsbeispiel finden Sie unter Nur-Proxy-Subnetz konfigurieren.

Damit Verbindungen vom Nur-Proxy-Subnetz akzeptiert werden, müssen Sie eine Firewallregel für Ihre Back-Ends konfigurieren. Ein vollständiges Konfigurationsbeispiel einschließlich der Einrichtung der Firewallregel finden Sie hier:

Proxyverfügbarkeit

Manchmal haben Google Cloud-Regionen nicht genügend Proxykapazität für einen neuen Load-Balancer. In diesem Fall gibt die Google Cloud Console beim Erstellen des Load-Balancers eine Warnmeldung zur Proxyverfügbarkeit aus. Sie haben folgende Möglichkeiten, dieses Problem zu beheben:

  • Wählen Sie eine andere Region für den Load-Balancer aus. Diese Option kann sinnvoll sein, wenn Sie Back-Ends in einer anderen Region haben.
  • Wählen Sie ein VPC-Netzwerk aus, dem bereits ein Nur-Proxy-Subnetz zugewiesen ist.
  • Warten Sie, bis das Kapazitätsproblem behoben ist.

Größe oder Adressbereich eines Nur-Proxy-Subnetzes ändern

Wenn die Menge des von Ihrem Load Balancer verarbeiteten Traffic zunimmt, müssen Sie möglicherweise Ihr Nur-Proxy-Subnetz vergrößern, um Ihrem Load-Balancer eine größere Anzahl von Envoy-Proxys zuzuweisen.

Sie können ein Nur-Proxy-Subnetz nicht auf dieselbe Weise erweitern wie bei einem primären Adressbereich (mit dem Befehl expand-ip-range). Stattdessen müssen Sie ein Nur-Proxy-Subnetz als Sicherung erstellen, das Ihren Anforderungen entspricht, und es dann der aktiven Rolle zuweisen. Dies liegt daran, dass nur ein einzelnes Nur-Proxy-Subnetz pro Region und VPC-Netzwerk aktiv sein kann und Sie nur den primären IP-Adressbereich eines Subnetzes erweitern können.

Neue Verbindungen bleiben vom Hochstufen eines Nur-Proxy-Sicherungssubnetzes zum aktiven Nur-Proxy-Subnetz unberührt:

  • Das neu aktivierte Nur-Proxy-Subnetz wird für neue Verbindungen verwendet.
  • Das zuvor aktive und jetzt zum Sicherungssubnetz herabgestufte Nur-Proxy-Subnetz wird für neue Verbindungen nicht mehr verwendet.
  • Google Cloud beginnt, vorhandene Verbindungen von Proxys im zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetz auszugleichen.

Sie können pro Region und VPC-Netzwerk nur ein aktives Nur-Proxy-Subnetz und nur ein Nur-Proxy-Sicherungssubnetz erstellen.

Console

  1. Erstellen Sie ein Nur-Proxy-Sicherungssubnetz in derselben Region und geben Sie einen primären IP-Adressbereich an, der Ihren Anforderungen entspricht.

    1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
      Zur Seite "VPC-Netzwerke"
    2. Klicken Sie auf den Namen des freigegebenen VPC-Netzwerks, dem Sie ein Nur-Proxy-Subnetz hinzufügen möchten.
    3. Klicken Sie auf Subnetz hinzufügen.
    4. Geben Sie einen Namen ein.
    5. Region auswählen:
    6. Legen Sie für Zweck einen der folgenden Werte fest:
      • Für regionale Load Balancer: Regional verwalteter Proxy
      • Für regionenübergreifende Load Balancer: Regionenübergreifender verwalteter Proxy
      • Wählen Sie als Rolle die Option Sicherung aus.
      • Geben Sie einen IP-Adressbereich ein.
      • Klicken Sie auf Hinzufügen.

  2. Erstellen oder ändern Sie für Ihre Backend-VMs oder -Endpunkte Firewallregeln, die eingehenden Traffic zulassen. Die Regeln müssen den primären IP-Adressbereich des Nur-Proxy-Sicherungssubnetzes enthalten.

  3. Stufen Sie das Nur-Proxy-Subnetz, das als Back-up dient, zum aktiven Subnetz hoch. Diese Aktion stuft auch das zuvor aktive Nur-Proxy-Subnetz zur Back-up-Rolle herab:

    1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
      Zur Seite "VPC-Netzwerke"
    2. Klicken Sie auf den Namen des freigegebenen VPC-Netzwerks, das Sie ändern möchten.
    3. Suchen Sie unter Reservierte Nur-Proxy-Subnetze für das Load-Balancing das im vorherigen Schritt erstellte Sicherungssubnetz.
    4. Klicken Sie auf Activate (Aktivieren).
    5. Geben Sie ein optionales Drain-Zeitlimit an.
    6. Klicken Sie auf Subnetz aktivieren.

  4. Wenn das Zeitlimit für den Verbindungsausgleich abgelaufen ist oder sichergestellt ist, dass Verbindungen zu Ihren Backend-VMs oder -Endpunkten nicht von Proxys im zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetz stammen, haben Sie folgende Möglichkeiten:

    • Ändern Sie die Firewallregeln für zulässigen eingehenden Traffic für Ihre Backend-VMs oder -Endpunkte so, dass diese nicht den primären IP-Adressbereich des zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetzes enthalten.
    • Durch Löschen des zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetzes können Sie die IP-Adressen freigeben, die dieses Subnetz für seinen primären IP-Adressbereich verwendet hat.

gcloud

In den folgenden Schritten wird davon ausgegangen, dass Sie bereits ein aktives Nur-Proxy-Subnetz haben.

  1. Erstellen Sie ein Nur-Proxy-Sicherungssubnetz in derselben Region und geben Sie mit dem Befehl gcloud compute networks subnets create mit dem Flag --role=BACKUP einen primären IP-Bereich an, der Ihren Anforderungen entspricht.

    gcloud compute networks subnets create BACKUP_PROXY_ONLY_SUBNET_NAME \
   --purpose=SUBNET_PURPOSE \
   --role=BACKUP \
   --region=REGION \
   --network=VPC_NETWORK_NAME \
   --range=BACKUP_PROXY_ONLY_SUBNET_RANGE

    Ersetzen Sie Folgendes:

    • BACKUP_PROXY_ONLY_SUBNET_NAME: der Name des neu erstellten Nur-Proxy-Sicherungssubnetzes
    • SUBNET_PURPOSE: der Zweck des neu erstellten Nur-Proxy-Sicherungssubnetzs
    • REGION: die Region des neu erstellten Nur-Proxy-Sicherungssubnetzs Das sollte dieselbe Region sein wie das aktuelle Nur-Proxy-Subnetz.
    • REGION: das Netzwerk des neu erstellten Nur-Proxy-Sicherungssubnetzs Dies sollte dasselbe Netzwerk wie das aktuelle aktive Nur-Proxy-Subnetz sein.
    • BACKUP_PROXY_ONLY_SUBNET_RANGE: der CIDR-Bereich des neu erstellten Nur-Proxy-Sicherungssubnetzs

  2. Erstellen oder ändern Sie für Ihre Backend-VMs oder -Endpunkte Firewallregeln, die eingehenden Traffic zulassen. Die Regeln müssen jetzt den primären IP-Adressbereich des Nur-Proxy-Sicherungssubnetzes enthalten. Die Firewallregel sollte bereits Verbindungen aus dem aktiven Subnetz akzeptieren.

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges ACTIVE_PROXY_ONLY_SUBNET_RANGE,BACKUP_PROXY_ONLY_SUBNET_RANGE

    Ersetzen Sie Folgendes:

    • PROXY_ONLY_SUBNET_FIREWALL_RULE: der Name der Firewallregel, die Traffic vom Nur-Proxy-Subnetz zulässt, um Ihre Backend-Instanzen oder Endpunkte zu erreichen
    • ACTIVE_PROXY_ONLY_SUBNET_RANGE: CIDR-Bereich des aktuellen aktiven Nur-Proxy-Subnetzes.

  3. Legen Sie das neue Subnetz als ACTIVE Nur-Proxy-Subnetz in der Region fest und warten Sie, bis der Verbindungsausgleich des alten Subnetzes abgeschlossen ist. Diese Aktion stuft auch das zuvor aktive Nur-Proxy-Subnetz zur Back-up-Rolle herab:

    Wenn Sie einen sofortigen Verbindungsausgleich für einen IP-Adressbereich ausführen möchten, legen Sie für --drain-timeout den Wert 0s fest. Dadurch werden unmittelbar alle Verbindungen zu den Proxys beendet, denen Adressen im Subnetz zugewiesen wurden, für das ein Verbindungsausgleich ausgeführt wird.

    gcloud compute networks subnets update BACKUP_PROXY_ONLY_SUBNET_NAME \
   --region=REGION \
   --role=ACTIVE \
   --drain-timeout=CONNECTION_DRAINING_TIMEOUT

    Ersetzen Sie Folgendes:

    • CONNECTION_DRAINING_TIMEOUT: die Zeit in Sekunden, die Google Cloud zum Migrieren vorhandener Verbindungen von Proxys im zuvor aktiven Nur-Proxy-Subnetz zur Verfügung hat.

  4. Kontrollieren Sie den Status des Verbindungsausgleichs mit dem Befehl list oder describe. Das Subnetz hat während des Verbindungsausgleichs den Status DRAINING.

    gcloud compute networks subnets list

    Warten Sie, bis der Verbindungsausgleich abgeschlossen ist. Anschließend erhält das alte Nur-Proxy-Subnetz den Status READY.

  5. Ändern Sie die Nur-Proxy-Firewall-Regel, um nur Verbindungen aus dem neuen Subnetz zuzulassen.

    gcloud compute firewall-rules PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges BACKUP_PROXY_ONLY_SUBNET_RANGE

  6. Wenn Sie sicher sind, dass Verbindungen zu Ihren Backend-VMs oder -Endpunkten nicht von Proxys im zuvor aktiven und jetzt zum Sicherungssubnetz herabgestuften Nur-Proxy-Subnetz stammen, können Sie das alte Subnetz löschen.

    gcloud compute networks subnets delete ACTIVE_PROXY_ONLY_SUBNET_NAME \
  --region=REGION

Zweck eines Nur-Proxy-Subnetzes migrieren

Wenn Sie zuvor ein Nur-Proxy-Subnetz mit --purpose=INTERNAL_HTTPS_LOAD_BALANCER erstellt haben, müssen Sie den Zweck des Subnetzes zu REGIONAL_MANAGED_PROXY migrieren, bevor Sie andere Envoy-basierte Load-Balancer in derselben Region des VPC-Netzwerks erstellen können.

Console

Wenn Sie den Load-Balancer über die Google Cloud Console erstellen, werden Sie aufgefordert, den Zweck eines zuvor erstellten Nur-Proxy-Subnetzes aus --purpose=INTERNAL_HTTPS_LOAD_BALANCER in REGIONAL_MANAGED_PROXY zu migrieren, während Sie den Load-Balancer erstellen.

gcloud

Verwenden Sie den folgenden Befehl, um den Zweck eines vorhandenen Nur-Proxy-Subnetzes von --purpose=INTERNAL_HTTPS_LOAD_BALANCER in REGIONAL_MANAGED_PROXY zu ändern:

gcloud compute networks subnets update PROXY_ONLY_SUBNET \
    --purpose=REGIONAL_MANAGED_PROXY \
    --region=REGION

Die Migration des Zwecks eines Nur-Proxy-Subnetzes von --purpose=INTERNAL_HTTPS_LOAD_BALANCER zu REGIONAL_MANAGED_PROXY verursacht keine Ausfallzeiten. Die Änderung sollte fast sofort wirksam werden.

Nur-Proxy-Subnetz löschen

Wenn Sie ein Nur-Proxy-Subnetz löschen, wird sein primärer IP-Adressbereich freigegeben und kann für einen anderen Zweck verwendet werden. Für Google Cloud gelten bei Eingang einer Anfrage zum Löschen eines Nur-Proxy-Subnetzes die folgenden Regeln:

  • Ein aktives Nur-Proxy-Subnetz kann nicht gelöscht werden, wenn sich in derselben Region und im selben VPC-Netzwerk ein oder mehrere regionale Load-Balancer befinden.

  • Ein aktives Nur-Proxy-Subnetz kann nicht gelöscht werden, wenn in derselben Region und im selben VPC-Netzwerk ein Nur-Proxy-Sicherungssubnetz vorhanden ist.

    Wenn Sie versuchen, ein aktives Nur-Proxy-Subnetz zu löschen, bevor Sie die Sicherung löschen, wird die folgende Fehlermeldung angezeigt: "Ungültige Ressourcennutzung: Aktives Subnetzwerk kann nicht gelöscht werden, da ein Sicherungssubnetz vorhanden ist."

In der Praxis haben diese Regeln folgende Auswirkungen:

  • Wenn in einer bestimmten Region und in einem bestimmten VPC-Netzwerk kein regionaler Load-Balancer definiert ist, können Sie die Nur-Proxy-Subnetze in dieser Region löschen. Wenn ein Nur-Proxy-Sicherungssubnetz vorhanden ist, müssen Sie dieses vor dem aktiven Nur-Proxy-Subnetz löschen.

  • Wenn in einer bestimmten Region und in einem bestimmten VPC-Netzwerk mindestens ein regionaler Load-Balancer festgelegt ist, können Sie das aktive Nur-Proxy-Subnetz nicht löschen. Sie haben aber die Möglichkeit, ein Nur-Proxy-Sicherungssubnetz zum aktiven Subnetz hochzustufen. Dadurch wird das zuvor aktive Nur-Proxy-Subnetz automatisch zum Sicherungssubnetz herabgestuft. Nachdem die Verbindungen geändert wurden, können Sie das (zuvor aktive) Nur-Proxy-Subnetz löschen.

Weitere Informationen finden Sie in der VPC-Netzwerkdokumentation unter Subnetze löschen.

Beschränkungen

Für Nur-Proxy-Subnetze gelten die folgenden Einschränkungen:

  • Sie können nicht sowohl ein INTERNAL_HTTPS_LOAD_BALANCER als auch ein REGIONAL_MANAGED_PROXY Subnetz im selben Netzwerk und in derselben Region haben, genauso wie Sie nicht zwei REGIONAL_MANAGED_PROXY Proxys oder zwei INTERNAL_HTTPS_LOAD_BALANCER Proxys haben können.

  • Sie können pro Region und VPC-Netzwerk nur ein aktives Nur-Proxy-Subnetz und nur ein Nur-Proxy-Sicherungssubnetz erstellen.

  • Sie können nur dann ein Nur-Proxy-Sicherungssubnetz in einer Region und in einem Netzwerk erstellen, wenn Sie darin zuvor ein Nur-Proxy-Subnetz angelegt haben.

  • Sie können ein Nur-Proxy-Sicherungssubnetz zu einem aktiven Nur-Proxy-Subnetz hochstufen. In diesem Fall wird von Google Cloud das zuvor aktive Nur-Proxy-Subnetz automatisch zum Nur-Proxy-Sicherungssubnetz herabgestuft. Sie können ein Nur-Proxy-Subnetz nicht explizit als Nur-Proxy-Sicherungssubnetz festlegen.

  • Während des Zeitraums des Verbindungsausgleichs eines Nur-Proxy-Subnetzes (--drain-timeout) können Sie ein Nur-Proxy-Sicherungssubnetz nicht zu einem aktiven Nur-Proxy-Subnetz hochstufen.

  • Von Google Cloud wird keine Warnung ausgegeben, wenn das Nur-Proxy-Subnetz keine IP-Adressen mehr hat. Sie können Monitoring jedoch so konfigurieren, dass die IP-Adressnutzung Ihres Nur-Proxy-Subnetzes überwacht wird. Sie können Benachrichtigungsrichtlinien definieren, um eine Benachrichtigung für den Messwert loadbalancing.googleapis.com/subnet/proxy_only/addresses einzurichten.

  • Nur-Proxy-Subnetze unterstützen keine VPC-Flusslogs.

Nächste Schritte