Test QNAP TS-h686 im Test: Das Intel-Xeon-ECC-PCIe-2,5-GbE-ZFS-M.2-NAS

[Nagilum99]

Ich hätte gerne einen NAS, der das von alleine macht und vielleicht in einem Log darauf hinweist.

Jedes NAS mit ZFS sollte das erledigen, da es Dateisystemnativ ist.
Was Synology mit BTRFS anstellt, weiß ich nicht, AFAIK legen sie es aber nur über MDADM um auch RAID anbieten zu können. Damit sollte die Prüfsummenfunktion aber erhalten bleiben, es ist nur nicht möglich Probleme auf einzelnen Datenträgern zu finden - was aber in Summe irrelevant ist.

Ergänzung (10. Februar 2021)

Dein 'kann doch garnicht sein' ist mir auch scheißegal, ich habe reale Benchmarks und schäme mich nicht die zu posten

Du hast irgendeinen Benchmarkscreenshot gepostet, der wirre Daten ohne Erklärung zeigt.
Ich halte dir entgegen, dass technisch gesehen rund das doppelte (280 MB/s) durchgehen.
Das erste ist eine Behauptung, das zweite ein Fakt (es ist nunmal ein definierter Standard).

Natürlich darfst du dich jetzt wie ein dreijähriger im Sandkasten verhalten, dem man die Schippe weggenommen hat, du könntest aber auch eine technische Erklärung liefern.

 

[Rickmer]

Ich halte dir entgegen, dass technisch gesehen rund das doppelte (280 MB/s) durchgehen.
Das erste ist eine Behauptung, das zweite ein Fakt (es ist nunmal ein definierter Standard).

Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie und die Praxis wurde sowohl hier im Review der QNAP wie auch in meinen eigenen Benchmarks gemessen.

Klar kann man den Benchmark immer hinterfragen, aber bei 'Messung machen mit 10G' dann Kabel umstecken und 1 Minute später 'Messung machen mit 1G' kann nicht so schrecklich viel schief gehen...

Natürlich darfst du dich jetzt wie ein dreijähriger im Sandkasten verhalten, dem man die Schippe weggenommen hat, du könntest aber auch eine technische Erklärung liefern.

Dito.
"So steht das in der Spezifikation" ist keine technische Erklärung für abweichendes Verhalten.

 

[Nagilum99]

Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie und die Praxis wurde sowohl hier im Review der QNAP wie auch in meinen eigenen Benchmarks gemessen.

Klar kann man den Benchmark immer hinterfragen, aber bei 'Messung machen mit 10G' dann Kabel umstecken und 1 Minute später 'Messung machen mit 1G' kann nicht so schrecklich viel schief gehen...


Dito.
"So steht das in der Spezifikation" ist keine technische Erklärung für abweichendes Verhalten.

War nicht so schwierig: Ich habe mir deinen Screenshot und den Artikel angeschaut.
Damit ist auch klar: Der Benchmark und die Daten sind völlig okay und es ist exakt so, wie ich oben beschrieb: Workload.
Wenn es sequentiell ist, kommt selbst eine einfache HDD gut mit, bei zufälligen Zugriffen natürlich nicht.
Da dort nicht eine sondern mehrere HDDs verbaut wurden, können die bei 10G natürlich auch weit über 250 MB/s durchblasen und die zufälligen Zugriffe besser ausbügeln. Da sie hier einen "Ordner mit 6,9 GB Daten" übertragen haben, der neben großen auch eine definierte Anzahl sehr kleiner Dateien enthält, bricht der wert selbstverständlich ein.
Bei auschließlicher Verwendung von SSDs sollte der Einbruch nahezu nicht existieren.

Wenn man dann, Ahnungslos, nur auf Zahlen schaut und sie eigenständig mit irgendwas verknüpft, kommt dann ggf. so ein Blödsinn raus wie: 2,5G kann nur 140 MB/s.

Das kann man schon so machen, aber dann ist es halt...

 

