LoadBalancerBlog.de

Nach einigen ziemlich technischen Themen möchte ich heute mal wieder einen Schritt zurücktreten und mich ganz grundsätzlich der Frage zuwenden: Wie kann ich Load Balancer für  meine (Web-, oder auch sonstige!) Anwendung nutzen? Und was sind die Kriterien für ein gutes Produkt?

Genau genommen ist die Frage natürlich falsch gestellt, in der Praxis gilt es ja ein vorhandenes Problem zu lösen (und nicht: Ein passendes Problem für ein vorhandenes Werkzeug zu finden…) – also etwa so:

1. “Wie kann ich meine Anwendung gegen Serverausfall schützen?” oder
2. “Wie kann ich meine Anwendung auf mehreren Servern gleichzeitig laufen lassen, um die Performance zu verbessern?”

(weiterlesen …)

Das das Web sich zunehmend weg von reiner Präsentation und hin zur Interaktion entwickelt (hat), ist eine Binsenweisheit. Und dass dabei Security – etwa zum Schutz persönlicher Daten oder natürlich von Zahlungsdaten – eine wichtige Rolle spielt, ebenfalls. Das Mittel der Wahl in solchen Fällen ist der Einsatz von HTTPS (also HTTP über SSL / TLS).

Im einfachsten Fall werden Websites mit solchen Sicherheitsanforderungen komplett unter HTTPS betrieben. Was aber, wenn ein Mischbetrieb gewünscht ist? Wenn zum Beispiel nur der Anmelde- oder Bezahlvorgang in einem  Shop geschützt werden soll, während all die anderen Zugriffe (z.B. Produktrecherche, aber auch das “In den Warenkorb legen”), die vermutlich 90% aller Zugriffe ausmachen, eigentlich problemlos über HTTP gehen könnten? (weiterlesen …)

Eines der ganz grundlegenden und doch immer wieder verwirrenden Konzepte im Loadbalancing ist die Unterscheidung in transparenten und nicht-transparenten Datenverkehr. Dabei geht es um die IP-Absenderadresse von Anfragen, die von außen zum Load Balancer und von diesem zum Real Server geschickt werden.

• Kommt diese unverändert beim Real Server an, spricht man von Transparenz (oder auch “Source IP Transparency“.)
• Kommt stattdessen die Adresse des Load Balancers als Absender beim Real Server an, ist die Konfiguration nicht-transparent.

Nun gibt es für beide Betriebsarten gewichtige Gründe – sowie einen “Mittelweg”, der für viele Anwender die beste Lösung ist. All dies soll hier erklärt werden. (weiterlesen …)

Zur Lastverteilung – also “Zu welchem Real Server soll die nächste neue Anfrage geschickt werden?” – gibt es verschiedene Algorithmen, nach denen ein Load Balancer entscheiden könnte. Der KEMP LoadMaster bietet hier eine große Auswahl – z.B. “Der Server mit den wenigsten bestehenden Verbindungen!” u.v.m., und dies optional kombiniert mit Gewichtungsfaktoren.

Prinzipiell jedoch kann die Entscheidungsfindung des Load Balancers immer nur auf Faktoren beruhen, die dieser auch kennt – also nicht auf Werten wie z.B. Performancewerten des Real Servers oder anderen Umgebungsfaktoren. Es sei denn, solche Werte werden dem Load Balancer zur Verfügung gestellt!

Diesen leistungsfähigen Ansatz nennt KEMP “Adaptive Load Balancing“. (weiterlesen …)

S-NAT ist die Kurzform von “Source NAT”, also Umsetzung der IP-Absenderadresse. In diesem Kontext geht es dabei aber nicht um Anfragen, die auf einem Virtuellen Service ankommen und deren Absender auf dem Weg zum Real Server entweder belassen wird (“Transparenz”) oder verändert wird (“nicht transparent”). Vielmehr bestimmt dieser Parameter, wie Anfragen zu behandeln sind, die vom Real Server selbst geschickt werden – so etwa für DNS-Anfragen, zum Email-Versand, oder beim Download von Patches. (weiterlesen …)

Dem Load Balancer die SSL/TLS Entschlüsselung von HTTPS-Verbindungen zum Browser zu überlassen, ist weit verbreitete Standardpraxis (vgl. mein Blogartikel zu SSL Beschleunigung). Was aber, wenn auch die Strecke zwischen Load Balancer und Real Server durch SSL geschützt werden soll? (weiterlesen …)