Übersicht über globalen externen Passthrough-Network Load Balancer

Globale externe Passthrough-Network Load Balancer sind Layer-4-Passthrough-Load Balancer, die externen Traffic auf Back-Ends (Instanzgruppen oder Netzwerk-Endpunktgruppen) verteilen, die sich in mehreren Cloud de Confiance Regionen befinden können. Diese Load Balancer basieren auf Maglevs, die global verteilt sind und über das globale Netzwerk und die Steuerungsebene von Google zusammenarbeiten.

Ein globaler externer Passthrough-Network-Load-Balancer leitet den Traffic automatisch an die Backend-Region weiter, die dem Punkt am nächsten ist, an dem der Nutzer-Traffic in das globale Netzwerk vonS3NSeintritt.

Vorausgesetzt, dass berechtigte Back-Ends in zwei oder mehr Regionen konfiguriert sind:

  • Wenn eine Region ausgelastet ist, leitet der Load-Balancer automatisch einige der neuen Nutzerverbindungen, die die Kapazität der Region überschreiten, an die nächstgelegenen Regionen mit verfügbarer Kapazität weiter. Bestehende Verbindungen bleiben in der aktuellen Region.

  • Wenn eine Region nicht verfügbar ist, leitet der Load-Balancer den Traffic automatisch zur nächstgelegenen Region mit freier Kapazität um.

Globale externe Passthrough-Network Load Balancer können Traffic von folgenden Quellen empfangen:

  • Jedem Client im Internet
  • Cloud de Confiance VMs mit externen IP-Adressen
  • Cloud de Confiance VMs mit Internetzugriff über Cloud NAT oder instanzbasiertes NAT

In folgenden Fällen sollten Sie einen globalen externen Passthrough-Network Load Balancer verwenden:

  • Sie benötigen einen leistungsstarken Pass-Through-Layer-4-Load-Balancer für TCP-, UDP-, ESP-, GRE-, ICMP- und ICMPv6-Traffic. Der Load Balancer kann sowohl IPv4- als auch IPv6-Traffic verarbeiten.

  • Sie müssen die ursprünglichen Pakete ohne Proxy empfangen. Zum Beispiel, wenn die Quell-IP-Adresse des Clients erhalten bleiben soll.

  • Sie müssen Traffic mit geringer Latenz über dieselbe Anycast-IP-Adresse an Back-Ends in mehreren Cloud de Confiance Regionen senden.

  • Ihre Bereitstellung muss gegen regionale Back-End-Fehler und Überlastungen resistent sein und den Traffic automatisch und reibungslos an die nächstgelegene Region mit verfügbarer Kapazität weiterleiten.

Wenn Sie einen globalen externen Passthrough-Network Load Balancer verwenden möchten, muss Ihre Bereitstellung die folgende Anforderung erfüllen:

  • Wenn Sie TLS-Traffic (SSL) bereitstellen, müssen Ihre Back-Ends den SSL-Traffic beenden. Der globale externe Passthrough-Netzwerk-Load-Balancer unterstützt keine SSL-Beendigung.

Wichtige Features

Globale externe Passthrough-Network Load Balancer unterstützen die folgenden wichtigen Funktionen.

Hochverfügbarkeit von Grund auf

Der Load Balancer stellt Ihnen zwei globale externe Anycast-IP-Adressen zur Verfügung, die jeweils von einer disjunkten und isolierten globalen Load-Balancing-Serverinfrastruktur für die Steuerungs- und Datenebene (auch als Verfügbarkeitsgruppe bezeichnet) bereitgestellt werden, um eine Hochverfügbarkeit zu gewährleisten. Clients können entweder die IPv4- oder die IPv6-Adresse verwenden, um eine Verbindung zum nächstgelegenen intakten Back-End mit verfügbarer Kapazität herzustellen.

Mit dem Load Balancer können Sie die Dienstverfügbarkeit verbessern, wenn Sie globale Backend-Dienste mit Backends in mehreren Cloud de Confiance Regionen erstellen. Wenn Back-Ends in einer bestimmten Region ausfallen, wird der Traffic problemlos auf die nächstgelegene Region umgeleitet.

Wir empfehlen, Backends in mindestens drei Cloud de Confiance Regionen bereitzustellen, um die Ausfallsicherheit bei regionalen Ausfällen zu gewährleisten, auch wenn Sie alle Ihre Backends in einer einzelnen Cloud de Confiance Region konfigurieren dürfen.

Latenz- und lastenabhängiges Load-Balancing

Ein globaler externer Passthrough-Network Load Balancer verwendet ausschließlich die Premium-Stufe. Mit der Premium-Stufe wird eingehender Traffic aus dem Internet an dem Point of Presence (PoP), der dem Nutzer am nächsten ist, in das Hochleistungsnetzwerk mit niedriger Latenz von S3NSgeleitet. Ausgehender Traffic wird über das Netzwerk von S3NSgesendet und verlässt das Netzwerk an dem PoP, der dem Nutzer am nächsten liegt.

Die global verteilten Maglev-Load-Balancer leiten eingehenden Traffic an dieCloud de Confiance -Region weiter, die dem PoP am nächsten ist, über den der Traffic in das Netzwerk vonS3NSgelangt, sofern die Region fehlerfreie Back-Ends mit verfügbarer Kapazität hat. Andernfalls leitet der Load-Balancer den Traffic automatisch und reibungslos an die nächstgelegene Region weiter, die über fehlerfreie Back-Ends mit verfügbarer Kapazität verfügt.

Sie legen Backend-Placements und ‑Kapazitäten für optimale Paketlatenz und Backend-Effizienz fest. Die Back-End-Kapazitäten können auf der maximalen eingehenden PPS-Rate (Pakete pro Sekunde), der maximalen CPU-Auslastung oder beidem basieren. Die in einem Backend-Dienst konfigurierten Backend-Kapazitäten werden gleichmäßig auf die IP-Adressen aller Weiterleitungsregeln verteilt, die auf den Backend-Dienst verweisen.

Funktionsweise von globalen externen Passthrough-Network Load Balancern

Ein globaler externer Passthrough-Network Load Balancer hat ein Frontend (die Weiterleitungsregel) und ein Backend (den Backend-Dienst und seine Backend-Gruppen). Sie können entweder Instanzgruppen oder GCE_VM_IP zonale NEGs als Back-End-Gruppen verwenden.

Architektur

Das folgende Diagramm zeigt einen globalen externen Passthrough-Network Load Balancer, der Traffic an Back-Ends in mehreren Cloud de Confiance Regionen verteilt. Wenn der Load-Balancer erstellt wird, weist Cloud de Confiance ihm zwei globale externe Anycast-IP-Adressen zu, die von einer disjunkten und isolierten Infrastruktur für Steuerungsebene und Datenebene (auch als Verfügbarkeitsgruppen, AG0 und AG1, bezeichnet) bereitgestellt werden.

Die beiden Steuerungs- und Datenebenen bieten Hochverfügbarkeit, Fehlertoleranz und Robustheit für jeden globalen externen Passthrough-Netzwerk-Load-Balancer. Ein Fehler in der Steuerungs- oder Datenebene einer Verfügbarkeitsgruppe hat keine Auswirkungen auf die andere Verfügbarkeitsgruppe. Richtig konfigurierte Clients müssen eine Verbindung zu beiden IP-Adressen des Load-Balancers herstellen können. Wenn ein Client beispielsweise keine Verbindung zur AG0-IP-Adresse herstellen kann, muss er so konfiguriert werden, dass er stattdessen eine Verbindung zur AG1-IP-Adresse herstellt.

