IO Leistung am RAID-Controller skaliert nicht mit mehr Festplatten

[Poison Nuke]

Hio,

eigenartiges Problem.

Supermicro X8 Plattform mit 56er Xeons.

Festplatten:
8x Seagate Cheetah 15k.7 300GB
8x Intel 320er SSD 160GB

RAID Controller:
3ware 9690SA-8i
3ware 9750-8i

jeweils mit voll geladener BBU. Write cache aktiv, read cache auf intelligent, policy ist auf balance gestellt.

Debian Squeeze mit fio, welches das Intel iometer fileserver benchmark pattern verwendet.


so, nehm ich z.B. 3x Cheetahs im RAID5, dann erreiche ich ca. 800 IOPS read, durchaus normaler Wert für 3 15k HDDs.
Jetzt denke ich mir, wenn ich das ganze auf 8 HDDs erweitere, dann müssten es ja deutlich mehr IOPS sein, wenigstens mal das doppelte. Nur es wird nicht mehr als 1000IOPS oder so. Bereits mit 4 HDDs im RAID5 ist der Wert erreicht und steigt dann nicht mehr an. Selbst wenn man 4 oder mehr in ein RAID0 packt wird es nicht schneller.


am Controller kann es aber scheinbar nicht liegen, schließ ich 3 SSDs im RAID5 an, dann liegen wir schonmal bei satten 9000 IOPS. Aber auch hier ist dann Schluss. Auch mit 8 Intel SSDs im RAID0 werden es nicht mehr.

Erst wenn ich zwei RAID COntroller parallel schalte und diese im OS als RAID0 zusammenschalte erreicht man annährend eine Verdoppelung der IOPS.



Was ist hier los
habt ihr eine Idee wo es hier hängt? Oder was man versuchen könnte?

 

[Poison Nuke]

was interessant ist, wenn man ein richtiges SAN nutzt (Dell Equalogic z.B.), dann skaliert das ziemlich gut mit den Festplatten.

Ein SAN mit 16x 300GB SAS im RAID5, angebunden über iSCSI, schafft satte 4800IOPS beim dem gleichen Test. Ausgehend davon müssten die 8 Festplatten am internen RAID Controller ja mindestens 2000IOPS schaffen, es sind aber bestenfalls 1000.


da grundsätzlich vom Grundansatz ein SAN ja auch erstmal nichts anderes ist wie ein dicker RAID Controller der statt direkt am PCIe Bus zu hängen erstmal noch ein iSCSI Netzwerk dazwischen hat, gehe ich mal davon aus, dass hat doch irgendwas mit dem RAID Controller zu tun.

Was kann der RAID Controller im SAN-chassis besser als der interne PCIe Controller?

 

[Backbone]

Reale IO Performance zu messen ist alles andere als trivial, theoretische Benchmarks sind da nicht verkehrt, aber haben oft nur begrenzte Aussagekraft für die Anwendungen.

Was kann der RAID Controller im SAN-chassis besser als der interne PCIe Controller?

Ich bin jetzt mal ganz naiv: Dein Controller kostet keine 400€ ... Wenn die Dinger in den SANs nicht deutlich performanter wären, würden die sich wohl eher schlecht verkaufen ...

Backbone

PS: Heute habe meine Techniker ne kleine EVA mit 48 FC-Platten zur Auslieferung zu recht gemacht. Auch wenn es deutlich fixeres gibt, die Dinger sind schon beeindruckend.

 

[Poison Nuke]

grundsätzlich spiegelt der iometer bench aber recht gut die Workload wieder, welche auch in der Praxis wo die Systeme gebraucht werden, auftreten. Und auch wenn die IOPS dann für die Praxis nicht ganz zutreffen, das Hauptproblem ist ja gerade die Skalierbarkeit.

Die Frage ist: wenn der RAID COntroller mit SSDs 10.000 IOPS schafft, warum werden es mit SAS 15k drives nicht mehr als 1000 IOPS, obwohl die Festplatten in anderer Umgebung auf über 2000 IOPs skalieren?


