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

[StefanWe 14]

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...

 

Mh... sehr interessant. Und wenn ich jetzt frage, woher ich short oder Long writes bekomme, wirst du vermutlich sagen, dass es an der Software liegt. Richtig?

[bla!zilla 10]

Die Stripesize oder Chunksize kannst du bei den meisten Controllern konfigurieren. Gibst du die Chunksize an, erhälst du über die Gesamtanzahl der Platten im RAID die Stripesize. Hast du die Stripesize, dann kommst du über die Gesamtanzahl der Platten im RAID zur Chunksize. Nun brauchst du wieder die IO Größe. Ist die IO Größe kleiner als die Chunksize, dann hast du wohl einen short IO...

 

Bleibt die Frage ob du MB/s haben willst oder viele IOPS. Soll jeder IO nur genau eine Platte beschäftigen, oder sollen sich mehrere Platten um einen IO kümmern?

[StefanWe 14]

 

Bleibt die Frage ob du MB/s haben willst oder viele IOPS. Soll jeder IO nur genau eine Platte beschäftigen, oder sollen sich mehrere Platten um einen IO kümmern?

 

Pauschal würde ich jetzt behaupten in einem VDI Szenario brauche ich viele IOPS. Da die einzelnen VM's nicht viel Durchsatz benötigen, sondern eher viele kleine IOs haben.

 

Kannst du für beide Szenarien Beispiel Konfigurationen nennen? Also, was brauche ich um mehr Durchsatz (MB) zu erzielen, und was brauche ich um die IOs zu erhöhen?

 

Vielen Dank.

[bla!zilla 10]

Bei VDI brauchst du weder viele MB/s, noch brauchst du viele IOPS. Ein virtueller Desktop kommt mit relativ wenig Leistung aus.

 

Ein Sizing aus dem Bauch heraus ist schwer. Grundsätzlich brauchst du, wenn du IOPS haben willst, vor allem eines: Platten, Platten, Platten... schnelle Platten. Wenn du dann MB/s haben willst, dann brauchst du große IOs.

 

Einfaches Beispiel: Exchange bis Exchange 2003 nutzt 4 KB IOs. Wenn ich z.B. aus einem System 4000 IOPS gezogen habe, dann bin ich gerade mal auf ca. 16 MB/s gekommen. Arbeite ich z.B. mit großen Files, die ich in großen IOs lese (z.B. 256 KB), dann komme ich ebi 4000 IOPS schon auf knapp 1000 MB/s.

[StefanWe 14]

Bei VDI brauchst du weder viele MB/s, noch brauchst du viele IOPS. Ein virtueller Desktop kommt mit relativ wenig Leistung aus.

 

Ein Sizing aus dem Bauch heraus ist schwer. Grundsätzlich brauchst du, wenn du IOPS haben willst, vor allem eines: Platten, Platten, Platten... schnelle Platten. Wenn du dann MB/s haben willst, dann brauchst du große IOs.

 

Einfaches Beispiel: Exchange bis Exchange 2003 nutzt 4 KB IOs. Wenn ich z.B. aus einem System 4000 IOPS gezogen habe, dann bin ich gerade mal auf ca. 16 MB/s gekommen. Arbeite ich z.B. mit großen Files, die ich in großen IOs lese (z.B. 256 KB), dann komme ich bei 4000 IOPS schon auf knapp 1000 MB/s.

 

Zum VDI Thema gibt es ja diverse White Papers. Wenn man mit 30 IOPS pro Desktop rechnet bin ich bei 100 Desktops schon bei 3000 IOPS. Das sind meiner Meinung nach schon recht viel ;)

 

Hast du irgendwo gute Lektüre, wo man sich all das noch mal in Ruhe nachlesen kann? Gerade auch im Bereich, wie size ich richtig. Woher weiß ich, welche IO Größe ich habe.

 

Ich meine gelesen zu haben, das ESX Server mit 4K IOs von den Platten lesen, und in den RAM schreiben. Kann ich mir allerdings schlecht vorstellen.

 

Die IO Größe wird also, wenn ich das richtig verstehe, von der Software, nicht vom OS bestimmt. Oder?

 

Wie sieht das dann mit virtuellen Maschinen aus? Wer setzt dort die IO Größe?

[bla!zilla 10]

Kommt drauf an... Ich rechnte für eine 15k SAS Disk, ohne Cache o.ä., 200 IOPS (kannst du dir sogar selber ausrechnen... Du brauchst nur Seektime und Rotation Latency). Wenn du 3000 IOPS (write) brauchst, dann hängt es vom RAID Level ab. Bei RAID 1+0 kannst du 50% der IOPS nutzen, bei RAID 5 nur 25%. Dementsprechend brauchst du 30 bzw. 60 Disks. Ist natürlich ohne Caches gerechnet... Pi x Auge x Hackebeil. Und wir haben hier noch nicht über IO Größen gesprochen...

 

Die heutigen Plattengrößen sind eine Pest. Viele Kunden/ Dienstleister orientieren sich an der Kapazität, nicht an den geforderten IOPS. Nicht umsonst finde ich immer mal wieder virtuelle Serverumgebungen mit viel RAM, verdammt vielen Kernen, 10 GbE... und einer Handvoll Platten. Man sollte sich eher an den notwendigen IOPS orientieren. Ich bin auch immer ein Freund von kleineren und schnelleren Platten. Ist eine Preisfrage. Man muss nicht 10 Semester BWL studiert haben um zu berechnen, ob man lieber 15k Platten nimmt oder entsprechend mehr 10k Platten. Irgendwann gibt es einen Break Even. Da muss man beim Design dann etwas spielen und rechnen. So können, je nach Preisen, 30x 300 GB 15k günstiger sein, als 20x 450 GB SAS 15k. Bei den 300 GB platten habe ich 50% mehr IOPS im Vergleich zu den 450er Platten.

 

Wenn wir über Virtualisierung reden, dann reden wir über brutalen random IO. Blockbasierter Speicher hat meist eh keine gute Cache Hit Rate, aber bei random IO bzw. Virtualisierung wird es noch schlimmer. Die IO Größe gibt der Gast bzw. die Anwendung vor. Insofern ist es gut, wenn dir dein Speichersystem die durchschnittliche IO Größe ausspuckt. Dann hast du zumindest einen Anhaltspunkt. Natürlich kannst du auch im Gast messen, geht auch.

[StefanWe 14]

Das was du mit der Virtualisierung schreibst, sehe ich auch bei vielen Kunden bzw. von Kollegen. Jemand meint, ab 9 Platten in einem RAID bekommt er nicht mehr Performance, sondern das RAID wird wieder langsamer.

 

Bei einem derzeitigen Kundenprojekt haben wir das Problem, dass RAM und CPU massenweise vorhanden sind, aber eben das Storage langsam ist. Glücklicherweise waren wir nicht der Dienstleister, der dieses Projekt begonnen hat.

 

Pie mal Daumen, 25% beim Schreiben bei RAID 5 ist ne Aussage. Beim Lesen müsste es aber deutlich mehr sein, Pie mal Daumen wie viel?

 

Würdest du denn die virtuellen Maschinen eher auf ein großes RAID mit vielen Disks legen, oder würdest du eher die Maschinen auf viele kleine Raids aufteilen?

 

Ich persönlich würde jetzt eher ein großes RAID machen. Allein weil ich dadurch weniger Overhead an Speicherverlust habe.

[bla!zilla 10]

Lesen geht bei RAID 5 wegen dem Striping natürlich fixer. Kannst du dir ja selber ausrechnen. Du hast in jedem Stripe einen Chunk mit Parity.

 

Große RAID Sets haben den Vorteil des geringen Verschnitts. Haben aber den Nachteil der Ausfallwahrscheinlichkeit. Auf jeden Fall sollte man nicht mehrere logische Laufwerke in einem Array erstellen, da sich dieser IO gegenseitig beeinflussen kann. Bei RAID 5 und SAS Platten finde ich Sets zwischen 6 und 9 Platten für okay. Hängt aber auch vom Speichersystem, der Plattengröße und dem RAID Level ab. Große Arrays resultieren halt in großen logischen Laufwerken und dann riesen Datastores. Ist auch doof...

[maxyl 10]

Hi liebe Boardmitglieder!

 

Ich bin neu hier in dem Forum und und hoffe, sehr das Ihr mir helfen könnt.

 

Was habe ich --> ESX4.1 Cluster in einem HP C3000 Shelf bestehend aus 4 BL460G1+G7 via FC an einer HP EVA4400 mit 3x12 400GB 10k SAS platten.

 

Das System hat immer gut funktioniert, doch seit einigen Tagen habe ich auf unserem Fileserver massive IOPS auf unser SAN. Ist nix anderes als ein gewöhnlicher Share, aber die "SAN-Auslastung" ist seit einigen Tagen erschreckend hoch.

 

Die Files liegen auf einem RawDevice mit 2TB Kapazität und seit einigen Tagen habe ich eine prozentuelle IdleTime sub 10% oft auch wirklich weit unter 5% im Mittel... (gemessen via PRTG)

 

Ich wollte wissen, ob es eine Möglichkeit gibt den "Verursacher" herauszufinden? Am System hat sich eigentlich nichts geändert :-(

 

ich bin für jegliche Info dankbar.

 

Viele Grüße,

Markus

[bla!zilla 10]

Hallo Markus,

 

du solltest eine Sache beherzigen: Ein Thema, ein Thread. Eröffne einfach einen neuen Thread. Speziell zu deinem Thema kann ich dir möglicherweise noch zwei Boards empfehlen: forum.san-ware.de und vmware-forum.de

 

Ansonsten eröffne hier einen neuen Thread.