Ein globaler externer Passthrough-Network Load Balancer leitet Traffic an VM-Instanzgruppen-Back-Ends weiter, die in den Regionen `us-west1` und `europe-west2` bereitgestellt werden.
Architektur eines globalen externen Passthrough-Network Load Balancers (zum Vergrößern klicken).

Der Load-Balancer besteht aus den folgenden Konfigurationskomponenten.

  • Zwei globale externe IP-Adressen, eine aus jeder Verfügbarkeitsgruppe (AG0 und AG1). Sie können statisch oder sitzungsspezifisch sein. Weitere Informationen finden Sie unter IP-Adressen.

  • Eine globale Weiterleitungsregel, in der die beiden globalen externen IP-Adressen angegeben sind, eine aus jeder Verfügbarkeitsgruppe (AG0 und AG1). Wenn Sie diese Weiterleitungsregel erstellen,generiert Cloud de Confiance zwei schreibgeschützte untergeordnete Weiterleitungsregeln, eine für jede Verfügbarkeitsgruppe, um eine hohe Verfügbarkeit zu gewährleisten. Weitere Informationen finden Sie unter Weiterleitungsregeln.

  • Ein globaler Backend-Dienst, der definiert, wie Traffic an die Backends in mehrerenCloud de Confiance Regionen verteilt wird. Die Back-End-Gruppen können entweder alle Instanzgruppen (zonale verwaltete Instanzgruppen oder zonale nicht verwaltete Instanzgruppen) oder alle zonalen NEG-Back-Ends (zonale NEGs mit GCE_VM_IP-Endpunkten) sein. Weitere Informationen finden Sie unter Back-End-Dienste.

  • Globale Systemdiagnose, die dem Backend-Dienst zugeordnet ist. Weitere Informationen finden Sie unter Systemdiagnosen.

  • Firewallregeln, mit denen der Load-Balancing-Traffic und die Systemdiagnoseprüfungen die Back-End-VMs erreichen können. Weitere Informationen finden Sie unter Firewallregeln.

Direkte Serverrückgabe

Ein globaler externer Passthrough-Network Load Balancer ist wie andere Passthrough-Network Load Balancer kein Proxy. Der Load-Balancer selbst beendet Nutzerverbindungen nicht. Pakete mit Load-Balancing werden unverändert an die Backend-VMs mit ihren Quell- und Ziel-IP-Adressen, ihrem Protokoll und gegebenenfalls Ports gesendet. Die Backend-VMs beenden dann Nutzerverbindungen und senden die zurückgegebenen Pakete direkt an die Clients. Die Antworten werden nicht über den Load Balancer zurückgesendet. Dieser Vorgang wird als direkte Serverrückgabe (DSR, Direct Server Return) bezeichnet.

Lokales Routing für die IP-Adresse des Load-Balancers

Wie andere Passthrough-Network Load Balancer führt der globale externe Passthrough-Network Load Balancer kein Quell- oder Ziel-NAT der IP-Adresse oder der Ports aus.

Die Cloud de Confiance Gastumgebung konfiguriert jede Back-End-VM mit den IP-Adressen des Load-Balancers. Ein Eintrag in der lokalen Routingtabelle der VM konfiguriert den Load-Balancing-Netzwerkschnittstellen-Controller (NIC) der Backend-VM so, dass Pakete akzeptiert werden, deren Ziel-IP-Adressen mit den IP-Adressen der einzelnen Weiterleitungsregeln übereinstimmen. Weitere Informationen finden Sie unter Lokale Routingtabelle nach den IP-Adressen des Load-Balancers durchsuchen.

IP-Adressen für Anfrage- und Rückgabepakete

Wenn eine Backend-VM ein Paket mit Load-Balancing von einem Client empfängt, sind die Quelle und das Ziel des Pakets:

  • Quelle: Eine externe IP-Adresse, die dem Client, einer Cloud de Confiance -VM oder einem System im Internet zugeordnet ist.
  • Ziel: eine der IP-Adressen der Weiterleitungsregel des Load-Balancers.
Da es sich beim Load-Balancer um einen Passthrough-Load-Balancer (nicht um einen Proxy) handelt, kommen Pakete an, die eine der IP-Adressen der Weiterleitungsregel des Load-Balancers enthalten.

Obwohl die Gastumgebung automatisch lokale Routen konfiguriert, damit das Betriebssystem der VM Traffic akzeptiert, der für die IP-Adresse des Load-Balancers bestimmt ist, kann das Betriebssystem diese Pakete nicht an Ihre Anwendung weiterleiten, wenn die Anwendung so konfiguriert ist, dass sie nur auf der zugewiesenen internen IP-Adresse der VM lauscht.

Damit das Betriebssystem Pakete an Ihre Anwendung sendet, müssen Sie die Anwendung, die auf Backend-VMs ausgeführt wird, so konfigurieren, dass sie Folgendes tut:

  • IP-Adressen der Weiterleitungsregel des Load-Balancers oder eine beliebige IP-Adresse (0.0.0.0 oder ::) überwachen und sich daran binden
  • Wenn das Protokoll der Weiterleitungsregel des Load-Balancers Ports unterstützt, einen Port (binden) überwachen, der in der Weiterleitungsregel des Load-Balancers enthalten ist

Rückgabepakete werden direkt von den Back-End-VMs des Load-Balancers an den Client gesendet. Die Quell-IP-Adresse des Rückgabepakets hängt vom Protokoll ab:

  • TCP ist verbindungsorientiert, sodass Backend-VMs mit Paketen antworten müssen, deren Quell-IP-Adressen mit der Ziel-IP-Adresse des anfragenden Pakets übereinstimmen, damit der Client die Antwortpakete der entsprechenden TCP-Verbindung zuordnen kann.
  • UDP, ESP, GRE, ICMP und ICMPv6 sind verbindungslos. Backend-VMs können Antwortpakete senden, deren Quell-IP-Adressen entweder mit der IP-Adresse der Weiterleitungsregel oder mit einer beliebigen zugewiesenen externen IP-Adresse für die VM übereinstimmen. Im Prinzip erwarten die meisten Clients, dass die Antwort von derselben IP-Adresse kommt, an die sie Pakete gesendet haben.

In der folgenden Tabelle werden die Quell- und Ziel-IP-Adressen für Antwortpakete zusammengefasst:

Traffictyp Quelle Ziel
TCP Das Ziel des anfragenden Pakets Die Quelle des anfragenden Pakets
UDP, ESP, GRE, ICMP und ICMPv6 In den meisten Anwendungsfällen das Ziel des anfragenden Pakets1 Die Quelle des anfragenden Pakets

1 Wenn eine VM eine externe IP-Adresse hat oder wenn Sie Cloud NAT verwenden, ist es auch möglich, die Quell-IP-Adresse des Antwortpakets auf die primäre interne IPv4-Adresse der VM-NIC festzulegen. Cloud de Confiance oder Cloud NAT ändert die Quell-IP-Adresse des Antwortpakets entweder in die externe IPv4-Adresse der NIC oder in eine externe Cloud NAT-IPv4-Adresse, um das Antwortpaket an die externe IP-Adresse des Clients zu senden. Nicht die IP-Adresse der Weiterleitungsregel als Quelle zu verwenden, ist ein erweitertes Szenario, da der Client ein Antwortpaket von einer externen IP-Adresse empfängt, die nicht mit der IP-Adresse übereinstimmt, an die ein Anfragepaket gesendet wurde.

