Open Source für den Mittelstand

10 Jahre erfolgreiche Partnerschaft:
KARRENA und ORDIX

Als das Ratinger Industrie-Unternehmen KARRENA Teile seiner Computersysteme auf Unix Systeme umstellte, bestand für einige Bereiche entsprechender Beratungs- und Unterstützungsbedarf. Aus einer lockeren Unterstützung, die der damalige ORDIX Geschäftsführer und heutige Vorstand Kögler geleistet hatte, entwickelten sich verschiedene Aufträge für das Paderborner Software-Unternehmen. Daneben wurden auch Schulungen bei ORDIX gebucht. Jüngst unterstützte ORDIX die KARRENA Gruppe bei der Umstellung der Linux Server auf Linux Cluster Server.

Von Unix zu Linux Neben dem ursprünglich eingesetzten HP Server deckte KARRENA den Ende der neunziger Jahre entstandenen Bedarf durch Linux Rechner ab. Als Vorreiter für Open Source stand ORDIX den IT-Mitarbeitern von KARRENA dabei zur Seite. Im Jahr 2004 kam das EDV Team von KARRENA zu dem Schluss, dass dem Themenschwerpunkt „Verfügbarkeit“ mehr Bedeutung beigemessen werden müsse. Obwohl die Daten schon damals auf drei verschiedene Server verteilt waren (je einer für die zentrale Datenbank, CAD- und Windows Dokumente), hätte der Ausfall einer dieser Maschinen zu nicht tolerablen Verzögerungen in den Arbeitsabläufen geführt.

Abb. 1: EDV-Leiter Dr. Helmut Lütcke (Mitte) mit seinen         beiden Mitarbeitern Thomas Sprenger (links) und         Christoph Schulz (rechts)..

Auf dem ORDIX Fachtreff zum Thema „Open Source Software - technische und kostensenkende Alternative“ erfuhr KARRENA, dass es im Bereich Linux Cluster und Verfügbarkeit inzwischen technologisch sehr gute Lösungen zu akzeptablen Preisen gibt.

Vom Linux Server zum Linux Cluster

Mit dem Wissen aus dem Fachtreff schmiedeten EDV-Leiter Dr. Lütcke und seine Mitarbeiter Thomas Sprenger und Christoph Schulz ein Konzept, wie die hausinterne IT mit zwei leistungsfähigen und mit genügend Festplattenplatz ausgestatteten Linux Servern neu zu gestalten sei.

Der Linux Heartbeat Cluster wurde favorisiert, weil zusätzlich zu der gewährleisteten Hochverfügbarkeit im Normalfall zwei Server bereitstehen, auf die die verschiedenen Dienste verteilt werden können, um so exzellente Response-Zeiten zu erhalten.

In der Vergangenheit stets gut beraten, wendeten sich die KARRENA Mitarbeiter für die Detailplanung auch dieses Mal vertrauensvoll an ORDIX. Ein Termin mit ORDIX reichte für die Prüfung des Konzeptes aus, wobei es nur an wenigen Stellen ergänzt werden musste. Das ORDIX Wissen um zusätzliche, kleine und zugleich wichtige Aspekte, wie z. B. Steckerleisten, Backupgeräte und die Trennung der Server durch feuerfeste Wände, rundete die Vorstellungen der Ratinger ab.

Mit den Informationen aus diesem Beratungstag erstellte das KARRENA EDV-Team eine Vorlage für die Geschäftsleitung, die schnell abgesegnet war. Nur wenige Wochen nach dem ersten Beratungstermin wurden die Cluster zusammen mit ORDIX aufgebaut, Software installiert und die Systeme konfiguriert.

Sämtliche Ausfallszenarien wurden erfolgreich durchgespielt. Jetzt wartet das Gesamtsystem darauf, entgültig in Betrieb genommen zu werden. Auch dabei wird ORDIX bei Bedarf wieder unterstützend tätig werden.

Die Hauptaktivitäten der KARRENA Gruppe liegen in der Auskleidung feuerfester Industrieanlagen und im Bau von Industrieschornsteinen. Seit der Gründung im Jahr 1914 ist die KARRENA inzwischen zu einer weltweit operierenden Unternehmensgruppe mit Vertretungen in mehr als 20 Ländern herangewachsen. Im Jahr 2000 erhielt KARRENA den größten Montageauftrag ihrer Firmengeschichte: Den Neubau von zwei Koksofenbatterien für die neue Kokerei in Duisburg Schwelgern. Nach den Ofenkammerdimensionen ist dies die größte Kokerei der Welt. Zu den Referenzen der KARRENA gehören ferner die Feuerfestauskleidung des größten Hochofens Europas und der größten zirkulierenden Wirbelschichtanlage in Europa, ebenso der mit 360 m höchste Schornstein Westeuropas. Tausende von Referenzanlagen stehen heute in mehr als 100 Ländern der Welt. Internet: www.karrena.de E-Mail: info@karrena.de

Welche Vorteile bringt KARRENA die Zusammenarbeit mit ORDIX?

