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