Komponenten

In den folgenden Abschnitten wird jede Konfigurationskomponente eines globalen externen Passthrough-Network-Load Balancers im Detail beschrieben.

IP-Adressen

Für einen globalen externen Passthrough-Network Load Balancer sind zwei globale externe IP-Adressen erforderlich, um Hochverfügbarkeit zu gewährleisten. Die Weiterleitungsregeln des Load-Balancers verwenden diese Adressen, um eingehenden Traffic zu akzeptieren. Sie müssen zur selben IP-Version gehören, also IPv4 oder IPv6. Cloud de Confiance bewirbt die IP-Adressen Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-IP-Adresse, die nur in der Premium-Stufe unterstützt wird.

Jede der beiden IP-Adressen muss aus globalen externen IP-Adresspools stammen, die zu einer separaten Verfügbarkeitsgruppe gehören. Die IP-Adressen sind keinem Subnetz in einem VPC-Netzwerk zugeordnet. In der API werden die Verfügbarkeitsgruppen mit dem Feld purpose in der Ressource globalAddresses dargestellt:

  • PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP0: für Adressen der Verfügbarkeitsgruppe 0.
  • PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP1: für Adressen der Verfügbarkeitsgruppe 1.

Im Feld IPAddresses einer Weiterleitungsregelressource werden null, eine oder zwei IP-Adressen angegeben:

  • Wenn Sie das Feld weglassen,werden von Cloud de Confiance zwei sitzungsspezifische IP-Adressen zugewiesen, eine aus jeder Verfügbarkeitsgruppe.
  • Wenn Sie eine IP-Adresse angeben, die auf eine vorhandene statische IP-Adressressource aus einer Verfügbarkeitsgruppe verweist, weist Cloud de Confiance eine temporäre IP-Adresse aus der anderen Verfügbarkeitsgruppe zu.
  • Wenn Sie zwei IP-Adressen angeben, die auf vorhandene statische IP-Adressressourcen verweisen, müssen sie aus verschiedenen Verfügbarkeitsgruppen stammen.

Verwenden Sie reservierte statische IP-Adressen für die Weiterleitungsregel, wenn Sie die Adressen, die Ihrem Projekt zugeordnet sind, wiederverwenden möchten, nachdem Sie eine Weiterleitungsregel gelöscht haben, oder wenn mehrere Weiterleitungsregeln auf dieselben IP-Adressen verweisen sollen.

Für eine Weiterleitungsregel für globale externe Passthrough-Network Load Balancer können die IP-Adressen eine der folgenden sein:

  • Eine statische oder sitzungsspezifische IPv4-Adresse aus einem globalen IP-Adresspool von Google.
  • Ein statischer oder sitzungsspezifischer /96-Bereich externer IPv6-Adressen aus einem globalen IP-Adresspool von Google.
  • Eine statische IPv4-BYOIP-Adresse aus einem globalen öffentlich delegierten Präfix.

Ein globaler externer Passthrough-Network Load Balancer unterstützt BYOIP (Bring your own IP addresses) nur für IPv4-Adressen. Der Support ist auf die BYOIP API v1 beschränkt. Die Bereitstellung neuer IPv4-Bereiche kann bis zu vier Wochen dauern. Es gibt keine APIs, mit denen Sie den Status Ihrer BGP-Ankündigung steuern können. Weitere Informationen finden Sie unter BYOIP-Konfigurationen.

Das Feld IPAddresses einer Weiterleitungsregel kann nur beim Erstellen festgelegt und nicht aktualisiert werden.

Unabhängig von ihrem Ursprung (Google-eigene oder BYOIP-Adressen) stammen die globalen externen IP-Adressen in Cloud de Confiance aus drei verschiedenen Arten von globalen externen IP-Adresspools:

  • Von globalen externen Passthrough-Network Load Balancern verwendete IP-Adresspools für die Verfügbarkeitsgruppe AG0
  • Von globalen externen Passthrough-Network Load Balancern verwendete IP-Adresspools für die Verfügbarkeitsgruppe AG1
  • Von globalen externen proxybasierten Load-Balancern verwendete IP-Adresspools

Daher können globale externe Passthrough-Network Load Balancer keine IP-Adressen mit anderen globalen oder regionalen Load Balancern gemeinsam nutzen.

Globale Weiterleitungsregeln

Eine globale externe Passthrough-Network Load Balancer-Weiterleitungsregel bildet das Frontend des Load-Balancers und gibt die Ziel-IP-Adressen, das Protokoll und die Ports an, über die der Load-Balancer Traffic annimmt. Da es sich bei einem globalen externen Passthrough-Netzwerk-Load-Balancer nicht um einen Proxy handelt, leitet er Traffic an Back-Ends weiter, ohne die Quell- und Ziel-IP-Adressen, das Protokoll und die Ports zu ändern, sofern das Protokoll Portinformationen enthält.

Eine globale Weiterleitungsregel für externe Passthrough-Network Load Balancer, die Sie konfigurieren, gibt Folgendes an:

  • Das Load-Balancing-Schema ist als EXTERNAL_PASSTHROUGH festgelegt.
  • Das Paar globaler IP-Adressen im Feld IPAddresses[], eine aus jeder Verfügbarkeitsgruppe.
  • Das Protokoll (TCP, UDP oder L3_DEFAULT) und die Ports.

Für jede globale externe Passthrough-Weiterleitungsregel für Network Load Balancer, die Sie erstellen (auch als übergeordnete Weiterleitungsregel bezeichnet), generiert Cloud de Confiancezwei schreibgeschützte untergeordnete Weiterleitungsregeln für jeden Load-Balancing-Stack: AVAILABILITY_GROUP0 und AVAILABILITY_GROUP1. Die untergeordnete Weiterleitungsregel hat dieselben Einstellungen für IP-Protokoll, Port und Backend-Dienst wie die übergeordnete Weiterleitungsregel, aber nur eine der beiden IP-Adressen der übergeordneten Weiterleitungsregel.

Die untergeordneten Weiterleitungsregeln können eindeutig identifiziert werden, da dem Namen der übergeordneten Weiterleitungsregel -ag0 und -ag1 angehängt werden. Sie verbrauchen kein zusätzliches Kontingent und verursachen keine zusätzlichen Kosten. Monitoring-Messwerte und der Integritätsstatus werden auf Ebene der untergeordneten Weiterleitungsregel gemeldet.

Eingehender Traffic wird einer Weiterleitungsregel zugeordnet, indem die Ziel-IP-Adresse, das Protokoll und der Port eines Pakets mit einer Kombination aus Weiterleitungsregelfeldern abgeglichen werden: zwei IP-Adressen, Protokoll und, bei einem portbasierten Protokoll, einem oder mehreren Ports, einem Portbereich oder allen Ports. Die Weiterleitungsregel leitet dann den Traffic an den Backend-Dienst des Load-Balancers weiter.

Weiterleitungsregeln für einen globalen externen Passthrough-Network Load Balancer können mit IPv4- oder IPv6-Adressen konfiguriert werden. Wenn der Load-Balancer sowohl IPv4- als auch IPv6-Traffic verarbeiten soll, erstellen Sie zwei Weiterleitungsregeln:

  • Eine Weiterleitungsregel für IPv4-Traffic, die auf reine IPv4- oder Dual-Stack-Backends verweist

  • Eine Weiterleitungsregel für IPv6-Traffic, die auf Nur-IPv6- oder Dual-Stack-Back-Ends verweist

