Warum gibt es keine Beispiele für horizontal skalierbare Software-Load-Balancer, die SSL ausgleichen?

Ich habe eine Reihe von Fragen zu SSL, lokalen Sitzungen und Lastausgleich, die miteinander verbunden zu sein scheinen. Daher entschuldige ich mich im Voraus für die Länge dieser Frage.

Ich habe eine Website, die dateibasierte Sitzungen verwendet. Die Art der Website ist, dass das meiste davon http ist, aber einige Abschnitte sind ssl. Derzeit ist es aufgrund der dateibasierten Sitzungen erforderlich, dass alle SSL-Anforderungen denselben Server wie alle vorherigen http-Anforderungen erreichen.

Aus Zeitgründen möchte ich das einfachste tun, um den erhöhten http- und ssl-Verkehr auszugleichen.

Es scheint zwei Optionen für Algorithmen zum Ausgleich von Haftlasten zu geben:

• IP-basiert
• Cookie-basiert

Die IP-basierte Lösung wird wahrscheinlich funktionieren, aber der Hashing-Algorithmus ändert möglicherweise den Server, zu dem ein Benutzer wechselt, wenn ein Server ausfällt oder hinzugefügt wird, was beim aktuellen dateibasierten Sitzungsaufbau unerwünscht ist. Ich nehme auch an, dass es einem Benutzer technisch möglich ist, die IP-Adresse beim Surfen auf einer Website zu ändern.

Der Cookie-basierte Algorithmus scheint besser zu sein, aber die Unfähigkeit, das Cookie zu überprüfen, wenn es von ssl verschlüsselt wird, bringt anscheinend seine eigenen Probleme mit sich.

Ich habe nach Beispielen für den Lastausgleich von SSL gegoogelt, und ich kann anscheinend keine expliziten Beispiele für Setups finden, die einen Cookie-basierten Lastausgleich durchführen UND die durch Hinzufügen eines weiteren SSL-Decoders mit erhöhter SSL-Last umgehen können.