und gibt es überhaupt bessere interne RAID Controller? Soweit ich das sehe ist man mit den LSI MegaRAID 9280 oder den baugleichen 3ware 9750 ja schon an dem maximal möglichen oder gibt es eine Firma neben Areca, Adaptec, Highpoint und LSI, die ich bisher übersehen habe welche bessere Controller herstellt?

 

[dv2130n]

schon eine spannende Frage, wie sich mit 3 15K platten 800 IOPS lesend im raid-5 erreichen lassen
eine einzelne 15k platte mit einer average seek time beim lesen von 3,4ms (wie die cheetah 15k.7) erreicht beim Lesen eine durchschnittliche random IO Latenz von 5,4ms
das führt zu 185 IOPS bei dieser Platte
da lesenderweise im raid-5 keine raid-Kalkulationen (ausser der block redirection wegen striping) zu berechnen sind und alle drei Platten benutzt werden, sollte das raid-5 aus 3 dieser Platten 555 IOPS liefern;
und ein raid-5 aus 8 dieser Platten 1480 IOPS
waraum du hier nur 1000 erreichst, keine Ahnung, falsche Controllereinstellungen?

ach ja, und diese iops können natürlich auch nur erreicht werden, soweit jeweils alle platten im raid auch tatsächlich angesprochen werden

 

[Poison Nuke]

interessant... ich habe eben mal den Test gemacht und eine Cheetah als Single Drive exportiert, unter Deaktivierung sämtlicher Caches. Damit sollte man ja die Roh-Leistung der Festplatten sehen.

deutlichst mehr als erwartet, hier kamen satte 500 IOPS raus. Da der Benchmark selbst auch den Cache vom OS umgeht, sollte hier in der Theorie nichts mehr dazwischen sein, zudem die Testfile auch eine Größe von 4GB hat. Und da diese IO Leistung über 10min sehr konstant war (bei aktiviertem Cache hat man in den ersten Momenten eine signifikant höhere IO Leistung), gehe ich davon aus das hier kein Cache dazwischen gewesen sein kann.

---------- Beitrag hinzugefügt um 12:01 ---------- Vorheriger Beitrag war um 08:59 ----------

wow. wenn ich 8 Cheetah Festplatten als Single Drive exportiert und ohne Cache in einem Software RAID0 bündel, dann komm ich auf 4100 IOPS read und 1050 IOPS write.

Hier hat die Leistung also annährend linear skaliert. Und das sogar an einem alten SAS 3GBit RAID Controller (3ware 9690SA)



also steht eigentlich fest, irgendwas am RAID Controller limitiert. Nur ich hab eigentlich schon alle erdenklichen Einstellungen durch. Read cache an (basic oder intelligent) oder Read cache aus.
Write cache an oder aus, je mit BBU oder ohne
StorSave policy auf protect oder balance, Queuing aktiviert oder deaktiviert, stripsize alle größen probiert.

es gibt klareweise Unterschiede zwischen diesen Optionen, aber nicht sehr gravierend

 

[ara1]

ist das Raid denn auch schon vollständig initialisiert? Das kann schonmal n paar Stunden bis Tage dauern, und wenn es im Quick-Init läuft ist die Leistung reduziert.

 

[fdsonne]

Ich denke der interne Controller spricht die Platten nicht einzeln an...
Nur mal als Beispiel. Schreibst du bei ner Chunk Size von 64kB auf ein Raid 0 aus acht HDDs, so muss das File mindestens 512kB groß sein. Damit auch alle acht HDDs einen Teil abbekommen.
Da aber alle HDDs eben diesen einen Request abarbeiten, steigt die IO Leistung nicht.
Würdest du nun aber 64kB Files auf das Array schieben, so kann ich mir vorstellen, das günstigere Controller eben nicht die Platten einzeln ansprechen können.

