SSD RAID Layout

[Morpheus2200]

Ich bin persönlich seit ca. 10 Jahren eher Software orientierten Lösungen zugeneigt, daher fehlen mir Erfahrungen mit SSDs an RAID Controllern.
Jetzt bin ich aber mal in der Situation, dass ich einen NFS Server plane, der bevorzugt mit Hardware RAID ausgestattet werden soll.
Kapazität im mittleren zweistelligen TB Bereich, bevorzugt mit RAID 6 oder 60.

Der Server bekommt es mit mixed Workloads zu tun, sowohl viele iops aber auch hoher Durchsatz sind gefragt. Im schlimmsten Fall sogar beides zeitgleich. Wobei die high iop Situationen bisher relativ selten waren, kommen jedoch in Zukunft vermutlich öfter.
Als Netzwerk Interface ist FDR oder ERD Infiniband geplant. Vielleicht wird mal NFS over RDMA getestet, IP over IB wäre aber auch ok. OS wird Linux, Infiniband ist da weit verbreitet und relativ gut getestet.
Das klingt jetzt dramatischer als es ist, 56 oder 100 GBit über NFS erwartet niemand, es soll nur die vorhandene Netzwerkstruktur genutzt werden. Sequentiell sollten aber gerade lesend schon Datenraten erreicht werden, die deutlich über 1GBit/s liegen.

Aktuell verrichtet noch ein RAID mit HDDs, dass immer wieder an seine Grenzen kommt den Dienst. Gerade wenn zeitgleich gelesen und geschrieben wird kommt es zu kritischen Situationen.
Da jedoch auch die Rechenleistung und damit das aufkommen neuer Daten wächst reicht es nicht, vorhandenes etwas flotter zu machen, der Flaschenhals soll schon deutlich breiter werden.

Ich habe von vielen Leuten gelesen, die mit der Performance ihrer SSD RAID Setups nicht so glücklich waren.
Wo lauern die Fettnäpfchen?
Welche Controller sind zu empfehlen?
Wie verhält sich so ein SSD RAID bei 80%+ Füllstand?
Wie weit sind NVME RAID Controller?
An welcher Stelle kann man sparen und wo besser nicht?
Welche Performance kann man erwarten?
Welches Interface würdet ihr nehmen? SATA SAS oder NVME?
Was für ein RAID Layout würdet ihr wählen?

 

[konfetti]

Ist das noch Privat@home oder doch schon professionell und Beruflich? - gerade bei dem wechselnden Workload...

Ich würde in Richtung intelligentes Storage gehen, dem die Datenblöcke keinen Festen HDD/SSDs sondern Tiers zugeteilt sind, das ist denke ich am performantesten, zumindest wenn ich da jetzt mal ne 3PAR mit ner "stinknormalen" MSA vergleiche.

Für welches Anwendungsszenario ist es denn genau? - Als Storage für nen Virtualisierungshost, oder eher gleich als Fileserver für X Clients?

 

[Morpheus2200]

HPC Cluster, ist kein Privatvergnügen.
Normalerweise wird bei der Größe langsam ein paralleles Filesystem interessant. Aber hier lief es bisher mit HDD RAID 60 erstaunlicherweise noch relativ gut. Mit Rücksichtnahme der Anwender, man hat den Flaschenhals schon bemerkt.
Man scheut die (folge-) Kosten für eine kommerzielle Softwarelösung und möchte auch nicht viel Zeit versenken.
Ich habe meine Erfahrungen mit Software basierten Lösungen gemacht und halte die auch für die bessere Option, allerdings braucht man dafür auch Zeit und oder Geld. Manchmal scheitert es auch an der Infiniband Unterstützung bei Kommerziellen Produkten. Mir fällt da auch kein Produkt ein, dass nicht entweder einen zu großen Teil vom Budget auffrisst, oder eben Zeit für Einrichtung und Administration benötigt oder eben zu wenig getestet ist.
Ich will da auch nichts frickeln und mich später wundern, warum es unter Last nicht ordentlich funktioniert. Zum ausgiebig testen fehlt die Zeit und die Möglichkeit ein so großes System unter realen Bedingungen zu testen.
Die Idee das Storage einfach etwas flotter zu machen und sich erst in ein paar Jahren wieder mit dem Problem befassen zu müssen hat schon ihren Reiz. Und etwas flotter als das HDD RAID würde hier tatsächlich ausreichen.
An anderer Stelle sammle ich meine ersten Erfahrungen mit CEPH, es wäre natürlich schön, dass langfristig auch im HPC Umfeld einsetzen zu können. Aber ich hätte hier gern einen einfachen Ansatz der für die nächsten Jahre ausreicht und mir Zeit verschafft.

Ich habe in den letzten Jahren meine Erfahrungen mit ZFS, Netapps WAFL und PANFS gemacht. Erscheint mir mit kommerziellem Support hier aber übertrieben.
ZFS gäbe es ja noch ohne Vendor Lock, aber ich habe keine Ahnung wie gut ZFS on Linux mittlerweile ist und wie gut Infiniband auf den geeigneteren Betriebssystemen unterstützt ist.
Ein stumpfes RAID wäre hier wirklich die einfachste Lösung und auch wenn die Hardware Kosten nicht ganz ohne sind vermutlich auch die billigste.

 

[Stueckchen]

Ich würde hier von einem HW-Raid absehen, auser es wird benötigt. Bei einem HPC glaube ich das nicht.
Darf sowas auch mit administrieren, und da würde ich mal genau schauen was benötigt wird, also von der Software. Wenn schnelle I/O benötigt wird würde ich eher ein kleinen schnellen Scratch realiesieten.
Sonst ist ein Blick auf ZFS sicher nicht verkehrt. Da kann man wenn die Storage node passt für kleine Münze viel aus dem Plattenspeicher rausholen.
Ceph oder so wenn es sich um einen eher kleineren HPC handelt würde ich vermeiden, da hier dir Performance recht hohe Ansprüche hat, grade wenn es um I/O geht. Ein activ/backup setup ist einfacher.

 

[gea]

Prinzipiell sind Hardware-Raid überholt. Eine moderne CPU schlägt einen Raidcontroller deutlich und Mainboard-RAM hat man mehr und der ist schneller. Ich sehe eigentlich nur noch den Einsatzzweck "altes Dateisystem wie ext4 oder ntfs" und der Wunsch ein Raid Crashsicher zu machen mit BBU Absicherung. Hinzu kommt, dass Hardware-Raid kein Trim kann. Sehr gute Enterprise SSD brauchen das zwar nicht aber dennoch.

Mei Tipp
BroadCom 12G SAS Controller 9300 und ZFS Softwareraid. Für sicheres Schreiben kann man da Sync aktivieren (falls der Pool zu langsam ist). Ideal wären Dualpatz SAS SSDs WD Datacenter 530. Haben Powerloss Protection, bis 2 GB/s Transferraten (DualSAS) und über 300k write iops.

Wenn man langsamere SSD nimmt, sollte man für ein Produktivsystem auf jeden Fall auf Powerloss Protection achten. Wenn die SSD "langsam" sind, ein Slog nehmen (Intel Optane).

Mit neuestem ZFS kann man auch einen "mixed Pool" von langsamen und schnellen Vdevs nehmen. Man kann dann Metadate oder einzelne Dateisysteme auf den schnellen vdev (z.B. OPtane, WD SS530) legen, vgl http://napp-it.org/doc/downloads/special-vdev.pdf und den Rest auf langeame vdevs aus Platten oder langsameren SSD.

Das Feature ist wie ZFS Raid-Trim aber erst seit diesem Sommer in Open-ZFS. Für ein kritisches System würde ich noch ein paar Monate warten.

Da ZFS performancemäßig mit RAM als Schreib/Lesecache skaliert auf genügend RAM achten. Ein ZFS Pool besteht aus einem oder mehreren Raid-Arrays (vdevs) die wie bei 2 vdevs wie ein Raid-60 arbeiten. Man kann aber nicht nur zwei sondern beliebig viele vdevs addieren um die Kapazität und Performance zu steigern.

 

[Morpheus2200]

Ja, ZFS ist ein tolles Dateisystem und würde hier einige Stärken voll ausspielen.
Und ja Hardware RAID ist überholt. Ich habe die letzten 10 Jahre darauf verzichtet wo es nur ging.

Aber ich habe da mehrere kleine Probleme.

1. Problem: Beschafft wird so ein HPC Cluster inkl. Storage per Ausschreibung.
Wenn ich da nur ZFS Storage mit Kapazität >X reinschreibe kann mir auch jemand ein ZOL System mit SATA SSD am SAS Expander anbieten und ich kann dann später gucken warum das nicht ordentlich läuft nachdem die Kiste mal hängen geblieben ist.
Schreibe ich rein SSD X von hersteller Y an Broadcom SAS Controller wird die Ausschreibung nie rausgehen weil kein Hersteller bevorzugt werden darf.
Ich kann natürlich SAS only reinschreiben, aber was dann für Hardware? SAS HDDs? Die können auch mal langsam sein wenn die falschen Daten gefordert sind.
SAS SSDs? Was macht ZFS da noch deutlich besser als der Hardware RAID Controller?
Eine Option da was ordentliches zu bekommen ist es auf Systeme mit Software Support und HCLs zu bestehen und das wird gern mal teuer. Und dann kann es noch sein, dass da Infiniband nicht läuft oder die Nutzerauthentifizierung etwas unflexibel ist.

2. Problem: Ich habe momentan wenig Zeit.
Das wird sich langfristig hoffentlich ändern, aber da ich hier erst sei ein paar Monaten tätig bin und die Stelle längere Zeit unbesetzt war gibt es noch viele andere Baustellen.
Daher orientiere ich mich am bisherigen Nutzungsverhalten und wenn für die Aufgabe bisher ein suboptimal konfiguriertes RAID 60 meist gereicht hat hoffe ich die nächsten 3 Jahre mit etwas performanterer Hardware auszukommen.
Ich habe letztes Jahr zwei kleinere Cluster mit ZFS Storage in Betrieb genommen, bei beiden Systemen musste ich analysieren und optimieren bevor die ordentlich liefen.
Ich habe aktuell keine Zeit Anwendungsfälle zu analysieren. So sehr ich die Caches bei ZFS schätze, für Anwender ist es nicht nachvollziehbar warum die Analyse mal in Sekunden fertig ist und mal eine halbe Stunde dauert.

3. Problem: Mögliche Vertreter (bei Urlaub/Krankheit) kennen sich mit ZFS nicht aus. Die Platte oder SSD die rot leuchtet am RAID Controller tauschen bekommt mit telefonischer Unterstützung jeder hin.

Langfristig kann ich mir verschiedene Softwarebasierte Lösungen ansehen und wenn sie sich gut schlagen langsam einführen. Hätte ich mehr Zeit würde ich mich mit wieder CEPH beschäftigen.
Ich betreibe hier mehrere HPC Cluster an zwei Standorten, ein Cluster übergreifendes und performantes Dateisystem hat da schon seinen Reiz.
Um so etwas umzusetzen wären aber weitreichende Änderungen notwendig, das kann man nur langfristig angehen.

Ich habe hier noch ein kleines System mit lokalem RAID 6 8+2 SAMSUNG PM1643 an einem MegaRAID 9361-8i stehen, leider noch nicht im produktiv Einsatz. Aber die ersten Tests sehen so aus als wäre die Performance ausreichen könnte.
An etwas in der Art mit mehr Kapazität habe ich hier gedacht. Mehrere 100 MB/s sequentiell schreiben können ohne bei zeitgleichen Lesezugriffen gleich einzubrechen wäre ausreichend.

Würde ich meinem Basteltireb freien Lauf lassen würde ich ein CEPH oder ZFS System aus NVME SSDs mit Optane log/metadata Device bauen um zu gucken was da so geht.
Aber ich brauche keine ungetestete Bastellösung sondern etwas das unauffällig 3-5 Jahre seinen Dienst verrichtet.

 

[Luckysh0t]

Da du Ceph erwähnt hast, kannst du dir ja mal PetaSAN Free Scale-Out SAN Highly Available Platform anschauen. Stellt den Storage allerdings via iSCSI bereit.Nutzt mein ehemaliger Arbeitgeber als Storage Cluster für dass vSphere Cluster.

 

[gea]

Ja, ZFS ist ein tolles Dateisystem und würde hier einige Stärken voll ausspielen.
Und ja Hardware RAID ist überholt. Ich habe die letzten 10 Jahre darauf verzichtet wo es nur ging.

Aber ich habe da mehrere kleine Probleme.

1. Problem: Beschafft wird so ein HPC Cluster inkl. Storage per Ausschreibung.
Wenn ich da nur ZFS Storage mit Kapazität >X reinschreibe kann mir auch jemand ein ZOL System mit SATA SSD am SAS Expander anbieten und ich kann dann später gucken warum das nicht ordentlich läuft nachdem die Kiste mal hängen geblieben ist.
Schreibe ich rein SSD X von hersteller Y an Broadcom SAS Controller wird die Ausschreibung nie rausgehen weil kein Hersteller bevorzugt werden darf.
Ich kann natürlich SAS only reinschreiben, aber was dann für Hardware? SAS HDDs? Die können auch mal langsam sein wenn die falschen Daten gefordert sind.
SAS SSDs? Was macht ZFS da noch deutlich besser als der Hardware RAID Controller?
Eine Option da was ordentliches zu bekommen ist es auf Systeme mit Software Support und HCLs zu bestehen und das wird gern mal teuer. Und dann kann es noch sein, dass da Infiniband nicht läuft oder die Nutzerauthentifizierung etwas unflexibel ist.

2. Problem: Ich habe momentan wenig Zeit.
Das wird sich langfristig hoffentlich ändern, aber da ich hier erst sei ein paar Monaten tätig bin und die Stelle längere Zeit unbesetzt war gibt es noch viele andere Baustellen.
Daher orientiere ich mich am bisherigen Nutzungsverhalten und wenn für die Aufgabe bisher ein suboptimal konfiguriertes RAID 60 meist gereicht hat hoffe ich die nächsten 3 Jahre mit etwas performanterer Hardware auszukommen.
Ich habe letztes Jahr zwei kleinere Cluster mit ZFS Storage in Betrieb genommen, bei beiden Systemen musste ich analysieren und optimieren bevor die ordentlich liefen.
Ich habe aktuell keine Zeit Anwendungsfälle zu analysieren. So sehr ich die Caches bei ZFS schätze, für Anwender ist es nicht nachvollziehbar warum die Analyse mal in Sekunden fertig ist und mal eine halbe Stunde dauert.

3. Problem: Mögliche Vertreter (bei Urlaub/Krankheit) kennen sich mit ZFS nicht aus. Die Platte oder SSD die rot leuchtet am RAID Controller tauschen bekommt mit telefonischer Unterstützung jeder hin.

Langfristig kann ich mir verschiedene Softwarebasierte Lösungen ansehen und wenn sie sich gut schlagen langsam einführen. Hätte ich mehr Zeit würde ich mich mit wieder CEPH beschäftigen.
Ich betreibe hier mehrere HPC Cluster an zwei Standorten, ein Cluster übergreifendes und performantes Dateisystem hat da schon seinen Reiz.
Um so etwas umzusetzen wären aber weitreichende Änderungen notwendig, das kann man nur langfristig angehen.

Ich habe hier noch ein kleines System mit lokalem RAID 6 8+2 SAMSUNG PM1643 an einem MegaRAID 9361-8i stehen, leider noch nicht im produktiv Einsatz. Aber die ersten Tests sehen so aus als wäre die Performance ausreichen könnte.
An etwas in der Art mit mehr Kapazität habe ich hier gedacht. Mehrere 100 MB/s sequentiell schreiben können ohne bei zeitgleichen Lesezugriffen gleich einzubrechen wäre ausreichend.

Würde ich meinem Basteltireb freien Lauf lassen würde ich ein CEPH oder ZFS System aus NVME SSDs mit Optane log/metadata Device bauen um zu gucken was da so geht.
Aber ich brauche keine ungetestete Bastellösung sondern etwas das unauffällig 3-5 Jahre seinen Dienst verrichtet.

1.
Ich kenne das Problem.
Meine Kollegen nehmen daher meist NetApp per Rahmenvertrag. Das geht einfach zum bestellen.


Man kann aber auch Ausschreibungen durchaus etwas detaillierter fassen z.B.
8 Port Dualpath 12G SAS Controller mit IT Firmware für ZFS Software-Raid
Treiber-Support für Free-BSD, Linux und Solaris

Das ergibt in 100% der Fälle einen BroadCom 930x Controller oder einen OEM dazu

Schreiboptimierte Dualpath 12G und SAS SSD, min 3 dwpd und iops/4k > 300k iops
Das ergibt fast immer WD Datacenter SS530

Zum Cache Verhalten.
Man muss nicht alles perfekt richtig machen solange man nichts grundlegendes falsch macht.
ZFS Caches muss man eigentlich nicht optimieren. Ausreichend RAM bereitstellen und es ist gut.

Bei SSD liegen Performance Probleme meist beim dauerhaften Schreiben. Viele SSD brechen da übel ein, genauso wenn es um kleine io geht wie bei sync write. Die taugen einfach nicht dazu. Da muss man nichts optimieren. Es ist einfach so, Samsung EVO taugen nicht für einen Server, bessere Intel Datacenter oder Optane oder WD Datacenter SS530 spielen da in einer anderen Liga.

Datacenter SSD verhalten sich einfach besser auch ohne Trim oder bei dauerhaftem Schreiben. Auf jeden Fall auf PLP bestehen. Sonst nützt auch der BBU im Raidcontroller oder sync write bei ZFS nichts.

Ein Problem bei Raid ist fehlendes Trim, mit denen man langsame SSD in Zeiten geringer Belastung wieder etwas auf Trab bringen kann. Trim geht aber meist nicht im Raid. Aktuelles ZFS ist da eine Ausnahme. Die können auch Trim im Raid.

Spezielle Treiber und Features sind nicht ZFS spezifisch sondern liegen am OS oder Services. Das muss man separat sehen.


2. und 3.
Ein HPC Cluster oder selbst ein einfacher Filer ohne eigenes minimales Know-How ist ein Problem. Das geht nur mit ganz großen Anbietern und SLA zu entsprechenden Kosten. Eine Storage Appliance mit Webmagement ist aber ansonst auf jeden Fall Pflicht.

Last but not least
Keep it simple und das so wie es die anderen auch machen (spart viele Kopfschmerzen)

 

[Morpheus2200]

Ich habe bereits einen kleinen CEPH Cluster mit 3 Object Storage Nodes, die gleichzeitig auch Monitor sind im Einsatz. Nutze es bisher als Storage für VMs. Also in etwa was dein ehemaliger Arbeitgeber auch macht.
Für virtuelle Block Devices funktioniert das schon ganz ordentlich.
Dabei ging es aber eher um Ausfallsicherheit, Performance ist in der Umgebung aufgrund der Netzwerkarchitektur begrenzt, aber glücklicherweise auch für die Anwendung ausreichend.
Man könnte schon fast von der ersten geschlossenen Baustelle sprechen.

Ich denke wenn man über CephFS ordentliche Performance haben möchte muss man schon etwas Zeit und Geld investieren. Die Metadata Server sollte man wohl ordentlich dimensionieren und die Netzwerkarchitektur sollte man auch nicht vernachlässigen.
Wie gesagt, ein langfristiges Projekt und vielleicht Lösung all meiner Storage Probleme der Zukunft.
Jetzt CephFS ohne ausreichen Erfahrung und ohne sich damit ausführlich auseinanderzusetzen für zentrale Systeme die in einem halben Jahr realisiert werden einzuplanen erscheint mir doch etwas blauäugig.
Erstmal aktuelle Probleme mit geringem Zeitaufwand lösen und dann in Ruhe zukünftige Strukturen planen.

 

[konfetti]

...
1. Problem: Beschafft wird so ein HPC Cluster inkl. Storage per Ausschreibung...

Wie gea schon schreibt, man kann da schon detailiert in die Ausschreibung mit reingehn, ohne Hersteller zu nennen - ist vlt. etwas aufwändiger, aber dafür kann man so ziemlich alles abgrenzen.

2. Problem: Ich habe momentan wenig Zeit.
Das wird sich langfristig hoffentlich ändern, aber da ich hier erst sei ein paar Monaten tätig bin und die Stelle längere Zeit unbesetzt war gibt es noch viele andere Baustellen.
Daher orientiere ich mich am bisherigen Nutzungsverhalten und wenn für die Aufgabe bisher ein suboptimal konfiguriertes RAID 60 meist gereicht hat hoffe ich die nächsten 3 Jahre mit etwas performanterer Hardware auszukommen.
Ich habe letztes Jahr zwei kleinere Cluster mit ZFS Storage in Betrieb genommen, bei beiden Systemen musste ich analysieren und optimieren bevor die ordentlich liefen.
Ich habe aktuell keine Zeit Anwendungsfälle zu analysieren. So sehr ich die Caches bei ZFS schätze, für Anwender ist es nicht nachvollziehbar warum die Analyse mal in Sekunden fertig ist und mal eine halbe Stunde dauert.

Zeitdruck ist nie gut, und wenn von jemanden, der noch nicht lange im Unternehmen ist erwartet wird, gleich sämtliche Zusammenhänge zu kennen, finde ich das auch nicht optimal - ist aber eher ein Managementproblem, genauso wie Budget und so... Wie Du oben schreibtest: günstig... - Günstig ist es solange, bis was ausfällt und länger steht.