Auf die Frage, warum KARRENA die Zusammenarbeit mit ORDIX schätzt, antwortet Herr Sprenger: „Ich kenne Herrn Kögler schon seit mehr als 20 Jahren. Was die Beratungs- oder Unterstützungsleistung betrifft, sind wir von ORDIX nie enttäuscht worden. ORDIX hatte für uns jederzeit das notwendige und richtige Know-how zur Verfügung.“ Und er erklärt weiter: „Die Berater sind kompetent und es herrscht Beständigkeit: Selbst der erste Berater, der 1995 bei uns war, steht uns heute noch bei Bedarf zur Verfügung. Wo finden Sie sonst solche Konstanz und Kompetenz?“

EDV-Leiter Dr. Lütcke ergänzt: „Für ein Unternehmen wie KARRENA, das nicht von der IT lebt, sondern diese nur als Mittel zum Zweck nutzt, ist es gerade im Bereich Open Source wichtig, auf jemanden zurückgreifen zu können, dem man vertraut und der einem sofort und unkompliziert helfen kann. Das alles finden wir bei ORDIX.“

Beim jüngsten Projekt hat ORDIX, wie bereits erwähnt, zwei Linux Server als Cluster aufgebaut, was im Weiteren beschrieben wird.

So (einfach) entsteht ein Linux Cluster System

Bei der technischen Umsetzung des Clusters wurde die zum Distributionsumfang des SUSE Linux Enterprise Server 9 gehörende Software des Linux High Availability Project eingesetzt. Die beiden Knoten überwachen sich gegenseitig mittels einer separaten IP-Verbindung über ein gekreuztes Netzwerkkabel sowie über ein an die seriellen Schnittstellen angeschlossenes Nullmodemkabel.

Im Normalfall läuft auf einem der Knoten („lina“) das RDBMS „Universe“ und auf dem zweiten („linb“) der Samba Fileserver. Fällt ein Knoten aus, übernimmt das übriggebliebene System die zu dem jeweiligen Dienst gehörende IP-Adresse und startet die notwendigen Skripte zur Übernahme des Dienstes.

Konfiguration des Clusters

Die Basiskonfiguration der Clustersoftware erfolgt in der Datei
/etc/ha.d/ha.cf:

# Heartbeat Meldungen alle 2 Sekunden senden
keepalive 2
# Nach 10 Sekunden Partner für „tot“ erklären
deadtime 10
# Heartbeat über die serielle Schnittstelle
baud 19200
serial /dev/ttyS0
# UDP Heartbeat über die Netzwerkschnittstelle eth1
udpport 694
bcast eth1
# Die Namen der Knoten
node lina
node linb

Gemeinsame Datenhaltung mit DRBD®

resource drbd0 {
  on lina {
    device /dev/drbd0;
    disk /dev/sda7;
    address 172.17.1.201:7788;
    meta-disk internal;
  }

  on linb {
    device /dev/drbd0;
    disk /dev/sda7;
    address 172.17.1.202:7788;
    meta-disk internal;
  }
}

Zur gemeinsamen Datenhaltung zwischen den Knoten wird die ebenfalls zum Distributionsumfang gehörende Distributed Replicated Block Device (DRBD®) Software eingesetzt. Mittels DRBD lassen sich virtuelle Blockdevices generieren, die dafür sorgen, dass Schreibvorgänge auf beiden Knoten simultan erfolgen (siehe Abbildung 2). Der Datentransfer erfolgt über die auch zur gegenseitigen Überwachung genutzte Gigabit Ethernet Verbindung zwischen den Knoten. Für den Cluster wurden zwei dieser DRBD Devices erzeugt, welche die für jeweils einen Dienst benötigten Daten enthalten. Die Konfiguration der Geräte erfolgt innerhalb der Datei /etc/drbd.conf (siehe Abbildung 3).

Die Clustersoftware entscheidet im laufenden Betrieb, welcher der beiden Knoten auf ein DRBD Device aktiv zugreifen darf (Primary) und welcher Knoten lediglich Daten empfängt (Secondary). Die Änderung des Status erfolgt über das zur Clustersoftware gehörende Skript /etc/ha.d/resource.d/drbddisk.

LVM2 auf DRBD®

Die DRBD Devices selbst wurden wiederum als Physical Volumes für das Logical Volume Management markiert:

pvcreate /dev/drbd0
			pvcreate /dev/drbd1

Um sie anschließend einer Volume Group zuteilen zu können, musste dafür gesorgt werden, dass die „unter“ dem DRBD Device liegenden physikalischen Partitionen /dev/sda7 und /dev/sda8 nicht vom LVM als Physical Volume erkannt werden, sondern lediglich das darauf befindliche DRBD Device. Mit dem neuen Logical Volume Manager in der Version 2 lassen sich zu diesem Zweck Filterregeln in Form logischer Ausdrücke definieren:

/etc/lvm/lvm.conf:

filter = [ "r|/dev/sda[7-8]$|" ]

