Informationen zu Lastausgleichsfunktionen für Anwendungen

Verwenden Sie IBM Cloud® Application Load Balancer for VPC (ALB), um Datenverkehr auf mehrere Serverinstanzen in derselben Region einer VPC-Instanz zu verteilen.

Wenn Sie öffentliche und private Workloads und Layer-7-Datenverkehr haben, verwenden Sie eine Lastausgleichsfunktion für Anwendungen.

Typen von Lastausgleichsfunktionen für Anwendungen

Wie in der Übersicht über Lastausgleichsfunktionen für VPC erläutert, können Sie eine öffentliche oder private ALB erstellen.

Diese Tabelle zeigt einen Vergleich der öffentlichen und privaten Funktionen.

Vergleich von öffentlichen und privaten Load Balancern
Feature Öffentliche Lastausgleichsfunktion Private Lastausgleichsfunktion
Im Internet zugänglich? Ja, mit einem vollständig qualifizierten Domänennamen (FQDN) Nein, nur interne Clients in derselben Region und VPC
Gesamter Datenverkehr zulässig? Ja Ja
(Die Einschränkung, nur Datenverkehr aus dem Adressraum RFC-1918 zu akzeptieren, wurde aufgehoben.)
Wie wird der Domainname registriert? Öffentliche IP-Adressen Private IP-Adressen

Öffentliche Lastausgleichsfunktion für Anwendungen

Einer öffentlichen Load-Balancer-Instanz wird ein öffentlich zugänglicher vollqualifizierter Domänenname (FQDN) zugewiesen, den Sie verwenden müssen, um auf Ihre Anwendungen zuzugreifen, die hinter dem Load Balancer gehostet werden. Dieser Domänenname kann mit einer oder mehreren öffentlichen IP-Adressen registriert werden.

Die Anzahl und der Wert für diese öffentlichen IP-Adressen können im Laufe der Zeit durch Wartungs- oder Skalierungsvorgänge geändert werden. Die virtuellen Backend-Serverinstanzen, auf denen Ihre Anwendung gehostet wird, müssen in derselben Region und unter derselben VPC ausgeführt werden.

Verwenden Sie den zugeordneten FQDN, um Datenverkehr an die öffentliche Lastausgleichsfunktion für Anwendungen zu senden und Konnektivitätsprobleme für Ihre Anwendungen bei Systemwartungs- und Scale-down-Vorgängen zu vermeiden.

Private Lastausgleichsfunktion für Anwendungen

Eine private Lastausgleichsfunktion für Anwendungen ist über Ihre privaten Teilnetze zugänglich, die Sie zur Erstellung der Lastausgleichsfunktion konfiguriert haben.

Ähnlich wie bei einem öffentlichen Anwendungs-Load-Balancer wird Ihrer privaten Anwendungs-Load-Balancer-Instanz ein FDQN zugewiesen. Für diesen Domänennamen wird jedoch mindestens eine private IP-Adresse registriert.

Durch IBM Cloud-Operationen können Anzahl und Wert der zugeordneten privaten IP-Adressen im Laufe der Zeit aufgrund von Wartungs- oder Skalierungsvorgängen geändert werden. Die virtuellen Backend-Serverinstanzen, auf denen Ihre Anwendung gehostet wird, müssen in derselben Region und unter derselben VPC ausgeführt werden.

Verwenden Sie den zugeordneten FQDN, um Datenverkehr an die private Lastausgleichsfunktion für Anwendungen zu senden und Konnektivitätsprobleme für Ihre Anwendungen bei Systemwartungs- und Scale-down-Vorgängen zu vermeiden.

Lastausgleichsmethoden

Zum Verteilen des Datenverkehrs auf die Back-End-Anwendungsserver stehen die folgenden drei Methoden für den Lastausgleich zur Verfügung:

Umlaufverfahren

Das Umlaufverfahren ist die Standardmethode beim Lastausgleich. Bei Verwendung dieser Methode leitet eine Lastausgleichsfunktion für Anwendungen eingehende Clientverbindungen im Umlaufverfahren an die Back-End-Server weiter. Als Ergebnis erhalten alle Back-End-Server in etwa die gleiche Anzahl von Clientverbindungen.

Gewichtetes Umlaufverfahren