Es ist möglich, dass eine IPv4- und eine IPv6-Weiterleitungsregel auf denselben Backend-Dienst verweisen. Der Backend-Dienst muss jedoch auf Backends mit Dual-Stack-VM-Netzwerkschnittstellen verweisen.

Die IP-Version Ihrer Weiterleitungsregel muss mit dem Stacktyp der Netzwerkschnittstellen der Backend-VM übereinstimmen.

Stacktyp der Netzwerkschnittstellen der Backend-VM Weiterleitungsregel
Nur IPv4-VM-Netzwerkschnittstelle (IPV4_ONLY) Kann nur für IPv4-Weiterleitungsregeln verwendet werden.
Nur IPv6-VM-Netzwerkschnittstelle (IPV6_ONLY) Kann nur für IPv6-Weiterleitungsregeln verwendet werden.
Dual-Stack-VM-Netzwerkschnittstelle (IPV4_IPV6) Kann als Back-End für IPv4-Weiterleitungsregeln, IPv6-Weiterleitungsregeln oder beides verwendet werden.

Weiterleitungsregelprotokolle

Globale externe Passthrough-Network Load Balancer unterstützen die folgenden Protokolloptionen für jede Weiterleitungsregel: TCP, UDP und L3_DEFAULT.

Verwenden Sie die Optionen TCP und UDP, um das TCP- bzw. UDP-Load-Balancing zu konfigurieren. Mit der Protokolloption L3_DEFAULT kann ein globaler externer Passthrough-Network Load Balancer TCP-, UDP-, ESP-, GRE-, ICMP- und ICMPv6-Traffic verteilen.

Neben der Unterstützung anderer Protokolle als TCP und UDP ermöglicht L3_DEFAULT auch die Bereitstellung mehrerer Protokolle mit einer einzelnen Weiterleitungsregel. Beispielsweise verarbeiten IPsec-Dienste in der Regel eine Kombination aus ESP- und UDP-basiertem IKE- und NAT-T-Traffic. Mit der Option L3_DEFAULT kann eine einzelne Weiterleitungsregel konfiguriert werden, um alle diese Protokolle zu verarbeiten.

Wenn Sie das Protokoll L3_DEFAULT verwenden, müssen Sie die Weiterleitungsregel so konfigurieren, dass Traffic an allen Ports akzeptiert wird. Da L3_DEFAULT eine Auffangregel ist, sollten Sie als bewährte Sicherheitsmethode Firewallregeln zum Zulassen von eingehendem Traffic konfigurieren, die nur die von Ihnen benötigten IP-Protokolle und -Ports zulassen.

Mehrere Weiterleitungsregeln

Sie können mehrere Weiterleitungsregeln konfigurieren. Es gibt zwei Arten von Weiterleitungsregeln:

  • Mehrere Weiterleitungsregeln für dieselben IP-Adressen: Sie können mehrere Weiterleitungsregeln für dasselbe IP-Adressenpaar konfigurieren, solange nicht zwei Weiterleitungsregeln dieselben Protokoll- und Portkombinationen verwenden. Jede Weiterleitungsregel kann einen anderen Backend-Dienst haben. Es können aber auch mehrere Weiterleitungsregeln auf denselben Backend-Dienst verweisen.

  • Mehrere Weiterleitungsregeln, die auf denselben Backend-Dienst verweisen: Sie können mehrere Weiterleitungsregeln konfigurieren, die auf denselben Back-End-Dienst verweisen. Vorbehaltlich der im ersten Punkt genannten Bedingungen können zwei oder mehr Weiterleitungsregeln dasselbe IP-Adressenpaar verwenden oder jede Weiterleitungsregel kann ein eindeutiges IP-Adressenpaar verwenden. Der Traffic für alle IP-Adressen aller Weiterleitungsregeln, die auf denselben Backend-Dienst verweisen, teilt sich die Kapazitäten des Back-End-Ziels fair.

Sie können jedoch nicht dieselbe globale externe IP-Adresse für einen globalen externen Passthrough-Network Load Balancer und einen globalen externen Application Load Balancer oder einen globalen externen Proxy-Network Load Balancer verwenden.

Wenn Sie mehrere Weiterleitungsregeln verwenden, sollten Sie die auf Ihren Back-End-VMs ausgeführte Anwendung so konfigurieren, dass sie an alle externen IP-Adressen der Weiterleitungsregeln des Load-Balancers gebunden wird.

Das Konfigurieren mehrerer Weiterleitungsregeln kann für die folgenden Anwendungsfälle nützlich sein:

  • Sie müssen mehr als ein Paar externer IP-Adressen für denselben Backend-Dienst konfigurieren. Beispiel: Eine Weiterleitungsregel für IPv4-Adressen und eine weitere für IPv6-Adressen.
  • Sie müssen mehrere Weiterleitungsregeln für dasselbe externe IP-Adressenpaar, aber mit unterschiedlichen Protokollen oder nicht überlappenden Ports oder Portbereichen konfigurieren. Die Weiterleitungsregeln können denselben oder unterschiedliche Back-End-Dienste verwenden.

Protokoll- und Porteinschränkungen für mehrere Weiterleitungsregeln

Cloud de Confiance wählt höchstens eine Weiterleitungsregel aus, um ein eingehendes Paket zu verarbeiten. Zwei oder mehr Weiterleitungsregeln, die dasselbe globale externe IP-Adressenpaar verwenden, müssen gemäß diesen Einschränkungen eindeutige Protokoll- und Portkombinationen haben:

  • Eine Weiterleitungsregel, die für alle Ports eines Protokolls konfiguriert ist, verhindert die Erstellung anderer Weiterleitungsregeln mit demselben Protokoll und derselben IP-Adresse.

    Weiterleitungsregeln, die TCP- oder UDP-Protokolle verwenden, können so konfiguriert werden, dass sie alle Ports verwenden, oder sie können für bestimmte Ports konfiguriert werden.

    Wenn Sie beispielsweise eine Weiterleitungsregel mit dem IP-Adressenpaar 136.124.69.214 und 136.124.83.205, dem TCP-Protokoll und allen Ports erstellen, können Sie keine andere Weiterleitungsregel mit demselben IP-Adressenpaar und dem TCP-Protokoll erstellen.

    Sie können zwei Weiterleitungsregeln erstellen, die beide das IP-Adressenpaar und das Protokoll TCP verwenden, wenn jede eindeutige Ports oder nicht überlappende Portbereiche hat. Sie können beispielsweise zwei Weiterleitungsregeln mit demselben IP-Adressenpaar und dem TCP-Protokoll erstellen, wobei die Ports einer Weiterleitungsregel 80,443 und die andere den Portbereich 81-442 verwendet.

  • Pro IP-Adressenpaar kann nur eine L3_DEFAULT-Weiterleitungsregel erstellt werden.

    Dies liegt daran, dass das L3_DEFAULT-Protokoll alle Ports per Definition verwendet. In diesem Kontext umfasst der Begriff „alle Ports“ Protokolle ohne Portinformationen.

  • Eine einzelne L3_DEFAULT-Weiterleitungsregel kann neben anderen Weiterleitungsregeln bestehen, die bestimmte Protokolle (TCP oder UDP) und dasselbe IP-Adressenpaar verwenden.

    Wenn Sie bestimmte TCP- oder UDP-Weiterleitungsregeln an ein IP-Adressenpaar angehängt haben, können Sie auch eine L3_DEFAULT-Weiterleitungsregel an dasselbe IP-Adressenpaar anhängen, um als Fallback für Traffic zu dienen, der nicht mit den spezifischen Weiterleitungsregeln übereinstimmt. Eine L3_DEFAULT-Weiterleitungsregel verarbeitet Pakete, die an ihre Ziel-IP-Adresse gesendet werden, nur dann, wenn die Ziel-IP-Adresse, das Protokoll und der Zielport des Pakets nicht mit einer protokollspezifischen Weiterleitungsregel übereinstimmen.

    Betrachten Sie zur Veranschaulichung diese beiden Szenarien. Weiterleitungsregeln in beiden Szenarien verwenden dasselbe IP-Adresspaar: 136.124.69.214 und 136.124.83.205.

    • Szenario 1 Die erste Weiterleitungsregel verwendet das Protokoll L3_DEFAULT. Die zweite Weiterleitungsregel verwendet das Protokoll TCP und alle Ports. TCP-Pakete, die an einen beliebigen Zielport einer der beiden IP-Adressen gesendet werden, werden von der zweiten, spezifischeren Weiterleitungsregel verarbeitet. Pakete mit verschiedenen Protokollen werden von der ersten Weiterleitungsregel verarbeitet.

    • Szenario 2 Die erste Weiterleitungsregel verwendet das Protokoll L3_DEFAULT. Die zweite Weiterleitungsregel verwendet das Protokoll TCP und den Port 8080. TCP-Pakete, die an Port 8080 einer der beiden IP-Adressen gesendet werden, werden von der zweiten Weiterleitungsregel verarbeitet. Alle anderen Pakete, einschließlich TCP-Paketen, die an unterschiedliche Zielports gesendet werden, werden von der ersten Weiterleitungsregel verarbeitet.

