ZFS: Scrub mit ~85Mbit/s

Probleme mit Samba, NFS, FTP und Co.
Antworten
mrserious
Beiträge: 266
Registriert: 22.06.2013 12:12:03

ZFS: Scrub mit ~85Mbit/s

Beitrag von mrserious » 28.07.2017 09:58:19

Moin zusammen,

entschuldigt meine diversen ZFS-Thtreads. Ich versuche nur, Ordnung zu halten.

Momentan betreibe ich testweise einen Dateiserver mit ZFS (3 1TB-Festplatten (7200U/min)) mit mirror.
Diese Platten sind zusätzlich alle mit cryptsetup verschlüsselt.
Was mir auffällt: Der Scrub läuft im Schnitt mit nur 85Mbit/s. Das kommt mir doch arg langsam vor, denn es sind 16GB RAM vorhanden und der restliche Server besteht auch aus neuer, schneller Hardware.

Mach ich was falsch? Gibt's Optimierungs-Parameter, die ich übersehen hab?
Erstellt wurde der Pool folgendermaßen:

Code: Alles auswählen

zpool create data mirror /dev/mapper/hdd1 /dev/mapper/hdd2 /dev/mapper/hdd3

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von Tintom » 28.07.2017 10:58:30

Wie ist denn die CPU-Auslastung wenn du die Festplatten beschreibst?

mrserious
Beiträge: 266
Registriert: 22.06.2013 12:12:03

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von mrserious » 28.07.2017 11:47:22

Man sieht, dass er ein wenig rödelt, ist aber noch jede Menge Reserve da.

Hab grad' mal spaßeshalber ein paar Nullen in den Pool gelegt. Auch da ist die Performance nicht überragend, aber für meine Zwecke absolut akzeptabel. Witzigerweise geht's schneller als das scrubben.

Code: Alles auswählen

Server:/data# dd if=/dev/zero of=test.bla bs=1M count=10000
10000+0 Datensätze ein
10000+0 Datensätze aus
10485760000 Bytes (10 GB, 9,8 GiB) kopiert, 67,2756 s, 156 MB/s

BenutzerGa4gooPh

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von BenutzerGa4gooPh » 28.07.2017 12:55:16

mrserious hat geschrieben: ↑ zum Beitrag ↑
28.07.2017 11:47:22
Man sieht, dass er ein wenig rödelt, ist aber noch jede Menge Reserve da.
Beantwortet sehr ungenau oder nicht:
Tintom hat geschrieben: ↑ zum Beitrag ↑
28.07.2017 10:58:30
Wie ist denn die CPU-Auslastung wenn du die Festplatten beschreibst?
Sinnvolle Frage wegen:
mrserious hat geschrieben: ↑ zum Beitrag ↑
28.07.2017 09:58:19
Diese Platten sind zusätzlich alle mit cryptsetup verschlüsselt.
Zum sinnvollen Einsatz von ZFS:
mrserious hat geschrieben: ↑ zum Beitrag ↑
28.07.2017 09:58:19
Momentan betreibe ich testweise einen Dateiserver mit ZFS (3 1TB-Festplatten (7200U/min)) mit mirror.
Dir ist schon klar, dass ZFS auch Nachteile, vor allem bei unzweckmäßigem Einsatz (oder Testaufbau) hat:
Weiterhin ist ZFS ein relativ schnelles Dateisystem; aufgrund der integrierten RAID-Funktionen und End-To-End-Checksummen kommt es jedoch in der Geschwindigkeit auf älteren bzw. langsameren Systemen nicht an einfachere Dateisysteme heran, wobei die Performance von ZFS auch davon abhängig ist, welche RAID-Funktionalität genutzt wird und ob die einzelnen Platten unabhängig voneinander und gleichzeitig Daten transferieren können.
...
ZFS ist für sehr große Datenmengen ausgelegt, was durch die durchgängige Verwendung von 128-Bit-Zeigern erreicht wird. In der Praxis sind die Grenzen jedoch mit denen eines 64-Bit-Dateisystems vergleichbar.
...
ZFS wurde für den Server- und Rechenzentrumseinsatz konzipiert und sammelt dort seine Pluspunkte, daraus ergeben sich teilweise Nachteile beim Einsatz auf Arbeitsplatzrechnern und eingebetteten Systemen.

