5x SanDisk Ultra II 960 GB - Schreibperformance nicht identisch

  • Ersteller Ersteller DunklerRabe
  • Erstellt am Erstellt am
DunklerRabe schrieb:
@xexex: Im Zweifelsfall hätte ich das getan, wobei mir das ggf. halt auch nichts gebracht hätte. Wenn das ein obskurer Fall von "die SSDs performen halt an einem Raidcontroller nicht" gewesen wäre, was eigentlich nicht sein kann oder sollte, dann taugen die SSDs nichts und ich kann sie nicht gebrauchen. Dafür gibt es ja Standards wie SAS bzw SATA, der SSD hat es egal zu sein welcher Controller an dem Port hängt.

Haha!

Ich empfehle einem immer mal sich die Release Notes für die Firmware Updates von LSI Controllern durchzulesen. Da erfährt man wieviel Standard in dem Standard steckt und wieviel man doch nachträglich noch in der Firmware, Software oder en Treibern ausbügeln muss.

Es sind eben keine SAS SSDs sondern billigste SATA SSDs für den Consumer Markt. Da hätte die Geschichte auch anders ausgehen können. Ich kann auf jeden Fall grundsätzlich für deinen Einsatzfall die Intel SSDs empfehlen, alles andere kann, muss aber nicht.
http://www.intel.de/content/www/de/de/solid-state-drives/data-center-family.html
Sowas kostet kaum mehr als deine Billiglösung und ist heutzutage von den meisten Raidcontroller- und Storageherstellern zertifiziert.
http://geizhals.de/intel-ssd-dc-s3510-800gb-ssdsc2bb800g601-a1266329.html


Freut mich aber trotzdem das du eine Lösung gefunden zu hast.
 
Zuletzt bearbeitet:
@Faust2011: Einzeln sah es jetzt ganz gut aus, als Array ist die Schreibperformance aber immer noch schlecht. Die Theorie, dass es am Schreibcache lag, hat sich also nicht bewahrheitet.

@xexex: Ich weiß was du meinst, stimmt schon. Aber was du als "kostet kaum mehr" beschreibst kostet fast das doppelte für weniger Storage. Für den Use Case hier eigentlich nicht akzeptabel.

Ich stell noch mal neue Performancemessungen zusammen und poste die gleich...

Writecache enabled:
raid5_writecache_enabled.png

Zusätzlich Writeback enabled, was man ja eher nicht machen würde:
writeback_enabled.png

Das hab ich so noch nie gesehen bisher bei SSDs. Das ist eher das Verhalten wie man es bei HDDs findet. Ich hab die Testgrößen für den zweiten Test erhöht, damit die Daten nicht komplett in den Cache des Controllers passen.
Bei einem echten Copy Job von einem anderen System aus kommen wir immerhin noch auf ca. 350 MB/s über 100 GB Daten.

Update: Ca. 370 MB/s im Schnitt über 221 Dateien und 155 GB
 
Zuletzt bearbeitet:
Hallo32 schrieb:
Alles was nicht den Standard folgt geht als fehlerhaft zurück.

Eine für den Consumer Markt hergestellte Platte braucht nicht an einem Raid Controller 100% zu funktionieren. Genauso wenig wie ein Ferrari keinen Anhänger ziehen braucht. Beschwere dich nicht beim Hersteller wenn es nicht funktioniert, obwohl es doch 4 Räder und einen Motor hat.

DunklerRabe schrieb:
@xexex: Ich weiß was du meinst, stimmt schon. Aber was du als "kostet kaum mehr" beschreibst kostet fast das doppelte für weniger Storage. Für den Use Case hier eigentlich nicht akzeptabel.

Verstehe mich nicht falsch. Mein erstes SSD Raidverbund bestand aus 16 OCZ Platten und die haben in einem vielgenutzten SQL Server über 5 Jahre problemlos ihren Dienst getan.

Dazwischen gab es aber auch schon versuche die von "geht gar nicht" über "geht ne zeit lang gut" bis "läuft" alles beinhaltet haben. Kritisch ist hierbei die zweite Variante. Geht ne Zeit lang gut bei einem Raid5 ist katastrophal. Wenn sich sie Platten wegen einem Protokollfehler sporadisch abhängen und das bei einem Rebuild passiert hast du definitiv am falschen Ende gespart.

Da reicht schon eine Stunde Ausfall und alle "Ersparnisse" sind auf einem Schlag weg. Deshalb meine Devise seit Jahren - spare nie am Storage oder Netzwerk! :)
 
Auf den SanDisk SSDs soll ein Backup liegen, das ist unkritisch wenn da was auseinanderfliegt. Das hab ich bewusst in Kauf genommen, zuletzt war das ein HDD Raid 0 wo sich eine Platte jetzt aber verabschiedet hat.
Deswegen ist aber die Schreibperformance relevant für mich, weil da hin und wieder halt Daten rüber geschaufelt werden und ich da nicht ewig drauf warten will. Ob die jemals nochmal alle zusammen wieder gelesen werden müssen ist fraglich, eigentlich greife ich da nur einzeln drauf zu und da ist die Leseperformance nicht so relevant.

Wenn das so weiter geht mach ich erstmal wieder ein Raid 0 aus den SSDs. Spielt keine Rolle wenn das über den Jordan geht, wenn die Performance stimmt ist das Backup schnell wiederhergestellt.

Ich hab das Raid 5 noch mal aufgelöst und die Platten noch mal einzeln getestet, jetzt wo der Schreibcache definitiv aktiviert ist:
singledrive_writecache_enabled.png

Immerhin sind sie jetzt gleich schnell, nur die letzte fällt jetzt sequentiell aus dem Rahmen. Das die Performance jeder einzelnen SSD nicht so gut ist wie sie kein könnte nehme ich in Kauf, das wird vermutlich durch den Raidcontroller kommen.
 
Zuletzt bearbeitet:
Raidcontroller tun sich bis heute teilweise schwer mit SSDs. Wir verbauen in der Firma in letzter Zeit häufig reine SSD Konfigurationen, deshalb hatte ich auch schon diverse Erfahrungen sammeln können. Ich würde auf jeden Fall auch den Schreibcache anlassen, auch wenn er bei SSDs in der Theorie nicht viel bringen sollte. Bzw. in deinem Fall zu einem Controller mit Cache greifen. Optimal für SSDs ist zum Beispiel der 9271-8i. Bei LSI muss du auf jeden Fall auch bei den Optionen den Cache auch auf IMMER auch wenn keine BBU vorhanden stellen, sonst läuft er in "WriteThru" Modus.

Die frühere Fastpath Option für SSD Raids hat LSI bereits in diverse Controller fest eingebaut, allerdings gilt das nur für die höherwertigen Varianten der LSI Controller!
http://www.avagotech.com/products/s...ntrollers/megaraid-fastpath-software#overview
https://www.thomas-krenn.com/de/wiki/MegaRAID_FastPath

Die LSI Controller haben zwar ein grausames Bios und einige Einstellungen lassen sich nur dort (oder über noch grausamere Komandozeilentools) konfigurieren, aber im Betrieb sind sie definitiv stabiler als die Adaptec Geräte und werden von sämtlichen Herstellern direkt unterstützt (von Intel mit den Drive Tools bis VMware), wobei ich den letzten Adaptec Controller auch schon paar Jahre her das letzte mal gesehen habe.

Leider ist Intel, genauso wie 3Ware schon vor langer Zeit aufgekauft worden und andere ernsthafte Alternativen gibt es nicht mehr.
 
Zuletzt bearbeitet:
Der Adaptec 71605 hat ja einen Cache und wie man an den Ergebnissen sieht hat der noch erstaunlich viel Auswirkungen auf die Performance des SSD Arrays, was eigentlich nicht sein sollte. In dem anderen System mit dem LSI 9341-8i ist die Performance auch ohne Cache in Ordnung. Den Controller halte ich, insbesondere auch aus P/L Sicht, für ideal für ein SSD Array, weil man den Cache ja sowieso nicht brauchen sollte. FastPath hat der bereits ab Werk, obwohl es ein Entry Level Modell ist.

Von der Stabilität und Performance her bin ich bis heute eigentlich sowohl mit Adaptec als auch LSI immer gut gefahren. Dass du schon länger keinen Adaptec Controller mehr in der Hand hattest merkt man, denn die "altbekannten" Probleme gibt es nicht mehr. Ich würde LSI noch immer die besseren Controller bescheinigen, allerdings ist der Vorsprung nicht mehr groß. LSI hat noch leichte Vorteile was die Performance angeht und ich finde den MegaRaid Storage Manager besser als Adaptecs maxView Storage Manager, aber im Grunde bin ich mit beiden Firmen zufrieden. Adaptec hat im Moment den Vorteil, dass sie RoCs mit mehr als 8 nativen Ports anbieten, das ist der Grund warum ich den 71605 damals gekauft habe anstatt ein weiteres LSI Modell ins Haus zu holen. Zwischenzeitlich hatte ich aus dem Grund auch noch einen 72405, der war ebenso gut.

Aber das driftet vom eigentlichen Thema ab. Ja, ich könnte LSI Controller kaufen und den 71605 ersetzen, vielleicht macht es das besser. Noch lieber hätte ich aber, dass es auch mit dem 71605 ordentlich tut. Es kann ja nicht sein, dass das Raid 5 aus fünf SSDs nicht mal die Schreibperformance einer einzelnen erreicht.

Ich denke ich werde mal SanDisk befragen warum eine SSD langsamer ist als die anderen vier und Adaptec warum das SSD Array so miese Schreibperformance liefert.
 
DunklerRabe schrieb:
Ich denke ich werde mal SanDisk befragen warum eine SSD langsamer ist als die anderen vier und Adaptec warum das SSD Array so miese Schreibperformance liefert.

Der Ansatz klingt gut. ;)

Edit:
Sinnvoll kann es auch sein, wenn du beide Mails in einer zusammenfasst und diese an beiden sendest und somit sofort auch die andere Seite informierst, dass du bei beiden Seiten anfragst.
 
Zuletzt bearbeitet:
Ich hab das jetzt über deren Kontaktformular gemacht, aber ggf. werde ich die beiden Supporter dann mal untereinander kurzschließen.

Als Raid 0 bescheinigt CDM dem Array übrigens sequentielle 1226 MB/s Schreibleistung was in Anbetracht der Einzelleistungen relativ realistisch zu sein scheint. Es ist nur das Raid 5 was hier offenbar Probleme macht. Da würde ich mindestens was um die 400 MB/s erwarten eigentlich.
 
Zuletzt bearbeitet:
DunklerRabe schrieb:
Auf den SanDisk SSDs soll ein Backup liegen
...
Deswegen ist aber die Schreibperformance relevant für mich, weil da hin und wieder halt Daten rüber geschaufelt werden und ich da nicht ewig drauf warten will.
Dafür sind das aber nun wirklich denkbar ungeeignete SSD, die sind für leseintensive Anwendungen, wie alle SSDs mit TLC NANDs, erst recht planaren TLC NANDs. Außerdem hat die Ultra II noch einen alten Marvell Controller der kein LPDC unterstützt, aber diese Fehlerkorrektur ist bei TLC wichtig, damit die Daten auch noch gelesen werden können, wenn sie dort länger liegen und schon etwas Ladung verloren gegangen ist.
 
Ja ich weiß, der Preis war da der treibende Faktor. Das ist aber schon in Ordnung so, mein Use Case verträgt das. Ist vermutlich auch nur eine Übergangslösung. Wäre trotzdem schön, wenn die Übergangslösung einigermaßen performen würde :)
 
Ja Hauptsache billig, aber dann über Probleme wundern, wenn die Dinge nicht so toll laufen wie gedacht. Ist doch immer wieder komisch, die Leute kaufen die billigste Consumer HW um die dann für Enterprise Anwendungen zu nutzen, gibt es dann Probleme taugt die Consumer HW eben nichts. Klar taugt die nicht für Enterpriseanwendungen, einen Autoreifen kann man auch nicht auf einen Kieslaster ziehen, der passt zum Glück nicht, aber der würde die Last auch nicht tragen können.
 
Niemand spricht von Enterprise Anwendungen, nicht mal im Ansatz. Und der Grund warum da ein Raidcontroller hinter hängt ist auch nur der Wunsch, aber nicht die zwingende Notwendigkeit, von bzw. nach Redundanz und einem großen logischen Laufwerk, was man notfalls auch noch anders hinkriegen würde.
Ich kopiere da ein Backup drauf, davon wird dann immer mal wieder gelesen und irgendwann kopiere ich ein neues Backup rüber und es geht von vorne los. Das ist nun wirklich nichts zu anspruchsvolles und garantiert kein Workload, der irgendwelche Enterprise Niveus erreicht.

