LoadBalancerBlog.de

Wer liest schon gerne Handbücher… Ich persönlich möchte immer sofort auspacken, anfassen, loslegen, und erste Erfolge sehen. Damit das auch mit dem neuen Load Balancer zuverlässig gelingt, hier drei einfache Beispiele:

• Load Balancing für Webserver
• Load Balancing mit SSL-Offloading (SSL Beschleunigung) für SSL-Webserver
• und Load Balancing für Windows Terminal Server.

All das kann man natürlich auch jederzeit mit einem kostenlosen Load Balancer unter VMware / Hyper-V ausprobieren.

Ausgangsbasis für diese Beispiele ist ein betriebsbereiter LoadMaster. Wer zunächst seinen LoadMaster unter VMware o.ä. zum Laufen bringen muss, dem sei vorab der Kochbuch-Artikel zur VLM-Einrichtung empfohlen.

Load Balancing für Webserver

Los geht’s mit dem Klick auf “Add New” unter “Virtual Services”. Dort wird nun die gewünschte IP-Adresse des neuen Dienstes (Virtual Service) eingegeben. Diese muss in einem IP-Netz liegen, in dem auch ein LoadMaster-Interface liegt!

Beispiel:

• Mein Test-LoadMaster hat auf eth0 die IP 192.168.69.251 (sprich über dieser Adresse manage ich ihn. Bei HA-Paaren wäre dies die shared IP), Netzmaske ist 255.255.255.0 (also /24), und eth1 ist nicht konfiguriert.
• Also müssen auch meine VIrtual Service-IPs 192.168.69.x heißen. Im Beispiel: 192.168.69.100

Ausblick: Virtuelle Services können auch auf eth1 usw. liegen. Und auch Alias-Adressen sind auf den LoadMaster-Interfaces möglich. D.h. mehr als ein Netz kann für Virtuelle Services verwendet werden.

Es erscheint nun die Konfiguration des neuen Virtuellen Service.

Dort bitte die folgenden Änderungen vornehmen:

• “L7 Transparency” ausschalten (Ausblick: vgl. Blog-Artikel zu Transparenz)
• Persistenz umstellen auf “Active Cookie or Source IP”, was im Normalfall meine Lieblingseinstellung ist.
• Persistenz-Timeout auf 1 Stunde hochsetzen (Persistenz-Netzmaske darf auf /32 bleiben, hat nichts mit dem lokalen IP-Subnetz zu tun!)
• Scheduling auf “Weighted Least Connections” setzen – auch dies ist meine Standardempfehlung.

Nun geben wir dem Service einen Namen, damit es später schön übersichtlich bleibt:

Nächster Schritt: Wir ordnen den oder die Webserver (“Real Server”) zu diesem Virtuellen Service zu:

Wie man sieht, muss hier der Webserver (“Real Server”) ebenfalls in einem lokalen Netz des Load Balancers stehen. (Ausblick: Das muss lässt sich für Sonderfälle auch anders einrichten…)

Nun wird das gleiche für alle weiteren Webserver wiederholt:

Fertig? Dann zurück in den Virtual Service per “Back”:

…wo nun alle angelegten Real Server aufgelistet sind:

Zur Kontrolle nun bitte links auf “View/Modify” klicken. Es erscheint die Übersicht aller Virtual Services, im praktischen Betrieb eine der wichtigsten Ansichten überhaupt.

In meinem Beispiel-Setup habe ich übrigens einen Real Server eingetragen, der momentan nicht aktiv ist. Prompt wird er als “rot” angezeigt, während der Virtual Service nun alle Anfragen zum anderen Real Server schicken würde – und damit weiterhin “grün” ist. So soll es natürlich sein!

Die korrekte Funktion zeigt sich, wenn ich nun per Browser auf die IP meines Virtual Service zugreife:

Load Balancing mit SSL Offloading für SSL-Webserver

Als nächstes wollen wir nun unsere vorhandenen Webserver per HTTPS (also über SSL) veröffentlichen – genauer: Die Webserver sollen bleiben wie sie sind, aber der Load Master soll sie nach außen mit SSL präsentieren (was gleichzeitig zu sog. SSL-Beschleunigung, “SSL Acceleration”, führt.)

Also los: Wir legen wie gehabt einen neuen Virtuellen Service an, ruhig mit der gleichen IP wie zuvor, aber diesmal auf dem HTTPS-Port 443.