3. Problem: Mögliche Vertreter (bei Urlaub/Krankheit) kennen sich mit ZFS nicht aus. Die Platte oder SSD die rot leuchtet am RAID Controller tauschen bekommt mit telefonischer Unterstützung jeder hin.

Täusch Dich da nicht, hab ich auch schon erlebt, das an nem Storage die Falsche Platte gezogen wurde - dann ist ggf. auch erst mal alles weg. - Hotspares schützen einen hier noch n Tick weiter, sofern das schon die defekte Platte ausgelöst hat und dann einfach nur eine andere fehlt...
An der Kommunikation und Schulung vorallem aud der Vertreter führt kein Weg vorbei, am besten schon bei der Implementation, nicht nur im Betrieb!

Würde ich meinem Basteltireb freien Lauf lassen würde ich ein CEPH oder ZFS System aus NVME SSDs mit Optane log/metadata Device bauen um zu gucken was da so geht.
Aber ich brauche keine ungetestete Bastellösung sondern etwas das unauffällig 3-5 Jahre seinen Dienst verrichtet.

Auch wenn der Reiz da ist, Bastellösungen haben im Operativen Betrieb einfach nichts zu suchen - zum lernen und Fehleranalysieren gern, aber Produktiv dann doch was handfestes, bei dem auch der Support stimmt.
Ich hab ein ZFS on Nas4Free auch nur in der Testumgebung im Einsatz, wenn die mal ne Zeitlang nicht läuft störts auch keinen, ist eher auch nur für die IT zum testen und spielen nebenbei (letzte Nutzung allerdings auch schon 3 Monate her...)

 

[Stueckchen]

Nochmal ein paar Anmerkungen:
Stell doch von Anfang an klar worum es geht: Neuanschaffung oder Upgrade im Bestand, dann kann man besser fragen stellen.

Gerade wenn es um HPC geht, mach dich schlau was drauf läuft und was der Code benötigt bzw. was Performace bringt.
Manchem Code ist Storage recht egal, da nur recht kleine Dateien (50-500MB), Hauptsächtlich Sequenzelle geschreiben werden. Niedrige Latenz ist hier aber gut.
Andere Code bringt Performance vor allem vom Durchsatz und es werden 100GB+ geschrieben. Dann ist evtl ehe besser das Lokal(per node) zu Regel wenn möglich.

Evtl. hängt die Performance ja auch garnicht am Storage, und der Flaschenhals ist CPU, Ram oder Netzwerk.

Dann ist natürlich noch die Frage wie viel Storage schneller wirklich benötigt wird, bzw. ob da einfach viele alte Rechnungen liegen.

Wie oben schon genannt: Solange das Storage nur für den Cluster ist, nicht Unmengen an Speicher 100TB+ benötigt werden ist man mit einem klassischen Storageserver besser dran als mit einen verteilten Dateisystem.

Bei einer Neuanschaffung: Budget anschauen und danach entscheiden, auch wie Unternehmenskritisch die ganze Sache ist. Wenn bei uns der Cluster mal einen Tag nicht oder dank HDD Ausfall langsamer läuft ist das zwar ärgerlich, aber verschmerzbar. Für die 99,9% Verfügbarkeit hätte wo anders Abstrichte gemacht werden müssen, was allg. schlimmer war.

Weiterhin: Ich kenne euer Setup ja nicht. Aber wenn der Storage Server wirklich nur Storage macht. Also eine NFS Freigabe, sehe ich nicht was gegen Servergrade Hardware mit Linux der Wahl und ZoL oder mdadm spricht. Viel Falschmaschen kann man da nicht und ist auch schnell eingerichtet. Wenn man ein hohes Raidlevel + Hotspare fährt muss man schon sehr lange im Urlaub sein, das jemand anderen eine Platte tauschen lassen muss.

Und was Ausschreibung angeht: Wenn man was bestimmtes will bekommt man das auch.

 

[Morpheus2200]

Mir wäre es ganz lieb wenn wir mal zurück zum Thema kommen würden.
Wenn keiner SSD RAIDs betreibt und daher keine Erfahrungen vorhanden sind ist das auch ok.

Neubeschaffung, Storage und drumherum, daher Ausschreibung.

