Tiefgehende Grundlagen SAN-Storage, IOPS, Raids, usw.

[StefanWe 14]

Hallo,

 

ich merke immer wieder bei verschiedenen Problemen, gerade in der Virtualisierung, dass man das Storage nicht außer Acht lassen sollte.

Dies ist sicher für viele jetzt nicht neu. :D

 

Aber ich muss ganz ehrlich sagen, ich habe da erhebliche Wissenslücken.

Vielleicht kann ja der ein oder andere zu den kommenden Fragen etwas berichten und evtl. sogar darüber hinaus seine Erfahrungen posten.

 

Fangen wir mal bei den RAID Systemen an. Ich muss mir ja nun überlegen, was will ich eigentlich darauf laufen lassen.

Raid 0 und Raid 1 lass ich jetzt mal außen vor, da ich denke, das diese eher selten bei SAN Systemen zum Einsatz kommen.

RAID5 = höhere Leserate, niedrigere Schreibrate. Hohe Speicherkapazität

RAID6 = gleich wie RAID5 nur mit 2 Paritätsplatten. Daher nicht so hohe Speicherkapazität.

RAID10 = niedrige Speicherkapazität, aber deutlich höhere Schreib und Lese Rate.

 

Soweit richtig, oder?

Ich möchte nun Server Virtualisierung betreiben. In der Regel würde ich mich jetzt zwischen RAID5 oder 6 entscheiden.

Doch wann macht ein Raid 10 Sinn? Doch eher wenn ich genügend Geld habe und doch mehr Platten kaufen kann um etwas mehr Performance zu bekommen?

Wie sieht es mit IOPS aus? Wie wichtig sind diese und was sind ca. Norm Werte, welche mein Storage mindestens erfüllen sollte?

 

Was ich bei verschiedenen Projekten immer wieder festgestellt habe, dass der eigentliche Durchsatz beim sequenziellen Lesen gar nicht so entscheidend ist, sondern eher der Random Access. Was bietet sich hier auf oben geannte Raids am besten an?

 

Habt ihr Erfahren, wie viele Festplatten in einem RAID betrieben werden sollten, was zu Verbesserung führt und was eher nicht?

 

Und der letzte Punkt, wie sieht es mit Troubleshooting aus. Wenn ihr merkt, eure VM's sind langsam. Sie starten träge und die Apps noch viel träger. Wie beginnt ihr? Aktuell habe ich z.B. auf einer VMware Umgebung ein ähnliches Problem. Wir wissen, dass es das Storage ist. Im vCenter sehen wir, dass die Last des Storages aber "eigentlich" in Ordnung ist. Verschieben wir eine VM auf ein anderes RAID, welches nicht benutzt wird, ist alles schnell. Sequenzielles lesen allerdings ist super. Daher vermuten wir, Random Access.

Oder wie sieht es z.B. mit den FC Karten aus. Mir ist Adhoc kein Storage oder Hypervisor System bekannt, wo ich erkenne, dass meine FC Ports ausgelastet sind. Was ja auch schnell mal passieren kann, wenn ich ein großes Storage mit Zig Shelfs habe und nur 2 oder 4 FC Ports mit 4GB.

Doch wie monitored, troubleshootet und beweist man so etwas am besten?

 

Ich weiß, viel Text. Wäre nett, wenn der ein oder andere aus seinen Erfahrungen berichten könnte.

 

Vielen Dank und Grüße

 

Stefan

[Dukel 436]

Das alles ist ein sehr komplexes Thema.

Das mit dem Raidlevel ist nicht so einfach. Ein Raid 10 hat z.B. (ganz pauschal) eine höhere Schreibrate, dafür ein Raid 5 eine höhere Leserate.

 

Meist gibt es auch vom Storagehersteller Empfehlungen oder Automatismen.

Netapp z.B. hat Raid 4 und Raid 6 und empfiehlt Raid 6 (Raid DP).

 

Das benötigte Raidlevel und die benötigten IOPS kommen auf den Workload und die Anforderungen an.

