Übersicht über internen Passthrough-Netzwerk-Load-Balancer

Ein interner Passthrough-Netzwerk-Load-Balancer ist ein regionaler Load-Balancer, der auf dem Virtualisierungsstack für das Andromeda-Netzwerk basiert.

Der interne Passthrough-Netzwerk-Load-Balancer verteilt den Traffic auf interne VM-Instanzen in derselben Region in einem VPC-Netzwerk (Virtual Private Cloud). Sie können damit Ihre Dienste hinter einer internen IP-Adresse ausführen und skalieren. Zugriff darauf ist nur für Systeme im selben VPC-Netzwerk oder für Systeme verfügbar, die mit Ihrem VPC-Netzwerk verbunden sind.

In folgenden Fällen sollten Sie einen internen Passthrough-Netzwerk-Load-Balancer verwenden:

  • Sie benötigen einen leistungsstarken Pass-Through-Layer-4-Load Balancer für die Protokolle TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH und GRE.
  • Wenn der Traffic über TLS (SSL) bereitgestellt wird, ist es zulässig, SSL-Traffic von Ihren Back-Ends und nicht vom Load-Balancer beenden zu lassen. Der interne Passthrough-Netzwerk-Load-Balancer kann SSL-Traffic nicht beenden.
  • Sie müssen die ursprünglichen Pakete ohne Proxy weiterleiten. Zum Beispiel, wenn die Quell-IP-Adresse des Clients erhalten bleiben soll.
  • Sie haben bereits eine Konfiguration, in der ein Pass-Through-Load-Balancer verwendet wird, und möchten sie ohne Änderungen migrieren.

Die internen Passthrough-Netzwerk-Load-Balancer sind für viele Anwendungsfälle vorgesehen. Einige allgemeine Beispiele finden Sie unter Übersicht: Passthrough-Network-Load-Balancer.

Funktionsweise von internen Passthrough-Netzwerk-Load-Balancern

Ein interner Passthrough-Netzwerk-Load-Balancer hat ein Frontend (die Weiterleitungsregel) und ein Backend (den Backend-Dienst). Sie können für den Backend-Dienst entweder Instanzgruppen oder GCE_VM_IP zonale NEGs als Backends verwenden. Dieses Beispiel zeigt Instanzgruppen-Backends.

Allgemeines Beispiel für einen internen Passthrough-Netzwerk-Load-Balancer
Allgemeines Beispiel für einen internen Passthrough-Network-Load-Balancer (zum Vergrößern klicken).

Im Gegensatz zu einem Proxy-Load-Balancer beendet ein interner Passthrough-Netzwerk-Load-Balancer keine Verbindungen von Clients und öffnet keine neuen Verbindungen zu Backends. Stattdessen leitet ein interner Passthrough-Netzwerk-Load-Balancer Verbindungen ohne Unterbrechung direkt von Clients an die fehlerfreien Backends weiter. Antworten von fehlerfreien Backend-VMs werden direkt an die Clients und nicht über den Load-Balancer gesendet. TCP-Antworten verwenden die direkte Serverrückgabe. Weitere Informationen finden Sie unter TCP und UDP – Anfrage und Rückgabe von Paketen.

Der Load-Balancer überwacht den Backend-Status über Systemdiagnoseprüfungen. Weitere Informationen finden Sie im Abschnitt Systemdiagnose.

Die Google Cloud Linux-Gastumgebung, die Windows-Gastumgebung oder ein entsprechender Prozess konfiguriert jede Back-End-VM mit der IP-Adresse des Load Balancers. Bei VMs, die aus Google Cloud -Images erstellt wurden, installiert der Gast-Agent (früher die Windows-Gastumgebung oder die Linux-Gastumgebung) die lokale Route für die IP-Adresse des Load Balancers. Google Kubernetes Engine-Instanzen, die auf Container-Optimized OS basieren, implementieren dies stattdessen mit iptables.

Google Cloud Das virtuelle Netzwerk verwaltet die Bereitstellung des Traffics und nimmt eine entsprechende Skalierung vor.

Protokolle, Schema und Bereich

Jeder interne Passthrough-Netzwerk-Load-Balancer unterstützt Folgendes:

  • Einen Back-End-Dienst mit dem Load-Balancing-Schema INTERNAL und einem unterstützten Protokoll. Weitere Informationen finden Sie unter Back-End-Dienst.
  • Backend-VMs, die auf eine der folgenden Arten angegeben sind:
  • Unterstützung von IPv4- und IPv6-Traffic bei Verwendung von Instanzgruppen-Back-Ends. Zonale Netzwerk-Endpunktgruppen (NEGs) mit GCE_VM_IP-Endpunkten unterstützen nur IPv4-Traffic.
  • Eine oder mehrere Weiterleitungsregeln, die entweder das Protokoll TCP, UDP oder L3_DEFAULT (Vorschau) verwenden und dem Protokoll des Backend-Dienstes entsprechen.
  • Jede Weiterleitungsregel mit einer eigenen eindeutigen IP-Adresse oder mehrere Weiterleitungsregeln, die eine gemeinsame IP-Adresse verwenden.
  • Jede Weiterleitungsregel mit bis zu fünf oder allen Ports.
  • Clients in jeder Region, wenn globaler Zugriff aktiviert ist.
  • Clients in derselben Region wie der Load-Balancer, wenn globaler Zugriff deaktiviert ist.

