Dabei ist es eigentlich ganz einfach - Soll ein Interface für die Überwachung verwendet werden und selbst überwacht werden, so muss dieser Haken gesetzt sein:

Ist dies nicht der Fall, so wird bei Ausfall des Interfaces am aktiven LoadMaster dieser nicht die Kontrolle an seinen Partner übergeben, sondern unbeirrt weiterarbeiten.
Außerdem können die LoadMaster sich nicht mehr gegenseitig sehen, wenn kein “Use for HA check” Interface mehr verfügbar ist – Gefahr der Fehlfunktion (“Split Brain”).

Also, nochmals zusammengefasst:

• Besagten Haken für alle produktiven Interfaces setzen!
• Möglichst mehr als ein Interface  für ”Use for HA check” auswählen!
  (Klassische Ausnahme: Querverbindung zwischen zwei RZ, bei der ohnehin alles VLANs auf der gleichen Physik sind.)

Auf zwei Sonderfälle möchte ich hinweisen:

• Direktes Kabel zwischen den Load Balancern: Eine dedizierte Verbindung macht Sinn, wenn der “interne” Datenverkehr von den Nutzdaten isoliert werden soll. Und wenn die Geräte räumlich nah beieinander sind, geht dies sogar über ein simples Ethernet-Kabel. Allerdings darf  ”Use for HA checks” nicht nur auf diesem Interface aktiviert sein – sonst werden, falls dieses Kabel gezogen wird, beide Load Balancer sich für “blind” bzw. defekt erklären.
• VLANs: VLAN-Interfaces, die auf Ethernet-Interfaces des LoadMasters liegen, müssen nicht gesondert überwacht werden. Es reicht, wenn beim darunter liegenden Ethernet-Interface der Haken gesetzt ist.

Dieses Thema habe ich übrigens auch aufgenommen in das “Kochbuch”: 10 Schritte zum Fein-Tuning des LoadMasters.

Dabei ist die Abhilfe doch so einfach, um nicht zu sagen: Ein einziger Knopfdruck im LoadMaster!

Und zwar ist offensichtlich das Ziel, Anfragen von HTTP (Port 80) umzuleiten auf HTTPS (Port 443). Dies kann der LoadMaster von Haus aus, und macht es dem Admin wirklich leicht:

• Gehen Sie in den Virtuellen Service für HTTPS, dort in die “Advanced Properties”
• Klicken Sie auf “Add a Port 80 Redirector VS”
• Fertig!

Anschließend sehen Sie dann in “View/Modify Virtual Services” einen neuen Service, der keine Real Server besitzt und deswegen immer den Status “Redirect” (gelb) hat. Und dadurch genau das tut was wir wollen.

Troubleshooting:

1. Ich sehe die ”Add a Port 80 Redirector VS” Option nicht
   - Sind wir überhaupt in einem HTTPS (Port 443) – Service?
   - Service Type HTTP/HTTPS gesetzt?
   - Gibt es schon einen Service auf dieser IP mit Port 80?
   - Fall SSL Acceleration ausgeschaltet: Ggf. Firmware-Update nötig.
2. Redirector eingetragen und Gelb, aber die Umleitung funktioniert nicht
   - Blockt eine vorgeschaltete Firewall TCP Port 80?

Wie aber funktioniert die 2-armige Variante? Ganz einfach: Genauso, mit den folgenden zwei kleinen Modifikationen.

Schauen wir uns zunächst nochmal die Grundidee an…

Im 1-Armed Setup sind die Server auf dem gleichen Interface (und in aller Regel im gleichen Subnetz) wie der gehörige Virtuelle Service:

1-Armed Setup des LoadMaster

Im Gegensatz dazu sind beim 2-Armed Setup die Server in einem anderen Subnetz:

2-Armed Setup des LoadMaster

(An dieser Stelle sei erwähnt: Natürlich kann man auch komplexere Topologien abbilden, siehe hierzu mein Text zu Netzwerk-Topologie Beispielen für Exchange 2010.)

Was ist nun also zu tun, um ein zweiarmiges Setup  verwenden anstelle des im “Kochbuch” beschriebenen einarmigen? Folgende Schritte:

• Richte ein weiteres Interface auf jedem LoadMaster ein (eth1), inklusive zugehöriger “Shared IP”.
  In der Zeichnung wären dies: 192.168.1.1 und 192.168.1.2 (sowie 192.168.1.254 als Shared IP.)
