Seminar Großrechneraspekte Backup- und Administrationswerkzeuge

Seminar Großrechneraspekte Backup- und Administrationswerkzeuge Oliver Kroker

Inhaltsverzeichnis 1. Einführung 2. Backup/Recovery Werkzeuge 2.1 Backup/Recovery Grundlagen 2.2 System Managed Storage (SMS) 2.2.1 Data Facility Storage Management Subsystem 2.2.2 Aggregate Backup & Recovery Support 2.2.3 Remote Copy 2.3 Tivoli Storage Manager 2.4 Zusammenfassung zu SMS 2.5 Storage Networks 2.5.1 Storage Area Network 2.5.2 Network Attached Storage 3. Einführung in die Hardware Management Console (HMC) 3.1 Konfiguration 3.2 Licensed Internal Code (LIC) 3.3 Aufgaben und Anwendung der HMC 4. Zusammenfassung 5. Literaturangaben

1. Einführung Backup/Recovery von Daten bzw. die Verfügbarkeit von Rechnern und Anwendungen sind heute zentrale Problemstellungen bei allen Firmen und Institutionen, die ihre Daten elektronisch speichern und verarbeiten. Besonders in der Industrie sind es dabei auch finanzielle Beweggründe die Ausfallzeiten möglichst gering zu halten (am Besten sollten sie gegen Null gehen). Gleichzeitig ist es natürlich auch nur das Budget, das die Sicherungsmöglichkeiten einschränkt, wodurch der Zwiespalt zwischen Kosten und Verfügbarkeit so überbrückt werden muss, dass für den jeweiligen Fall die best mögliche gewünschte Sicherheit gegeben ist. Je mehr in Redundanz von Hardware und Software investiert werden kann, desto besser kann man sich gegen Ausfälle schützen. Durch diese Redundanz wächst aber nochmals die Größe des Systems, wodurch es wichtig für den Administrator ist, die richtigen und möglichst mächtigen Werkzeuge für die Konfiguration der Hardware und für die Datenverwaltung zur Verfügung zu haben. Unter OS/390 von IBM gibt es zum einen Teile des Betriebssystems wie das Data Facility Storage Management Subsystem (DFSMS), die bei der Datenorganisation und verwaltung helfen aber auch zusätzliche Softwarepakete wie der Tivoli Storage Manager, die als kommerzielle Produkte noch mehr Unterstützung und Automatisierung bieten sollen. Für die Überwachung und Konfiguration der Hardware wird in IBM Großrechnern die Hardware Management Console (HMC) verwendet, die eine zentrale Kontrollinstanz für sämtliche Statusmeldungen in einem IBM Großrechner bildet. Per LAN angebunden bietet sie verschiedene Möglichkeiten zur Problemanalyse und Lösung. Im folgenden werden nun einige Werkzeuge und Szenarien hinsichtlich dieser Anforderungen vorgestellt. 2. Backup/Recovery Werkzeuge 2.1 Backup/Recovery Grundlagen: Besonders in großen Systemen ist es notwendig, einen Recoveryplan zu erstellen der die möglichen Problemfälle für dieses spezielle System und die zugehörigen Lösungen zusammenfasst, um größtmögliche Sicherheit zu erreichen. Dieser muss von Administrator und User zusammen erstellt werden, da zwar der Administrator weiß, welche Systemdaten und Programmdaten gesichert werden müssen, aber welche Nutzdaten was für eine Priorität für den laufenden Betrieb haben, muss der User mit ihm klären. Der User in diesem Sinne ist hier nicht der gemeine Mitarbeiter an seinem Rechner, sondern sicherlich auch ein spezieller Administrator für diesen Software- und Datenbereich. Es wird dazu geklärt in was für Intervallen welche Daten gesichert werden müssen und wie viel Kopien davon auf was für Medien gemacht werden sollen. Dabei gibt es für Backups verschiedene Strategien. Mit einem Vollbackup werden immer alle Daten komplett gesichert. Das ist bezüglich benötigter Zeit und Speicherplatz sehr kostenintensiv, und kann damit für eine Sicherung aller paar Minuten nur schlecht verwendet werden. Besser eignet sich dazu das Inkrementelle Backup, das einmal alles sichert und bei darauffolgenden Backups nur noch die geänderten Datenobjekte übernimmt. Dabei besteht aber immer noch das Problem das alle Daten gleich behandelt werden. Das löst das Partielle Backup, indem es verschieden Datenobjekte zu verschiedenen Zeitpunkten, unterschiedlich oft sichert. Zusätzlich zu diesen Sicherungsstrategien wird festgelegt, wie die Wiederherstellung im Fehlerfall zu erfolgen hat. Bei der Erstellung solcher Strategien helfen auch die folgenden 7 Recoverystufen, die Beispiele für verschiedene Sicherungsszenarien zeigen und damit die Grundlage für eigene Lösungen bilden können:

