Es gab eine Zeit, in der Dinosaurier die Erde bevölkerten. Die Menschen begannen mit Werkzeugen wie Steinen und DSR-basierten Layer 4-Lastverteilern zu arbeiten.
Damals waren diese Tools nützlich, weil man damit die Server erreichen konnte, und sie waren auch nützlich, weil es einfach war, sicherzustellen, dass dem Anwendungsserver die tatsächliche Client-IP-Adresse präsentiert wurde.
Ein Load Balancer sitzt zwischen dem Client und der Anwendung. Wer ist also, von der Anwendung aus gesehen, der Absender? Der Client (Ja, bitte) oder der Load Balancer?
Das war ziemlich einfach, und Sie hatten einige Möglichkeiten zur Auswahl.
DSR-Modus – Direct Server Return.
- Der Client würde sich mit dem Load Balancer verbinden.
- Der Load Balancer würde sie mit der SourceIP des Clients an die Anwendung senden.
- Die Anwendung würde dann eine Antwort direkt an den Client senden. Sie würde wahrscheinlich feststellen, dass die SourceIP eine externe IP ist, und die Antwort an das Gateway weiterleiten und so den Load Balancer auf der Response überspringen.
Den Dinosauriern gefiel dieser Ansatz, da er weniger Ressourcen in der Infrastruktur beansprucht und die Anwendung die echte Client-IP erhält.
Der Nachteil ist, dass Sie eine spezielle Netzwerkkonfiguration auf dem App-Server UND der großen Enthüllung vornehmen müssen … Der Load Balancer erhält oder sieht die Antwort nicht, so dass jegliche SSL- oder Inhaltsumschaltung nicht möglich ist.
Der andere Nachteil ist, dass der LB keine Ahnung hat, wie gut der App-Server arbeitet, so dass es schwieriger ist, die Last auf Server zu verteilen, die wahrscheinlich leistungsfähiger sind. Der ADC würde die am schnellsten reagierenden oder die am wenigsten Verbindungen nutzen. (Stone Age Man kann einen Agenten auf dem App-Server installieren, der dies meldet.) Oder ein ADC könnte SNMP verwenden, um dies zu erfahren.
Wie auch immer, dieses System hat viele Jahre lang gut funktioniert, wie das Pferd und der Wagen, und in der Tat gibt es immer noch Situationen, in denen dies die beste Option ist, wie z.B. bei Wagenrennen oder einigen älteren Protokollen.
Als nächstes sind wir dran:
Gateway-Modus
- Der Client würde sich mit dem Load Balancer verbinden
- Der Load Balancer würde sie mit der SourceIP des Clients an den App Server senden
- Die Anwendung würde dann eine Antwort direkt an den Client senden, ABER ÜBER den Load Balancer, da Sie das Standard-Gateway des App-Servers in das des Load Balancers geändert haben. Das bedeutet, dass der Load Balancer die Antwort erhält.
Das ist in mancher Hinsicht viel besser, aber der gesamte externe Datenverkehr vom App-Server, wie z.B. Software-Updates, wird über den Load Balancer geleitet, so dass es unübersichtlich wird.
Das war häufiger der Fall, als die Load Balancer noch wie Switches aussahen und alles direkt mit Hochgeschwindigkeits-Cups und String-Netzwerkverbindungen verbunden war.
Mann lernt Farming und proxy-basierten Lastausgleich zu nutzen
Zu dieser Zeit wurden die Netzwerke und die CPU-Geschwindigkeiten immer schneller, und wir begannen, den Proxy-Ansatz zu verwenden.
Wir haben uns entschlossen, den Load Balancer als Quell-IP zu verwenden, anstatt den Anwendungsserver auszutricksen. Wir haben dies aus vielen Gründen getan, u.a. wegen der TCP-Leistung, der Sicherheit und der Möglichkeit, zusätzliche Dienste auf dem Load Balancer anzubieten.
Aber diese Abkehr von der Jagd war mit einem hohen Preis und einer großen Herausforderung verbunden.
Wie senden Sie die Client-IP an den Anwendungsserver?
Glücklicherweise hatte das gute alte HTTP eine großartige Antwort, solange Sie HTTP verwendeten.
X_Forwarded_For Header – ermöglicht es Ihnen, die Client-IP in den Header zu setzen und dann weiterzusenden.
Ich werde dies nicht zu detailliert erklären, da es ziemlich einfach ist, aber es genügt zu sagen, dass es eine Kopfzeile ist, die jeder leicht einstellen kann. Außerdem kann es komplex werden. Was passiert zum Beispiel, wenn dem Load Balancer bereits eine X_Forwareded_For IP gesendet wurde? Soll er diese verwenden oder die Quell-IP verwenden und sie ändern? Normalerweise lassen sich diese Einstellungen auf einem anständigen LB konfigurieren, aber sie haben alle Sicherheitsaspekte usw.
Wie auch immer, in 99% der Fälle, wenn eine Webanwendung den Quellcode benötigt, erhalten sie ihn auf diese Weise (Anmerkung: 99% der Statistiken sind erfunden)
Was ist mit anderen Protokollen?
Einige wenige haben einige protokollspezifische Hacks, aber es gibt nichts Generisches, das weiter verbreitet ist.
Nun, das war so, bis das Proxy-Protokoll vorgeschlagen und weithin angenommen wurde.
Proxy-Protokoll erklärt
Das Proxy-Protokoll löst dieses Problem, indem es der weitergeleiteten Anfrage eine Kopfzeile hinzufügt, die die Verbindungsdaten des ursprünglichen Clients enthält.
Es gibt bereits zwei Versionen dieses Protokolls.
- Proxy-Protokoll v1: Verwendet ein einfaches, von Menschen lesbares Textformat.
- Proxy-Protokoll v2: Verwendet ein Binärformat, das effizienter ist und zusätzliche Funktionen wie IPv6 und Unix-Socket-Adressen unterstützen kann.
Der Unterschied ist, dass die meisten Anwendungsserver nicht mehr funktionieren, wenn Sie diese Funktion aktivieren, ohne sie dafür zu konfigurieren. Das liegt daran, dass das Proxy-Protokoll die erforderlichen Angaben buchstäblich an den Anfang der Daten stellt.
Die Akzeptanz wächst jedoch und viele Anbieter unterstützen dies inzwischen.
Es eignet sich zum Beispiel hervorragend für DNS-Proxys.
Wie bei X_Forwardard_For müssen noch einige Entscheidungen getroffen werden:
Was soll der Load Balancer zum Beispiel tun, wenn Sie einen Proxy-Protokoll-Header vorfinden? Entfernen Sie ihn und setzen Sie einen neuen, oder behalten Sie ihn bei? Wenn Sie nicht erwarten, dass ein solcher Header gesendet wird, sollten Sie ihn ignorieren und sich einen eigenen besorgen, aber diese Entscheidungen müssen berücksichtigt werden.
Das Proxy-Protokoll ist eine einfache Möglichkeit, die Client-IP zu erhalten, und wird inzwischen weitgehend unterstützt, also machen Sie weiter und genießen Sie es.
Ich denke jetzt wieder über Hochverfügbarkeit in der Cloud nach, Ciao!
