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. Sie können einen internen TCP/UDP-Load-Balancer als nächsten Hop verwenden, an den 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.

Bevor Sie die Informationen auf dieser Seite durchgehen, sollten Sie bereits mit den Konzepten aus der Routenübersicht vertraut sein

Ein interner TCP/UDP-Load-Balancer als nächster Hop 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.

Sie können eine benutzerdefinierte statische Route erstellen, um Traffic an einen internen TCP/UDP-Load-Balancer zu übergeben, wobei der Load-Balancer der nächste Hop der statischen Route ist. 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 Traffic an allen Ports an die Back-End-VMs weiter, unabhängig von folgenden Bedingungen:

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

Der interne TCP/UDP-Load-Balancer, der als nächster Hop der Route dient, unterstützt die nahtlose Weiterleitung des gesamten Traffics für Protokolle, die von Google Cloud-VPC-Netzwerken unterstützt werden (z. B. TCP, UDP und ICMP).

Weitere Überlegungen

  • Netzwerk-Tags werden nicht unterstützt. 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.

  • Wenn alle Back-Ends fehlerhaft sind. Wenn alle Back-Ends eines internen TCP/UDP-Load-Balancers bei Systemdiagnosen fehlschlagen, sind die Routen, die diesen nächsten Hop verwenden, noch aktiv. Von der Route verarbeitete Pakete werden gemäß der Trafficverteilung an eines der Back-Ends des nächsten Hop-Load-Balancers gesendet.

  • Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden (--purpose=SHARED_LOADBALANCER_VIP), werden nicht unterstützt. Ein interner TCP/UDP-Load-Balancer mit nächstem Hop und interne Weiterleitungsregeln des TCP/UDP-Load-Balancers mit einer gemeinsamen IP-Adresse schließen sich gegenseitig aus. Der interne TCP/UDP-Load-Balancer mit nächstem Hop muss eine IP-Adresse verwenden, die für die Weiterleitungsregel des Load-Balancers eindeutig ist, damit nur ein Back-End-Dienst (ein Load-Balancer) eindeutig referenziert wird. Es ist möglich, dass Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden, auf verschiedene Back-End-Dienste verweisen (verschiedene interne TCP/UDP-Load-Balancer).

  • Gleiches Ziel und mehrere interne TCP/UDP-Load-Balancer als nächsten Hop Wenn Sie zwei oder mehr benutzerdefinierte statische Routen mit demselben Ziel und unterschiedlichen internen TCP/UDP-Load-Balancern als nächste Hops erstellen, verteilt Google Cloud den Traffic nie unter den Load-Balancern als nächste Hops mit ECMP. Wenn die Routen eindeutige Prioritäten haben, verwendet Google Cloud den internen TCP/UDP-Load-Balancer als nächsten Hop aus der Route mit der höchsten Priorität. Wenn die Routen dieselben Prioritäten haben, wählt Google Cloud trotzdem nur einen internen TCP/UDP-Load-Balancer als nächsten Hop aus. Wie in der folgenden Abbildung dargestellt, verwendet Google Cloud einen deterministischen internen Algorithmus, um eine Weiterleitungsregel als nächsten Hop (forwarding-rule-a) auszuwählen und andere Routen mit derselben Priorität zu ignorieren.

    Gleiches Ziel, unterschiedliche interne TCP/UDP-Load-Balancer als nächste Hops
    Gleiches Ziel, unterschiedliche interne TCP/UDP-Load-Balancer als nächste Hops
  • Mehrere Ziele und derselbe TCP-UDP-Load-Balancer für den nächsten Hop: Sie können denselben internen TCP/UDP-Load-Balancer für den nächsten Hop für mehrere benutzerdefinierte statische Routen verwenden, wenn jede Route eine eindeutige Kombination aus Ziel und Priorität hat. Sie können nicht mehrere benutzerdefinierte statische Routen mit derselben Kombination aus Ziel, Priorität und internem TCP/UDP-Load-Balancer für den nächsten Hop erstellen. Beispielsweise können route-x, route-y und route-z erstellt werden, route-x-copy jedoch nicht.

    Beispielrouten mit einem gemeinsamen internen TCP/UDP-Load-Balancer als nächsten Hop
    Beispielrouten mit einem gemeinsamen internen TCP/UDP-Load-Balancer als nächsten Hop

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