In Stufe 0 ist keinerlei Disasterrecoveryplan aufgestellt und es werden keinerlei Backups erstellt, die extern gespeichert bzw. gelagert werden. Die Stufe 1 beinhaltet die sogenannte Pickup Access -Methode (PTAM) bei der Backups erstellt werden und diese meist täglich außerhalb gelagert werden. Damit ist für den extremen Fehlerfall wie zum Beispiel Feuer oder Erdbeben die Sicherheit der Daten gegeben. Diese Form ist natürlich sehr zeitaufwendig bei der Wiederherstellung, da die Sicherungskopien erst von außerhalb geholt werden müssen um dann wieder eingespielt zu werden, womit die Zeit für den Recoveryvorgang gewöhnlich bis zu eine Woche beträgt. Außerdem ist auch der Zeitraum für den die Daten im Fehlerfall verloren gehen ziemlich groß, die dann erst wieder nachgearbeitet werden müssen. Stufe 2 erweitert die PTA-Methode um eine sogenannte Hot-Side. Das ist ein komplettes Rechnersystem, das dem zu sichernden entspricht und nur ein minimales Betriebssystem geladen hat. Im Fehlerfall werden die extern gelagerten Backups zu der Hotside gebracht und dort aufgespielt. Damit muss bei Hardwarefehlern nicht bis zur Reparatur gewartet werden, sondern sobald die Daten bei der Hot-Side ankommen, können sie eingespielt werden, wodurch sich die Down-Time drastisch reduzieren lässt. Für die Clients ist das von außen nicht sichtbar, sondern der oder die Ersatzrechner verhalten sich genauso wie das ausgefallene Original. Trotzdem kann der Datenverlust zwischen Backup und Ausfall immer noch sehr groß werden, da die mechanische externe Lagerung der Daten viel Zeit in Anspruch nimmt. Dieses Problem beginnt Stufe 3 zu beheben, die wiederum das vorherige Modell um eine elektronische Verbindung zwischen Hauptsystem und Hot-Side erweitert. Über diese werden kritische Daten häufiger direkt auf dem Reservesystem gesichert als die regelmäßigen Basis-Backups auf Offlinemedien. Damit verringert sich der Verlust von diesen Daten bei Ausfällen, aber es dauert immer noch lange bis die grundlegenden Offlinekopien wiederhergestellt werden können. Durch das Szenario der Stufe 4 wird diese Zeit nun reduziert, indem die Hot-Side aktiv wird, das heißt, dass Workload-Aufkommen wird zwischen dem Basissytem und der Hot-Side aufgeteilt und auf beiden wird gearbeitet. Damit muss auch auf beiden Systemen ein Backup auf Offline-Medien gemacht werden, aber außerdem gibt es einen elektronischen Datenabgleich zwischen beiden, der regelmäßig gleiche Systemzustände garantiert. Im Fehlerfall gehen also nur die Daten seit dem letzten Abgleich verloren, und zusätzlich stehen immer noch die extern gelagerten Sicherheitskopien zur Verfügung. In Stufe 5 wird nun der elektronische Abgleich so erweitert, dass sofort alle Daten auf beiden Seiten gespeichert werden. Wenn also auf der Basisseite gearbeitet wird, kopiert diese, die gespeicherten Daten sofort automatisch auf die Hot-Side (und umgekehrt). Bei einem Ausfall gehen also nur die zuletzt bearbeiteten Daten verloren, die noch nicht übertragen wurden. Das kann zum Beispiel durch eine Erhöhung der Bandbreite zur Datenübertragung noch optimiert werden. Damit steht im Problemfall ein weiteres voll funktionsfähiges System zur Verfügung auf dem nur ein minimaler Datenverlust entsteht. Stufe 6 ist dann die so genannte Zero Data Loss -Stufe bei der praktisch keine Daten verloren gehen, da das Basissystem und Hot-Side so gegenseitig abgesichert sind, dass beide immer automatisch auf gleichem Stand sind.

Abb. 1: Die Entwicklung von Zeitbedarf und Kosten in den einzelnen Stufen Viele Aufgaben, die in den einzelnen Stufen vorkommen, werden auf IBM Mainframes durch das System Managed Storage Subsystem übernommen. Im folgenden werden nun einzelne Werkzeuge von diesem Subsystem vorgestellt. 2.2 System Managed Storage Das System Managed Storage Subsystem umfasst als Bestandteil des Betriebssystems (z.b. OS/390) die gesamte Verwaltung von nichtflüchtigen Speichermedien wie Festplatten, Datenbänder, CDs, DVDs oder auch Netzwerkfreigaben. Es wird automatisch die Struktur und Organisation der Daten auf diesen Medien organisiert. Das geschieht über verschiedene Regelarten die von Administratoren definiert und von dem System angewendet werden. Neben diesen Strukturierungsaufgaben werden auch Werkzeuge für Datensicherung und wiederherstellung zur Verfügung gestellt. Die folgenden Ziele hat SMS: Die Benutzerfreundlichkeit der verschiedenen Speichermedien wie Festplatten und Bänder soll verbessert werden. Dazu gehört zum Beispiel die Verringerung der out-ofspace-zugriffe, das heißt, dass man bei dem Zugriff auf Daten nicht plötzlich in leeren Segmenten einer Platte oder in anderen Daten landet, da die Organisation dem Benutzer vorbehalten ist. Auch sollte es möglich sein einen bestimmten Block an freiem Speicherplatz zu reservieren auch wenn er bis jetzt noch nicht komplett mit Daten gefüllt ist. Die Arbeit der Storage-Administratoren soll verringert werden, in dem das Storage Management eine zentrale Kontrollinstanz bietet die alle Vorgänge, die Speichermedien betreffen, überwacht und eine Automatisierung von bestimmten Aufgaben bietet. Außerdem sollten auch interaktive Kontrollelemente zur Verfügung gestellt werden, um eine Übersicht über das System und die Aufgaben zu geben. Für den einfachen Nutzer der Speichermedien soll die Notwendigkeit sich mit Details von Performance, Speicherplatz und Device-Management auseinandersetzen zu

