News WD Red SN700: NVMe-SSDs sollen lahmen NAS-HDDs Beine machen

[AGB-Leser]

Auf welches Betriebssystem beziehen sich deine Fragen?

Momentan noch TrueNAS
Werde, wenn zfs unter Linux läuft, dann umsteigen

 

[zEtTlAh]

Alle HDDs sind langsam

Würde ich so nicht unterschreiben. Für alles wo SSD zu klein sind oder HDD zu langsam, gibt´s Raid.

 

[mgutt]

Wenn das NFS auch könnte, wär gut.

Aber TrueNAS kann doch NFS?!

 

[AGB-Leser]

Aber TrueNAS kann doch NFS?!

Diese Aussage bezog sich auf den Text vom Nutzer darüber.

Alle HDDs sind langsam

Also ich finde weit über 200mb/s für eine Festplatte keine schlechte Leistung...

 

[Rickmer]

Würde ich so nicht unterschreiben. Für alles wo SSD zu klein sind oder HDD zu langsam, gibt´s Raid.

Das hilft auch kaum wenn IOPS verlangt werden
10k und 15k rpm HDDs können da noch ein bisschen was, aber da geht dann auch wieder die Kapazität bei flöten.

Also ich finde weit über 200mb/s für eine Festplatte keine schlechte Leistung...

Sequential geht ganz gut, aber wehe man fragt IOPS an.

Um Backups oder Filme aufs NAS zu schreiben sind HDDs prima geeigent. Aber wehe man hat 1-2 VMs auf demselben NAS laufen und/oder die macht grade eine Indexierung

 

[AGB-Leser]

Ja, in dem Privatforum bin ich jetzt nicht von solcher hoher IOPS ausgegangen da dürfte eher serielle Übertragung eine Hauptrolle spielen. Klar, für den Kleinkram braucht man eine SSD. Ich weiß aber nicht, inwiefern dann das Ethernet und die Protokolle darüber dann noch begrenzen

 

[zonediver]

das schafft doch auch ne normale HDD?!

...kleine (sehr kleine) Dateien und die IOPs... da kannst ne HDD vergesen...

 

[pseudopseudonym]

Sorn NAS kostet meiner meinung nach eh schon viel zu viel. Wenn das dann noch mit ein paar platten befüllt ist, ist man mal schnell über 1000€ los.... für einen Netzwerkspeicher?!

Das kannst du deutlich geschickter anstellen.
Ich hab's in etwa so gemacht und seit Jahren laufen, nur die Speicher habe ich mal verändert:
Gebrauchtes Mainboard mit nem aufgelöteten passiv gekühlten Atom-Quadcore (ich hab ein Asrock J3455M) für 25€, für (grob geschätzt) 40€ 8GB DDR3 und so ein ganz günstiges Bequiet Systembuilder-Teil für ungefähr 35€. Als Gehäuse irgendeinen Schrott aus dem Keller. Damit bist du bei 100€ fürs Grundsystem.

Als System-SSD und "schnellen NAS-Speicher" hab ich eine 1TB MX500 für 85€, 14TB ausgebaut aus einer WD Elements haben vor dem Chia-Boom unter 300 gekostet. Damit bist du für unter 500€ bei einer NAS mit 14TB HDD und 1TB SSD (- ~40GB fürs System).
Gut, ne Backup-Platte solltest du noch dazurechnen.

1gbit =125mb/s und das schafft doch auch ne normale HDD?!

In bestimmten Szenarien merkt man vor allem die kürzeren Zugriffszeiten, weswegen auch z. B. an SATA-II SSDs einen Unterschied machen.
Wenn man seine HDDs schlafen legt, kommt noch die Anlaufzeit dazu. Will man schnell ein Lied abspielen, dauert das mit schlafenden HDDs ein paar Sekunden.
Gut ist ständiges Hochdrehen auch nicht, Durchlaufenlassen frisst aber mehr Strom und ist lauter. Seitdem alles häufig verwendete auf der SSD liegt, drehen meine HDDs nicht einmal mehr täglich.

 

[zEtTlAh]

Das hilft auch kaum wenn IOPS verlangt werden

Nenn mir mal eine Anwendung wo 20+TB gebraucht werden, mit hohen IOPS. Fände ich interessant. Vor allem wie hoch der Marktanteil dieser Anwendung ist.

 

[Rickmer]

Nenn mir mal eine Anwendung wo 20+TB gebraucht werden, mit hohen IOPS. Fände ich interessant. Vor allem wie hoch der Marktanteil dieser Anwendung ist.

Privat:

• 'NAS für Alles' mit großer Filmsammlung ein einer größeren Anzahl an Diensten & VMs, die drauf laufen
  • Nextcloud/Owncloud, Plex, privater Mailserver, noch ein piHole und dieses oder jenes...
• Ambitionierte Hobby-Regisseure beim scrubbing

Enterprise:

• Veeam Backup-Server mit aktiv verwendetem SureBackup und/oder instant VM recovery (Veeam ist Marktführer, daher Marktanteil nicht schlecht)
• Sach mir bloß, du hast noch keinen 20+ TB Fileserver gesehen
  • Geizhals-Kunde: "SAN erneuern ist zu teuer, lasst uns den großen Fileserver auf ein NAS verschieben". Ja, habe ich schon erlebt. Wurde dann wieder aufgegeben als QNAP bewiesen hat, dass die nicht zu Enterprise-gerechten Reparaturzeiten fähig sind.
• Videobearbeitung mit mehr als zwei-drei Editoren, LinusTechTips hat zu den Problemen die auftreten mehrere Videos gemacht
• SAN für größere Unternehmen
• Lass uns mit allem was auf 'big data' oder 'machine learning' hört garnicht erst anfangen
• und vieles mehr...

Ja, nicht alle Enterprise-Beispiele sind NAS-spezifisch, aber du würdest Bauklötze staunen, was manche Fennigfuchser glauben, was gehen sollte. Von IOPS haben die noch nie gehört. 'Der Speicherplatz reicht doch, warum wollt ihr so viel Geld ausgeben?'...

 

[zEtTlAh]

Also privat sehe ich da echt 0 Anwendung. Ich bin selbst Fotograf und Videograf in meiner Freizeit. Mache auch Gaming Tutorials und zeichne in 4K mit 60FPS auf. noch NIE ist da die NAS auch nur Ansatzweise ans Limit gekommen.

Veem ist Zeitgesteuertes Backup to Disk. Wenn man da mehrere Jobs auf den selben SAN gleichzeitig laufen lässt ist das schon ein Planungsfehler. Ebenso der Fileserver. Ich habe noch kein Unternehmen gesehen, dass jeden Share auf identische, physikalische Shares legt. Und selbst wenn... da müssen schon Tausende User parallel drauf rödeln um eine gescheite SAN an die Kotzgrenze zu bringen.

Egal ob Veem, Avamar oder ZIFS, in Zeiten von Cache SSDs echt kein Problem mehr.

Das Video von Linus habe ich auch gesehen. Hausgemachtes Problem geschaffen um es dann Glorreich zu lösen. Wenn Filmstudios das genau so machen, und da editieren noch mehr Leute gleichzeitig, dann haben die echt einen Konzept Fehler

Machine Learning lasse ich mir noch gefallen. Aber da wären wir wieder bei Marktanteil. Wer sowas macht hat auch Kohle für Enterprise SSD SAN

In 90% der Fälle sind es Design Fehler oder aufgezwungener Budget Mangel. Man muss ich auch immer fragen, wie haben wir vor SSD´s und 10GBit LAN blos überlebt ?

Update:

Hatte ich ganz vergessen zu erwähnen Veem (und auch andere) speichern komprimiert, schreiben also Sequenziell und nicht IOPS orientiert Das Argument fällt also auch aus

 

[Reset90]

Das kannst du deutlich geschickter anstellen.
Ich hab's in etwa so gemacht und seit Jahren laufen, nur die Speicher habe ich mal verändert:
Gebrauchtes Mainboard mit nem aufgelöteten passiv gekühlten Atom-Quadcore (ich hab ein Asrock J3455M) für 25€, für (grob geschätzt) 40€ 8GB DDR3 und so ein ganz günstiges Bequiet Systembuilder-Teil für ungefähr 35€. Als Gehäuse irgendeinen Schrott aus dem Keller. Damit bist du bei 100€ fürs Grundsystem.

Als System-SSD und "schnellen NAS-Speicher" hab ich eine 1TB MX500 für 85€, 14TB ausgebaut aus einer WD Elements haben vor dem Chia-Boom unter 300 gekostet. Damit bist du für unter 500€ bei einer NAS mit 14TB HDD und 1TB SSD (- ~40GB fürs System).
Gut, ne Backup-Platte solltest du noch dazurechnen.

Ich habe aktuell 6 externe 3,5" platten, welche ich immer je nach dem welche ich brauche mit USB an meinen PC anschließe.

Was anderes als eine USB festplatte würde ich ein NAS auch nicht nutzen. kein Cloud oder das der Fernseher was vom NAS streamt. brauche ich alles nicht.

Wie siehts mit dem Stromverbrauch vom deinem ding aus? Würde bei mir aber so oder so rausfallen, da ich es Softwareseitig nicht hinbekommen würde

 

[Rickmer]

Veem ist Zeitgesteuertes Backup to Disk. Wenn man da mehrere Jobs auf den selben SAN gleichzeitig laufen lässt ist das schon ein Planungsfehler.

Hatte ich ganz vergessen zu erwähnen Veem (und auch andere) speichern komprimiert, schreiben also Sequenziell und nicht IOPS orientiert Das Argument fällt also auch aus

Ich vermute, du kennst das Produkt nicht spezifisch, aber ich habe schon absichtlich SureBackup und Instant VM Restore geschrieben.

Ersteres ist ein automatisierter Restore-Test (ist das Backup bootfähig und besteht ein paar simple Funktionstests?), zweites ist ein Restore, bei dem die VM direkt vom Backup gebootet wird und erst danach die Daten auf den SAN verschoben werden (was eine enorme Zeitersparung ist gegenüber einem traditionellem Restore).
In beiden Fällen hast du erstmal eine VM bis zu einer Gruppe an VMs die direkt aus Backup-Speicher gebootet sind und entsprechend IOPS verlangen.

Das Backup-Jobs erstmal sequentiell schreiben ist mir durchaus bekannt, aber darum ging es mir ja auch garnicht. Tellerrand, etc. Traue keinem Backup, das du nicht getestet hast.

Ich habe noch kein Unternehmen gesehen, dass jeden Share auf identische, physikalische Shares legt.

Alle SANs die ich kenne funktionieren nach Grundprinzip 'Alle physischen Datenträger zu einem großen Storage-Pool kombinieren, darauf werden dann LUNs aufgesetzt'.

 

[zEtTlAh]

Instant VM Restore geschrieben.

Also für sowas haben wir eine 90TB SSD SAN. Und da wird nur die Betriebssystem Partition gesichert. Die reinen Datenpartitionen laufen normal ins Avamar / Veem. Für sowas ist halt HDD echt nix. Aber ein eher seltenes Szenario

'Alle physischen Datenträger zu einem großen Storage-Pool kombinieren, darauf werden dann LUNs aufgesetzt'.

Ich denke das Thema lassen wir aus, darüber kann man Doktorarbeiten schreiben Kommt halt auch auf die Größe der Umgebung und deren Anwendung an. Kann man ja auch Skalieren. Aber wie gesagt, das wird hier too much

 

[Rickmer]

Also für sowas haben wir eine 90TB SSD SAN.

Dafür ist der durchschnittliche Kunde mit dem ich zu tun habe viel zu klein. Selbst die Backup-Server haben meistens nur im Bereich 10-50TB Speicherplatz, wenige mal dreistellig. Halt so das drei- bis fünffache von der Größe eines Fullbackup, mit ReFS und Block Cloning reicht das.

So unterscheiden sich die Erfahrungen...

 

[pseudopseudonym]

Was anderes als eine USB festplatte würde ich ein NAS auch nicht nutzen.

Muss man auch nicht, aber ich nutze meine NAS unter anderem, um mehrere Geräte zu synchronisieren, auch wenn ich außer Haus bin. Da bringt USB mich nicht viel weiter.

Wie siehts mit dem Stromverbrauch vom deinem ding aus?

Ich hab's ehrlich gesagt nicht mehr im Kopf, irgendwann hab' ich es mal gemessen. Für meine Haushaltsgröße liege ich unterm Durchschnitt vom Gesamtverbrauch her, es kann also nicht zu schlimm sein.