Im Anschluss daran konnten Volume Groups und Logical Volumes für die beiden Dienste erstellt werden:

vgcreate universe /dev/drbd0
vgcreate samba /dev/drbd1
lvcreate -L6.5GB -n ibm universe
...

Die Aktivierung einer Volume Group bzw. der darin enthaltenen Logical Volumes erfolgt wiederum bei der Übernahme des Dienstes durch das von ORDIX für den LVM2 angepasste Skript /etc/ha.d/resource.d/LVM2.

Konfiguration der Clusterdienste

Mit der Datei /etc/ha.d/haresources wird letztendlich definiert, welche Skripte bei der Übernahme eines Dienstes gestartet werden sowie welcher Knoten diesen Dienst standardmäßig aktivieren soll (siehe Abbildung 4).

lina 192.9.200.203 drbddisk::drbd0 LVM2::universe \
	Filesystem::/dev/universe/ibm::/usr/ibm::reiserfs \
	Filesystem::/dev/universe/dd51::/dd51::reiserfs \
	Filesystem::/dev/universe/dd52::/dd52::reiserfs \
	Filesystem::/dev/universe/dd53::/dd53::reiserfs \
	universe MailTo::admin1,admin2::Universe-Dienst

Beim Start des Dienstes „Universe DBMS“ werden demnach folgende Aktionen von der Clustersoftware ausgeführt:

1. Aktivierung der IP Adresse 192.9.200.203
2. Status „Primary“ setzen für DRBD Device drbd0
3. Volume Group „universe“ auf drbd0 akti­vie­ren
4. Logical Volumes „ibm“, „dd51“, „dd52“, „dd53“ in den Dateibaum einhängen
5. Universe DBMS starten
6. Hinweis über die Übernahme per Mail an die Benutzer „admin1“ und „admin2“ versenden

Ein Stopp des Dienstes sorgt für die Deaktivie­rung der genannten Komponenten in umgekehr­ter Reihenfolge. Das Start/Stop Skript /etc/ha.d/resource.d/universe musste zu diesem Zweck zunächst von der ORDIX AG erstellt werden. Die Universe Software selbst liegt auf dem Logical Volume „ibm“ und wird bei der Aktivierung des Dienstes unter /usr/ibm eingehängt.

# Der APC-Switch 192.9.200.18 ist das STONITH Device
stonith_host lina apcmastersnmp 192.9.200.18 161 geheim
stonith_host linb apcmastersnmp 192.9.200.18 161 geheim

STONITH

Ein zentrales Problem beim Aufbau eines Clus­ters stellt die „Split Brain“ Situation dar. Diese bezeichnet eine kritische Situation, die beim Ausfall der Kommunikationsleitungen zwischen den Knoten entsteht. In diesem Fall erhalten die Knoten keine Information über den Status des Partners und gehen demzufolge fälschlicherweise davon aus, dass dieser nicht mehr lebt. Wenn nun beide Knoten den Dienst übernehmen wollen, kann es zu Datenkorruption und IP-Konflikten im Netzwerk kommen.

Um dies auszuschließen, verwendet die Clustersoftware das STONITH Verfahren („Shoot the other node in the head“). Beim Ausfall der Heartbeat Leitungen bzw. sobald sich die Knoten nicht mehr erreichen, versuchen beide Knoten über eine schaltbare Stromleiste (APC Masterswitch), den Partner abzuschalten. Dazu ist die in Abbildung 5 gezeigte Konfigurationseinstellung in der Datei /etc/ha.d/ha.cf getätigt worden.

Will z. B. der Rechner „lina“ den Rechner „linb“ ausschalten, so verbindet er sich per SNMP mit dem APC Masterswitch mit der IP-Adresse 192.9.200.18 auf dem Port 161 und mit dem Passwort „geheim“. Anschließend wird die Steckdose mit der Bezeichnung „linb“ abgeschaltet. Dies bedingt die vorherige Zuweisung dieser Bezeichnung über die Administrationsoberfläche des Masterswitches.

Fazit

Bei der Installation des Clusters wurde ausschließlich Software aus dem Distributionsumfang des SUSE Linux Enterprise Server 9 verwendet. Auch für die Knoten wurden keine teuren Serversysteme eingesetzt, sondern übliche PC Hardware. Zudem konnte durch den Einsatz von DRBD® auf kostenintensive, externe Storagesysteme zur gemeinsamen Datenhaltung verzichtet werden.

Dennoch verfügt KARRENA nun über ein hoch­gradig ausfallsicheres System, welches Schutz gegen jeden denkbaren Einzelfehler der Hardwarekomponenten bietet. Dies wurde im Rahmen der Abnahme in Form eines ausführlichen Testkatalogs verifiziert.

Planen auch Sie den Einsatz eines Linux Clusters? Dann fordern Sie uns!

Christof Amelunxen (info@ordix.de).

DRBD® ist eine eingetragene Marken der LINBIT Information Technologies GmbH, Austria

Seitenanfang

Seite drucken

Seite weiterempfehlen