• Achtung: Die Netzwerkinterfaces des LoadMaster müssen nicht nur in unterschiedlichen Subnetzen sein, sondern dürfen auch nicht im selben Ethernet (sprich: Switch / VLAN) stecken!
• Platziere die Server in ebendiesem Subnetz und verwende dabei die neue Shared IP als Default Gateway.

Fertig – Nun können diese Server als “Real Server” in den gewünschten Virtuellen Services verwendet werden! Und das nennt man dann 2-Armed Setup.

Mischbetrieb (manche Real Server 1-Armed, manche 2-Armed) ist übrigens möglich, aber nicht unbedingt empfehlenswert, wenn man die Dinge einfach und übersichtlich halten will.

Abschließend noch die Frage:

Was ist besser, 1-Armed oder 2-Armed?

Tja… schwer zu  beantworten – wichtig ist eigentlich nur, beides zu können. Denn in der Praxis kommen immer wieder Situationen vor, die einfach die eine oder andere Variante  zwingend erfordert.

Wenn ich “auf der grünen Wiese” die Wahl habe, würde ich allerdings eher zum 2-Armed Setup tendieren, aus folgenden Gründen:

• Übersichtlicheres Setup, einfacherer Betrieb und Fehlersuche,
• Keine Routing-Probleme bei transparentem Betriebsmodus des Virtuellen Service,
• Verteilung der Last auf mehrere Interfaces, d.h. mehr Kapazitätsreserven.

Das Ergebnis deckt sich mit meiner eigenen Einschätzung: KEMP bietet eine einzigartige Kombination aus leistungsfähigem Produkt und hochattraktivem Preis – und wurde in der Studie daher zum “Value Leader” erklärt.

Das Ergebnis auf einen Blick stellt EMA als Diagramm dar:

Load Balancing Hersteller im Vergleich: EMA Radar Studie 2011

Im Text der EMA-Studie (Enterprise Management Associates, www.enterprisemanagement.com) finden sich dann natürlich viele ausführlichere Aussagen zu den Kandidaten und auch zur Methodik. So etwa über den KEMP LoadMaster:

The price point is ideal for small and medium-size businesses as well as larger organization at the departmental or division level with their own discretionary IT budget to purchase a device. What is most notable is KEMP’s ability to pack as many features as they have into their LM family of products, given the price points at which they sell.

Bingo! Gut auf den Punkt gebracht. Auch den Teil “larger organizations” kann ich tatsächlich genau so bestätigen: In Banken und anderen Großunternehmen ist der LoadMaster heute noch nicht unbedingt im Kernrechenzentrum zu finden, wohl aber in allen möglichen anderen Teilbereichen wie Exchange 2010, Lync, oder für Webauftritte in Internet und Intranet.

Neben dem Thema “Große Leistung zu kleinen Kosten” gab es zudem noch weiteres Lob:

Als besonderer Pluspunkt des LoadMasters wird die überragende Einfachheit der Bedienung (“Ease of Use”) hervorgehoben, siehe zweite Abbildung.

KEMP gewinnt auch "Ease of Use" (Quelle: EMA)

Die 15-seitige Zusammenfassung des Report gibt es auf der EMA-Website als kostenfreies PDF zum Download (kostenlose Registrierung bei EMA erforderlich).

Außerdem wird das Ganze nochmal sehr schön im zugehörigen Webcast erläutert. Empfehlung!

Zitat und abgebildete Folie:
(c)2011 Enterprise Management Associates.

1. Virtual Service – Einrichtung
2. SNAT
3. Stateful Failover
4. Virtual MAC
5. Eindeutige HA-Kennung
6. LoadMaster als Router
7. Schnelles Umschalten bei Serverausfall
8. Nachlaufzeit bei Deaktivierung (“Drain Stopping”)
9. Logging auf externen Syslog-Server
10. Backup
11. [ Nachtrag: Eigene Interfaces überwachen ]

Bevor wir aber mit Nr. 1 starten, vielleicht vorab noch eine “Nummer 0″:

0. Aktualität der Firmware sicherstellen

…denn das kann auch schon manches spätere Problem vermeiden. Die aktuell freigegebene Version findet sich hier (zu beziehen wie immer vom KEMP Support.)

1. Virtual Service – Einrichtung

Hier geht es um Details im Virtual Service – diese Einstellungen sind also für jeden Dienst gesondert vorzunehmen bzw. zu prüfen.