Das heist, in deinem SAN Test könnte ich mir vorstellen, bei 64kB Files werden alle acht HDDs gleichzeitig betankt, die IO Leistung skalliert dementsprechend.
Beim internen Controller könnte hingegen ein Zugriff auf das Array quasi das Array "blockieren" und somit würden acht 64kB Blöcke jeweils sequenziel abgearbeitet und somit steigt die IO Leistung nicht.

Man müsste also herrausfinden, wie der Controller intern die HDDs ansprechen kann...
Skalliert die IO Leistung nicht bei größer vier HDDs (so wie es im Startpost steht) gehe ich davon aus, das der Controller eben nicht so viele gleichzeitige HDD Zugriffe auf ein und das selbe Array zulässt...

Ein anderer/besserer Controller könnte hier Abhilfe schaffen...

 

[Poison Nuke]

wobei ich jetzt komisch finde:
mach ich zwei RAID5 aus je 4 HDDs an einem Controller und fasse die im OS zu einem RAID0 zusammen, dann habe ich sagen wir mal 1/3 mehr Leistung. Nehm ich jetzt 2 4port Controller mit den gleichen Arrays, nur halt jeder Controller ein eigenes RAID5, und wieder beide als RAID0 im OS, dann verdoppelt sich die IO Leistung annährend. Also scheinbar hilft es auch nicht, wenn man viele kleine Arrays macht, welche man im OS dann zu einem großen RAID0 verbindet...zumindest nicht solange die kleinen Arrays an einem Controller hängen.


aber welcher Controller ist denn nun besser? Ich mein bei 400€ ist man doch bereits in der oberen Preisklasse für interne RAID Controller mit 8 Ports (mehr Ports gibt es normalerweise eh nicht, alle Controller mit mehr als 8 Ports haben einen Expanderchip, wäre mir neu das es RAID Controller mit mehr als 8 Ports ohne Expander gibt). Oder gibt es 8port Controller die wirklich deutlich leistungsfähiger sind?

und bei einem SAN ist der RAID Controller auch nicht wirklich teurer. Was kostet denn so ein Dell Equalogic z.B.. Der größte Teil geht da für die SAS-Backplane, die Powerbackplane, die Netzteile, das Gehäuse selbst und die Steuereinheit der Controller drauf. Für den eigentlichen XOR Chip bleibt da auch nicht viel übrig. Würde mich wundern wenn der wirklich mehr kostet wie ein interner Controller.

ist das Raid denn auch schon vollständig initialisiert? Das kann schonmal n paar Stunden bis Tage dauern, und wenn es im Quick-Init läuft ist die Leistung reduziert.

bei einem RAID0 gibt es kein Init und bei den RAID5 Tests hatte ich das Init entsprechend abgewartet.




edit
achja, bezüglich Parallelität noch etwas:
es werden ja mehrere Datenblöcke parallel gelesen. Da die meisten Zugriffe kleiner 8k sind, wird kein einziger einzelner Zugriff parallel verteilt werden können. Aber da ja viele Zugriffe parallel erfolgen und es unwahrscheinlich ist, dass alle angefragten Blöcke nur auf einer einzelnen Festplatte liegen, sollte der Controller ja die Lesezugriffe parallel abarbeiten können. Eventuell hängt es wohl hier, dass er zwar 64 Commands im Queue hat, diese aber trotzdem nur linear abarbeitet.

wäre eine erste Vermutung. Aber ob das bei einem RAID Controller, der immerhin von LSI für Enterprise-Umgebungen gedacht ist, wirklich der Fall ist ?

 

[fdsonne]

Neja ich sag mal so, interne Controller mit 8Ports sind für acht HDDs ausgelegt.
Schaust du dir Mittelklasse SAN Systeme von Dell und Co. an, gehen da schon mal idR 12x3,5" HDDs in ein Case, das ganze ist erweiterbar auf fünf und mehr Cases am gleichen Controller...

Der Controller selbst bzw. dessen Hardware muss schon eine ganze Ecke mehr Bumms besitzen als so ne 8Port internes Kärtchen.