Auswahl von Weiterleitungsregeln

Cloud de Confiance wählt eine oder null Weiterleitungsregeln aus, um ein eingehendes Paket mithilfe dieses Eliminierungsprozesses zu verarbeiten, beginnend mit der Reihe von Weiterleitungsregelkandidaten, die der Ziel-IP-Adresse des Pakets entsprechen:

  • Entfernen Sie Weiterleitungsregeln, deren Protokoll nicht mit dem Protokoll des Pakets übereinstimmt, mit Ausnahme von L3_DEFAULT-Weiterleitungsregeln. Weiterleitungsregeln, die das Protokoll L3_DEFAULT verwenden, werden bei diesem Schritt nie gelöscht, da L3_DEFAULT mit allen Protokollen übereinstimmt. Wenn das Protokoll des Pakets beispielsweise TCP ist, werden nur Weiterleitungsregeln entfernt, die das Protokoll UDP verwenden.

  • Entfernen Sie Weiterleitungsregeln, deren Port nicht mit dem Port des Pakets übereinstimmt. Die für alle Ports konfigurierten Weiterleitungsregeln werden bei diesem Schritt nie gelöscht, da eine Weiterleitungsregel für alle Ports mit jedem Port übereinstimmt.

  • An dieser Stelle fallen die verbleibenden Kandidaten für Weiterleitungsregeln in eine der folgenden Kategorien:

    • Es bleiben zwei Weiterleitungsregeln übrig: eine L3_DEFAULT-Weiterleitungsregel und eine protokollspezifische Weiterleitungsregel. Verwenden Sie die protokollspezifische Weiterleitungsregel, um das Paket weiterzuleiten.

    • Es bleibt eine einzelne Weiterleitungsregel übrig, entweder eine L3_DEFAULT-Weiterleitungsregel oder eine protokollspezifische Weiterleitungsregel. Sie wird verwendet, um das Paket weiterzuleiten.

    • Null Kandidaten für die Weiterleitungsregel bleiben bestehen und das Paket wird verworfen.

Globale Back-End-Dienste

Ein Backend-Dienst eines globalen externen Passthrough-Network Load Balancers verteilt eingehenden Traffic auf angehängte Backends, die sich in mehreren Cloud de Confiance Regionen befinden können. Jedes Backend besteht aus einer Instanzgruppe oder einer Netzwerk-Endpunktgruppe und Informationen zur Bereitstellungskapazität des Backends. Die Bereitstellungskapazität für das Back-End kann auf der CPU-Auslastung, eingehenden Paketen pro Sekunde (PPS) oder beidem basieren. Der Back-End-Dienst verwaltet die Traffic-Verteilung gemäß den konfigurierten Affinitäts- und Kapazitätseinstellungen.

Der Backend-Dienst definiert die folgenden Backend-Parameter:

  • Load-Balancing-Schema: Wenn Sie einen Backend-Dienst für einen globalen externen Passthrough-Network-Load-Balancer festlegen möchten, muss das Load-Balancing-Schema explizit auf EXTERNAL_PASSTHROUGH festgelegt werden.

  • Protokoll Das Protokollfeld des Backend-Dienstes ist redundant und kann nur auf UNSPECIFIED gesetzt werden. Back-End-Dienste mit dem Protokoll UNSPECIFIED können unabhängig vom Weiterleitungsregelprotokoll mit jeder Weiterleitungsregel verwendet werden.

  • Verteilung des Traffics. Ein Backend-Dienst verteilt den Traffic gemäß der konfigurierten Sitzungsaffinität, der Richtlinie für das Verbindungs-Tracking, dem Load-Balancing-Modus, den Backend-Kapazitäten und der Load-Balancing-Richtlinie für den Ort. Der Back-End-Dienst kann auch so konfiguriert werden, dass der Verbindungsausgleich aktiviert, die Back-End-Kapazitäten reduziert und bevorzugte Back-Ends festgelegt werden. Die meisten dieser Einstellungen haben Standardwerte, die einen schnellen Einstieg ermöglichen.

  • Systemdiagnose. Ein Backend-Dienst muss eine zugehörige Systemdiagnose haben.

  • Backends Back-Ends sind die tatsächlichen Endpunkte, die Traffic mit Load Balancing empfangen. Ein globaler externer Passthrough-Network Load Balancer kann Traffic an Instanzgruppen oder zonale NEGs verteilen, die sich in mehreren Cloud de Confiance Regionen befinden:

    • Wenn Sie Instanzgruppen auswählen, können Sie zonal verwaltete Instanzgruppen, zonal nicht verwaltete Instanzgruppen oder eine Kombination der Instanzgruppentypen verwenden. Instanzgruppen unterstützen sowohl RATE als auch UTILIZATION als Load-Balancing-Modus.

    • Wenn Sie zonale NEGs verwenden, müssen Sie zonale GCE_VM_IP-NEGs verwenden. NEGs unterstützen nur RATE als Load-Balancing-Modus.

Kompatibilität von VM-Netzwerkschnittstellen mit Weiterleitungsregeln

Da globale externe Passthrough-Network Load Balancer den Traffic nicht beenden oder übersetzen, muss der Stacktyp der Netzwerkschnittstelle der Backend-VM mit der IP-Adressversion der Weiterleitungsregel kompatibel sein.

Weiterleitungsregel Stacktyp der Netzwerkschnittstellen der Backend-VM
Nur IPv4-Weiterleitungsregeln Nur IPv4 (IPV4_ONLY) oder Dual-Stack (IPV4_IPv6)
Nur IPv6-Weiterleitungsregeln Nur IPv6 (IPV6_ONLY) oder Dual-Stack (IPV4_IPv6)
IPv4- und IPv6-Weiterleitungsregeln Dual-Stack (IPV4_IPv6)

