Load-Balancing- und High-Availability-Cluster mit IPtables

Egal ob Leben oder IT: Muss eine Arbeit verrichtet werden, selbst wenn der Arbeiter wegen Grippe ausfällt, geht das nur mit Ersatzkräften. Hier wie dort stellt sich die Frage, ob der Ersatzmann nur im Notfall einspringt oder ob er schon mitwerkeln soll, während der Kollege noch gesund ist. In die Informationstechnik übertragen, steht entweder neben dem Produktivsystem ein Standby-Computer, der erst im Ernstfall einspringt, oder ein Load-Balancing-Cluster verteilt die Last laufend auf mehrere Maschinen. Letzteres gibt es zentralistisch gesteuert oder kollektiv ausgehandelt.

Bei dem Gespann aus Produktivsystem und Standby-Maschine wacht eine Cluster-Software wie Heartbeat über das erste System und schaltet bei Anzeichen eines Problems automatisch auf die zweite Maschine um. Das geschieht meist durch Übernahme einer gemeinsamen MAC-Adresse. Im Netzwerk ist dieser Ansatz durch die Protokolle HSRP (Hot Standby Router Protocol), VRRP (Virtual Router Redundancy Protocol) oder CARP (Common Address Redundancy Protocol) realisiert. Vom Linux-HA-Projekt [1] stammt die bekannteste Umsetzung für HA-Server-Cluster.

Beim Load Balancing verteilt meist eine zentrale Instanz die Arbeit auf die Koten [2]. Sind genügend Reserven vorhanden, kann ein Knoten aus dem Verbund austreten. Um keinen Single Point of Failure zu erzeugen, empfiehlt es sich, die Zentralinstanz wiederum über Heartbeat hochverfügbar auszulegen.

Dezentral

Wer die zentrale Load-Balancing-Instanz gänzlich scheut, greift zum Beispiel zum »CLUSTERIP«-Target von IPtables. Es ist bereits im offiziellen Netfilter-Code enthalten, arbeitet aber noch nicht ganz stabil. Dennoch überzeugt die Technik: Bei Cluster-IP berechnet jeder Knoten selbst anhand eines Hash-Algorithmus, ob er für eine Verbindung zuständig ist.

Kontrolle über das System hat der Administrator, indem er Zuständigkeiten dem Knoten online über »/proc/net/ipt_CLUSTERIP« mitteilt. So können Mensch oder Skript dynamisch in die Lastverteilung oder -übernahme eingreifen. Diese Methode ist schon länger in den Produkten der Firma Stonesoft [3] realisiert und funktioniert dort hervorragend.

Beispielcluster

Der Cluster in Abbildung 1 besteht aus zwei Knoten. Jeder besitzt ein Interface im LAN (»eth0«) und ein weiteres im Managementnetz (»eth1«), über das sich die Knoten gegenseitig prüfen und steuern. Besteht der Cluster nur aus zwei Knoten, genügt ein Crossover-Kabel als Ersatz für den Management-Switch.

Abbildung 1: Die LAN-Interfaces beider Cluster-Knoten sind zu einem virtuellen Interface mit einheitlicher IP- und MAC-Adresse zusammengefasst. Daneben gibt es ein Management-Netz.

Im LAN erhält jedes Interface zusätzlich eine gemeinsame virtuelle Cluster-Adresse, über die Clients später den gesamten Cluster ansprechen. Jeder Knoten ermittelt selber, ob er zuständig ist - dazu muss ihn das Paket aber schon erreicht haben. Der Cluster erhält daher eine gemeinsame IP-Adresse sowie eine gemeinsame MAC-Adresse, die auf jedem Knoten gleich lauten. Das klappt nur mit Multicast-MAC-Adressen, erkennbar am gesetzten niederwertigen Bit im höchstwertigen Byte. Die Multicast-Adresse verhindert Adressenkonflikte.

Einen Haken hat dies allerdings: RFC 1812 [4] bestimmt, dass ein Router keinem ARP-Reply (Address Resolution Protocol) vertrauen darf, der einer IP-Adresse eine Multicast- oder Broadcast-MAC zuordnet. Bei Routern, die sich sklavisch an das RFC halten, muss der Admin diese Multicast-MAC statisch in die ARP-Tabelle eintragen.

Switches geben empfangene Multicast-Pakete normalerweise an allen Interfaces aus. Das kann bei hochverfügbaren Architekturen mit HSRP-Routern oder wie im Beispiel mit zwei Switches für erhebliche Verwirrung sorgen. Der aktive Switch 1 erhält das Paket aus dem LAN und reicht es sowohl an den Knoten als auch an den zweiten Switch weiter, damit Knoten 2 das Paket erhält. Switch 2 hat nun nichts Besseres zu tun, als das Paket sowohl an den Knoten 2 weiterzugeben als auch an den ersten Switch zurückzuschicken. Einige ältere Switche erzeugten tatsächlich diese Schleife und legten damit das LAN lahm.

Wenn ein Switch Multicast-Adressen nicht über den normalen Mechanismus lernt, muss der Admin ihm per Konfiguration mitteilen, welcher Port Eingang und welcher Ausgang für diese Multicast-Pakete ist. So leitet der Switch jedes Paket genau einmal an das LAN-Interface jedes Knotens. Hängen die beiden Knoten des Clusters an Interface 1 und 2, dann lautet das Kommando beispielsweise für Cisco-Switche:

mac-address-table static 01:02:03:04:05:06 interface FastEthernet0/1 FastEthernet0/2

Bei hochverfügbaren Szenarien mit doppeltem Switch (einem pro Knoten) hilft zudem das Spanning-Tree-Protokoll. Es verhindert Schleifen im Weg zum Ziel.

Der Cluster muss alle zu einer Verbindung gehörenden Pakete demselben Knoten zuweisen. Nur dies verhindert, dass ein Client auf eine Anfrage doppelte Antworten erhält oder dass der Server mit einem Paket nichts anzufangen weiß, weil er die Vorgeschichte nicht kennt. Die Cluster-Software im Netfilter-Paket erledigt das elegant selbstständig.