Hochverfügbarer TSM Server - PROFI Engineering Systems AG

DEN TSM SERVER 

HOCHVERFÜGBAR MACHEN 

Tipps zur Realisierung

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 

2 

28.10.2013 

WEBCast TSM hochverfügbar machen







06 Diskussion 

3 

28.10.2013 


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 

28.10.2013 WEBCast TSM hochverfügbar machen


Das führt zu der Frage: 

Brauche ich eine HA-Lösung für TSM? 

5 



• 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 



• 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 



• 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 








06 Diskussion 

9 

28.10.2013 


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 








06 Diskussion 

11 

28.10.2013 


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 


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 


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 


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 


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 


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 








06 Diskussion 

18 

28.10.2013 


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 







05 Beispiele aus PROFI-Projekten 

06 Diskussion 

20 

28.10.2013 


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 


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 


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 


• Copypool-Tapes auslagern 

23 


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) 


• Trennung der Cluster-Nodes – Verteilung auf verschiedene Server-Räume 

24 


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 







05 Beispiele aus PROFI-Projekten 

06 Diskussion 

26 

28.10.2013 


VIELEN DANK FÜR 

IHRE AUFMERKSAMKEIT 

ROLF MEYER 

SENIOR SYSTEMINGENIEUR 

TEL: 040-636699-0 

EMAIL: R.MEYER@PROFI-AG.DE

Hochverfügbarer TSM Server - PROFI Engineering Systems AG

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?