© 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 1.

Präsentation zum Thema: "© 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 1."—  Präsentation transkript:

1 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 1

2 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 2 Gliederung des Vortrages n Einleitung & Begriffe n Reliability & Availability n Performance n Strategien n Turbo Linux Cluster n Oracle 8i R2

3 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 3 Single Points of Failure (SPOF) Ein Single Point of Failure bewirkt den Ausfall des Gesamten Systems - Ein einfaches Netzteil - Ein einfaches Netzwerk oder Netzwerkkarte - Ein einfacher SCSI-Adapter oder Kabel - Eine ungespiegelte Festplatte - Ein einfacher Computer-Raum - Ein einzelnes Gebäude Quelle:Linux HA Vortrag German Unix User Group

4 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 4 Der Weg... zu hoch verfügbaren Systemen: - Alle Single Points of Failure aufspüren - Wo nötig redundante Komponenten einsetzen - Automatische Fehlererkennung (Umschaltung) - Software-Updates müssen zur Laufzeit eingespielt werden - Administration darf das System nicht (ganz) unterbrechen Quelle:Linux HA Vortrag German Unix User Group

5 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 5 High Availiability/Fault Tolerance Hoch verfügbare Systeme können teilweise ausfallen, sind aber so aufgebaut, daß sie in kürzester Zeit wieder komplett laufen. - Typische Ausfallzeiten liegen unter 5 Minuten - Es treten keine Datenfehler auf - Transaktionsorientierte Software verliert keine Daten Fehlertolerante Systeme sollten überhaupt nicht ausfallen, sind aber sehr teuer - Spezielle Hardware wird benötigt - Alles muß redundant ausgelegt werden - Computer-Räume und Gebäude sind trotzdem SPOFs Quelle:Linux HA Vortrag German Unix User Group

6 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 6 Anwendung von HAC / HPC High Performance Clustering (HPC) - Grand Challenge Applications - Hohe Geschwindigkeit - Anwendung High Availiability Clustering (HAC) - For Mission Critical Applications - Hohe Verfügbarkeit - Anwendung

7 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 7 Kosten bei System-Ausfall $6.500.000 $2.600.000 $1.150.000 $113.000 $10.000 $100.000 $1.000.000 $10.000.000 Average Cost per Hour of Downtime Financial Brokerage Operations Financial Credit Card Sales Media Pay-per-View Retail Home Shopping (TV) Retail Catalog Sales Transportation Airline Reservations Quelle:Compaq Architecting and Deploying High-Availability Solutions

8 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 8 Gliederung des Vortrages n Einleitung & Begriffe n Reliability & Availability n Performance n Strategien n Turbo Linux Cluster n Oracle 8i R2

9 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 9 Company Alpha Internet/Intranet Router HDD Service Server HUB Relevanter Bereich Netzwerk Avaliability

10 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 10 91,6 83,9 91,6 GerätMTBFReliability %p.a. Netzwerk100.000 Server 50.000 HDD100.000 Gesamt: ?? Beispiel zur Berechnung der Reliability Auf ein Jahr bezogen: 24 Stunden * 365 Tage= 8760 Stunden R(8760) = e - 0,00001*8760 = 91,6 % 24.955 R (t) = e -at a=1/MTBF 70,3 Quelle: Distributed Information Systems, Erroly Simon MTBF= Mean Time Between Failure

11 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 11 Company Beta Internet/Intranet Router HUB Relevanter Bereich Server ABackup A HDD (gespiegelt) Netzwerk Avaliability Service InterfaceStandby Interface

12 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 12 Reliabilityno backupwith backup Netzwerk91,6 % Server 83,9 % HDD91,6 % Gesamt:70,3 % Berechnung der Reliability R backup = 1- (1 - Netzwerk ) 2 = 1- ( 1- 0,916) 2 = 0,9929 R backup = 1-(1 - R no backup ) 2 R overall = 1-(1 - R 1 ) (1 - R 2 )*...*(1 - R n ) R overall = 1- (1 - Netzwerk ) (1 - Server ) (1 - HDD) = 1 - (1 - 0,916)(1 - 0,839)(1 - 0.916) = 0.9988 99,29 % 97,40 % 99,29 % 99,88 % Quelle: Distributed Information Systems, Erroly Simon