Bei diesem Verfahren leitet ein Anwendungs-Load-Balancer eingehende Client-Verbindungen proportional zu der Gewichtung, die diesen Servern zugewiesen wurde, an die Backend-Server weiter. Jedem Server wird ein 50 Standardgewicht von zugewiesen. Das Gewicht kann auf jeden Wert im Bereich 0- angepasst 100 werden.

Beispiel: Wenn den Anwendungsservern A, B und C die Gewichtungen 60, 60 und 30 zugeordnet sind, erhalten Server A und B gleich viele Verbindungen, während der Server C nur halb so viele Verbindungen erhält.

Die Gewichtung 0 bewirkt, dass keine neuen Verbindungen an den betreffenden Server weitergeleitet werden. Der vorhandene Datenverkehr wird jedoch weiterhin übertragen. Mit der Gewichtung 0 kann ein Server allmählich heruntergefahren und aus dem turnusmäßigen Servicebetrieb entfernt werden.

Die Gewichtungswerte der Server werden nur im gewichteten Umlaufverfahren angewendet. Sie werden beim einfachen Umlaufverfahren und bei Lastausgleichsmethoden, die Server mit den wenigsten Verbindungen zuerst berücksichtigen, ignoriert.

Wenigste Verbindungen

Bei diesem Verfahren erhält die Backend-Serverinstanz, die zu einem bestimmten Zeitpunkt die geringste Anzahl an Verbindungen bedient, die nächste Client-Verbindung.

Front-End-Listener und Back-End-Pools

Front-End-Listener sind Anwendungsports für Lastausgleichsfunktionen, mit denen eingehende Anforderungen empfangen werden, während Back-End-Pools die Anwendungsserver hinter den Lastausgleichsfunktionen sind.

Richtlinien zur Verwendung von Listenern

Lesen Sie die folgenden Richtlinien für Front-End-Listener:

  • Sie können bis zu 10 Front-End-Listener definieren und diese den Back-End-Pools auf Ihren Back-End-Anwendungsservern zuordnen.
  • Der zugeordnete, vollständig qualifizierte Domänenname (FQDN) für Ihre Lastausgleichsfunktion und die zugeordneten Front-End-Listener-Ports sind im öffentlichen Internet zugänglich. Eingehende Benutzeranforderungen werden über diese Ports empfangen.
  • Der unterstützte Protokolle für Front-End-Listener und Back-End-Pools sind HTTP, HTTPS und TCP.
  • Sie können einen HTTP/HTTPS-Front-End-Listener mit einem HTTP/HTTPS-Back-End-Pool konfigurieren.
  • HTTP/2 wird nur für Zuhörer unterstützt.
  • HTTP- und HTTPS-Listener und -Pools sind austauschbar.
  • Sie können nur einen Front-End-Listener vom Typ TCP mit einem Back-End-Pool vom Typ TCP konfigurieren.
  • Sie können einem Back-End-Pool bis zu 50 Virtual Server-Instanzen zuordnen. Der Datenverkehr für jede Instanz wird an den angegebenen Datenport gesendet. Dieser Datenport muss nicht identisch mit dem Front-End-Listener-Port sein.
  • Nur privat-Endpunkte für Secrets Manager werden von HTTPS-Listenern nicht unterstützt. Wenn Sie einen HTTPS-Listener in einer ALB konfigurieren möchten, müssen Sie Ihre TLS-Zertifikate auf einen öffentlichen und privaten Endpunkt hochladen.

HTTPS-Umleitungslistener

HTTPS-Umleitungslistener leiten den Datenverkehr von einem HTTP-Listener an einen HTTPS-Listener um. Für diese Aktion müssen keine Regeln auf den Listener angewendet werden.

Wenn beispielsweise ein Dienst auf Port 443 unter HTTPS erreichbar ist und ein Benutzer versucht, über HTTP auf den Dienst auf Port 80 zuzugreifen, wird die Anfrage automatisch auf Port 443 unter HTTPS umgeleitet.

Wenn Richtlinien für den HTTPS-Umleitungslistener vorhanden sind, werden die Richtlinien zunächst ausgewertet. Wenn keine übereinstimmenden Richtlinien vorhanden sind, wird die Anfrage an einen konfigurierten HTTPS-Listener weitergeleitet.

