HV-Konzept für Unix-basierte AM Application IT2003: HW/SW Unix (M. Hilsamer) Autor: Armin M. Warda, TZS 1
Architektur = 3-Tier: DBMS - AS - Present. Single-Points of Failure = SPoFs: das eine DBMS die eine Central-Instance (ENQ, MSG) * das eine Netzwerk der eine NFS- (/usr/sap/trans,..) keine SPoFs: mehrere Dialog-Instances (DIA, BTC, UPD,..) 2
Systeme DBMS: 64-Bit z/os DB2 (Sysplex/Data Sharing) Central Instance: 31-Bit z/os-uss (Unix-System-Services) Dialog Instances: 64-Bit Unix-basierte Appl. (AS) 3
-Farm Konzept der SAP: Application (AS) werden als -Farm betrieben identische (geklonte) Systeme wie Web--Farm mit Load-Balancer AS sind nur AS: für andere Unix-basierte Dienste/Produkte sollen andere verwendet werden! 4
3-Zellen: 3x50% zrz Zelle 1 zrz Zelle 2 zrz Zelle 3 White- White- WhitezSeries zseries zseries zseries Space Space Space White- Space GbE-/FE-Switch GbE-/FE-Switch GbE-/FE-Switch GbE-/FE-Switch with Router GbE-/FE-Switch GbE-/FE-Switch with Router 101 102 103 104 201 202 203 204 301 302 303 304 prim. Network Install HA-NFS second. Network Install HA-NFS 5
weiche Lastseparierung dedizieren von AS für spezielle Anwendungszwecke/Anwendergruppe Online, Batch, Disp./Feeder,.. Sachbearbeiter, Recherche, Controlling,.. Separierung unterschiedlicher Last-Profile über Logon-Groups erhöht Cache-Qualität => Performance! 6
Ausfall eines AS... Ausfall einer Dialog Instanz bedeutet: Verlust der Sessions (z.b. SAPgui) dieses AS Rollback der (betr-)offenen Transaktionen Reconnect notwendig (bei SAPgui autom.) Restart der aktiven Batch-Läufe dieser Instance Leistungsverlust des Gesamtsystems Unsymmetrische Lastverteilung ungünstiges Logon-Group Load-Balancing 7
HV-Ziele für AS möglichst hohe Single--Availability AS sollen datenlos sein: keine Datenhaltung auf den Application n insbesondere keine betriebswirtschaftlich-relevanten Daten (z.b. Transaktions-Log) Ausnahme: Read-Only-Caching, System-Logs für System-Diagnose & -Troubleshooting alles soll Remote möglich sein 8
Single--Availability fehlertolerante (Stratus, Sun FT,..) existieren, aber nicht performant, zu teuer, nicht strategisch darum nur hohe Ausfallsicherheit und seltene, kurze Downtime angestrebt 9
seltene Ausfälle hohe Ausfallsicherheit durch: HW-Redundanz (Netzteile, Disks, CPUs,..) SW-Redundanz (Multi-Pathing, Mirroring,..) hohe Qualität der HW und SW 10
seltene Downtime Vermeidung von Downtime durch: HW Hot-Swap (Add/Replace/Remove) SW Hot-Swap ( Life-Upgrade der SW + OS) Online Resize (Kernel, Filesys., Swap-Space,..) frühzeitige autom. Erkennung + Meldung von potentiellen Problemen gute Diagnose-/Troubleshooting-Möglichkeit 11
kurze Downtime kurze Downtime durch: autom. Erkennung von OS-Hangs (< 5min) kurze Reboot-Dauer (< 30min) kurze Restore-/Install-Dauer (< 3h) Support- & Wartungs-Verträge (7x24x4h) 12
Everything Remote Power-On (Re-) Installation über Netz System-Console Service-Prozessor/System-Controller Terminal-Concentrator 13
System-Installation Remote Installation über Netz Live-Upgrade Rollback/Backout von Patches Alternate Disk-Install System-Disk-Cloning System-Cloning 14
Netzwerk-Anforderung Backbone und LAN redundant Backbone: Tier 1 <-> Tier 2 (z/os <-> Unix) LAN: Tier 2 <-> Tier 3 (Unix <-> Rest) DB2-ICLI kennt Standby-, aber...... SAP-RFC, NFS, Filetransfer,... brauchen zuverlässiges IP-Netz 15
Netzwerk-Realisierung Layer-2: 2-fach redundantes Gigabit-Ethernet redundante Kaskadierung, Spanning-Tree,.. Layer-3: 4-fach redundante IP-Netze (VLANs) redundante Routing-Instanzen IPAT, IPMP, DGW-Detection, VIPA, OSPF 16
Network Filesystem NFS ist zustandslos (bis auf File-Locking) HA-NFS durch Failover Remote-Mirroring IP-Address-Takeover (IPAT) Alternativen: HA-NFS mit z/os-uss im Parallel Sysplex HA-NFS mit Unix-HA-Cluster oder Appliances 17