Fileserver für extrem hohen Datendurchsatz

[cubewall]

Moin zusammen,

wir stossen in letzter Zeit öfter an die Grenzen der im Mietmarkt verfügbaren Rental-NAS-Systeme für das Content-Handling unserer Medienserver. Ein typisches Szenario sieht so aus:
8-12 Medienserver sind per LAG (2 x 10GBit/s) an einen 48-Port 10GBase Switch angebunden. Datenquelle ist ein NAS oder ein Windows-Fileserver, der mit bis zu 4x10GBit/s (je nach verfügbarer Ausstattung) an den Uplink des Switch angebunden ist. Verfügbare NAS-Systeme im Markt sind aktuell 2477-Serie von QNAP, alternativ auch DELL-Server, zum Teil auch schon mit SSD bestückt. Realistische Datenströme bei Anbindung von 8-12 Servern fallen dann pro Server schnell in den Bereich um die 200 MB/s , also nur unwesentlich schneller als eine geteamte Gigabit-Verbindung. Übertragen werden dabei in der Regel unkomprimierte Einzelbild-Sequenzen (TIFF,PNG) mit einer Einzeldateigrösse von 6-24MB, je nach Projekt also zwischen 25 und 60 Bilder pro Sekunde. Diese werden dann lokal in den RAIDs der Medienserver gespeichert.
Der Flaschenhals ist also offensichtlich die Anbindung des NAS/Servers an den Switch. Im Markt verfügbare NAS-Systeme von QNAP sind mit max. 2 x 40GBit/s Karten bestückbar, Synology hat sogar auf nur 2 x 25Gbit/s reduziert.

Meine Idealvorstellung wäre ein Fileserver, der eine konstante Lese-Rate von 8000-12000 MB/s realisieren kann, also konstant 100GBit/s Richtung Switch schieben kann, um ausreichend Datenstrom zu gewährleisten. Dazu denke ich an einen Netzwerkadapter mit 2 x QSFP28, der die Verbindung zwischen Server (NAS ist mE an der Stelle raus) und Switch bedient. Brutto-Kapazität sollte bei ca. 50TB liegen (mit 24 x 2TB in einem Raid 5/6 wäre es wahrscheinlich zu knapp) . Wie und mit welcher Hardware schaffe ich es, daß der Server diese Datenmengen auch zur Verfügung stellen kann?
Raid-Controller für bis zu 28 Stück SATA 6GB/s oder SAS 12GB/s sind *nur* mit PCIe 3 x8 angebunden, theoretisch als mit max 7,8GByte/s , wenn ich der Tabelle trauen kann, die ich gefunden habe.
Welchen Ansatz soll ich nun verfolgen:
- 24-36 Platten SATA oder SAS? Wie stabil sind Systeme aus mehreren Raid-Controllern, um auf den gewünschten Datendurchsatz zu kommen?
- NVMe oder U.2 Raids? gleiches Problem mit mehreren Controllern, um auf die gewünschte Kapazität zu kommen
Welches Betriebssystem, um den Overhead so gering wie möglich zu halten?

Als Switch wäre entweder der Cisco Nexus 9300-EX mit 48xRJ45 und 6 x QSFP28 geplant oder der N5860-48SC von fs.com.

Der zweite Schritt ist dann die Bereitstellung von Schnittplätzen, die auch mit der entsprechenden Geschwindigkeit auf den Server schreiben können.

Bin für ein paar Denkanstösse und das Aufzeigen von Fallstricken bei dem Thema dankbar. Das ist ja doch ein bisschen jenseits von dem, was man jeden Tag in den Fingern hat.

Gruss
Cube

 

[v3nom]

Das wird kein simples NAS mehr sein, das wird ja schon ein richtiger Server.
100GbE mit HDDs zu sättigen halte ich für nachezu unmöglich. Da musst du schon Richtung SSDs planen, aber dann wird es teuer.
Beachte auch das ein hoher Durchsatz eine starke CPU braucht.

 

[fard dwalling]

