Ich habe einen Zpool mit 24 Laufwerken, der aus 3 RAIDZ1-Vdevs besteht, auf denen 8 Seagate Exos X18-Laufwerke mit 16 TB pro Vdev laufen. Dies ist ein Supermicro-MB mit einem 64-Core (128 Threads) AMD Threadripper Pro und 256 GB ECC RAM.
Die Systemauslastung während der Scrub-Vorgänge zeigt, dass höchstens zwei CPUs gleichzeitig genutzt werden und die gesamte Scrub-Dauer dürfte fünf bis sieben Tage betragen.
Gibt es eine Möglichkeit, alle CPU-Kerne parallel am Scrub arbeiten zu lassen, um es zu beschleunigen?
Antwort1
Höchstwahrscheinlich ist die CPU nicht der limitierende Faktor für die Leistung. Spindeln mit 7200 U/min erreichen etwa 60 bis 70 zufällige IOPS. Selbst 24 Festplatten lassen nicht viel freie Leistung für eine Integritätsprüfung mit niedrigerer Priorität übrig.
Planen Sie für die aktuelle Leistung vielleicht eine Bereinigung pro Woche ein. Wenn Ihr Wiederherstellungspunktziel eine nächtliche Sicherung ist, wird die Wiederherstellungsquelle nicht vollständig bereinigt worden sein. Vielleicht ein Snapshot. Das könnte für Sie akzeptabel sein.
Erwägen Sie, Backups an Scrubs auszurichten. Wenn Sie jede Woche ein vollständiges Backup erstellen und zu diesem Zeitpunkt ein Scrub starten, könnte es vor dem vollständigen Backup der nächsten Woche abgeschlossen sein. Dies gibt zusätzliche Sicherheit für die Integrität des Arrays und damit auch der Backups. Dies ist jedoch nicht viel Zeit, um ein Backup mit einer guten Integritätsprüfung des Dateisystems zu haben. Erwägen Sie, mehrere vollständige Backups griffbereit zu halten. Wie nützlich viele Tage alte Archive für Ihre Wiederherstellungsziele sind, bleibt Ihnen überlassen, aber zumindest das zugehörige Scrub sollte abgeschlossen sein.
Antwort2
Es sieht so aus, als ob derzeit an der Parallelisierung von Festplatten-Lese-/Schreibvorgängen für ZFS gearbeitet wird, die Arbeit ist jedoch noch nicht testbereit.
Parameter und ein bisschen Mathematik zur Steuerung der Antworten:
Kapazität pro Laufwerk: 16.000.000.000.000 Bytes (nicht 16 TB).
Dauerhaftes Lesen/Schreiben: 270 MB/s (258 MiB/s).
Mittlere Betriebsdauer zwischen Ausfällen: 285 Jahre.
Nicht korrigierbare Sektorlesefehler pro gelesenem Bit: 1 Bitfehler pro 116.415 TB gelesener Daten.
Zufälliges Lesen 4K QD16 QCD: 170 IOPS.
Zufälliges Schreiben 4K QD16 QCD: 550 IOPS.
Jedes RAIDZ1-vdev mit 8 Laufwerken ist mit einem 8-Kanal-PCIe-3.0x-HBA verbunden, der einen dauerhaften Durchsatz von 512 MB/s pro angeschlossenem Laufwerk unterstützt.
Der HBA ist an einen PCI4.0 x16-Steckplatz auf einem 128-Lane-Motherboard angeschlossen.
Im Parallelbetrieb unterstützt das System ein vollständiges Lesen aller 24 16-TB-Laufwerke in 22 Stunden.
Ich gehe davon aus, dass die Bereinigung in weniger als 24 Stunden abgeschlossen sein sollte. Der Engpass ist daher die CPU-Auslastung für die Prüfsummenüberprüfung. Angesichts der Verfügbarkeit von 5 Rechen-Threads/Laufwerk (dies ist ein System mit 128 Threads/24 Laufwerken) sollte die Parallelisierung der Prüfsummen das Engpassproblem lösen.
Pro Zuverlässigkeit:
Die stochastische Theorie sagt voraus, dass ein Laufwerksausfall unwahrscheinlich ist, wenn man die MTBF des Herstellers von 285 Jahren und ein Konfidenzintervall von sechs Standardabweichungen annimmt. Trotzdem habe ich 4 Laufwerke für die Fehlerkorrektur und Notfallwiederherstellung eingesetzt.
Bitrot (nicht behebbare Sektorlesefehler pro gelesenem Bit) ist ein gesondertes Problem, weshalb ich mir über Scrub-Operationen Sorgen mache. Die erwartete Fehlerrate beträgt 1 Bitfehler pro 116.415 TB gelesener Daten. Das bedeutet, dass alle 14 Jahre ein Bitlesefehler auftritt, IFF kontinuierliche Lesevorgänge bei vollem Durchsatz von 270 MB/s werden 14 Jahre lang rund um die Uhr aufrechterhalten.
Diese Maschine ist Teil eines Hot-Failover-Clusters mit 1.024 Knoten und 1 Petabyte.