Eigenschaften des HTTPS-Umleitungslisteners

Eigenschaften des HTTPS-Umleitungslisteners
Eigenschaft Beschreibung
Empfangsprogramm Der HTTPS-Listener, an den eine Anforderung umgeleitet wird.
HTTP-Statuscode Der Statuscode der vom Anwendungs-Load-Balancer zurückgegebenen Antwort. Zulässige Werte: 301, 302, 303, 307 und 308.
URI Der relative URI, an den eine Anforderung umgeleitet wird. Die Angabe dieser Eigenschaft ist optional.

Ausfallsicherheitsrichtlinien für Backend-Pools

Wenn Sie einen Backend-Pool in einem Load Balancer bearbeiten, können Sie eine der folgenden ausfallsicheren Richtlinienaktionen angeben:

  • Weiterleiten: Der Load Balancer leitet Anfragen an einen bestimmten Backup-Pool weiter. Dies bietet einen sauberen Failover-Pfad zu einem anderen Satz von Anwendungsservern. Sie müssen einen bestehenden Backup-Pool konfiguriert und bereit haben, Datenverkehr zu empfangen.
  • Verwerfen: Der Load Balancer verwirft alle eingehenden Anfragen, und der Client erhält keine Antwort.
  • Fehlschlag: Der Load Balancer lehnt Anfragen mit dem Statuscode HTTP 503 ("Service Unavailable") ab und teilt dem Kunden mit, dass der Dienst vorübergehend nicht verfügbar ist.

Sie können ein ausfallsicheres Ziel aus einer Liste geeigneter Sicherungspools auswählen.

Anforderungen an den ausfallsicheren Zielpool (wenn die Aktion Vorwärts ist):

  • müssen zum selben Load Balancer gehören
  • müssen das gleiche oder ein kompatibles Protokoll haben ( TCP ist nur mit TCP kompatibel, aber jede Kombination von HTTP und HTTPS ist kompatibel)

Nur bei Application Load Balancern ist es möglich, mehr als einen Pool mit einem einzigen Listener zu verknüpfen. Stellen Sie sicher, dass mindestens ein Pool bereits im Load Balancer vorhanden ist.

In einer Load-Balancer-Konfiguration wird ein Listener als übergeordnete Ressource betrachtet. Sie können Pools auf zwei Arten mit diesem Hörer verknüpfen, indem Sie sie direkt oder indirekt referenzieren. Für eine direkte Zuordnung konfigurieren Sie den Pool als default_pool des Hörers. Für eine indirekte Verbindung referenzieren Sie den Pool von einem anderen Pool über eine failsafe_policy.target Beziehung, wobei Sie sicherstellen, dass der andere Pool bereits mit dem Hörer verbunden ist.

Elastizität

Die Lastausgleichsfunktion für Anwendungen wird durch Hinzufügen von Rechenressourcen skaliert, wenn die Arbeitslast zunimmt.

SSL-Auslagerung und erforderliche Berechtigungen

Durch die Secure Sockets Layer ( SSL )-Auslagerung kann der Anwendungs-Load-Balancer alle eingehenden HTTPS-Verbindungen beenden.

Ist ein HTTPS-Listener mit einem HTTP-Pool konfiguriert, wird die HTTPS-Anforderung an der Front-End-Instanz beendet und die Lastausgleichsfunktion richtet eine HTTP-Kommunikation in Klartext mit der Back-End-Serverinstanz ein. Durch diese Vorgehensweise werden CPU-intensive SSL-Handshakes sowie Ver- und Entschlüsselungstasks aus den Back-End-Serverinstanzen ausgelagert, d. h. alle CPU-Zyklen dieser Tasks können für die Verarbeitung des Anwendungsdatenverkehrs genutzt werden.

Die SSL-Auslagerung setzt voraus, dass Sie ein SSL-Zertifikat für die Lastausgleichsfunktion für Anwendungen bereitstellen, über die SSL-Auslagerungstasks ausgeführt werden sollen. Die SSL-Zertifikate können Sie mit IBM Cloud Secrets Manager verwalten.