Natürlich wird das Server Hardware mit redundater Stromversorgung, ECC Speicher, SSDs mit ordentlich er Lebenserwartung bei schreibenden Workloads usw.
Ja die Speichermenge wird benötigt. Es gibt 2 weitere Systeme mit HDDs auf die "alte" Daten ausgelagert werden. Man kann nur nie ganz verhindern, dass Anwender auch mal auf dem schnelleren Bereich Daten liegen lassen.
Ein großer Teil des Workloads sieht so aus, dass großen Files etwas angehängt wird. Von vielen Clients auch mal zeitgleich, wie viele es werden weiss ich erst wenn Angebote da sind ich rechne mit ~200.
Einfach zu bewältigen sollte man meinen, bis jemand auf die Idee kommt die Daten auszuwerten und aus den großen Files die dank des zeitversetzten anhängen dann in einem total fragmentierten Zustand im Dateisystem liegen zu lesen während natürlich weiter geschrieben wird.
Und natürlich kann auch mal jemand auf die Idee kommen sich nur noch einen von x Werten aus diesen langen Files zu interessieren und ohne nachzudenken so eine Datei zeilenweise lesen und die benötigten Daten zu filtern. Das erzeugt dann jede Menge fiese lesende Zugriffe. Und wenn man sich "kalte" Daten ansieht hilft da auch kein caching Mechanismus wirklich gut.

Aber das ist nur eine von wenigen Anwendungen, Anwender und Codes ändern ihr Verhalten über die Zeit. Ein bisschen Reserve einzuplanen ist nie ganz falsch.

Aktuell defragmentiere ich bei einem Vorgänger Cluster das Dateisystem bei load <x und geringem I/O.
Nur kommt das auf so einem Cluster wenn das Storage eh schon am Limit läuft eher selten vor, kann Wochen bis Monate dauern bis man da positive Effekte sieht.In der Zeit ändern sich die Daten ja auch wieder. Es ist ein ewiger Kampf...
Wahlfreier lesender Zugriff tut nunmal bei HDDs deutlich mehr weh als bei SDDs.

Meine bisherigen Erfahrungen mit MD-RAID waren eher durchwachsen. Bei hohem load war das teilweise nicht ganz stable, resyncs im ganz normalen Betrieb kamen vor und haben die Performance sehr negativ beeinflusst.
ZFS habe ich bisher immer nur auf BSD oder Solaris genutzt, ZoL in so einer Umgebung "auszuprobieren" kommt nicht in Frage. Da sollte man zunächst an anderer Stelle Erfahrungen sammeln.

 

[MadVector]

Darf ich mich hier kurz mit einer kleinen Frage einklinken?

Ich betreibe ein Raid 1 mit 2x 2Tb HDDs von WD.
Kann ich, sofern ich was günstiges finde, eine der beiden HDDs (egal welche) ausstecken und durch eine 2Tb SSD ersetzen, und das System wird sich dann selbst spiegeln?
Oder muss ich diesen Prozess irgendwie anstossen?

 

[martingo]

Mach bitte Dein eigenes Thema auf, Deine Frage hat nicht ansatzweise etwas mit der von Fr@ddy zu tun.

Mir wäre es ganz lieb wenn wir mal zurück zum Thema kommen würden.

Da hast Du die Rechnung aber ohne die Luxxer gemacht, das wäre ja noch schöner, wenn man nur Antworten auf die gestellten Fragen bekäme :-D
Auch wenn der eine oder andere Denkanstoß sicher sinnvoll war.

 

[konfetti]

Mir wäre es ganz lieb wenn wir mal zurück zum Thema kommen würden.
Wenn keiner SSD RAIDs betreibt und daher keine Erfahrungen vorhanden sind ist das auch ok.

Naja, für unsere DB-Server läuft hier in der MSA2052 nen RAID10 aus 4x800TB SSDs - Angebunden an die ESX-Server mit 12G SAS, das Storage ist bei denen nicht mehr der Flaschenhals, gegenüber früher.
Dennoch muss ich sagen, das die MSA halt mit ihrem recht "starren" RAID total gegen eine 3PAR abstinkt, diese hatten wir bei meinem vorherigen AG im Einsatz, da war auf reinen Disks die IO und auch der Durchsatz schon höher, da war nur die X-IO geiler ^^

Wir haben in der MSA auch Caching SSDs für die HDD-Tiers und das bringt schon nochmal einen Schub, aber für Deinen Anwendungsfall als Filer mit Direktzugriff kann ich Dir da nicht helfen.
Darum hatte ich ja oben mal gefragt, wofür das Storage ist...