Backup- und Administrationswerkzeuge

Seminar Großrechneraspekte

Gliederung Backup/Recovery Werkzeuge

• Grundlagen und Einführung

• System Managed Storage:

• Data Facility Storage Management Subsystem

• Aggregate Backup & Recovery Support

• Remote Copy

• Tivoli Storage Manager

• SAN & NAS

Einführung in Hardware Management Console

Zusammenfassung

Allgemeines zu Backup/Recovery

• Hohe Verfügbarkeit und Datensicherheit wichtiger Wirtschaftsfaktor

• Zwiespalt: Verfügbarkeit Kosten

• Für Datensicherheit in großen Systemen Recoveryplan nötig: erstellt durch Administrator und User

Was soll wie und wogegen gesichert werden?

• Vollbackup: alles wird gesichert

• Inkrementelles Backup: es werden nur Objekte gesichert die seit der letzten Sicherung verändert wurden

• Partielles Backup: verschiedene Objekte werden zu verschiedenen Zeitpunkten & verschieden häufig gesichert

7 Recovery-Stufen• Stufe 0: Es existiert kein Recovery-Plan bzw. die

Möglichkeit für Backups

• Stufe 1: Pickup Truck Access Methode (PTAM)

Backup auf Externspeichermedium

Medien werden außerhalb in sicherer Umgebung gelagert und

für Recovery zurückgeholt

• Stufe 2: PTAM + Hotside

Hotside = doppelte Hardware an anderem Ort auf

der im Crashfall Recovery durchgeführt wird

• Stufe 3: Elektronischer Abgleich kritischer Daten

• Stufe 4: Aktive Hotside

• Stufe 5: Two-side Two-phase commit

automatischer Online-Datenabgleich zwischen beiden Seiten

• Stufe 6: kein Datenverlust

System Managed Storage: DFSMS

• Data Facility Storage Management Subsystem übernimmt automatische Datenverwaltung als Teil des Betriebsystems

• DFSMS fasst verschiedene Werkzeuge zusammen: Hierarchischer Speichermanager Datensatz-Services

• Administrator definiert Poolstruktur von Speichergruppen und ACS (automatic class selektion) Routinen

• ACS Routinen bestimmen welchen Speichergruppen welche Daten zugeordnet werden

System entscheidet automatisch wieviel Speicher es an welcher Stelle für welche Daten braucht

System Managed Storage: CDS

• Control Data Set (CDS) sind Metadaten über die vom DFSMS kontrollierten Daten

• M(igration)CDS: Informationen über Datensätze der Benutzer und der Anwendungen

• B(ackup)CDS: Informationen über Backup-Kopien der jeweiligen Datensätze

• O(ffline)CDS: Informationen über gesicherte Datensätze auf Externspeichermedien (Datenbänder)

• Durch CDS und Journal Recovery auf Hotside mit differenzierter Hardware und Struktur möglich

System Managed Storage: ABARS (1)

• Aggregate Backup & Recovery Support benötigt aktives DFSMS

• Daten und Anwendungen werden durch CDS in kritisch und unkritisch unterschieden Auswahl durch User und Administrator nötig

• Definition von Aggregate Groups die Daten und zugehörige Metadaten für Backup auf Band oder über Netzwerk zusammenfassen

• Verschiedene Gruppen werden zu Managementklassen zusammengefasst die gemeinsame Attribute für Verwaltung besitzen

System Managed Storage: ABARS (2)

• Tape-Storage-Groups verbinden Gruppen mit Tapelibrarys und ermöglichen so automatische Verteilung der Backups

• Abackup erstellt 3 Dateitypen:– Aggregation control file: enthält Information über Umgebung für

Remote-Recovery

– Instruction data set: enthält Metadaten über gesicherte Daten

– Aggregation data file: enthält eigentliche Daten

• Backup kann explizit durch ein Kommando gestartet werden oder eingebettet in ein Programm

• Falls bei Recovery Namenskonflikte auftreten, kann dies durch Ersetzen, Auslassen des Datensatzes oder Umbenennen des Ziels oder der Quelle gelöst werden

Beispiel: ABARS

System Managed Storage: Remote Copy

• Dient automatischem Abgleich zu remoter Hotside

• Extended Remote Copy (XRC) – ab Recovery-Stufe 4 einsetzbar z.B. bei Wide-Area Parallel

Sysplex

– Zeitunterschied beim Speichern auf Localhost und Remotehost möglich da asynchrones Kopieren der Daten zum Recovery-System im Fehlerfall nur geringe Datenverluste

• Peer-to-Peer Remote Copy (PPRC)– Speichert synchron Daten auf Localhost und Recovery-System

