Lifekeeper

Der LifeKeeper ist eine Clusterlösung aus der Klasse der Verfügbarkeits-Cluster. Mit dieser können unternehmenskritische Anwendungen und Daten in Hochverfügbarkeitskonzepte integriert werden. Es ist auf verschiedenen Linux-Distributionen und Microsoft Windows (Application Recovery Kits) als Betriebssystem lauffähig. Zudem können Testversionen zur Verfügung gestellt werden.

Es gibt verschiedene Möglichkeiten, die aktuellen Daten den Cluster-Nodes zur Verfügung zu stellen. Dies kann sowohl lokal, mit Datenreplikation, auf einem gemeinsamen Datenspeicher (Shared Storage) als auch mittels geeigneter WAN-Verbindungen über Standorte hinweg erfolgen. Geschäftskritische Anwendungen werden einzeln auf den jeweiligen Servern überwacht und geschützt. Fällt eine geschützte Anwendung aus, wird nur diese mit allen benötigten Komponenten (den Ressourcen) neu gestartet oder auf den Backup-Node verschoben. Andere, nicht ursächlich mit dieser Anwendung zusammenhängende Anwendungen, bleiben von dem Failover (Ausfall) unberührt.

Auf den Nodes eines LifeKeeper-Clusters können geschützte und ungeschützte Applikationen gleichzeitig betrieben werden. Nach Ausfall eines Nodes stehen ungeschützte Applikationen jedoch nicht mehr zur Verfügung. SCSI- oder Fibre Channel-basierten Storage-Systeme, SAN-Konfigurationen und NAS-Systeme werden unterstützt. Die einzelnen Nodes im LifeKeeper-Cluster können aus heterogener Hardware bestehen, müssen also keine baugleichen Systeme sein. Die Konfiguration der Server wird im Wesentlichen durch die Anforderungen der Anwendungen bestimmt. Dabei ist sowohl die Konstellation im Normalbetrieb, als auch in allen Failover-Szenarien zu beachten. Das Wissen um den Aufbau und die möglichen Fehlerszenarien für die Applikation steckt in den Application Recovery Kits (ARK). Diese modularen Bausteine sind für verschiedenste Applikationen verfügbar.

Übrigens: Die PlusPedia ist NICHT die Wikipedia. Wir sind ein gemeinnütziger Verein, PlusPedia ist werbefrei. Wir freuen uns daher über eine kleine Spende!

1 Geschichte

Die Software wurde ursprünglich von den AT&T Bell Labs ab 1992 für das weltweite Telefonsystem auf der Basis von Unix entwickelt. Nachdem AT&T die entsprechende Abteilung in seinem Unternehmen an NCR abgetreten hatte, wurde die Technologie 1999 von SteelEye übernommen. SteelEye wurde 2006 von der SIOS Technology Corp. gekauft und einige Jahre später umbenannt.

2 Aufbau, Konfiguration und Funktionsweise

2.1 Aufbau

2.1.1 Softwarearchitektur

Der SteelEyeLifeKeeper besteht aus zwei verschiedenen Funktionsgruppen: dem Core Kit, in dem die Grundfunktionalität der Clustersoftware enthalten ist, und den Application Recovery Kits, die das Wissen um die zu schützende Anwendung beinhalten.

Das Core Kit wird auf jedem Server im Cluster installiert. Es ist eine Middleware, die sich logisch zwischen Betriebssystem und Applikation (Anwendung) befindet. Das Core Kit beinhaltet demzufolge auch die Schnittstelle zur Hardware und zum lokalen Netzwerk. Bereitgestellt werden verschiedene Application Interfaces (Anwendungsschnittstellen), über die die Application Recovery Kits (ARK) mit dem LifeKeeper Core kommunizieren. Geschützt werden können vom Core Kit auch IP-Adressen und Fileservices. Ein wichtiger Bestandteil des Core Kits ist die Cluster-Datenbank. Hier werden die Konfigurationsdaten aller Cluster Nodes gespeichert. Dies umfasst auch die Einbindung der Applikationen in das Cluster. Beim LifeKeeper befindet sich diese Cluster-Konfigurationsdatenbank auf jedem Cluster Node. Dadurch wird, im Unterschied zu Konzepten mit einer zentralen Quorum Disk, ein Single Point of Failure (SPOF) vermieden. Für die Homogenität der Cluster-Datenbank sorgt der LifeKeeper.

