Höchstverbindungen

Verwenden Sie die Konfigurationseinstellung für max connections zum Begrenzen der maximalen Anzahl gleichzeitig bestehender Verbindungen für einen bestimmten virtuellen Front-End-Port. Falls Sie keinen Wert konfigurieren, verwendet das System als Standardwert 2000 gleichzeitige Verbindungen. Die maximale Anzahl gleichzeitiger Verbindungen für einen bestimmten virtuellen Front-End-Port oder systemweit für alle virtuellen Front-End-Ports beträgt 15000.

Sitzungsbindung

Standardmäßig leitet eine ALB Anforderungen an einen Back-End-Server gemäß der konfigurierten Lastausgleichsmethode weiter. Sie können die Sitzungsstabilität aktivieren, um sicherzustellen, dass ein Client während einer Sitzung mit demselben Back-End-Server verbunden bleibt. Weitere Informationen finden Sie unter Aktualisieren der Sitzungshaftung für Anwendungslastverteiler.

HTTP offen halten

HTTP keep alive ermöglicht es einem HTTP Client und einem Server, mehrere Anfrage-Antwort-Paare über eine einzige TCP Verbindung auszutauschen. Dies reduziert die Latenz für nachfolgende Anfragen, minimiert den Netzwerk-Overhead und verbessert die Gesamteffizienz.

Application Load Balancer for VPC unterstützt HTTP keep alive, wenn es sowohl auf dem Verbraucher- als auch auf dem Backend-Server aktiviert ist. Wenn der Verbraucher dies unterstützt HTTP keep alive, hält der ALB die Verbindung für mehrere Anfragen offen. Die ALB versucht, serverseitige HTTP-Verbindungen zu Backend-Servern wiederzuverwenden, um den Verbindungsaufwand zu minimieren.

HTTP keep alive muss sowohl auf der Kunden- als auch auf der Backend-Serverseite der Verbindung aktiviert sein.

TCP offen halten

TCP keep alive ist ein Mechanismus auf der Transportschicht ( TCP ), der die Aufrechterhaltung langlebiger, nicht aktiver Verbindungen unterstützt, indem er in regelmäßigen Abständen kleine Pakete (so genannte Keep Alive Probes) sendet, um zu prüfen, ob das andere Ende der Verbindung noch erreichbar ist.

Application Load Balancer for VPC unterstützt TCP am Leben erhalten. Bei dieser Einstellung sendet der Load Balancer alle 5 Sekunden TCP keep alive-Pakete an die Verbraucher- und Backend-Server. Nachdem eine Verbindung für eine bestimmte Zeit (die so genannte "Keep Alive"-Zeit, oft eine Voreinstellung von 2 Stunden) nicht genutzt wurde, sendet der TCP Stack eine "Keep Alive"-Sonde. Wenn der Peer antwortet, bleibt die Verbindung bestehen. Wenn nach mehreren Versuchen keine Antwort erfolgt, wird die Verbindung als unterbrochen betrachtet und geschlossen.

TCP keep alive ist ein Paket auf Socket-Ebene ohne Daten, das an den Peer gesendet wird, um ihm mitzuteilen, dass der Host am Leben ist. Als solches wird es nur auf der Netzebene verwendet und nicht auf der Anwendungsebene. Diese Einstellung hilft auch, die Trennung von TCP-Verbindungen durch einen Zwischenproxy oder eine zwischengeschaltete Firewall zu verhindern, die möglicherweise über Richtlinien verfügen, die Verbindungen nach einem bestimmten Inaktivitätszeitraum verwerfen.

Verbindungszeitlimits

Von einer Lastausgleichsfunktion für Anwendungen (ALB) werden die nachfolgend angegebenen Zeitlimitwerte verwendet. Derzeit sind nur die Werte für das clientseitige und das serverseitige Inaktivitätszeitlimit in der folgenden Tabelle anpassungsfähig.

IP-Adresse des End-Clients beibehalten (nur HTTP/HTTPS)

Application Load Balancer for VPC fungiert als Reverse Proxy, der eingehenden Verkehr vom Client beendet. Die Lastausgleichsfunktion stellt unter Verwendung ihrer eigenen IP-Adresse eine separate Verbindung zur Instanz des Back-End-Servers her. Bei HTTP-Verbindungen zu den Back-End-Servern (gegenüber HTTP- oder HTTPS-Verbindungen zu Front-End-Servern) behält die Lastausgleichsfunktion die ursprüngliche IP-Adresse des Clients bei, indem sie in den HTTP-Headereintrag X-Forwarded-For einbezogen wird. Bei TCP-Verbindungen werden die ursprünglichen IP-Informationen des Client nicht beibehalten.

Protokoll des End-Clients beibehalten (nur HTTP/HTTPS)

Eine ALB behält das ursprüngliche Protokoll bei, das vom Client für HTTP- und HTTPS-Front-End-Verbindungen verwendet wird, indem es in den HTTP-Header X-Forwarded-Proto aufgenommen wird. Dies gilt nicht für das TCP-Protokoll, da der Layer-7-Datenverkehr bei Verwendung des TCP-Protokolls nicht von der jeweiligen Lastausgleichsfunktion für Anwendungen (ALB) berücksichtigt wird.

Umsetzung der privaten Lastausgleichsfunktion aktivieren

