DEN TSM SERVER HOCHVERFÜGBAR MACHEN. Tipps zur Realisierung

Transkript

1 DEN TSM SERVER HOCHVERFÜGBAR MACHEN Tipps zur Realisierung

2 AGENDA 01 Ist eine HA-Lösung für TSM erforderlich 02 Besonderheiten bei TSM Version 6 03 Methoden der Absicherung des TSM-Betriebs 04 Entscheidungskriterien 05 Erfahrungen aus PROFI-Projekten 06 Diskussion WEBCast TSM hochverfügbar machen

4 ANFORDERUNGEN AN DEN SERVICE BACKUP Datensicherung soll die erstellten Daten möglichst unauffällig lesen und sicher auf einem externen Datenträger speichern. Der Service Datensicherung muss in der Lage sein, Dateien auf Anforderung wieder herstellen zu können. Wie lange das dauern darf, hängt von den individuellen Ansprüchen der Anwender bzw. der Wertigkeit innerhalb des Produktionsbetriebes ab. Für die normale Arbeit des IT-Anwenders ist Datensicherung nicht wirklich erforderlich. 4

5 ANFORDERUNGEN AN DEN SERVICE BACKUP Das führt zu der Frage: Brauche ich eine HA-Lösung für TSM? 5

6 ANFORDERUNGEN AN DEN SERVICE BACKUP Hochverfügbarkeit unterscheidet sich allerdings von Katastrophenvorsorge! Nach einer Katastrophe wird in der Regel eine passive Systemumgebung aktiviert. Der Aufsetzpunkt (für Wiederherstellungen) kann dabei variieren. Wichtig ist die Verfügbarkeit der gesicherten Daten! 6

7 ANFORDERUNGEN AN DEN SERVICE BACKUP Der Anspruch für eine Hochverfügbarkeit bedeutet: Auf den Service Datensicherung kann nur eine kurze Zeit (< 1 Stunde?) verzichtet werden. Wichtig ist neben der Verfügbarkeit der gesicherten Daten auch die Betriebsfähigkeit des TSM-Servers. 7

8 ANFORDERUNGEN AN DEN SERVICE BACKUP Wo ist Hochverfügbarkeit erforderlich Sicherung von Datenbank-Transaktions-Logs Archiv-Systeme mit TSM als Back-End HSM verwaltete Speichersysteme Hier kann ein Ausfall des TSM-Servers zu ernsten Produktions-Störungen führen. 8

10 BESONDERHEITEN BEI TSM V6 Der große Unterschied zur Version 5 ist die Datenbank V5 hatte DB mit bis zu drei identischen Dateien (DB und DB- Copy), ebenso das Recovery-Log Mit mindestens einer Version konnte gestartet werden! V6 benutzt ein originales DB2 (Enterprise Edition) Tablespaces und Transaktions-Logs gibt es nur einmal Festplattenfehler führen immer zu DB2-Recovery-Aufgaben 10

12 METHODEN ZUR ABSICHERUNG DES TSM-SERVERS Tape Rotation 2 RZs, 2 Server, DRM zur Wiederherstellung des TSM- Servers Datenspiegelung 2 RZs, 2 Server, Remote Volume Mirror mit Hilfe der Festplatten-Speicher TSM Node Replication 2 RZs, 2 unabhängige TSM-Server und Storage Pools HADR Replikation (mit TSM V6 möglich) 2 RZs, 2 TSM-Server, synchrone TSM-Datenbank TSM-Server als geclusterte Systeme (AIX mit PowerHA, Linux mit Linux- HA) 12

13 TAPE ROTATION Magnetbänder werden ausgelagert und transportiert Die Entfernung zwischen den beiden Standorten ist nicht entscheidend (keine Leitungskosten, kein Bandbreiten-Problem) Ist eine Cold-StandBy-Lösung, weil eine Wiederherstellung des TSM- Servers aus den ausgelagerten Datenbeständen einer Wiederaufnahme des TSM-Betriebs vorausgehen muss. Ein weiteres Problem: Die manuelle Verwaltung der Bandbestände muss besonders sorgfältig erfolgen. 13

14 DATENSPIEGELUNG Voraussetzung: RZs sind in LWL-Reichweite und die Festplattensysteme können die Daten spiegeln (PPRC, RVM o.ä.) Am Backup-Standort muss ein Server vorgehalten werden. Die Umschaltung beginnt mit der Aktivierung des Festplattenspiegels als aktive Seite. Die Spiegelung muss konsistent sein (consistency groups) Auf diese Art ist ein warmes StandBy-Szenario abbildbar, dass ohne Wiederherstellung der TSM-Datenbank auskommt. 14

15 TSM NODE REPLICATION Voraussetzung: Zwei unabhängige TSM-Server, die über Netzwerk- Verbindungen miteinander in Kontakt treten können. Die Replikation erfolgt auf Basis von TSM Nodes Management-Regeln können differieren, viele Spielarten sind damit möglich. Die verfügbare Netzwerk-Bandbreite zwischen den beiden Servern bestimmt die Leistungs-Fähigkeit. Der gesicherte Client kennt nur einen Server. Das soll sich aber in Zukunft ändern. 15

16 HADR REPLIKATION Voraussetzung: Zwei unabhängige TSM-Server, die über Netzwerk- Verbindungen miteinander in Kontakt treten können. HADR (high availability disaster recovery) ist eine Funktion des DB2 und stellt die Replikation der TSM Datenbank durch DB2 Log-Shipping zur Verfügung. Auf dem zweiten TSM-Server läuft eine DB2-Datenbank-Instanz, die von der primären Datenbank synchron gehalten wird. Für die Einrichtung sind Eingriffe in die DB2-Konfiguration der TSM- Server notwendig. Die Replikation betrifft nur die Datenbank. Die Verfügbarkeit der Storage Pools ist gesondert zu betrachten. 16

