ZFS: Die Zukunft 12. November 2009 Constantin Gonzalez This presentation covers the OpenSolaris OS, a new part of the Solaris ecosystem. It is based on the work being done in the OpenSolaris community, where the next generation of Solaris is being built. This is the fruition of what was called “Project Indiana,” and is now the reference release for the OpenSolaris community. ZFS: Die Zukunft 12. November 2009 Constantin Gonzalez Principal Field Technologist Sun Microsystems GmbH

ZFS Architektur ZPL: ZFS POSIX Layer ZVOL: ZFS Volumes ZIL: ZFS Intent Log ZAP: ZFS Attribute Processor DMU: Data Management Unit DSL: Dataset & Snapshot Layer ARC: Adaptive Replacement Cache ZIO: ZFS I/O Pipeline VDEV: Virtual Devices LDI: Layered Driver Interface http://www.opensolaris.org/os/community/zfs/source/

Jetzt schon in ZFS Hybride Pools Log Devices (aka Slog, WriteZilla, Write-Cache) L2ARC (aka ReadZilla, Read-Cache) Am besten mit SSDs User/Group Quotas RAID-Z3: RAID-Z mit 3-facher Parität „Mind the gap“-Optimierung: RAID-Z schneller als Spiegel Parallel Device Open Zero-Copy I/O ...weitere nützliche Features

Hybride Pools ZFS Intent Log Zwischenspeicher für synchrones Schreiben Gute „Enterprise“ SSDs, gespiegelt Einige GB reichen L2ARC (Lese-Cache) Günstige, Lese-SSDs Genug GB für das “working set“ RAM groß genug für Metadaten Keine Redundanz nötig

Beispiel für hybriden ZFS Pool 4 Xeon 7350 CPUs (16 Cores) 32GB FB DDR2 ECC DRAM OpenSolaris mit ZFS Konfiguration A: Konfiguration B: 1x32G Flash ZIL “Platte” 1x80GB Flash L2ARC “Platte” 7x146GB 10.000 rpm SAS Platten 5x400GB 4200 RPM SATA Platten

Ergebnisse: Hybrider ZFS Pool Hybrider Storage Pool: (DRAM + Read SSD + Write SSD + 5x 4200 RPM SATA) Traditioneller Storage Pool (DRAM + 7x 10K RPM 2.5”) 4% 4.9x 3.2x 2x 11% Read IOPs Write IOPs Preis Stromverbrauch (Watt) Kapazität (TB) Gleiche Kosten, mehr Performance, weniger Verbrauch Je größer die Konfig, desto eher zahlt sie ihre Kosten zurück

User/Gruppen-Quotas Beispiel: # zfs set userquota@user1=5G tank/data # zfs set groupquota@staff=10G tank/staff/admins # zfs get userused@user1 tank/data NAME PROPERTY VALUE SOURCE tank/data userused@user1 5.13G local # zfs userspace tank TYPE NAME USED QUOTA POSIX USER ahrens 14M 1G POSIX USER lling 256M none POSIX GROUP staff 3.75G 32T SMB USER marks@sun 103M 3G „Deferred Enforcement“: 1 Transaktions-Gruppe darf über Quota liegen.

Infrastruktur- Baustein Demnächst in ZFS „wird gebraucht für...“ Block Pointer Rewrite Performance Besserer Scrub Infrastruktur- Baustein Neue Funktionalität De- Duplikation Ver- schlüs- selung Devices entfernen Neuer Block Allocator Pool Recovery Shadow Migration Sync Mode JIT Decompr. Decrypt Native iSCSI

Block-Pointer Rewrite Zieht atomar Blöcke um, passt alle Pointer an Muss alle Referenzen finden Muss auch mit De-Duplikation funktionieren Grundlegende Technologie in ZFS, erlaubt Devices entfernen, Online-Defragmentierung, Re-Komprimierung, Deduplikation alter Daten, etc. Copy-on-Write macht's möglich Ist aber sehr anspruchsvoll Subtile Probleme, Race-Conditions, schwer zu debuggen Muss perfekt werden!

Scrub-Verbesserungen Raw Scrub Unabhängig von komprimierten und verschlüsselten Blöcken Wichtig, damit man ohne Schlüssel ein Resilvering von Spiegeln oder RAID-Z durchführen kann Nutzt jetzt die Prefetch-Engine Wird von Block Pointer Rewrite mit übernommen

De-Duplikation Nur 1 Kopie von identischen Blöcken speichern 3 Teile: Auf Platte, im Speicher, in send/receive Funktioniert über Prüfsummen-Vergleich Referenz-Zähler für Blöcke Gleiche Checksummen, gleiche Daten? SHA256: 10-77 Wahrscheinlichkeit für zwei verschiedene Blöcke mit gleicher Prüfsumme 50 Größenordnungen weniger wahrscheinlich als ein unentdeckter ECC-Fehler! Block-Kontrolle ist daher optional, bei fletcher4- Prüfsummen aber dringend empfohlen

De-Duplikation: Beispiele #zfs set dedup=on tank #zfs set dedup=off tank/home #zfs set dedup=verify tank #zfs set dedup=fletcher4,verify tank De-Duplikation geschieht sofort (synchron) Nur Daten, die nach Aktivierung geschrieben werden Speicherplatz wird trotzdem den Usern, Quotas etc. zugeordnet Anwendungen: Virtualisierung, Backup, Mail, SW- Entwicklung Spart Plattenplatz, RAM und Netzwerk-Bandbreite