Sie können eine Berechtigung über „ IAM-Berechtigungen “ erstellen. Wählen Sie unbedingt VPC-Infrastrukturdienste als Quelldienst, und wählen Sie dann Spezifische Ressourcen. Klicken Wählen Sie ein Attribut aus und wähle Ressourcentyp von der Liste. Wählen Sie „ Load Balancer für VPC “ als Ressourcentyp aus und klicken Sie auf „ Weiter “. Wählen Sie für den Target-Dienst Secrets Manager. Stellen Sie den Zugriff auf die Ziel-Service-Instanz auf „Alle Instanzen“ oder auf Ihre spezifische „ IBM Cloud Secrets Manager “-Instanz ein. Ordnen Sie die Servicezugriffsrolle Schreibberechtigter zu. Weitere Informationen finden Sie im Abschnitt zum Erteilen von Zugriff zwischen Services.

Um Fehler zu vermeiden, müssen Sie die erforderliche Berechtigung zwischen Ihrer Lastausgleichsfunktion und IBM Cloud Secrets Manager einrichten. Darüber hinaus werden Ihre ALB nicht automatisch aktualisiert, wenn Sie Zertifikate in „ Secrets Manager “ aktualisieren. Damit Ihr Load Balancer alle Änderungen im Zertifikat berücksichtigt, nehmen Sie eine kleine Aktualisierung vor (z. B. Änderung des Intervalls für die Zustandsprüfung oder des Timeout-Werts), um eine Aktualisierung zu veranlassen. Durch diese Aktion wird das Zertifikat auf Ihrem Load Balancer aktualisiert, sodass es mit dem Zertifikat in „ Secrets Manager “ übereinstimmt. Anschließend können Sie alle Änderungen, die Sie vorgenommen haben, auf ihre ursprünglichen Werte zurücksetzen.

Transport Layer Security (TLS) 1.2 und 1.3 werden unterstützt. Standardmäßig wird jedoch TLS 1.3 verwendet, es sei denn, Sie konfigurieren die Client-Seite ausdrücklich so, dass 1.2 verwendet wird. Application Load Balancer akzeptieren alle unterstützten TLS 1.3 Chiffren, die von der clientseitigen Anfrage gesendet werden.

Im Folgenden werden die unterstützten Cipher-Suites nach Priorität geordnet aufgelistet:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Zertifikats-CRN suchen

Wenn Sie während der Bereitstellung in der Konsole die Authentifizierung für einen Anwendungs-Load-Balancer konfigurieren, können Sie wählen, ob Sie die Zertifikate Secrets Manager und SSL oder die CRN des Zertifikats angeben möchten. Dies kann sinnvoll sein, wenn Sie Secrets Manager nicht im Dropdown-Menü sehen können, was bedeutet, dass Sie keinen Zugriff auf die Secrets Manager-Instanz haben. Beachten Sie, dass Sie die CRN eingeben müssen, wenn Sie die API zum Erstellen eines ALB verwenden.

Um die CRN zu erhalten, benötigen Sie Zugriffsrechte auf die Secrets Manager-Instanz.

Führen Sie die folgenden Schritte aus, um nach dem CRN eines Zertifikats zu suchen:

  1. Gehen Sie in der zu IBM Cloud Konsole Navigationsmenü-Symbol Navigationsmenü-Symbol > Ressourcenliste.
  2. Klicken Sie auf Sicherheit, um den Bereich zu erweitern, und wählen Sie dann den Secrets Manager aus, für den Sie die CRN ermitteln möchten.
  3. Wählen Sie eine beliebige Stelle in der Tabellenzeile des Zertifikats aus, um die Seitenanzeige mit den Zertifikatdetails zu öffnen. Die CRN des Zertifikats ist aufgeführt.

End-to-End-Verschlüsselung mit SSL

Durch die Konfiguration eines HTTPS-Listeners mit einem HTTPS-Pool wird eine End-to-End-Verschlüsselung mit SSL ermöglicht. Der ALB beendet die eingehende Anfrage HTTPS am Front-End-Listener und baut eine HTTPS-Verbindung zu den Back-End-Instanzen auf. Durch die End-to-End-Verschlüsselung wird der gesamte Datenverkehr, der über den Load Balancer zu den Backend-Knoten geleitet wird, über HTTPS verschlüsselt.

