Copyright Hermann Brunner - Tel 08092/ Fax 08092/

Transkript

1 Wozu überhaupt über I/O Performance nachdenken? Storage - zu viele Optionen?? Wie wähle ich aus dem umfangreichen Angebot das für mich sinnvollste aus? 2F Relative Performance Memory Größe ( 1000x x) Jahr CPU Geschwindigkeit ( 100x x) I/O Geschwindigkeit (ca. 5x - 10x) 1 2 CI DSSI FC Bus-Systeme Ur-Cluster (1985!) Billigere Lösung für Low-End-Systeme (ca. 1990) Technischer Vorläufer von Varianten-Chaos Billig, wird immer stabiler Seriell, schnell, über Glasfaser Loop-Architektur oder Switched Fabric CI - Eigenschaften Stern-Topologie Maximal 16 Nodes Hardware + Microcode der Controller optimal auf VMScluster abgestimmt Erst 7,75 MHz (CIBCA) später 2x 7,75 MHz (CIXCD) Von DSSI und nicht zu schlagen Erst Fibre Channel kann im VMScluster CI langsam ersetzen 3 4 CI - Konfiguration DSSI - Eigenschaften VAX VAX Alpha Alpha HSJ HSJ HSJ HSJ HSJ HSJ HSJ HSJ Bus-Topologie -ähnliche Protokoll-Architektur, jedoch elektrisch erheblich stabiler Billige Lösung für AlphaServer und VAX4000-Serie Performance Miserabel You get what you pay for 4 MB/sec 5 6

2 DSSI - Typische Konfiguration - lebhafte Geschichte VAX 4500 VAX 4100 AlphaS 4000 HSD HSD SE SE oder DIFF -2 U- 5MHz 5 MB/sec 10 MHz 10 MB/sec wide 20 MB/sec 20 MHz 20 MB/sec wide 40 MB/sec nicht mehr kompatibel LVD U2- U3-40 MHz 80 MB/sec 80 MHz 160 MB/sec Typische Konfiguration Fibre Channel AlphaServer AlphaServer AlphaServer HSZ HSZ Konzept High Performance Serieller Bus Loop-Architektur oder Switched Network Im Moment nicht für direkten Anschluß von Disks geeignet Aber toller Ersatz für CI im VMScluster (I/O only!) Somit ähnliche Probleme mit Cluster-Kommunikation wie -Cluster ( FDDI etc...) 100 MB/sec, später 200 MB/sec 9 10 FC - Typische Konfiguration (2) FC - Typische Konfiguration (1) Cluster-Interconnect FDDI Cluster-Interconnect FDDI Quorumstation ALPHA1 ALPHA2 ALPHA3 ES40 ES40 ES40 2x 5/625 2x 5/625 2x 5/625 2 GB 2 GB 2 GB KGPSA KGPSA KGPSA KGPSA KGPSA KGPSA WILDFIRE 1 Partition1 Partition2 ALPHA1 ALPHA2 KGPSA KGPSA KGPSA KGPSA WILDFIRE 2 Partition1 Partition2 ALPHA3 ALPHA4 KGPSA KGPSA KGPSA KGPSA FC-Switch1 FC-Switch2 FC-Switch1 FC-Switch2 FC-Controller FC-Controller 11 12

3 Controller l HSZxx l HSJxx CI l HSDxx DSSI l HSGxx FC Arrays WB-Cache 13 Disks GB rpm (8,66 ms) 1,5 2MB/s 20ms 18ms 4, Bandbreite versus I/O-Größe 18 9,1 GB / rpm IBM-Disk am Adaptec 2940 VW-Controller Sequential Reads, EZ- Benchmark 36 Drehzahl (Rotational Latency) Bandbreite Response Time Bandwidth [MB/sec] rpm (5,55 ms) 2 2,5 3MB/s 17ms 15ms 14ms rpm (4,33 ms) 4 5 7MB/s 13ms 12ms 12ms rpm (3,0 ms) MB/s 11ms 11ms 10ms K 4K 8K 16K 15 32K 64K 128K 256K 512K I/O Size [KB] Solid State Disk 16 Solid State Disk Host l Konzept: ð Disk-gepufferte Cache ð Dadurch Disk-Verhalten bei (nahezu) Hauptspeicher-Geschwindigkeit ð Real: 0,5-1,5 ms/io ð Bandbreite wie Disk Disk Controller l Vorteil: Exzellente Response Time (R + W) l Nachteil: Teuer, große Kapazität nicht machbar l Optimaler Einsatz: Hot Files, Kleine DBs z.b. HSZ70 17 Solid State Memory Ezxx - Batterie-gepuffert - Automatische Data Retention 18

