Wir immer führen viele Wege nach Rom, und wie immer “kommt es darauf an.” Hier zunächst die Denkrichtungen im Überblick:

1. HTTP-Header basierte Authentisierung für den LoadMaster entfernen
2. HTTP-Header basierte Authentisierung (z.B. Basic Authentication) abbilden
3. Formularbasierte Authentisierung für den LoadMaster entfernen
4. Formularbasierte Authentisierung per server-seitigem Skript durchführen

Beginnen wir also bei der Frage:

Welchen Authentifizierungs-Mechanismus nutzt die Website überhaupt?

Üblich sind zwei Varianten.

a) Die HTTP-Header basierten Authentisierung ist das altbekannte “Browser-Popup”, z.B. im “Basic Authentication” Verfahren (sicher übrigens nur mit SSL!)

Details gibt es z.B. bei Wikipedia; für uns ist an dieser Stelle nur wichtig zu wissen: Die Anmeldedaten werden durch den Browser abgefragt (besagtes Popup) und “verschleiert” automatisch mit jeder Anfrage mitgegeben. Nämlich in Form einer gesonderten HTTP-Header-Zeile. Beispiel:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Dieser HTTP-Header wird nun auf der anderen Seite durch den Webserver angenommen und gegen die zulässigen Werte geprüft; beim Apache etwa durch “htaccess” – siehe z.B. dieses Tutorial. Man beachte: Die Web-Anwendung ist hier an keiner Stelle eingebunden.

b) Im Gegensatz dazu steht die Formularbasierte Authentisierung, bei der Anmeldedaten wie Benutzername und Kennwort per Formular in der Website abgefragt und direkt an die Anmeldung übermittelt werden (typischerweise per POST-Request). Wie auch immer dann dort die Überprüfung stattfindet. Bei Folgezugriffen bleibt es dann übrigens ebenfalls der Anwendung überlassen, wie sie erkennt, dass der Benutzer sich bereits erfolgreich angemeldet hat (Stichworte: Session-ID, meist per  Cookie oder URL). Nach diesem Theorie-Teil können wir nun zurückgehen zu unseren vier Lösungsansätzen von oben.

Authentifizierung abschalten?

Require valid-user
Allow from 192.168.1.101 192.168.1.102
Satisfy Any

Einfügen der Authentisierung als HTTP Header

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ=="

Pünktlich zur CeBIT war KEMP gut in der Presse vertreten… Mit einem Heise iX-Grundlagenartikel inklusive Review des LoadMaster 2200, sowie einem spezielleren Artikel zum Thema “Verteilung über mehrere Standorte” in der LANline.

Als Service hier die Artikel als PDF zum Download:

KEMP-Review “Doppelwaage” (iX 3-2012)
und
KEMP-Fachartikel “Der richtige Weg” (LANline 3-2012)

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…