a) Transparenz an!

Wenn möglich, sollten Services besser mit aktivierter “Transparency” laufen. Dies aber hat zwingende Voraussetzungen:

• Default Gateway der Real Server ist der LoadMaster (genauer: deren Shared IP)
• Keine Clients im gleichen Subnetz wie ein Real Server

(Siehe auch Blogartikel zu Transparenz)

Anmerkungen: L4-Dienste laufen automatisch immer transparent. Bestimmte Konstellationen (SSL Reencryption, Nested Virtual Serivces) unterbinden Transparenz per se.

b) Hochwertige Funktionsüberwachung!

• Wählen Sie eine repräsentative (aber die Server nicht zu sehr belastende) URL aus
• Falls Sie namensbasierte virtuelle Hosts im Webserver betreiben, müssen Sie ggf. den zu überwachenden Servernamen angeben. Dazu “HTTP 1.1″ aktivieren!

c) Durchdachte Persistenz-Werte

(Was das ist? Grundlagen zu Persistenz kann man hier nachlesen.)

• Wählen Sie eine großzügige Persistenzdauer (“Timeout”)! Am besten gleich oder größer der Session-Lebenszeit in der Anwendung – da diese aber oft nicht bekannt oder stabil ist, empfehle ich i.d.R. 30 Minuten oder mehr zu wählen (wenn Sie nicht gerade hunderttausende Benutzer auf dem System haben…)
• Falls Sie “Active Cookie” verwenden: Wählen Sie einen Namen, der keinesfalls auch anderer Stelle verwendet wird!
• Wenn die Persistenz-Regel Ihrer Wahl auch in “Or Source IP”-Variante verfügbar ist – verwenden Sie diese. Dies bedeutet, dass der LoadMaster immer noch einen Fallback hat, wenn das eigentliche Persistenzkriterium nicht verfügbar ist (z.B. keine Cookieunterstützung im Browser)

d) Sinnvolles Verteilverfahren wählen!

Keine Ahnung was zu nehmen ist? “Weighted Least Connections” passt eigentlich immer…

2. SNAT

SNAT ist ausschließlich dann sinnvoll, wenn die angebundenen Server selbst Verbindungen ins Internet aufbauen (z.B. für DNS-Abfragen oder zum Email-Versand) und sich dabei hinter der IP des LoadMasters “verstecken” müssen (siehe Blogartikel zu SNAT).

In vielen anderen Fällen aber führt dieses “Verstecken” – je nach Routenführung – zu ungewollten Effekten.

Daher: Wenn Sie sie nicht ausdrücklich brauchen, deaktivieren Sie diese Option!

3. Stateful Failover

Bei zwei LoadMastern im Hochverfügbarkeitsmodus (“HA-Betrieb”) soll auch der Wechsel zwischen den beiden (geplant oder im Störungsfall) möglichst ohne Serviceeinbußen erfolgen. Dabei spielt es gerade im Web-Bereich (HTTP/S) eine wichtige Rolle, dass die Sessions erhalten bleiben. Zu diesem Zweck aktivieren Sie bitte die Option namens “Inter HA L7 Persistancy Updates” (und wenn Sie Virtuelle Services im L4 Modus betreiben, dann auch die L4-Option.)

4. “Virtual MAC”-Verwendung

Um den Schwenk zwischen zwei LoadMastern möglichst schnell und reibungslos erfolgen zu lassen, ist für Hardware-Geräte die Aktivierung der “Virtual MAC”-Option zu empfehlen (nicht verfügbar im VLM, da von den Virtualisierungs-Plattformen nicht durchgehend unterstützt.) Diese bewirkt, dass im Failover-Fall nicht nur IP-Adressen von einem zum anderen LoadMaster übernommen werden, sondern auch Ethernet-Adressen. Dadurch müssen umliegende Systeme Ihre sog. ARP-Caches nicht anpassen, sondern können einfach weiterarbeiten.

Zu finden ist diese Option unter “HA Parameters” (im gleichen Bildschirm wie im vorangegangenen Punkt “Stateful Failover”, ganz unten.)

Achtung: Dieses “Wandern” der Ethernet-Adresse von einem LoadMaster zum anderen lässt nicht jeder Switch zu – manchmal unterbindet die Sicherheitskonfiguration dieses. Also vorab überprüfen und ggf. anpassen!

5. Eindeutige HA-Kennung

