Interne TCP/UDP-Load-Balancer als nächste Hops

Das interne TCP/UDP-Load-Balancing ist ein regionaler Load-Balancer, mit dem Sie Ihre Dienste hinter einer internen IP-Adresse für das Load-Balancing ausführen und skalieren können. Dabei können Sie einen internen TCP/UDP-Load-Balancer als nächstes Gateway verwenden, an das Pakete entlang des Pfads zu ihrem endgültigen Ziel weitergeleitet werden. Dazu legen Sie den Load-Balancer als nächsten Hop in einer benutzerdefinierten statischen Route fest.

Diese Konfiguration ist in den folgenden Fällen nützlich:

  • Wenn Sie das Load-Balancing auf mehreren VMs vornehmen müssen, die als NAT-Appliances (Virtual Network Address Translation) funktionieren.

  • Wenn Sie einen Load-Balancer als nächsten Hop für eine Standardroute benötigen. Wenn VM-Instanzen (Virtual Machine) in Ihrem VPC-Netzwerk (Virtual Private Cloud) Traffic an das Internet senden, wird der Traffic über virtuelle Gateway-Appliances mit Load-Balancing geleitet.

  • Wenn Sie Traffic über mehrere Load-Balancer in zwei oder mehrere Richtungen mit demselben Satz von VMs mit mehreren NICs als Back-Ends senden müssen. Erstellen Sie dazu einen Load-Balancer und verwenden Sie ihn als nächsten Hop für eine benutzerdefinierte statische Route in jedem VPC-Netzwerk. Jeder interne TCP/UDP-Load-Balancer wird in einem einzelnen VPC-Netzwerk betrieben und verteilt den Traffic an die Netzwerkschnittstellen der Back-End-VMs in diesem Netzwerk.

Load-Balancing für mehrere NICs (zum Vergrößern klicken)
Load-Balancing für mehrere NICs (zum Vergrößern klicken)

Im vorherigen Diagramm dient eine VM-Instanzengruppe als Back-End für zwei verschiedene Load-Balancer. Dieser Anwendungsfall wird interne TCP/UDP-Load-Balancer als nächste Hops mit gemeinsamen Back-Ends genannt, da mehrere NICs (nic0 und nic1 in diesem Fall) Load-Balancing auf den Back-End-VMs erhalten. Diese Bereitstellung ist zulässig, da internes TCP/UDP-Load-Balancing das Load-Balancing für jede Schnittstelle auf Back-End-VM-Instanzen unterstützt (nicht nur für die primäre Schnittstelle nic0).

Im Gegensatz dazu können zwei Gruppen von VM-Instanzen als Back-Ends für zwei unterschiedliche Load-Balancer dienen. Sie können zwei Gruppen von Back-Ends verwenden, wenn Sie unterschiedliche Zugriffsprofile für eingehenden und ausgehenden Traffic haben. Dieser Anwendungsfall wird interne TCP/UDP-Load-Balancer als nächste Hops mit unterschiedlichen Back-Ends genannt, da nur die primären Schnittstellen (nic0) Load-Balancing auf den Back-End-VMs erhalten. Diese Konfiguration wird im folgenden Diagramm dargestellt:

Load-Balancing für einzelne NICs (zum Vergrößern klicken)
Load-Balancing für einzelne NICs (zum Vergrößern klicken)

Sie können eine benutzerdefinierte statische Route erstellen, um TCP- und UDP-Traffic an einen internen TCP/UDP-Load-Balancer zu übergeben. Dabei ist der Load-Balancer der nächste Hop für die statische Route. Die Route kann die Standardroute (0.0.0.0/0), ein externes (öffentlich weiterleitbares) CIDR-Präfix oder ein internes CIDR-Präfix sein, wenn das Präfix nicht mit einer Subnetzroute in Konflikt steht. So können Sie beispielsweise Ihre Standardroute 0.0.0.0/0 durch eine Route ersetzen, die Traffic zur Paketverarbeitung an Back-End-VMs von Drittanbietern weiterleitet.

Zur Verwendung der benutzerdefinierten statischen Route müssen sich die VM-Instanzen in jedem VPC-Netzwerk in derselben Region befinden wie der zugehörige Load-Balancer.