müssen möglichst abgeschafft werden. Damit kann dieser sich auf das Nutzen der Informationen anstatt auf das Organisieren der Daten konzentrieren Unter OS/390 stellt das Data Facility Storage Management System (DFSMS) diese Werkzeuge zur Verfügung. 2.2.1 DFSMS Das DFSMS bietet mit einem Speichermanager (DFSMShsm) und den Datensatz-Services Tools für die automatische Speicherverwaltung. Der Administrator definiert eine Poolstruktur von dem gesamten Speicherplatz der ihm zur Verfügung steht. Dabei spielt es keine Rolle wie der Speicherplatz auf möglicherweise verschiedenen Medien verteilt ist, sondern nur das er vorhanden ist und dem Pool bekannt gemacht wurde. Diese Menge wird dann in verschiedene Speichergruppen unterteilt, die jeweils eigene Automatic Class Selection (ACS) Routinen besitzen. Diese Routinen beinhalten die Regeln für die Zuteilung von bestimmten Daten zu einer Speichergruppe, und müssen von dem Administrator festgelegt werden. Es gibt 3 unterschiedliche Klassen von diesen Routinen: die Data Class, die Storage Class und die Management Class: Die Data Class enthält Attribute über das Filesystem wie das Format der Datenrecords oder die Recordlänge. In der Storage Class sind Performanceangaben enthalten. Dazu gehört unter anderem die Antwortzeit von Devices, die für Daten, deren Zugriff zeitkritisch erfolgt, wichtig ist. Diese Daten werden, falls sie entsprechend deklariert sind, dann automatisch auf Medien mit einer geringeren Antwortzeit gespeichert. Zu dieser Klasse gehören auch Angaben über die Nutzung von verschiedenen Caching-Strategien der unterschiedlichen Devices, was wiederum Einfluss auf die Zugriffsperformance hat. Die Management Class beinhaltet unter Anderem Angaben zur Backupanzahl bezüglich der Daten der jeweiligen Speichergruppe, oder auch ab welchem Zeitpunkt Daten als veraltet gelten und dann auch automatisch gelöscht werden können (falls das gewünscht ist). Damit vereinfacht sich für den Benutzer die Arbeit enorm, da das System eine zentrale Kontrollinstanz bildet, und automatisch entscheiden kann wo es wie viel Speicher für die aktuell zu speichernde Datei benötigt. Damit aber auch die Daten richtig den Speichergruppen zugeordnet werden können, sind zusätzliche Informationen, die sogenannten Control Data Sets (CDS), notwendig. Diese beinhalten die Metadaten der vom DFSMS kontrollierten Daten: Das Migration CDS (MCDS) enthält dabei die Informationen über die Benutzer und die Anwendungen zu denen die jeweiligen Dateien gehören. Das beinhaltet auch Zugriffsrechte auf die Daten durch Clients und Programme. Im Backup CDS (BCDS) sind die Informationen zur Datensicherung und deren Wiederherstellung enthalten. Diese sind für die Organisation des Backups notwendig, wie zum Beispiel wann welche Daten gesichert werden müssen (welche Priorität sie haben) und für den Recoveryfall wo sie wieder hergestellt werden müssen. Letzteres ist besonders wichtig falls sich das zu sichernde Basissystem und die Hot-Side in Hardware- und Softwarekonfiguration unterscheiden, aber die Daten dennoch gleichartig zur Verfügung stehen sollen. Das Offline CDS (OCDS) enthält Daten über die gesicherten Dateien, insbesondere wo und auf welchen Medien die Dateien gesichert werden. Das ist insbesondere wichtig für die Verwaltung großer Bandbibliotheken in denen sich Tausende Bänder befinden.

Nur mit diesen CDS-Informationen ist die Recovery der Sicherheitskopien auf Hot-Sides mit differenzierter Hardware und Struktur möglich. 2.2.2 Aggregate Backup and Recovery Support (ABARS) ABARS ist der Teil des DFSMShsm (des Speichermanagers), der speziell für Backup und Recovery zuständig ist. Für seinen Betrieb benötigt es folglich auch ein aktives DFSMS, da es die oben vorgestellten Regeln und Metadaten (ACS und CDS) für die Datensicherung verwendet. Gut skalierbar ist dieses System unter anderem dadurch, dass bis zu 64 eigene Tasks im Adressbereich des DFSMShsh gestartet werden können. Durch die Control Data Sets (CDS) werden die Dateien, die unter Kontrolle des DFSMS abgespeichert sind, in kritisch und unkritisch unterschieden. Diese Unterscheidung ist nur unter Zusammenarbeit von den verschiedenen Administratoren (Systemadministrator, Anwendungsadministrator...) bzw. mit den Nutzern (je nach dem wie groß das System ist) möglich, da nur die jeweilige Person entscheiden kann welche Daten und Anwendungen was für eine Priorität bei der Sicherung haben. Das Backup selbst geschieht durch das Abackup- Programm, das die Daten und die zugehörigen Metadaten zusammen sichert. Diese werden in Tape-Storage-Groups unterteilt, die Storage-Groups mit den Tape-Libraries verbinden, um so eine übersichtliche Verwaltung der Speichermedien in diesen Bibliotheken zu ermöglichen. Dazu gehört im Fehlerfall wo ein bestimmtes Backup zu finden um es wiederherstellen zu können, oder das bestimmte Bänder veraltet sind und deshalb gelöscht werden können um wieder zur Verfügung zu stehen. Diese ganzen Abläufe geschehen automatisch in den Tapelibraryries genauso wie das Einund Auslagern der Kopien in diesen. Die durch Abackup erstellten Sicherungskopien, die sogenannten Aggregate, enthalten drei Dateitypen: Das Aggregation Control File enthält Informationen über die Hardwareumgebung und das System von dem das Backup erstellt wurde, um eine Recovery auf dazu verschiedenen Systemen zu ermöglichen. Das Instruction Data Set enthält die Informationen, wie Benutzerrechte oder zugehörige Anwendung, über die gesicherten Dateien. Im Aggregation Data File sind die eigentlich zu sichernden Dateien enthalten Dabei enthalten die ersten beiden Dateien letztendlich nur die Informationen aus den oben beschriebenen ACS und den CDS. Der Befehl zum Abackupaufruf kann entweder explizit auf einer Konsole direkt am Rechner oder remote ausgeführt werden, oder es kann auch in ein Programm als eine Art Batch- Betrieb aufgerufen werden. Damit ist es auch möglich diese Aufrufe zu automatisieren, um regelmäßig bestimmte Daten zu sichern. Für den Wiederherstellungsprozess ist auf der Hot-Side ein laufendes OS/390 Betriebssystem notwendig, da Arecover das Data Facility Storage Management Subsystem mit dem DFSMShsm braucht. Dann werden zunächst die Backups der Metadaten wiederhergestellt. Das ist nötig, um die eigentlichen Daten dann richtig zuordnen zu können. Besonders bei einer unterschiedlichen Struktur der Hot-Side im Vergleich zum Basissystem ist das wichtig, da der Storage-Pool, der vom SMS kontrolliert wird, dann eine andere Organisation haben kann. Als nächstes werden die eigentlichen Daten wiederhergestellt, die eventuell durch eigene Backups der User ergänzt werden. Für den Fall das die eigentlichen Backupkopien auch in Mitleidenschaft gezogen wurden, müssen die hoffentlich vorhandenen Kopien der Bänder für die Recovery dafür genutzt werden. Zuletzt werden die Log-Files wieder eingespielt, um daraus falls möglich die Aktionen, die im letzten Backup vor dem Crash noch eingespielten Dateien nicht noch einmal wiederhergestellt werden. Für den Fall eines Konfliktes während des Recoveryprozesses ( wenn zum Beispiel eine Datei an dem Zielort schon existiert) gibt es verschiedene Möglichkeiten: Ersetzen: Die vorhandenen Daten werden von dem Backup überschrieben.