Gehst du dann noch nen Schritt weiter auf noch größere Lösungen wo die HDDs ganze 40HE Schränke füllen, gehts leistungstechnisch noch weiter hoch.


In der Theorie ist die Sache ja ganz klar.
Der Controller muss in der Lage sein, bei gleichzeitigen Zugriffen diese auch gleichzeitig abzuarbeiten und dabei noch die Zugriffe auf mehrere HDDs zu verteilen. Kann er das nicht (oder gibts da ein Limit) skallierts irgendwann nicht mehr...
Wie sich die Controller hier verhalten müsste man mal genauer untersuchen... Beispielsweise eine Produktreihe in verschiedenen Ausführen (vier, acht, 12, 16 Port) durchtesten...


Die nächste Analyse wäre die eigentliche Datenablage auf der HDD selbst...
Denn hier können je nach Einstellung der Chunk Size, Stripe Size und der Clustergröße des Filesystems bzw. der Zuordnungsgröße der HDD Sektoren erhebliche unterschiede auftreten. Vor allem, wenn das Alignment nicht passt.

 

[Poison Nuke]

wieviele Ports ein Controller hat, und mit wievielen HDDs er umgehen kann, sind zwei absolut verschiedene Sachen.

Die SAN Controller haben intern auch meist nicht mehr als 8 Ports, die einfach nur erweitert werden.

Alle RAID Controller mit mehr als 8 Ports auf der Karte sind nichts weiter als ei 8port Controller, auf dem lediglich noch ein Expander aufgelötet ist.

Ob ich nun ein 24port RAID Controller nehme und 24 HDDs direkt anschließe oder ob ich einen 8port Controller nehme und ein Gehäuse mit Expanderbackplane ist im Endresultat IDENTISCH.


Die Controller von LSI (egal wieviele Ports physikalisch drauf sind) skalieren laut deren Aussage idealerweise mit bis zu 24HDDs. Bis zu 96HDDs sind an einem 4port Controller von LSI ebenfalls noch problemlos möglich aber da soll kaum noch eine Skalierung stattfinden.


Tja, sie tun es aber in der Praxis nicht. Nächste Woche soll hier der aktuell beste RAID Controller von LSI hier eintreffen (Der MegaRAID 9265-8i), der noch etwas neuer ist als der 3ware 9750-8i, welcher aber baugleich zum LSI 9260-8i ist.

Wenn ihr noch einen Tipp habt welcher interne RAID Controller noch besser ist, dann immer her damit.


PS: also ich kann dir locker einen einzelnen Server bauen, der mithilfe interner RAID Controller ein ganzes 40HE Rack gefüllt mit 441 Festplatten ansteuert. Für die paar HDDs brauch man noch kein SAN. Gut, wenn es um 2,5" HDDs geht wird es interessant, aber bekomm man auch noch hin, 864 2,5" HDDs in einem Rack als einzelner Server zu betreiben.
Rein von der IO Leistung des Mainboards und der CPU kommt man da gerade so noch mit, zumindest wenn man ein Dual-Boxboro Chipset hat.
Die RAID Controller dürften wohl das Problem darstellen... eben das worum es hier geht.

 

[fdsonne]

Das Problem ist, du gehst hier von theoretischen Werten aus. Obwohl dir dein Test was anderes vermittelt... Von mir aus kann ein 4 Port Controller 96 HDDs ansteuern. Aber was bringt mir das, wenn die Performance nicht skalliert. Und darum gehts doch...
Ebenso weist du nicht, ob in der SAN Lösung bessere Hardware verbaut ist (und das wird sie mit Sicherheit sein) als in so ner popligen 4-8 Port Raidcontroller Einheit...

 

[Poison Nuke]

gibt es ein Beispiel für einen RAID Controller der nicht "popelig" ist?
Warum gibt es Servergehäuse für 88 Festplatten und mehr, wenn es keinen RAID Controller auf der Welt gibt, mit denen man auch nur im Ansatz die Leistung dieser HDDs nutzen könnte? Das kann ich mir eigentlich auch nicht beim besten Willen vorstellen.

