DOAG Konferenz 2007 in Nürnberg

Transkript

1 DOAG Konferenz 2007 in Nürnberg Auswahl und Sizing: Die richtige Hardware (+Software) für Oracle Björn Bröhl Projektmanager Handlungsbevollmächtigter Seite 1

2 Inhalt Die Zielsetzung Vorgehensweise Auswahl Hardware (Server, Storage, Netzwerk?) 32Bit oder 64Bit? Software (Betriebssystem) Sizing Kennzahlen Hardware Multicore-CPU`s Storage-System Praxis-Beispiele Review Seite 2

4 Mögliche Fragen: Vorgehensweise: Zielsetzung Was soll auf dem neuen System alles betrieben werden? Oracle Datenbank,Oracle Application Server,... Definition der grundlegenden Anforderungen Soll ein bestehendes System migriert werden? dann existieren möglicherweise Erfahrungswerte (Kennzahlen)! Muss Hochverfügbarkeit und Sicherheit berücksichtigt werden? Neu-Definition der grundlegenden Anforderungen Seite 4

5 Bewährt in vielen Projekten: Vorgehensweise 1. Definition der Anforderungen festlegen der Ziele z.b. einzusetzende Versionen, Verfügbarkeit, Security etc. 2. Bestimmung der Architektur z.b. Client/Server, Web, Cluster etc. 3. Berechnung der Kennzahlen Wie viele Anwender arbeiten mit dem System? 4. Erstellung eines Architekturentwurfes grobes Design 5. POC / Benchmark zur Überprüfung Verfeinerung der Architektur Seite 5

7 Auswahl: Hardware-Hersteller (Auswahl) Beispiel Prozessoren:??? Intel Core2 Intel Xeon Intel Itanium2 AMD Opteron Sun UltraSPARC T2 und T1 Sun SPARC64-VI

8 Auswahl: 32Bit oder 64Bit? 1/2 Unterschiede: - z.b. Speicheradressierung: (Quelle: Microsoft) 2 32 = Bytes = 4 GBytes 2 64 = Bytes = GBytes = 16 ExaBytes

9 Auswahl: 32Bit oder 64Bit? 2/2 32Bit oder 64Bit? Es sind kaum noch 32Bit-Systeme zu bekommen 64Bit-Systeme sind grundsätzlich zu bevorzugen Verfügbarkeit von Software (und Release-Zyklen) berücksichtigen (vergl. Oracle RDBMS 11g!)

10 Auswahl: Hard- und Software-Hersteller (Auswahl)???

11 Auswahl: Auswahl des Betriebssystems 1/2 Möglichkeiten: Unix / Linux Red Hat Enterprise Linux Oracle Enterprise Linux SuSE Linux Enterprise Server IBM AIX HP UX Sun Solaris (x86, x86_64, SPARC) Windows /64Bit 2003 Itanium

12 Auswahl: Auswahl des Betriebssystems 2/2 Vorgehensweise / Fragen: Gibt es Vorgaben innerhalb der IT- bzw. Anbieter-Strategie? Wo gibt es das beste KnowHow innerhalb des Unternehmens? Was unterstützt die Hardware (was ist zertifiziert)? muss alles selbst beantwortet werden! Antworten: Release- und Patch-Strategie von Oracle beachten! eigentlich kein klares pro oder kontra zu Windows vs. Linux 75% aller OC-Datenbank-Installationen unter Linux/Unix 95% aller OC-RAC-Installationen unter Linux/Unix Zertifizierungen einhalten (gerade bei komplexeren Systemen, siehe Beispiele)

14 Bewährt in vielen Projekten: Sizing: Kennzahlen (Vorgehensweise) 1/7 1. Definition der Anforderungen festlegen der Ziele z.b. einzusetzende Versionen, Verfügbarkeit, Security etc. 2. Bestimmung der Architektur z.b. Client/Server, Web, Cluster etc. 3. Berechnung der Kennzahlen Wie viele Anwender arbeiten mit dem System? 4. Erstellung eines Architekturentwurfes grobes Design 5. POC / Benchmark zur Überprüfung Verfeinerung der Architektur Seite 14

15 Sizing: Kennzahlen 2a/7 Welche Werte müssen als Kennzahl berücksichtigt werden? CPU (Taktfrequenz und Anzahl) Speicherbedarf auf Festplatte Speicherbedarf im Arbeitsspeicher IO-Transaktionen Netzwerk-Traffic

16 Sizing: Kennzahlen 2b/7 Wie können diese Werte ermittelt werden? CPU (Taktfrequenz und Anzahl) Erfahrungswerte, Berechnung anhand anderer Kennzahlen wie z.b. IO, etc. Speicherbedarf auf Festplatte Vorgaben von Oracle + Transaktionsvolumen Speicherbedarf im Arbeitsspeicher Vorgaben von Oracle + Speicherbedarf Anzahl d. Sessions IO-Transaktionen Erfahrungswerte, Ermittlung durch Lasttest/Benchmark Netzwerk-Traffic Erfahrungswerte, Ermittlung durch Lasttest/Benchmark

17 Sizing: Kennzahlen 3/7 Wege zur Bestimmung von Kennzahlen: Betrachtung der Alt-Systeme Oracle Installation Guides

20 Sizing: Kennzahlen 4/7 Wege zur Bestimmung von Kennzahlen: Betrachtung der Alt-Systeme Oracle Installation Guides / Tuning Guides / OTN / Metalink

21 Sizing: Kennzahlen 5/7 anderes Beispiel:

22 Sizing: Kennzahlen 5/7 anderes Beispiel:

23 Sizing: Kennzahlen 6/7 weiteres Beispiel:

24 Sizing: Benchmarks / Lasttests 7/7

28 Sizing: (Hardware) Single-Core vs. Multi-Core 1/4

29 Sizing: (Hardware) Single-Core vs. Multi-Core 2/4 Sinn und Zweck Mehrkernprozessoren wurden entwickelt, weil die Kosten für den Einsatz eines einzelnen Chips mit mehreren Ressourcen häufig geringer sind als bei mehreren einzelnen Chips. Anders betrachtet kann mit der gleichen Anzahl an Chip-Sockeln und Chips theoretisch eine vervielfachte Rechenleistung erzielt werden (das Zweifache bei Doppelkernen). In der Realität kann diese Steigerung jedoch nie erreicht werden, die Leistungssteigerung schwankt, je nach Programm, zwischen nicht vorhanden (bei nicht auf Mehrkernprozessoren ausgelegter Software) und fast 100 % (bei stark optimierter Software). ( ) Mehrkernprozessoren stellen neben einer Erhöhung der Taktfrequenz und dem Pipleining eine von vielen Möglichkeiten dar, die Leistung von Mikroprozessoren zu erhöhen. In der Praxis hängt die Leistungssteigerung aber stark von dem Parallelisierungsgrad des ausgeführten Programms und des verwendeten Betriebssystems ab. Quelle: Wikipedia

30 Sizing: (Hardware) Single-Core vs. Multi-Core 3/4 Vergleich zwischen OLTP und DWH-Anwendung Single-Core OLTP Hohe Anzahl von einzelnen Transaktionen (z.b. einzelnen Sessions) - DWH Hohe Belastung einzelner CPU/Kerne (z.b. bei Auswertungen oder Aggregation von Daten) ++ Multi-Core ++ +

31 Sizing: (Hardware) Single-Core vs. Multi-Core 4/4 besser im Vergleich zu Single-Core-CPU`s bei gleicher Anzahl der Gesamtkerne! (ermittelt bei OLTP-Benchmarks)

