Lifekeeper

Aus PlusPedia
Wechseln zu: Navigation, Suche
QS-Informatik

Dieser Artikel wurde aufgrund von inhaltlichen Mängeln auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen und beteilige dich an der Diskussion! (+

)
Begründung: Werbung, keine Einleitung, nichtsaussagende Bilder --Crazy1880 12:17, 14. Jun. 2009 (CEST)



Coin Ü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 Allgemeines

Der SteelEye LifeKeeper ist eine Clusterlösung aus der Klasse der Verfügbarkeits-Cluster. Mit dieser können unternehmenskritische Anwendungen und Daten in HA-Konzepte (Hochverfügbarkeitskonzepte) integriert werden. Die Software ist dabei für verschiedene Linux-Distributionen und für Microsoft Windows (s. Application Recovery Kits) als Betriebssystem verfügbar. Es gibt verschiedene, skalierbare Möglichkeiten, die aktuellen Daten den Cluster-Nodes zur Verfügung zu stellen. Dies kann sowohl lokal, mit Datenreplikation, auf einem gemeinsamen Datenspeicher 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. Diese können auf Intel-, Opteron-, OpenPower- und EM64T-Systemen basieren. 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.

2 Aufbau, Konfiguration und Funktionsweise

2.1 Aufbau

Datei:Lifekeeper softwarearchitektur.JPG
LifeKeeper-Softwarearchitektur

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 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- Konfigurationsdatenbanken 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

Datei:Lifekeeper verhalten im fehlerfall.JPG
LifeKeeper Verhalten im Fehlerfall

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.

Datei:Lifekeeper nway failover.JPG
LifeKeeper N-Way Failover

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.

Datei:Lifekeeper cascading failover.JPG
LifeKeeper Cascading Failover

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:

3 Datenzugriff

Datei:Lifekeeper datenzugriff.JPG
LifeKeeper Verhalten im Fehlerfall

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

5 Weblinks

6 Init-Quelle

Entnommen aus der: Wikipedia

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

Für diesen Artikel fehlt ein Link zur Löschdiskussion und/oder die Kategorie:WikiPedia Deleted
Hier ist die Anleitung zum Finden der Löschdiskussion

Diesen Artikel melden!
Verletzt dieser Artikel deine Urheber- oder Persönlichkeitsrechte?
Hast du einen Löschwunsch oder ein anderes Anliegen? Dann nutze bitte unser Kontaktformular

PlusPedia Impressum
Diese Seite mit Freunden teilen:
Mr Wong Digg Delicious Yiggit wikio Twitter
Facebook




Bitte Beachte:
Sämtliche Aussagen auf dieser Seite sind ohne Gewähr.
Für die Richtigkeit der Aussagen übernimmt die Betreiberin keine Verantwortung.
Nach Kenntnissnahme von Fehlern und Rechtsverstößens ist die Betreiberin selbstverständlich bereit,
diese zu beheben.

Verantwortlich für jede einzelne Aussage ist der jeweilige Erstautor dieser Aussage.
Mit dem Ergänzen und Weiterschreiben eines Artikels durch einen anderen Autor
werden die vorhergehenden Aussagen und Inhalte nicht zu eigenen.
Die Weiternutzung und Glaubhaftigkeit der Inhalte ist selbst gegenzurecherchieren.


Typo3 Besucherzähler - Seitwert blog counter
java hosting vpn norway