Die Umsetzung privater Lastausgleichsfunktionen verhindert die Erstellung öffentlicher Lastausgleichsfunktionen. Dadurch wird sichergestellt, dass nur Clients ohne Internetzugriff bzw. Clients aus Ihrer eigenen Netzumgebung auf Ihre Lastausgleichsfunktionen zugreifen können. Wenn diese Option aktiviert ist, wird für Ihr Konto eine Einschränkung festgelegt, um die Erstellung von variablen IP-Adressen auf allen ALBs zu verhindern.

Wenn Sie die Umsetzung privater Lastausgleichsfunktionen implementieren möchten, öffnen Sie einen IBM Support-Fall und weisen Sie darauf hin, dass Sie Änderungen an Ihrem Konto vornehmen müssen, um die Erstellung variabler IP-Adressen zu beschränken. Nachdem die Änderung durch IBM verarbeitet worden ist, können Sie künftig keine öffentlichen Lastausgleichsfunktionen mehr erstellen.

Wenn die Funktion aktiviert ist, gilt die Umsetzung privater Lastausgleichsfunktionen für alle Regionen.

HTTP/2-Unterstützung für Clients, die Verbindungen zu HTTPS-Listenern herstellen

Application Load Balancer for VPC verwendet Application-Layer Protocol Negotiation (ALPN), um mit Clients, die sich mit HTTPS Listenern verbinden, zu verhandeln, und unterstützt sowohl HTTP als auch HTTPS Protokolle.

Das Protokoll HTTP/2 wird für Back-End-Pools noch nicht unterstützt. Allerdings werden die Protokolle HTTP und HTTPS unterstützt.

Komprimierung (nur HTTP/HTTPS)

Mit der HTTP/HTTPS-Komprimierung können Sie die Daten, die an Ihre Benutzer übertragen werden, mithilfe von gzip komprimieren.

Um übertragene Daten mit einer ALB zu komprimieren, muss der Anforderungsheader Accept-Encoding: gzip enthalten und der MIME-Typ muss text/html, text/plain oder text/xml sein.

Proxy-Protokoll aktivieren

Sie können das Proxy-Protokoll für TCP-, HTTP- und HTTPS-Listener sowie für Back-End-Pools aktivieren. Im Folgenden finden Sie Informationen zu den entsprechenden Anwendungsfällen:

Anwendungsfall 1: Client stellt eine direkte Verbindung zur Lastausgleichsfunktion her

Wenn die Lastausgleichsfunktion für Anwendungen (ALB) direkt von einem Client Datenverkehr empfängt, wird die Lastausgleichsfunktion durch die Aktivierung des Proxy-Protokolls für den Back-End-Pool so konfiguriert, dass sie den Proxy-Protokoll-Header an die an den betreffenden Back-End-Pool gesendeten TCP-Pakete anhängt.

Alle Back-End-Member des betreffenden Pools müssen das Proxy-Protokoll unterstützen, damit der Datenpfad ordnungsgemäß verwendet werden kann. Beim Aktivieren dieser Einstellung können Sie die Version des Proxy-Protokoll-Headers (Version 1 oder Version 2) auswählen. Die Einstellung ist standardmäßig inaktiviert, wenn sie nicht angegeben ist. Mithilfe dieser Einstellung können die Back-End-Server die Client-IP- und -Portinformationen abrufen, die von der Lastausgleichsfunktion im Proxy-Protokoll-Header festgelegt werden.

Anwendungsfall 2: Client stellt eine Verbindung zu einem Proxy oder einer Proxy-Verkettung her, der bzw. die daraufhin unter Verwendung des Proxy-Protokolls eine Verbindung zur Lastausgleichsfunktion herstellt

Wenn die Application Load Balancer for VPC (ALB) Datenverkehr von einem Proxy (oder einer Proxy-Verkettung) empfängt, der (bzw. die) das Proxy-Protokoll verwendet, muss beim Listener das Proxy-Protokoll aktiviert sein, damit die in den Proxy-Protokoll-Headern enthaltenen Informationen zum Ursprungsclient geparst werden können. Diese Einstellung ist standardmäßig inaktiviert, sofern sie nicht angegeben ist. Da die Lastausgleichsfunktion die Version des Proxy-Protokoll-Headers erkennen und korrekt parsen kann, ist eine Angabe der Version des für den Datenverkehr an die ALB verwendeten Proxy-Protokolls nicht erforderlich.

Bei der Aktivierung des Proxy-Protokolls für einen Front-End-Listener wird beim gesamten Datenverkehr, der an diesem Front-End-Port eingeht, vorausgesetzt, dass es sich um Proxy-Protokoll-Datenverkehr handelt. Weist eine der Verbindungen nicht die richtigen Proxy-Protokoll-Header auf, wird die Verbindung nicht eingerichtet. Wenn die Clientinformationen an den Back-End-Server-Pool weitergeleitet werden sollen, müssen Sie das Proxy-Protokoll für den Pool aktivieren. Wie auch bei Anwendungsfall 1 müssen Sie Version 1 oder Version 2 auswählen, je nach der Version des Proxy-Protokolls, für die die Back-End-Server konfiguriert sind. Sie können auch entscheiden, dass diese Clientinformationen nicht an die Back-End-Server weitergeleitet werden sollen, wenn die Server nicht für die Verarbeitung dieser Informationen eingerichtet sind. In diesem Falls werden diese Informationen bei der Lastausgleichsfunktion gelöscht.