[Rickmer]

Da dort nicht eine sondern mehrere HDDs verbaut wurden, können die bei 10G natürlich auch weit über 250 MB/s durchblasen und die zufälligen Zugriffe besser ausbügeln. Da sie hier einen "Ordner mit 6,9 GB Daten" übertragen haben, der neben großen auch eine definierte Anzahl sehr kleiner Dateien enthält, bricht der wert selbstverständlich ein.

Falsch.
https://blog.storagecraft.com/raid-performance/

In einem Raid 5 mit 4 HDDs (wie hier getestet) ist die Write Performance des Raid identisch zur Write Performance einer einzelnden HDD.

Der Benchmark von dem ich einen Screenshot gemacht hatte war schreibend.

Wenn man dann, Ahnungslos, nur auf Zahlen schaut und sie eigenständig mit irgendwas verknüpft, kommt dann ggf. so ein Blödsinn raus wie: 2,5G kann nur 140 MB/s.

Erstens: Das habe ich nicht behauptet. Wie schon sagtest: Sowas ist alles Workload-Abhängig und ich habe einzig von der Workload in dem einzelnem Testscenario gesprochen.

Zweitens: Dann erklär mir doch mal wie exakt dasselbe Setup mit lediglich einer schnelleren Netzwerkverbindung dann von 140 auf 250 MB/s steigt. "Geht nicht" gibt's nicht, weil dir die Praxis wiederspricht.

 

[Nagilum99]

Falsch.
https://blog.storagecraft.com/raid-performance/

In einem Raid 5 mit 4 HDDs (wie hier getestet) ist die Write Performance des Raid identisch zur Write Performance einer einzelnden HDD.

lolwat?
Klar, weil die Daten erst durch die erste HDD müssen, damit sie auf den anderen 2 Daten-HDDs landen. Oder so.
Ich will den Bandwurmartikel gar nicht durchlesen, aber auf den ersten Blick sehe ich schon, dass sie das da nicht geschrieben haben.
Damit bin ich auch raus, das wird mir hier langsam esotherisch. Dein Fachgebiet ist scheinbar WaKü pimpen und DRAM Timings optimieren. Ich bleib lieber bei großem Spielzeug.
(Und wenn in unserem SAN das RAID nur die Schreibleistung einer einzelnen HDD hätte, wären wir ziemlich am Arsch.)

Zweitens: Dann erklär mir doch mal wie exakt dasselbe Setup mit lediglich einer schnelleren Netzwerkverbindung dann von 140 auf 250 MB/s steigt. "Geht nicht" gibt's nicht, weil dir die Praxis wiederspricht.

Habe ich doch oben geschrieben, wie oft denn noch?
Die großen Brocken können bei 10 G natürlich auch schneller durch, seuquentiell sollten aus 3 nutzbaren Datenträgern locker 5-600 MB/s kommen und damit den Schnitt massiv anheben.
Was du da siehst, ist der DURCHSCHNITT, kein Maximum. Dass da 250 Steht und das so schön auf 2,5G passt (tut es übrigens nicht wirklich) ist Zufall und der Zusammensetzung des Ordners geschuldet.

 

[mgutt]

ich habe reale Benchmarks

CrystalDiskMark ist ziemlich nutzlos um ein NAS zu testen. Das hier ist das Benchmark von meiner Disk1 (HDD):

Du testest da also eigentlich nur den Samba-Overhead und den RAM.

Da wäre eine automatisiche "Selbstheilung" toll. Die Theorie dahinter mit Prüfsummen ist mir grob klar. Ich hätte gerne einen NAS, der das von alleine macht und vielleicht in einem Log darauf hinweist.

Eigentlich macht das jede HDD schon von Haus aus so. Nennt sich ECC:

Und dank Reed-Solomon erfolgt auch von der HDD Firmware selbst eine Korrektur (falls möglich). Ein zusätzlicher ECC von ZFS/BTRFS erhöht aber natürlich noch mal zusätzlich die Sicherheit, da dieser auch Dinge "außerhalb" erfasst wie zB eine fehlerhafte Übertragung der Daten durch ein defektes Kabel oder Controller.

Ob man aber als Privatperson so ein Dateisystem braucht, ist meiner Ansicht nach fraglich. Es geht ja meist um Mediensammlungen. Da genügt eigentlich auch der Abgleich der unregelmäßige Abgleich der Hashsummen. Und wer saubere Backups macht, also 2 Kopien, der muss die Hashsummen nicht mal abspeichern, sondern kann dann im Problemfall einfach die Datei wiederherstellen, die am häufigsten vorkommt. Bei einem Unternehmen mit Datenbanken etc sieht die Sache natürlich anders aus. Da macht ZFS/BTRFS absolut Sinn.

Ergänzung (10. Februar 2021)

Die großen Brocken können bei 10 G natürlich auch schneller durch

Ich hätte jetzt durch die MTU erwartet, dass die Dateien immer in gleich große Teile zerlegt und übertragen wird. Meinst du nicht? Apropo MTU. Vielleicht war die ja bei 2.5G eine andere als bei 10G.

 

[Nagilum99]

Eigentlich macht das jede HDD schon von Haus aus so. Nennt sich ECC:

Das ist durchaus korrekt, dennnoch weisen Festplatten Bitfehlerraten aus, 1e+14 ist eine nicht unübliche Größenordnung. D.h. statistisch gesehen gibt es pro 11 TB Datenvolumen rund einen Bitfehler. Den sollte ZFS abfangen.
Da moderne NAS durchaus schonmal 50+ TB fassen können, sammelt es sich.
Gehen wir davon aus, dass jemand seine Videosammlung, Urlaubsfotos... wird diese gekippten Bits mit an Sicherheit grenzender Wahrscheinlichkeit niemand bemerken, weil lediglich ein Pixel minimal verändert wurde.
Blöder wäre es, wenn es wichtige Daten verändert.

Ergänzung (10. Februar 2021)

Ich hätte jetzt durch die MTU erwartet, dass die Dateien immer in gleich große Teile zerlegt und übertragen wird. Meinst du nicht? Apropo MTU. Vielleicht war die ja bei 2.5G eine andere als bei 10G.

Was hat die MTU damit zu tun?
Jumboframes werden stark überbewertet und sorgen viel zu oft für Ärger, daher wird das selten angefasst und wenn dann eher in getrennten Netzen für NFS/iSCSI...
Kurzum: Nein, meine ich nicht. Der Bandbreitenfaktor ist, was relevant ist - sofern die Systeme mit der Verarbeitung nachkommen. Du schiebst halt in gleicher Zeit das 2,5fache von 1G raus - oder das 4fache von 2,5G...
Mit den MTUs holst du erfahrungsgemäß vielleicht 10 % raus.

Ergänzung (10. Februar 2021)

Ach so, wer ein iX Plus oder Heise+ Abo hat (kann man ggf. auch über den Kiosk kaufen):
Kurz erklärt: Bitfehler bei Festplatten
Bitrot und ein wenig ZFS. Alt aber informativ.

 

[mgutt]

D.h. statistisch gesehen gibt es pro 11 TB Datenvolumen rund einen Bitfehler. Den sollte ZFS abfangen.

Was statistisch gesehen total im Widerspruch zu meinen Erfahrungen steht. Ich denke damit sind nur "Garantien" der Hersteller gemeint. Im realen Einsatz hatte ich bisher noch nie einen Bitrot (ich lasse die Hashsummen abgleichen). Und wir sprechen hier immerhin von >80TB, verteilt auf viele 12TB HDDs.

Ergänzung (10. Februar 2021)

Der Bandbreitenfaktor ist, was relevant ist - sofern die Systeme mit der Verarbeitung nachkommen. Du schiebst halt in gleicher Zeit das 2,5fache von 1G raus - oder das 4fache von 2,5G...