Ein (virtueller) Fileserver braucht eine andere Konfiguration wie ein SQL Server.

 

Zum Troubleshooting / Monitoring: Kommt wie immer auf die Komponenten an. Unterschiedliche HBA's haben unterschiedliche Tools, Storagesysteme haben unterschiedliche Tools und Switche haben widerum unterschiedliche Tools.

 

Es gibt einen Monitoring / Management Standard namens SMI-S. Damit sollte sich alles vereinheitlichen lassen.

 

Bei Problemen muss man einfach den kompletten Stack analysieren. Von dem VM Gast über den Hypervsor, Server, HBA, Switch bis zur Storage.

[StefanWe 14]

Hi Dukel, danke für deine Antwort.

 

Bzgl. der Tools für HBA usw. habe ich ja in einer virtuellen Umgebung, sagen wir mal VMware das Problem, dass ich dort keine Tools installieren bzw. nutzen kann. Außer, wenn es der Hypervisor unterstützt, was wie ich finde teilweise sehr **** ist.

 

Könntest du denn z.B. noch was zu den allgemeinen IOPS sagen, was so Norm Werte usw. sind.

 

Das natürlich ein Fileserver andere Daten braucht, als ein SQL, ist mir allerdings schon bewusst ;)

[StefanWe 14]

Habe gerade dieses hier gefunden.

MSXFAQ.DE - IOPS

 

Dort steht, dass eine 10k Festplatte ca 130-150IOPS macht. Gehen wir bei heutigen aktuellen Festplatten von mal 150 IOPS aus.

 

Heißt das, wenn ich ein System brauche mit 1000 IOPS, das ich dann 6,6 Festplatten dafür benötige?

In einem RAID dann 8, weil eine als Parität verloren geht?

 

Doch wie verhalten sich IOPS zur eigentlichen Lese und Schreib Geschwindigkeit? AUch gerade im Bezug, wenn ich viele VMs mit kleinen Random Lese Zugriffen habe?

[Dukel 436]

Die IOPS kommen auch auf das RAID Level an.

 

Ich würde mich beim Storage Hersteller Informieren. Dieser hat meist Formeln und Best Practices. Bei Netapp ist es z.B. Raid 6, bei EMC Raid 5 was lt. Hersteller die beste Performance bringt.

 

Außerdem kann man meist mehrere Raidgruppen zusammenfassen. Bei Netapp sind das dann mehrere Raidgruppen a 12-14 Disks bei EMC mehrere mit 5 oder 8 Disks. Durch diese mehrere Raidgruppen kommt dann die Peformance zustande.

 

Paschal kannst du sagen, je mehr Disks (Spindeln) desto mehr Performance.

 

 

Wenn du viel Random IO hast und Performance brauchst dann willst du SSD's nutzen.

[Dunkelmann 96]

Es es sehr schwer zu dem Thema pauschale Aussagen zu treffen.

 

Ein zusätzlicher Faktor bei der Auswahl des RAID Levels sollte auch die Gesamtzahl der Platten im Verbund sein.

Je mehr Platten, um so höher ist die Wars***einlichkeit, dass eine oder mehrere ausfallen (können).

Oftmals gibt es die Empfehlung bei mehr als 10 oder 12 Platten in einem Verbund, RAID 6 einzusetzen um 2 Paritätsplatten zu haben. Durch RAID 6 gibt es auf der anderen Seite aber wieder Performanceeinbußen durch das doppelte Anlegen der Parität.

 

Die Anbindung kann auch zum Flaschenhals werden. Nehme ich iSCSI 1GBE, 10GBE, gehe ich auf FC oder reicht mir SAS?

Das schnellste System im Backend nützt nichts, wenn die Daten im Netz nicht durchkommen.

 

Zur eigentlichen Ermittlung des IOPS Bedarfs, kann man im besten Fall auf eigene historische Daten zuzugreifen. Viele Storage Hersteller bieten Monitoring Tools an oder man hat einen Operations Manager am laufen und zieht sich die notwendigen Berichte.