Ein interner Passthrough-Netzwerk-Load-Balancer unterstützt nicht:

Clientzugriff

Standardmäßig unterstützt der Load Balancer nur Clients, die sich in derselben Region wie der Load Balancer befinden. Clients können sich im selben Netzwerk wie der Load Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist. Sie können globalen Zugriff aktivieren, damit Clients aus jeder Region auf Ihren internen Passthrough-Netzwerk-Load-Balancer zugreifen können.

Interner Passthrough-Network-Load-Balancer mit globalem Zugriff.
Interner Passthrough-Network-Load-Balancer mit globalem Zugriff (zum Vergrößern klicken)

In der folgenden Tabelle wird der Clientzugriff zusammengefasst.

Globaler Zugriff deaktiviert Globaler Zugriff aktiviert
Clients müssen sich in derselben Region wie der Load-Balancer befinden. Sie müssen sich außerdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist. Clients können sich in jeder beliebigen Region befinden. Sie müssen sich aber trotzdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.
Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge müssen sich in derselben Region wie der Load-Balancer befinden. Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge können sich in einer beliebigen Region befinden.

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: Die interne IPv4-, IPv6- oder die IPv4-Adresse des Clients aus einem der Alias-IPv4-Bereiche des Clients.
  • Ziel: die IP-Adresse der Weiterleitungsregel des Load-Balancers Die Weiterleitungsregel verwendet entweder eine einzelne interne IPv4-Adresse oder einen internen IPv6-Bereich.

Da es sich beim Load-Balancer um einen Pass-Through-Load-Balancer (nicht um einen Proxy) handelt, kommen Pakete an, die die Ziel-IP-Adresse der Weiterleitungsregel des Load-Balancers enthalten. Software, die auf Backend-VMs ausgeführt wird, sollte so konfiguriert werden, dass sie Folgendes tut:

  • IP-Adresse 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 Backend-VMs des Load-Balancers an den Client gesendet. Die Quell- und Ziel-IP-Adressen des Rückgabepakets hängen vom Protokoll ab:

  • TCP ist verbindungsorientiert, sodass Backend-VMs mit Paketen antworten müssen, deren Quell-IP-Adressen mit der IP-Adresse der Weiterleitungsregel übereinstimmen, sodass der Client die Antwortpakete der entsprechenden TCP-Verbindung zuordnen kann.
  • UDP ist verbindungslos, sodass Backend-VMs Antwortpakete senden können, deren Quell-IP-Adressen entweder mit der IP-Adresse der Weiterleitungsregel oder mit einer beliebigen zugewiesenen 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 Quellen und Ziele für Antwortpakete zusammengefasst:

Traffictyp Quelle Ziel
TCP Die IP-Adresse der Weiterleitungsregel des Load-Balancers Die Quelle des anfragenden Pakets
UDP In den meisten Anwendungsfällen die IP-Adresse der Weiterleitungsregel des Load-Balancers Die Quelle des anfragenden Pakets

Es ist möglich, die Quelle des Antwortpakets auf die primäre interne IPv4-Adresse der VM-NIC oder einen Alias-IP-Adressbereich festzulegen. Wenn für die VM die IP-Weiterleitung aktiviert ist, können auch beliebige IP-Adressquellen verwendet werden. Nicht die IP-Adresse der Weiterleitungsregel als Quelle zu verwenden, ist ein erweitertes Szenario, da der Client ein Antwortpaket von einer internen IP-Adresse empfängt, die nicht mit der IP-Adresse übereinstimmt, an die ein Anfragepaket gesendet wurde.

Architektur

Ein interner Passthrough-Netzwerk-Load-Balancer mit mehreren Back-Ends verteilt Verbindungen auf alle diese Back-Ends. Weitere Informationen zur Verteilungsmethode und zu ihren Konfigurationsoptionen finden Sie unter Traffic-Verteilung.

Sie können Instanzgruppen oder zonale NEGs verwenden, aber keine Kombination aus beiden als Back-Ends für einen internen TCP/UDP-Load-Balancer:

  • Wenn Sie Instanzgruppen auswählen, können Sie nicht verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen, regionale verwaltete Instanzgruppen oder eine Kombination von Instanzgruppentypen verwenden.
  • Wenn Sie zonale NEGs verwenden, müssen Sie zonale GCE_VM_IP-NEGs verwenden.

Unter Hochverfügbarkeit wird beschrieben, wie Sie einen internen Load-Balancer entwerfen, der nicht von einer einzelnen Zone abhängig ist.