Die Verarbeitung der 128-Bit-Pointer (siehe Eigenschaften) ist vergleichsweise aufwändig, da sie nicht der Wortbreite aktueller CPUs entspricht, die typischerweise bei 32 Bit im Bereich Appliances und älterer Personal Computer sowie bei 64 Bit im Bereich aktueller Einzelplatzrechner und den meisten Servern liegt. Somit ist auf derartigen Systemen keine optimale Performance gegeben. Überhaupt bringt die 128-Bit-Auslegung nur dort Vorteile, wo ungewöhnlich große Datenmengen gespeichert werden sollen. Im SOHO-Bereich hingegen sind je nach Datenträgergröße 32- oder 64-Bit-basierte Dateisysteme bezüglich der ablegbaren Datenmengen ausreichend (vergl. Btrfs, Ext2, FAT32, HFS+, NTFS, UFS usw.), die üblicherweise schon unter Verwendung von 32-Bit-Datentypen Dateisysteme mit einer Kapazität von knapp 16 Terabyte (z. B. ext2) verwalten können, bei 64-Bit-Pointern natürlich weitaus mehr, beispielsweise ca. 8 Exabyte (8 Millionen Terabyte) bei XFS. Die 128-Bit-Auslegung bedeutet hier also nur zusätzlichen Rechen- und Zeitaufwand sowie einen etwas erhöhten Platzbedarf auf dem Medium.

ZFS nutzt Copy-On-Write und ein ZIL (ZFS Intent Log). ZFS kann so zu jeder Zeit auf ein konsistentes Dateisystem zurückgreifen. Sicherungen und Rücksicherungen von Blöcken, sowie Dateisystemprüfungen sind so bei Abbrüchen wie einem Stromausfall nicht nötig. Inkonsistenzen in Metadaten und Daten werden bei jedem Lesevorgang automatisch erkannt und bei redundanter Information soweit möglich automatisch korrigiert. Die Performance von solchen Dateisystemen nimmt allerdings ab ca. 80 % Belegung spürbar ab, wie bei allen anderen Filesystemen auch.
https://de.m.wikipedia.org/wiki/ZFS_(Dateisystem)

M. E. setzt Redhat xfs auf Servern ein. Wäre das für dich ein Kompromiss? Wikipedia darfst du jetzt selber lesen. :wink:

PS:
Zur Fehlereingrenzung könnte man testweise Verschluesselung, evtl. noch RAID weglassen. Oder nur mal zfs->ext4/xfs? Hast ja mehrere potentielle Fehlerquellen ...

mrserious
Beiträge: 266
Registriert: 22.06.2013 12:12:03

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von mrserious » 28.07.2017 15:44:46

Die Nachteile sind mir natürlich bewusst, in meinem Fall aber zu vernachlässigen.
Zum Einsatz kommt ein Xeon-Prozessor, dessen Ausleistung auch beim Schreiben der o.g. Beispieldaten bei 0.03 liegt. Ebenfalls waren nur knapp 3GB RAM belegt (von wie gesagt 16 verbauten).
Insofern: Klar, auf leistungsschwacher Hardware kann ZFS zum Problem werden, aber hier suche ich den Fehler grad' nicht bei der Hardware.

Ich benötigte unbedingt ein Dateisystem mit Checksumming und am besten auch mit den Raid-Methoden. Insofern ist XFS für mich keine Alternative.

jeff84
Beiträge: 324
Registriert: 15.07.2009 13:32:36

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von jeff84 » 28.07.2017 15:46:02

mrserious hat geschrieben: ↑ zum Beitrag ↑
28.07.2017 15:44:46
Ich benötigte unbedingt ein Dateisystem mit Checksumming und am besten auch mit den Raid-Methoden. Insofern ist XFS für mich keine Alternative.
btrfs hat Checksummen und kann RAID

mrserious
Beiträge: 266
Registriert: 22.06.2013 12:12:03

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von mrserious » 28.07.2017 16:03:10

Schön und gut, aber ZFS muss doch auch eine annehmbare Performance bringen können?

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von r4pt0r » 28.07.2017 18:28:43

mrserious hat geschrieben: ↑ zum Beitrag ↑
28.07.2017 09:58:19
Diese Platten sind zusätzlich alle mit cryptsetup verschlüsselt.
Für optimale performance und datenintegrität gehört ZFS ohne zusätzlichen Layer direkt auf die Platte. ZFS native encryption ist in entwicklung, dürfte noch dieses jahr verfügbar sein und wird auch nachträglich aktivierbar sein - ggf überträgt man eben all Daten per zfs send|receive in einen neuen pool damit alles verschlüsselt ist.

Scrubbing läuft als sehr niedrig priorisierter Hintergrundjob - jegliche anderweitige I/O hat Vorrang. Zudem ist die berechnung der Geschwindigkeit etwas eigenwillig - währrend dem sammeln der Metadaten in den ersten paar sekunden/minuten sind wenige Mbit/s normal. Bei frischen (vor allem sehr großen) pools die fast komplett leer sind ist die ausgegebene Geschwindigkeit auch extrem niedrig - der scrub beendet aber schon nach kurzer zeit wie zu erwarten.