Befindet sich ein Cloud Router in derselben Region wie ein Load-Balancer, können Sie diese Route mithilfe von benutzerdefinierten Cloud Router Route Advertisements für andere verbundene Netzwerke bewerben. Weitere Informationen finden Sie unter Internes TCP/UDP-Load-Balancing und verbundene Netzwerke.

Weitere Informationen

Vorteile der Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop

Wenn der Load-Balancer ein nächster Hop für eine statische Route ist, müssen Sie Ihre Clients nicht explizit so konfigurieren, dass sie Traffic an den Load-Balancer oder an jede Back-End-VM senden. Sie können Back-End-VMs als Bump-in-the-Wire integrieren.

Ein interner TCP/UDP-Load-Balancer als nächster Hop für eine statische Route bietet dieselben Vorteile wie das interne TCP/UDP-Load-Balancing. Die Systemdiagnose des Load-Balancers sorgt dafür, dass neue Verbindungen an fehlerfreie Back-End-VMs weitergeleitet werden. Wenn Sie eine verwaltete Instanzengruppe als Back-End verwenden, können Sie das Autoscaling so konfigurieren, dass die Gruppe VMs je nach Dienstanforderung erweitert oder verkleinert wird.

Spezifikationen

Im Folgenden finden Sie Spezifikationen für die Verwendung interner TCP/UDP-Load-Balancer als nächste Hops.

Client-IP-Sitzungsaffinität

Client-IP-Sitzungsaffinität ist eine verfügbare Sitzungsaffinitätsoption. Es handelt sich um eine Zwei-Tupel-Affinität, die die Quell-IP-Adresse und die Ziel-IP-Adresse als Eingaben für eine Hash-Funktion verwendet.

Wenn Sie einen internen TCP/UDP-Load-Balancer verwenden, ist die Ziel-IP-Adresse die IP-Adresse der Weiterleitungsregel des Load-Balancers. Client-IP-Sitzungsaffinität in diesem Kontext bedeutet, dass Verbindungen von einem Client mit einer konstanten Quell-IP-Adresse an dieselbe Back-End-VM geliefert werden, wenn die Back-End-VM intakt ist.

Wenn dagegen ein interner TCP/UDP-Load-Balancer als nächster Hop für eine statische Route verwendet wird, variiert die Ziel-IP-Adresse, da die Back-End-VMs des Load-Balancers Pakete verarbeiten und an verschiedene Ziele weiterleiten. Die Verwendung der Client-IP-Sitzungsaffinität in diesem Kontext führt nicht dazu, dass Pakete von derselben Back-End-VM verarbeitet werden, selbst wenn der Client über eine konstante Quell-IP-Adresse verfügt.

Zielbereich

Das Ziel einer benutzerdefinierten statischen Route kann nicht gleich oder spezifischer als eine Subnetzroute sein. Beachten Sie, dass spezifischer bedeutet, dass die Subnetzmaske länger ist. Diese Regel gilt für alle benutzerdefinierten statischen Routen, auch wenn der nächste Hop ein interner TCP/UDP-Load-Balancer ist. Angenommen, Ihre Subnetzroute ist 10.140.0.0/20. Das Ziel einer benutzerdefinierten statischen Route kann nicht identisch (10.140.0.0/20) und nicht spezifischer sein (10.140.0.0/22).

Gleiches VPC-Netzwerk und gleiche Region

Benutzerdefinierte statische Routen, die interne TCP/UDP-Load-Balancer als nächste Hops verwenden, sind auf Folgendes beschränkt:

  • Ein einzelnes VPC-Netzwerk. Der Load-Balancer und die benutzerdefinierte statische Route müssen sich im selben VPC-Netzwerk befinden.

  • Eine einzelne Region oder alle Regionen. Sofern Sie keinen globalen Zugriff konfiguriert haben, ist die benutzerdefinierte statische Route nur für Ressourcen in derselben Region wie der Load-Balancer verfügbar. Diese regionale Beschränkung wird erzwungen, obwohl die Route selbst Teil der Routingtabelle für das gesamte VPC-Netzwerk ist. Wenn Sie den globalen Zugriff aktivieren, ist die benutzerdefinierte statische Route für Ressourcen in jeder Region verfügbar.