Kompatibilität der Netzwerkschnittstelle der Back-End-VM mit VPC-Subnetzen

Wie in der vorherigen Tabelle gezeigt, können Sie einen globalen externen Passthrough-Network Load Balancer so konfigurieren, dass er Backends mit reinen IPv4-Schnittstellen, Dual-Stack-Schnittstellen und reinen IPv6-Schnittstellen hat. In der folgenden Tabelle wird zusammengefasst, welche Netzwerk-Schnittstellentypen von Backend-VMs mit den einzelnen VPC-Subnetz-Stacktypen kompatibel sind.

Stacktyp von VPC-Subnetzen Stacktyp der Netzwerkschnittstelle der Back-End-VM
IPV4_ONLY (Single-Stack)
Nur IPv4-Subnetzbereiche		 Nur IPv4 (IPV4_ONLY)
IPV4_IPV6 (Dual-Stack)
IPv4- und IPv6-Subnetzbereiche		 Nur IPv4 (IPV4_ONLY), Dual-Stack (IPV4_IPv6) und nur IPv6 (IPV6_ONLY)
IPV6_ONLY (Single-Stack)
Nur IPv6-Subnetzbereiche		 Nur IPv6 (IPV6_ONLY)

Wichtige Hinweise:

  • Die einer VM-Netzwerkschnittstelle zugewiesene IP-Adresse wird direkt aus dem zugrunde liegenden VPC-Subnetz zugewiesen.

  • Für die IPv6-Konnektivität weist Cloud de Confiance der VM-Netzwerkschnittstelle einen /96-Adressbereich aus der ersten Hälfte (/65) des externen IPv6-Adressbereichs /64 des Subnetzes zu, wenn eine VM-Netzwerkschnittstelle einem IPv6-fähigen /64-Subnetz zugewiesen wird. Weitere Informationen finden Sie unter Externe IPv6-Spezifikationen.

  • Wenn der Stack-Typ der VM-Netzwerkschnittstelle Dual-Stack (IPV4_IPv6) oder nur IPv6 (IPV6_ONLY) ist, müssen Sie festlegen, wie die IPv6-Adresse der VM-Netzwerkschnittstelle erreicht werden kann. Dazu konfigurieren Sie die Einstellung --ipv6-access-type im VPC-Subnetz auf EXTERNAL oder INTERNAL. Wenn --ipv6-access-type des Subnetzes auf EXTERNAL gesetzt ist, müssen Sie auch --ipv6-network-tier der Netzwerkschnittstelle der VM auf PREMIUM setzen. Weitere Informationen finden Sie unter IPv6-Subnetzbereiche.

Instanzgruppen-Back-Ends und Netzwerkschnittstellen

Innerhalb einer bestimmten (verwalteten oder nicht verwalteten) Instanzgruppe befindet sich die nic0-Netzwerkschnittstelle jeder Mitglieds-VM immer im selben VPC-Netzwerk:

  • Bei verwalteten Instanzgruppen stammt das VPC-Netzwerk der Instanzgruppe von der in der Instanzvorlage definierten Schnittstelle nic0.
  • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk der Instanzgruppe auf das VPC-Netzwerk festgelegt, das von der Netzwerkschnittstelle nic0 der ersten VM-Instanz verwendet wird, die Sie der nicht verwalteten Instanzgruppe hinzufügen. Sie können das VPC-Netzwerk der Instanzgruppe später nicht mehr ändern, auch wenn Sie die erste Instanz, die Sie der Gruppe hinzugefügt haben, entfernen.

Mitglieds-VMs können zusätzliche Netzwerkschnittstellen (vNICs oder dynamische Netzwerkschnittstellen) haben. Jede Nicht-nic0-Schnittstelle kann sich entweder im VPC-Netzwerk der Instanzgruppe (dem Netzwerk, das von der nic0-Schnittstelle verwendet wird) oder in einem anderen VPC-Netzwerk befinden.

Wenn Sie Load-Balancing-Traffic an eine Nicht-nic0-Netzwerkschnittstelle verteilen möchten, können Sie keine Instanzgruppen-Back-Ends verwenden. Verwenden Sie stattdessen zonale NEGs mit GCE_VM_IP-Endpunkten. Weitere Informationen finden Sie unter Backend-Dienste und VPC-Netzwerke.

Zonale NEG-Back-Ends und Netzwerkschnittstellen

Wenn Sie eine neue zonale NEG mit GCE_VM_IP-Endpunkten erstellen, müssen Sie die NEG explizit mit einem Subnetzwerk eines VPC-Netzwerks verknüpfen, bevor Sie der NEG Endpunkte hinzufügen können. Weder das Subnetz noch das VPC-Netzwerk können nach dem Erstellen der NEG geändert werden.

Innerhalb einer bestimmten NEG stellt jeder GCE_VM_IP-Endpunkt tatsächlich eine Netzwerkschnittstelle dar. Die Netzwerkschnittstelle muss sich in dem Subnetzwerk befinden, das der NEG zugeordnet ist. Aus Sicht einer Compute Engine-Instanz kann die Netzwerkschnittstelle eine beliebige Kennung verwenden. Aus der Perspektive eines Endpunkts in einer NEG wird die Netzwerkschnittstelle anhand ihrer primären internen IPv4-Adresse identifiziert. Weitere Informationen finden Sie unter NEGs mit GCE_VM_IP-Endpunkten.

Es gibt zwei Möglichkeiten, einer NEG einen GCE_VM_IP-Endpunkt hinzuzufügen:

  • Wenn Sie beim Hinzufügen eines Endpunkts nur einen VM-Namen (ohne IP-Adresse) angeben, Cloud de Confiance erfordert, dass die VM eine Netzwerkschnittstelle in dem Subnetzwerk hat, das der NEG zugeordnet ist. Die IP-Adresse, die Cloud de Confiancefür den Endpunkt auswählt, ist die primäre interne IPv4-Adresse der Netzwerkschnittstelle der VM im Subnetzwerk, das der NEG zugeordnet ist.
  • Wenn Sie beim Hinzufügen eines Endpunkts sowohl einen VM-Namen als auch eine IP-Adresse angeben, muss die von Ihnen angegebene IP-Adresse eine primäre interne IPv4-Adresse für eine der Netzwerkschnittstellen der VM sein. Diese Netzwerkschnittstelle muss sich in dem Subnetzwerk befinden, das mit der NEG verknüpft ist. Beachten Sie, dass die Angabe einer IP-Adresse redundant ist, da es nur eine einzige Netzwerkschnittstelle geben kann, die sich im Subnetzwerk befindet, das der NEG zugeordnet ist.

Backend-Dienste und VPC-Netzwerke

Der Backend-Dienst ist keinem VPC-Netzwerk zugeordnet. Jede Backend-Instanzgruppe oder zonale NEG ist jedoch wie bereits erwähnt einem VPC-Netzwerk zugeordnet. Solange sich alle Back-Ends im selben Projekt befinden und alle Back-Ends vom selben Typ (Instanzgruppen oder zonale NEGs) sind, können sich der Load Balancer und seine Back-Ends entweder im selben oder in verschiedenen VPC-Netzwerken befinden.

Wenn Sie Pakete an Nicht-nic0-Schnittstellen verteilen möchten, müssen Sie beide der folgenden Anforderungen erfüllen:

  • Sie müssen zonale NEGs (mit GCE_VM_IP-Endpunkten) und keine Instanzgruppen verwenden.

  • Die Netzwerkschnittstellen für nic0 und nic0 müssen sich in verschiedenen VPC-Netzwerken befinden. Das VPC-Netzwerk der NEG darf nicht die nic0-Schnittstelle und die gewünschte Nicht-nic0-Schnittstelle enthalten.

Bevorzugte Back-Ends

Sie können bestimmte Back-Ends als bevorzugte Back-Ends festlegen. Diese Back-Ends müssen für die Kapazität verwendet werden (d. h. die Zielkapazität, die vom Balancing-Modus des Back-Ends angegeben wird), bevor Anfragen an die verbleibenden Back-Ends gesendet werden.

Der Backend-Dienst eines globalen externen Passthrough-Network Load Balancers kann maximal eine bevorzugte Backend-Gruppe haben und lässt keine bevorzugten und nicht bevorzugten Backends in derselben Cloud de Confiance Region zu.

Weitere Informationen finden Sie unter Erweiterte Load-Balancing-Optimierungen.

Systemdiagnosen

Anhand von Systemdiagnoseinformationen wird bestimmt, welche Back-Ends für neue Verbindungen infrage kommen und ob bestehende Verbindungen auf fehlerhaften Back-Ends bestehen bleiben.

Der Load Balancer sendet Systemdiagnoseprüfungen für jede IP-Adresse der Weiterleitungsregel separat. Daher wird eine globale externe Passthrough-Network Load Balancer-Weiterleitungsregel mit zwei IP-Adressen für jede IP-Adresse geprüft, wodurch sich die Prüffrequenz auf jedem Backend verdoppelt. Weitere Informationen finden Sie unter Mehrere Prüfungen und Häufigkeit.

Typ, Protokoll und Port der Systemdiagnose

Der Backend-Dienst des Load-Balancers muss auf eine globale Systemdiagnose verweisen, wobei ein beliebiges unterstütztes Systemdiagnoseprotokoll und ein beliebiger Port verwendet werden können. Das Protokoll und die Portdetails der Systemdiagnose müssen nicht mit dem Protokoll und den Portinformationen der Weiterleitungsregel übereinstimmen.

Da alle unterstützten Systemdiagnoseprotokolle auf TCP basieren (UDP-Systemdiagnosen werden nicht unterstützt), müssen auf Backend-VMs ein TCP-basierter Server ausgeführt werden, um auf Systemdiagnoseprüfungen zu reagieren, wenn Sie einen globalen externen Passthrough-Network Load Balancer zum Ausgleich von Verbindungen und Traffic für andere Protokolle verwenden. Sie können beispielsweise eine HTTP-Systemdiagnose in Kombination mit einem HTTP-Server verwenden, der auf jeder Backend-VM ausgeführt wird. In diesem Beispiel sind Ihre Skripts oder Ihre Software dafür verantwortlich, den HTTP-Server so zu konfigurieren, dass er den Status 200 nur zurückgibt, wenn die Software, die auf Load-Balancing-Verbindungen wartet, betriebsbereit ist.

Weitere Informationen zu unterstützten Systemdiagnoseprotokollen und ‑ports finden Sie unter Kategorien, Protokolle und Ports der Systemdiagnose und Funktionsweise von Systemdiagnosen.

Systemdiagnose-Pakete

Bei Back-Ends mit Instanzgruppen senden Systemdiagnose-Prober Pakete an die Netzwerkschnittstelle nic0 jeder Back-End-VM. Für zonale NEG-Backends vom Typ GCE_VM_IP senden Health-Check-Prober Pakete an die Netzwerkschnittstelle im VPC-Subnetzwerk der NEG. Systemdiagnose-Pakete haben die folgenden Merkmale:

  • Die Ziel-IP-Adresse stimmt mit einer der beiden IP-Adressen der Weiterleitungsregel überein, die auf den globalen externen Passthrough-Network Load Balancer-Backend-Dienst verweist. Systemdiagnosepakete werden an beide IP-Adressen gesendet.
  • Der Zielport muss mit der Portnummer übereinstimmen, die Sie in der Systemdiagnose angeben.

Anwendungen, die auf den Backend-VMs ausgeführt werden, müssen an die relevanten IP-Adressen und Portkombinationen gebunden sein und diese überwachen. Konfigurieren Sie dazu die Anwendung so, dass sie an die relevanten Ports einer der IP-Adressen der VM (0.0.0.0 oder ::/0) gebunden wird und auf diesen Ports lauscht. Weitere Informationen finden Sie unter Ziel für Prüfungspakete.

Firewallregeln

Da es sich bei einem globalen externen Passthrough-Netzwerk-Load-Balancer nicht um einen Proxy handelt, leitet er Traffic an Backend-VMs weiter, ohne die Quell- und Ziel-IP-Adressen, das Protokoll und die Ports zu ändern, sofern das Protokoll Portinformationen enthält. Daher müssen Sie Firewallregeln zum Zulassen von eingehendem Traffic oder eine hierarchische Firewallrichtlinie zum Zulassen von eingehendem Traffic erstellen, um den Zugriff auf die Backend-VMs des Load-Balancers zu steuern und insbesondere Systemdiagnosen und den Traffic für das Load-Balancing zuzulassen. Andernfalls werden eingehende Pakete von allen externen Quell-IP-Adressen durch die implizierte Firewallregel zum Ablehnen von eingehendem Traffic blockiert.

Weiterleitungsregeln und Firewallregeln oder hierarchische Regeln zum Zulassen von eingehendem Traffic arbeiten so zusammen: Eine Weiterleitungsregel gibt die Ziel-IP-Adresse, das Protokoll und (falls definiert) die Portanforderungen an, die ein Paket erfüllen muss, um an eine Back-End-VM weitergeleitet zu werden. Firewallregeln für eingehenden Traffic steuern, ob die Firewall die weitergeleiteten Pakete an die VM zustellt oder verwirft. Das Standard-VPC-Netzwerk Cloud de Confiance enthält eine begrenzte Anzahl von vorkonfigurierten Firewallregeln zum Zulassen von eingehendem Traffic.

  • Wenn Sie Traffic von beliebigen IP-Adressen im Internet akzeptieren möchten, müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic mit dem Quellbereich 0.0.0.0/0 oder ::/0 erstellen. Um nur Traffic von bestimmten IP-Adressbereichen zuzulassen, verwenden Sie restriktivere Quellbereiche.

  • Als bewährte Sicherheitsmethode sollten Ihre Firewallregeln zum Zulassen von eingehendem Traffic nur die von Ihnen benötigten IP-Protokolle und -Ports zulassen. Die Beschränkung der Protokollkonfiguration (und, falls möglich, des Ports) ist besonders wichtig, wenn Sie Weiterleitungsregeln verwenden, deren Protokoll auf L3_DEFAULT festgelegt ist. L3_DEFAULT-Weiterleitungsregeln leiten Pakete für alle unterstützten IP-Protokolle weiter (an allen Ports, wenn das Protokoll und das Paket Portinformationen haben).

  • Globale externe Passthrough-Network Load Balancer verwenden Cloud de Confiance Systemdiagnosen. Daher müssen Sie immer Traffic aus den IP-Adressbereichen der Systemdiagnose zulassen. Sie können diese Firewallregeln für zulässigen eingehenden Traffic speziell für das Protokoll und die Ports der Systemdiagnose des Load-Balancers konfigurieren.