Bei den meisten expliziten Beispielen, die ich gesehen habe, befindet sich der SSL-Decoder (normalerweise Hardware, Apache_mod_ssl oder Nginx) zwischen dem Browser-Client und dem Load Balancer. Die Beispiele scheinen normalerweise so etwas zu haben (geändert von http://haproxy.1wt.eu/download/1.3/doc/architecture.txt ):

      192.168.1.1 192.168.1.11-192.168.1.14
 ------- + ----------- + ----- + ----- + ----- +
        | | | | |       
     + - + - + + - + - + + - + - + + - + - + - + - + - +    
     | LB1 | | A | | B | | C | | D |    
     + ----- + + --- + + --- + + --- + + --- +    
     Apache 4 billige Webserver
     mod_ssl
     Haproxy 

Der SSL-Decodierungsteil im obigen Beispiel scheint ein potenzieller Engpass zu sein, der nicht horizontal skalierbar ist.

Ich habe mir Haproxy angesehen und es scheint eine 'mode tcp'-Option zu geben, die so etwas zulässt, dass Sie mehrere SSL-Decoder haben können:

              Haproxy
                 |
            -------------
            | |
ssl-decoder-1 ssl-decoder2
            | |
        -------------------
        | | |  
      web1 web2 web3

In einem solchen Setup scheint es jedoch, dass Sie die Client-IP verlieren würden, da Haproxy die SSL nicht dekodiert: https://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -zum

Ich habe mir auch Nginx angesehen und sehe auch keine expliziten Beispiele für horizontal skalierbare SSL-Decoder. Es scheint viele Beispiele für Menschen zu geben, die Nginx als potenziellen Engpass haben. Und zumindest scheint dieser Link darauf hinzudeuten, dass nginx nicht einmal die Option des haproxy-ähnlichen Setups hat, bei dem Sie die IP verlieren würden, indem Sie sagen, dass nginx "das transparente Übergeben von TCP-Verbindungen an ein Backend nicht unterstützt". So übergeben Sie Apache SSL-Verkehr durch Nginx-Proxy? .

Fragen:

• Warum scheint es nicht mehr Beispiele für Setups zu geben, die mehr SSL-Decoder hinzufügen, um mit erhöhtem Datenverkehr fertig zu werden?
• Liegt es daran, dass der SSL-Decodierungsschritt nur ein theoretischer Engpass ist und praktisch ein Decoder im Wesentlichen ausreicht, außer für Websites mit lächerlichem Datenverkehr?
• Eine andere mögliche Lösung, die in den Sinn kommt, ist vielleicht, dass jeder mit solch erhöhten SSL-Anforderungen auch einen zentralen Sitzungsspeicher hat, sodass es keine Rolle spielt, auf welchen Webserver der Client bei sequentiellen Anforderungen trifft. Dann können Sie mod_ssl oder ein gleichwertiges Element auf jedem Webserver aktivieren.
• Die oben genannte Haproxy-Lösung scheint zu funktionieren (neben dem Client-IP-Problem), aber jemand ist auf eine auf Cookies basierende Software-Load-Balancer-Lösung gestoßen, die funktioniert, indem die Anzahl der Decoder erhöht wird, während die Client-IP beibehalten wird, oder ist dies möglicherweise technisch nicht der Fall möglich (weil Sie die Anforderung dekodieren müssen, um die Client-IP zu erhalten. In diesem Fall liegt ein Decoder-Engpass vor).

Unter der Annahme, dass alles, was ich gesagt habe, wahr ist, scheinen dies meine Optionen zu sein:

• Verwenden Sie IP-Hashing (schlecht für Benutzer, die möglicherweise IPs legitim ändern, und für Server, die Szenarien hinzufügen und löschen).
• Verwenden Sie nginx oder mod_ssl als erstes Programm, das die SSL-Anforderung berührt. Dies ist ein potenzieller SSL-Dekodierungsengpass
• Verwenden Sie Haproxy als erstes Programm, das die SSL-Anforderung berührt, um eine horizontale SSL-Skalierbarkeit zu erreichen.
• Wechseln Sie langfristig zu einem mobilen oder zentralen Sitzungsspeicher, sodass keine klebrigen Sitzungen erforderlich sind

Das "Einfachste" ist im Ernst, in einen zentralen Sitzungsspeicher zu wechseln. Sie müssen all diese Installationen mit Load Balancern, Haproxy, SSL und dem Rest davon einrichten, wenn es mit jedem Code für die Sitzungsbehandlung, den ich je gesehen habe, nahezu trivial ist, verschiedene Speicher-Engines anzuschließen Ein bisschen Code und sehr, sehr wenig zusätzliche Komplexität lösen alle Ihre Probleme.

womble hat Recht mit dem Shared Session Store, der die Dinge rundum viel einfacher macht. Zusätzlich zu seiner Antwort kann ich die Lastausgleichsteile der Frage etwas näher erläutern:

Warum scheint es nicht mehr Beispiele für Setups zu geben, die mehr SSL-Decoder hinzufügen, um mit erhöhtem Datenverkehr fertig zu werden?

Moderne Multi-Core-PCs können mehrere tausend SSL-Transaktionen pro Sekunde ausführen. Und wenn dies zu einem Engpass wird, kann eine dedizierte Appliance von F5 , Citrix, Cisco oder dergleichen noch schneller sein. Daher wachsen die meisten Websites nie aus einer guten SSL- und Lastausgleichslösung für einzelne Geräte heraus.

Unter der Annahme, dass alles, was ich gesagt habe, wahr ist, scheinen dies meine Optionen zu sein:

Es gibt Optionen zum horizontalen Skalieren der SSL-Entschlüsselung, falls dies erforderlich sein sollte.

Der übliche Ansatz besteht darin, DNS Round Robin für hochverfügbare SSL-Beschleunigerpaare zu verwenden, dh mehrere IP-Adressen für die Domäne zu veröffentlichen, wobei jede IP-Adresse auf ein Paar SSL-Beschleuniger verweist.

In diesem Fall können Sie sich Sorgen machen, dass das DNS-TTL-Timing während einer Benutzersitzung abläuft und der Benutzer auf einen anderen Anwendungsserver gestoßen wird. Das sollte nicht alltäglich sein, aber es könnte passieren. Ein gemeinsam genutzter Sitzungsspeicher ist die übliche Lösung, kann jedoch auf andere Weise behandelt werden.

Als ein Beispiel könnten Sie die SSL-Entschlüsselung vom Anwendungsserverausgleich trennen. Die SSL-Verarbeitung ist CPU-intensiver als der grundlegende Lastausgleich. Daher sollte ein einzelner Lastausgleich in der Lage sein, einige SSL-Beschleuniger zu sättigen. So was:

Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers

Wie eingangs erwähnt, vereinfacht ein gemeinsam genutzter Sitzungsspeicher viele Dinge und ist mit ziemlicher Sicherheit eine bessere langfristige Lösung, als Ihre SSL- / Lastausgleichsschicht mit viel Komplexität zu versehen.

Es macht Spaß, auf 2 Jahre alte Fragen wie diese zu antworten, wenn sich Produkte weiterentwickelt haben. Derzeit unterstützt haproxy das PROXY-Protokoll, mit dem die IP des Clients auch im reinen TCP-Modus an den nächsten Hop übergeben werden kann. Es unterstützt auch natives SSL sowie SSL-Klebrigkeit, wenn Sie es als erste Schicht vor einer SSL-Farm (möglicherweise aus Haproxy-Servern) verwenden möchten. Es scheint also, dass Ihre Anfrage etwas früher war und dass die Implementierungen aufgeholt haben :-)

Ich stimme Womble und Jesper hier zu. Der einfachste / beste Weg ist, den Code zu korrigieren. Natürlich haben wir als Systemadministratoren diese Option oft nicht, aber selbst in diesem Fall gibt es genug Tricks, mit denen Sie relativ billige moderne Hardware weit genug skalieren können, auch wenn sie nicht wirklich horizontal ist.