Umbenennen der Source: Die Sourcefiles werden unter einem anderen Namen wiederhergestellt. Umbenennen des Ziels: Die schon vorhandenen Elemente werden umbenannt und die Sourcen unter ihrem normalen Namen wiederhergestellt. Auslassen dieser Sourcen: Die kritischen Elemente bei der Recovery werden einfach ausgelassen, und die vorhandenen Dateien bleiben bestehen. Welches Vorgehen in einem solchen Fall gewählt wird, kann vorher global bzw. für bestimmte Dateitypen festgelegt werden, oder es gibt eine Abfrage des Systems was geschehen soll. Abb. 2: In dieser Darstellung des Recoveryprozesses sind rechts die Backups der Metadaten, die für die Wiederherstellung auf der Hot-Side notwendig sind (CDS back, Disaster Agg) und die der eigentlichen Daten dargestellt (ABARS tapes, TAPEREPL alternates, Arch Logs). Die Pfeile zeigen die einzelnen Stufen der Wiederherstellung auf der Hot-Side (rechte Seite). Zuerst werden die Metadaten wiederhergestellt um das System vorzubereiten (CDS Recovery für Control Data Sets und ARECOVER für die Datenkataloge (Catalogs)) und darauf folgt die Recovery der eigentlichen Daten (ARECOVER auf SMS- oder non-sms Plattensysteme), die durch Sicherungen der Anwender (User Tapes) ergänzt werden können. ML1 und 2 sind eine Unterteilung der Datenträger in Platten (Migrationlevel 1) und Externspeicher (Migrationlevel 2) auf welche die Recovery erfolgt. Zuletzt werden die Log-Files ausgewertet (Apply Logs) um das System möglichst genau wiederherzustellen. 2.2.3 Remote Copy Zwei weitere Werkzeuge zur Datensicherung sind Extended Remote Copy (XRC) und Peerto-Peer Remote Copy (PPRC), die zum Datenabgleich zwischen System und Hot-Side verwendet werden können. XRC ist ab Recoverystufe 4 einsetzbar also zum Beispiel auch bei Wide-Area Parallel Sysplex. Das sind Großrechnernetze die zwar eng gekoppelt sind, bei denen aber die Einzelrechner räumlich bis zu mehreren Hundert Kilometer getrennt sind. Dabei ist aber dennoch, um ein reibungsloses Zusammenspiel zu gewährleisten, ein unmittelbarer und dauerhafter Datenabgleich zwischen den Rechnern über eine Breitbandverbindung notwendig. Diese Aufgabe kann XRC übernehmen, da bei dieser Remote Copy Methode ein

Zeitunterschied zwischen dem Speichern auf dem Localhost und dem Speichern auf dem Remotehost möglich ist. Die Daten werden dabei asynchron kopiert, wodurch der Localhost während des Kopiervorgangs normal weiter arbeiten kann ohne auf eine Bestätigung der Gegenseite zu warten, und das wiederum hält den Datenverlust bei Systemausfall oder Verbindungsproblemen gering. Im Gegensatz dazu ist PPRC auf eine Verbindungsentfernung von 40 Kilometern beschränkt und benötigt dafür Glasfaserverbindungen. Der Kopiervorgang dauert länger und ist mit zunehmender Distanz zwischen den Rechnern immer kritischer, da das Kopieren synchron geschieht, und damit immer auf die Bestätigung der jeweiligen Gegenseite gewartet werden muss um die Arbeit fortzusetzen. Der Vorteil dieser Methode ist jedoch, dass sie vollautomatisch ablaufen kann, währenddessen XRC teilweise Nutzereingaben für die Durchführung braucht. 2.3 Tivoli Storage Manager (TSM) Der Tivoli Storage Manager ist ein Client-Server-System von IBM für die verschiedensten Betriebssysteme und umgebungen (dazu gehören zum Beispiel: OS/390, verschiedene Unixe, Linux,...), das die Speicherverwaltung und Systemmanagementaufgaben übernehmen kann. Der TSM ist ein optionales Programmpaket von IBM, das die Aufgaben des DFSMS übernehmen kann und noch eine verbesserte und vereinfachte Organisation vor allem der Nutzdaten ist großen Systemen ermöglicht. Client-Server-System bedeutet, dass es zum einem Clients gibt, die von verschiedener Art sein können: i386-architektur, VAX,... aber auch verschiedenste Großrechner wie eben die S/390. Die Clients werden zentral von einem Mainframe überwacht, auf dem der TSM-Server läuft, und von diesem wird die Administration und Sicherung der Daten übernommen. Die Verbindung zwischen Client und Server kann auf unterschiedliche Art und Weise geschehen. Sie können durch ein übliches Wide Area Network (WAN) oder Local Area Network (LAN) verbunden sein oder aber auch durch ein Storage Area Network (SAN). Über diese Netzwerke werden die Daten möglichst intelligent verschickt, um die Netzlast bei Sicherungen so niedrig wie möglich zu halten. Dazu ist in den TSM eine relationale Datenbank integriert, die die Attribute der Daten auf den Clients und die Struktur der Daten im Offline-Speicher enthält. Mit Offline-Speicher sind hier vor allem Bandmedien gemeint die von dem TSM in Tape-Storage-Libraries verwaltet werden. Außerdem enthält die Datenbank wichtige Informationen bezüglich des Versionsmanagements, das heißt, was es für unterschiedliche Sicherungsvarianten bestimmter Daten gibt, ob sie eventuell zu bestimmten Zeitpunkten zu ersetzen sind, oder wann sie veraltet sind und gelöscht werden können, um den Speicherplatz wieder frei zu geben. Neben diesen Bibliotheken wird außerdem ein Storage-Pool, der aus Speicherkapazitäten auf Festplatten zusammengesetzt ist, organisiert. Der gesamte Vorgang der Datenadministration und sicherung erfolgt automatisch. Dazu existiert im TSM eine flexible Policy Engine, die sich bis hinunter auf die Ebene von einzelnen Dateien mit Regeln durch den Administrator konfigurieren lässt. Dadurch sind globale Standardeinstellungen genauso wie ganz genau auf bestimmte Daten zugeschnittene Anpassungen möglich, die wenn sie einmal spezifiziert wurden nur noch minimale Eingriffe von außen im laufenden Betrieb benötigen. Falls nun Daten von bestimmten Clients gesichert werden sollen, werden über das jeweilige Netzwerk vom Server Anfragen geschickt, und die benötigten Daten werden zu ihm kopiert. Dort werden die Daten zunächst in dem Disk-Storage-Pool zwischengesichert, um kurzfristig einen schnellen Zugriff im Fehlerfall zu gewährleisten. Da ein solches Online-Backup aber verhältnismäßig teuer ist, werden die Daten je nach Priorität automatisch nach einer bestimmten Zeit auf den Tape-Storage-Pool ausgelagert. Es wird also ein Offline-Backup gemacht, um damit Kosten zu sparen, aber die Performance sinkt natürlich, da im