Die Probleme, über die ich mich hier wundere, haben ja nun nichts damit zu tun, dass ich die SSDs mit meinem Workload überfordern würde. Ich kann ja im Moment noch nicht mal sagen ob es überhaupt an den SSDs liegt.
 
Zuletzt bearbeitet:
So ein SAS RAID Controller ist Enterprise-HW, der richtet sich nicht mehr an normale Heimanwender und damit bist Du bei einer Enterprise Anwendung, auch wenn das Teil bei Dir im Keller steht und nur einmal im Monat ein Backup gemacht wird. Heimanwender-HW sind die normalen SATA Ports und einfach SATA Host Controllerkarten, aber keine SAS RAID Controller.

Außerdem: Ein Backup von dem immer wieder gelesen wird, scheint mir nicht wirklich ein Backup sein, sondern klingt sehr nach einer Datenauslagerung bzw. wenigstens danach, dass die andere Kopie der Daten das Backup ist.
 
Ok, wenn es du an dem SAS Controller fest machst, dann hast du natürlich Recht. Ich ging nach dem Workload, der nun wirklich nichts besonderes ist.

Es handelt sich um ein Backup von Daten, die auf diesem zweiten System landen. Das zweite System benutzt die Daten lesend weiter und hin und wieder aktualisiere ich den Datenbestand zwischen den beiden Systemen wieder. Und ja, das ist Absicht anstatt einfach shared Storage für beide Systeme zu haben. Hatte ich früher mal, hab ich aus diversen Gründen aber abgerissen und bin wieder auf lokalen Storage gewechselt. Zukünftig wird es von einem Teil dieser Daten auch noch eine dritte Kopie geben, deswegen ist das alles vermutlich temporär. Die SanDisk SSDs sollen dann der Storage für diese dritte Kopie sein, bis es soweit ist nutze ich die aber eben für die zweite Kopie.

Und falls das mit dem Raid 5 nicht performt und das Problem nicht zu lösen ist, dann werde ich da eben eine andere Lösung für finden.
 
DunklerRabe schrieb:
Fünf neue SanDisk Ultra II 960 GB eingebaut, angeschlossen an einem Adaptec 71605 (Firmware und Treiber aktuell von 06/2015) und als Raid 5 konfiguriert.

Funktioniert TRIM?

RAID hat es ja so an sich bei der Initialisierung erstmal (eine oder zwei) Platten komplett zu überschreiben (mit den Daten der anderen Platten) damit das eben alles in Sync ist. Ditto wenn eine Platte aus dem RAID fliegt und wieder zugefügt wird.

Für eine SSD bedeutet das dann aber daß sie "voll" ist und (von der int. Reserve mal abgesehen) für jeden weiteren Schreibzugriff erstmal was gelöscht werden muss was bei SSD lange dauert und dann die Schreibgeschwindigkeit drückt.

Daher muss man so ein Array dann erstmal wieder (mit blkdiscard, fstrim oder was immer) komplett freischnitzeln um wieder auf normale Werte zu kommen. Bei Linux Software-RAID/mdadm würde man sich den ersten Sync komplett sparen (blkdiscard auf alles und dann mdadm --create --assume-clean)
 
Kein Trim:
http://ask.adaptec.com/app/answers/...-command-support-and-adaptec-raid-controllers
SSD TRIM command support and Adaptec RAID controllers
Most Adaptec RAID controllers do not present physical devices (i.e. drives) to the operating system, only logical devices (i.e. RAID arrays, simple volumes, or JBODs). The TRIM command requires direct access to the physical SSD device, and this is not possible when connected to an Adaptec RAID controller in RAID mode.

Ich wüsste daher auch nicht wie ich das noch erzwingen könnte, ich habe ja keinen Zugriff mehr auf die physikalischen Devices.
 