13 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 13 MTBF MTTRAvailability System Alpha24.955 2 (No Backup) System Beta7.295.619 !! 2 (with Backup) Berechnung der Availability A = MTBF / MTBF + MTTR A overall = 1-(1-A 1 )(1-A 2 )*...*(1-A n ) A(t) = (b / a+b) + (a /a+b)* e - (a+b)t bei Alpha: 99,9919 % >>> bei 100.000 Anfragen ist das System 81 mal unavailable bei Beta: 99,9999 % >>> bei 100.000 Anfragen ist das System nur 1 mal unavailable Quelle: Distributed Information Systems, Erroly Simon 99,9919862 % 99,9999726 % MTTR= Mean Time to Repair

14 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 14 Gliederung des Vortrages n Einleitung & Begriffe n Reliability & Availability n Performance n Strategien n Turbo Linux Cluster n Oracle 8i R2

15 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 15 Annahmen: - 1 Client request/second = 6 packets per/ second network traffic - 2 disk I/O per second on a server/client Estimated maximum throughput = 25 client requests/second Estimated main bottleneck = Server disk I/O Main Bottleneck (Flaschenhals) Quelle: Distributed Information Systems, Erroly Simon

16 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 16 RAID Redundand Array of Inexpensive Disks -mirroring -parity Daten Disk ADisk BDisk C Daten Disk ADisk B Techniken: -striping

17 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 17 Striped Disk Array without Fault Tolerance min. 2 Harddisks high I/O performance very simple design not a "True" RAID because it is NOT fault-tolerant the failure of just one drive will result in all data in an array being lost Should never be used in mission critical environments RAID Level 0 Used for: Video Production and Editing Image Editing Pre-Press Applications Any application requiring high bandwidth

18 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 18 100% redundancy of data means no rebuild of data is necessary in case of disk failure, just a copy to the replacement disk Simplest RAID storage subsystem design Highest ECC (Error Checking/Correction) disk overhead of all RAID types (100%) – inefficient Hardware implementation recommendend Mirroring and Duplexing For Highest performance, the controller must be able to perform two concurrent separate Reads per mirrored pair or two duplicate Writes per mirrored pair. min. 2 Harddisks RAID Level 1 Used for: Accounting Payroll Financial Any application requiring very high availability

19 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 19 Independent Data disks with distributed parity blocks Each entire data block is written on a data disk; parity for blocks in the same rank is generated on Writes, recorded in a distributed location and checked on Reads. min 3 Harddisks highest Read data transaction rate medium Write data transaction rate low ratio of ECC (Parity) disks to data disks means high efficiency most complex controller design difficult to rebuild in the event of a disk failure (as compared to RAID level 1) Used for: File and Application servers Database servers WWW, E-mail, and News servers Intranet servers Most versatile RAID level RAID Level 5

20 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 20 Gliederung des Vortrages n Einleitung & Begriffe n Reliability & Availability n Performance n Strategien n Turbo Linux Cluster n Oracle 8i R2

21 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 21 Company Beta Internet/Intranet Router HUB Server A Backup A HDD (gespiegelt) Netzwerk Strategien

22 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 22 Idle Standby Quelle:Linux HA Vortrag German Unix User Group

23 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 23 Mutual Takeover Quelle:Linux HA Vortrag German Unix User Group

24 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 24 Software Komponenten Heartbeat Syslog Hooks Event Scripts Watchdog Configuration Tool Cluster Manager Daemon Quelle:Linux HA Vortrag German Unix User Group

25 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 25 Gliederung des Vortrages n Einleitung & Begriffe n Reliability & Availability n Performance n Strategien n Turbo Linux Cluster n Oracle 8i R2

26 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 26 Der Turbo-Linux Cluster

27 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 27 TurboCluster Architecture Service Cluster Advanced Traffic Manager

28 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 28 Der Turbo-Linux Cluster

29 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 29 Gliederung des Vortrages n Einleitung & Begriffe n Reliability & Availability n Performance n Strategien n Turbo Linux Cluster n Oracle 8i R2

30 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 30 Oracle 8i R2 Cluster Solution Quelle:Oracle

31 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 31 Oracle 8i Cache Strategie Quelle:Oracle

32 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 32 Oracle 8i Load Balancing Quelle:Oracle

33 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 33 Oracle Failover Feature Quelle:Oracle

34 © 1999 Christian Breuker15.12.1999Projektgruppe SAP R/3 auf Linux ClusterSeite : 34 ENDE