Recoveryfall nun erst die Bänder aus den Storage-Libraries geholt und eingelesen werden müssen. Zusätzlich zu dem Tape-Storage-Pool gibt es noch den Copy-Storage-Pool, der auch Bandmedien verwaltet. Er erhält bei einer Offline-Auslagerung von Daten automatisch eine Kopie von diesen und bietet somit eine zusätzliche Absicherung. Falls es bei der Datensicherung über das Netzwerk zu einem Verbindungsabbruch kommt, kann durch das Versionsmanagement der integrierten Datenbank nach dem Wiederherstellen der Verbindung entweder die Sicherung an der Stelle fortgesetzt werden an der sie unterbrochen wurde, oder es kann auch automatisch die neueste Version gesichert werden, und die alte wird gelöscht. Abb. 3: Der Backupprozess des Tivoli Storage Managers Der Wiederherstellungsvorgang von Daten muss entweder vom Administrator selbst am Server initiiert werden, indem dem TSM mitgeteilt wird welche Clients bestimmte Daten für die Recovery benötigen, oder die Anfragen können auch direkt von Clients aus an den Server gestellt werden. Dieser überprüft in seiner Datenbank, was für Versionen der angeforderten Daten im Disk-Storage-Pool und Tape-Storage-Pool vorhanden sind und schickt, falls nicht eine ältere Version angefordert wurde, die aktuellste an die Clients. Falls die Daten im Tape- Storage-Pool liegen, dieser aber nicht verfügbar ist, oder ein Medienfehler der Tapes vorliegt, wird auf die Sicherungskopie des Copy-Storage-Pools zurückgegriffen. 2.4 Zusammenfassung zu SMS Alle diese vorgestellten Werkzeuge beinhalten insgesamt nun die folgenden Vorteile von System Managed Storage: Die Vereinfachung der Verteilung von Speicherplatz an bestimmte Daten ist ein wichtiger Vorteil von SMS, denn ansonsten müsste der Nutzer genau festlegen auf welcher Unit, in welchem Volume und unter welchem System die Daten abgelegt werden sollen. Außerdem müsste er genau berechnen wie viel Speicherplatz die Dateien in Tracks oder Zylindern auf der Platte brauchen. Der einfache Benutzer

müsste also systeminterne Informationen haben. Das alles wird ihm von dem SMS abgenommen, er muss höchstens den benötigten Speicherplatz in Mega- oder Gigabyte angeben, den Rest erledigt das System automatisch. Die verbesserte Kontrolle über die Speicherplatzzuordnung ermöglicht es, einen bestimmten Bedarf an Speicherplatz über eine Menge von Direct Access Storage Devices (DASD)-Volumes zu verteilen. Das System sucht automatisch einen genügend großen Speicherplatz und legt die Daten dort ab, womit out-of-space- Zugriffe fast ausgeschlossen werden können. In den Tape-Libraries ist es in diesem Zusammenhang möglich, eine bestimmte Anzahl von leeren Bändern anzugeben, damit immer genug Medien vorhanden sind. Das I/O Performance Management wird dahingehend verbessert, dass es möglich ist einer bestimmten Klasse von Daten ein Performanceziel zuzuordnen. Das bedeutet zum Beispiel das zeitkritischere Daten auf Medien mit einer geringeren Zugriffszeit gespeichert werden. Ein automatisiertes DASD-Speicherplatz-Management erlaubt es Speicherplatz von alten und ungenutzten Daten freizugeben, falls dieser benötigt wird. Mit Regeln kann bestimmt werden wie lange bestimmte Daten ungenutzt auf Volumes bleiben, auf denen eigentlich die aktiven Daten (die dauernd benutzt werden) gespeichert sind. Über diese Regeln wird auch festgelegt ob das System diese Daten dann auf andere Platten oder auf Offlinemedien (Band, CD...) ausgelagert werden soll, oder ob sie einfach gelöscht werden. Auch Offlinemedien wie Bänder, CDs oder DVDs können in das automatische Speicherplatzmanagement einbezogen werden. Dabei geht es vor allem um die bestmögliche Nutzung der Speicherplatzkapazität. Aber auch das automatische Laden von zum Beispiel Bändern aus einer Tape-Library ist darin inbegriffen. Besonders wichtig ist natürlich auch die Datenverfügbarkeit und deren Administration. Es können unter dem SMS die verschiedensten Daten auf einem DASD-Volume liegen, die aber alle eigene Anforderungen an das Backup stellen. So kann man zum Beispiel DB2 Datenbanken oder Partitioned Data Sets Extended (PDSE) automatisch vom gleichen Volume auf unterschiedliche Art und Weise sichern. Für besonders kritische Daten, auf die dauernder Zugriff gewährleistet sein muss, gibt es Concurrent Copy, das die Datenverfügbarkeit auch während des Backups sichert. Eine einfache Auslagerung der Daten auf andere Devices ist möglich, da es keine feste Bindung zu einer Unit oder einem Volume gibt. Das ist besonders für Hardwareadministratoren wichtig, um alte gegen neue Geräte austauschen zu können, die meist eine höhere Speicherkapazität haben. 2.5 Storage Networks Die im folgenden vorgestellten zwei Varianten von Storage Networks sind weniger Werkzeuge für Backup & Recovery, als vielmehr Zielmedien um die Backups zu speichern und von da aus wiederherzustellen.