Kannst du das evtl detaillierter erklären? Also gerade warum die Bandbreite bei 2.5G so negative Auswirkungen bei unterschiedlich großen Dateien hat, aber eben nicht bei einer großen (weil da war ja die 2.5G Bandbreite ja voll ausgelastet).

 

[Nagilum99]

Was statistisch gesehen total im Widerspruch zu meinen Erfahrungen steht. Ich denke damit sind nur "Garantien" der Hersteller gemeint. Im realen Einsatz hatte ich bisher noch nie einen Bitrot (ich lasse die Hashsummen abgleichen). Und wir sprechen hier immerhin von >80TB, verteilt auf viele 12TB HDDs.

Ergänzung (10. Februar 2021)

Kannst du das evtl detaillierter erklären? Also gerade warum die Bandbreite bei 2.5G so negative Auswirkungen bei unterschiedlich großen Dateien hat, aber eben nicht bei einer großen (weil da war ja die 2.5G Bandbreite ja voll ausgelastet).

1. Das sind nunmal die Angaben und kein Hersteller gibt freiwillig viel weniger an, als er müsste. Dann würden ja alle eher "den" anderen Hersteller kaufen. Kein Fehler bei dir, kann 10 Fehler beim Nachbarn bedeuten. Auch das ist Statistik. Aber es gibt auch andere Serien die auf 15 hochgehen, IIRC.

2. Hat sie nicht, du hast den Kontext nur nicht verstanden. Das Problem sind die HDDs: Sie sind sequentiell (also da wo die Köpfe auf der Spur bleiben können) sehr schnell: 260+ MB/s sind durchaus drin. Bei 10G können sie potentiell Peaks von ~3x 260 MB/s (4x HDD RAID 5 -> n-1)über die Leitung blasen, was die Transferzeit des Ordners und damit die durchschnittliche Geschwindigkeit drastisch anhebt.
Für die Krümeldateien, wo die Köpfe sich abrackern müssen, benötigen sie wohl exakt gleich lange (hier ist die Bandbreite irrelevant).
RAID-Spezifika lassen wir hier mal außen vor, die sind da weitgehend irrelevant.

 

[lamda]

Eigentlich ganz gute hardware die mir genügen würde doch der Preis ist mir leider um den Faktor 3 zu hoch.

 

[Rickmer]

CrystalDiskMark ist ziemlich nutzlos um ein NAS zu testen.

Das war kein NAS, sondern eine SSD direkt eingebunden in eine Server 2019 VM (auf Hyper-V). Das dürfte eine einfache Netzwerkfreigabe gewesen sein.

Das ist durchaus korrekt, dennnoch weisen Festplatten Bitfehlerraten aus, 1e+14 ist eine nicht unübliche Größenordnung.

Im unteren Preisbereich ja, im gehobenen Segment nicht.
(Wenn man überhaupt von 'gehoben' reden kann wenn von allen CMR Platten auf dem Markt eine 14TB Enterprise HDD den besten Preis / TB hat)

Die Seagate IronWolf ab 8TB sowie alle IronWolf Pro HDDs sind mit 1 pro 10E15 ausgewiesen und Enterprise Platten wie Seagate Exos oder die aktuell preislich sehr attraktiven Toshiba Enterprise Capacity sowieso.

Ergänzung (10. Februar 2021)

Bei 10G können sie potentiell Peaks von ~3x 260 MB/s (4x HDD RAID 5 -> n-1)über die Leitung blasen

Eben nicht, mach mal deine Hausaufgaben zu write-Performance im Raid 5

 

[Nagilum99]

Eben nicht, mach mal deine Hausaufgaben zu write-Performance im Raid 5

Och Kindchen. Du kriegst deine write penalty und ich IO+Bandbreite. Dafür bin ich mit dir nun aber auch durch.
Du tust ja so als ob da in allen Belangen n=1 sei. Das würde jedes RAID5 in den Tod bringen.

 

[Dummsday]

Kannste das mal vorrechnen?

