Das Dokument bietet eine umfassende Übersicht über hohe Verfügbarkeit (High Availability) und Notfallwiederherstellung (Disaster Recovery) für DB2 in Verbindung mit IBM Connections, Sametime und Traveler. Es werden verschiedene Cluster-Technologien, Implementierungsansätze sowie praktische Beispiele für die Konfiguration und den Betrieb bereitgestellt. Darüber hinaus werden Tipps zur Administration und zum Monitoring gegeben, um eine zuverlässige Datenverfügbarkeit zu gewährleisten.

1. Make Your Data Work for You
DB2 High Availability für
IBM Connections, Sametime
und Traveler
Nico Meisenzahl
September 2016

2. • Consultant bei panagenda
• IBM Notes / Domino seit 2008
• IBM Connections seit Version 3.0 / 2010
• Jahrelange Erfahrung in:
– Consulting
– Migrationen & Administration
• “panagendian” seit 2016 mit Fokus auf:
– IBM Connections Consulting
– ICS Deployment & Optimierung
Nico Meisenzahl
2
 @nmeisenzahl
 linkedin.com/in/nicomeisenzahl
 meisenzahl.org
 nico.meisenzahl
 +49 170 7355081
nico.meisenzahl@panagenda.com

3. I. Cluster Technologien
II. High Availability and Disaster Recovery (HADR)
III. Installation & Konfiguration (Demo/Hands-on)
IV. Administration & Tipps
Agenda

4. Make Your Data Work for You
Cluster Technologien &
High Availability and Disaster
Recovery (HADR)

5. Übersicht Technologien
• pureScale
– “Going to extremes on scale and availability for DB2”
– mehrere aktive Nodes
– shared Storage
– Workload Management
• SQL Replication / Q-Replication
• High Availability mit
– Disk mirroring oder Log shipping
– Cluster-Manager Software
• IBM Tivoli System Automation (SA MP)
• Microsoft Cluster Server für Windows
• IBM PowerHA SystemMirror für AIX
• Sun Cluster für Solaris
5

6. High Availability and Disaster Recovery
• Cluster-Manager Software
– IBM Tivoli System Automation (SA MP)
– Microsoft Cluster Service for Windows
– IBM PowerHA SystemMirror for AIX
– LifeKeeper for Linux/Windows
– pureScale (seit v10.5)
• Datenreplikation mithilfe vom Log Shipping
• Automatic Client Reroute (ACR)
• DB2 High Availability Instance Configuration Utility (db2haicu)
6

7. Topology
7

8. Takeover (1)
8

9. Takeover (2)
9

10. Takeover (3)
10

11. Takeover & Tivoli SA MP
11
• Bietet Scripts zum
– Monitoring/Locking von Ressourcen
– Starten und Stoppen von Ressourcen
– Takeover von Ressourcen
– Takeover der Virtuellen IP (VIP)
• Monitoring
• Auslösen von Takeover &
Ressourcen-Locking

12. Automatic Client Reroute
12
• JDBC
– enableClientAffinitiesList=1
– clientRerouteAlternateServerName=<serverlist>
– clientRerouteAlternatePortNumber=<portlist>
• DB2 Connect
– clientRerouteAlternateServerName =<serverlist>
– clientRerouteAlternatePortNumber=<portlist>
• Support in weiteren Produkten z.B. WAS
• Hinterlegen der VIP oder des Standby Nodes

13. Datenbanken im HADR
13

14. Log shipping
14

15. High Availability Topology
• Aktiv/aktiv
– Mehrere aktive Nodes (seit. v10.1)
– Ressourcen aller Nodes werden genutzt
– Auf Datenbank-Ebene weiterhin primary/standby
• Aktiv/passiv
– Ein aktiver Node
– Bis zu drei passive Nodes möglich
– Primary DB auf aktivem Node, Standby DB auf passivem Node
• Aktiv/passiv (reads on standby, ROS, seit v9.7.x)
– Gleich aktiv/passiv
– Lesender Zugriff auf Standby Datenbanken möglich
15

16. • HOT Node
– Lizenzierung gleich Primary Node
• WARM Node
– 100 PVU oder 25 Authorized User
Single Installs (je nach Lizenzierung)
• COLD Node
– Keine Lizenz nötig
• pureScale unterliegt einer
eigenen Lizenzierung
Info: Nutzung mit Connections,
Sametime und Traveler abklären!
HADR Lizenzierung
16

