LoadBalancerBlog.de

Nachdem im letzten Teil der “Kochbuch”-Serie einige einfache Grundeinrichtungen besprochen wurden, soll es heute in die Details gehen, und zwar in Form einer Checkliste mit Erklärungen.
Die Themen im Überblick:

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!