Wäre doch eigenartig, wenn ich immer gleich ein SAN hinstellen müsste nur wenn ich mehr als 2 Festplatten nutzen will.

 

[DarkDeveloper]

Wenn du iometer mit dem normalen Fileserver-Pattern benutzt, ist dein Problem wahrscheinlich nicht der Controller, sondern der Benchmark.
Im Fileserver-Pattern sind nur 80% der Requests Reads und davon sind 80% 4k oder kleiner. Je mehr Platten dein RAID5 umfasst, desto mehr wirken sich die Schreiboperationen aus, da im Extremfall, wenn keine Daten im Controller-Cache sind, erstmal von allen Platten ein Stripe gelesen werden muß bevor dann die Daten und Parity zurückgeschreiben werden können. Dein Raid5 verhält sich also beim Schreiben schlechter als eine einzelne Platte.
Die Skalierung wird besser, je mehr Daten des Working-Set im Controller-Cache sind. Das allein könnte z.B. schon das viel bessere Verhalten des SAN erklären.

 

[Poison Nuke]

d.h. das SAN ist nur deswegen besser, weil es mehr Daten im Cachen behalten kann?

und was ist mit den RAID0 tests, hier gibt es ja keine Parity die berechnet werden muss, theoretisch dürfte doch hier sogut wie nie ein Schreibzugriff mehr als eine Festplatte gleichzeitig beeinflussen oder?


edit:
merke jetzt erst ich hab außerversehen im home-server bereich gepostet. Hat damit ja definitiv nix mehr zu tun. Wäre bitte ein Mod so freundlich, das ganze in den Profi-Bereich zu schieben?

 

[DarkDeveloper]

Mit dem worst-case habe ich mal wieder an ZFS gedacht. Einfaches Parity-Raid müsse im worst-case 4 IOs pro Schreiboperation haben, da die neue Paritiy aus alten/neuen Daten + alter Parity berechnet werden kann. Von daher sollte es natürlich auch normal mit der Anzahl der Platten skalieren, wenn die Request zufällig verteilt sind.

Was für eine Queue Tiefe hast du für deine Tests benutzt und hast du auch mal die Tests mit mit unterschiedlicher Tiefe wiederholt?

 

[dv2130n]

ich denke es ist klar, dass IOPS ausschliesslich kurze zufällige schreib- oder lese-muster messen (und nicht sequentielle Datenzugriffe, die werden in Durchsatz gemessen, also MB/s)

dann, was die benchmarks, die du verwendest, da so treiben um zu solchen Werten zu kommen, das weiss ich nicht
aber du musst ja irgendeinen Grund haben, zu glauben, dass es sich bei den Werten im Anfangspost um reine Lese-Performance handelt, also eine rein lesende Anwendung, die der Bench simuliert
und für den Fall (@ DarkDeveloper) gibt es eben auch keine Paritätsberechnungen durch den Controller, sondern nur die block redirection wegen Striping über hier 3 oder 8 Platten

beim reinen Schreiben im raid-5 resultiert dagegen (grob oder annäherungsweise gesagt) jeder Zugriff des host in 4 IO, was bedeutet, dass die raid-5 performance beim reinen Schreiben von zufälligen Mustern nur noch ein Viertel seiner Leseperformance (bei zufälligen Mustern) beträgt
werden also mit 8 platten der oben angegebenen Spezifikation im Raid-5 beim reinen Lesen ausreichend zufälliger Muster 1480 IOPS erreicht, sinkt die raid-5 Performance dieses Arrays beim reinen Schreiben ausreichend zufälliger Muster auf ein Viertel, nämlich ca. 370 IOPS
werden gemischte zufällige Schreib-Lese-Operationen durch die Anwendung durchgeführt, errechnet sich die Gesamtperformance entsprechend dem Verhältnis der Schreib- und Lese-Operationen zueinander
diese Rechnungen berücksichtigen natürlich keinerlei Zwischenspeicher