Setze den pool ohne zusätzliche softwarelayer (crypt, dm-raid usw) unterhalb von ZFS neu auf, pack ein paar GB daten drauf und lass dann einen scrub vollständig durch laufen. Mit halbwegs aktueller SATA3-Hardware sollten je nach last >50M/sec für ein mirror-setup normal sein - begrenzender Faktor ist hier meistens der Controller, speziell wenn ein onboard-controller verwendet wird.

schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von schwedenmann » 28.07.2017 18:37:36

Hallo

Hier mal ein benchmark für zfs, btrfs und ext4

http://www.phoronix.com/scan.php?page=a ... -zfs&num=1

mfg
schwedenmann

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von r4pt0r » 28.07.2017 18:45:03

schwedenmann hat geschrieben: ↑ zum Beitrag ↑
28.07.2017 18:37:36
Hallo

Hier mal ein benchmark für zfs, btrfs und ext4

http://www.phoronix.com/scan.php?page=a ... -zfs&num=1

mfg
schwedenmann
Seit Januar 2016 hat sich so einiges getan - kürzlich kam z.b. auch compressed ARC dazu, was einen ziemlichen Performanceschub gibt.

Zudem wird in dem Test die Poolkonfiguration nirgends genannt - da es sich um einzelne SSDs handelt gab es vermutlich keinerlei mirroring - und genau hier holt ZFS erst richtig performance indem möglichst alle provider für i/o genutzt werden.
Als grober Richtwert sind die Benchmarks von phoronix aber völlig OK - auch wenn manche Tests eher Fragwürdig sind in bezug auf Filesystem-Performance...

mrserious
Beiträge: 266
Registriert: 22.06.2013 12:12:03

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von mrserious » 28.07.2017 18:57:36

Ja, die Scrub-Geschwindigkeit (oder zumindest deren Anzeige) variieren in der Tat ziemlich stark. Da stimmt die Beschreibung auf jeden Fall ;-)
Ich könnte die Verschlüsselung jetzt rausnehmen und mal testen. Das Problem ist nur: Auf meinen Produktivsystemen bin ich auf Verschlüsselung unbedingt angewiesen. Da ist dann die Frage, ob ich ein so neues Feature wie ZFS-eigene Verschlüsselung nutzen will, oder lieber mein altbewährtes cryptsetup einsetze, das bis dato nie Probleme gemacht hat.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von r4pt0r » 28.07.2017 23:31:28

mrserious hat geschrieben: ↑ zum Beitrag ↑
28.07.2017 18:57:36
ob ich ein so neues Feature wie ZFS-eigene Verschlüsselung nutzen will, oder lieber mein altbewährtes cryptsetup einsetze, das bis dato nie Probleme gemacht hat.
Bei OpenZFS stammt der großteil der Entwickler aus den Reihen von Illumos (bzw auch einige ex-Sun Mitarbeiter) und FreeBSD - beide OS sind auch die Referenzimplementierungen für ZFS. In beiden Lagern wird Codequalität sehr groß geschrieben und alles was in master landet muss absolut production-ready und production-safe sein; die Ansprüche sind hier weit mehr in Richtung professionelle/enterprise-Nutzung ausgerichtet. Halbgare und völlig verbugte releases wie bei vielen Linux-projekten leider üblich gibt es dort nicht. Wenn native encryption in OpenZFS-master landet (nicht als "experimental") ist es auch nutzbar und funktioniert.

Ich würde es eher kritisch sehen, einen völlig eigenen layer unterhalb eines Dateisystems zu nutzen, das darauf ausgelegt ist direkt auf die Hardware zugriff zu haben - viele Mechanismen von ZFS sind exakt auf diese Annahme hin entwickelt und optimiert.

Zudem: mit cryptsetup muss eine zusätzliche Abstraktionsschicht verwaltet werden - anstatt alles was mit dem Speicherpool und Dateisystem zu tun hat sauber und aufeinander abgestimmt direkt in ZFS zu verwalten.
Verschlüsselung wird wie Kompression oder Deduplizierung einfach per flag aktiviert und arbeitet dann auch sauber mit snapshots, pool-replikation und Backups via send|receive. Mit crytsetup wäre zur Laufzeit sowieso alles entschlüsselt - ist auf Servern also sowieso sinnbefreit - und verlässt das System beim Backup auch unverschlüsselt. Mit per-dataset encryption kann die Entschlüsselung z.B. auch nur nach Bedarf geschehen bzw beim Backup per snapshot/send|receive verlassen auch nur verschlüsselte Blöcke das System.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von scientific » 29.07.2017 11:14:35

Abgesehen davon... cryptsetup scheint auf SSDs sowieso sinnbefreit.
Fürs Wearleveling und insbesondere für trim benötigt eine SSD freie Bereiche auf der Platte. Mit cryptsetup ist die ganze Platte aber als belegt markiert. Hab man freie Bereicje, landen Daten in unverschlüsselten Bereichen (auch in jenen, die für den User gar nicht zugänglich von der Firmware verwaltete fürs Wearleveling verwendete).