Schreiben Lesen Verschlüsselung Checksumme Verifizieren Einpacken Entschlüsseln Auspacken Einpacken Verschlüsseln Checksumme berechnen

Verschlüsselung: Ziele Verschlüsselung aller Daten und ZPL Metadaten (Name, Owner, etc.) Verschlüsselte auch ganze ZVOLs Erlaube sichere Löschung Ohne spezielle Hardware Nutzt sie aber wenn vorhanden Darf nicht mit Copy-on-Write kollidieren Sauber integriert mit ZFS Administration Klartext und verschlüsselte Datasets sollen gemischt werden können

Schlüssel-Management Zwei Schlüssel-Modell Äusserer Schlüssel, vom User angegeben Innerer Schlüssel für Daten, zufällig generiert, durch den äußeren Schlüssel geschützt Sicheres Löschen: Vergiss den Schlüssel! Der äußere Schlüssel kann gewechselt werden, ohne alle Daten neu verschlüsseln zu müssen.

ZFS Encryption: Administration Verschlüsselung kann nur bei Erzeugung eingeschaltet werden Schlüssel-Quelle und Algorithmus angeben SHA-256-Checksummen automatisch aktiviert Schlüssel-Quelle gilt für äußeren Schlüssel Anfangs zwei Algorithmen unterstützt: AES-128-CCM, AES-256-CCM (default) Beispiel: # zfs create -o encryption=on \ -o keysource=passphrase,prompt tank/fs

Neuer Block Allocator Der alte war sehr simpel „First fit“: Nimm die erste zusammenhängende Gruppe von Blöcken Schnell, wenn der Pool leer ist, aber dann... Neue Strategie: Erst „First fit“, dann „Best fit“ Erfordert mehr Daten in den Space Maps

Pool Recovery ZFS ist sehr robust, aber: Die Schreib-Reihenfolge ist wichtig! Wenn der Überblock geschrieben wurde, aber die Daten dazu nicht, dann ist der Pool korrupt! Manche (Consumer-, USB-) Platten: Schicken falsche Bestätigungen Können die Reihenfolge durcheinander bringen Sind daher anfällig für Pool-Korruption Tritt nicht bei Laptops, oder professionellen Systemen auf, umso mehr bei Heim-Servern Reparatur bisher sehr aufwändig

Pool Recovery: Die Lösung Repariert den Pool, auch wenn die Platten die Schreib-Reihenfolge durcheinander bringen Nutzt den Überblock-Ring, der noch alte Überblöcke enthält Freie Blöcke werden erst verzögert wirklich frei gegeben Man könnte sie ja doch noch brauchen... Pool korrupt? Dann auf die nächst-ältere Transaktions-Gruppe zurückrollen Bis der Pool wieder korrekt gelesen werden kann.

Shadow Migration Migration von Daten kann sehr lange dauern Manchmal Tage... Mit Shadow-Migration geht das in Minuten! Arbeitet als Proxy im VFS/vnode-System Daten, die noch nicht migriert wurden: werden vom alten NFS-Server gelesen, an den Client weitergereicht, und dann in das neue ZFS-Filesystem eingepflegt. Alles transparent für den Client Vorerst nur für NFS

Sync Mode NFS Standard verlangt: Daten müssen auf „stable Storage“ sein, wenn der COMMIT-Befehl beendet ist! Das ist nicht immer optimal Z.B. bei Installation, Restore, Benchmarks In Zukunft als Tunable konfigurierbar: Langsam+Standard-konform (wie heute), Reihenfolge strikt eingehalten, aber schnelles OK Schnell+gefährlich: OK kommt sofort, auch wenn die Daten noch nicht auf Platte sind.

Just-in-Time Dekompression/Decrypt Vorher: Daten wurden gelesen und gleich ausgepackt Ob sie benutzt wurden, oder auch nicht! Z.B.: Prefetch, Scrub, etc. Just-in-Time: Daten werden komprimiert/verschlüsselt gelassen Erst bei Benutzung dekomprimiert/entschlüsselt Spart Speicher und bringt Performance Vor allem beim Scrubben/Resilvering Erlaubt Resilvering/Scrub ohne Schlüssel

Noch ein paar Kleinigkeiten Dynamische LUN-Expansion Snapshot Holds/Unholds Verhindert versehentliches Löschen wichtiger Snapshots Schutz vor versehentlichem Multi-Mount Heartbeat-Protokoll auf der Platte Offline von ZIL Volumes (Slogs, Writezillas)

Mehr Infos: Jeff Bonwick, Bill Moore „ZFS: The Next Word“ In Google nach den Folien suchen Als Video auf SLX.sun.com: https://slx.sun.com/1179275620 ZFS Community auf opensolaris.org ARC Case Log arc.opensolaris.org

Vielen Dank! Constantin Gonzalez constantin@sun.com This presentation covers the OpenSolaris OS, a new part of the Solaris ecosystem. It is based on the work being done in the OpenSolaris community, where the next generation of Solaris is being built. This is the fruition of what was called “Project Indiana,” and is now the reference release for the OpenSolaris community. Vielen Dank! Constantin Gonzalez constantin@sun.com blogs.sun.com/constantin twitter.com/zalez