4 Motivationen für RAID Daten-Sicherheit Verfügbarkeit Disaster-Toleranz Performance Management / Handling Kosten-Reduktion 19 RAID 0 RAID 1 RAID 5 RAID-Optionen Striping auch Host-Based Mirroring Shadowing Praktisch immer Controller Based RAID 1+0 Controller Based Striping + Host Based Shadowing Controller Based Mirroring + Striping nur Host-Based 20 Welches RAID? Shadowing oder Mirroring? Mirroring Einzeldisks Host-Based Caching Ultra- HS 70/80 Räuml. nein Trennung ja Host-Based erforderlich Shadowing? tiefe nein ja Striping I/O Queues? Viele Write-Back nein Writes ja Cache (> 30%)? Striping Bandbreitenorientiert Durchsatzorientiert Striping I/O Demand [MB/sec] [IO/sec] Host based oder Controller based? Redundanz aller Systemteile nötig Shadowing Höchstmögliche Performance Mirroring Direkter Zugriff auf Verwaltung über CMD-Prozeduren nötig (z.b. Shadow Set Rotation ) Shadowing Optimale Kombination mit Striping Mirroring Räumliche Trennung nötig Shadowing Mit HSG70 (Fibre Cannel) wird auch räumliche Trennung über mehrere Cabinetsauf einem Controller-Paar möglich Mirroring Szenario 1 Lösungsansätze 1 Hoher I/O-Durchsatz (IO/sec, nicht MB/sec) Z.B. Oracle Datenbank mit vielen Usern bzw. hohem BATCH-Workload Viel Random - I/O Response Time ist wichtigster Faktor (insbesondere bei WRITES) ❶ Bus weniger wichtig CI,, FC ❷ Controller unbedingt mit Write-Cache ❸ Disks mindestens 7200 rpm ❹ Striping + hilft nur, wenn I/O-Queue vorhanden 23 24

5 Szenario 2 Hohe Bandbreite (MB/sec) Z.B. Video on Demand, Seismik, Meteorologie, Bild-Daten höchster Auflösung Viel Streaming I/O Device- + Bus-Bandbreite zählen... Lösungsansätze 2 ❶ Bus zählt! Ultra, FC ❷ Nur WIDE Disks am Bus ❸ Nur Disks mit rpm ❹ Striping kann Bandbreiten-Defizite der Devices (bedingt) ausgleichen (wenn I/Os groß genug sind, um über mehrere JUNKS zu gehen) Wichtige Indikatoren Problem Random Klein Impulshaft Sequentiell Groß Konstant Viele Reads Viele Writes Striping WB-Cache Hohe Bandbreite Hohe Drehzahl Optimale Cache-Strategie WB-Cache mit Dual-redundantem Controller 27 Einige Daten sind nur schwer feststellbar Sehr gute Monitoring-Tools unbedingt erforderlich! (DECps / Unicenter TNG / AdviseIT, Robomon, ViewPoint / Datametrics) Systematische Auswertung erfordert etwas Erfahrung -...aber es zahlt sich aus!!! 28 Praktisches Beispiel Analyse AlphaServer 4100 / 1GB Hauptspeicher PPS-Anwendung mit Oracle-V7.3 DB Online-Betrieb (tagsüber) Performance nicht berauschend, aber OK Nachtverarbeitung (Batch) viel zu langsam (8 Stunden) es bleibt nicht mehr genug Zeit für Backup System soll aufgerüstet werden CPU tagsüber zu ca. 40% ausgelastet, mittlere CPU-Queues. CPU nachts zu ca. 22% ausgelastet, sehr geringe CPU-Queues. Hauptspeicher tagsüber max. 75% belegt. nachts max. 50% belegt. I/O-Subsystem wirkt NICHT überfordert. Kaum I/O-Queues, insbesondere nachts

6 Analyse (2) Datafiles gut verteilt 10 Files auf 8 Disks I/O-Raten jedoch mieserabel balanciert 2 Disks leisten 80% vom gesamten I/O keine Write-Cache im Controller während Nachtverarbeitung etwa 60% Write-Zugriffe zu den zwei kritischen Disks VCC-Cache und/oder Rdb-Buffering wirken offensichtlich sehr gut. 31 Maßnahmen Upgrade HSZ40 auf HSZ70 weil Ausrüstung des HSZ40 mit Write- Cache wirtschaftlich nicht vertretbar neuer HSZ70 Dual-Redundant mit 64MB Nach Rücksprache mit DBA: 6 x 2 x 9GB Stripe/Mirror-Set für Datafiles Alle Datafiles auf das eine Set. 1 x 2 x 9GB Disk für Redo-Logs und Archive 32 Erfolg Online-Performance etwas besser nächtliche Batch-Performance: 8 Stunden-Job braucht jetzt 2:50 Stunden CPU-Auslastung dabei von ca. 22% auf ca. 50% angestiegen. Übrigens: Ohne diese Analyse hätte man eine zweite CPU und ein weiteres GB für die 4100 gekauft, da das System am Ende ist BY THE WAY... Wenn ein Full Table Scan einer Oracle- Datenbank heute eine Stunde dauert, kann er ❶mittels neuester Hardware vielleicht auf min beschleunigt werden Faktor 2-3 ❶durch Einführung eines schlauen Index vielleicht vollständig vermieden werden. 1 sec Faktor