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 Google Cloud Load-Balancern 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 und Produkte

Für Envoy-basiertes Cloud Load Balancing und Secure Web Proxy-Produkte sind Nur-Proxy-Subnetze erforderlich:

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).

Größe des Nur-Proxy-Subnetzes planen

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 Anzahl der Ihrem Load Balancer 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 verarbeiten,wenn Cloud Logging deaktiviert ist. Wenn Sie Logging aktivieren, kann eine Proxy-Instanz weniger Anfragen pro Sekunde verarbeiten. 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.

Für jeden zusätzlichen Proxy fällt eine zusätzliche Stundengebühr an. Informationen zur Abrechnung von Nur-Proxy-Subnetzen finden Sie in der Dokumentation zu Cloud Load Balancing im Abschnitt Gebühren für Proxy-Instanzen.

Envoy-basierte Load-Balancer und Secure Web Proxy-Envoy-Proxys

Wenn Sie sowohl einen Envoy-basierten Load Balancer als auch Secure Web Proxy in derselben VPC konfigurieren, ist Folgendes zu beachten:

  • Sowohl der Envoy-basierte Load Balancer als auch der Secure Web Proxy verwenden IP-Adressen aus demselben Nur-Proxy-Subnetz.

  • Um die IP-Adressanforderungen für beide Dienste zu erfüllen, sollten Sie ein größeres Nur-Proxy-Subnetz verwenden, z. B. ein /22-Subnetz. So wird sichergestellt, dass für beide Konfigurationen genügend Adressraum vorhanden ist.

  • Wir empfehlen, die Proxykapazität im Blick zu behalten, um den Verbrauch von IP-Adressen nachzuvollziehen. So wird verhindert, dass das Nur-Proxy-Subnetz erschöpft ist, was zu Dienstunterbrechungen führen kann.

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: Regionsü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 -Konsole 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 Traffics zunimmt, müssen Sie möglicherweise Ihr Nur-Proxy-Subnetz vergrößern, um eine größere Anzahl von Envoy-Proxys für Ihre Load Balancer zuzulassen.

Sie können den primären IPv4-Adressbereich eines Nur-Proxy-Subnetzes nicht auf dieselbe Weise erweitern wie den primären IPv4-Adressbereich eines regulären Subnetzes (mit dem Befehl expand-ip-range). Stattdessen müssen Sie das Nur-Proxysubnetz durch ein neues ersetzen. So funktioniert der Ersatzprozess:

  • Erstellen Sie ein neues Nur-Proxy-Subnetz in derselben Region und im selben VPC-Netzwerk wie das vorhandene (originale) Nur-Proxy-Subnetz. Legen Sie beim Erstellen dieses neuen Nur-Proxy-Subnetzes role auf BACKUP fest. Für jeden Zweck eines Nur-Proxy-Subnetzes Google Cloud kann in einer bestimmten Region und einem bestimmten VPC-Netzwerk ein ACTIVE- und ein BACKUP-Nur-Proxy-Subnetz vorhanden sein.

  • Passen Sie die Firewallregeln für zulässigen eingehenden Traffic für Ihre Back-Ends so an, dass Verbindungen von den primären IPv4-Adressbereichen des ursprünglichen und des neuen Nur-Proxy-Subnetzes zugelassen werden.

  • Legen Sie die Rolle des neuen Nur-Proxy-Subnetzes auf ACTIVE fest und geben Sie einen Zeitraum für den Verbindungsausgleich an, damit Verbindungen zwischen Ihren Back-Ends und den Envoy-Proxys im ursprünglichen Nur-Proxy-Subnetz beendet werden können. (Google Cloud legt die Rolle des ursprünglichen Nur-Proxy-Subnetzes automatisch auf BACKUP fest, wenn Sie die Rolle des neuen Nur-Proxy-Subnetzes auf ACTIVE festlegen.)

  • Behalten Sie den Status des ursprünglichen Nur-Proxy-Subnetzes im Blick. Weitere Informationen zum Monitoring finden Sie auf dem Tab „gcloud“. Sobald der Status READY lautet, wird das Subnetz nicht mehr verwendet, sofern seine Rolle BACKUP ist. An diesem Punkt können Sie die Firewallregeln zum Zulassen von eingehendem Traffic so anpassen, dass nur Verbindungen aus dem primären IPv4-Adressbereich des neuen Nur-Proxy-Subnetzes zugelassen werden. Das ursprüngliche Nur-Proxy-Subnetz können Sie löschen.

Console

  1. Erstellen Sie das neue Nur-Proxy-Subnetz in derselben Region und demselben VPC-Netzwerk und geben Sie einen primären IPv4-Adressbereich an, der Ihren Anforderungen entspricht. Legen Sie die Rolle des neuen Nur-Proxy-Subnetzes auf „backup“ fest.

    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: Regionsübergreifender verwalteter Proxy
      • Wählen Sie als Rolle die Option Sicherung aus.
      • Geben Sie einen IP-Adressbereich ein.
      • Klicken Sie auf Hinzufügen.

  2. Aktualisieren Sie die Firewallregeln für zulässigen eingehenden Traffic für Ihre Backend-VMs oder -Endpunkte so, dass sie die primären IPv4-Adressbereiche beider Nur-Proxy-Subnetze (des ursprünglichen und des neuen) enthalten.

  3. Legen Sie die Rolle des neuen Nur-Proxy-Subnetzes auf „aktiv“ fest und geben Sie ein Zeitlimit für den Verbindungsausgleich an, damit Verbindungen zwischen Ihren Back-Ends und dem ursprünglichen Nur-Proxy-Subnetz beendet werden können.Wenn Sie die Rolle des neuen Nur-Proxy-Subnetzes auf „aktiv“ festlegen, wird die Rolle des ursprünglichen Nur-Proxy-Subnetzes automatisch auf „zur Datensicherung“ gesetzt. Google Cloud

    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 ursprünglichen Nur-Proxy-Subnetz stammen, haben Sie folgende Möglichkeiten:

    • Aktualisieren Sie die Firewallregeln für zulässigen eingehenden Traffic für Ihre Backend-VMs oder -Endpunkte so, dass diese nur den primären IPv4-Adressbereich des neuen Nur-Proxy-Subnetzes enthalten.
    • Löschen Sie das ursprüngliche Nur-Proxy-Subnetz.

