TSMCluster 5.3 Präsentation

Werbung
TSMC
TSM luster
®
Version 5.3
Hochverfügbarkeit
für TSM Server auf UNIX
August 2015
Warum ein Cluster für TSM?
Schutz vor geplanten und ungeplanten Ereignissen.
RZ 1
TS3500
Server A
Prod-A
3592
3592
3592
3592
3592
3592
10.20.30.1
S
A
N
tsm01
10.20.30.11
10.20.35.1
192.168.2.1
Port 1511
tsm02
10.20.30.12
10.20.25.2
Port 1512
Bekannte Fehler:
Prozess bricht ab
IP/Port fehlerhaft
Platten Crash
Server Crash
DB Inkonsistenz
Bedienerfehler
Umwelteinflüsse
DB2 container
Active log
Archive log
Mirror log
Pools (disk & file)
15.08.2015
(c) 2015 by eXstor GmbH
2
Warum ein Cluster für TSM?
1. „Brauchen wir nicht. Ist doch nur Backup.“
TSM muss als 24x7 Anwendung gesehen werden.
Datenbanken sichern ihre Logs durchgehend ins TSM.
Restore von Einzeldateien aus den Home Verzeichnissen.
Einhaltung von SLA's.
Einhaltung von staatlichen Vorgaben (Basel-II).
2. „Cluster für TSM? Haben wir selbst gemacht.“
Das war sehr leicht für TSM Version 5. und Version 6?
Funktionieren die Scripts auch bei 6.2 / 6.3 / 6.4 / 7.1 ??
Validierung und Test? Fehler werden erst beim Auftreten erkannt.
Kontinuierliche Weiterentwicklung notwendig.
Abhängigkeit zu einem oder zwei Entwicklern (Urlaub? Krank??)
Haben Sie DB2 Kenntnisse?
Was sind „Log pinning“, Semaphore, „IPC Sockets“ in DB2?
15.08.2015
(c) 2015 by eXstor GmbH
3
Warum ein Cluster für TSM?
3. „Wir haben einen OS Cluster von Hersteller xy.
OS Cluster sind sehr OS-lastig. Starke Durchdringung gewünscht.
Jedes OS hat seinen eigenen Cluster (HACMP, MSCS, ..)
Neues OS / Neuer Patch = Neuer Cluster.
OS Update = Cluster Update = Downtime.
OS Cluster soll möglichst viel abdecken.
Sehr schulungsintensiv / sehr komplex. Meist wenig Know-How.
Überwachung von klassischen Ressourcen.
Der applikationsspezifische Teil muss selbst programmiert werden.
OS Personal <> TSM Personal (bei Problemen / Updates?)
Kosten sind Maschinenabhängig.
4. „Ist zu teuer für uns.“
???
15.08.2015
???
(c) 2015 by eXstor GmbH
4
TSM hochverfügbar
Ideal: TSM als Applikationscluster.
TSM ist nicht „Cluster-aware“
TSM kennt kein Aktiv-Aktiv-Betrieb, sondern nur Aktiv-Passiv.
Es existiert kein API oder andere Schnittstelle.
In Version 6 und 7 besteht TSM aus TSM und DB2.
Möglichkeiten:
1. DB2 HADR
→ Replikation auf DB2 Basis
→ Synchron / asynchron
→ TSM weiß nichts davon.
→ Schützt nur vor DB Problemen.
2. Kontinuierliche DB Replikation mittels TSM
→ Prima mit Version 5. Mit Version 6??
→ Schützt nur vor DB Problemen.
3. oder …...
15.08.2015
(c) 2015 by eXstor GmbH
5
Was machen wir anders?



TSMCluster® erweitert einen normalen TSM Server
um eine Hochverfügbarkeit auf Applikationsebene.
Wir brauchen keine weitere Software.
TSMCluster® ist eine anerkannte IBM Value
Advantage Plus Lösung und „IBM certified“.
15.08.2015
(c) 2015 by eXstor GmbH
6
Was machen wir anders?

TSMCluster® ist einfach zu bedienen.
Administration und
Monitoring der TSM
Komponenten durch einen
TSM Admin.
TSM
15.08.2015
TSM Server, API und Client
DB2 Ressourcen, Prozesse
Filesysteme, VGs, Dateien
Platten, Spiegel, Snapshots
IP, Bonds, Etherchannel, Ports
SAN, FC Adapter, Tapes
Semaphore, IPCS, ShMem
Kernel Parameter und Logs
Externe Ressourcen
(c) 2015 by eXstor GmbH
7
Was machen wir anders?

Any-to-any Konzept