2.5.1 Storage Area Network (SAN) Ein Storage Area Network ist ein dediziertes Netzwerk für die Datenspeicherung, das sich aus mehreren Knoten zusammensetzt, auf denen der Speicherplatz verteilt ist. Dabei gibt es eine any-to-any Verbindung zwischen den einzelnen Knoten. Dieses verteilte Speicher- und Backupmedium ist meist per Glasfaser an Großrechner angebunden, und bietet damit eine hohe Performance. Über diese Glasfaserverbindung wird ein mit SCSI verwandtes Protokoll verwendet, das für hohe Geschwindigkeiten prädestiniert ist. Durch diese Verbindungsart lässt sich ein SAN auch dezentral aufbauen, das heißt zwischen den einzelnen Knoten sind Distanzen von bis zu 10 Kilometern möglich. Die Knoten an sich sind keine Rechner, sondern nur Festplatten mit ihrer Steuerungshardware und den Anschlüssen untereinander. Administriert und gesteuert wird ein solches System von einem Server aus, der zum Beispiel den Tivoli Storage Manager nutzt. Mit dieser Software ist auch ein so genanntes Server-free Backup möglich, das heißt für die Sicherung ist kein Server notwendig, der den Datentraffic verarbeiten muss, sondern nur ein Rechner mit dem TSM. Mit einer angeschlossenen Tape- Library übernimmt der TSM automatisch die Sicherung der Daten von den Knoten direkt auf Bänder. Ein großes Plus bei der Verwendung von SANs ist das dedizierte Netzwerk. Dadurch kann unter anderem bei Backups der Traffic im LAN, durch das die Clients verbunden sind, auf ein Minimum reduziert werden, da nur wenige Steuerungsdaten darüber mit dem TSM-Server abgeglichen werden müssen. Insbesondere für Datenbanken und ähnliche Anwendungen, die kaum auf Filelevel arbeiten, ist positiv, dass Anfragen im Blocklevel an das SAN gestellt werden. Damit ist es möglich nur einzelne Blöcke auszulesen oder zu schreiben, also in Bezug auf Datenbanken können zum Beispiel einzelne Datensätze ausgelesen werden, die vielleicht ein paar Kilobyte groß sind, und nicht eine mehrere Gigabyte große Datei die alle Datensätze der Datenbank enthält. Abb. 4: Ein Beispiel für die Nutzung eines SANs: Oben sind die Clients dargestellt, die entweder über ein Netzwerk verbundene Workstations oder Mainframes sein können (rot). Der untere Teil bildet das SAN, das aus den Plattenarrays (Disk storage arrays, Non-RAID disks) und Tape-Libraries besteht. Der Zugriff vom LAN auf das SAN ist hier über Server geregelt, auf denen dann zum Beispiel zur Verwaltung der Tivoli Storage Manager läuft.

2.5.2 Network Attached Storage (NAS) Network Attached Storage nutzt im Gegensatz zu SANs die Infrastruktur und die Protokolle des LANs wie zum Beispiel Ethernet und TCP/IP oder Netbios. Dadurch wird natürlich bei der Übertragung von großen Datenmengen oder vielen gleichzeitigen Zugriffen das lokale Netzwerk ausgebremst, was sich auf die Produktivität der anderen Clients, die mit diesen Zugriffen eigentlich nichts zu tun haben, negativ auswirkt, da sie alle um die Bandbreite des Netzes konkurrieren. Das hat zur Folge, dass ein NAS für Backups großer Installationen schlecht geeignet ist, wenn es nicht zumindest ein eigenes lokales Netzwerk bekommt. Von der Struktur her ist ein NAS eigentlich nur der Zusammenschluss von Speicherplatzfreigaben normaler Fileserver. Damit können beliebige Fileserver zusammengefasst werden, egal ob sie unter Windows NT, Unix, Linux oder OS/390 laufen, aber es werden jeweils vollständige Rechner benötigt die für Dateifreigaben konfiguriert sind. Es gibt nicht solche Möglichkeiten wie das Server-free Backup im SAN, sondern nur die Möglichkeit des LAN-free Backup, indem eine Tapelibrary mit den einzelnen Servern jeweils direkt verbunden wird. Außerdem werden, wie bereits aus dem Aufbau ersichtlich ist, bei Anfragen nur ganze Dateien verarbeitet (es wird also auf Filelevel gearbeitet). Im Gegensatz zu SANs muss nun für einen Datensatz die gesamte mehrere Gigabyte große Datei ausgelesen werden. Vorteilhaft ist aber der geringere Administrationsaufwand und die einfachere und schnellere Bereitstellung von zusätzlichem Speicherplatz. Abb. 5: Im unteren Teil sind gelb die Rechner dargestellt, deren Freigaben das NAS bilden. Über ein LAN sind diese an die verschiedensten Clients (im oberen Teil dargestellt: Workstation, Mainframe, Diskarrays) angebunden. In der rechten oberen Ecke befindet sich der Backup-Server der ebenfalls über dieses LAN mit dem NAS verbunden ist. 3. Einführung in die Hardware Management Console 3.1 Konfiguration Die Hardware Management Console (HMC) ist ein mächtiges Administrationswerkzeug mit einem Graphical User Interface (GUI) für die S/390 und die zu ihnen kompatiblen Großrechner von IBM. Sie bildet eine Kontrollinstanz, bei der letztlich alle Fehler- und Problemmeldungen bezüglich Hardwarekonfiguration abgefragt werden können. Die HMC kann von beliebigen Clients aus aufgerufen werden, die lediglich über ein LAN an den

