Nur-Proxy-Subnetze für regionale externe HTTP(S)-Load-Balancer

Auf dieser Seite wird gezeigt, wie Sie Nur-Proxy-Subnetze für regionale Load-Balancer verwenden.

Eine allgemeine Übersicht über regionale externe HTTP(S)-Load-Balancer finden Sie unter HTTP(S)-Load-Balancing – Übersicht.

Ein Nur-Proxy-Subnetz ist ausschließlich für Proxys regionaler Load-Balancer reserviert. Es kann nicht für andere Zwecke verwendet werden. Für jedes VPC-Netzwerk in jeder Region kann jeweils nur ein Nur-Proxy-Subnetz aktiv sein.

Sie müssen ein Nur-Proxy-Subnetz erstellen, bevor Sie Weiterleitungsregeln für Ihre Load-Balancer erstellen. Jede Region eines VPC-Netzwerks, in dem Sie regionale Load-Balancer verwenden, muss ein Nur-Proxy-Subnetz haben.

Der regionale Load-Balancer stellt einen Pool von Proxys für Ihr Netzwerk bereit. Die Proxys bestimmen anhand der URL-Zuordnung, der Sitzungsaffinität des Back-End-Dienstes, des Load-Balancing-Modus jeder Back-End-Instanzgruppe, der Netzwerk-Endpunktgruppe und anderer Faktoren, wohin eine HTTP(S)-Anfrage gesendet wird.

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

  2. Einer der Proxys empfängt und beendet die Netzwerkverbindung des Clients.

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

Jedem Proxy des Load-Balancers wird eine interne IP-Adresse zugewiesen. Die Proxys für alle regionalen Load-Balancer in einer Region verwenden interne IP-Adressen aus einem einzelnen Nur-Proxy-Subnetz in dieser Region Ihres VPC-Netzwerks. Ein Nur-Proxy-Subnetz muss mindestens 64 IP-Adressen bereitstellen. Das entspricht einer Präfixlänge von maximal /26.

Nur die Proxys, die von Google Cloud für die regionalen Load-Balancer einer Region erstellt wurden, verwenden das Nur-Proxy-Subnetz. Die IP-Adresse für die Weiterleitungsregel des Load-Balancers stammt nicht aus dem Nur-Proxy-Subnetz. Auch die IP-Adressen der Back-End-VMs und -Endpunkte kommen nicht aus dem Nur-Proxy-Subnetz.

Jeder Proxy überwacht die IP-Adresse und den Port, die in der Weiterleitungsregel des entsprechenden Load-Balancers angegeben sind. Jedes Paket, das von einem Proxy an eine Back-End-VM oder einen Back-End-Endpunkt gesendet wird, hat eine Quell-IP-Adresse aus dem Nur-Proxy-Subnetz.

Die Proxyzuweisung erfolgt auf VPC-Ebene, nicht auf der Load-Balancer-Ebene. Das bedeutet, dass mehrere regionale Load-Balancer, die sich in derselben Region und demselben VPC-Netzwerk befinden, Proxys für das Load-Balancing teilen.

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

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

Komponenten des regionalen externen HTTP(S)-Load-Balancers (zum Vergrößern klicken)
Komponenten des regionalen externen HTTP(S)-Load-Balancers (zum Vergrößern klicken)

