Im Zusammenhang mit den Anforderungen für hochverfügbare Anwendungen ist ein Begriff von entscheidender Bedeutung: „Resiliency“ – und zwar von Daten, Anwendungen und Devices. Die Resiliency von Daten ist nichts Neues und wird in der IT-Industrie seit langem durch diverse Technologien wie beispielsweise Raid-5 oder Mirroring im Plattenbereich sichergestellt. Ein anderes Beispiel dafür sind die bei Hauptspeicherkarten bestimmte Verfahren für „Error Detection and Correction“. Der höchstmögliche Grad an Verfügbarkeit in diesem Sinne besteht darin, ein zweites oder Backup-System im Standby-Modus zu betreiben, wobei der Wiederherstellungsprozess manuell zu erfolgen hat. Resiliency von Daten wird zukünftig aber nicht mehr ausreichen; vielmehr müssen die Anwendungen (mit den Daten) kontinuierlich verfügbar sein, um der Forderung nach Transaktionen für 24 Stunden an 365 Tagen gerecht werden zu können. Die Anwendung selbst gerät in den Mittelpunkt der Betrachtung; das heißt sie muss so „designed“ sein, dass sie wiederherstellbar sowie wiederanlauffähig ist. Im Fehlerfall müssen sowohl Benutzer als auch Anwendung so schnell und so transparent wie möglich auf einen ganz bestimmten, wohl definierten Zustand wiederhergestellt werden können; die Geschäftsprozesse dürfen also keine oder nur eine minimale Unterbrechung erfahren. Den Lösungsansatz für diesen Prozess bietet das so genannte Cluster. Ein Cluster verbindet und verwaltet auf logischer und physischer Ebene Daten, Anwendungen und Benutzer. Dabei ist es möglich, die Benutzer innerhalb eines Clusters auf alternative Knoten (Server) zu schalten und sowohl Anwendungen als auch Benutzer in einen wohl definierten Status zu bringen. IBM unterstützt und investiert in diesen Ansatz der Resiliency von Anwendungen durch das so genannte ClusterProven-Programm. Eine ClusterProven-Anwendung auf der iSeries ist eine Anwendung, die in die Cluster-Infrastruktur des Betriebssystems OS/400 eingebunden ist und auf bestimmte Ereignisse der so genannten „Cluster Resource Services (CRS)“ reagiert. Diese CRS rufen ein Exit-Programm auf, um bestimmte Schritte abzuarbeiten, die für bestimmte Operationen (beispielsweise „Failover“) durchzuführen sind. So hat ein Bankkunde diesen Lösungsansatz der ClusterProven-Anwendungen für Testzwecke verwendet, indem er an einem Wochenende 21-mal zwischen seinem Produktions- und Backup-System umgeschaltet hat.

Methoden für Resiliency von Daten

Im Zusammenhang mit der Resiliency von Daten stehen zwei Methoden zur Verfügung: „Replication Services“ und „Resilient Devices“. Replication Services sind eine Methode um in Real-Time ein Duplikat der Produktionsdaten auf einem zweiten System zu erstellen. Resilient Devices sind in Verbindung mit der Topologie von „Switchable“-Platten von Bedeutung; denn Resilient Devices sind physisch mit mehreren Knoten in einem Cluster verbunden. Der physische Besitz kann dabei von einem auf den anderen Knoten übergehen, wobei die Vereinigung von Daten, Benutzern und Anwendungen Bestandteil des Umschaltprozesses sind. In diesem Szenario wird für den Fall, dass innerhalb eines Clusters ein Knoten ausfällt, der logische Besitz des Switchable-Platten-Towers an einen anderen Knoten des Clusters übergeben und die Benutzer werden ihren operationalen Betrieb erst wieder aufnehmen können, nachdem das Netz umgeschaltet (IP-Switch), der Zugriff zu den Daten etabliert und somit die komplette Umgebung für Benutzer und Anwendungen wieder hergestellt ist. Bei der iSeries wird dieses Konzept der „Switched Disk Solution“ auch als IASP (Independent Auxiliary Storage Pool) bezeichnet.

Die folgenden Abbildungen 2 und 3 verdeutlichen die Konzepte von Replication Cluster und Switchable Disk Cluster (Resilient Devices).

Im Zusammenhang mit den beiden bisher diskutierten Topologien für Clustering gibt es einen weiteren methodischen Ansatz für Hochverfügbarkeit. Dieser kommt aus dem „Storage Area Network“ bzw. SAN-Umfeld. Hierbei wird die Resiliency der Daten dadurch erreicht, dass innerhalb des Storage-Servers oder zwischen den Storage-Servern eine Kopie der Daten erzeugt wird. Die Resilient Devices sind Raid-5 Arrays oder werden gespiegelt und basieren auf redundanter, Switchable-Hardware. Diese Technologie erlaubt zwar eine sehr hohe Resiliency der Daten, aber – und das ist der entscheidende Punkt – diese Technologie ist unabhängig vom Host-System. Das heißt: Diese Technologie ist nicht in die komplette Cluster-Lösung eingebunden. In Abbildung 4 wird dieses Konzept dargestellt.

Die Resiliency Services auf Basis des SAN-Konzeptes erstellen eine Kopie der Daten. Dieser Vorgang findet aber ohne die Einbeziehung des Betriebssystems OS/400 statt. Somit findet zwar eine Erweiterung der Daten des primären Host-Systems statt, es fehlt aber die logische Einbindung dieser Daten in das Backup-System. Erst durch die logische Einbindung auf dem Backup-System kann auf die Daten im Recovery-Prozess zugegriffen werden. Dieser Recovery-Prozess besitzt exakt die gleiche Charakteristik wie eine Fehlersituation bei einem einzelnen System. Das folgende Beispiel verdeutlicht dies: Es wird angenommen, dass in einem einzelnen System die Prozessorkarte ausfällt. In dem Recovery-Fall wird diese Karte ausgetauscht und im Rahmen eines manuellen Prozesses findet dann die erneute logische Einbindung der Daten (abnormal IPL) zurück in das Host-System statt. Bezogen auf eine SAN-Umgebung bedeutet dies, dass die gespiegelten Daten des zweiten Disk-Subsystems logisch genauso in das Backup-System einzubinden sind, wie es bei einem einzelnen System erforderlich ist. Ein ganz wichtiger Aspekt dieser SAN-Methode ist die Tatsache, dass die Kopie der Daten nicht gleichzeitig für andere Zwecke wie beispielsweise Datensicherung auf Band, Anwendungen mit reinen Leseoperationen, Queries etc. zur Verfügung stehen. Somit sollte der SAN-Ansatz höchstens für ein Disaster Recovery in Betracht gezogen werden – und zwar nur dann, wenn die primären und sekundären Storage-Server (aus Gründen der Integrität) synchron miteinander verbunden sind.

In diesem Zusammenhang ist es erforderlich, noch einmal darauf hinzuweisen, dass für jede Topologie der Daten-Resiliency – dies gilt sowohl für die Clustering-Techniken als auch für die SAN-Methode – das so genannte Journaling aktiv sein muss. Der Grund hierfür liegt darin, dass die Transaktionen im Hauptspeicher ausgeführt werden, die im Fehlerfall verloren gehen können und somit muss sichergestellt werden, dass die Veränderungen der Daten auf jeden Fall auf den Platten aufgezeichnet werden. Um aber die vollständige Integrität der Transaktionen gewährleisten zu können, muss die Anwendung darüber hinaus das so genannte Commitment Control beinhalten. Durch diese Technologie werden die journalisierten Veränderungen mit den Transaktionen zu einer logischen Gruppe miteinander verbunden und dann auf die Platten (Journal-Receiver) geschrieben. Tritt während der Ausführung einer Transaktion ein Fehler auf, so wird diese Gruppe nicht weggeschrieben und die Anwendung kann auf einen ganz genau definierten (integren) Zustand wieder hergestellt werden. Somit ist also Commitment Control die Basis für die Resiliency von Anwendungen.

Clustering via Daten-Replikation

Der methodische Ansatz der Daten-Replikation (wie in Abbildung 2 skizziert) ist die umfassendste Topologie in dem Sinne, dass sie die umfangreichsten Möglichkeiten hinsichtlich Flexibilität – sowohl für geplante als auch ungeplante Ausfälle – bietet. Die Daten werden kontinuierlich unter Einbeziehung des Betriebssystems OS/400 repliziert. Damit sind die Daten auf dem Backup-System gleichzeitig für andere Anwendungen verfügbar. Insbesondere kann bei diesem Ansatz das Backup-System in der Nacht für Datensicherungszwecke verwendet werden, wobei das primäre System kaum oder gar nicht unterbrochen werden muss. In Verbindung mit Resilient-Anwendungen erlaubt diese Cluster-Technologie im Fehlerfall den automatischen Wechsel (wenn gewollt, sonst mit minimalem Eingriff des Operators) auf das Backup-System.

Die Replication Services, die im Zusammenhang mit dem Clustering auf der iSeries Verwendung finden, werden von den drei so genannten High-Availability-Partnern (HABPs) angeboten: DataMirror, Lakeview Technology und Vision Solutions. In Verbindung mit diesen Lösungen ist zu empfehlen, eine Funktionalität zu verwenden, die integraler Bestandteil des Betriebssystems OS/400 ist und Remote-Journaling genannt wird. Hierbei wird die Journal-Verarbeitung automatisch auf dem Backup-System durchgeführt. Remote-Journaling kann sowohl synchron als auch asynchron durchgeführt werden. Bei der Implementierung eines hochverfügbaren Clusters – sowohl für geplante als auch ungeplante Ausfälle – sollte eine Verbindung der Systeme via High Speed Link (HSL) vorgenommen und die synchrone Variante implementiert werden. Die asynchrone Variante des Remote-Journalings könnte aus Gründen der Entfernung in Betracht kommen; dann ist es aber unbedingt erforderlich, im Vorfeld entsprechende Performance-Tests durchzuführen.

Die zweite Methode der Replication Services (siehe Abbildung 3) stellen die Switchable Disk-Cluster oder IASPs dar. In diesem Fall werden die Platten-Tower via HSL mit den beiden iSeries-Systemen verbunden. Die Daten in den Switchable-Towern sind in so genannten Auxiliary Storage Pools (ASPs) enthalten. Diese Platten-Tower können sowohl bei ungeplanten als auch bei geplanten Ausfällen (beispielsweise Hardware- oder Software-Upgrades) logisch zwischen den Systemen umgeschaltet werden. Das Cluster-Management „switched“ Benutzer und Daten des IASPs auf das Backup-System. Die Zeit für eine vollständige Wiederherstellung im Falle eines ungeplanten Ausfalles ist abhängig von der Anzahl der wieder herzustellenden Objekte und vor allem von der Robustheit (wenn Commitment Control verwendet wird) der Anwendung. Hinsichtlich eines geplanten Ausfalles (beispielsweise beim Hardware-Upgrade), ist diese Topologie hervorragend geeignet, Benutzer, Daten und Anwendungen in sehr kurzer Zeit auf dem Backup-System verfügbar zu machen. Ein Beispiel für eine ClusterProven-Anwendung, die diese Technologie verwendet ist – wie in Abbildung 5 dargestellt – Domino auf der iSeries.

Der Switchable Disk-Cluster ist an HSL gebunden und wird bei der gegenwärtigen Implementierung (OS/400 V5R1) nicht gespiegelt. Damit stellen die Platten-Tower einen „Single Point of Failure“ dar. Diese Topologie ist somit nicht für ein Disaster Recovery zu verwenden. Der wesentliche Vorteil des Switchable Disk-Clusters liegt darin, dass die Komplexität und die Kosten im Vergleich zu dem Replikation-Ansatz erheblich geringer sind. In diesem Zusammenhang ist es wichtig darauf hinzuweisen, dass zur Zeit ausschließlich das so genannte Integrated File System (IFS) unterstützt wird. Es ist geplant, in Zukunft auch Datenbankobjekte mit einzubeziehen. Für Planungsüberlegungen ist anzumerken, dass sich die Replication-Services und der Switchable Disk-Cluster nicht gegenseitig ausschließen. Es gibt zahlreiche Kunden, die momentan dabei sind, Szenarien zu implementieren, bei denen beide Technologien – abhängig von den Anwendungen – gleichzeitig innerhalb eines Clusters zum Einsatz kommen.

Die Zeit drängt – Wie starten?

Aufgrund der Tatsache, dass sich die Geschäftsprozesse und damit die Anwendungen in Zukunft dramatisch verändern werden, ist es unbedingt erforderlich, eine umfassende Strategie bezüglich Hochverfügbarkeit und Disaster Recovery zu planen und zu implementieren. Dies ist ohne Zweifel keine einfache Aufgabe. Die IBM in Verbindung mit ihren Partnern verfügt über langjährige Erfahrungen und ist in der Lage, diese Strategie zu definieren und dann auch umzusetzen. Unabhängig von der gewählten Methode steht auf jeden Fall am Beginn aller Überlegungen eine Analyse der Geschäftsprozesse, denn hieraus ergeben sich die Anforderungen hinsichtlich Hochverfügbarkeit und Disaster Recovery.

Weitere Informationen zu Hochverfügbarkeit, ClusterProven und Disaster Recovery und damit einen guten Einstieg in diese Thematik findet sich unter folgender Webseite: www.ibm.com/eserver/iseries/ha

IBM Deutschland

D–28329 Bremen

Telefon: (+49) 0421/2381-0

www.de.ibm.com