17 TSM-SERVER ALS GECLUSTERTE SYSTEME Voraussetzung: Software zur Verwaltung der Cluster-Ressourcen (TSM, Speicher, Netzwerk-Adressen) und gemeinsam nutzbare Datenspeicher-Einheiten. TSM, die Storage-Pools und die Server-Adresse werden als Cluster- Ressourcen zwischen mehreren gleichartigen Server-Systemen geschwenkt. Die Cluster-Verwaltung übernimmt die Steuerung. Wenige bzw. keine manuellen Eingriffe für die Umschaltung erforderlich. 17

19 DIE VERSCHIEDENEN SZENARIEN Ausfall Cluster HADR Node Replikation Festplatten-Spiegel Tape Rotation Server-Hardware X Festplatte für TSM DB X X X X RZ-Raum (X) X X X X notwendige Aktionen Crash Recovery der Datenbank Crash Recovery und Audit der Storage Pools Crash Recovery und Audit der Storage Pools Restore der TSM DB, Audit der Storage Pools 19

20 AGENDA 01 Ist eine HA-Lösung für TSM erforderlich 02 Besonderheiten bei TSM Version 6 03 Methoden der Absicherung des TSM-Betriebs 04 Entscheidungskriterien 05 Beispiele aus PROFI-Projekten 06 Diskussion WEBCast TSM hochverfügbar machen

21 PROFI ERFAHRUNGEN MIT HADR Die schlechte Nachricht zuerst: HADR ist nur sehr bedingt geeignet TSM weiß nichts von DB2 DB2 weiß nichts von TSM (und seinen Besonderheiten) Start und Stop von DB2 passiert im TSM Start bzw. Stop Ein Stop des TSM-Servers (geplant oder ungeplant) unterbricht die HADR Partnerschaft (db2stop force!!) 21

22 BEISPIEL MIT NODE REPLIKATION Kunde: Photo-Dienstleister 2 RZs (innerhalb der Stadtgrenzen) 10Gb/s Bandbreite zwischen den Standorten Je einen TSM-Server in jedem RZ Diskpools im RZ1 (rd. 120 TB, 70% used), Tape-Library im RZ2 Das tägliche Sicherungs-Volumen kann zeitlich problemlos repliziert werden ( Bandbreite! ) Bei Ausfall des Haupt-Servers müssen vor einem Restore die Options-Dateien geändert werden ( wird vielleicht in Zukunft nicht mehr nötig sein ) Keine COPYPOOLS! Bei Ausfall des Diskpools müssen alle Daten zurück repliziert werden Empfehlung: Copypools auf der primären Seite mit einplanen. Für geeignet große Bandbreite sorgen 22

23 BEISPIEL MIT FESTPLATTENSPIEGELUNG Kunde: Zeitungsverlag Hauptanwendung: SAP System mit Sicherung über TDP for ERP 2 Rechnerräume (im gleichen Gebäude) SAN LWL-Verkabelung zwischen den RZs Je einen TSM-Server in jedem RZ Diskpools im RZ1, Tape-Library im RZ2 DB-Instanz über zwei Festplattensysteme V7000 mit LVM gespiegelt Linux-HA Cluster DB2 Volumegruppe und Diskpools sind Cluster-Ressourcen Einarbeitung in Linux-HA ist etwas aufwändiger System läuft seit mehreren Monaten störungsfrei Empfehlung: Copypool-Tapes auslagern 23

24 BEISPIEL MIT SHARED DISK Kunde: Fernsehsender Hauptanwendung: HSM-Archiv für Videodaten 2 Rechnerräume (auf dem Campus 500m Entfernung) SAN LWL-Verkabelung zwischen den RZs GPFS Cluster aus drei Knoten,Linux-HA Cluster über diesen GPFS-Cluster TSM-Server ist Cluster Ressource DB-Instanz auf GPFS-Filesystem Kleine Diskpools, Backup und HSM-Archiv auf getrennte Tape Libraries Linux-HA-Umgebung ist aufwändig (drei Knoten, viele Ressourcen, Anspruch auf bedienerlosen Betrieb) System läuft schon seit mehreren Jahren so (früher schon mit V5) Empfehlung: Trennung der Cluster-Nodes Verteilung auf verschiedene Server-Räume 24

25 ZUSAMMENFASSUNG Meine Empfehlungen Wenn SAN-Verbindung zwischen den TSM-Servern möglich ist TSM DB-Instanz als GPFS-Filesystem oder LVM-Spiegel über zwei Festplattensysteme TSM als Cluster-System Bei ausreichender Netzwerk-Bandbreite zwischen den TSM-Servern Node-Replikation (uni- oder bi-direktional) Copy-Pools auch auf der primären Server-Seite 25

26 AGENDA 01 Ist eine HA-Lösung für TSM erforderlich 02 Besonderheiten bei TSM Version 6 03 Methoden der Absicherung des TSM-Betriebs 04 Entscheidungskriterien 05 Beispiele aus PROFI-Projekten 06 Diskussion WEBCast TSM hochverfügbar machen

27 VIELEN DANK FÜR IHRE AUFMERKSAMKEIT ROLF MEYER SENIOR SYSTEMINGENIEUR TEL: