Sticky sessions, Persistence auf Load Balancer
Ich bin im Begriff einen Load Balancer vor mehrere Anwendungsserver (nenn wir sie A, B, C) zu stellen. Wenn nun ein Client einen HTTPS-Request auf Server B macht und in Folge noch mehrere Requests in dieser Session macht, sollen seine Requests immer auf Server B gehen.
Jetzt bieten die verschiedenen Load Balancer mehrere Optionen um sticky sessions zu ermöglichen:
Source IP address: geht nicht, wegen NAT
SSL Session ID: geht nicht, weil ab IE 5 und mittlerweile Firefox die SSL Session ID alle paar Minuten ändern
Cookies: geht nicht, weil ja die Requests verschlüsselt sind
Die meisten Load Balancer bieten Hardware SSL Beschleuniger. Kann man dadurch trotzdem Cookie-basierte Verfahren verwenden? Bzw. gibt es noch andere Möglichkeiten um Persistenz sicherzustellen? Cookies sind ja im allgemeinen nicht so angenehm...
Hat jemand von euch Erfahrung mit Load Balancern? Empfehlungen?
Greets
Jetzt bieten die verschiedenen Load Balancer mehrere Optionen um sticky sessions zu ermöglichen:
Source IP address: geht nicht, wegen NAT
SSL Session ID: geht nicht, weil ab IE 5 und mittlerweile Firefox die SSL Session ID alle paar Minuten ändern
Cookies: geht nicht, weil ja die Requests verschlüsselt sind
Die meisten Load Balancer bieten Hardware SSL Beschleuniger. Kann man dadurch trotzdem Cookie-basierte Verfahren verwenden? Bzw. gibt es noch andere Möglichkeiten um Persistenz sicherzustellen? Cookies sind ja im allgemeinen nicht so angenehm...
Hat jemand von euch Erfahrung mit Load Balancern? Empfehlungen?
Greets
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 106140
Url: https://administrator.de/forum/sticky-sessions-persistence-auf-load-balancer-106140.html
Ausgedruckt am: 26.04.2025 um 07:04 Uhr
6 Kommentare
Neuester Kommentar
Der Load Balancer führt eine Session Tabelle wenn du NAT machen musst was man normalerweise nicht muss.
Sticky sessions funktionieren somit immer ebenso wie Cookies und das natürlich auch wenn du SSL Beschleunigung aktiv hast und auch Adress Translation machst auf dem LB.
Jedenfalls ist das so bei Produkten von F5 und Foundry Networks.
Damit ist dein Problem ohne Hindernisse mit solcher Hardware lösbar !
Ist ja auch so zigtausendfach im Einsatz bei Banken und anderen die sicherheitsrelevante Server betreiben..also nix Neues und ein alter Hut !
Sticky sessions funktionieren somit immer ebenso wie Cookies und das natürlich auch wenn du SSL Beschleunigung aktiv hast und auch Adress Translation machst auf dem LB.
Jedenfalls ist das so bei Produkten von F5 und Foundry Networks.
Damit ist dein Problem ohne Hindernisse mit solcher Hardware lösbar !
Ist ja auch so zigtausendfach im Einsatz bei Banken und anderen die sicherheitsrelevante Server betreiben..also nix Neues und ein alter Hut !
Das heisst, um cookies werd ich nicht herum kommen? Source IP funktioniert nicht, wegen NAT und Proxy Servern - man kann die IP nicht zuverlässig einem User zuordnen.
Natürlich gibt es solche Lösungen zb bei Banken - verwenden die auch Cookies oder gibt es zuverlässige Cookie-freie Lösungen? Beim Online-Dienst meiner Bank muss ich zb Cookies aktivieren...
Natürlich gibt es solche Lösungen zb bei Banken - verwenden die auch Cookies oder gibt es zuverlässige Cookie-freie Lösungen? Beim Online-Dienst meiner Bank muss ich zb Cookies aktivieren...
Nein zu 80% werden sticky Sessions benutzt. Das bedeutet dann aber das HTTPS User nicht mehr pro Session gebalanced werden sondern auf einem Server verbleiben.
Ist aber nicht weiter schlimm, denn die Verteilung ist trotzdem recht homogen.
Nur wenn man partout nicht mit Sticky arbeiten will, dann bleibt dir nur das Cookie Switching...
Sticky ist aber meist das Verfahren der Wahl bei SSL...
Ist aber nicht weiter schlimm, denn die Verteilung ist trotzdem recht homogen.
Nur wenn man partout nicht mit Sticky arbeiten will, dann bleibt dir nur das Cookie Switching...
Sticky ist aber meist das Verfahren der Wahl bei SSL...
Hm, verstehe ich da jetzt was falsch? Sticky session ist ein Verfahren? Ich dachte, sticky session wird durch Verfahren wie cookie switching realisiert!?
Wie wird das gewährleistet? Der Load Balancer muss doch jeden Request (vor allem den "ersten") einem Benutzer zuordnen können.
Zitat von @aqui:
... Das bedeutet dann aber das
HTTPS User nicht mehr pro Session gebalanced werden sondern auf einem
Server verbleiben....
... Das bedeutet dann aber das
HTTPS User nicht mehr pro Session gebalanced werden sondern auf einem
Server verbleiben....
Wie wird das gewährleistet? Der Load Balancer muss doch jeden Request (vor allem den "ersten") einem Benutzer zuordnen können.
Richtig ! Sticky und Cookie sind definitiv zwei unterschiedliche Verfahren (Jedenfalls bei F5 und Foundrys Server Iron).
Bei Sticky merkt sich der Balancer den User anhand einer IP und weist einer Session immer einen festen Server zu.
Bei Cookies passiert das auf Basis der Cookies eben also pro Endgerät.
Beides sind 2 unterschiedliche Verfahren, wie gesagt !!!
Bei Sticky merkt sich der Balancer den User anhand einer IP und weist einer Session immer einen festen Server zu.
Bei Cookies passiert das auf Basis der Cookies eben also pro Endgerät.
Beides sind 2 unterschiedliche Verfahren, wie gesagt !!!
OK, ich verstehe. Das ist also wahrscheinlich Definitionssache...
Hast du mit Geräten von Foundry Networks bzw F5 Erfahrung, d.h. hast du diese schon verwendet? Funktioniert Persistenz mit dem IP-Verfahren zuverlässig?
Hast du mit Geräten von Foundry Networks bzw F5 Erfahrung, d.h. hast du diese schon verwendet? Funktioniert Persistenz mit dem IP-Verfahren zuverlässig?