Noch eine Kleinigkeit im Bereich HA: Standardmäßig steht die sog. Cluster-ID auf  ”1″  - sollte je ein weiteres Cluster-System im gleichen Netz auftauchen, könnte es “knallen”. Also sorgfältig verwalten… Und ich selbst habe es mir zur Gewohnheit gemacht, von vornherein diese ID auf einen Nicht-Standard-Wert abzuändern:

6. Routing an oder aus?

Gar nicht so bekannt: Will man Geräte hinter dem LoadMaster direkt erreichen (etwa per SSH, RDP o.ä.), so muss man auf dem LoadMaster gar nichts tun – dieser kann einfach als Router fungieren!

Ist dies aber nicht gewünscht (etwa in DMZ-Umgebungen), kann diese Funktionsweise abgeschaltet werden – dies nennt sich “Packet Filter” und sieht so aus:

7. Schnelles Umschalten bei Serverausfall

Musterbeispiel Exchange 2010: In manchen Virtuellen Services setzt man laaaaange Timeout-Zeiten, damit die Benutzer keine lästigen Warnungen bekommen. Fällt nun aber ein “Real Server” aus, so würde der LoadMaster normalerweise den Timeout abwarten. Um dies zu vermeiden (also sofort umzuschalten), unbedingt den Haken setzen bei “Drop Connections on RS failure”!

8. Nachlaufzeit bei Deaktivierung (“Drain Stopping”)

So langsam kommen wir beim echten “Feintuning” an. Hier zum Thema: Was passiert eigentlich, wenn ich einen Real Server im LoadMaster – etwa zu Wartungszwecken – deaktivere? (Dies kann ja bekanntlich je Virtual Service oder insgesamt geschehen.)

Antwort:

• Offene Verbindungen werden weiter abgearbeitet.
• Ist Persistenz definiert, werden sogar neue Verbindungen desselben Clients ebenfalls weiterhin zum gleichen Real Server geschickt – und zwar über einen bestimmte Zeitraum hinweg, den sog. “Drain Stop” Timeout.

Sinn dieser Technik ist natürlich, dass Benutzer nicht “hart” aus ihrer Session geworfen werden (also z.B. den Warenkorb verlieren, oder sich neu anmelden müssen.)

Vielmehr werden lediglich keine neuen Clients mehr angenommen, so dass mit der Zeit immer weniger Benutzer auf dem fraglichen Real Server sind. (Tipp: Wie viele Verbindungen noch offen sind, sieht man in der Statistik.)

Je nach Natur des Dienstes kann es ratsam sein, sehr lange Drainstop-Zeiten zu hinterlegen, und das Deaktivieren entsprechend lange vor der Wartung einzuleiten.

9. Logging auf externen Syslog-Server

Möchten Sie LoadMaster-Meldungen dauerhaft speichern?  Dann sollten Sie daran denken, dass der LoadMaster selbst dies nicht tut – spätestens nach dem nächsten Reboot werden die Logs wieder bereinigt. Einzurichten wäre daher das Weiterleiten der Meldungen an einen externen Syslog-Server.

Dies wird hinterlegt in “System Configuration” -> “Logging Options” -> “Syslog Options”. Am besten aber nur WARN und höher weiterleiten, sonst kann das viel werden…

10.Backup

Und zu guter Letzt noch der Klassiker: Backup nicht vergessen!

Auch hierzu noch einige Feinheiten, die man kennen sollte:

• Beim HA-Paar enthält jedes Backup die Konfiguration BEIDER Systeme – es ist also keine getrennte Sicherung nötig.
• Kennwörter werden nicht mitgesichert – eine Wiederherstellung verändert dieses also auch nicht. (Verlorenes Kennwort zurücksetzen? Ganz einfach, siehe Handbuch, Stichwort “pwreset”…)
• SSL Zertifikate sind ebenfalls sicherheitskrtitisch und daher im normalen Backup nicht enthalten.
  Stattdessen sollte unbedingt das gesonderte, passphrase-gesicherte Zertifikats-Backup genutzt werden (“Certificates” -> “Backup/Restore Certs.”)!
• Regelmäßiges automatisches Backup gewünscht? Hier nachlesen – oder auf die Firmware-Version 6 warten, die auch hier Neues bringt :)

—————

NACHTRAG: 11. Eigene Interfaces überwachen