32 Sizing: (Hardware) Storage-Systeme 1/4 allgemeine Fragen zur Auswahl eines Storage-Systems (Auszug): Wie erfolgt die Anbindung (IP bzw. ISCSI, SCSI, FC,etc.)? Sollen Snapshots zum Backup verwendet werden? Soll der Speicher auf einen anderen Standort gespiegelt werden? Soll ein bestehendes Storage-System weiter verwendet werden? Fragen zu den Facts : Wie groß muss der Speicher dimensioniert werden? Welche Zugriffszeiten müssen realisiert werden? Welche Transaktionsraten müssen realisiert werden?

33 Sizing: (Hardware) Storage-Systeme 2/4 Antworten auf die allgemeine Fragen zur Auswahl eines Storage-Systems: Wie erfolgt die Anbindung (IP bzw. ISCSI, SCSI, FC,etc.)? empfohlen wird mind. FC Sollen Snapshots zum Backup verwendet werden? bietet sich z.b. bei großen Datenmengen, oder zum Aufbau von Test-Systemen an (Achtung bei Multi-Volume-Snapshots!) Soll der Speicher auf einen anderen Standort gespiegelt werden? bietet Schutz gegen den Ausfall eines Storage-Systems (K-Fall) Soll ein bestehendes Storage-System weiter verwendet werden? wenn ja, ggf. Storage-Virtualisierung