2.1.2 Netzwerk- und Clientsicht

In der Netzwerksicht wird gezeigt, wie sich die physikalisch vorhandenen Server und die virtuellen Applikationen mit ihren virtuellen Adressen und Namen im Netzwerk darstellen. Um die Server-Hardware ansprechen zu können, werden den Servern auch im Cluster IP-Adressen zugewiesen. Die Applikation selbst ist jedoch über eine davon unabhängige Adresse erreichbar, die sich je nach Konfiguration und Zustand des Clusters auf einem beliebigen Cluster-Node befinden kann.

Ein praktisches Beispiel für die Clientsicht: der im Cluster geschützte virtuelle Mailserver. Der Mailclient erreicht über eine virtuelle Adresse nur virtuelle Ressourcen, wie Postfächer, öffentliche Ordner oder Kalender. Für den Client ist daher transparent, auf welchem Node sich diese Ressourcen im Moment befinden.

2.2 Funktionsweise

2.2.1 N+1 Failover

In der Cluster-Konfiguration wird ein dedizierter Backup-Server für 1-2 andere Server im Cluster bereitgestellt. Hierzu eignen sich besonders Systeme wie File-Server, die selbst wenig Ressourcen benötigen. Eine oder mehrere Applikationen können im Fehlerfall auf diesen Node wechseln.

2.2.2 N-Way Failover

Mehrere geschützte Applikationen auf einem primären Server können im Fehlerfall auf mehr als einen Backup-Server verteilt werden. Damit können Unverträglichkeiten auf dem Backup-System oder auch Ressourcenengpässe vermieden werden. Minimiert werden damit die zusätzliche Last und eine Verschlechterung des Antwortzeitverhaltens auf dem Backup-Server.

2.2.3 Cascading Failover

Konfiguriert werden kann ein zweiter Failover, für den Fall, dass auch der erste Backup-Server funktionsunfähig ist. Somit wird ein hohes Maß an Ausfallsicherheit erreicht.

2.2.4 Erweiterte Anwendungsszenarien

Neben den klassischen aktiv/passiv und aktiv/aktiv Konfigurationen lassen sich im LifeKeeper auch komplexere Umgebungen abbilden. Durch sein modulares Design und Zusatzkomponenten wie Data Replication lassen sich zum Beispiel Szenarien wie Disk-to-Disk Backup abbilden. Darüber hinaus ist auch die Integration in virtuelle Umgebungen möglich, sowohl in Storage virtualisierter Umgebung als auch in Server virtualisierten Umgebungen. Als erweiterte Anwendungsszenarien sind möglich:

• Data Replication
• SAN basierte Storagespiegelung
• Servervirtualisierung
• Storagevirtualisierung
• Disk-to-Disk Backup
• Continuos Data Protection (CDP)

3 Datenzugriff

Basis jeder Clusterkonfiguration ist die Möglichkeit des gemeinsamen Datenzugriffs für alle beteiligten Nodes.

Die Datenreplikation kann synchrone Datenbestände in zwei Servern zur Verfügung zu stellen.

Durch den Einsatz von WAN-Verbindungen wird die Nutzung der Clustertechnologie für die Gestaltung regional getrennter Disaster Recovery Szenarien möglich. Somit kann selbst bei Ausfall eines kompletten Rechenzentrums die Kernfunktionalität weiter gesichert werden.

4 Siehe auch

• Failover

5 Weblinks

• Homepage, international, leitet auf SIOS um
• Homepage von SteelEye, Deutschland

7 Andere Lexika

• Dieser Artikel wurde in der Wikipedia gelöscht.

---

---

• Autoren: Bitsandbytes, Lantus, Crazy1880, Chaddy, Maloedisch , GiordanoBruno, Mitten, Zwobot, TheWolf, Avron, Lichtkind, Gronau , Nicor, RedBot, MarkusHagenlocher
• Löschdiskussion