Hat man keine eigenen Daten, muss man ein wenig recherchieren und den IOPS Bedarf seiner Systeme anhand von Richtwerten und Empfehlungen schätzen.

Dabei ist es im Prinzip egal ob die Empfehlung eines Softwareleferanten sich auf physische oder virtuelle Systeme bezieht. Der IOPS Bedarf ist in beiden Szenarien annähernd gleich.

 

Hat man sich dann für ein System entschieden, sollte man vor dem Produktivsetzen noch ein paar eigene Tests durchführen.

Dazu bietet sich zB IO Meter an. Damit kann man sich schöne Jobs anlegen, die individuell auf den zu erwartenden Workload abgestimmt sind.

Hat man vorher sauber seine Anforderungen definiert, sich vom Lieferanten schriftlich bestätigen lassen, dass das Storage diese Anforderungen erfüllt, hat man gute Chancen das System notfalls noch auszutauschen, wenn die Performance doch nicht ausreichen sollte.

[Dunkelmann 96]

Wenn du viel Random IO hast und Performance brauchst dann willst du SSD's nutzen.

In kleineren Umgebungen kann eventuell auch ein Controller mit 4 oder 8 GB Cache den Einsatz von SSD sparen.

[bla!zilla 10]

Nein, das spart dir sicherlich nicht den Einsatz von SSDs. Der Cache hat noch ein paar andere Funktionen. Wenn du einen Usecase für SSDs hast, dann setz welche ein. Ich halte die Einsatzmöglichkeiten für SSDs immer noch für sehr beschränkt, zumal die Leistung in vielen Umgebungen einfach verpufft.

 

RAID5 = höhere Leserate, niedrigere Schreibrate. Hohe Speicherkapazität

 

It depends on... Es kommt auf den Workload an und wie ein RAID Controller das Ganze optimiert. Dein größtes Problem ist die Write Penalty, und die trifft dich vor allem bei Short Writes.

 

RAID6 = gleich wie RAID5 nur mit 2 Paritätsplatten. Daher nicht so hohe Speicherkapazität.

 

... und eine noch viel schlimmere Write Penalty. Dazu kommt eine noch niedrigere Rate an effektiven IOPS.

 

RAID10 = niedrige Speicherkapazität, aber deutlich höhere Schreib und Lese Rate.

 

Korrekt.

 

Ich möchte nun Server Virtualisierung betreiben. In der Regel würde ich mich jetzt zwischen RAID5 oder 6 entscheiden.

 

Gewagte Bauchentscheidung...

 

Doch wann macht ein Raid 10 Sinn? Doch eher wenn ich genügend Geld habe und doch mehr Platten kaufen kann um etwas mehr Performance zu bekommen?

 

It depends on... Es kommt auf deinen Usecase an. Wenn du kompromisslose Performance brauchst, gepaart mit hoher Verfügbarkeit, dann brauchst du RAID 1+0.

 

Wie sieht es mit IOPS aus? Wie wichtig sind diese und was sind ca. Norm Werte, welche mein Storage mindestens erfüllen sollte?

 

Wie wichtig sind PS? IOPS sind IOs pro Sekunde. Und IOPS x IO Größe = MB/s. Eine ganze einfache Gleichung.

 

Wieviele IOPS du brauchst, hängt von deinen Anforderungen ab. Natürlich machst du vor einem Virtualisierungsprojekt in Assesment und schaust dir die Systeme an. Misst und entwickelst dann eine Lösung.

 

Was ich bei verschiedenen Projekten immer wieder festgestellt habe, dass der eigentliche Durchsatz beim sequenziellen Lesen gar nicht so entscheidend ist, sondern eher der Random Access. Was bietet sich hier auf oben geannte Raids am besten an?

 

Wie hast du das gemessen?

 

Habt ihr Erfahren, wie viele Festplatten in einem RAID betrieben werden sollten, was zu Verbesserung führt und was eher nicht?

 