Die Basiskonfiguration nehmen wir wie gehabt vor (geben aber natürlich einen anderen “Nickname”). Anschließen bitte bei “SSL Acceleration” den Kasten für “Enabled” ankreuzen!

Es erscheint der Hinweis, dass nun zunächst automatisch ein selbstsigniertes SSL-Zertifikat erzeugt und verwendet wird. Dieses kann dann später durch ein “offizielles” Zertifikat (von Verisign, Thawte & Co.) ersetzt werden.

Nach Bestätigung sieht der Abschnitt mit den SSL-Eigenschaften nun so aus:

Nun noch die Real Server eintragen, und zwar GENAU wie im vorangegangenen Abschnit – also auf Port 80, denn unsere echten Webserver wissen ja in diesem Beispiel gar nichts von SSL.

War das schon alles? Ja!

Bleibt nur noch die Funktion zu testen per Zugriff auf den neuen Service (https:// nicht vergessen!) – es erscheint nun natürlich eine Warnung des Browsers, weil wir kein “offizielles” SSL-Zertifikat installiert haben:

…was also erwartet ist. Und nach Bestätigung dieser Warnung wird tatsächlich unsere Website unter HTTPS angezeigt:

Ausblick: Zur Praxis von SSL Beschleunigung (auch SSL Offloading, SSL Acceleration gennant) bitte weiterlesen in diesem Artikel zu SSL Offloading.

Load Balancing für Windows Terminal Server

Im letzten Abschnitt bewegen wir uns nun weg vom Webserver, und schauen uns das Thema Load Balancing für Terminal Servicer an, also für das Remote Desktop Protokol (RPD).

Wir werden schnell sehen, dass sich nun das meiste wiederholt…

Beginnen wir also wieder mit dem “Add new”, womit sonst. Was man vorab wissen muss: RDP läuft auf TCP-Port 3389.

Auch hier erkennt der LoadMaster, um welches Protokoll es sich handelt, und nimmt einige Voreinstellungen vor. Alles andere ist schon bekannt…

Allerdings habe ich hier mal einen höheren “Persistence Timeout” angenommen, was für Terminal Server Sinn machen dürfte.

Ausblick: Statt “Weighted Least Connections” ist gerade für Terminal Server KEMP’s “Adaptive Balancing” (oder “Ressource Based Balancing”) besonders gut geeignet – siehe Blog-Artikel zu Ressource Based Load Balancing.

Nun nach die Real Server eintragen – auf dem richtigen Port:

…und das war’s auch schon wieder!

Wie immer zum Abschluss die Funktion überprüfen, in diesem Falle mit einem Remote Desktop Client der Wahl.

Ausblick: Technische Details finden sich auf der KEMP-Dokumentations-Website (http://www.kemptechnologies.com/documentation/) im Load Balancing Microsoft Terminal Services Guide.

Nächste Schritte

Schauen wir nun abschließend noch einmal auf die Liste der Virtual Services, die wir angelegt haben:

Wie angekündigt haben wir nur wenige Beispiele herausgegriffen, es gibt natürlich hunderte mehr (genauer gesagt: beliebig viele). Und es gibt viel Anwender, die tatsächliche hunderte Virtuelle Services auf dem gleichen LoadMaster betreiben, dann natürlich oft überwiegend vom gleichen Typ (z.B. 50 SSL-Websites parallel.)
Zum Load Balancing der  verschiedenen Anwendungen, von Exchange 2010 bis Sharepoint, von DNS bis MySQL, von Citrix bis SAP, …) finden sich hier wie auch anderenorts im Web diverse Hinweise und Tipps; generell aber sind die Fragen und Antworten wiederkehrend und lassen sich mit ein wenig Grundverständnis nach kurzer Zeit selbst erschließen.
Und ein wenig Blättern in den KEMP Handbüchern kann auch nicht schaden ;-)

Das gleiche gilt für Applikations-unabhängige Themen wie Topologie, Transparenz, Persistenz, Monitoring, Datensicherung und vieles mehr.

Und dann gibt es immer auch ausgefallenere Aspekte und Neuigkeiten, von denen es demnächst an dieser Stelle wieder zu lesen gibt.

Der nächste “Kochbuch”-Artikel aber wird sich mit dem Thema “Feintuning des LoadMasters” beschäftigen, als Checkliste mit den 10 wichtigsten Punkten, die man beachten sollte!

Anleitung erstellt auf Basis von LoadMaster Firmware Version 5.1-45