17. Make Your Data Work for You
Demo / Hands-on

18. Demo: HADR aktiv/passiv
• Zwei Nodes
– DB2 ESE 10.5.7 vorinstalliert
– Instanz db2inst1
• Topologie
– Node db1
• Public: db1.pana.local, 192.168.9.206, eth0
• Private: db1-hadr.pana.local, 192.168.203.206, eth1
– Node db2
• Public: db2.pana.local, 192.168.9.207, eth0
• Private: db2-hadr.pana.local, 192.168.203.207, eth1
– VIP
• Public: db-access.pana.local, 192.168.9.208, eth0:0
18

19. Demo: HADR aktiv/passiv
• DB2 Installation
– Pre-request Check
• <setupdir>/db2precheck
• <setupdir>/db2/linuxamd64/tsamp/prereqSAM
– „Typical“ installiert Tivoli SA MP
– Deaktivieren von DB2 Fault Monitoring (db2fm)
– Lizenz einspielen!
• To Dos:
– Vorbereiten der Instanzen
– Konfiguration der Datenbank
– HADR starten
– High Availability Instance Configuration Utility (db2haicu)
– Takeover testen
Info: Lizenzen für Warm Cluster notwendig
19

20. Demo: Vorbereitung DB2
• Anpassung /etc/services
– DB2_HADR_testdb 50501/tcp
– Instanz neustarten
• Nodes vorbereiten
– preprpnode db1 db2
• Datenbank „TESTDB“ anlegen (db1)
– CREATE DB TESTDB
20

21. Demo: Konfiguration testdb primary (db1)
• UPDATE DB CFG FOR TESTDB USING LOGARCHMETH1 LOGRETAIN;
BACKUP DB TESTDB TO /home/db2inst1/;
• UPDATE DB CFG FOR TESTDB USING HADR_LOCAL_HOST 192.168.203.206;
UPDATE DB CFG FOR TESTDB USING HADR_LOCAL_SVC 50501;
UPDATE DB CFG FOR TESTDB USING HADR_REMOTE_HOST 192.168.203.207;
UPDATE DB CFG FOR TESTDB USING HADR_REMOTE_SVC 50501;
UPDATE DB CFG FOR TESTDB USING HADR_REMOTE_INST db2inst1;
UPDATE DB CFG FOR TESTDB USING HADR_TIMEOUT 120;
UPDATE DB CFG FOR TESTDB USING HADR_TARGET_LIST 192.168.203.207:50501;
UPDATE DB CFG FOR TESTDB USING HADR_SYNCMODE NEARSYNC;
UPDATE DB CFG FOR TESTDB USING HADR_PEER_WINDOW 120;
UPDATE DB CFG FOR TESTDB USING HADR_SPOOL_LIMIT 0;
UPDATE DB CFG FOR TESTDB USING HADR_REPLAY_DELAY 0;
UPDATE DB CFG FOR TESTDB USING BLOCKNONLOGGED YES;
UPDATE DB CFG FOR TESTDB USING LOGINDEXBUILD ON;
UPDATE DB CFG FOR TESTDB USING INDEXREC RESTART;
UPDATE ALTERNATE SERVER FOR DATABASE TESTDB USING HOSTNAME 192.168.9.208 PORT 50501;
BACKUP DB TESTDB TO /home/db2inst1/;
21

22. Demo: Konfiguration testdb standby (db2)
• RESTORE DB TESTDB FROM /home/db2inst1/;
• UPDATE DB CFG FOR TESTDB USING HADR_LOCAL_HOST 192.168.203.207;
UPDATE DB CFG FOR TESTDB USING HADR_REMOTE_HOST 192.168.203.206;
UPDATE DB CFG FOR TESTDB USING HADR_TARGET_LIST 192.168.203.206:50501;
22

23. Demo: testdb HADR starten
• db2.pana.local
– START HADR ON DB TESTDB AS STANDBY
• db1.pana.local
– START HADR ON DB TESTDB AS PRIMARY
23

24. Demo: High Availability Instance Configuration Utility
• Befehl: db2haicu
• Konfiguriert die Tivoli SA MP Scripts
• Standby Node zuerst konfigurieren
24

25. Demo: db2haicu auf db2 (1)
25

26. Demo: db2haicu auf db2 (2)
26

27. Demo: db2haicu auf db2 (3)
27

28. Demo: db2haicu auf db2 (4)
28

29. Demo: db2haicu auf db2 (5)
29