Traffic-Verteilung

Bei einem globalen externen Passthrough-Network Load Balancer hängt die Verteilung des Traffics von verschiedenen Attributen ab, z. B. von der Sitzungsaffinität, der Verbindungs-Tracking-Richtlinie, dem Load-Balancing-Modus und den Backend-Kapazitäten, bevorzugten Backends und der Load-Balancing-Richtlinie für den Ort. Sie sind alle Teil eines koordinierten Workflows, mit dem Sie Ihre Load-Balancing-Konfiguration für zuverlässige Leistung und effiziente Ressourcennutzung optimieren können.

Architektur einer freigegebene VPC

Beachten Sie die folgenden Punkte in Bezug auf eine Architektur mit gemeinsam genutzter VPC für einen globalen externen Passthrough-Network Load Balancer:

  • Mit Ausnahme der IP-Adressressourcen müssen alle anderen Ressourcen, die einem globalen externen Passthrough-Network Load Balancer zugeordnet sind (Weiterleitungsregel, Backend-Dienst, Systemdiagnose und Backend-Gruppen (Instanzgruppen oder NEGs)), im selben Projekt vorhanden sein. Dieses Projekt kann ein Hostprojekt oder ein Dienstprojekt sein.

  • Wenn die Load-Balancing-Ressourcen im Hostprojekt vorhanden sind, müssen auch die IP‑Adressressourcen im Hostprojekt vorhanden sein.

  • Wenn die Load-Balancing-Ressourcen in einem Dienstprojekt vorhanden sind, können sich die IP-Adressressourcen entweder im selben Dienstprojekt oder im Hostprojekt befinden.

In der folgenden Tabelle ist aufgeführt, wo sich die verschiedenen Komponenten eines globalen externen Passthrough-Network Load Balancers in einer Architektur mit freigegebene VPC befinden.

Standort von Load-Balancing-Ressourcen1 Erforderlicher Standort von IP-Adressressourcen
Hostprojekt Hostprojekt
Dienstprojekt Dienstprojekt oder Hostprojekt

1: Enthält die Weiterleitungsregel, den Backend-Dienst, die Systemdiagnose und die Backends (Instanzgruppen oder NEGs).

Beschränkungen

  • Back-Ends können nur in den folgenden Cloud de Confiance Regionen bereitgestellt werden:

    • Nordamerika: us-west1, us-west4, us-east4, us-east5
    • Europa: europe-west2, europe-west3
    • Asien: asia-southeast1, asia-south1, asia-northeast1
    • Südamerika: southamerica-east1
    • Afrika: africa-south1
    • Australien: australia-southeast1

  • Der globale externe Passthrough-Network Load Balancer kann nur in der Premium-Stufe konfiguriert werden.

  • Sie können keinen globalen externen Passthrough-Network Load Balancer über die Cloud de Confiance Console konfigurieren. Verwenden Sie stattdessen entweder die Google Cloud-Befehlszeile oder die REST API.

  • Sie können keine regionalen verwalteten Instanzgruppen als Back-Ends verwenden. Sie können zonale verwaltete Instanzgruppen, zonale nicht verwaltete Instanzgruppen und zonale NEGs mit GCE_VM_IP-Endpunkten verwenden.

  • Die vorhandenen Einschränkungen und Hinweise zur Verwendung von Instanzgruppen in Backend-Diensten gelten auch für globale externe Passthrough-Network Load Balancer. Eine Instanzgruppe, die von einem globalen externen Passthrough-Network Load Balancer und regionalen Passthrough-Network Load Balancern (regionaler externer Passthrough-Network Load Balancer oder interner Passthrough-Network Load Balancer) gemeinsam verwendet wird, muss für die Verwendung des Balancing-Modus RATE auf dem globalen externen Passthrough-Network Load Balancer konfiguriert werden. Regionale Passthrough-Network Load Balancer verwenden immer den Balancing-Modus CONNECTION.

  • Sie können dieselbe globale externe IP-Adresse für mehrere globale externe Passthrough-Network Load Balancer-Weiterleitungsregeln verwenden, sofern die konfigurierten Protokolle und Ports nicht in Konflikt stehen. Sie können jedoch nicht dieselbe globale externe IP-Adresse für einen globalen externen Passthrough-Network Load Balancer und einen globalen externen Application Load Balancer oder globalen externen Proxy-Network Load Balancer verwenden.

  • Ein globaler externer Passthrough-Network Load Balancer unterstützt BYOIP (Bring your own IP addresses) nur für IPv4-Adressen. Der Support ist auf die BYOIP API v1 beschränkt. Die Bereitstellung neuer IPv4-Bereiche kann bis zu vier Wochen dauern. Es gibt keine APIs, mit denen Sie den Status Ihrer BGP-Ankündigung steuern können. Weitere Informationen finden Sie unter BYOIP-Konfigurationen.

  • Sie können in einem Projekt nicht mehr als 10 Weiterleitungsregeln erstellen und einem Backend-Dienst nicht mehr als 25 Backend-Gruppen hinzufügen. Einzelheiten finden Sie unter Kontingente und Limits.

  • Ein globaler externer Passthrough-Network Load Balancer-Backend-Dienst kann höchstens eine PREFERRED-Backend-Gruppe haben. Sie können nicht sowohl eine PREFERRED- als auch eine Nicht-PREFERRED-Backend-Gruppe in derselben Cloud de Confiance -Region haben.

  • Sie können keinen globalen externen Passthrough-Network-Load-Balancer in GKE bereitstellen.

  • Sie können Google Cloud Armor nicht verwenden, um erweiterten DDoS-Netzwerkschutz für globale externe Passthrough-Network-Load-Balancer bereitzustellen. Weitere Informationen finden Sie unter Erweiterten DDoS-Netzwerkschutz konfigurieren.

  • Die Load-Balancing-Richtlinie für den Ort, die für den Backend-Dienst des Load-Balancers konfiguriert ist, unterstützt die Option WEIGHTED_MAGLEV nicht. Bei globalen externen Passthrough-Network-Load-Balancern wird nur MAGLEV unterstützt.

  • Der PER_SESSION-Verbindungs-Tracking-Modus wird nicht unterstützt. Nur der PER_CONNECTION-Verbindungs-Tracking-Modus wird unterstützt.

  • Nur die folgenden Load-Balancing-Modi werden unterstützt: RATE und UTILIZATION. Die Rate wird nicht in Anfragen pro Sekunde, sondern in eingehenden Paketen pro Sekunde definiert. Instanzgruppen unterstützen sowohl RATE als auch UTILIZATION, während NEGs nur RATE unterstützen.

  • Weiterleitungsregeln für die Steuerung (Quell-IP-basierte Trafficsteuerung) werden nicht unterstützt.

  • Alle an einen Backend-Dienst angehängten Backends müssen vom selben Typ sein. Ein Backend-Dienst kann nicht sowohl Instanzgruppen als auch zonale NEGs enthalten.

  • Monitoring-Messwerte können nicht mit den übergeordneten globalen Weiterleitungsregeln abgefragt oder gefiltert werden. Sie müssen mit den von Cloud de Confiancegenerierten untergeordneten Weiterleitungsregeln abgefragt werden.

Preise

Preisinformationen finden Sie unter Netzwerkpreise: Cloud Load Balancing.

Nächste Schritte