Instanzen, die als Backend-VMs für interne Passthrough-Netzwerk-Load-Balancer verwendet werden, müssen die entsprechende Linux- oder Windows-Gastumgebung oder andere Prozesse ausführen, die gleichwertige Funktionen bereitstellen. Diese Gastumgebung muss den Metadatenserver (metadata.google.internal, 169.254.169.254) zum Lesen von Instanzmetadaten kontaktieren können, damit lokale Routen zum Akzeptieren von Traffic generiert werden können, der an die interne IP-Adresse des Load-Balancers gesendet wird.

Dieses Diagramm veranschaulicht die Traffic-Verteilung auf VMs in zwei separaten Instanzgruppen. Traffic, der von der Clientinstanz an die IP-Adresse des Load-Balancers 10.10.10.9 gesendet wird, wird zwischen den Back-End-VMs in einer der Instanzgruppen verteilt. Von einer der bereitstellenden Backend-VMs gesendete Antworten werden direkt an die Client-VM zugestellt.

Sie können einen internen Passthrough-Netzwerk-Load-Balancer entweder mit einem VPC-Netzwerk im benutzerdefinierten Modus oder im automatischen Modus verwenden. Sie können auch interne Passthrough-Netzwerk-Load-Balancer mit einem vorhandenen Legacy-Netzwerk erstellen.

Ein interner Passthrough-Netzwerk-Load-Balancer unterstützt nicht:

Interne IP-Adresse

Interne Passthrough-Network Load Balancer unterstützen nur IPv4-, Dual-Stack- und nur IPv6-Subnetze. Weitere Informationen zu den einzelnen Typen finden Sie unter Subnetztypen.

Für einen internen Passthrough-Netzwerk-Load-Balancer ist mindestens eine Weiterleitungsregel erforderlich. Die Weiterleitungsregel verweist auf die interne IP-Adresse:

  • Bei IPv4-Traffic verweist die Weiterleitungsregel auf eine IPv4-Adresse aus dem primären IPv4-Subnetzbereich.
  • Bei IPv6-Traffic verweist die Weiterleitungsregel auf einen /96-Bereich interner IPv6-Adressen aus dem internen /64-IPv6-Adressbereich des Subnetzes. Das Subnetz muss entweder ein Dual-Stack- oder ein Single-Stack-IPv6-Subnetz (Vorabversion) mit einem internen IPv6-Adressbereich sein (ipv6-access-type auf INTERNAL festgelegt). Der IPv6-Adressbereich kann eine reservierte statische Adresse oder eine sitzungsspezifische Adresse sein.

    Weitere Informationen zur IPv6-Unterstützung finden Sie in der VPC-Dokumentation zu IPv6-Subnetzbereichen und IPv6-Adressen.

Firewallkonfiguration

Für interne Passthrough-Netzwerk-Load-Balancer ist die folgende Konfiguration für hierarchische Firewallrichtlinien und VPC-Firewallregeln erforderlich:

Weitere Informationen finden Sie unter Firewallregeln konfigurieren.

Weiterleitungsregeln

Mit einer Weiterleitungsregel werden das Protokoll und die Ports angegeben, über die der Load-Balancer den Traffic annimmt. Da interne Passthrough-Netzwerk-Load-Balancer keine Proxys sind, leiten sie Traffic an Back-Ends über dasselbe Protokoll und denselben Port weiter.

Für einen internen Passthrough-Netzwerk-Load-Balancer ist mindestens eine interne Weiterleitungsregel erforderlich. Sie können mehrere Weiterleitungsregeln für denselben Load-Balancer definieren.

Erstellen Sie zwei Weiterleitungsregeln., wenn der Load-Balancer sowohl IPv4- als auch IPv6-Traffic verarbeiten soll: eine Regel für IPv4-Traffic, die auf IPv4- (oder Dual-Stack-)Back-Ends verweist, und eine Regel für IPv6-Traffic, der nur für 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 Dual-Stack-Backends verweisen.

Die Weiterleitungsregel muss auf ein bestimmtes Subnetz im selben VPC-Netzwerk und in derselben Region wie die Backend-Komponenten des Load-Balancers verweisen. Diese Anforderung hat folgende Auswirkungen:

  • Das Subnetz, das Sie für die Weiterleitungsregel angeben, muss nicht mit einem der von Backend-VMs verwendeten Subnetze identisch sein. Das Subnetz muss sich jedoch in derselben Region wie die Weiterleitungsregel befinden.
  • Bei IPv4-Traffic verweist die interne Weiterleitungsregel auf eine regionale interne IPv4-Adresse aus dem primären IPv4-Adressbereich des ausgewählten Subnetzes. Diese IPv4-Adresse kann automatisch ausgewählt werden; alternativ können Sie eine statische (reservierte) IPv4-Adresse verwenden.
  • Bei IPv6-Traffic verweist die Weiterleitungsregel auf einen /96-IPv6-Adressbereich aus dem internen /64-IPv6-Adressbereich des Subnetzes. Das Subnetz muss ein Dual-Stack-Subnetz sein, wobei ipv6-access-type auf INTERNAL gesetzt ist. Der IPv6-Adressbereich /96 wird entweder automatisch zugewiesen oder Sie verwenden eine reservierte interne IP-Adresse.