Reihenfolge von Vorgängen

Sie müssen einen internen TCP/UDP-Load-Balancer erstellen, bevor Sie eine benutzerdefinierte statische Route erstellen können, die ihn als nächsten Hop verwendet. Der Load-Balancer muss vorhanden sein, bevor Sie die Route erstellen. Wenn Sie versuchen, eine Route zu erstellen, die auf einen nicht vorhandenen Load-Balancer verweist, gibt Google Cloud einen Fehler zurück.

Sie können einen internen TCP/UDP-Load-Balancer für den nächsten Hop angeben. Verwenden Sie dazu den Namen der Weiterleitungsregel und die Region des Load-Balancers und nicht die mit der Weiterleitungsregel verknüpfte interne IP-Adresse.

Wenn Sie eine Route mit einem nächsten Hop erstellt haben, der auf einen internen TCP/UDP-Load-Balancer verweist, können Sie den Load-Balancer erst löschen, nachdem Sie die Route gelöscht haben. Insbesondere können Sie eine interne Weiterleitungsregel erst dann löschen, wenn keine benutzerdefinierte statische Route diese Weiterleitungsregel als nächsten Hop verwendet.

Back-End-Anforderungen

  • Sie müssen alle Back-End-VMs des internen TCP/UDP-Load-Balancers so konfigurieren, dass die IP-Weiterleitung zugelassen wird (--can-ip-forward = True). Weitere Informationen finden Sie unter Überlegungen zum instanzbasierten oder Load-Balancer-basierten Routing.

  • Sie können keinen internen TCP/UDP-Load-Balancer verwenden, dessen Back-Ends GKE-Knoten (Google Kubernetes Engine) als nächster Hop für eine benutzerdefinierte statische Route sind. Software auf den Knoten kann Traffic nur dann an Pods weiterleiten, wenn das Ziel mit einer vom Cluster verwalteten IP-Adresse übereinstimmt, nicht mit einem beliebigen Ziel.

TCP-, UDP- und anderen Protokoll-Traffic verarbeiten

Wenn ein interner TCP/UDP-Load-Balancer als nächster Hop bereitgestellt wird, leitet Google Cloud den gesamten TCP- und UDP-Traffic über alle Ports an die Back-End-VMs weiter, unabhängig von folgenden Bedingungen:

  • Protokoll und Portkonfiguration der Weiterleitungsregel
  • Die Protokollkonfiguration des Back-End-Dienstes

Der Load-Balancer verarbeitet nur TCP- und UDP-Traffic und ignoriert den gesamten anderen Traffic, z. B. ICMP. Traffic, der nicht das TCP- oder UDP-Protokoll verwendet, wird von der nächsten spezifischsten Route in Ihrem VPC-Netzwerk verarbeitet. Die Routen für Nicht-TCP- und Nicht-UDP-Traffic haben folgende Eigenschaften:

  • Sie haben keinen internen TCP/UDP-Load-Balancer als nächsten Hop.
  • Sie werden entsprechend der Routingreihenfolge ausgewählt.

Angenommen, Sie haben die folgenden Routen in Ihrem VPC-Netzwerk:

  • Ziel: 1.1.1.1/32, nächster Hop: interner TCP/UDP-Load-Balancer
  • Ziel: 1.0.0.0/8, nächster Hop: Standard-Internetgateway

Bei Clients, die sich in derselben Region wie der Load-Balancer befinden (oder in jeder Region, in der der globale Zugriff aktiviert ist), verwendet der an 1.1.1.1/32 gerichtete TCP- und UDP-Traffic die Route mit dem nächsten TCP/UDP-Load-Balancer als nächsten Hop.

Für Nicht-TCP- und Nicht-UDP-Traffic (z. B. ICMP-Pings) wird stattdessen die Route 1.0.0.0/8 verwendet.