und benötigt damit ein immer aktuelles Remotesystem

Tivoli Storage Manager (1)

• Optionales Programmpaket von IBM für Speicherverwaltung und Wartung unter vielen OS

• Client-Server Anwendung:

Tivoli Storage Manager (2)

• Automatisiert gesamten Backupprozess:– Daten werden über Netzwerk vom Client an den TSM-Server

versendet

– Server verwaltet sowohl Bandlaufwerke als auch Disk Storage Pool

– Optional ist gleichzeitige weitere externe Kopie der Daten möglich

– Verwaltung der Daten und zugehöriger Metadaten erfolgt über relational Datenbank

• Automatisierung für Recovery schwierig da meist ad-hoc Ereignis:– Zumindest Definition der Arbeiten die parallel bei

Wiederherstellung ausgeführt werden können

Storage Area Network (SAN)

• Speicher ist auf dediziertes Netzwerk verteilt mit any-to-any Verbindung zwischen Speicher und Prozessoren

• Verteiltes Speicher- und Backupmedium das per Glasfaser (oder selten: Ethernet) an Mainframe angebunden ist

• Reduziert I/O-Traffic im LAN bei mehr möglichen gleichzeitigen Zugriffen durch mehr Prozessoren (Server)

• Setzt SCSI-Protokoll über Netzwerk für Zugriffe um

• Backup innerhalb des SAN direkt möglich ohne externes Zubehör und mit gringer Belastung des LAN da nur Metadaten darüber gesichert

• Server-free Backup per Tivoli Storage Manager umgesetzt

SAN-Struktur

Network Attached Storage (NAS)

• NAS nutzt LAN und dessen Protokolle (TCP/IP, Netbios) für Datenübertragung und –zugriffe

• Im Prinzip jeder Fileserver unter jeglichem OS für NAS nutzbar da nur Device-Freigaben z.B. NFS-Freigaben zusammengefasst werden

• Arbeitet auf Filelevel (verarbeitet bei Anfragen nur ganze Dateien) im Gegensatz zum SAN mit Blocklevel

• Für Backup schlechter geeignet da I/O-Zugriffe vollständig über LAN ablaufen

NAS-Struktur

Hardware Management Console (HMC)

• Mächtiges Administrationswerkzeug für Remoteeinsatz

bildet Kontrollinstanz und stellt Systemimages bereit

• Direkte Verbindung über LAN mit Supportelementen (SE) der Prozessorelemente (CPC)

• Pro CPC gibt es 2 SEs per Power Service & Control Network angebunden:– Speichern Hardware-Konfigurationsinformationen

– Laden gespeicherten LIC in Prozessor

– Überwachen Hardware- und Imagestatus

– Im Fehlerfall (Ausfall einer SE oder Verlust der Verbindung) ersetzt zweite automatisch erste SE

Beispielkonfiguration

HMC: Aufgaben

• Überwacht Statusreporte der einzelnen Hardwareelemente

• Kann System komplett herunterfahren oder neu starten

• Dient Problemanalyse:– Administrator definiert Bedingungen für Fehlerbehandlung

– HMC überwacht Bedingungen und setzt falls nötig Status auf „Service benötigt“

• Stellt Systemimage(s) für CPC mit eigener VM bereit und ordnet jeweils Hardwareressourcen zu (LPAR)

• Kann einzelne Prozessoreinheiten in CPC im Fehlerfall deaktivieren und dafür ungenutzte PUs bereitstellen

• Regelt Lastverteilung innerhalb einer CPC

Licensed Internal Code (LIC)

• LIC ist Maschinencode der über HMC und SE direkt im CPC ausgeführt werden kann

• kann unterhalb des OS Hardware simulieren

• Es gibt jeweils 2 Kopien (A- und B-side) die abgespeichert sind aber verschiedene aktive Elemente bzw. Befehle enthalten die direkten Hardwarezugriff ermöglichen

• Durch Start der verschiedenen Kopien unterschiedliches Hardwareverhalten möglich

• Unterstützt Mirroring von Platten und auch von ganzen virtuellen Hardwaresystemen mit darüber liegendem OS

Zusammenfassung

•Remotezugriff bzw. Netzwerkfähigkeit für Backup und andere Administrationsaufgaben notwendig

• Automatisierung vieler Backupaspekte durch DFSMS und zusätzlicher Programmpakete wie z.B. Tivoli

• HMC kann Hardware fast in vollem Umfang „online“ verwalten und konfigurieren

• sehr wichtiger Kostenfaktor für Firmen

einfache und übersichtliche Administration notwendig