Hewlett-Packard: "Cluster Consistency Monitor" bietet Schutz durch Simulation

Rubrik: Markt/Hintergrund

Unstimmigkeiten in der Cluster-Konfiguration während des Normalbetriebs erkennen

(05.12.02) - In der heutigen Zeit sind viele Unternehmen auf die permanente Verfügbarkeit ihrer IT-Infrastruktur und Applikationen angewiesen. Bereits Ausfallzeiten von wenigen Minuten können großen finanziellen Schaden verursachen. Um sich pro-aktiv vor Systemausfällen zu schützen, verwenden viele Unternehmen Cluster-Lösungen, vor allem in SAP-Umgebungen. Dies bedeutet, ein zweiter Rechner übernimmt unverzüglich die Aufgaben der ausgefallenen Node. Mit diesem Ansatz ist es möglich, Hardwareausfälle oder Störungen im Betriebssystem durch eine redundante Konfiguration abzufangen. Dieses Prinzip des Wiederanlaufs durch redundante Hard- und Software ist seit vielen Jahren Industriestandard und hat sich vielfach bewährt. Doch seine Möglichkeiten sind begrenzt und somit wird in der IT-Branche an einem Verbesserungsprozess gearbeitet. HP setzt hierbei auf das Prinzip "Cluster Consistency Monitor" (CCMon).

Grenzen der redundanten Konfiguration

Doch zunächst ein Blick auf das gängige Prinzip der redundanten Cluster-Lösung. Um im Fall einer Störung einwandfrei zu funktionieren, müssen bei diesem Prinzip alle Nodes in einem Cluster die gleiche Konfiguration haben. Dies ist in der Praxis jedoch nicht der Fall. So ist es durchaus üblich, dass Änderungen, wie zum Beispiel das Installieren neuer Software oder das Aufsetzen eines neuen Benutzers, nur am aktiven Server vorgenommen werden und der Ersatzrechner übersehen wird. Fällt jedoch der aktive Server aus, kann das System unter Umständen nicht mehr richtig arbeiten. Bei einer solchen Cluster-Lösung müssen nach jeder Änderung Umschalttests vorgenommen werden, damit die Redundanz gewährleistet ist. Diese Tests führen zu höheren geplanten Ausfallzeiten einer Applikation. Außerdem decken Umschalttests als Methode der Cluster-Verifikation nur einen Teilbereich der Funktionalität ab, beispielsweise nicht die Archivierungen oder Schnittstellen. Der Start eines SAP- R/3 Systems auf einer neuen Hardware bedeutet nicht implizit, dass beispielsweise alle Interface-Datensysteme wie Drucken, Faxen, Datenaustausch und Archivierung ebenfalls funktionieren.

Es ergeben sich noch weitere Probleme aus diesem Lösungsansatz, die an dieser Stelle kurz angerissen werden sollen:

· Die Installation und der Betrieb einer Applikation in einem Cluster sind überaus kompliziert und erfordern tiefes Know-how – sowohl über Cluster und Betriebssysteme als auch über die Applikation selbst. Oft ist dieses Wissen in großen Unternehmen jedoch auf verschiedene Personen verteilt.

· Jede Änderung in einem existierenden Cluster kann zu Störungen in der Hochverfügbarkeit führen.

· Nicht funktionale Cluster wirken sich im Normalbetrieb nicht aus. Falls jedoch durch eine Störung ein Failover notwendig wird, kann eine Applikation häufig nicht oder nur mit eingeschränkter Funktionalität auf eine redundante Hardware umgeschaltet werden. Die Folgen sind unabsehbar.

· Die Anforderung einer produktiven, unternehmenskritischen Applikation sind in der Regel so wenig geplante Ausfallzeiten wie möglich. Dies führt dazu, dass in den kurzen Wartungsfenstern alle geplanten Arbeiten zusammengefasst werden. Häufig bleibt keine Zeit für Verifikationen.

Mehr Sicherheit durch Cluster Consistency Monitor (CCMon)

Den oben angerissenen Problemen und Nachteilen einer redundanten Lösung wird heute durch automatisierte, regelbasierende Systeme begegnet, die das Management eines Applikations-services aktiv unterstützen. Das Basisprinzip eines Cluster Consistency Monitors (CCMon) ist es, die Sicht einer Applikation an ihre Umgebung zu simulieren und diese Tests auf allen Rechnern eines Cluster-Verbundes anzuwenden.

Dazu werden zunächst entsprechende Daten über die Konfigurationen der einzelnen Nodes benötigt. Dazu zählen u.a. Informationen über Hardware, SWAP- und Plattenressourcen, Kernel Parameter, Sicherheitseinstellungen, Benutzer und Benutzergruppen. Diese werden von dem Kollektorprogramm zur Verfügung gestellt. Die gesammelten Informationen einer Node werden in einer Datenbank (RSDB) gespeichert. Der CCMon liest die benötigten Daten aus und vergleicht sie mit einem gespeicherten Profil (CCMon Comparator Profile). Anschließend wird ein Report erzeugt, der wahlweise in Ascii- oder HTML-Format ausgegeben wird.

Bedingt durch die vielfältigen Anforderungen von Applikationen und Infrastrukturen müssen Cluster Consistency Monitore adaptiv sein, d.h. an die jeweiligen Anforderungen angepasst werden können. Für Standardapplikationen wie SAP R/3 können alle bekannten und generischen Ressourcen in einer Ressourcenbeschreibung vorkonfiguriert werden. Jedoch ist es unerlässlich, die individuellen Subsysteme und Ressourcen von Installation zu Installation zu untersuchen und zu beschreiben. Selbstverständlich können durch diese Anpassungsfähigkeit auch Erweiterungen in einer Applikation, die nachträglich hinzukommen sind, in dieses Konzept aufgenommen werden.

Regelmäßige Verifikationen

Verifikationen durch einen CCMon müssen periodisch und automatisiert durchgeführt werden. Um die Effizienz und Produktivität einer IT-Abteilung zu verbessern, sollten CCMon als aktive Change Management Komponenten im Hintergrund mögliche Störungen diagnostizieren.

Funktionalitäten eines CCMon:

· Konfigurierte Ressourcenbeschreibungen erlauben eine hohe Flexibilität. Erweiterungen und Anpassungen sind einfach durchzuführen.

· Installierbar in den laufenden Systembetrieb ohne nachteilige Auswirkungen.

· Alle auf HP-UX basierenden Cluster-Lösungen können mit CCMon geschützt werden, insbesondere MC/ServiceGuard Cluster, Metro- oder Campus-Cluster, Installation von Shadow-DBs und HP Somersault.

· Verifikation automatisch oder interaktiv.

· Cluster-Monitor kann bei erkannten Abweichungen beliebige Alarme bedienen.

· Ausgabeberichte in Ascii- oder HTML-Format.

· Bestätigte Abweichungen, so dass diese nicht mehr als Fehler angesehen werden.

· Selbstüberwachung der Installation.

· Wegfall von Failover-Tests.

· Kompaktes Speicherformat – wenige 100 KB beschreiben beispielsweise eine Konfiguration mit 5000 bis 10.000 Datenpunkten. Bedingt durch diese Speicherdichte wird nur sehr wenig Hauptspeicher während einer Verifikation benötigt. Die Daten können über eine WAN-Verbindung übertragen werden.

Bei dem Cluster Consistency Monitor handelt es sich um eine Eigenentwicklung von HP. Ziel ist es, Unstimmigkeiten in der Cluster-Konfiguration schon während des Normalbetriebs zu erkennen und zu verkürzen. Sie ist bereits bei über 100 HP-internen und Kundensystemen im Einsatz. (ma)

Hewlett-Packard

Tel. (07031) 14-6260

Web: www.hewlett-packard.de