Hochverfügbarer TSM Server - PROFI Engineering Systems AG

profi.ag.de

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


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

3

28.10.2013

WEBCast TSM hochverfügbar machen


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


ANFORDERUNGEN AN DEN SERVICE ‚BACKUP‘

Das führt zu der Frage:

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

5

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

9

28.10.2013

WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

11

28.10.2013

WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

18

28.10.2013

WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

20

28.10.2013

WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

28.10.2013 WEBCast TSM hochverfügbar machen


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

26

28.10.2013

WEBCast TSM hochverfügbar machen


VIELEN DANK FÜR

IHRE AUFMERKSAMKEIT

ROLF MEYER

SENIOR SYSTEMINGENIEUR

TEL: 040-636699-0

EMAIL: R.MEYER@PROFI-AG.DE

Weitere Magazine dieses Users
Ähnliche Magazine