UCARP: Hochverfügbarkeit für Linux und Unix

Die redundante Auslegung von Systemen ist häufig die einzige Möglichkeit, geschäfts­kritische Anwendungen vor einem Ausfall zu bewahren. In den ORDIX News wurde schon häufiger über Heartbeat, das "Linux High Availability Projekt", berichtet. Dieser Artikel soll eine Alternative zu diesem Projekt aufzeigen und deren Funktionen erläutern.

Grundlegendes

UCARP ist eine portable Userland-Implementierung des Common Adress Redundancy Protocols (CARP), das vom OpenBSD Projekt entwickelt wurde. Dieses Protokoll zeichnet sich besonders durch den sehr geringen Overhead und die verschlüsselte Kommunikation aus. Diese Verschlüsselung wird mittels SHA-1 vorgenommen. Darüber hinaus wird für die Verbindung der Knoten keine dedizierte Verbindung benötigt, d. h. die Statusmeldungen der Systeme werden über das Netzwerk übertragen.

Die Hochverfügbarkeit wird gewährleistet, indem den Netzwerkschnittstellen zusätzlich zur physikalischen noch eine virtuelle IP-Adresse zugeteilt wird. Diese virtuelle IP-Adresse ist immer dem Master-System zugeordnet. Fällt es aus, wird das Backup-System zum Master. So ist der Cluster immer über eine IP-Adresse erreichbar. Dies ist notwendig, damit beim Ausfall eines Knotens für den Client keine Veränderungen auftreten.

CARP versus VRRP

Wenn man sich über CARP oder allgemein über die redundante Auslegung von Systemen informiert, wird man schnell auf ein weiteres Protokoll stoßen, das VRRP (Virtual Router Redundancy Protocol). Dieses Protokoll wird in vielen kommerziellen Routern zur Einrichtung eines Aktiv-Passiv-Clusters verwendet. Doch wo liegen die Unterschiede zwischen diesen beiden Protokollen und weshalb sollte CARP eingesetzt werden?

• VRRP basiert auf Patenten der Firma CISCO. Um patentrechtlichen Problemen aus dem Weg zu gehen, sollte auf den Einsatz von VRRP verzichtet werden.
• CARP arbeitet im Gegensatz zu VRRP protokollunabhängig. Das bedeutet, es ist mit IPv4 und IPv6 nutzbar.
• Wie oben beschrieben, wird die gesamte Kommunikation von CARP verschlüsselt. Dies ist beim VRRP nicht der Fall.

Der Vergleich der beiden Protokolle zeigt, dass CARP dem VRRP nicht nur ebenbürtig, sondern sogar überlegen ist. Dies ist zum Teil dadurch zu begründen, dass die Entwickler von CARP ihr Protokoll anhand von VRRP entwickelt haben. So konnten Fehler des VRRP bei der Entwicklung von CARP vermieden werden.

Unterschiede zu Heartbeat?

In der Ausgabe 1/2006 haben wir über die zweite Version von Heartbeat berichtet. Seit dieser Version ist es möglich, mittels Heartbeat bis zu 16 Knoten in einem Verbund aufzunehmen. Vorher konnte ein Cluster nur aus zwei Knoten bestehen. Mit UCARP lassen sich ebenfalls mehrere Knoten zu einem Cluster zusammenschließen. Getestet wurde von uns ein System mit einem Master- und zwei Backup-Servern. Es sollte aber problem­los möglich sein, weitere Slaves hinzuzufügen. Der Aufbau des von uns getesteten Systems wird im Laufe des Artikels noch genauer erläutert.

Der größte Vorteil von Heartbeat im Vergleich zu UCARP ist sein hoher Bekanntheitsgrad im Linux Umfeld. Auf Grund dessen sind wesentlich mehr Dokumentationen zu Heartbeat verfügbar. Dieses Manko soll dieser Artikel zu einem gewissen Grad ausgleichen.

Es muss aber von Fall zu Fall entschieden wer­den, welche Lösung bevorzugt wird. UCARP zeichnet sich durch seinen schlanken Aufbau und seine Stabilität aus, bietet aber nicht so viele Funktionen wie Heartbeat.

Beispiel

In vielen Fällen ist es sinnvoll, einen Server redundant auszulegen. Die Einrichtung eines solchen Clusters lässt sich am Besten anhand eines Beispiels beschreiben.

Der Proxy-Server ist in einem Unternehmen häufig der zentrale Punkt im Aufbau des Netzwerks und ein Ausfall dieses Servers führt schnell zu gravierenden Problemen. Somit ist ein Proxy-System, das doppelt ausgelegt ist, ideal für unser Beispiel. Um alle Möglichkeiten von UCARP zu erläutern, besteht unser Testaufbau aus einem Master- und zwei Slave-Systemen. Details sind im Netzplan dar­gestellt (siehe Abbildung 1).

Abb. 1: Netzplan.

Um das System, wie es auf dem Netzplan abgebildet ist, einzurichten, sind verschiedene Schritte notwendig, die im Folgenden genau erläutert werden. Für den Aufbau ist jedes Unix-Derivat denkbar. Drei installierte Systeme mit einem Squid-Server werden vorausgesetzt.

1. Installation

Als erstes muss das Programm z. B. von der offiziellen UCARP-Webseite [1] heruntergeladen werden. Im Anschluss daran kann UCARP auf allen Knoten kompiliert und installiert werden
(./configure && make && make install).

Nach der Installation finden Sie UCARP unter /usr/local/sbin/ucarp. Ebenfalls wurde eine Manpage angelegt. Für weitergehen­de Informationen ist in dem aktuellen Verzeichnis die offizielle Dokumentation von UCARP in der Datei README abgelegt.

2. Konfiguration

UCARP verwendet normalerweise keine Konfigurationsdateien und legt auch keine Start- oder Stoppskripte an. Falls nicht auf Skripte zur Steuerung des Prozesses verzichtet werden kann, müssen diese von Hand erstellt werden.

Das Verhalten von UCARP wird nur durch die Optionen beeinflusst, die beim Start mit angegeben werden. Es ist notwendig, mindestens die wichtigsten Optionen (siehe Abbildung 2) zu kennen.

Um einen einfachen Cluster mit zwei Rechnern aufzubauen, wären nur folgende Befehle notwendig:

• Knoten 1: ucarp -v 1 -p test -a 192.168.1.254 -s 192.168.1.1
• Knoten 2: ucarp -v 1 -p test -a 192.168.1.254 -s 192.168.1.2

Bei dieser Lösung haben beide Knoten dieselbe Priorität. Bei einem kompletten Ausfall des einen Systems, würde das andere seine Aufgabe übernehmen. Es wird aber kein Dienst oder ähnliches überwacht. Das bedeutet, wenn auf dem einen System der zu überwachende Dienst nicht mehr läuft, wird dies nicht erkannt und somit auch kein Wechsel der Knoten vorgenommen. In der Praxis ist so eine Konfiguration natürlich sinnlos.

Um genau solche Fehler auszuschließen und einen größeren Komfort zu erlangen, sind einige Skripte notwendig. Beispielhaft werden hier die Skripte für den ersten Knoten abgebildet. Auf den anderen Knoten laufen, mit geringen Abweichungen, dieselben Skripte.

01 # Aufruf fuer eth0
02   /usr/local/sbin/ucarp –v 1 –p test –s 192.168.1.1 –a 192.168.1.254 \
03   –i eth0 -P –B -u /etc/ucarp/vip1-up.sh –d /etc/ucarp/vip1-down.sh
04   sleep 1
05   PID1=`ps -ef | grep /usr/local/bin/ucarp | grep -v grep \
06   | awk '{print $2}'` echo $PID1 >/var/run/ucarp1.pid
07 
08 # Aufruf fuer eth1
09   /usr/local/sbin/ucarp –v 2 -p test -s 192.168.2.1 -a 192.168.2.254 \ 
10   –i eth1 -P –B -u /etc/ucarp/vip2-up.sh –d /etc/ucarp/vip2-down.sh
11   sleep 1
12   ps -ef | grep /usr/local/bin/ucarp | grep -v grep | grep –v $PID1 \
13   awk '{print $2}' >/var/run/ucarp2.pid
14 
15 # Start des Ueberwachungsskripts
16   /usr/local/sbin/ucarp-check &

Start- und Stoppskript

Um UCARP auf komfortable Weise starten und stoppen zu können, wird für unsere Lösung ein Skript benötigt, das genau diese Funktionen übernimmt. Die wichtigsten Zeilen aus dem Startskript sind in Abbildung 3 zu sehen. Abbildung 2 erläutert die Funktionen der verschiedenen Optionen, mit denen UCARP aufgerufen wird.

Skript zur Überwachung des Serverdienstes

Falls der Squid nicht mehr läuft, wird im Normalfall kein Wechsel der Server durchgeführt. Das Internet ist nicht mehr erreichbar. Damit dies nicht passiert, wird ein Skript benötigt, welches die Überwachung übernimmt und UCARP bei einem Zwischenfall beendet. Das in Abbildung 4 aufgeführte Skript wird unter /usr/local/sbin/ucarp-check abgelegt und von dem Startskript (Abbildung 3, Zeile 16) aufgerufen. In unserem Skript wird nur überprüft, ob der Dienst noch läuft, also ob sein Prozess noch vorhanden ist. Man könnte an dieser Stelle auch kompliziertere Methoden implementieren, um die Funktionsfähigkeit des Serverdienstes zu überprüfen.

1  #!/bin/sh
2  # Skript zur Ueberwachung des Serverdienstes
3  
4  SCHLEIFE=1
5  DIENST=squid
6  
7  while [ $SCHLEIFE == 1 ]
8  do
9    ps -ef grep $DIENST | grep -v grep >/dev/null 2>&1 || \
10   { /etc/init.d/ucarp stop >/dev/null 2>&1; \
11   logger -i -t ucarp-check \
12   -- Der Serverdienst ist down. UCARP wurde beendet; \
13   SCHLEIFE=0; }
14   sleep 1
15 done

Die Skripte vip-up.sh und vip-down.sh

Diese Skripte werden ausgeführt, wenn der Knoten Master bzw. Slave wird. Für die beiden UCARP-Prozesse existieren jeweils zwei Skripte, in denen die virtuelle IP-Adresse einem Interface zugeteilt oder entsprechend wieder entzogen wird. In diesen Skripten lassen sich aber durchaus noch weitere Funktionen einbauen. Das Skript, welches aufgerufen wird, wenn der Knoten zum Master wird, benötigt in jedem Fall folgenden Befehl:
/sbin/ip addr add <IP-Adresse> dev <Interface>.

common
  pass test
  preempt
  binarypath /usr/local/sbin/ucarp
 
virtip 192.168.1.254
  srcip 192.168.1.1
  interface eth0
  vhid 1
  upscript /etc/ucarp/vip-up1.sh
  downscript /etc/ucarp/vip-down1.sh
 
virtip 192.168.2.254
  srcip 192.168.2.1
  interface eth1
  vhid 2
  upscript /etc/ucarp/vip-up2.sh
  downscript /etc/ucarp/vip-down2.sh

Das Script ucarpctl

Für jemanden, der keine Erfahrung im Erstellen von Skripten hat, existiert eine gute Alternative. Das Programm ucarpctl-0.2 von Robert Woodcock [2] unterstützt die aktuelle Version 1.2 von UCARP. Das Programm ist in C geschrieben und eigentlich nur ein Skript zur Steuerung des UCARP-Prozesses. Es greift auf die Konfigurationsdatei (/etc/ucarp.conf) zu, in der alle Einstellungen zu UCARP vorgenommen werden. Die Datei für den ersten Knoten ist in Abbildung 5 zu sehen.

Die Möglichkeit, UCARP mittels ucarpctl zu starten, ist zwar auf den ersten Blick sehr komfortabel, es lassen sich aber nicht so leicht Änderungen am Startskript vornehmen. Das bedeutet, mit dieser Lösung wird man ohne entsprechende C-Kenntnisse im professionellen Einsatz schnell an die Grenzen stoßen.

Fazit

UCARP bietet alle grundlegenden Funktionen, die man benötigt, um einen Aktiv-Passiv-Cluster aufzubauen. Die Konfiguration ist im Gegensatz zu Heartbeat trivial, bietet allerdings nicht so viele Möglichkeiten. So wurden im Großen und Ganzen alle Funktionen, die UCARP bietet, durch das Beispiel in diesem Artikel abgedeckt. Wem dieser Funktionsumfang ausreicht und wen die etwas spärliche Dokumentation nicht stört, der findet in UCARP eine gute Alternative zu den gängigen Lösungen.

Marius Dorlöchter (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen