ZFS und SAN - Best Practices?

In den meisten Diskussionen zu ZFS wird empfohlen, das Hardware-RAID auszuschalten und ZFS direkt mit den Festplatten zu kommunizieren und das RAID auf dem Host (anstelle des RAID-Controllers) zu verwalten.

Dies ist auf einem Computer mit 2 bis 16 oder mehr lokalen Festplatten sinnvoll. Wie sieht es jedoch in einer Umgebung mit einem großen SAN aus?

Das Unternehmen, für das ich arbeite, verfügt beispielsweise über ein aus meiner Sicht bescheidenes SAN mit zwei vollen Festplatten-Racks, also etwa 400 Spindeln. Ich habe SAN-Regale gesehen, die viel dichter sind als unsere und SAN-Bereitstellungen viel größer als unsere.

Sind 100 Festplatten direkt großen ZFS-Servern ausgesetzt? 300 Scheiben? 3000 Scheiben? Ermöglichen die SAN-Verwaltungstools die automatisierte Verwaltung solcher Dinge?

FWIW Ich habe Erfahrung mit bis zu 92 Festplatten in einem einzelnen ZFS-Pool und bisher funktioniert es einwandfrei .

Aber wenn Sie wirklich über mehrere Hundert Platten sprechen, würde ich in Betracht ziehen , sie in eine kleine Anzahl von getrennten (aber immer noch großen) Pools zu unterteilen. Ich möchte nicht wissen, wie lange z. B. ein zpool scrubLaufwerk auf einem 3000-Platten-Pool ausgeführt wird (aber Sie möchten regelmäßig scrubben). Auch die Ausgabe von Befehlen wie zpool statuswäre bei einer so großen Anzahl von Platten unhandlich. Warum also alle Eier in einen Korb legen?

(Randnotiz zu Dedup : Beachten Sie, dass Dedup zwar auf Datensatzebene gesteuert werden kann, jedoch auf Poolebene Duplikate findet. Das heißt, Sie werden wahrscheinlich schlechtere Dedup-Ergebnisse erzielen, wenn Sie wie vorgeschlagen partitionieren. Andererseits werden Sie Sie benötigen viel mehr Speicher , um die Dedup-Hashes eines einzelnen Riesenpools zu speichern , die möglicherweise nicht in ARC + L2ARC passen, wenn der Pool zu groß ist. Wenn Sie also Dedup verwenden, ist die Menge des verfügbaren Speichers wahrscheinlich ein guter Indikator für die maximale praktische Poolgröße .)

Wir lassen unsere SANs das RAID verwalten. Warum sollten Sie Geld für all das batteriegepufferte NVRAM und diese dedizierten Prozessoren ausgeben und die Arbeit dann auf den Server verlagern, dessen CPUs ich nicht als RAID-Prüfsummen verwenden möchte?

Hier ist eine Website, die Sie möglicherweise besuchen möchten, um die Größe und Konfiguration des Pools (der Pools) auf die Wahrscheinlichkeit eines Datenverlusts hin zu überprüfen.
https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protection

Es ist eine alte Frage, aber sie ist heute nur relevant, wie es vor 7 Jahren war!

Um den ersten Teil der Frage zu beantworten, ist mir nicht bekannt, was wir ein "SAN" nennen würden, das die Raw-Festplatten jemals einem Server aussetzen würde, auf dem ZFS ausgeführt werden könnte. Ein SAN stellt per Definition nur Blockspeicher (Block Storage, LUNs) oder möglicherweise mit so etwas wie einem Filer / FS ein NFS oder CIFS dar. Es gibt einige "SANs", auf denen ZFS tatsächlich intern ausgeführt wird. Dies ist jedoch weitestgehend ausgeschlossen. Die Datenträger werden niemals einem Server ausgesetzt. Stattdessen stellt die "Filer" -Komponente des SAN den Servern Block- oder Netzwerkdateisysteme zur Verfügung.

Ein Gerät, das die Raw-Festplatten (über SAS oder weniger wahrscheinlich über FC) darstellt, ist ein DAS. Wenn Sie ZFS ausführen möchten, weisen Sie den RAID-Controller normalerweise an, die Datenträger als JBOD zu präsentieren.

Sollten Sie jedoch ZFS auf einer LUN verwenden, die von einem SAN bereitgestellt wird? Möglicherweise: ZFS im Vergleich zu beispielsweise EXT4 bietet einige zusätzliche Funktionen, z. B. Scrubs, die Prüfsummen überprüfen oder Snapshots ausführen. Ein Scrub kann wahrscheinlich nicht auf die gleiche Weise automatisch geheilt werden wie ein Festplatten-RAID, aber es kann Sie trotzdem auf Korruption hinweisen und so Bitrot verhindern. Die Snapshots, die Sie beispielsweise auf einem Linux-SAMBA-Dateiserver erstellen können, sind Ihren Möglichkeiten mit EXT weit überlegen. Diese können sogar in Windows als "Vorgängerversionen" verfügbar gemacht werden.

Wenn Sie ZFS keine redundanten Daten für die Arbeit zur Verfügung stellen (z. B. Spiegel, RAID-Z), verlieren Sie viele Vorteile der Verwendung. Die Anzahl der beteiligten Festplatten wird diese Tatsache nicht ändern. Ob dies wirklich wichtig ist, hängt jedoch von Ihrer Umgebung ab. Sie müssen feststellen, welche Speicherfunktionen Sie benötigen (eine möglicherweise arbeitsintensive Analyse), und dann nach der kostengünstigsten Lösung (die Sie sich leisten können) suchen, die Ihren Anforderungen entspricht. Dies kann bedeuten, dass ZFS überall zusammen mit spezialisierten Oracle-Speichergeräten verwendet wird (einige tun dies und haben viele Festplatten, die problemlos mit ZFS in Berührung kommen, und verwenden Oracle-Tools für die Verwaltung) einige hybride (in diesem Fall müssen Sie wahrscheinlich einige Tools und Prozesse selbst entwickeln, um die Umgebung zu verwalten). Don'