bei grösseren arrays muss auch die queue Tiefe gross und zufällig genug sein, um alle Platten wirklich anzusprechen
Wenn das nicht der Fall ist, können auch keine höheren IO Werte resultieren. Denn mit IOPS wird ja gerade die (random access) Leistung der beteiligten Platten wiedergegeben, wenn diese Leistung aber (auch irgendwelchen Gründen wie mangelnde Queue Tiefe, mangelnde Zufälligkeit der Zugriffsoperationen) gar nicht angefordert wird, können die IOPS Werte auch nicht steigen

ausserdem hilft eventuell Folgendes weiter (und sei es auch nur beim Akzeptieren der Tatsachen), wenn die Performance niedriger als erwartet ausfällt;
in einem array verhält sich idealerweise die Leistung des arrays proportional zur Anzahl der beteiligten Platten
dies setzt aber voraus, dass der im raid stack verwendete algoritmus stets in der Lage ist, die Host Kommandos gleichmässig auf die beteiligten Platten zu verteilen; alle Methoden, dies zu erreichen, haben gewisse Nachteile und sind von Controller zu Controller verschieden,
und durch die Art und Weise wie der verwendete Algoritmus arbeitet, wird natürlich in jedem konkreten Fall auch entscheidend die Performance beeinflusst

 

[Backbone]

Warum gibt es Servergehäuse für 88 Festplatten und mehr, wenn es keinen RAID Controller auf der Welt gibt, mit denen man auch nur im Ansatz die Leistung dieser HDDs nutzen könnte? Das kann ich mir eigentlich auch nicht beim besten Willen vorstellen.

Ich sehe diese "Servergehäuse" eigentlich eher als Spielerei für Bastler. In großen, produktiven Umgebungen wird man sowas in aller Regel nicht finden. Und schaut man sich mal bei den großen Markenherstellern um haben die sowas auch eher selten...

Wäre doch eigenartig, wenn ich immer gleich ein SAN hinstellen müsste nur wenn ich mehr als 2 Festplatten nutzen will.

Es gibt sicher eine gewisse Grauzone, vor allem macht es oft eben doch Sinn KEIN San zu verwenden. Aber man muss einfach konstatieren, dass der gesamte Storage-Bereich jetzt seit mehr als 5 Jahren deutlich stärker wächst als das Serversegment für sich betrachtet.

Aber generell ist der reine Speicherplatz eigentlich eher selten der Grund, zu einem SAN zu greifen...

d.h. das SAN ist nur deswegen besser, weil es mehr Daten im Cachen behalten kann?

Allein der Blick auf die feature-Liste gängiger Systeme sollte die Frage beantworten.

Backbone

 

[Poison Nuke]

Ich sehe diese "Servergehäuse" eigentlich eher als Spielerei für Bastler. In großen, produktiven Umgebungen wird man sowas in aller Regel nicht finden. Und schaut man sich mal bei den großen Markenherstellern um haben die sowas auch eher selten...

Im Gegenteil, man findet sich ja immer öfter bei den Markenherstellern. Und die sind ja auch alles andere als billig. 2000 bis 3000€ für ein einfaches Gehäuse nur mit Netzteil und Backplane das ist sicher nix für einen Bastler, mit allem was noch dazu gehört liegen wir hier im gleichen Preisbereich wie die Komponenten in einem SAN. Die Hersteller werden sicher nicht aus Spaß mal eben Komponenten auf den markt werfen die ähnlich teuer wie RAID Chassis im SAN sind aber dann keinen Nutzen bringen. Für so blöd halte ich die Marketingabteilungen dann ja nun doch nicht.




trotzdem, kurz und bündig, die Frage an sich bleibt ja:
ein SoftwareRAID0 schafft es linear zu skalieren, ein SAN auch. Die getesteten RAID Controller (Adaptec 5805, 3ware 9690SA, 3ware9750 bisher) schaffen es nicht.
Wenn es daran liegen sollte, dass diese RAID Controller einfach nur billig sind, gibt es denn RAID Controller die es können, wenn ja, welche?