Ein weiterer wichtiger Punkt ist mir noch aufgefallen, den ich gerne nachreichen möchte: Die “Use for HA checks” Option – siehe dazu dieser eigenständige Artikel zur Interfaceüberwachung!

WEIGHT (% of 100)	MAX VALUE	DIRECTION	HARD LIMIT VALUE	COUNTER  \Object(Instance)\Name
30	100	up	-1	\Prozessor(_Total)\Prozessorzeit (%)
20	3766	down	-1	\Speicher\Verfügbare MB
10	50	up	-1	\Speicher\Seiten/s
20	10	up	-1	\Physikalischer Datenträger(_Total)\Durchschnittl. Warteschlangenlänge des Datenträgers
20	25	up	25	\Terminal Services\Aktive Sitzungen
0	10000000	up	-1	#\Netzwerkschnittstelle(MS TCP Loopback interface)\Aktuelle Bandbreite

ACHTUNG, noch eine Falle in der Windows-Mehrsprachigkeit: Wer zwischen verschiedenen Betriebssystemen bzw. Zeichencodierungen wechselt, sollte sichergehen, dass er die Konfiguration mit ihren Umlauten tatsächlich unter Windows eingibt…

Wie aber funktioniert die Einrichtung dafür? Erstaunlich einfach, wie wir uns im Folgenden anschauen wollen.

Ausgangszustand

Basis für dieses Beispiel ist wieder das System, dass wir in den vorangegangenen Kochbuch-Artikeln aufgesetzt haben.

ACHTUNG: Wenn Sie schon über “HA-2″-Gerät” verfügen, bzw. die VLM-Lizenz schon erhalten haben: Lassen Sie dieses zunächst ausgeschaltet!

Als Vorbereitung muss zunächst sichergestellt werden, dass ein Default Gateway eingetragen und existent ist. Die muss kein echter Router sein, nur eben ein System, welches vom LoadMaster per Netz erreichbar ist. In meinem Fall nehme ich einfach die IP des Laptops, auf dem mein VLM läuft:

Tragen Sie bitte außerdem einen funktionierenden NTP-Server ein (siehe Artikel zu NTP-Einstellungen im LoadMaster).

Wenn Ihr bestehendes System bereits als HA-1 konfiguriert ist (z.B. weil es sich um einen vorlizensierten Hardware-Load Balancer handelt, oder weil Sie die VLM-Lizenz gleich als “HA-1″ angefordert haben), können Sie nun direkt zum Kapitel Hinzufügen des “HA-2″ LoadMaster springen.

Sollten Sie noch keine “HA-2″ Lizenz haben, empfehle ich, die Beantragung nun vorzunehmen (also aus dem Abschnitt “Hinzufügen des HA-2 LoadMaster” vorzuziehen):
- Zweite VLM-Instanz hochfahren, analog dem Artikel zum VLM-Setup
- Beim Beantragen der Lizenz dann “HA-2″ auswählen.

Nun zurück zum bestehenden LoadMaster. Schauen wir uns zunächst nochmals die Interface-Einstellungen an:

…und Click auf “Home” zeigt genau diese Adresse als die des LoadMasters.

Nebenbei übrigens bitte schonmal die graue Leiste oben beachten – links neben “LoadMaster Vitals” sieht man bisher nichts. (Darauf kommen wir später zurück…)

Umstellung des Einzel-LoadMasters auf “HA-1″

Nun wollen wir das bestehende System auf HA-Betrieb umstellen. Dies geschieht unter “HA Parameters”, wo wir von “Non HA Mode” auf “HA (First) Mode” (den wir auch als “HA-1″ bezeichnen werden) wechseln.

Diese Umstellung erfordert einen Neustart des Systems, den wir bestätigen:

Anschließend (Browser-Warnung wegen selbstsigniertem Zertifikat bestätigen) hat sich schon ein erstes Bisschen verändert – man beachte die grün/roten Boxen in der angesprochenen grauen Leiste, sowie das reduzierte Menü auf der linken Seite!

Nun geht es an’s Eingemachte, die eigentlichen Cluster-Einstellungen.

Dazu zunächst eine Vorüberlegung:

Bisher haben wir auf den LoadMaster über seine IP-Adresse zugegriffen, um ihn zu konfigurieren, zu booten, usw.
Im HA-Verbund aber müssen wir unterscheiden:

a) Aktionen, die sich auf alle Geräte gleichzeitig beziehen (etwa Änderungen an Virtuellen Services oder Alarmierungs-Einstellungen)