Mehr Platten = Mehr Performance und weniger Overhead. Nachteil: Mit jeder Platte steigt die Möglichkeit des Plattenausfalls in einem Array und damit auch die Möglichkeit eines Double Failures. Zudem bist du oft durch die Controller limitiert.

 

Doch wie monitored, troubleshootet und beweist man so etwas am besten?

 

Durch Tools des Herstellers oder geeignete Systemmanagementlösungen. Es ist deine Aufgabe das mit in die Lösung einzubinden. Sonst passiert das, was du bei deinem Kunden gerade siehst: Blindflug. Und wenn du dann wichtige Grundlagen nicht beherrscht, dann tappst du im Dunkeln und findest keinen Ausweg. Alles nur Vermutungen, aber keine stichhaltigen Anhaltspunkte für das Troubleshooting.

 

Brocade FC Switches bringen z.B. Fabric Watch, Top Talkers etc. mit. Oder den Brocade Network Advisor oder SAN Health. Für Cisco MDS gibt es ähnliche Tools. Ethernet Switches (für iSCSI Umgebungen) lassen sich meist auch sehr gut monitoren, HP ProCurves z.B. mit dem ProCurve Manager.

 

Wichtig ist aber, dass du die Basics verstanden hast.

bearbeitet 2. Juli 2012 von bla!zilla

[zahni 521]

Für den Anfang ist das HP SAN Design Reference Guide zu empfehlen. Ist zwar in Teilen herstellerspezifisch, bringt aber einen guten Überblick:

 

http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c00403562/c00403562.pdf

[bla!zilla 10]

Der SAN Design Guide setzt aber schon auf einem recht hohen Level an und bezieht sich nur auf FC Fabrics. Einen Teil der Informationen kann man durchaus auf andere Hersteller übertragen: C-Series sind Cisco MDS, H-Series sind Qlogic, B-Series sind Brocade, und M-Seriess ind McData Switches (schon vor einiger Zeit von Brocade geschluckt).

 

Aktuell wird hier ja nur über RAID Level und IOPS gesprochen. Meist krankt es an Bauchentscheidungen bei der Plattenauswahl und -anzahl, bzw. wenn da genug Leistung vorhanden ist, verpufft das gerne mal in schlechten Fabrics bzw. schlechten iSCSI SAN Designs.

[StefanWe 14]

Hi,

 

danke für die vielen Antworten.

 

blazilla schreibt. MB lässt sich über die IO Größe berechnen. Wie bekomme ich diese denn eigentlich heraus?

 

Etwas anderes noch. Nehmen wir an, eine Platte schafft 200 IOs. Wir nehmen ein Raid5 mit 3 Platten. D.h. wir würden dann 600 IOPS schaffen?

 

Steht der maximal Wert immer zur Verfügung, oder durch was kann dieser herabgesetzt werden? Z.B. viele kleine Schreibzugriffe usw.

Gerade hier weiß ich ja, wenn ich auf einer Platte Lese und Schreibe, dass die Performance stark in den Keller geht.

 

Wie genau kann ich Tools wie IOMeter oder dem Windows Perf Mon trauen, wenn ich einen Test auf einem RAID ausführe und ich dort 240 IOPS angezeigt bekomme?

 

Versucht ein System eigentlich immer die maximale IO Zahl vom Storage zu bekommen? D.h. wenn mein Storage 2000 IOPS zur Verfügung stellt und ich eine 10 GB Große Datei von A nach B kopiere, und nichts anderes auf dem System läuft, würden die 2000 IOPS hierfür genutzt?

 

Vielen dank für die Mühe.

[Dukel 436]

Bei einem Raid 5 ist ein Schreibforgang 4 IO's. d.h. die 600IOPS teilst du durch 4.

Das verhältnis ist beim lesen aber besser.

[StefanWe 14]

Bei einem Raid 5 ist ein Schreibforgang 4 IO's. d.h. die 600IOPS teilst du durch 4.

Das verhältnis ist beim lesen aber besser.

 