Ich wollte nur posten, um zu kommentieren, wo Sie über den Verlust der Client-IP besorgt sind. In jeder der wichtigsten L7 / Proxy-Lösungen können Sie einen X-Forwarded-For-Header (oder was auch immer Sie möchten) in die Anforderung einfügen. Anschließend können Sie auf dem Backend-Webserver, der die Anforderung empfängt, das Protokolldateiformat ändern, um diesen Wert an derselben Stelle in der Datei zu protokollieren, die zum Protokollieren der Layer3-Client-IP verwendet wurde. Auf diese Weise erkennt jede Protokollanalyse-Software den Unterschied nicht (und Sie auch nicht beim Tailing).

Es gibt Kompromisse bei allem und wir haben nicht genug über Ihr Setup gehört, um es zu wissen, aber mit dem Trio aus Ha-Proxy, Nginx und Lack, das Sie nicht falsch machen können, ist es wahrscheinlich eine gute Idee, Ihren Lastausgleich zu verschieben zu einem Proxy-Layer-Tool. Das wird Ihr SSL-Problem lösen und Ihnen eine Vielzahl neuer Optionen wie Caching, Inhaltsumschaltung und Header-Manipulation bieten.

Einige zufällige Gedanken;)

Erschießen Sie zunächst die Person, die sich für die Verwendung dateibasierter Sitzungsdaten entschieden hat. Das Lesen / Schreiben von Daten aus einem Dateisystem ist auf keinen Fall schneller als das Zurückkehren zur Quelle, um die benötigten Daten abzurufen. Hier geht es um die SCHLECHTESTE Vorgehensweise.

Ich persönlich habe noch nie eine Situation gesehen, in der das Speichern von Daten in einer Sitzung besser war, als sie bei Bedarf direkt aus der Datenbank abzurufen. Trotzdem habe ich gesehen, wo die Verwendung von Memcache oder ähnlichen Caching-Strategien dazu beitragen kann, eine Site auf Millionen von Benutzern zu skalieren, aber das ist nicht einmal im gleichen Bereich wie die Verwendung von Sitzungen.

Zweitens haben Sie gerade den Hauptgrund gefunden, Sitzungen überhaupt nicht zu verwenden: Lastausgleich. Zu Ihrer Information - Sticky bedeutet nicht Stuck. Selbst wenn Sticky-Sitzungen aktiviert sind, besteht die sehr reale Möglichkeit, dass der Benutzer während der Verwendung Ihrer App auf einen anderen Server verschoben wird. Dies wird zu den ungünstigsten Zeiten geschehen. Sticky bedeutet nur, dass der Load Balancer versucht , den Benutzer auf den Server zurückzuschieben, auf dem er gestartet wurde. Dies ist jedoch keine Garantie.

Dieser Punkt führt normalerweise dazu, dass Benutzer die Sitzung wieder in der Datenbank speichern ... Was meiner Meinung nach ein völliger Fehler ist . Damit die Sitzung funktioniert, muss sie auf jeder Seitenanforderung geladen und geschrieben werden. Wenn es in einer Datenbank gespeichert ist (erforderlich für Server mit Lastenausgleich), sind zwei Serverabfragen erforderlich: die erste zum Abrufen der Daten und die zweite zum Schreiben von Aktualisierungen.

Der Fehler besteht darin, dass Benutzer normalerweise Sitzungen verwenden, damit sie nicht zur Datenbank zurückkehren müssen, um Dinge wie den Benutzernamen abzurufen. Wenn die Seite jedoch die Datenbank abfragen muss, um eine Sitzung zu laden, dann ... nun, Sie sollten in der Lage sein, das logische Problem hier zu sehen.

Nur ist es bei Sitzungen schlimmer ... weil der Seitenprozessor die Sitzungsdaten am Ende des Seitenlebenszyklus zurück in die Datenbank schreiben muss, falls sich etwas ändert. Dies bedeutet, dass Sie anstelle der einen Abfrage zum Abrufen des Benutzernamens zwei erhalten. Für jede einzelne Seitenladung. Darüber hinaus bedeutet dies, dass die Daten serialisiert und deserialisiert werden, was sich auf die Leistung auswirkt.

Mein Punkt ist: Sitzung ist böse und Sie sind normalerweise besser dran ohne sie. Websites mit geringem Datenverkehr, die nur auf einem Webserver ausgeführt werden, benötigen nicht die Leistungssteigerung, die auftreten kann. Websites mit hohem Datenverkehr, die in einer Webfarm ausgeführt werden, sind aufgrund dieser Skalierung nur begrenzt skalierbar.

Anstatt Haproxy auf der Vorderseite zu verwenden, können Sie Round-Robin-DNS verwenden, um einen Grobausgleich zwischen mehreren SSL-Decodern durchzuführen, und diesen dann für den richtigen Lastausgleich an Haproxy übergeben.