Also mit normalen Platten wirst du das nicht hinkriegen.
Hier wirst du auf reines SSD System gehen müssen. Um wie viel Speicherplatz reden wir hier denn?

Ach hast du ja geschrieben... 50TB brutto...
Uiuiui.
Evtl Mal ne Nimble HF40 oder HF60 anschauen? Mit reichlich SSD Cache könnte das was geben.

Und dann wirst du zwingend SMB Multichannel nutzen müssen. Denn im Prinzip sind die TIFFs ja schon Recht klein mit den 6MB.. da reicht dir brutale sequentielle Leistung nicht..

 

[cubewall]

Moin,

habe heute mal 2 Systemhäuser kontaktiert und auch schon 1 Angebot erhalten. Liegt mit gut 20k netto bei 60TB Nettokapazität absolut im Rahmen dessen, was ich erwartet habe. Dort geht man den Ansatz von 11 x Kioxia CD6-R mit jeweils 7.68TB im Raid 50, also 2 x 5 Platten mit 1 Platte Spare. Allein der Strassenpreis der 11 Platten laut Geizhals übersteigt die angebotene Summe, von daher kann ich das eine Angebot nicht ganz nachvollziehen. Oder die Jungs haben wirklich so viel bessere Einkaufskonditionen und geben sie auch weiter.

Aber das ist mal ein Ansatz, ob sich ein Selbstbau unter den Umständen lohnt oder ob ich die Maschinen dann lieber gleich mit 3 Jahren vor Ort Service fertig kaufe - ich glaube, da tendiere ich eher zu letzterem.

Der zweite Anbieter hat mich auf Montag vertröstet, aber geht gemäss seiner Aussagen am Telefon den gleichen Weg mit U.2 NVMe von Samsung, wenn ich es richtig interpretiert habe.

Schaun mer mal, was dabei rauskommt.

 

[gea]

Ich denke nicht dass der Flaschenhals die Netzanbindung ist sondern concurrent io. Wenn ein Dutzend Server jeweils unterschiedliche Daten lesen/schreiben wollen die wild über das Array verteilt sind, so nützt weder hoher Netzwerkperformance noch hoch sequentielle Leistung sondern iops und idealerweise große rambasierte Lesecaches. Arrays skalieren mit der Anzahl der Platten. Sequentiell hat eine Platte bestenfalls ca 200 MB/s, bei random Last vielleicht noch 100 MB/s. SSD liegen in beiden Werten bei bis zu 500 MB/s, NVMe bei 2000 MB/s.

Besonders iops sind ein Problem. Eine Festplatte kann ca 100 iops, eine gute SSD bis zu 80k iops, sehr gute SAS SSD bis zu 300k und die best of all, eine Intel Optane 500k. Insgesamt halte ich 10GB/s bei random Last für kaum realisierbar. Wichiger als 1 x 10 GB/s wären aber eh 10 x 500 MB/s gleichzeitig. Bei meinen letzten ZFS Tests mit einem 16/32 core Epyc und 128 GB RAM als Cache kam ich nicht über 4 GB/s mit Intel Optane Raid-0. Mehr ist in jedem Fall sportlich und teuer. ZFS bedeutet zwar höchste Datensicherheit und Datenversionierung und nicht max. Performance aber auch Dateisysteme mit weniger Datensicherheit dürften da Probleme haben.

Mit normalen Platten wird am ehesten ein Multi-Raid 10 System funktionieren. Da skaliert iops mit der Anzahl der Mirror schreibend und 2 x Mirror lesend. Bei einem Raid-50 hat man lediglich ca 200 iops, so wie 2 Platten, das wird kaum reichen - mal davon abgesehen dass Raid-5/50 bei großen Arrays eher unsicher ist. Raid 6/60 wäre sicherer, ZFS Z2 toppt das nochmal

Mit SSD z.B. WD SS530 oder Enterprise NVMe hat man bessere Chancen.

 

[kalgani]