30. Demo: db2haicu auf db2 (6)
30

31. Demo: db2haicu auf db1 (1)
31

32. Demo: db2haicu auf db1 (2)
32

33. Demo: db2haicu auf db1 (3)
33

34. Demo: lssam & db2pd -ha
34

35. Demo: Takeover (switch role)
• TAKEOVER HADR ON DB TESTDB
35

36. Demo: Takeover (failover)
36

37. Demo: Takeover (failover)
37

38. Demo: Takeover (failover)
38

39. Demo: Takeover (failover)
39

40. Make Your Data Work for You
Administration & Tipps

41. Administrative Befehle
• Starten/Stoppen
– START HADR ON DB TESTDB AS STANDBY
– START HADR ON DB TESTDB AS PRIMARY (BY FORCE)
– STOP HADR ON DB TESTDB
• HADR Status
– lssam
– db2pd -hadr -db testdb (-alldbs)
– db2pd –ha
• Takeover
– TAKEOVER HADR ON DB TESTDB (BY FORCE)
• Unlock Ressouces
– rgreq -o unlock xxx
Info: Vorsichtiger Umgang mit by force
41

42. Takeover - prevent split brain
• Primary Datenbank startet nur wenn Standby verfügbar
– Hadr_timeout
• Takeover: alte Primary DB kontaktiert neue Primary DB und startet als
Standby
• Split Brain ist möglich!
– Komplexer Ausfall inkl. Netzwerkausfall und Reboots
– Administrativer Fehler (by force)
– Auflösen über
• Backup/Restore
• START HADR ON DB TESTDB AS STANDBY
• Auf VIP achten!
42

43. Deactivate/Activate Tivoli SAMP & Ressourcen locking
• Deaktivieren Tivoli SA MP
– samctrl -M T
• Aktivieren Tivoli SA MP
– samctrl -M F
• Ressourcen locken (db2haicu deaktivieren)
– db2haicu -disable
• db2haicu aktiveren
– db2haicu
43

44. Monitoring
• db2pd -hadr -db testdb (-alldbs)
• db2pd –ha
• MON_GET_HADR Funktion
• Verbesserungen mit v10.1
44

45. Monitoring Parameter
• HADR_ROLE
• HADR_STATE
• HADR_CONNECT_STATUS
• TIME_SINCE_LAST_RECV
– HEARTBEAT_INTERVAL
• HADR_LOG_GAP
45

46. Logs
• db2diag
– Filter Optionen
• db2diag.log
– Logfile Rollover konfigurieren!
• samlog
– Logs sind binär
• Syslog
46

47. Links
• DB2 HADR Wiki
– https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/DB
2HADR
• DB2 HADR Redbook
– http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf
• Tivoli SA MP Cheatsheat
– http://www-01.ibm.com/support/docview.wss?uid=swg21653981
• MON_GET_HADR Tabellen Funktion
– http://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.
sql.rtn.doc/doc/r0059275.html
• HADR Simulator
– https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/DB
2HADR/page/HADR%20simulator?section=Introduction
47

48. Fragen?
48
 @nmeisenzahl
 linkedin.com/in/nicomeisenzahl
 meisenzahl.org
 nico.meisenzahl
 +49 170 7355081
nico.meisenzahl@panagenda.com

49. Headquarters, Austria:
panagenda GmbH (Ltd.)
Schreyvogelgasse 3/10
AT 1010 Vienna
Phone: +43 1 89 012 89
Fax: +43 1 89 012 89-15
E-Mail: info@panagenda.com
Headquarters, Germany:
panagenda GmbH (Ltd.)
Lahnstraße 17
DE 64646 Heppenheim
Phone: +49 6252 67 939-00
Fax: +49 6252 67 939-16
E-Mail: info@panagenda.com
USA:
panagenda Inc.
60 State Street, Suite 700
MA 02109 Boston
Phone: +1 617 855 5961
Fax: +1 617 488 2292
E-Mail: info@panagenda.com
Germany:
panagenda Consulting GmbH (Ltd.)
Donnersbergstraße 1
DE 64646 Heppenheim
Phone: +49 6252 67 939-86
Fax: +49 6252 67 939-16
E-Mail: info@panagenda.com
The Netherlands:
Trust Factory B.V.
11th Floor,
Koningin Julianaplein 10
NL 2595 AA The Hague
Phone: +31 70 80 801 96
E-Mail: info@trust-factory.com
© 2007-2015 panagenda
Make Your Data Work for You