Bin zwar kein Experte, aber soviel konnte ich mir zusammenstöpseln, dass SSD und Festplattenverschlüsselung eher Schlangenöl als einer sicheren Lösung gleicht. Ganz im Gegentum zur Vollverschlüsselung auf HDDs!
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

DeletedUserReAsG

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von DeletedUserReAsG » 29.07.2017 11:19:59

OT, sorry:
Mit cryptsetup ist die ganze Platte aber als belegt markiert. Hab man freie Bereicje, landen Daten in unverschlüsselten Bereichen (auch in jenen, die für den User gar nicht zugänglich von der Firmware verwaltete fürs Wearleveling verwendete).
Dies ist unzutreffend. Man kann eine Partition erstellen, die den Datenträger nicht ausfüllt, ergo einen freien Bereich lassen. Verschlüsselt man die Partition und das Laufwerk entscheidet, den freien Bereich für’s Wearleveling zu nutzen, ist das auf OS-Seite ziemlich egal – die Daten werden trotzdem nur verschlüsselt an den Controller gesendet.

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von smutbert » 29.07.2017 13:14:49

und auch das Durchreichen von discard/trim durch die Verschlüsselungsschicht erleichtert einen Angriff auf die Verschlüsselung nur insofern, als für den Angreifer erkennbar ist wo verschlüsselte Daten liegen und welche Bereiche (momentan) ungenutzt sind, weil die wegen trim/discard nur Nullen liefern.
(Ohne trim/discard wären in freien Bereichen optimalerweise von verschlüsselten Daten ununterscheidbare Zufallsdaten oder eben veraltete verschlüsselte Daten.)
Zuletzt geändert von smutbert am 30.07.2017 09:40:29, insgesamt 1-mal geändert.

mrserious
Beiträge: 266
Registriert: 22.06.2013 12:12:03

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von mrserious » 30.07.2017 09:01:11

Wie ist das überhaupt mit trim und ZoL?
Wird das bald endlich mal implementiert? Ist kein Drama, normalerweise nutze ich ZFS nur auf Festplatten. Kann mir aber auch Szenarien vorstellen, wo ich das auf SSDs benutzen möchte...

BenutzerGa4gooPh

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von BenutzerGa4gooPh » 30.07.2017 13:16:59

Da ZFS erst bei grösseren Datenmengen Vorteile bringt und derzeit SSD recht beschränkt sind, ist das wohl nicht so wichtig.

Ich hatte PFSense (Grundlage FreeBSD) mit ZFS auf SSD: Massenspeicherperformance egal, sicher booten nach Stromausfall ohne USV nicht. Mit FreeBSD funktioniert trim auf SSD. Jedoch nicht für Swap - zumindest nicht Anfang 2017 hingekriegt. (Hatte Swap wegen 4GB Ram eh nicht oder unbemerkt selten gebraucht.)

Zu Linux/ZoL/trim:
There is a pull request for ZFS On Linux which implements FreeBSD's (Sep 2012) ZFS TRIM support.
http://open-zfs.org/wiki/Features

Vielleicht solltest du ZFS gemeinsam mit xBSD nutzen?!

Ob Trim bei neuen SSDs sooo wichtig ist? Die Experten streiten sich. Würde mich da vorrangig auf Herstelleraussagen zum konkreten Produkt mit konkretem OS verlassen. Den H. kann man vor SSD-Kauf sicher mal anfragen. :wink:

mrserious
Beiträge: 266
Registriert: 22.06.2013 12:12:03

Re: ZFS: Scrub mit ~85Mbit/s

Beitrag von mrserious » 30.07.2017 14:19:17

Bin kein großer E-Techniker, aber nach allem was ich so lese ist TRIM bei SSDs ja schon sinnvoll.

Ja, auf BSD werde ich das auf alle Fälle zumindest mal testen.
Leider kann ich halt nicht kurz mal die betreffenden Server bei Kunden auf BSD umstellen...
Klar, neue Dateiserver kann ich in Zukunft direkt so aufsetzen, bloß gibt's eben einen großen Bestand an Systemen, die jetzt schon laufen.

Achso und mir geht's garnicht so sehr um große Dateiserver.
Teilweise haben die nur 1TB Speicher. Aber: Das Checksumming ist mir sehr wichtig. Vor allem, wenn ich z.B. mittels Mirror beschädigte Dateien dann durch ZFS wiederherstellen lassen kann.
Und insofern hat ZFS auch auf diesen "kleinen" Speichern deutliche Vorteile für mich. Zumindest ggü. z.B. ext4.

Antworten