gcloud

In den folgenden Schritten wird gezeigt, wie Sie ein vorhandenes Nur-Proxy-Subnetz durch ein neues Nur-Proxy-Subnetz ersetzen. In allen folgenden Schritten:

  • ORIGINAL_PROXY_ONLY_SUBNET_NAME: der Name des vorhandenen Nur-Proxy-Subnetzes
  • ORIGINAL_PROXY_ONLY_SUBNET_RANGE: Der primäre IPv4-Adressbereich des vorhandenen Proxy-only-Subnetzes im CIDR-Format. Das ist ein Adressbereich, den Sie zuvor ausgewählt haben.
  • NEW_PROXY_ONLY_SUBNET_NAME: der Name des neuen Nur-Proxy-Subnetzes
  • NEW_PROXY_ONLY_SUBNET_RANGE: der primäre IPv4-Adressbereich des neuen Nur-Proxy-Subnetzes im CIDR-Format. Wählen Sie einen IPv4-Adressbereich aus, der Ihren Anforderungen entspricht.
  • PROXY_ONLY_SUBNET_FIREWALL_RULE: der Name einer VPC-Firewallregel zum Zulassen von eingehendem Traffic, die Verbindungen von Nur-Proxy-Subnetzen zulässt.
  • REGION: die Region, die das ursprüngliche und das neue Nur-Proxy-Subnetz enthält
  • VPC_NETWORK_NAME: der VPC-Netzwerkname des Netzwerks, das das ursprüngliche und das neue Nur-Proxy-Subnetz enthält

  1. Erstellen Sie mit dem Befehl gcloud compute networks subnets create mit dem Flag --role=BACKUP ein neues Nur-Proxysubnetz in derselben Region und demselben VPC-Netzwerk.

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

    Ersetzen Sie Folgendes:

    • SUBNET_PURPOSE: Entweder REGIONAL_MANAGED_PROXY oder GLOBAL_MANAGED_PROXY, je nach Load Balancer, der das Nur-Proxy-Subnetz verwenden muss. Weitere Informationen finden Sie unter Unterstützte Load-Balancer.

  2. Aktualisieren Sie die Firewallregeln für zulässigen eingehenden Traffic für Ihre Backend-VMs oder -Endpunkte so, dass sie die primären IPv4-Adressbereiche beider Nur-Proxy-Subnetze (des ursprünglichen und des neuen) enthalten.

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges=ORIGINAL_PROXY_ONLY_SUBNET_RANGE,NEW_PROXY_ONLY_SUBNET_RANGE

  3. Legen Sie die Rolle des neuen Nur-Proxy-Subnetzes auf ACTIVE fest und geben Sie ein Zeitlimit für den Verbindungsausgleich (--drain-timeout) an, damit Verbindungen zwischen Ihren Back-Ends und dem ursprünglichen Nur-Proxy-Subnetz beendet werden können. Wenn Sie die Rolle des neuen Nur-Proxy-Subnetzes auf ACTIVE festlegen, wird die Rolle des ursprünglichen Nur-Proxy-Subnetzes automatisch auf BACKUP gesetzt.Google Cloud

    Wenn Sie die Verbindungen zwischen Ihren Back-Ends und Envoy-Proxys im ursprünglichen Nur-Proxy-Subnetz sofort trennen möchten, legen Sie --drain-timeout auf 0s fest.

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

    Ersetzen Sie Folgendes:

    • CONNECTION_DRAINING_TIMEOUT: die Zeit in Sekunden, die vorhandenen Verbindungen zwischen Ihren Back-Ends und Envoy-Proxys im ursprünglichen Nur-Proxy-Subnetz zum Beenden zur Verfügung steht.

  4. Überwachen Sie den Status des ursprünglichen Nur-Proxy-Subnetzes mit dem Befehl gcloud compute networks subnets describe.

    gcloud compute networks subnets describe ORIGINAL_PROXY_ONLY_SUBNET_NAME \
   --region=REGION

    Warten Sie, bis der Verbindungsausgleich abgeschlossen ist. Während des Verbindungsausgleichs hat das ursprüngliche Nur-Proxy-Subnetz den Status DRAINING. Möglicherweise müssen Sie den Befehl describe einige Male ausführen, bevor sich der Status des ursprünglichen Nur-Proxy-Subnetzes in READY ändert.

  5. Nachdem das ursprüngliche Nur-Proxy-Subnetz READY mit der Rolle BACKUP ist, wird das Subnetz nicht mehr verwendet. Aktualisieren Sie die Firewallregeln für zulässigen eingehenden Traffic für Ihre Backend-VMs oder -Endpunkte so, dass sie nur den primären IPv4-Adressbereich des neuen Nur-Proxy-Subnetzes enthalten.

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges=NEW_PROXY_ONLY_SUBNET_RANGE

  6. Löschen Sie das ursprüngliche Nur-Proxy-Subnetz.

    gcloud compute networks subnets delete ORIGINAL_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 führt zu keiner Ausfallzeit. Die Änderung wird normalerweise umgehend wirksam.

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. Google Cloud 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.

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

Nächste Schritte