b) Aktionen, die sich nur auf ein Gerät beziehen (etwa Reboot, IP-Adress-Änderungen, oder Software-Update)

Letztere geschehen – naheliegenderweise – durch Zugriff auf die IP-Adresse des betreffenden Geräts. Genau das haben wir eben auch getan – und daher sehen wir nun im linken Menü “Local Administration”, welches genau die unter (b) beschriebenen Aktionen erlaubt.

Für (a) hingegen nutzen wir den übergreifenden Zugriff per sogenannter “Shared IP”, welcher sich auf alle Geräte im HA-Verbund auswirkt. Wir brauchen also eine zusätzliche, “virtuelle” IP-Adresse, die nur für übergreifende Aufgaben wie das Management des HA-Clusters verwendet wird. Wir sprechen daher neben “Shared IP” auch von der “Management IP”, was das gleiche meint.

Also, zusammengefasst brauchen wir:

• “Physikalische” IP-Adresse des ersten LoadMasters (“HA-1″) – Im Beispiel: 192.168.69.251
• “Physikalische” IP-Adresse des zweiten LoadMaster (“HA-2″) – Im Beispiel: 192.168.69.252
• Shared IP des LoadMaster-Verbunds – Im Beispiel: 192.168.69.250

Und genau dies tragen wir nun in der eth0-Konfiguration ein (jeden Wert per Klick auf zugehörigen Button bestätigen)…

…und aktivieren das Ganze per Reboot.

Nach Reboot scheint sich zunächst wenig geändert zu haben – nur dass nun bei “IP address” neben der “physikalischen” auch die Shared IP angezeigt wird:

Und “Shared IP” ist dann auch das richtige Stichwort, denn wie oben schon festgestellt, wird ja ab sofort ja diese zum Management verwendet. Also ab zu https://192.168.69.250 (Browser-Warnung wegen selbstsigniertem Zertifikat bestätigen). Und siehe da – endlich haben wir wieder das gewohnte Menü auf der linken Seite!

Die Umstellung des bestehenden LoadMaster auf HA ist nun abgeschlossen. Das Ganze stellt sich nun dar wie ein LoadMaster-Cluster, bei dem ein Knoten ausgeschaltet ist. Sprich: Alle Virtual Services sollten wie gehabt funktionieren!

Hinzufügen des “HA-2″ LoadMaster

Wir brauchen nun also einen zweiten LoadMaster, und zwar mit “HA-2″ Lizenz.

• Wer Hardware vor sich hat, bei dem ist vermutlich schon die passende HA-2 Lizenz eingespielt.
• Wer mit VLM arbeitet, sollte nun eine zweite Instanz hochfahren und dort die Lizenz eintragen analog dem Artikel zum VLM-Setup. (Vorab, falls noch nicht geschehen: Zunächst Lizenz beantragen, wie im vorgenannten Artikel beschrieben. Dabei Typ “HA-2″ auswählen!)

Nach Eingeben der HA-2 Lizenz im neuen VLM – und erzwungener Kennwort-Änderung – greifen wir in diesem Beispiel per Tastatur und VGA-Monitor zu.

Dabei werden nun die Basisdaten abgefragt:

und der neue VLM verbindet sich nun mit seinem Partner:

Tipp: In VMware-Umgebungen kann es vorkommen, dass dieser initiale Schritt nicht auf Anhieb funktioniert (“Failed to receive configuration…” – verursacht durch Timing-Probleme der Plattform.) Als zuverlässigster Workaround hat sich herausgestellt:

<N>o – Kein Retry
<C>ancel – Quicksetup abbrechen
7 – Utilities
1 – Software upgrade (Warnung bestätigen)
3 – Reset to factory defaults (Warnung bestätigen)

Achtung, dabei wird das Kennwort aus Sicherheitsgründen NICHT zurückgesetzt – also beim erneuten Login das bereits geänderte Kennwort verwenden. Ab hier sollte es nun in jedem Fall reibungslos funktionieren!

Abschließend starten wir nun einmal den LoadMaster neu.

Nach erfolgtem Neustart sollte der Zugriff auf die Shared IP zwei grüne Kästen anzeigen:

und damit läuft der LoadMaster-Cluster nun – viel Spaß beim Testen!