Mainframe angebunden sein müssen. Mit einer HMC ist es möglich bis zu 100 Mainframesysteme zu kontrollieren und ein System kann von bis zu 32 HMC Clients gleichzeitig überprüft werden. Auf dem Großrechner gibt es zwei sogenannte Support Elemente(SE), die an die jeweiligen LANs angeschlossen sind und die Gegenseite (den Server der HMC) für den Client bilden. Diese beiden Support Element sind zwei normale Notebooks, die sich direkt bei dem Mainframe befinden und über das Power Service and Control Network (PSCN) mit diesem verbunden sind. Es gibt zwei davon, um für den Ausfall von einem SE die Zugriffsmöglichkeit über die andere zu gewährleisten. Beide SEs haben zwei Schnittstellen zu zwei unterschiedlichen LANs, wodurch wiederum die Ausfallwahrscheinlichkeit reduziert wird. Die Support Elemente werden für direkte Konfigurationsänderungen am Mainframe genutzt, und der Hardwarestatus wird durch sie kontrolliert. Dabei gibt es immer ein aktives SE und ein zweites alternatives SE. Nur im Fehlerfall wird automatisch zu dem zweiten Support Element umgeschalten. Ein Fehlerfall kann ein Hardwareproblem des SE sein, das aktive SE stellt fest, dass es die Verbindung über das PSC-Network zum Server verloren hat, oder falls das zweite SE einen Verbindungsverlust zur aktiven SE über LAN und PSCN feststellt. Ein manuelles Umschalten wird nur unter fachlicher Anleitung von IBM empfohlen. Es kann aber auch sein, dass das Umschalten nicht möglich ist, in zum Beispiel diesen Fällen: Es läuft gerade der Recoveryvorgang auf einer der Festplatten. Der Licensed Internal Code (LIC, Abschnitt 3.2) wird durch ein Update aktualisiert. Ein Mirroring Task ist gerade aktiv, das heißt, eine logische Partition (LPAR) wird auf eine andere kopiert, und beide können dann mit der gleichen Konfiguration laufen. Im normalen Betrieb, also ohne Ausfall des ersten SE, dient das alternative SE nur dazu, in regelmäßigen Abständen eine genaue Kopie der Konfiguration und des aktuellen Systemzustandes des aktiven SE zu machen, um für den Fehlerfall immer einen möglichst aktuellen Status zu haben. Abb. 6: Eine Möglichkeit wie die HMC genutzt werden kann: 2 Clients in verschiedenen Netzen sind redundant mit den beiden Support Elementen (Primary und Alternate SE) einer z900 Maschine verbunden, um eine höhere Ausfallsicherheit bezüglich der SEs und der Netzwerke zu erreichen.

3.2 Licensed Internal Code Der Licensed Internal Code (LIC) ist eine Art Maschinencode, der direkt auf der Hardware der S/390 Maschine ausgeführt werden kann. Man kann LIC von der Hardware Management Console über das Support Element oder direkt vom SE aus in den Mainframe laden. Beim Systemstart wird zuerst eine Konfiguration, die in LIC beschrieben ist, von dem SE geladen. Dabei verhält er sich ähnlich wie das Basic Input/Output System (BIOS) bei den bekannten i386-systemen. Es gibt jeweils 2 Kopien des LIC (A-side und B-side) auf dem aktiven Support Element, die aber verschiedene aktive Elemente (wie zum Beispiel Befehle für den direkten Hardwarezugriff) enthalten können. Damit ist es möglich den Mainframe mit unterschiedlichen Hardwarekonfigurationen zu starten, da auf einige Hardwareelemente der Zugriff möglich ist und auf andere nicht. Von der HMC aus kann während des laufenden Betriebs Updates des LIC geladen werden. Dabei kann auch aktiver Code des LIC, der vom System gerade geladen ist, ausgetauscht werden. Außerdem ist der Licensed Internal Code die Konfigurationsgrundlage für das Logical Partitioning (LPAR). Mit LPAR ist es möglich mehrere Betriebssysteme auf einem Großrechner gleichzeitig laufen zu lassen. Dabei muss das nicht unbedingt OS/390 oder z/os sein, sondern es läuft zum Beispiel auch Linux darauf. Mit LPAR wird dem jeweiligem Betriebssystem vorgegaukelt, es hätte exklusiv alle Hardwareressourcen für sich allein, dabei wird immer zwischen den Partitionen gewechselt, und so bekommt jede immer ihren Anteil an exklusiven Zugriffsrecht auf die Hardware. Diese logischen Partitionen können auch mit LIC exakt kopiert werden (Mirroring). So ist es einfach, mit einer einmal konfigurierten logischen Partition mehrere laufende Systeme zu erzeugen. Es kann dabei nochmals unterschieden werden, ob nur die Hardwarekonfiguration einer logischen Partition oder auch das darüber liegende Betriebssystem gespiegelt werden soll. 3.3 Aufgaben und Anwendung der HMC Die Hardware Management Console ist hauptsächlich für die Überwachung der Statusreporte der einzelnen Hardwareelemente zuständig. In einer grafischen Benutzeroberfläche werden alle aktuellen Meldungen präsentiert. Der Zugriff darauf ist wie bereits beschrieben mit einem Client auf dem die Zugriffssoftware installiert ist möglich, oder man kann auch einfach per Webbrowser zugreifen, da ein Webserver integriert ist. Im Problem- oder Fehlerfall wird der Systemstatus auf Service required gesetzt, damit der jeweilige Administrator in Kenntnis gesetzt wird. Er wird durch die Statusmeldungen und Logfiles bei seiner Problemanalyse unterstützt. Mögliche Fehler, die diesen Status hervorrufen, sind: Eines der Netzteile fällt aus, und die n+1 Stromversorgung ist somit nicht mehr gegeben. Das erste und zweite SE verlieren die Verbindung zueinander. Auf Grund von Ausfällen gibt es keine freien Prozessoreinheiten mehr. Für bekannte Probleme ist es aber auch möglich, dass über die HMC Bedingungen und Regeln deklariert werden, damit das System selbstständig und ohne Eingriff von außen reagieren und das Problem beseitigen kann. Das ist zum Beispiel bei dem Ausfall einer Prozessoreinheit (PU) in dem System möglich, dann kann automatisch das defekte Element deaktiviert werden, und dafür wird eine bis jetzt ungenutzte PU aktiv. Des weiteren ist die Überwachung und Konfiguration der bereits erwähnten LPARs komplett remote über die HMC möglich. Das bedeutet die jeweiligen Administratoren müssen sich nicht unbedingt direkt bei dem Mainframe befinden und über das aktive Support Element