Zusätzliche Spezifikationen

  • Eine benutzerdefinierte statische Route kann keine Netzwerk-Tags verwenden, wenn die Route über einen internen TCP/UDP-Load-Balancer als nächsten Hop verfügt.

  • Sie können nicht mehrere benutzerdefinierte statische Routen mit derselben Priorität, demselben Ziel und demselben internen TCP/UDP-Load-Balancer für den nächsten Hop erstellen. Daher muss jede benutzerdefinierte statische Route mit demselben Load-Balancer als nächsten Hop mindestens ein eindeutiges Ziel oder eine eindeutige Priorität haben.

  • Wenn Sie verschiedene interne TCP/UDP-Load-Balancer als nächste Hops für mehrere Routen mit demselben Ziel und derselben Priorität haben, verteilt Google Cloud den Traffic nicht auf die Load-Balancer. Stattdessen wählt Google Cloud nur einen der Load-Balancer als nächsten Hop für den gesamten Traffic aus, der mit dem Ziel übereinstimmt, und ignoriert die anderen Load-Balancer.

  • Wenn Sie einen internen TCP/UDP-Load-Balancer als nächsten Hop für eine benutzerdefinierte statische Route verwenden, können Sie das Flag --purpose=SHARED_LOADBALANCER_VIP nicht mit der IP-Adresse der internen Weiterleitungsregel verwenden. Das liegt daran, dass die freigegebene interne IP-Adresse indirekt auf mehr als einen Back-End-Dienst verweisen kann.

Weitere Informationen finden Sie in der Routenübersicht.

Anwendungsfälle

Sie können einen internen TCP/UDP-Load-Balancer als nächsten Hop in mehreren Bereitstellungen und Topologien verwenden.

Beachten Sie für jedes Beispiel die folgenden Richtlinien:

  • Jede VM-Schnittstelle muss in einem separaten VPC-Netzwerk sein.

  • Sie können keine Back-End-VMs oder Load-Balancer verwenden, um Traffic zwischen Subnetzwerken im selben VPC-Netzwerk weiterzuleiten, da Subnetzrouten nicht überschrieben werden können.

  • Der interne TCP/UDP-Load-Balancer ist ein Software-definierter Passthrough-Load-Balancer. NAT und Proxy werden nur von den Back-End-VMs, den virtuellen Firewall-Appliances, ausgeführt.

Internen TCP/UDP-Load-Balancer als nächsten Hop zu einem NAT-Gateway verwenden

Bei diesem Anwendungsfall wird der Traffic per Load-Balancing von internen VMs auf mehrere NAT-Gateway-Instanzen verteilt, die Traffic an das Internet weiterleiten.

NAT-Anwendungsfall (zum Vergrößern klicken)
NAT-Anwendungsfall (zum Vergrößern klicken)

Hub-and-Spoke: Routen mit nächstem Hop über VPC-Netzwerk-Peering austauschen

Zusätzlich zum Austausch von Subnetzrouten können Sie VPC-Netzwerk-Peering konfigurieren, um benutzerdefinierte statische und dynamische Routen zu exportieren und zu importieren. Benutzerdefinierte statische Routen, die Netzwerk-Tags verwenden oder einen nächsten Hop des Standard-Internet-Gateways haben, werden ausgeschlossen.

Sie können eine Hub-and-Spoke-Topologie mit Ihren virtuellen Firewall-Appliances mit nächstem Hop konfigurieren, die sich im hub-VPC-Netzwerk befinden. Gehen Sie dazu so vor:

  • Erstellen Sie im hub-VPC-Netzwerk einen internen TCP/UDP-Load-Balancer mit virtuellen Firewall-Appliances als Back-Ends.
  • Erstellen Sie im hub-VPC-Netzwerk eine benutzerdefinierte statische Route und legen Sie als nächsten Hop den internen TCP/UDP-Load-Balancer fest.
  • Verbinden Sie das hub-VPC-Netzwerk mithilfe von VPC-Netzwerk-Peering mit jedem der spoke-VPC-Netzwerke.
  • Konfigurieren Sie für jedes Peering das hub-Netzwerk, um dessen benutzerdefinierten Routen zu exportieren, und konfigurieren Sie das entsprechende spoke-Netzwerk, um benutzerdefinierte Routen zu importieren. Die Route mit dem nächsten Hop des Load-Balancers ist eine der Routen, die vom hub-Netzwerk exportiert werden.

Der Firewall-Appliance-Load-Balancer mit nächstem Hop im hub-VPC-Netzwerk kann in jedem spoke-Netzwerk gemäß der Routing-Reihenfolge verwendet werden.