Weiterleitungsregelprotokolle

Interne Passthrough-Network Load Balancer unterstützen die folgenden IPv4-Protokolloptionen für jede Weiterleitungsregel: TCP, UDP oder L3_DEFAULT.

Interne Passthrough-Network Load Balancer unterstützen für jede Weiterleitungsregel die folgenden IPv6-Protokolloptionen: TCP oder UDP.

Mit der Option L3_DEFAULT (Vorschau) können Sie Load Balancing für TCP-, UDP-, ICMP-, ICMPv6-, SCTP-, ESP-, AH- und GRE-Protokolle ausführen.

Neben der Unterstützung von anderen Protokollen als TCP und UDP ermöglicht es die Option L3_DEFAULT (Vorschau), dass eine einzige Weiterleitungsregel gleichzeitig Traffic für mehrere Protokolle weiterleitet. Sie können beispielsweise nicht nur HTTP-Anfragen stellen, sondern auch die IP-Adresse des Load Balancers per Ping kontaktieren.

Weiterleitungsregeln mit den Protokollen TCP oder UDP können auf einen Backend-Dienst verweisen, der entweder dasselbe Protokoll wie die Weiterleitungsregel oder ein Backend-Dienst mit dem Protokoll UNSPECIFIED verwendet.

Wenn Sie das Protokoll L3_DEFAULT verwenden, müssen Sie die Weiterleitungsregel so konfigurieren, dass Traffic an allen Ports akzeptiert wird. Um alle Ports zu konfigurieren, stellen Sie entweder --ports=ALL mithilfe der Google Cloud-Befehlszeile ein oder setzen Sie mithilfe der API allPorts auf True.

In der folgenden Tabelle wird zusammengefasst, wie diese Einstellungen für verschiedene Protokolle verwendet werden.

Traffic für das Load-Balancing Protokoll der Weiterleitungsregel Protokoll des Backend-Dienstes
TCP (IPv4 oder IPv6) TCP TCP or UNSPECIFIED
UDP (IPv4 oder IPv6) UDP UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH und GRE L3_DEFAULT UNSPECIFIED

Weiterleitungsregeln und globaler Zugriff

Die Weiterleitungsregeln eines internen Passthrough-Netzwerk-Load-Balancers sind regional, auch wenn der globale Zugriff aktiviert ist. Nachdem Sie den globalen Zugriff aktiviert haben, wird das Flag allowGlobalAccess der regionalen internen Weiterleitungsregel auf true gesetzt.

Weiterleitungsregeln und Portspezifikationen

Wenn Sie eine interne Weiterleitungsregel erstellen, müssen Sie eine der folgenden Portspezifikationen auswählen:

  • Geben Sie mindestens einen und bis zu fünf Ports mit Nummer an.
  • Geben Sie ALL an, um Traffic an allen Ports weiterzuleiten.

Mit einer internen Weiterleitungsregel, die entweder alle TCP-Ports oder alle UDP-Ports unterstützt, können Backend-VMs mehrere Anwendungen jeweils mit eigenem Port ausführen. Traffic, der an einen bestimmten Port gesendet wird, wird an die entsprechende Anwendung geleitet, und alle Anwendungen verwenden dieselbe IP-Adresse.

Wenn Sie Traffic an mehr als fünf bestimmte Ports weiterleiten müssen, kombinieren Sie Firewallregeln mit Weiterleitungsregeln. Geben Sie beim Erstellen der Weiterleitungsregel alle Ports an und erstellen Sie dann allow-Firewallregeln für eingehenden Traffic, die nur Traffic zu den gewünschten Ports zulassen. Wenden Sie die Firewallregeln auf die Back-End-VMs an.

Nach dem Erstellen einer Weiterleitungsregel kann diese nicht mehr geändert werden. Wenn Sie die angegebenen Ports oder die interne IP-Adresse für eine interne Weiterleitungsregel ändern müssen, müssen Sie sie löschen und neu erstellen.

Mehrere Weiterleitungsregeln für einen einzelnen Back-End-Dienst

Sie können mehrere interne Weiterleitungsregeln konfigurieren, die alle auf denselben internen Backend-Dienst verweisen. Für einen internen Passthrough-Netzwerk-Load-Balancer ist mindestens eine interne Weiterleitungsregel erforderlich.

Wenn Sie mehrere Weiterleitungsregeln für denselben Back-End-Dienst konfigurieren, können Sie Folgendes tun:

  • Weisen Sie dem Load-Balancer mehrere IP-Adressen zu. Sie können mehrere Weiterleitungsregeln mit jeweils einer eigenen IP-Adresse erstellen. Für jede Weiterleitungsregel können alle Ports oder eine Gruppe von bis zu fünf Ports angegeben werden.

  • Weisen Sie dem Load-Balancer eine bestimmte Gruppe von Ports mit derselben IP-Adresse zu. Sie können mehrere Weiterleitungsregeln mit derselben IP-Adresse erstellen, wobei jede Weiterleitungsregel eine bestimmte Gruppe von bis zu fünf Ports verwendet. Dies ist eine Alternative zur Konfiguration einer einzelnen Weiterleitungsregel, bei der alle Ports angegeben sind.

Weitere Informationen zu Szenarien mit zwei oder mehr internen Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse haben, finden Sie unter Mehrere Weiterleitungsregeln mit derselben IP-Adresse.

Wenn Sie mehrere interne Weiterleitungsregeln verwenden, sollten Sie die auf Ihren Backend-VMs ausgeführte Software so konfigurieren, dass sie an alle IP-Adressen der Weiterleitungsregel oder an eine beliebige Adresse gebunden ist (0.0.0.0/0 für IPv4 oder::/0 für IPv6). Die Ziel-IP-Adresse für ein über den Load-Balancer ausgeliefertes Paket ist die interne IP-Adresse, die der entsprechenden internen Weiterleitungsregel zugeordnet ist. Weitere Informationen finden Sie unter TCP und UDP – Anfrage und Rückgabe von Paketen.

Backend-Dienst

Jeder interne Passthrough-Netzwerk-Load-Balancer hat einen regionalen internen Backend-Dienst, der Backend-Parameter und das Verhalten definiert. Der Name des Backend-Diensts ist der Name des internen TCP/UDP-Load-Balancers, der in der Google Cloud Console angezeigt wird.

Jeder Backend-Dienst definiert die folgenden Backend-Parameter:

  • Protokoll. Ein Backend-Dienst unterstützt IPv4- und IPv6-Traffic. Wenn das Protokoll ein Konzept eines Ports hat (z. B. TCP oder UDP), stellt der Backend-Dienst Pakete an Backend-VMs am selben Zielport bereit, an den der Traffic gesendet wurde.

    Backend-Dienste unterstützen die folgenden IPv4-Protokolloptionen: TCP, UDP oder UNSPECIFIED.

    Backend-Dienste unterstützen die folgenden IPv6-Protokolloptionen: TCP oder UDP. Das Protokoll des Back-End-Dienstes muss mit dem Protokoll der Weiterleitungsregel übereinstimmen.

    Eine Tabelle mit möglichen Kombinationen von Weiterleitungsregeln und Back-End-Dienstprotokollen finden Sie unter Protokollspezifikation für Weiterleitungsregeln.

  • Traffic-Verteilung. Ein Backend-Dienst ermöglicht das Verteilen von Traffic gemäß einer konfigurierbaren Sitzungsaffinität.

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

Jeder Backend-Dienst wird in einer einzelnen Region ausgeführt und verteilt den Traffic für Backend-VMs in einem einzelnen VPC-Netzwerk:

Instanzgruppen-Back-Ends und Netzwerkschnittstellen

Das mit einer Instanzgruppe verknüpfte VPC-Netzwerk ist das VPC-Netzwerk, das von der Netzwerkschnittstelle nic0 jeder Mitglied-VM verwendet wird.

  • Bei verwalteten Instanzgruppen wird das VPC-Netzwerk für die Instanzgruppe in der Instanzvorlage definiert.
  • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk für die Instanzgruppe als das VPC-Netzwerk definiert, das von der Netzwerkschnittstelle nic0 der ersten VM-Instanz verwendet wird, die Sie der nicht verwalteten Instanzgruppe hinzufügen.

Innerhalb einer bestimmten (verwalteten oder nicht verwalteten) Instanzgruppe müssen alle VM-Instanzen die nic0-Netzwerkschnittstellen im selben VPC-Netzwerk haben. Jede Mitglieds-VM kann optional zusätzliche Netzwerkschnittstellen (nic1 bis nic7) haben, aber jede Netzwerkschnittstelle muss an ein anderes VPC-Netzwerk angehängt werden. Diese Netzwerke müssen sich auch von dem VPC-Netzwerk unterscheiden, das der Instanzgruppe zugeordnet ist.

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 (nic0 bis nic7). Aus der Perspektive eines Endpunkts in einer NEG wird die Schnittstelle anhand ihrer primären IPv4-Adresse identifiziert.

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, Google Cloud erfordert Google Cloud, dass die VM eine Netzwerkschnittstelle in dem Subnetzwerk hat, das der NEG zugeordnet ist. Die IP-Adresse, die Google Cloudfü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.

Netzwerkspezifikation für Backend-Dienst

Sie können ein VPC-Netzwerk explizit mit einem Backend-Dienst verknüpfen. Verwenden Sie dazu das Flag --network, wenn Sie den Backend-Dienst erstellen. Die Netzwerkregeln für den Backend-Dienst werden sofort wirksam.