34 Sizing: (Hardware) Storage-Systeme 3/4 Antworten auf die Fragen zu den Facts : Wie groß muss der Speicher dimensioniert werden? Ermittlung kann z.b. auf den Werten des Alt-Systems erfolgen auslesen aus der DB (z.b. OC-DB-Info-Tool) oder durch Benchmarks Welche Zugriffszeiten müssen realisiert werden? Ermittlung kann z.b. auf den Werten des Alt-Systems erfolgen Durchführung von Benchmarks Welche Transaktionsraten müssen realisiert werden? Ermittlung kann z.b. auf den Werten des Alt-Systems erfolgen Durchführung von Benchmarks

35 Sizing: (Hardware) Storage-Systeme 4/4 Beispiel für eine mögliche Architektur mit Storage-Virtualisierung: Site A Site B Oracle DB RAC Oracle DB Tape- Library Storage- Virtualisierung Storage- Virtualisierung Storage-ALT (langsam) Storage-NEU (schnell) Storage-NEU (langsam)

37 Das Praxis-Beispiel 1/3 Migration Oracle DB ? Unterstützung durch Oracle 11g Real Application Testing

38 Das Praxis-Beispiel 2/3 Migration Oracle DB RAC Kennzahlen können von Single-Instance nicht einfach auf ein RAC übertragen werden (Berücksichtigung von Interconnect und Block- Shipping!) Hardware-Vorgaben für RAC beachten (siehe Metalink) Durchführung eines Lasttests wird empfohlen!

39 Das Praxis-Beispiel 3/3 Migration Oracle Forms 6i Client Server Forms 10g Web Berücksichtigung fixer Kennzahlen wie z.b. Speicher pro Forms- Session auf dem OAS (mind. ca. 25MB) Möglichkeit der Wahl einer speziellen CPU wie z.b. Sun T1/T2 Skalierbarkeit durch (Netzwerk)-Loadbalancing Durchführung eines Lasttests wird empfohlen!

41 Bewährt in vielen Projekten: Review: Vorgehensweise 1. Definition der Anforderungen festlegen der Ziele z.b. einzusetzende Versionen, Verfügbarkeit, Security etc. 2. Bestimmung der Architektur z.b. Client/Server, Web, Cluster etc. 3. Berechnung der Kennzahlen Wie viele Anwender arbeiten mit dem System? 4. Erstellung eines Architekturentwurfes grobes Design 5. POC / Benchmark zur Überprüfung Verfeinerung der Architektur Seite 41

42 Fragen und Antworten Kontakt: Björn Bröhl Tel: / Mobil: 0173 / bjoern.broehl@opitz-consulting.de Seite 42