Hub-and-Spoke (zum Vergrößern klicken)
Hub-and-Spoke (zum Vergrößern klicken)

Load-Balancing für mehrere NICs

Im folgenden Anwendungsfall sind die Back-End-VMs virtuelle Appliance-Instanzen (z. B. Firewallinstanzen oder NAT-Gateways) mit NICs in mehreren VPC-Netzwerken. Firewallinstanzen und NAT-Gateways können von Drittanbietern als virtuelle Appliances bereitgestellt werden. Virtuelle Appliances sind Compute Engine-VMs mit mehreren NICs.

Dieses Beispiel zeigt eine einzelne Gruppe von virtuellen Back-End-Appliances in einer verwalteten VM-Instanzengruppe.

Im testing-VPC-Netzwerk hat der interne TCP/UDP-Load-Balancer eine Weiterleitungsregel namens fr-ilb1. Im Beispiel verteilt dieser Load-Balancer den Traffic auf die Schnittstelle nic0 jeder virtuellen Appliance, aber es kann eine beliebige NIC sein.

Im production-VPC-Netzwerk hat ein anderer interner TCP/UDP-Load-Balancer eine Weiterleitungsregel namens fr-ilb2. Dieser Load-Balancer verteilt den Traffic auf eine andere Schnittstelle; nic1 in diesem Beispiel.

Traffic mit Multi-NIC-Load-Balancing (zum Vergrößern klicken)
Traffic mit Multi-NIC-Load-Balancing (zum Vergrößern klicken)

Detaillierte Informationen zur Konfiguration finden Sie unter Load-Balancing für mehrere Back-End-NICs.

Internen TCP/UDP-Load-Balancer als nächsten Hop mit einer einzelnen NIC verwenden

Wie im vorherigen Anwendungsfall sind die Back-End-VMs virtuelle Appliance-Instanzen (z. B. Firewallinstanzen oder NAT-Gateways) mit NICs in mehreren VPC-Netzwerken.

Die folgenden Beispiele zeigen zwei Gruppen von virtuellen Back-End-Appliances in zwei verwalteten VM-Instanzengruppen.

Die Back-Ends werden wie folgt zusammengefasst.

Instanzen mit Load-Balancing für testing-to-production-Traffic Instanzen mit Load-Balancing für production-to-testing-Traffic
fw-instance-a
fw-instance-b
fw-instance-c
fw-instance-d
fw-instance-e
fw-instance-f

In der Richtung testing zu production stammt der Traffic aus dem VPC-Netzwerk testing. Im Netzwerk testing hat der interne TCP/UDP-Load-Balancer eine Weiterleitungsregel namens fr-ilb1. In diesem Beispiel werden interne TCP/UDP-Load-Balancer mit Back-End-Diensten verwendet, die keinen angegebenen network-Parameter haben. Das bedeutet, dass jeder Load-Balancer den Traffic nur auf die primäre Netzwerkschnittstelle jeder Back-End-VM verteilt.

Traffic mit Single-NIC-Load-Balancing (<code>testing</code>-to-<code>production</code>) (zum Vergrößern klicken)
Traffic mit Single-NIC-Load-Balancing (testing zu production) (zum Vergrößern klicken)

In der Richtung production zu testing stammt der Traffic aus dem VPC-Netzwerk production. Im production-Netzwerk verfügt ein anderer interner TCP/UDP-Load-Balancer über eine Weiterleitungsregel namens fr-ilb2. In diesem Beispiel werden interne TCP/UDP-Load-Balancer mit Back-End-Diensten verwendet, die keinen angegebenen Parameter network haben. Das bedeutet, dass jeder Load-Balancer den Traffic nur auf die primäre Netzwerkschnittstelle jeder Back-End-VM verteilt. Da jede virtuelle Appliance nur ein nic0 haben kann, erfordert diese Bereitstellung eine zweite Gruppe von virtuellen Appliances: die erste für testing-to-production-Load-Balancing und die zweite für production-to-testing-Load-Balancing.

Traffic mit Single-NIC-Load-Balancing (<code>production</code>-to-<code>testing</code>) (zum Vergrößern klicken)
Traffic mit Single-NIC-Load-Balancing (production zu testing) (zum Vergrößern klicken)

Nächste Schritte