Ist bei den Anforderungen ein SSD-SAN mit FC Anbindung und passendem Fileserver nicht sinnvoller?
z.B. Dell EMC Powerstore 500 / Lenovo ThinksystemDE ...
Da könnte man auch einfacher das System erweiteren.
Weiteres Bay dran und gut ist.

 

[gea]

Storage erweitern geht bis zu mehreren Hundert Platten am einfachsten, schnellsten (2 x 12G, 2 x 24G am Kommen) und billigsten mit SAS. FC ist eher für die schnelle Anbindung von Clients an den SAN Server von Interesse. (Blockbasiert als Alternative zu iSCSI). Filesharing (NFS, SMB) ist aber erheblich flxibler, ähnlich schnell und man kann filebasierte Versionierung machen (ZFS Snaps, Windows vorherige Version)

 

[kalgani]

FC um Clients anzubinden?!?
Wird das FC Fabric dann nicht etwas kompliziert?

 

[cubewall]

Moin Gea, Moin Kalgani,

danke für eure vielen Anregungen und Tips, da merke ich dann doch, dass selbst das Formulieren der Anforderungen bei verschiedenen Firmen ganz schnell durch eine vorschnelle Bemerkung meinerseits in die gleiche - falsche? - Richtung laufen. Das Thema IOPS war mir in dem Zusammenhang nicht so bewusst, ich habe rein auf die max. erreichbaren Geschwindigkeiten geachtet, ohne zu wissen, was wirklich dahinter steckt.

Um einige Punkte auf zu greifen:
@ kalgani: Natürlich wäre das Ganze auf Fibre wesentlich einfacher skalierbar, Bestand bei den ganzen Vermietfirmen der Medienserver sind aber nach wie vor die Dual-10G-Karten, meist von Intel. Selbst wenn ich als Systemkomponenten die Netzwerkkarten für eine 25GB-Infrastruktur stellen würde, dürften sie nicht verbaut werden, da die Server auf proprietären Systemen laufen, wo sogar das Upgraden von Treibern untersagt ist, um die Systemstabilität nicht zu gefährden. Von daher ist lediglich die Anbindung Server-CoreSwitch von Belang.

@gea: Danke für deinen Input, lässt mich das Ganze ein wenig nüchterner betrachten. Die Erweiterbarkeit des System ist erstmal zweitrangig, Mir fehlt jetzt hier aber das Grundverständnis für den AUfbau eines solchen Systems from the scratch, also welches Gehäuse, Anschluss Backplane an Raidcontroller und damit eihergehend welche Raidcontroller werden evtl. noch als Einsteckkarten benötigt, Dimensionierung CPU/RAM usw.

Mich interessiert das Thema schon wahnsinnig, aber ich tue mich schwer, Seiten zu finden, wo die Basics gerade für solch komplexen Systeme mal erklärt werden. Würde mich da gerne einlesen, damit ich wenigstens verstehe, warum ein System eher in die eine oder die andere Richtung designed sein sollte.

Gruss
Cube

 

[noexen]

Dort geht man den Ansatz von 11 x Kioxia CD6-R mit jeweils 7.68TB im Raid 50, also 2 x 5 Platten mit 1 Platte Spare. Allein der Strassenpreis der 11 Platten laut Geizhals übersteigt die angebotene Summe, von daher kann ich das eine Angebot nicht ganz nachvollziehen.

ähh und was soll bei den 20T euro dann da noch an hardware zu den kioxia SSDs mit drin sein? DAS wäre mal interessant. weil irgendwo müssten die SSDs ja auch drin sein und das wird wohl kein 0815 thinkserver sein können wenn mind. 12 hotswap bays (und "irgendwas" in dem ding muss ja auch rechnen und 8GB ram werden es wohl auch nicht tun... ^^) und ein controller drin sein muss der 12 devices ansteuern kann, der auch nicht für 100euro zu haben ist.

kann ich mir eingentlich für den prezzo 1. gar nicht vorstellen und 2. nur wenn das systemhaus eine mischkalkulation macht und sich das geld über wartungsvertrag wieder rein holt.
ODER aber die hardware war schon mal verkauft und nie oder nur zur IBN zum einsatz gekommen ist abgeschrieben oder sowas...