Wenn Sie beim Erstellen eines Backend-Dienstes das Flag --network weglassen, verwendetGoogle Cloud eines der folgenden qualifizierenden Ereignisse, um implizit das zugehörige VPC-Netzwerk des Backend-Dienstes festzulegen. Nachdem sie festgelegt wurde, kann das zugehörige VPC-Netzwerk des Backend-Dienstes nicht mehr geändert werden:

  • Wenn der Backend-Dienst noch keine zugehörigen Backends hat und Sie die erste Weiterleitungsregel so konfigurieren, dass sie auf den Backend-Dienst verweist, legtGoogle Cloud das verknüpfte VPC-Netzwerk auf das VPC-Netzwerk fest, das das von dieser Weiterleitungsregel verwendete Subnetz enthält.

  • Wenn der Backend-Dienst noch nicht auf eine Weiterleitungsregel verweist und Sie das erste Instanzgruppen-Backend dem Backend-Dienst hinzufügen, legtGoogle Cloud das VPC-Netzwerk des Backend-Dienstes auf das VPC-Netzwerk fest, das dem ersten Instanzgruppen-Backend zugeordnet ist. Das bedeutet, dass das mit dem Backend-Dienst verknüpfte VPC-Netzwerk das Netzwerk ist, das von der Netzwerkschnittstelle nic0 jeder VM im ersten Instanzgruppen-Backend verwendet wird.

  • Wenn der Backend-Dienst noch keine Weiterleitungsregel hat, die darauf verweist, und Sie das erste zonale NEG-Backend (mit GCE_VM_IP-Endpunkten) zum Backend-Dienst hinzufügen, legtGoogle Cloud das VPC-Netzwerk des Backend-Dienstes auf das VPC-Netzwerk fest, das diesem ersten NEG-Backend zugeordnet ist.

Nachdem das VPC-Netzwerk des Backend-Dienstes durch ein qualifizierendes Ereignis festgelegt wurde, müssen alle zusätzlichen Weiterleitungsregeln, Backend-Instanzgruppen oder von Ihnen hinzugefügten zonalen Backend-NEGs müssen den Netzwerkregeln für Backend-Dienste folgen.

Netzwerkregeln für Backend-Dienste

Die folgenden Regeln gelten, nachdem ein Backend-Dienst mit einem bestimmten VPC-Netzwerk verknüpft ist:

  • Wenn Sie eine Weiterleitungsregel für den Verweis auf den Backend-Dienst konfigurieren, muss die Weiterleitungsregel ein Subnetz des VPC-Netzwerks des Backend-Dienstes verwenden. Weiterleitungsregeln und Backend-Dienste können keine unterschiedlichen VPC-Netzwerke verwenden, auch wenn diese Netzwerke verbunden sind (z. B. über VPC-Netzwerk-Peering).

  • Beim Hinzufügen von Instanzgruppen-Back-Ends muss eine der folgenden Bedingungen erfüllt sein:

    • Das VPC-Netzwerk, das der Instanzgruppe zugeordnet ist, d. h. das VPC-Netzwerk, das von der Netzwerkschnittstelle nic0 jeder VM in der Instanzgruppe verwendet wird, muss mit dem verknüpften VPC-Netzwerk des Backend-Diensts übereinstimmen.
    • Jede Backend-VM muss eine Nicht-nic0-Schnittstelle (nic1 bis nic7) im VPC-Netzwerk haben, das dem Backend-Dienst zugeordnet ist.
  • Wenn Sie zonale NEG-Backends mit GCE_VM_IP-Endpunkten hinzufügen, muss das mit der NEG verknüpfte VPC-Netzwerk mit dem VPC-Netzwerk übereinstimmen, das dem Backend-Dienst zugeordnet ist.

Dual-Stack-Back-Ends (IPv4 und IPv6)

Wenn der Load Balancer Dual-Stack-Back-Ends verwenden soll, die sowohl IPv4- als auch IPv6-Traffic verarbeiten, beachten Sie die folgenden Anforderungen:

  • Back-Ends müssen in Dual-Stack-Subnetzen konfiguriert werden, die sich in derselben Region wie die IPv6-Weiterleitungsregel des Load-Balancers befinden. Für die Back-Ends können Sie ein Subnetz verwenden, bei dem ipv6-access-type auf INTERNAL oder EXTERNAL gesetzt ist. Wenn ipv6-access-type des Backend-Subnetzes auf EXTERNAL gesetzt ist, müssen Sie für die interne Weiterleitungsregel des Load Balancers ein anderes Dual-Stack- oder reines IPv6-Subnetz verwenden, bei dem ipv6-access-type auf INTERNAL gesetzt ist. Weitere Informationen finden Sie unter Dual-Stack-Subnetz hinzufügen.
  • Back-Ends müssen für Dual-Stack konfiguriert sein, wobei stack-type auf IPv4_IPv6 gesetzt ist. Wenn ipv6-access-type des Backend-Subnetzes auf EXTERNAL gesetzt ist, müssen Sie auch --ipv6-network-tier auf PREMIUM setzen. Weitere Informationen finden Sie unter Instanzvorlage mit IPv6-Adressen erstellen.

Nur IPv6-Backends