Konfigurieren Sie die End-to-End-Verschlüsselung mit SSL wie folgt:

  1. Konfigurieren Sie einen Front-End-Listener für HTTPS mit Ihrem SSL-Zertifikat, so wie Sie es bei der Konfiguration der Auslagerung von SSL tun würden.
  2. Konfigurieren Sie einen HTTPS-Back-End-Pool.
  3. Fügen Sie Ihre Back-End-Mitgliedsinstanz zum HTTPS-Back-End-Pool hinzu. Stellen Sie sicher, dass Ihre Backend-Instanzen so konfiguriert sind, dass sie den Datenverkehr von HTTPS verarbeiten können.
  4. Konfigurieren Sie den Statusprüfungstyp als HTTPS, damit verschlüsselte Statusprüfungen mit Ihren Back-End-Poolmitgliedern durchgeführt werden.

Die SSL-Zertifikate für die Back-End-Mitgliedsinstanzen werden von einer Lastausgleichsfunktion für Anwendungen nicht überprüft.

Horizontale Skalierung

Die Kapazität einer Lastausgleichsfunktion für Anwendungen wird automatisch an die Arbeitslast angepasst. Bei dieser Anpassung wird möglicherweise die Anzahl der zugeordneten IP-Adressen für den DNS-Namen der Lastausgleichsfunktion geändert.

MZR-Unterstützung

IBM Cloud Application Load Balancer for VPC unterstützt Regionen mit mehreren Zonen (Multi-Zone-Regions, MZRs). Hochverfügbarkeit und Redundanz können Sie durch die Bereitstellung einer Lastausgleichsfunktion für Anwendungen in Teilnetzen verschiedener Zonen erreichen. Wenn Teilnetze aus mehreren Zonen zur Bereitstellung einer Lastausgleichsfunktion verwendet werden, werden die Appliances der Lastausgleichsfunktion in mehreren Zonen bereitgestellt.

Integration mit Instanzgruppen

In IBM Cloud Application Load Balancer for VPC können Instanzgruppen integriert werden, von denen Back-End-Mitglieder auto scale werden können. Poolmitglieder werden abhängig von der Nutzung und den Anforderungen dynamisch hinzugefügt und gelöscht.

Weiterleitung von Datenpfadprotokollen

Wenn die Datapath-Protokollierung aktiviert ist, werden die Protokolle des Lastenausgleichs an den Dienst IBM Cloud Logs weitergeleitet, wo Sie Ihre Datapath-Protokolle einsehen können.

HTTP2-Unterstützung

Application Load Balancer unterstützen den End-to-End-Verkehr HTTP2 und arbeiten mit Listener-Protokollen, die entweder als HTTPS oder TCP eingestellt sind.

Unterstützung für WebSocket

WebSocket bietet Vollduplex-Kommunikationskanäle über eine einzige Verbindung TCP. Application Load Balancer unterstützen WebSocket mit jeder Art von Listener-Protokoll ( HTTP / HTTPS / TCP ).

Hochverfügbarkeits- und Anwendungslastenausgleich

Um sicherzustellen, dass High Availability (HA) mit Ihrem ALB funktioniert, fügen Sie drei Subnetze aus verschiedenen Zonen zum ALB hinzu und stellen Sie Appliances in diesen Zonen bereit. Dazu wählen Sie zunächst Ihre Subnetze während des ALB-Erstellungsprozesses aus. Sie können zwei Subnetze in verschiedenen Zonen auswählen (z. B. us-south-1 und us-south-2). Dadurch werden die IP-Adressen des ALB (z. B. die IP-Adressen der Appliance) in zwei verschiedenen Subnetzen erstellt.

Sie können dies auch mit bereits vorhandenen ALBs tun. Gehen Sie zum Abschnitt Attached Resources auf der Detailseite Ihres Load Balancers. Klicken Sie im Abschnitt Subnetz auf Subnetze bearbeiten. Fügen Sie dann weitere Subnetze hinzu. Der ALB wechselt in den Status "Migrating". Wenn die Migration abgeschlossen ist, erhalten Sie eine neue IP für die Appliance aus dem Subnetz, das Sie gerade hinzugefügt haben. Sie haben nun zwei IP-Adressen aus unterschiedlichen Subnetzen in unterschiedlichen Zonen.