Ok, das versteh ich jetzt mal überhaupt nicht. Warum ist bei einem RAID 5 ein Schreibvorgang 4 IOs? Wenn ich nur 3 Datenträger habe? Genaugenommen wird ja nur auf 2 Datenträgern geschrieben und auf dem 3. wird die Parität abgelegt.

 

Wenn ich nun die 600 durch 4 Teile habe ich ja 50 IOs weniger als wenn ich kein Raid einsetzen würde.

[bla!zilla 10]

blazilla schreibt. MB lässt sich über die IO Größe berechnen. Wie bekomme ich diese denn eigentlich heraus?

 

IO Größen kannst du messen. Ansonsten gibt es ein paar Standardwerte, die sich in der Praxis bewährt haben. Zum Beispiel arbeiten die meistne Datenbanken mit 4k bis 8k IOs, Exchange z.B. mit 32k etc.

 

Etwas anderes noch. Nehmen wir an, eine Platte schafft 200 IOs. Wir nehmen ein Raid5 mit 3 Platten. D.h. wir würden dann 600 IOPS schaffen?

 

Theoretisch ja. Nun hängt es aber davon ab ob es Read oder Write IO ist, ob short oder long IO, random oder sequential IO.

 

Steht der maximal Wert immer zur Verfügung, oder durch was kann dieser herabgesetzt werden? Z.B. viele kleine Schreibzugriffe usw.

Gerade hier weiß ich ja, wenn ich auf einer Platte Lese und Schreibe, dass die Performance stark in den Keller geht.

 

Ist doch logisch, oder? Die Platte schafft in Summe eine bestimmte Anzahl IOPS. Wenn du nun liest und schreibst, vielleicht sogar random und sequential, dann kann dein konkreter IO Vorgang nur eine Teilmenge davon nutzen. Hängt halt auch vom IO Verhalten des Betriebssystems ab, wie es IOs priorisiert, von der Queue Tiefe etc.

 

Wie genau kann ich Tools wie IOMeter oder dem Windows Perf Mon trauen, wenn ich einen Test auf einem RAID ausführe und ich dort 240 IOPS angezeigt bekomme?

 

Kommt darauf an. Du testst hier vom Betriebssystem aus. In Richtung des rotierenden Rostes kommen noch Software, Bussysteme, Cache etc.

 

Versucht ein System eigentlich immer die maximale IO Zahl vom Storage zu bekommen? D.h. wenn mein Storage 2000 IOPS zur Verfügung stellt und ich eine 10 GB Große Datei von A nach B kopiere, und nichts anderes auf dem System läuft, würden die 2000 IOPS hierfür genutzt?

 

Warum sollte das nicht so sein?

[bla!zilla 10]

Bei einem Raid 5 ist ein Schreibforgang 4 IO's. d.h. die 600IOPS teilst du durch 4.

Das verhältnis ist beim lesen aber besser.

 

Ok, das versteh ich jetzt mal überhaupt nicht. Warum ist bei einem RAID 5 ein Schreibvorgang 4 IOs? Wenn ich nur 3 Datenträger habe? Genaugenommen wird ja nur auf 2 Datenträgern geschrieben und auf dem 3. wird die Parität abgelegt.

 

Wenn ich nun die 600 durch 4 Teile habe ich ja 50 IOs weniger als wenn ich kein Raid einsetzen würde.

 

Jein. Es kommt darauf an wie es der Controller organisiert und ob es ein long oder short IO ist. Bei einem Short IO (also ändern eines Chunks in einem Stripe) sind es vier IOs:

 

1. Chunk lesen

2. Parity lesen

3. Chunk schreiben

4. Parity schreiben

 

Wird der ganze Stripe geschrieben, dann kann sich der Controller das Lesen vorher sparen und direkt in einem Rutsch durchschreiben. Der dritte IO ist dein eigentlicher, effektiver IO. Der Rest ist Overhead und wird als Write Penalty bezeichnet. Deswegen sind paritätsbasierte RAID Level (RAID 3, 4, 5, 6 etc.) bei short Writes eine schlechte Wahl. Außer man hat entsprechend viele Platten...