edit: ODER die SSDs sind "vom laster gefallen"... (jk!)
edit: hups, ja moin, der thread ist ja hornalt, zu welchem system ist es denn jetzt gekommen und wie läuft es?

 

[cubewall]

Moin noexen,
sooooo alt ist der thread auch noch nicht, Aber das Projekt ist erstmal zurück gestellt, weil die Resonanz im Markt nicht wirklich einen ROI innerhalb eines vernünftigen Zeitraums erwarten lässt,
Zudem waren ein paar andere Anschaffungen dringlicher für die laufenden Projekte.

Aber wie ich im letzten Post schon geschrieben habe, würde ich gerne erstmal mehr über die Abhängigkeiten in einem solchen System lernen und verstehen, bevor ich mehrere Zehntausend Euro für Hardware ausgebe, die dann doch nicht meine Anforderungen erfüllt.

Ich bin auch offen für gewerbliche Angebote, die über diese Schiene hier kommen, im Eigenbau werde ich das definitiv nicht umsetzen.

Gruss
Cube

 

[jdl]

Gibt es noch Diskussionsbedarf?

 

[lihp]

Moin noexen,
sooooo alt ist der thread auch noch nicht, Aber das Projekt ist erstmal zurück gestellt, weil die Resonanz im Markt nicht wirklich einen ROI innerhalb eines vernünftigen Zeitraums erwarten lässt,
Zudem waren ein paar andere Anschaffungen dringlicher für die laufenden Projekte.

Aber wie ich im letzten Post schon geschrieben habe, würde ich gerne erstmal mehr über die Abhängigkeiten in einem solchen System lernen und verstehen, bevor ich mehrere Zehntausend Euro für Hardware ausgebe, die dann doch nicht meine Anforderungen erfüllt.

Ich bin auch offen für gewerbliche Angebote, die über diese Schiene hier kommen, im Eigenbau werde ich das definitiv nicht umsetzen.

Gruss
Cube

Zu Deinem Projekt kann ich gerne Einiges mitgeben. Nur zwei Dinge fielen mir vorab ins Auge:

1. NVME - Samsung versus Kioxia: einfach den Link https://www.storagereview.com/review/samsung-pm1735-ssd-review - Kurzfazit: die Samsung Laufwerke PM17xx sind i.d.R. im gleichen Preissegment wie die Kioxia Pendants (CD6, CM6), aber im Einsatz brechen die Samsung-Laufwerke früh und teilweise heftig ein (gitl für alle Varianten: M.2, PCIe, U2 und E). Da gewinnen die Kioxia Laufwerke immer.
2. Anforderungen: es wird nicht klar, welche Art Traffic für Dich relevant ist. Daraus folgt erst die Lösung, die das auch belastbar kann. Eckpunkte:
   1. single-threaded: Ist der traffic im hohen Volumen vor allem single threaded? Also zB ein file/ein user?
   2. multi-threaded: Sind es viele Dateien gleichzeitig?
   3. (a-)synchron: Werden Daten synchron oder asynchron übertragen?

Bandbreiten im Server von 10GB+ dauerhaft für synchrone, single-threaded-Leistungen sind möglich aber tatsächlich braucht es da einiges. Asynchron, multi-threaded ist fast schon Standard, wenn man Flaschenhälse beseitigt (Storage, Netz, Bus, CPU,,..)

 

[amdpc]

Zu Deinem Projekt kann ich gerne Einiges mitgeben. Nur zwei Dinge fielen mir vorab ins Auge:

1. NVME - Samsung versus Kioxia: einfach den Link https://www.storagereview.com/review/samsung-pm1735-ssd-review - Kurzfazit: die Samsung Laufwerke PM17xx sind i.d.R. im gleichen Preissegment wie die Kioxia Pendants (CD6, CM6), aber im Einsatz brechen die Samsung-Laufwerke früh und teilweise heftig ein (gitl für alle Varianten: M.2, PCIe, U2 und E). Da gewinnen die Kioxia Laufwerke immer.
2. Anforderungen: es wird nicht klar, welche Art Traffic für Dich relevant ist. Daraus folgt erst die Lösung, die das auch belastbar kann. Eckpunkte:
   1. single-threaded: Ist der traffic im hohen Volumen vor allem single threaded? Also zB ein file/ein user?
   2. multi-threaded: Sind es viele Dateien gleichzeitig?
   3. (a-)synchron: Werden Daten synchron oder asynchron übertragen?

Bandbreiten im Server von 10GB+ dauerhaft für synchrone, single-threaded-Leistungen sind möglich aber tatsächlich braucht es da einiges. Asynchron, multi-threaded ist fast schon Standard, wenn man Flaschenhälse beseitigt (Storage, Netz, Bus, CPU,,..)

Bitte um Beispiele, welche "wie auch immer" 80-100Gbit Durchsatz auf einem IP basierten Protokoll schaffen + keine Unsummen (>100K) kosten.

 

[lihp]

Bitte um Beispiele, welche "wie auch immer" 80-100Gbit Durchsatz auf einem IP basierten Protokoll schaffen + keine Unsummen (>100K) kosten.

Ich schrieb 10GB+, nicht 80-100Gbit. Das ist ein Unterschied: 10GB+/s = 80Gbit+/s. .

1. SDS-array über 4 Kioxia CM6-V U.3, 3.2 TB schaffen das bereits bei großen Dateien.
2. xfs
3. RDMA (Direct-nfs auch mit Direct-Samba möglich, idealerweise ab Kernel 5.x+)

gesamt ca. 6+ K € für einen Knoten, schafft 80GBit++ synchron, single-threaded unter Ubuntu 20.04 HWE. .

PS: mit iSer habe ich da noch meine Probleme mit der Bandbreite - meine aktuelle Tätigkeit. Nächstes sind Tests mit NVME-OF.

 

[Fr@ddy]

Ich habe ein System für read intensive workloads bestellt. Dual Epyc mit 24*15TB PM1733.
Wenn Interesse besteht poste ich hier Benchmarkergebnisse sobald ich das gute Stück in Betrieb genommen habe.

200Gb/s Connect-X6 Interface ist auch dran, für Tests von remote muss ich aber mal gucken ob da noch ein anderer Rechner mit voller Bandbreite angebunden ist, in dem Netz habe ich sonst nur 2x100Gb/s splitter Kabel um Switche zu sparen.

 

[lihp]

Ich habe ein System für read intensive workloads bestellt. Dual Epyc mit 24*15TB PM1733.

Die PM1733 sind eher schwach für sustained load (Latenz unter Last). Wenn es noch geht, würde ich empfehlen auf die Kioxia CM6 oder CD6 auszuweichen. Deutlich besseres Lastverhalten. Selbst der Nachfolger der 1733, die 1735, säuft noch ab.
https://www.storagereview.com/review/samsung-pm1735-ssd-review
https://www.storagereview.com/review/kioxia-cm6-pcie-4-0-ssd-review

Zum Nachfolger, der PM9A3 kann ich nicht viel sagen, da wir die noch nicht getestet haben. Nur auch da gehe ich von einem ähnlichen Lastverhalten aus - die Technologie hat sich eben nicht drastisch geändert.

Wenn Interesse besteht poste ich hier Benchmarkergebnisse sobald ich das gute Stück in Betrieb genommen habe.

Großes Interesse. Fragen und Anmerkungen meinerseits:

• Erfahrungsgemäß liefert XFS die beste Performance, zumeist wenn man das gesamte Laufwerk direkt formatiert (RHEL/Ubuntu).
• mdadm ist... lahm. Mit der letzten größeren Änderung passt zumindest die Leseperformance weitgehend.
• iSer lieferte bei uns die beste Performance über das Netz.
• Performanceseitig ist raidix mit eraraid die mit Abstand beste SDS-Lösung - bei Interesse PM an mich, dann kommst Du direkt rein für Tests etc.

1. Wie bindet Ihr die Laufwerke an? Aktuell gibt es ja nicht so viel Gutes für U2/U3 PCIe 4.0 - Anbindung?
2. Welche Art Last ist Euer Haupteinsatzziel?
3. OS?

200Gb/s Connect-X6 Interface ist auch dran, für Tests von remote muss ich aber mal gucken ob da noch ein anderer Rechner mit voller Bandbreite angebunden ist, in dem Netz habe ich sonst nur 2x100Gb/s splitter Kabel um Switche zu sparen.

Jaaa kenne ich - die Switche kosten mal so richtig - da sind wir auch eher zurückhaltend Aber DAC geht ja eigentlich immer oder?

Beitrag automatisch zusammengeführt: 18.11.2021

PS: je nach Last ginge ja auch ein "Hot Storage" - groß genug, um die Bursts deutlich abzufangen, klein genug, damit es nicht das Budget sprengt. Weil dann geht auch Intel Optane SSD DC P5800X, U.2 für den Hot Storage.

 

[Fr@ddy]

Filesystem werde ich testen müssen, da ich ähnliche Systeme bisher nicht im Einsatz hatte. Mit XFS hatten wir hier in der Vergangenheit mal Probleme bei vielen parallelen Zugriffen über NFS, aber an XFS wurde ja einiges getan...
Ich wollte mal RAIDX mit Testlizenz testen, nutzen werde ich vermutlich md raid oder sowas, wird freie Software werden wenn die Differenz für unseren Anwendungsfall nicht signifikant ist.

1. Darüber darf sich in diesem Fall der Anbieter Gedanken machen. Wird als Komplettsystem gekauft.
2. Auf dem System werden lokal Datenanalysen gefahren, bisher war das Storagesubsystem der begrenzende Faktor für diese Anwendung.
Das Filesystem wird dann noch per NFS an einen Cluster angebunden, dann können die zu analysierenden Daten direkt schon da erzeugt werden ohne Last auf anderen Filesystemen zu verursachen.
3. Centos 8 mal gucken wohin wir dann migrieren,

Naja nicht nur die Switche sind teuer, die Kabel leider auch.
Aber diese Y-Kabel mit 2x100Gb/s sparen schon enorm wenn man vor allem geringe Latenzen und nicht nur Bandbreite braucht. Non-Blocking Fabric mit 40 Nodes pro leaf-Switch ist schon toll.

 

[lihp]

Filesystem werde ich testen müssen, da ich ähnliche Systeme bisher nicht im Einsatz hatte. Mit XFS hatten wir hier in der Vergangenheit mal Probleme bei vielen parallelen Zugriffen über NFS, aber an XFS wurde ja einiges getan...

Ich bin gespannt, was bei Euch rauskommt. Nur sorry, wenn es noch einmal kommt: die Samsung 1733 machen wenig Spass, vor allem wenn es unter Volllast Aussetzer gibt, weil die Latenz gegen unendlich geht - dann ist der SDS auch mal im deadlock. Passiert mit eraraid und auch mit mdadm (bei mdadm seltener, weil mdadm nicht so schnell ist ).

Ich wollte mal RAIDX mit Testlizenz testen, nutzen werde ich vermutlich md raid oder sowas, wird freie Software werden wenn die Differenz für unseren Anwendungsfall nicht signifikant ist.

da bin ich mal gespannt - der Unterschied raidix zu mdadm ist drastisch. In fast allen Szenarien kam raidix nahe an das physikalische Maximum, mdadm nicht ansatzweise, zB reiner Storagedurchsatz 20GB/s+ (große RAID 6 Arrays - nicht einmal RAID 5). Kleiner Tipp: eraraid-Anleitung wirklich im Detail lesen und verstehen. Mehrere "blöde" Probleme werden abgefangen, wenn man es gelesen hat.

2. Auf dem System werden lokal Datenanalysen gefahren, bisher war das Storagesubsystem der begrenzende Faktor für diese Anwendung.
Das Filesystem wird dann noch per NFS an einen Cluster angebunden, dann können die zu analysierenden Daten direkt schon da erzeugt werden ohne Last auf anderen Filesystemen zu verursachen.

Direct-NFS?

3. Centos 8 mal gucken wohin wir dann migrieren,

CentOS 8.4 aktuell NICHT CentOS 8.5 - eraraid wird noch für das neue 8.5er Kernel angepasst.
Ubuntu 20.04 HWE legt in der performance noch einmal deutlich zu. Deswegen haben wir unser Testsystem gerade von RHEL 8.4 nach Ubuntu 20.04 HWE umgestellt.

Naja nicht nur die Switche sind teuer, die Kabel leider auch.
Aber diese Y-Kabel mit 2x100Gb/s sparen schon enorm wenn man vor allem geringe Latenzen und nicht nur Bandbreite braucht. Non-Blocking Fabric mit 40 Nodes pro leaf-Switch ist schon toll.

ja

Beitrag automatisch zusammengeführt: 19.11.2021

werde ich testen müssen

PS: Für manches ist es praktisch ein zweites Testsystem zu haben mit 3-4 NVME. Da geht fast jede Enterprise NVME und raidix ist ehh kostenlos bis 4 Laufwerke. Dann kann man Änderungen, kleinere Tests an dem System vorab probieren und spart sich eventuellen RAID-rebuilt oder init an der dicken Maschine mit den Wartezeiten.

Beitrag automatisch zusammengeführt: 19.11.2021

PPS: für Last kommt unser Einsatz dem Chia-Crypto-plotting nahe. In Deinem Falle sollte die Lastgrenze bei ca. 88 parallelen K32-Plots á 2 Threads sein. Sehr schön, um Hochlastverhalten über einen längeren Zeitraum zu testen.

 

[Fr@ddy]

Treten deine befürchteten Aussetzer bei nur schreibendem oder auch bei lesendem Zugriff auf?
Ich habe produktiv keine Quelle die schreibend das System auch nur ansatzweise an die Grenze bringen wird. Die schnellste Datenquelle in dem Netz ist ein SAS SSD Array.

0815 NFS, vom OS. Da wird die Performance nicht entscheidend sein, geht eher darum die Ergebnisse nicht später für die Analyse noch einmal kopieren zu müssen.
Das erzeugen der Daten ist doch eher CPU limitiert.

Ich teste (wenn die Zeit es erlaubt) gründlich wenn die Kiste kommt. Nach Test wird eingerichtet und ab dann genutzt, da wird dann nicht mehr viel getestet und modifiziert.
Steht das System mal still oder läuft ein rebuild können wir die Analysen halt in dem Moment nicht so schnell fahren. Das System wird nicht 24/7 so genutzt werden, die zu analysierenden Daten zu erzeugen dauert voraussichtlich deutlich länger als die Analyse.
Aktuell haben wir für diesen Anwendungsfall keine geeignete Hardwareplattform, das ganze ist auch ein bisschen Forschung wie sich das ganze unter Last verhält wenn man das Nadelöhr Storage etwas aufbort.
Für mich ist es echt spannend mal lokal so viel schnellen Speicher zu haben, caching ist halt doch eine ganze Ecke einfacher wenn es sich um ein lokales Dateisystem handelt auf das der Rechner exklusiven Zugriff hat.

 

[lihp]

Treten deine befürchteten Aussetzer bei nur schreibendem oder auch bei lesendem Zugriff auf?
Ich habe produktiv keine Quelle die schreibend das System auch nur ansatzweise an die Grenze bringen wird. Die schnellste Datenquelle in dem Netz ist ein SAS SSD Array.

Also wir haben die Aussetzer erlebt. Frage ist einfach wie nahe Ihr über längere Zeit an die Leistugnsgrenze geht. Am ersten Link von mir sieht man das ganz gut:

Die Zugriffe nehmen zu und die Latenz "springt" hoch. Habt Ihr dann noch mehr Zugriffe, dann machen die Platten zu, die zugehörigen Prozesse gehen in D-state. Geht es immer noch weiter, dann kommen die Prozesse aus dem D-State nicht mehr raus - deadlock. Das ist ein Risiko von SDS, haben aber HW-RAIDs in anderer Form ähnlich...

0815 NFS, vom OS. Da wird die Performance nicht entscheidend sein, geht eher darum die Ergebnisse nicht später für die Analyse noch einmal kopieren zu müssen.
Das erzeugen der Daten ist doch eher CPU limitiert.

Deswegen ja Direct NFS. Ist im Prinzip RDMA NFS mit den Mellanox-Karten. Erst damit kriegt man hohe Durchsätze übers Netz konstant hin.

Ich teste (wenn die Zeit es erlaubt) gründlich
<snip>

Die Geschwindigkeit kann "süchtig" machen, weil auf einmal ganz andere Konzepte möglich sind. Sei es im Datenbankenbereich, Cluster, rt-Finanzdatenauswertung etc. Bei uns werden es deswegen hoffentlich auch bald dicke Storage-Cluster mit den Optane DC P5800X - einfach weil die Latenz so abartig gering ist. Damit sollte noch einmal ein Sprung möglich sein. Nur für die braucht man Budget, die sind nicht billig...

 

[Fr@ddy]

So die Kiste ist gestern angekommen und ich habe mal auf die schnelle ein MD-RAID 6 angelegt und teste gerade. Habe bisher nur die Anzahl der für die Paritätsberechnung verwendeten Threads erhöht, sonst noch nichts.
Laufen gerade erste Tests, beim schreiben geht die CPU Last schon ordentlich hoch, wobei mich ja für meinen Anwendungsfall eher interessiert wie es lesend aussieht.
Aktuell ca. 1-2GB/s schreibend bei ca. 4TB written. Ohne die Threads für die Paritätsberechnung anzupassen sind es <1GB/s. Das alles noch während im Hintergrund das Filesystem initialisiert wird.
MDRAID ist schreibend also wie erwartet nicht so fix. Wobei das wie gesagt eine Einschränkung ist mit der ich für den Anwendungsfall leben könnte.
Dauert halt alles ein bisschen mit dem Testen, aber Testfälle die kleiner sind als der lokale RAM (2TB) machen lesend eben wenig Sinn.

 

[lihp]

Das alles noch während im Hintergrund das Filesystem initialisiert wird.

Zahlen mit init rauszugeben ist schoa ebbes früh

 

[Fr@ddy]

Naja schlechter als die Zahlen wirds wohl nicht ;-)

 

[drdope]

@cubewall
Wenn du schon in dem QNAP-Game drin bist, könntest du dir auch mal das QNAP TS-h2490FU anschauen:
--> https://www.qnap.com/de-de/product/ts-h2490fu
Alternativ wäre das kleine TrueNAS R10 evtl. was für dich.
--> https://www.truenas.com/r-series/#Models

 

[Fr@ddy]

Zeit ist ein bisschen knapp im Moment, da ich heute noch 2 weitere Systeme bekommen habe um die ich mich kümmern muss. Aber ich habe zwischendurch ein bisschen mit fio getestet.
Sequentiell lesend ist es auch mit MD-RAID 6 und ext4 schon recht flott. Folgende Werte habe ich mit 24 fio Threads erreicht, je Thread 50GB also nur 1,2TB beim Test erzeugte Daten, daher sind die buffered Werte mit Vorsicht zu genießen.
Bei 1M großen Blöcken BW=36.7GiB/s lesend mit direct i/O read und bei 64.9GiB/s buffered read.
Bei random read mit großen 1M Blöcken lässt sich auch noch um die 30GiB/s direct i/o erreichen.
Mit kleinen Blöcken sieht das wie zu erwarten leider viel schlechter aus, geht runter bis auf ~1Gib/s und nur <300k iops 4k random read.
So kleine Blöcke sind natürlich auch fies für einen großen RAID6 Array.

Wenn ich zeit zum testen hatte melde ich mich wieder.