konfigurieren, sondern es ist theoretisch von jedem Ort aus möglich. Falls es notwendig sein sollte, kann der Administrator über die HMC das Herunterfahren oder den Neustart des Systems initiieren. Über die Schnittstelle der Hardware Management Console lassen sich also sämtliche Statusinformationen eines S/390 Systems überwachen und Konfigurationsparameter anpassen. 4. Zusammenfassung Wie bereits Eingangs erwähnt, ist die Verfügbarkeit von Daten in der heutigen Welt ein wichtiger Wirtschaftsfaktor. Je größer die Sicherheit der Daten und ihr Verfügbarkeit sein soll, desto größere Ausgaben müssen dafür getätigt werden. Besonders bei großen Installationen mit Mainframes, ist es wichtig, dass Backup und Recovery möglichst automatisch ablaufen, und der normale Arbeitsablauf dadurch möglichst wenig gestört wird. Dabei helfen unter OS/390 und kompatiblen Systemen das DFSMS als Teil des Betriebsystems oder auch zusätzliche Softwarepakete wie der Tivoli Storage Manager. Durch sie ist es möglich die zu sichernden Daten von User und Administrator in Klassen einzuteilen, damit alle Daten, die so zusammengefasst sind, bei Backup und Recovery automatisch gleich behandelt werden. Auch die eigentliche Verwendung von Speichermedien wie Festplatten wird enorm vereinfacht, um den Anwender nicht mit systeminternen Details zu belasten. Ein besonderer Schwerpunkt ist im letzten Jahrzehnt die Netzwerkfähigkeit von Hardwaresystemen und Applikationen geworden, was sich mit dem rasanten Wachstum des Internets begründen lässt. Damit ist heute theoretisch von jedem Ort der Welt zu jeder Zeit der Zugriff auf Rechner über einen einfachen Webbrowser möglich. Ganze Mainframekonfigurationen können über den Webserver der Hardware Management Console gewartet werden, wodurch der jeweilige Administrator auch von außerhalb der Firma den Systemstatus überprüfen kann, und im Fehlerfall entscheiden kann oder das Problem online lösbar ist oder er vor Ort benötigt wird. Womit man wieder bei den finanziellem Gesichtspunkt angelangt ist, denn wenn eine einfache und übersichtliche Administration mit einem hohen Grad an Automatisierung gegeben ist, kann eine möglichst geringe Downtime gewährleistet werden. Nur auf diesem Weg ist man in der Lage solche Großinvestitionen wie Mainframes effektiv zu nutzen.

5. Literaturangaben [1] Einführung in z/os und OS/390 (Herrmann, Kebschull, Spruth) [2] Präsentation: Disaster Recovery Planning with DFSMS (von www.redbooks.ibm.com) IBM Internetseiten zu den Produkten: [4] www.ibm.com/tivoli [5] www.ibm.com/os390 IBM Redbooks (www.redbooks.ibm.com): [6] System Planning Guide [7] High Availability on the AS/400 System (S. Powers, N. Harris, E. Dreyer Andersen, S. Baker, D. Mee) [8] The System Administrator s Companion to AS/400 Availibility (S. Powers, E. Dreyer Andersen, R. Jones, H. Lye) [9] Backup Recovery and Media Services for OS/400 (S. Powers, S. Buttel, A. Dave, R. Hahn, D. McBryde, Tony Storry) [10] DFSMS/MVS V1R4 Technical Guide (M. Lovelace, P. Zerbini, G. Littlewood) [11] DFSMShsm Primer (Y. Cascajo Jiminez, H. Truong) [12] DFSMShsm Data Recovery Scenarios [13] DFSMSdfp Storage Administration Reference [14] Solutions for Disaster Recovery (B. Mellish, G. Castets, D. Asselin, J. Doherty, N. Mackintosh, F. Olivera Silva) [15] zseries 900 Technical Guide (F. Injey, M. Almeida, T. Gannon, J. Nessbit) [16] IBM Tape Solutions for Storage Area Networks and FICON (B. Kadleck, A. Bentley, W. Kessel, A. Vulic) [17] Introduction to Storage Area Networks (R. K. Khattar, M. S. Murphy, G. J. Tarella, K. E. Nystrom) [18] NAS Backup & Recovery Solutions (R. Tretau, I. Fuchs, J. Garcia Bayo, G. Korn, R. Rebolj) [19] ABCs of OS/390 System Programming (P. Rogers, D. Carey, N. Davies, L. Fadel, K. Hewitt, F. Pita, A. Salla) [20] Disaster Recovery Strategies with Tivoli Storage Manager (C. Brooks, M. Bedernjak, I. Juran, J. Merryman)