Für den Produktiveinsatz gibt es noch einige Feintuning-Maßnahmen, die ich in einem folgenden Kochbuch-Artikel vorstellen werde.
Das Wichtigste aber sei vorweggenommen: Um wirklich in jeder Situation robust reagieren zu können, brauchen die LoadMaster zwei unabhängige Querverbindungen (also z.B. auf eth0 und eth1).
Und in diesem Zusammenhang: Mehrere Interfaces eines LoadMasters (also z.B. eth0 und eth1) dürfen sich nicht im gleichen Netzwerk befinden. Details finden sich natürlich auch in der KEMP LoadMaster Dokumentation.

Doch noch Probleme mit der Cluster-Einrichtung? Vielleicht bringt ja dieser Artikel zum Troubleshooting beim HA-Setup eine Lösung. Ansonsten hilft der KEMP-Support unter http://www.kemptechnologies.com/contact-support/ gerne weiter!
Und ich freue mich wie immer über Kommentare (oder direktes Feedback per Kontaktformular.)

Anleitung erstellt auf Basis von LoadMaster Firmware Version 5.1-45

• 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

Entscheidung für eine Virtualisierungsplattform

Der VLM ist momentan verfügbar für VMware und Microsoft Hyper-V. Welche davon nehmen? Ganz egal, der LoadMaster sieht auf allen Hypervisoren gleich aus, und natürlich auch als Hardware-Appliance. Kriterium wird also allenfalls sein “was habe ich schon” / “was kenne ich schon” / “was läuft auf meiner Hardware”…

In meinem Fall einfach: Zum Testen nehme ich einfach mal “VMware Fusion” auf meinem Macbook…

Download der aktuellsten VLM-Version

Auch dieses Thema können wir knapp halten: Auf http://www.kemptechnologies.com/try/ die gewünschte Version wählen (in meinem Fall die “VMware Workstation, Server, and Player”), herunterladen, ZIP-Archiv auspacken, fertig.

Öffnen und Starten des Virtuellen LoadMaster in VMware

Im Öffnen-Dialog im eben ausgepackten Verzeichnis die “VMX”-Datei auswählen:

Dann einfach starten, und der LoadMaster startet bis zum Login:

Benutzername und Kennwort nach Neuinstallation sind übrigens “bal” und “1fourall” (das erste Zeichen ist die Ziffer Eins). Wer diese nun eingibt, sieht den Lizensierungsschirm:

aber – STOP – es ist einfacher, ab hier per Web-Oberfläche weiterzumachen!

Zugriff per Web-Oberfläche

Wir machen uns nun zunutze, dass der LoadMaster über seine VMware per Netz erreichbar ist.

Im obigen (schwarzen) Screenshot sieht man, dass er in meinem Beispiel sogar per DHCP eine Adresse bekommen hat (die 192.168.2.113). Steht kein DHCP zur Verfügung, so wird übrigens die 192.168.1.101 als feste IP verwendet.

Der Zugriff erfolgt nun also über den Browser, und zwar per SSL – im Beispiel: https://192.168.2.113
Die an dieser Stelle unvermeidliche Browserwarnung ist natürlich zu bestätigen, und es erscheint die Lizenzcode-Abfrage nunmehr per Browser:

Abrufen und Einspielen der Test-Lizenz

Nun kommt der große Vorteil des Browser-Zugriffs… Der Access-Code kann nämlich ausgeschnitten und in die Lizenzanforderung unter http://www.kemptechnologies.com/activate-vlm/ eingefügt werden. Kurz danach sollte die Testlizenz per Email eintreffen, und wird am besten ebenfalls per Copy&Paste zurück in die VLM-Oberfläche übernommen.

Es erscheint die Erfolgsmeldung:

Abschließend kommt die Anmeldeaufforderung mit dem Start-Benutzername und Kennwort (siehe oben: “bal” und “1fourall”; das erste Zeichen ist die Ziffer Eins). Nun noch die Pflicht-Kennwortänderung:

Fertig!

Und so geht’s weiter:

Damit steht der LoadMaster nun bereit, die eigentliche Konfiguration kann beginnen. Wichtig: Zunächst die endgültige Interface-Konfiguration vornehmen (am besten zunächst eth0).

Dann kann der erste Virtuelle Service angelegt werden. Eigentlich ganz einfach… nachzulesen in der Dokumentation unter http://www.kemptechnologies.com/documentation/. Oder in Kürze hier im nächsten Teil der “Kochbuch”-Reihe!

Anleitung erstellt auf Basis von LoadMaster Firmware Version 5.1-45