Wie im Diagramm dargestellt, sind für die Bereitstellung eines regionalen Load-Balancers mindestens zwei Subnetze erforderlich:

  • Die Back-End-VMs und Back-End-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 Back-End-VMs und -Endpunkte mehrere Subnetze verwenden. Die Subnetze müssen sich dazu in derselben Region wie der Load-Balancer befinden.
  • Das Nur-Proxy-Subnetz ist 10.129.0.0/23 (in diesem Beispiel).
  • Nur-Proxy-Subnetz erstellen

    Wenn Sie ein Subnetz für einen regionalen Load-Balancer reservieren möchten, gehen Sie im Prinzip wie beim Erstellen eines Subnetzes vor, verwenden aber einige zusätzliche Flags.

    Sie können ein vorhandenes Subnetz nicht als Nur-Proxy-Subnetz wiederverwenden. In jeder Region, die einen regionalen externen HTTP(S)-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. Beim Nur-Proxy-Subnetz muss --purpose auf REGIONAL_MANAGED_PROXY gesetzt werden.

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

    Sie müssen in jeder Region eines virtuellen Netzwerks (VPC), in dem Sie regionale Load-Balancer verwenden, ein Nur-Proxy-Subnetz anlegen. Dieses Subnetz wird von allen regionalen Load-Balancern in der Region gemeinsam genutzt.

    Nur-Proxy-Subnetze müssen unabhängig davon erstellt werden, ob Ihr Netzwerk im automatischen oder im benutzerdefinierten Modus arbeitet. Als Subnetzgröße wird /23 (512 Nur-Proxy-Adressen) empfohlen. Die Mindestgröße beträgt /26 (64 Nur-Proxy-Adressen).

    Console

    1. Rufen Sie in der 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. Wählen Sie eine Region aus.
    6. Setzen Sie Zweck auf Regional verwalteter Proxy.
    7. Geben Sie einen IP-Adressbereich ein.
    8. Klicken Sie auf Hinzufügen.

    gcloud

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

    gcloud beta compute networks subnets create SUBNET_NAME \
        --purpose=REGIONAL_MANAGED_PROXY \
        --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.
    • 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. Weitere Informationen finden Sie in der Konfiguration von fw-allow-proxies unter Firewallregeln konfigurieren.

    Proxyverfügbarkeit

    Manchmal haben Google Cloud-Regionen nicht genügend Proxykapazität für einen neuen regionalen Load-Balancer. In diesem Fall gibt die 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 Sie die Anzahl der Back-Ends in Ihrer Bereitstellung ändern, müssen Sie möglicherweise die Größe oder den Adressbereich Ihres Nur-Proxy-Subnetzes ändern.

    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 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. Wählen Sie eine Region aus.
      6. Setzen Sie Zweck auf Regional verwalteter Proxy.
      7. Wählen Sie als Rolle die Option Sicherung aus.
      8. Geben Sie einen IP-Adressbereich ein.
      9. Klicken Sie auf Hinzufügen.
    2. Erstellen oder ändern Sie für Ihre Back-End-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 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 Back-End-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 Back-End-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

    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 beta compute networks subnets create BACKUP_PROXY_SUBNET \
         --purpose=REGIONAL_MANAGED_PROXY \
         --role=BACKUP \
         --region=REGION \
         --network=VPC_NETWORK_NAME \
         --range=CIDR_RANGE
      

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

    3. Mit dem folgenden gcloud-Befehl wird ein Nur-Proxy-Sicherungssubnetz zum aktiven Subnetz hochgestuft und das zuvor aktive Nur-Proxy-Subnetz zum Sicherungssubnetz herabgestuft:

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

      Dabei gilt:

      • BACKUP_PROXY_SUBNET: der Name des neu erstellten Nur-Proxy-Sicherungssubnetzes
      • REGION: Region des neu erstellten Nur-Proxy-Sicherungssubnetzs
      • 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. Wenn das Zeitlimit für den Verbindungsausgleich abgelaufen ist oder sichergestellt ist, dass Verbindungen zu Ihren Back-End-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 Back-End-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.

    Konfigurationsbeispiel

    Dieser Abschnitt enthält eine Beispielkonfiguration, die die Schritte zum Ändern des Nur-Proxy-Subnetzes in einer Region zeigt.

    1. Erstellen Sie ein Nur-Proxy-Sicherungssubnetz für die Region.

      gcloud beta compute networks subnets create new-l7xlb-backend-subnet-us-west1 \
         --purpose=REGIONAL_MANAGED_PROXY \
         --role=BACKUP \
         --region=us-west1 \
         --network=default \
         --range=10.130.0.0/23
      

    2. Aktualisieren Sie die Back-End-Firewall, um Verbindungen vom neuen Subnetz zuzulassen.

      gcloud compute firewall-rules update l7-ilb-firewall \
         --source-ranges 10.129.0.0/23,10.130.0.0/23
      
    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.

      gcloud beta compute networks subnets update new-l7xlb-ip-range-us-west1 \
         --drain-timeout 1h --role ACTIVE
      

      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.

    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 Back-End-Firewallregel, um nur Verbindungen aus dem neuen Subnetz zuzulassen.

      gcloud compute firewall-rules update l7-ilb-firewall \
         --source-ranges 10.130.0.0/23
      
    6. Löschen Sie das alte Subnetz.

      gcloud beta compute networks subnets delete l7xlb-ip-range-us-west1 \
         --region us-west1
      

    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.

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

    Nächste Schritte