Flexibler Load Balancer

Dieses Bild zeigt drei gängige Anwendungsfälle und verdeutlicht, wie Kunden flexible Load Balancer-Module nutzen können. Diese Anwendungsfälle sind:

1. Automatisches Verteilen der Anwendungslast auf die Ressourcen
2. Modernisierung und Schaffung resilienter Anwendungen
3. Verteilung von Anfragen auf der Grundlage von Traffic-Merkmalen

Automatisches Verteilen der Anwendungslast auf die Ressourcen

Im ersten von drei Anwendungsfällen wird ein virtuelles Cloud-Netzwerk gezeigt. Es enthält einen flexiblen Load Balancer, der bidirektional mit zwei virtuellen Maschinen verbunden ist, die sich im selben virtuellen Cloud-Netzwerk befinden.

Der Load Balancer ist bidirektional mit einem externen Benutzer außerhalb des virtuellen Cloud-Netzwerks verbunden.

Vom externen Benutzer gehen Anforderungen an den Lastenausgleich ein, der die Anforderung an jede der virtuellen Maschinen senden kann. Dadurch kann die Anwendung mehr Benutzer unterstützen, als eine einzelne virtuelle Maschine verarbeiten kann.

Modernisierung und Schaffung resilienter Anwendungen

Im zweiten von drei Anwendungsfällen wird ein virtuelles Cloud-Netzwerk gezeigt. Es enthält einen flexiblen Load Balancer. Im selben virtuellen Cloud-Netzwerk befinden sich zwei Gruppen. Wobei jede Gruppe über eine virtuelle Maschine und eine Datenbank verfügt. Diese stellen zwei Instanzen einer älteren, nicht Cloud-nativen Anwendung dar.

Und der Load Balancer ist bidirektional mit jeder Gruppe verbunden.

Von Benutzern gehen Anfragen beim Load Balancer ein, der die Anfrage an eine der Legacy-Anwendungen senden kann. Dadurch kann eine Legacy-Anwendung mehr Benutzer als üblich unterstützen, indem Benutzeranforderungen auf mehrere Instanzen der Legacy-Anwendung verteilt werden.

Verteilung von Anfragen auf der Grundlage von Traffic-Merkmalen

Im dritten von drei Anwendungsfällen wird ein virtuelles Cloud-Netzwerk gezeigt. Es enthält einen flexiblen Load Balancer, der bidirektional mit drei virtuellen Maschinen verbunden ist.

Anfragen werden basierend auf den Werten im HTTP-Header der Anfrage an die erste virtuelle Maschine gesendet.

Anfragen werden basierend auf den Werten im virtuellen Hostnamen der Anfrage an die zweite virtuelle Maschine gesendet.

Anfragen werden basierend auf den Werten in der URL der Anfrage an die dritte virtuelle Maschine gesendet.

Dadurch können Anfragen auf der Grundlage von HTTP-bezogenen Werten in der Anfrage selbst an eine andere Ressource weitergeleitet werden.

Dieses Bild zeigt ein logisches Layout von Ressourcen und Verbindungen in einer typischen flexiblen Load Balancer-Architektur.

Eine OCI-Region wird angezeigt. Innerhalb der Region befinden sich drei separate Availability-Domains mit den Nummern eins, zwei und drei.

Ein virtuelles Cloud-Netzwerk durchquert und umfasst alle drei Availability-Domains. Zum virtuellen Cloud-Netzwerk gehört auch ein Internetgateway, das bidirektional mit dem Internet verbunden ist.

Innerhalb der ersten Availability-Domain befindet sich das erste Subnetz. Es enthält den primären flexiblen Load Balancer.

Innerhalb der zweiten Availability-Domain befindet sich das zweite Subnetz. Es enthält den Failover-Load Balancer.

Zwischen den beiden Availability-Domains und Subnetzen befindet sich ein Listener mit einer öffentlichen IP-Adresse. Der Listener ist bidirektional mit dem Internetgateway verbunden. Und er kann Anfragen aus dem Internet empfangen.

Der Listener ist Teil einer Gruppe, die sowohl den primären als auch den Failover-Load Balancer umfasst. Diese Gruppe fungiert als logischer Load Balancer, der auch dann weiter funktioniert, wenn die primäre Load Balancer-Komponente ausfällt.

Es gibt drei weitere Subnetze, eines in jeder Availability-Domain. Sie sind mit den Nummern drei, vier und fünf versehen. Jedes Subnetz verfügt über Compute-Ressourcen.

Der primäre Load Balancer ist bidirektional mit den Subnetzen drei, vier und fünf verbunden. Der Failover-Load Balancer ist bidirektional mit den Subnetzen drei, vier und fünf verbunden.

Beim Listener gehen Anfragen aus dem Internet ein, die an den primären Load Balancer gesendet werden. Anschließend leitet der Load Balancer die Anforderung basierend auf Gewichtungen oder HTTP-Eigenschaften an eines der Subnetze mit Ressourcen weiter.