Beliebig viele TSM Server (Instanzen) laufen auf
beliebig vielen Maschinen (Nodes)
TSM server „tsm01“
IP Alias
Port
10.10.1.21
1521
TSM server „tsm02“
IP Alias
Port
10.10.1.22
1522
TSM server „tsm03“
IP Alias
Port
10.10.1.23
1523
TSM server „tsm05“
IP Alias
Port
TSM server „tsm04“
IP Alias
Port
15.08.2015
10.10.1.24
1524
(c) 2015 by eXstor GmbH
8
10.10.1.25
1525
Was machen wir anders?

Sensoren
Ein Sensor ist wie ein Stethoskop
 Sensoren für TSM, DB2 und OS
 Mehrere Sensoren erlauben einen “Blick in die
Zukunft (“failover prediction”)
 Sensoren und Schwellwerte sind konfigurierbar
 Sensoren beeinflussen Wertigkeiten der Nodes
 Statische, Dynamische, historische Sensoren
 Zentrale Datenbank für erfasste Werte (SQL
Abfragen möglich)
 Weitere Sensoren werden permanent ergänzt

15.08.2015
(c) 2015 by eXstor GmbH
9
Was machen wir anders?

Sensoren
 Es
gibt lokale und remote Sensoren.
 Beispiele:
Name
Type
Test
Dep.
Result
V5_LogTrigger
Local
Log Pct_Util > 98%
No
Shutdown instance
V5_NoScratchLeft
Local
No Scratch tapes for DB Backups
No
Alert
V5_SANDiscovery
Local
SAN Discovery has changed paths
No
Alert
V6_DB2_Dftdbpath
Local
Dftdbpath has less than 1 GB left
No
Alert
V6_DB2_API
Local
API config has changed
Yes
Alert and Modification
V6_DB2_LogCons
Local
Log Consumption is very fast
Yes
Alert
V6_DB2_Archlog
Local
Not enough space in archlog dir
Yes
Alert and Modification
V6_TSM_LogTrigger
Local
Log Pct_Util > 98%
No
Shutdown instance
V6_TSM_DBBackup
Local
DB Backup is more than 24h ago
Yes
Alert
V6_OS_MemUtil
Local
Memory on local node is not enough
Yes
Move if possible
V6_OS_R_MemUtil
Remote
Memory on spare node enough?
Yes
Alert/Move/Modification
15.08.2015
(c) 2015 by eXstor GmbH
10
Was noch?

Weltweit geschützter Name: TSMCluster®

Lösung im “IBM global solution directory” (GSD)

Webinterface und CLI
15.08.2015
(c) 2015 by eXstor GmbH
11
Was noch?

Einfaches, manuelles Arbeiten

Konfigurierbarer, regelbasierter Failover

Obligatorische und fakultative Ressourcen

Zentraler Logserver

Zentrale Konfiguration in XML Format

Beliebig viele Heartbeat Netze (LAN / SAN)

Upgrade / Downgrade durch ein Paket

Mail, SMS, syslog, SNMP etc. Anbindung

Kommunikation ist verschlüsselt (SSL / https)

Intelligente Split-Brain Behandlung
15.08.2015
(c) 2015 by eXstor GmbH
12
Was noch?

Plattenspiegel einfach integrierbar (IBM, EMC...)

Unterschiedliche Bonding Modes

DB2 HADR kann integriert werden

ERMM, ACSLS und 3494 Schnittstelle

GPFS als Shared Filesystem (alternativ JFS2)

TSM DRM Anbindung

TSM SNMP Anbindung
15.08.2015
(c) 2015 by eXstor GmbH
13
Welche Plattform?

TSM
 Alle
TSM Versionen: TSM Version 5.5, 6.x und
7.1
 Mischbetrieb ist möglich, wenn genug Nodes
vorhanden sind

OS
 IBM
AIX 6.1 / 7.x, JFS2 / GPFS
 Linux, RHEL 5, 6 und 7 mit GPFS/LVM
 SLES 10-12 mit GPFS/LVM
 Mischbetrieb einfach möglich
15.08.2015
(c) 2015 by eXstor GmbH
14
Wie geht es weiter?
TSMCluster® 6.1 ist geplant für Q2/2016
 Inhalte V6.1:

 Neue
GUI auf Basis IBM Websphere
 Tivoli Operation Center Integration
 Spectrum
Control und Scale Integration
 Support für Spectrum Scale 4.2
 Weitere Sensoren
TSMCluster® wird zusammen entwickelt mit der
META-LEVEL Software AG in Saarbrücken.
http://www.meta-level.de
15.08.2015
(c) 2015 by eXstor GmbH
15
Kontakt:

Address:
eXstor GmbH
Hans-Bredow-Strasse 56
65189 Wiesbaden



E-Mail: [email protected]
Website: http://www.tsmcluster.com
Tel.: +49 170 6326924
15.08.2015
(c) 2015 by eXstor GmbH
16
Herunterladen