Ne, das alles aufzuzählen würde hier 2 Seiten verschlingen.

Wage ich zu bezweifeln, siehe unten



Aha - "nur" eine Oberfläche für Nutzer? Warum gibt es dann Malware die "nur" QNAP angreift und nicht jedes Debian? Und wie sieht es denn mit Schwachstellen in der MusicStation aus? Oder dem QNAP VPN?

Angreifen läßt sich nur was aktiviert ist und von außen sichtbar ist. Die MusicStation gehört auf einem beruflich genutzten System definitiv nicht dazu (wär aber auch kein Problem, wenn sie über einen virtuellen Switch und VLAN auf ein eigenes abgetrenntes internes LAN gelegt wird) . Als VPN bietet QNAP OpenVPN an, das ich nutze. Grundsätzlich ist das dieselbe Software die auch auf Debian genutzt wird. QNAP-Eigenentwicklungen bei der IT-Sicherheit nutze ich grundsätzlich nicht. Ergänzend hab ich eine PFsense Firewall als virtuelle Maschine installiert, die die QNAP eigene Firewall ersetzt. PFsense bietet QNAP kostenlos an und ist in drei Minuten installiert und aktiviert (nicht konfiguriert). VLANs nutze ich ebenfalls auf dem QNAP. Allein mit diesen Tools lässt sich schin ein brauchbares Sicherheitsniveau allein über das NAS realisieren, selbst dann wenn das Gerät Sicherheitslücken hat. Die IT-Infrastruktur drumherum erledigt dann den Rest, wenn man sie sinnvoll aufbaut.

Für den Katastrophenfall hab ich ein eigenes kleineres Backup-NAS

---

@Picard87 War eigtl als Übertreibung gemeint, wenn ich mir den Link anschaue, dann war es eine Untertreibung ... ;-)

https://www.qnap.com/de-de/security-advisories?ref=security_advisory_details

 

[Rickmer]

Och Kindchen. Du kriegst deine write penalty und ich IO+Bandbreite. Dafür bin ich mit dir nun aber auch durch.

Och Kindchen. Beschäftige dich wenigstens mit der Mathe hinter einem Raid bevor du noch mehr Unsinn von dir gibst.

Moment...

Ich will den Bandwurmartikel gar nicht durchlesen

Nevermind, du bist mit voller Absicht blöd. Okay, ich geb's auf, weil du hast ja selber geschrieben: du willst es nicht kapieren.

Aber falls du dich doch noch zur Selbstinformierung zusammenraffen kannst ist es hier viel knapper zusammengefasst:
https://theithollow.com/2012/03/21/understanding-raid-penalty/

 

[Dummsday]

Hui, okay da kann man die Kerne mit beschäftigen.
Die hätte ich eher auf einem Server abgelegt aber ob man im Server oder dem NAS für die Hardware zahlt macht eigentlich auch keinen Unterschied mehr.

Edit:
Wenn bei diesem NAS das ZFS schon den gesamten Ram verspachtelt hat sich das Thema VMs/Docker auch erledigt.

Mein NAS hat noch kein ZFS, leider :-(. Hab 32GB Ram und ne XEON CPU vom Typ Haswell (4*3,4 GHZ). Als VM Läuft Windows 10, Windows 7, Linux Mint und ne PFSense Firewall). Die aktuelle VM-Station auf der QNAP kann mittlerweile sogar Ram-Sharing der VMs.

Ergänzung (10. Februar 2021)

für welche Zielgruppe soll diese Gerät gut sein für diesen utopischen Preis? Privatanwender mit etwas Know-How bauen sich für ein Bruchteil was schnelleres zusammen und kleine und mittelständische Firmen basteln sich idR nichts selber zusammen

Die sind für mich als Zielgruppe (Ingenieurbüro) ideal . Keine Ahnung was an dem Preis utopisch sein soll. Im beruflichen Bereich bietet QNAP absolute Schleuderpreise..

 

[Picard87]

Zur CPU: Vermutlich Kosten & Entwicklungszeit. Dann wäre die Kiste nicht mit 1.400 € bepreist...
Der RAM soll auch keine fehlenden Kerne kompensieren - du hast das Konzept und/oder die Technik nicht verstanden.

Selbstverständlich nicht. Kompensieren bedeutete hier, dass ich zwar 128GB rein bauen kann, was toll klingt, diese aber nicht sinnvoll nutzen kann, da die CPU für eine oder mehrere VMs + Docker viel zu schwach ist.

 

[Dummsday]

Selbstverständlich nicht. Kompensieren bedeutete hier, dass ich zwar 128GB rein bauen kann, was toll klingt, diese aber nicht sinnvoll nutzen kann, da die CPU für eine oder mehrere VMs + Docker viel zu schwach ist.

QNAP will halt das du dann das nächstgrößere Modell kaufst. Kostet dann 1900.-

 

[Nagilum99]

Selbstverständlich nicht. Kompensieren bedeutete hier, dass ich zwar 128GB rein bauen kann, was toll klingt, diese aber nicht sinnvoll nutzen kann, da die CPU für eine oder mehrere VMs + Docker viel zu schwach ist.

Es ist offensichtlich nicht beabsichtigt, das NAS so zu verwenden.
Wie oben schon geschrieben wurde: RAM ist gut für ZFS, insbesondere mit deduplizierung. Nur weil da viel RAM rein geht, heißt es nicht dass jemand selbigen für CPU-inzensive VMs vorsieht.
Du bist damit schlichtweg nicht die Zielgruppe.

Ergänzung (10. Februar 2021)

QNAP will halt das du dann das nächstgrößere Modell kaufst. Kostet dann 1900.-

Wer Actros statt Sprinter will...

 

[Atkatla]

Falsch.
https://blog.storagecraft.com/raid-performance/
In einem Raid 5 mit 4 HDDs (wie hier getestet) ist die Write Performance des Raid identisch zur Write Performance einer einzelnden HDD.

Das ist falsch. Denn diese Aussage gilt nur teilweise und dann auch nur bei kleinen Schreiboperationen, wo sich die Parität eines Stripes ändert und daher erst die Lese-Operationen stattfinden müssen. Bei großen Schreiboperationen, wo der Stripe völlig neu geschrieben wird, können alle Platten parallel die Daten vom RAID-Controller schreiben.

Und es gibt eine weitere Ungenauigkeit im Blogeintrag: er behauptet, die Viertelung der Leistung sei wegen der zusätzlichen Schritte (wenn die Parität eines Stripes sich ändert): 1. Lesen der Daten, 2. Lesen der Parität, 3. Schreiben der Daten, 4. Schreiben der Parität. Da 1 und 2 sowie 3 und 4 auf unterschiedlichen Platten stattfinden, können sie jeweils zeitgleich durchgeführt werden und haben dann bei einem entsprechenden Controller keine Viertelung der Leistung zur Folge.

Geringere Schreibleistungen bei RAID5/6 hängen also davon ab, wie hoch der Änderungsanteil in Stripes ist sowie von der Leistung des RAID-Controllers bei Paritätsberechnungen. Von mechanischen Faktoren wie den Zugriffszeiten mal ganz zu schweigen (der RAID-Controller weiss ja nicht, wann bei den einzelnen Platten der entsprechende Sektor unter dem Lese-/Schreibkopf vorbeirauschen wird).

 

[janer77]

@Frank :

Ich frage mich immer wieder, wieso ihr für sowas eure Kapazitäten "verschwendet"?! Immer wieder diese auffälligen NAS-Tests mit der "weil wir QNAP und Synology heißen können wir uns solche Preise herausnehmen"-Hardware, die in dem Fall ECC auch noch als Besonderheit hinstellen. Das könnte man auch für die Hälfte anbieten und sich immer noch dumm und dusslig verdienen... Man braucht dafür nicht Intel mit so einem Pseudo-Xeon.