@DunklerRabe: Ohne mich da jetzt zuweit einmischen zu wollen, aber du solltest deine Backup-Strategie nochmal grundlegend überdenken.
1. Von Raid0 ist immer abzuraten. Ein Backup muss auch halbwegs ausfallsicher sein, beim zurückspielen im Fehlerfall. Raid5 ok, aber Raid0 hängt die ganze Sache am seidenen Faden
2. Natürlich kann man auch im Privatbereich teure Controller einsetzen. Immer noch besser als Software-RAID. Kann das Holt nicht komplett zustimmen. Außer natürlich bei der Wahl der Speichermedien.
3. Wir haben doch durch Locky und die anderen Verschlüsselungstrojaner eindrucksvoll wieder vorgeführt bekommen, warum man ein Backup vom Produktivsystem physikalisch trennen muss. So wars schon immer und wird sich auch nie ändern. Drum ist eine Bandsicherung auch immer besser als eine USB-Platte die am Rechner hängt (wobei bei letzterem ja auch noch die Gefahr eines Stromschadens dazukommt und die Sicherung mitreissen kann). Wenn schon keine Bandsicherung, dann zumindest eine die abseits vom Backup-Prozess keine Verbindung zum restlichen System hat, seis durch Strom oder Netzwerkverbindungen. (USB zumindest Kabel ab)

So, das waren nur meine paar langen Worte dazu. Kannst du ignorieren oder dir zu Herzen nehmen, das entscheidest du ;)
Ich halte dein System als Backuplösung, selbst im Privatbereich, so wie du es aktuell beschrieben hast, für nicht durchdacht und ungeeignet, da zuviele potentielle Schwachstellen vorhanden sind
 
DunklerRabe schrieb:
wüsste daher auch nicht wie ich das noch erzwingen könnte, ich habe ja keinen Zugriff mehr auf die physikalischen Devices.
Das kannst Du nicht und bei einem RAID 5 kann TRIM auch nicht gehen, denn einmal reagieren die SSD verzögert und dann müsste nach dem ausführen von TRIM die Parity wieder korrigiert werden, die bezieht sich ja sonst noch auf die Daten, aber nach dem Ausführen von TRIM würde was anderes, meist 00, ausgelesen werden und damit würde die Parity nicht zu den Daten passen, die ausgelesen werden. Man müsste den ganze Stripe trimmen und das zu verwalten wären dann schon recht aufwendig und bei Enterprise Storage auch unnötig, da wird ja fast nie was gelöscht, sondern praktisch immer nur überschrieben, wobei TRIM unnötig wäre. Durch das Überschreiben erfährt der Controller ja auch so, dass die alten Daten die unter der Adresse abgelegt werden, nun ungültig sind und gelöscht werden können.

rg88 schrieb:
2. Natürlich kann man auch im Privatbereich teure Controller einsetzen. Immer noch besser als Software-RAID. Kann das Holt nicht komplett zustimmen.
Klar kann man, aber dann nutzt man eben Enterprise-HW und nicht mehr nur Consumer-HW. Das macht einen gewaltigen Unterschied, zumal die SSDs dann eben an genau dieser Enterprise HW hängen und die Hersteller können und werden nicht jede SATA SSD an jedem SAS HBA/RAID Controller ausprobieren können, gerade die billigen nicht.
 
@Holt:
das versteh ich schon. Ich würde jetzt, wenn ich das im privaten Sektor einsetzen wollen würde aber sicherlich auch eine hochwertige Controllerkarte kaufen.
Nur würd ich eh keine Adaptech nehmen, sondern eine LSI und diese dann erst mal in der Firma testen ob sie bei meinem Plan passt. Aber diese Möglichkeiten hat nun mal leider nicht jeder.
Gut davon abgesehen: Ich würde mir bei 500 Euro für die Karte auch sicherlich nicht die billigsten Consumer-SSDs kaufen :D Von daher sind wir da eigentlich schon wieder auf einer Meinung.

Trotzdem ist ein echter RAID-Controller eine bessere Lösung als der integrierte Schrott. Sinnvoll bestücken sollte man ihn dann natürlich, das ist auch klar. Aber mit der richtigen Kombi kann man durchaus Enterprise-Hardware mit Consumer-Produkten mischen im privaten Bereich. Irgendwo ist ja auch mal eine Budgetgrenze vorhanden, die sich nicht wie im Businessbereich mit Argumenten wegdiskutieren lässt. RAID ist bei mir eine Sache dich ich nur als 1 oder bestenfalls 10 einsetze im privaten Bereich. RAID 5 nur mit Controllern die das auch sauber hinbringen und RAID 0 -> never
 
Zurück
Oben