Wenn der Load Balancer nur IPv6-Back-Ends verwenden soll, beachten Sie die folgenden Anforderungen:

  • Reine IPv6-Instanzen werden nur in nicht verwalteten Instanzgruppen unterstützt. Andere Backend-Typen werden nicht unterstützt.
  • Back-Ends müssen entweder in Dual-Stack- oder IPv6-Subnetzen konfiguriert werden, die sich in derselben Region wie die IPv6-Weiterleitungsregel des Load Balancers befinden. Für die Back-Ends können Sie ein Subnetz verwenden, bei dem ipv6-access-type auf INTERNAL oder EXTERNAL gesetzt ist. Wenn ipv6-access-type des Backend-Subnetzes auf EXTERNAL gesetzt ist, müssen Sie für die interne Weiterleitungsregel des Load Balancers ein anderes IPv6-Subnetz verwenden, bei dem ipv6-access-type auf INTERNAL gesetzt ist.
  • Back-Ends müssen für IPv6-only konfiguriert sein, wobei stack-type der VM auf IPv6_ONLY gesetzt ist. Wenn ipv6-access-type des Backend-Subnetzes auf EXTERNAL gesetzt ist, müssen Sie auch --ipv6-network-tier auf PREMIUM setzen. Weitere Informationen finden Sie unter Instanzvorlage mit IPv6-Adressen erstellen.

Reine IPv6-VMs können sowohl in Dual-Stack- als auch in reinen IPv6-Subnetzen erstellt werden. Dual-Stack-VMs können jedoch nicht in reinen IPv6-Subnetzen erstellt werden.

Backend-Teilmengeneinstellung

Die Backend-Teilmengeneinstellung ist eine optionale Funktion, die die Leistung verbessert, indem die Anzahl der Backends begrenzt wird, auf die der Traffic verteilt wird.

Sie sollten die Teilmengeneinstellung nur aktivieren, wenn Sie mehr als 250 Backend-VMs auf einem einzelnen Load-Balancer unterstützen müssen. Weitere Informationen finden Sie unter Backend-Teilmengeneinstellung für internen Passthrough-Netzwerk-Load-Balancer.

Systemdiagnose

Der Back-End-Dienst des Load-Balancers muss einer globalen oder regionalen Systemdiagnose zugeordnet sein. Spezielle Routen außerhalb des VPC-Netzwerks erleichtern die Kommunikation zwischen Systemdiagnosen und Back-Ends.

Sie können eine vorhandene Systemdiagnose verwenden oder eine neue definieren. Die internen Passthrough-Netzwerk-Load-Balancer verwenden den Systemdiagnosestatus wie unter Traffic-Verteilung beschrieben, um zu bestimmen, wie neue Verbindungen weitergeleitet werden.

Sie können eines der folgenden Systemdiagnoseprotokolle verwenden: Das Protokoll der Systemdiagnose muss nicht mit dem Protokoll des Load-Balancers übereinstimmen:

  • HTTP, HTTPS oder HTTP/2. Wenn Ihre Backend-VMs Traffic über HTTP, HTTPS oder HTTP/2 bereitstellen, verwenden Sie am besten eine Systemdiagnose, die mit diesem Protokoll übereinstimmt, da HTTP-basierte Systemdiagnosen geeignete Optionen für dieses Protokoll bieten. Die Bereitstellung von HTTP-Traffic über einen internen Passthrough-Netzwerk-Load-Balancer bedeutet, dass das Protokoll des Load-Balancers TCP ist.
  • SSL oder TCP. Wenn Ihre Back-End-VMs keinen HTTP-Traffic bereitstellen, sollten Sie entweder eine SSL- oder eine TCP-Systemdiagnose verwenden.

Unabhängig vom Typ der erstellten Systemdiagnose sendet Google Cloud Systemdiagnoseprüfungen an die IP-Adresse der Weiterleitungsregel des internen Passthrough-Netzwerk-Load Balancers und an die Netzwerkschnittstelle im vom Backend-Dienst des Load Balancers ausgewählten VPC-Netzwerk. Hiermit wird simuliert, wie Traffic mit Load-Balancing gesendet wird. Software, die auf Ihren Back-End-VMs ausgeführt wird, muss sowohl auf Traffic mit Load Balancing als auch auf Systemdiagnoseprüfungen reagieren, die an die IP-Adresse der einzelnen Weiterleitungsregeln gesendet werden. Die Software muss über 0.0.0.0:<port> und nicht über eine bestimmte IP-Adresse reagieren, die einer Netzwerkschnittstelle zugewiesen ist. Weitere Informationen finden Sie unter Ziel für Prüfungspakete.

Systemdiagnosen und UDP-Traffic

Google Cloud bietet keine Systemdiagnose an, bei der das UDP-Protokoll verwendet wird. Wenn Sie einen internen Passthrough-Netzwerk-Load-Balancer mit UDP-Traffic verwenden, müssen Sie auf Ihren Backend-VMs einen TCP-basierten Dienst ausführen, um Informationen aus der Systemdiagnoseprüfung bereitzustellen.

Bei dieser Konfiguration erfolgt das Load Balancing von Clientanfragen mithilfe des UDP-Protokolls und ein TCP-Dienst wird verwendet, um den Google Cloud -Systemdiagnoseprüfern Informationen bereitzustellen. Sie können beispielsweise auf jeder Back-End-VM, die eine HTTP 200-Antwort an Google Cloudzurückgibt, einen einfachen HTTP-Server ausführen. In diesem Beispiel sollten Sie Ihre eigene Logik verwenden, die auf der Back-End-VM ausgeführt wird, um dafür zu sorgen, dass der HTTP-Server nur dann 200 zurückgibt, wenn der UDP-Dienst richtig konfiguriert ist und ordnungsgemäß ausgeführt wird.

Hochverfügbarkeitsarchitektur

Der interne Passthrough-Netzwerk-Load-Balancer ist standardmäßig hochverfügbar. Es gibt keine speziellen Schritte, um den Load-Balancer hochverfügbar zu machen, da der Mechanismus nicht auf einem einzelnen Gerät oder einer einzigen VM-Instanz beruht.

Gehen Sie gemäß dieser Empfehlungen vor, um Ihre Back-End-VM-Instanzen in mehreren Zonen bereitzustellen:

  • Verwenden Sie regional verwaltete Instanzgruppen, wenn Sie Ihre Software mithilfe von Instanzvorlagen bereitstellen können. Regional verwaltete Instanzgruppen verteilen den Traffic automatisch auf mehrere Zonen. Dadurch lassen sich potenzielle Probleme in einer bestimmten Zone vermeiden.

  • Bei zonal verwalteten Instanzgruppen oder nicht verwalteten Instanzgruppen verwenden Sie für denselben Back-End-Dienst mehrere Instanzgruppen in verschiedenen Zonen (in derselben Region). Die Verwendung mehrerer Zonen schützt vor möglichen Problemen in einer bestimmten Zone.

Architektur einer freigegebenen VPC

In der folgenden Tabelle sind die Komponentenanforderungen für interne Passthrough-Netzwerk-Load-Balancer zusammengefasst, die mit freigegebenen VPC-Netzwerken verwendet werden. Ein Beispiel finden Sie auf der Seite „Internen Passthrough-Netzwerk-Load-Balancer auf der bereitgestellten freigegebenen VPC erstellen“.

IP-Adresse Weiterleitungsregel Backend-Komponenten
Eine interne IP-Adresse muss im selben Projekt wie die Back-End-VMs definiert werden.

Damit der Load Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die Google Cloud interne IP-Adresse im selben Dienstprojekt definiert werden, in dem sich die Backend-VMs befinden. Außerdem muss sie auf ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verweisen. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.

Wenn Sie eine interne IP-Adresse in einem Dienstprojekt erstellen und sich das IP-Adress-Subnetz im VPC-Netzwerk des Dienstprojekts befindet, wird der interne Passthrough-Netzwerk-Load-Balancer vom Dienstprojekt als lokal betrachtet. Er wird von keinem freigegebenen VPC-Hostprojekt als lokal betrachtet.
Eine interne Weiterleitungsregel muss im selben Projekt wie die Back-End-VMs definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne Weiterleitungsregel im selben Dienstprojekt definiert werden, in dem sich die Backend-VMs befinden. Außerdem muss sie auf dasselbe Subnetz (im freigegebenen VPC-Netzwerk) verweisen, auf das die verknüpfte interne IP-Adresse verweist.

Wenn Sie in einem Dienstprojekt eine interne Weiterleitungsregel erstellen und sich das Subnetz der Weiterleitungsregel im VPC-Netzwerk des Dienstprojekts befindet, wird der interne Passthrough-Netzwerk-Load-Balancer vom Dienstprojekt als lokal betrachtet. Er wird von keinem freigegebenen VPC-Hostprojekt als lokal betrachtet.
Im Szenario eines freigegebenen VPC-Netzwerks befinden sich die Back-End-VMs in einem Dienstprojekt. Dort müssen auch der regionale interne Back-End-Dienst und die Systemdiagnose definiert werden.

Traffic-Verteilung

Interne Passthrough-Network Load Balancer unterstützen eine Vielzahl von Optionen zur Anpassung der Trafficverteilung, einschließlich Sitzungsaffinität, Verbindungs-Tracking und Failover. Weitere Informationen dazu, wie interne Passthrough-Network Load Balancer Traffic verteilen und wie diese Optionen miteinander interagieren, finden Sie unter Trafficverteilung für interne Passthrough-Network Load Balancer.

Kontingente und Limits

Informationen zu Kontingenten und Limits finden Sie unter Kontingente für Load-Balancing-Ressourcen.

Beschränkungen

  • Sie können die Google Cloud Console nicht verwenden, um einen internen Passthrough-Network Load Balancer mit zonalen NEG-Backends zu erstellen.

Nächste Schritte