Ulrich Gräf Senior SE / OS Ambassador Platform Technology ...

ZFS 

Ulrich Gräf 

Senior SE / OS Ambassador 

Platform Technology 

- OpenSolaris, Solaris, Performance - 

Sun Microsystems Deutschland GmbH 

1

ZFS – Eine neue Generation 

• Daten-Integrität 

> Volume Manager ist integriert 

> Alle Blöcke mit Prüfsummen gesichert 

• Kapazität ist zukunftssicher 

> 128 Bit Filesystem 

> Alle Parameter automatisch anpassend 

• Einfachste Administration 

> Ein Filesystem mit einem Kommando 

• Performance durch Transaktionen 

Sun Confidential: Internal Only 2

Volmgr. + FS / ZFS: 

Posix-Interface: 

UFS: 

Bit-Optimierung 

Abstraktion 

Hiding 

Volume 

Filesystem: 

FS 

VM 

... 

File 

ZFS: 

Dir 

Dir 

Dir 

File 

File File 

Dir 

File 

File 

ZPL 

DMU 

SPA 

... 

Admin-Optimierung 

Prüfsummen 

Transaktionen 

Dynamic Striping 

Kompression 

Self-Healing 

HW-Optimierung 


Existierende Filesysteme 

• Datenkorruption ist möglich 

– Prüflesen direkt nach Schreiben (in Platten Firmware) 

– Volume Manager kennt nicht die Struktur der Daten 

=> Schreib-Optimierung unmöglich 

– Filesystem kennt nicht den Spiegel / das physikalische Layout 

=> Zugriff zu intaktem Spiegel nur manuell 

• Hoher Administrationsaufwand 

– Ein Filesystem erfordert (nacheinander!): 

– Partitionieren 

– Volume erzeugen (Wartezeit) 

– Filesystem erzeugen (Wartezeit) 

– vfstab Eintrag 

– dfstab Eintrag 

– grow/shrink ist zeitaufwendig 


Ziel der ZFS Entwicklung 

“End the Suffering” 

• Data Management 

–Soll einfach sein 

–Mächtige Kommandos haben 

–Ohne lange Wartezeiten oder Befehlsketten 

–Daten sollen inhärent sicher sein 


ZFS – wie Entwickeln? 

Es gibt keinen Weg vom jetzigen Modell: Volume Manager + 

Filesystem 

• 20 – 40 Jahre alte Annahmen stimmen nicht mehr, wie z.B. 

> Prüfsummen sind zu teuer (nicht mehr bei 64 Bit / >>1 Ghz ) 

> Sparsame Metadaten (heute: Geschwindigkeit wichtiger) 

• Volume Manager sind aus der Not geboren 

> Flexiblere Verwaltung von Daten 

– Concat / Stripe / Mirror / Raid-5, Feingranulare Partitionierung 

> Aber: 

– Verhindern Optimierungen im Filesystem 

– Keine Integrität 

Diese Design-Entscheidungen enden in einer Sackgasse 

=> Neuentwicklung 


ZFS Design Prinzipien 

• Pooled Storage 

> Filesystem auf mehreren Disks 

> Hierarchische Aufteilung 

> Vereinfachung der Administration durch Vererbung 

• End-to-end Daten-Integrität 

> Prüfsummen auf jedem Block (heute machbar) 

> Automatische Korrektur durch Zugriff auf Spiegel / Raid-5 aus 

dem Filesystem 

• Transaktionen für jede Veränderung im Filesystem 

> fsck niemals notwendig 

> Jederzeit Konsistenzprüfung möglich (online!) 

> Erhöht die Schreib-Performance 


ZFS – Design Paradigmen 

• Elemente 

> Plattenpools 

> Volume Manager 

> Große Filesysteme 

> Transaktionen auf der Platte 

> Prüfsummen 

> Self-Healing 

> Adminstrative Vereinfachung durch Vererbung 

• Alles ist bisher schon mal dagewesen ... 

Allerdings: nicht in dieser Kombination! 


Warum gibt es Volumes (LUNs)? 

Vorher: 

Filesystem auf 

einer Platte 

oder Slice 

FS 

1G 

Disk 

• Kunden wollten kleinere und größere Filesysteme 

> Es erschien schwer die Filesysteme zu ändern 

> Man ging den (vermeintlich) leichteren Weg: Volume Manager 

• Probleme: 

> Filesystem kann nicht optimieren (parallel lesen/schreiben) 

> Filesystem kann den Spiegel nicht lesen 

> Volume darf Schreibreihenfolge nicht optimieren (Integrität) 

FS 

Volume 

(2G concat) 

Lower 

1G 

Upper 

1G 

Volume 

(2G stripe) 

Even 

1G 

FS FS 

Odd 

1G 

Volume 

(1G mirror) 

Left 

1G 

Right 

1G 


FS/Volume Modell vs. ZFS 

Traditionelle Volumes 

• Abstraktion: virtuelle Disk (fest) 

• Volume für jedes Filesystem 

• Grow/shrink nur koordiniert 

• Bandbreite / IOs aufgeteilt 

• Fragmentierung des freien Platzes 

FS 

Volume 

FS 

Volume 

ZFS Pooled Storage 

• Abstraktion: Datei (variabel) 

• Keine feste Platzeinteilung 

• Grow/shrink via Schreiben/Löschen 

• Volle Bandbreite / IOs verfügbar 

• Freier Platz wird geshart 

FS ZFS ZFS ZFS 

Volume 

Storage Pool 


FS/Volume Model vs. ZFS 

FS/Volume I/O Stack 

Block Device Interface 

• Schreib-Reihenfolge erzeugt 

quasi-Integrität 

• Stromausfall: Metadaten 

konsistent mittels fsck 

• Journaling 

(nur Metadaten) 

Block Device Interface 

• Muß so schreiben wie es vom 

FS kommt 

• Stromausfall: ggf. Spiegel 

ungleich 

• Langsam, da synchron 

FS 

Volume 

ZFS I/O Stack 

Object-basierte Transaktionen 

• Daten-Änderungen => 

Transaktionen 

• All-or-nothing! 

Transaction Group Commit 

• Daten-Änderung und zugehörige 

Metadaten => 

Transaktions-Gruppen 

• Commit mittels COW 

Transaction Group Batch I/O 

• Zusammenfassung + 

Optimierung 

• Stromausfall -> alter Zustand 

• Platten werden ausgenutzt 

ZFS 

DMU 

SPA 


ZFS Daten Integrität 

• Copy-On-Write 

> Daten werden niemals überschrieben (= Rücksetzen ist möglich) 

> Neuer Zustand wird in freien Blöcken vorbereitet 

• Transaktionen (ausschließlich) 

> Neue uberblock-Version -> neuer Zustand 

(128 zyklisch benutzte uberblocks, 4 Kopien in Header und Trailer) 

> Transaktionen umfassen auch die Daten im FS 

> Journaling nicht notwendig! 

• Prüfsummen auf jedem Block des Filesystems 

> Daten und Metadaten 

> Uberblock via Seriennummer und CRC 

> Filesystem Header 


Copy-On-Write Transaktionen 

1. Konsistenter Zustand 2. Dateien schreiben 

3. Zufügen Metadaten 

4. Schreiben uberblock (= Commit) 


ZFS Snapshot: 

• Verweis im uberblock zeigt auf Snapshot-Zustand 

• + Aufpassen beim Wegwerfen von Blöcken 

> used und referenced Blöcke 

Snapshot root 

Live root 


End-to-End Daten Integrität 

Disk Block Prüfsummen 

• Prüfsummen bei Datenblock 

• Auf Disks meist kurz (Fehler unentdeckt) 

• Einige Disk Fehler bleiben unentdeckt 

Data 

Checksum 

Data 

Checksum 

Nur Fehler auf Medium erkennbar 

✔ Bit rot 

✗ Phantom writes 

✗ Misdirected reads and writes 

✗ DMA parity errors 

✗ Driver bugs 

✗ Accidental overwrite 

ZFS Daten Integrität 

• Prüfsumme bei Adresse 

• Fehler auf beiden Spiegeln: unwahrscheinlich 

• Storage Pool ist ein 

validierener Baum 

Address 

Data Data 

ZFS validiert alle Blöcke 

✔ Bit rot 

✔ Phantom writes 

✔ Misdirected reads and writes 

✔ DMA parity errors 

✔ Driver bugs 

✔ Accidental overwrite 

Address 

Checksum Checksum 

Address 

Address 

Checksum Checksum 


Traditionelles Volume/FS Modell 

1. read liefert defekten Block 2. Falsche Metadaten: 

Filesystem hat Probleme, 

Absturz OS möglich 

Application 

FS 

xxVM mirror 

Application 

FS 

xxVM mirror 

3. Falsche Daten: 

Applikation bekommt Probleme 

oder rechnet falsch 

(ggf. unbemerkt!!!) 

Application 

FS 

xxVM mirror 


Self-Healing in ZFS 

1. read liefert defekten Block 2. ZFS berechnet Prüfsumme; 

da diese falsch ist, 

wird der Spiegel gelesen 

Application 

ZFS mirror 

(Metadaten sind also korrekt) 

Application 

ZFS mirror 

3. ZFS liefert korrekte Daten an 

die Applikation; 

UND korrigiert defekten Block! 

Application 

ZFS mirror 


Transaktionen + Self Healing vs. fsck 

Traditionell: fsck 

> Filesystem Code verläßt sich auf die Inhalte der Metadaten 

> Online Prüfung der Metadaten zu teuer (Prüfsumme fehlt) 

> Daher mount erst dann, wenn fsck ok ist 

(sonst Crash durch “system panic”) 

> Weiterhin: 

– Annahme: FS geht während Betrieb nicht kaputt (heute noch gültig?) 

– Online-Check nicht möglich! 

(Synchronisation ist im FS Code und Disk-Layout nicht vorgesehen) 

ZFS: Transaktionen 

> Erkennt online defekte Daten und Metadaten 

> Online check möglich (zpool scrub) 

> fsck (~= zpool scrub) vor mount unnötig 


Traditionell: RAID-4 and RAID-5 

• Daten-Blöcke + Parity Block (hier: 4+1) 

^ ^ ^ ^ = 0 

• Partial Stripe Writes (zB. bei Stromausfall) 

^ ^ ^ ^ 0 

– Daten des Stripe sind inkonsistent (write hole): 

– Batteriegepufferter und gespiegelter Cache notwendig! 

– Random writes: aufwendiger read-modify-write Zyklus 

• Stille Datenkorruption nur teilweise erkennbar 

– 8 Bit Prüfsumme der Platte -> nur 255 von 256 Fehlern erkennbar 


ZFS: RAID-Z 

• wie RAID-5, mit 

> Dynamische Größe des Stripe 

(4+1, wenn wenig Daten dann vielleicht 2+1) 

> Dynamische Block-Größe 

> Immer full-stripe write (kein read-modify-write): Performance 

(read-modify-write macht herkömmliches Raid-5 langsam) 

> Copy-On-Write commitet immer ganze Raid-Z Zeile 

– Raid-5 write hole entfällt 

– RAID-Z braucht keinen Cache mit Batterie 

• Datenkorruption wird wie bei ZFS mirror erkannt 

• Keine spezielle HW notwendig: “ZFS loves cheap disks” 

> Siehe Sun Fire X 4500 mit 24 TB disks und ZFS auf 4 Rack-Units 

• raidz-2: (seit 11/06) 2 Platten können ausfallen 


Disk Scrubbing 

• Alle Daten werden gelesen und ggf. korrigiert 

> mirror: alle Spiegel-Seiten 

> raidz: alle Daten und Parity-Blöcke 

> (raidz2 für doppelte Redundanz in Vorbereitung, -> OpenSolaris) 

• Daten Integrität erhalten für lange unbenutzte Daten 

> Wird auch für Wiederherstellung von Spiegeln benutzt 

(“re-silvering”) 


ZFS Skalierbarkeit 

• Immense Kapazität (128-bit) 

> Moore's Law: Bit 65 bis 2020 notwendig 

> Zetabyte = 70-bit (ISO Vorsilbe für 1 Milliarde TB) 

– tera = 10 12 ≈ 2 40 

heutige Disks 

– peta = 10 15 ≈ 2 50 

kleine Unternehmen 

– exa = 10 18 ≈ 2 60 

große Unternehmen 

– zeta = 10 21 ≈ 2 70 

größte ISO Vorsilbe 

– ??? = 10 36 ≈ 2 128 max Größe eines ZFS 

> Max Filegröße 2 63 -1 durch Posix API limitiert, bei Bedarf anpassbar 

• Metadaten: dynamisch, automatisch anpassend 

• Einstellungen: online durch Attribute 

• Parallele Nutzung aller Basis-Disks 


ZFS Performance 

• Copy-on-write Design 

> Geschriebene Daten werden neu allokiert 

– sonst sind Transaktionen nicht rücksetzbar 

> Viele kleine Random writes => wenige größere sequential writes 

• Multiple Blockgrößen, pipelined IO 

> 512 Byte ... 128 Kbyte Blöcke 

> Automatische Anpassung nach Datenaufkommen 

> Details: 

– Intelligente Algorithmen (slab allocator, gang chaining) 

– Scoreboard Pipeline (24 Stufen) mit I/O Abhängigkeits-Analyse 

– Parallelisierung über Disks 

– Priority, deadline scheduling, out-of-order issue, sorting, aggregation 

– Dynamic striping, multi-user Prefetch pro Datei 


Dynamic Striping 

• Automatische Migration von 4 auf 5 Spiegel 

• Hinzufügen von 5. Spiegel -> • write: 5-fach Stripe 

• existierende Daten bleiben bestehen 

ZFS ZFS ZFS 

Storage Pool 

1 2 3 4 

ZFS ZFS ZFS 

Storage Pool 

1 2 3 4 5 


Intelligent Prefetch 

• Multi User Prefetch 

– Für Streaming Service Provider 

– Length & Stride Erkennung 

– Volume/FS Modell: 

The Matrix (2 hours, 16 minutes) 

Jeff 0:07 Bill 0:33 Matt 1:42 

– Prefetch meist nur auf Volume 

– ggf konkurrierende Mechanismen auch mit 

Storage Subsystemen 

The Matrix 

(10M rows, 

10M columns) 


ZFS Security Features 

• ACLs wie bei NFSv4 und Windows NT-style 

– Allow/deny mit Vererbung 

• Daten-Authentifizierung mittels Prüfsummen 

– Benutzer-definierbarer Algorithmus (auch SHA-256) 

– Daten können nur schwer verfälscht werden 

– uberblock Prüfsumme ist die Signatur für den gesamten Pool 

• Encryption (future) 

– Wichtig für mobile Geräte und zugängliche Platten 

– Auswählbarer Algorithmus aus Solaris Security Framework 

• Sicheres Löschen (future) 

– Freigegebene Blöcke werden gelöscht 


ZFS Access Control Lists (≠ UFS ACLs) 

siehe chmod(1): chmod (options) A file... 

• Subjekte (Für wen?) 

> owner@, group@, everyone@ (wie traditionell) 

> user:, group: (andere User und Gruppen) 

• Rechte (Worum geht es?) 

> read/write/append data, execute 

> read/write attributes, read/write extended attributes, read/write acl 

> list/add directory, add/delete file, delete child 

> write owner, synchronize 

• Vererbung (Weitergabe der Rechte) 

> file_inherit, dir_inherit, inherit_only, no_propagate 

• Allow/Deny 

> Recht explizit erlaubt oder Recht explizit verboten 


ZFS hot spare / hot space 

Solaris 10 11/06: 

> hot spare: extra hotspare Disks für einen oder mehrere Zpools, 

die automatisch beim Ausfall einer Disk übernehmen 

Entwicklungsprojekt: 

> hot space: Nutzung von noch freiem Platz auf der anderen 

Spiegelseite, statt dediziertem hot spare 


ZFS ab Solaris 10 10/08 

• ZFS Boot Support 

> Booten von ZFS (rootpool) 

> ZFS Root installlierbar 

– Via Text Install (keine vollgraphische Installation) 

– Jumpstart (auch Platteneinteilung) 

– Fehler bein Installation von flar, WanBoot (Bug 6744320) 

– Keine NFS Installation ohne Jumpstart 

• Zonensupport auf ZFS 

• Live Upgrade 

> Mit ZFS Root als clone im rootpool 

> Mit Zonen nur bei bestimmten Konstellationen 

(Patch, Update 7) 



• ZFS Delegation an User (Rollen) 

> Wie bisher bei Delegation an Zone 

> Zusätzlich Einschränkung der Operationen möglich 

> z.B. zfs allow snapshot@tank/ulrich 

• Dediziertes Logging Device definierbar 

> z.B. für schnelle Platten oder SSD 

> z.B. zpool add log mirror disk7 disk8 

• Dediziertes Cache Device vorgesehen (disabled) 

> Ggf. wenn grosse SSDs verfügbar sind 

• ZFS Hotplug Support 

> USB-Stick, Hotplug Platten, SAN 



• ZFS Kompression mit gzip-1 ... gzip-9 

> gzip-1 ist besser als lzjb und noch schnell 

• Spiegelung auf einer Platte 

> zfs set copies=2 tank/ulrich 

> Daten werden doppelt auf einer Platte abgelegt 

• Kommando-Kosmetik 

> ZFS create/clone mit -p (Pfadelemente werden gemacht) 

> ZFS rename ist rekursiv (ganzer ZFS Baum umbenennbar) 

• Misc 

> ZFS Upgrade auf neues Pool Format (nur aufwärts) 

> Mehr ZFS history 


ZFS: ... und was ist mit Linux btrfs 

• Inittiert von Oracle, 

> Jetzt OpenSource Projekt 

> Oracle Beteiligung heruntergefahren (größer als gedacht???) 

> User-Eigenschaften von ZFS ... ein bisschen umlackiert 

• Größte Unterschiede 

> Arbeitet mit Volume-Manager nur zusammen 

– keine Integration, man will die Projekte nicht verärgern 

– bisher kein Self Healing 

> Snapshots sind direkt writable 

– Kein genauer Stand 

– SOX Problematik 


ZFS Administration per Web 

Graphisches User Interface mitgeliefert. 

Einschalten Webserver bei Boot: 

> /usr/sbin/smcwebserver enable 

> /usr/sbin/smcwebserver start 

Webserver ist erreichbar unter 

https://localhost:6789/zfs 


ZFS Test Methode 

• ZFS kann auch im User Kontext laufen 

> ztest arbeitet parallel: 

– read, write, create, delete Dateien und Directories 

– create, destroy von ZFS und ZPOOls 

– load auf Filesystem mit Umschalten Kompression 

– Umschalten Prüfsummen-Algorithmus unter Last 

– Änderungen der Devices unter Last 

– Änderung IO Caching und Scheduling Policies unter Last 

– Schreiben von Random Daten auf eine Seite des Spiegels/RAIDZ 

– Strom-Ausfall Simulation an zufälligen Stellen im ZFS Betrieb 

– Überprüfung des Datenzustands 

> ZFS hat einige Millionen Crashes ohne Datenverlust 

überstanden 

> ztest läuft jede Nacht auf dem aktuellen nightly build 


ZFS Administration 

• Pooled storage 

> Wie Volume Gruppen / Disk Gruppen 

> Nur Filesysteme, Volumes entfallen 

> Platz wird geshart benutzt, keine Fragmentierung mehr 

• Hierarchische Filesysteme 

> Vererbung von Properties 

– Policies einzeln oder für Hierarchie-Ebenen setzbar 

– ZFS ist zentraler Konfigurationspunkt 

– Mount-Point, NFS-Share, Quota, Reservierung, Compression, ... 

> Filesysteme erzeugen ist schnell 

• Online everything 


Zpool Kommandos 

• zpool create Erzeugen eines Zpool und ZFS 

• zpool add Vergrößern eines Zpool 

• zpool destroy Löschen eines Zpool 

• zpool export Zpool exportieren 

• zpool import Zpool importieren 

(Auswahl, Umbenennung) 

Ein Zpool ist immer auch ein ZFS. 


ZFS Kommandos 

• zfs create Erzeugen ZFS (Hierarchie) 

• zfs create -V Erzeugen Zvol (~raw device) 

• zfs set Verändern von Attributen 

• zfs snapshot Snapshot erzeugen 

• zfs clone Schreibbare Kopie eines Snapshot 

• zfs rollback Zurücksetzen auf Snapshot Stand 

• zfs send ZFS Snapshot serialisieren 

• zfs receive Serielle Form als ZFS erzeugen 

Nur das ZFS in der Wurzel der Hierarchie ist auch ein Zpool. 


ZFS: neu in Solaris 10 11/06 

• Support für Sun Cluster 3.2 (als lokales Filesystem) 

• Snapshots rekursiv (alle abhängigen Filesysteme) 

• double parity: 

> raidz2: 2 Platten können ausfallen 

• hot spares: 

> manueller und/oder automatischer Ersatz defekter Platten 

• Verwaltung 

> zfs promote (clone in Filesystem umwandeln) 

• Neues on-disk Format 

> Notwendig für Performance und für zfs promote 

> Kommmando: zpool upgrade 


ZFS in Solaris 10 8/07 (Solaris 10 U4) 

• ZFS Kommando Historie (zpool history) 

• ZFS Volumes können iSCSI Targets sein 

• ZFS Properties wurden erweitert (User Properties) 

• ZFS Kommando Pflege 

• /etc/system Einstellungen für Tuning 

• Branded zoneadm clone nutzt zfs clone 


ZFS Solaris Ausblick 

• Solaris 10 U5 (Mitte 2008) 

> ZFS Volumes als Devices für Ldoms 

• Solaris 10 U6 (2008/2009) 

> ZFS User Delegation 

> ZFS mehr History (delegierte Aktionen) 

> ZFS boot 

> ZFS reduce (?) 


ZFS Serialisierung 

• Serielle Repräsentation eines ZFS Snapshots 

> Nutzung für Backup und Restore (Snapshot: fester Zustand) 

> Bewegen eines Filesystems zwischen Systemen oder Disks 

> Inkrementelle Serialisierung (Unterschiede zwischen Snapshots) 

• Full backup 

# zfs send tank/fs@A >/backup/A 

• Incremental backup 

# zfs send -i tank/fs@A tank/fs@B >/backup/B-A 

• Remote replication: send incremental once per minute 

# zfs send -i tank/fs@11:31 tank/fs@11:32 | 

ssh host zfs receive -d /tank/fs 


ZFS Kommando Historie (S10 8/07) 

• Strukturverändernde Operationen werden im Zpool 

mitgeschrieben 

# zpool history 

History for 'tank': 

2007-10-26.18:45:22 zpool create -f -m none tank c0t1d0s6 

2007-10-26.18:46:39 zfs create -o mountpoint=/zone tank/zone 

2008-01-11.14:46:22 zfs create tank/test 


ZFS Properties allgemein (S10 8/07) 

• User-Attribute 

> selbst definierbar 

> Property Name muss : (Doppelpunkt) enthalten 

# zfs set fs:owner="Ulrich Graef" tank/test 

# zfs get fs:owner tank/test 

NAME PROPERTY VALUE SOURCE 

tank/test fs:owner Ulrich Graef local 


Solaris 10 10/08: ZFS Boot 

• ZFS Boot Support 

> Booten von ZFS (root pool) 

> Text-Install für ZFS root 

> Jumpstart für ZFS root 

> Live Upgrade von UFS auf ZFS root 

> Live Upgrade auf anderen root pool 

• Rollback ohne umount (auch f. Root!) 


Solaris 10 10/08: ZFS 

• ZFS send / receive 

> inkrementelles send in einen Ziel snapshot 

> inkrementelles send in einen Clone 

> rekursives send eines ZFS Baums 

> Damit: einfache Replikation eines ZFS Baums 

• ZFS quotas / reservations nur für filesysteme 

> snapshots und clones zählen nicht mit 

• ZFS pool Properties 

> Kommando: zpool get / set 

> Property: cachefile (f. import / export) 

> Property: failmode (Verhalten bei Device Fehlern) 



• ZFS delegation 

> Delegation von ZFS Filesystemen an User / Rollen 

> Eingeschränkte Rechte möglich 

• ZFS history wurde erweitert 

> Name des Users 

• Dediziertes Logging Device definierbar 

> Interessant für Flash-Devices 

• ZFS create / clone / rename mit -p 

• ZFS hotplug support 

> USB-Stick, hotplug Platten 



• ZFS rename geht jetzt auch rekursiv 

• ZFS Kompression nun auch mit gzip (-1 ... -9) 

• ZFS mit multiplen Kopien auf einer Disk 

> = Spiegelung in einer Platte 

> zfs set copies=2 .... 

• ZFS Upgrade 

> Upgrade existierender ZFS Filesysteme möglich 

• Zone kann auf ZFS liegen 


ZFS in OpenSolaris 

• CIFS Integration 

> SMB Service im Kernel analog zu NFS 

> Samba für andere Dienste noch notwendig 

> Einfach: zfs set sharecifs=yes ... 

> Kommt erst ins Solaris nach Solaris 10 

• OpenSolaris Developer Preview (Project Indiana) 

> ZFS root Filesystem 

> Rollback mit ZFS snapshot (pkg) 


Solaris als Storage Plattform 

Solaris besitzt nun die Basis-Technologien 

• Datenverwaltung 

> ZFS Filesysteme 

> ZFS Volumes 

• Netzwerk Services 

> NFSv3 und NFSv4 

> iSCSI Target (Server für iSCSI Volumes) 

> Samba 

> CIFS im Kernel (Samba Fileservice, nur OpenSolaris) 

> Active Directory Nameservice Client 


Projekt NAS 2.0: Storage Appliance 

• Basis: OpenSolaris (gestrippt) 

• Verwaltung der Daten mit ZFS 

• Netzwerk Services von Solaris 

• Verwaltung und Monitoring 

> Project Fishworks 

(Bryan Cantrill, natürlich mit DTrace...) 


ZFS: Erzeugen 

• Das einfachste ZFS Filesystem 

# zpool create tank c1t0d0 

> Erzeugt einen zpool namens tank auf der Platte c1t0d0 

(Inklusive Erzeugen eines EFI-Labels auf der Platte) 

> Erzeugt ein Filesystem des gleichen Namens 

> Mounted das Filesystem unter /tank 

> Merkt sich die Einstellung für Mount nach Reboot 


ZFS: Erzeugen (2) 

• Gespiegelter zpool mit Filesystem 

# zpool create tank mirror c0t0d0 c1t0d0 

• Hierarchisch untergeordnetes Filesystem mit Mountpoint 

# zfs create tank/home 

# zfs set mountpoint=/export/home tank/home 

• Home Directories (für das ZFS Team) 

Automatisch unter /export/home/{ahrens,bonwick,billm} durch Vererbung 

# zfs create tank/home/ahrens 

# zfs create tank/home/bonwick 

# zfs create tank/home/billm 

• Vergrößern des zpool 

# zpool add tank mirror c2t0d0 c3t0d0 


ZFS Properties 

• NFS-export aller Directories 

# zfs set sharenfs=rw tank/home 

• Kompression (gesamter zpool) 

# zfs set compression=on tank 

• Quota (Limit nach oben) 

# zfs set quota=10g tank/home/eschrock 

• Reservation (garantierter Platz) 

# zfs set reservation=20g tank/home/tabriz 


ZFS Snapshots 

• Snapshot ist read/only (sofort und beliebig viele) 

> quasi: Kopie des uberblock 

– Platz wird nur für die Unterschiede gebraucht 

– Snapshot optional sichtbar in .zfs/snapshot des Filesystems 

– Benutzer können selbst Zugriff auf alten Stand nehmen 

• Snapshot erzeugen 

# zfs snapshot tank/home/joeuser@tuesday 

• Rollback: Filesystem zurück auf alten Stand 

# zfs rollback tank/home/joeuser@monday 

• Zugriff auf alte Version via Filesystem 

$ cat ~joeuser/.zfs/snapshot/wednesday/foo.c 


ZFS Clones 

• Clone ist eine schreibbare Version des Snapshot 

> Sofort und beliebig viele 

> Mittel für Varianten eines FS 

• Erzeugen eines Clone 

# zfs clone tank/solaris@monday tank/ws/lori/fix 

Clone ist abhänging vom Snapshot 

• “Befördern” eines Clone zum unabhängingen Filesystem 

# zfs promote tank/ws/lori/fix 

Der Snapshot kann nun gelöscht werden 


ZFS Serialisierung 

• Serielle Repräsentation eines ZFS Snapshots 

> Nutzung für Backup und Restore (Snapshot: fester Zustand) 

> Bewegen eines Filesystems zwischen Systemen oder Disks 

> Inkrementelle Serialisierung (Unterschiede zwischen Snapshots) 

• Full backup 

# zfs send tank/fs@A >/backup/A 

• Incremental backup 

# zfs send -i tank/fs@A tank/fs@B >/backup/B-A 

• Remote replication: send incremental once per minute 

# zfs send -i tank/fs@11:31 tank/fs@11:32 | 

ssh host zfs receive -d /tank/fs 


ZFS Daten Migration 

• Endian neutrales on-disk format 

– Strukturen enthalten endianness, ZFS interpretiert beide 

– ZFS schreibt in der endianess des Hosts (kein Verlust) 

• ZFS enthält alle Informationen des Data Management 

– Label, Device Pfade, Striping, Mount-Point, NFS-Share 

– Ein integrierter Punkt zur Administration 

– Platten werden an anderen Stellen erkannt (auch als Kopien) 

• Export zpool 

old# zpool export tank 

• Import nach Umbau der Platten 

new# zpool import tank 


ZFS: Self Healing in Praxis 

• Gespiegelter ZFS auf Dateien unter /test 

# dd if=/dev/zero of=/tmp/d1 bs=1024 count=102400 

# dd if=/dev/zero of=/tmp/d2 bs=1024 count=102400 

# lofiadm -a /tmp/d1 

# lofiadm -a /tmp/d2 

# zpool create test mirror /dev/lofi/3 /dev/lofi/4 

# ### hier richtige lofi Nummern verwenden! 

• Parallel: Störfeuer und Datei-Operationen 

# cd /test 

# dd if=/dev/urandom of=/dev/lofi/3 bs=1024 count=102400 & \ 

> ( cd /; tar cf – etc ) | tar xf - 


ZFS: Self Healing in Praxis 

• Inhalt prüfen; ZFS wiederherstellen 

# zpool status # ein paar Fehler 

# zpool unmount test # Cache im OS löschen 

# zpool mount test 

# tar cvf /tmp/test.tar /test # Filesystem ist ok 

# zpool status # Fehler beheben 

# zpool scrub test 

# zpool status 


ZFS Kommando Historie (S10 8/07) 

• Strukturverändernde Operationen werden im Zpool 

mitgeschrieben 

# zpool history 

History for 'tank': 

2007-10-26.18:45:22 zpool create -f -m none tank c0t1d0s6 

2007-10-26.18:46:39 zfs create -o mountpoint=/zone tank/zone 

2008-01-11.14:46:22 zfs create tank/test 


ZFS Volumes als iSCSI Targets (S10 8/07) 

• Ab Solaris 10 8/07 iSCSI Target Support 

> “Backing Store”: Dateien, Raw-Devices 

> Auch: ZFS Volumes 

• Administration integriert in ZFS Tools 

# zfs create -V 2g tank/volumes/v2 # Volume erzeugen 

# zfs set shareiscsi=on tank/volumes/v2 # Freigabe 

# Fertig! 

# iscsitadm list target 

Target: tank/volumes/v2 

iSCSI Name: iqn.1986-03.com.sun:02:984fe301-c412-ccc1-... 

Connections: 0 


ZFS Properties: xattr (S10 8/07) 

• xattr Extended Attribute ein/aus 

> Extended Attributes: Datei pro Attribut 

> Linux hat 2kByte für alle extended Attribute 

> Implementiert durch verstecktes Verzeichnis 

> Siehe 

– Kommando: runat(1) 

– Systemcall: openat(1) 


ZFS Properties: canmount (S10 8/07) 

• canmount Mountpoint ein/aus 

> Deaktivieren Mounten ohne Löschen von mountpoint 

# zfs get canmount,mountpoint tank/test 


tank/test canmount on default 

tank/test mountpoint /mnt local 


ZFS Properties allgemein (S10 8/07) 

• User-Attribute 

> selbst definierbar 

> Property Name muss : (Doppelpunkt) enthalten 

# zfs set fs:owner="Ulrich Graef" tank/test 

# zfs get fs:owner tank/test 


tank/test fs:owner Ulrich Graef local 


ZFS Properties initial setzen (S10 8/07) 

• Setzen der Properties bei ZFS create 

> -o = 

> mehrfach ist erlaubt 

# zfs create -o mountpoint=/mnt \ 

-o compression=on \ 

-o sharenfs=rw tank/test2 

# zfs get mountpoint,compression,sharenfs tank/test2 


tank/test2 mountpoint /mnt local 

tank/test2 compression on local 

tank/test2 sharenfs rw local 


ZFS Kommando Pflege (S10 8/07) 

• zfs status 

> Zeigt Dateinamen statt inodes bei defekten Dateien 

• zfs get 

> Ohne Zpool/ZFS Angabe werden alle angezeigt 

• zfs receive -F 

> Setzt das Ziel-Filesystem auf letzten Snapshot zurück 


ZFS und Zonen 

Zone A Zone B Zone C 

tank/a tank/b1 tank/b2 tank/c 

tank 

Global Zone 


zpool Object-Based Storage 

• DMU ist ein Transaktionaler Objekt Speicher 

– Filesysteme 

– Databanken 

– Swap Space 

– Volume Emulation 

– ??? 

ZFS POSIX 

Layer 

NFS 

Database 

App 

Data Management Unit (DMU) 

Storage Pool Allocator (SPA) 

UFS iSCSI Raw 

Swap 

ZFS Volume Emulator (zvol) 


ZFS Vergleich: Allgemeines 

Legende Farben: traditionell besser 

optimal 

UFS (+ SVM) VxFS (+ VxVM) ZFS 

Größe 16 TB = 2 

online Attribute 

44 Byte 8 EB = 263 Byte 16 EB = 264 Byte 

interne Größe 16 TB = 244 Byte 8 EB = 263 Byte 2128 Byte 

Transaktionen nein nein ja 

Datenblock Schutz nein nein ja 

fsck / Konsistenzprüfung offline (fsck) offline (fsck) online (zpool scrub) 

I/O Optimierung einige Optionen viele Optionen 

veraltet: c/t/s Mod. 24-stufige Pipeline 

Hierarchische Administration nein (nur VM) nein (nur VM) ja 

Filesystem – Vergrößerung ja (Volume + FS) ja (Volume + FS) ja (zpool Attribut) 

Filesystem – Verkleinerung nein ja (FS + Volume) ja (zpool Attribut) 

Pool – Verkleinerung ja ja geplant für U8 

Ersetzen von Platten im Pool ja ja ja (auch größer) 

Filesystem – Snapshots ja (zus. Platz) ja ja (in Nullzeit) 

Filesystem – Clones nein nein ja 

Verzeichnis-Ops in konstanter Zeit nein nein ja 

Filesystem auf mehreren Volumes nein ja (MDS, MVS) ja (FS im zpool) 


ZFS Vergleich: Details 


Konfiguration im OS vfstab, dfstab vfstab, dfstab integriert 

Fragmentierung freier Platz pro Volume pro Volume Platz ist shared 

Online Mod. Filesystem Parameter wenige einige alle 

Pool auf Platten ja ja ja 

Pool auf Partitionen ja nicht supportet ja 

Pool auf Dateien ja (lofiadm) ja (lofiadm) ja 

Disk Label Schutz nein nein yes (nur EFI label) 

Benutzbar f. root Filesystem ja nein ja (S10 10/08) 

User Quota 

ja ja ja (m. FS pro User) 

Filesystem Quota fest (Größe Volume) fest (Größe Volume) Online änderbar 

Range Locks in Dateien nein nein ja 

Kompression nein nein ja 

Serialisierung f. Backup etc. ja (ufsdump) ja (vxfsdump) ja (*zfs send) 

Inkrementelle Serialisierung ja (ufsdump -N) nein ja (zfs send -i) 

Rollback in Nullzeit nein nein ja 

Pool Export / Import 

ja (metaset) ja (diskgroup) ja (zpool) 

Little / Big Endian Unabhängigkeit nein nein ja 

Extended Attribute 

ja nein ja 

Delegation FS an Zonen nein nein ja 


ZFS Vergleich: Zuverlässigkeit 


Transaktionen nein nein immer 

Prüfsummen im Filesystem nein nein ja 

Entdecken v. Daten-Fehlern nein nein ja 

fsck ja ja nicht notwendig 

Online Integritätsprüfung nicht möglich nicht möglich ja (zpool scrub) 

Fehler in den Metadaten System panic System panic online Reparatur 

Fehler in den Daten wrong results wrong results online Reparatur 

Fehler im Disk Label kein Zugriff kein Zugriff 

online Rep. (EFI) 

Online Reparatur mit Spiegel no 

nein ja 

Online Reparatur mit Raid-5/-Z 

Software RAID-5 “write hole” 

nein nein ja 

ja nein, ist langsam m. nein 

dirty region logging 

Scrubbing 

nein nein ja 

Hot Spare Mechanismus ja ja ja (seit S10 11/06) 

Überlebt Datenkorruption 

(dd von Zufallsdaten auf Spiegel) 

nein nein ja 


ZFS Vergleich: Performance 

Striping 


Daten Layout statisch bei statisch bei dynamisch, nach 

Erzeugung Volume Erzeugung Volume Applikations-Last 

statisch statisch automatisch 

Anpassung an Last 

Daten Prefetch linear im FS nein Länge und Abstand 

Online Integritätsprüfung nein nein ja 

Geschwindigkeit Spiegelung langsam (Volume) langsam (Volume) nur (Meta-) Daten 

Zeit: Erzeugen eines Pools einige Minuten Minuten; ggf. reboot Sekunden 

Zeit: Erzeugen Filesystem Sekunden – Minuten Sekunden – Minuten < 1 Sekunde 

Linear bzgl Größe konstante Zeit 

Optimierung I/O Reihenfolge nein nein ja (Transaktionen) 

Online Disk-Auswahl nein nein ja (nach Last) 

I/O Lastausgleich zwischen FS nein nein ja (im zpool) 

I/O Bandbreiten Ausgleich nein nein ja (im zpool) 

Logging mit 2. Schreibvorgang ja (langsam) ja (langsam) nein (Transaktion) 

Daten im Logging enthalten nein Option (langsam bei ja (immer) 

hoher Datenrate) 

Automatische Block-Größe nein ja (nur Erzeugen) ja 


B: ZFS auf lokalen Platten 

> lokale Platten 

> Spiegelung im ZFS (Self Healing, Read Performance) 

> zpool create pool mirror disk1 disk2 ... 

> zpool add pool spare disk7 

> ggf. raidz oder raidz2 

> ggf. Einsatz von SSD für schnelles synchrones Schreiben 

Solaris Host 

1 2 3 


B: ZFS im SAN (1) 

> LUN vom Storage Subsystem (dort Raid-5 mit hot spare) 

> ZFS: Verzicht auf Self Healing 

> zpool create pool lun1 

> Redundanz vom Storage Subsystem, Integritätscheck via ZFS 

lun1 

Solaris Host 

Storage Subsystem Raid 5 

1 2 3 P Hot Spare 


B: ZFS im SAN (2) 

lun1 

> 2 LUNs vom Storage Subsystem (dort Raid-5 mit hot spare) 

> ZFS: mit Self Healing 

> zpool create pool mirror lun1 lun2 

> Redundanz vom Storage Subsystem und vom ZFS 


1 2 3 P Hot Hot Spare Spare 

Solaris Host 


1 2 3 P Hot Hot Spare Spare 

ggf. Firewall 

lun2 


B: ZFS und Datenbanken (1) 

• Verwaltung vereinfacht sich 

> Ersetzt Volume Manager 

> ZFS Volumes möglich (zfs create -V ...) 

– Wie raw device, aber ZFS write Transaktionen 

– z.B.: /dev/zvol/rdsk/tank/vol/v0 

• Empfehlung: 

> Separater zpool für Datenbank Log einrichten 

> Attribut recordsize für Log und Daten einstellen 

> NEU: 

– zpool mit SSD Platte (ggf. mirror) als Log einrichten 

– Oder: Gleich die ganze DB auf SSD (heute noch $$$$$$...) 


B: ZFS und Datenbanken (2): Datenbank 

Was ist eine Datenbank (u.a.)? 

• Konsistente Änderungen in einem Datenbestand 

• Transaktionen 

Realisierung: 

• Änderungen werden mittels Transaktions-Log abgesichert 

• Im Hintergrund: Schreiben in die DB Dateien 

• Danach Freigabe der Log-Einträge 

Genau so arbeitet auch ZFS mit dem ZFS Intent Log! 


B: Datenbank Schreibkonzept 

Wie schreibt eine Datenbank? 

Datenbank: 

synchron Schreiben 

(Integrität) 

Applikation 

Datenbank 

Log Writer Database Writer 

... 

asynchron Schreiben 


B: ZFS Schreibkonzept 

Wie schreibt eine ZFS? 

ZFS: FS Code 

synchron Schreiben 

(nur: fsync) 

ZFS Posix Layer 

Data Management Unit 

ZFS Intent Log Storage Pool Allocator 

... 

asynchron Schreiben 


B: Datenbank auf ZFS 

• Doppelte Implementierung von 

> Asynchrones Schreiben 

> Logging Funktion 

• Optimierte DB 

> Modell von Platte und Kopf 

> Stimmt nicht mehr auf ZFS 

> Das Modell der DB entspricht 

nicht mehr der Realität 

• Unoptimierte DB 

> ZFS implementiert die Optimierung 

Datenbank: 

Applikation 

Datenbank 

Log Writer Database Writer 

ZFS Posix Layer 

Data Management Unit 

ZFS Intent Log Storage Pool Allocator 

Sun Confidential: Internal Only 80 

...

B: ZFS und Datenbanken (3): Performance 

Optimierte Datenbanken: 

• Oracle, Informix, DB/2, Adabas C, ... 

• Optimiert auf Raw Devices (Kopfbewegungen) 

=> Daher beste Performance auf Raw Devices 

=> Rewrite Filesysteme (UFS, VxFS) gehen auch noch 

• ZFS ist eine zusätzliche Schicht (nochmal Log+Writer), 

die Performance wegnimmt 

Nicht optimierte Datenbanken 

• Sybase, MySQL, PostGreSQL, MaxDB, SQLite 

• ZFS stellt I/O Optimierung für die Datenbank 

=> Beste Performance auf ZFS 


B: Beispiel: ZFS und Sybase 

Sybase 

• schreibt Log 

• In-Place Updates der Daten (kein Re-Ordering) 

=> Mehr I/Os, weniger Datenrate 

Positiver Effekt der ZFS Transaktionen: 

• “Sybase auf ZFS ist 8x schneller als vorher!” 

(Feedback von einem ISP) 


ZFS und Datenbanken: Summary 

Kann ich denn nun ZFS für Datenbanken benutzen? 

• Ja! 

• ZFS bietet eine Vereinfachung der Platzverwaltung 

gegenüber dem Volume / Filesystem - Modell 

• Uneingeschränkt: die nicht I/O optimierten Datenbanken 

> Sybase, MySQL, PostGreSQL, MaxDB, SQLite, ... 

• Auf Raw-Devices optimierte DB funktionieren mit ZFS 

> Oracle, Informix, DB/2, Adabas C, ... 

> Höchste Performance erreicht man mit Raw-Devices 

> Lösbar seit S10 10/08 / in OpenStorage mit SSD im Log (Logzilla) 


Best Practices: ZFS Resilvering/Scrubbing 

• Resilvering / Scrubbing ist sehr schnell 

> SAN Luns: starke I/O und Speicherbelastung (bis 50%) 

Empfehlungen: 

• Beeinträchtigung des Betriebs einkalkulieren 

• Resilvering/Scrubbing ggf. auf Maintenance Zeiten 

verschieben (SAN devices) 

• Einzeln statt parallel Resilvering/Scrubbing einleiten 

• Mindestens Solaris 10 8/07 nutzen! 

Einstellung der Speicherbelastung mit Patch möglich 


B: ZFS Speicherbedarf 

• ZFS nutzt einen neuen Cache-Mechanismus: ARC 

> Mischung von LRU und FIFO Algorithmus 

• Mehr Daten im Cache → mehr Speicherbedarf als UFS 

• Jedes FS braucht Platz, viele ZFS brauchen viel Platz 

Empfehlungen: 

• Mehr Speicher als bei UFS/vxfs einkalkulieren 

• Mindestens Solaris 10 8/07 nutzen 

• Große Applikationen: ARC limitieren 

> /etc/system: set zfs:zfs_arc_max = 0x780000000 


B: Verkleinerung zpool 

Verkleinerung ZFS mittels Attribute 

> Platz sofort in anderen ZFS des gleichen Pools nutzbar| 

Verkleinerung zpool 

• Allgemein: noch nicht implementiert 

• Verfügbar heute: 

> zpool remove von hot spares geht 

> zpool detach von Spiegelseiten geht 

> zpool replacedurch gleiche/größere Disks geht 


B: ZFS und Platten-Schreibcache 

ZFS nutzt den Schreibcache von Platten 

• Voraussetzung: Platte als ganzes ist im Zpool 

> zpool create tank c5t6d7 # diskname ohne s* 

• Konsistenz durch force-write-cache SCSI-Kommando 

(vor dem Transaktions-Commit = Schreiben uberblock) 

• force-write-cache wirkt ggf. negativ: 

> Transaktion (alle 5 Sek.) leer den Cache (ggf. vollständig) 

• Abhilfe: 

> Slice der Platte in den Zpool konfigurieren 

> HDS: ignoriert force-write-cache (keine Einstellung nötig) 

> Konfigurierbar bei LSI (25xx, 3510, 6130, 6140, 6540, ...) 

> Global: /etc/system: setzfs:zfs_noflushcache = 1 


ZFS nutzt den Platten-Schreibcache 

ZFS nutzt den Schreibcache von Platten 

• Voraussetzung: Platte als ganzes ist im Zpool 

> zpool create tank c5t6d7 # diskname ohne s* 

• Konsistenz durch force-write-cache SCSI-Kommando 

(vor dem Transaktions-Commit = Schreiben uberblock) 


B: ZFS und ZIL 

• ZIL – ZFS Intent Log 

> Daten werden mit den Transaktionen geschrieben, 

i.d.R. alle 5 Sekunden 

> Manche Applikationen schreiben synchron / nutzen fsync 

– Synchron heisst: Daten liegen garantiert auf der Platte 

– Konsistenz von Datenstrukturen der Applikation 

> Synchrones Schreiben im ZFS erfolgt in das ZIL 

> Das ZIL ist das einzige zpool Objekt, 

das ohne Transaktion geschrieben wird! 

• ZIL abschalten: Performance-Boost für sync writes 

> ABER: Die Konsistenz der Daten ist in Gefahr! 

• Besser: ZIL auf SSD legen 


B: Anzahl paralleler Writes pro Device 

• Vor Solaris 10 5/08 und bei älteren Nevada builds: 

Anzahl der I/Os pro Device ist limitiert auf 35 

• Einstellung in /etc/system: zfs_vdev_max_pending=55 

> Anzahl der IOs pro Platte pro Sekunde 

> Ähnlich max_throttle beim sd / ssd Treiber 

• Limit existiert bei neueren ZFS Versionen nicht mehr 


B: ZFS ACLs 

ZFS ACLs sind 

• Weitergehend als die von UFS 

• Anders als die von UFS und NFSv3 

• Angepasst an NFSv4 

Aufgetretene Konflikte: 

• Datentransfer zu ZFS (ACLs in Originaldaten) 

• Einspielen UFS/vxfs Backup auf ZFS 

• Linux NFS Implementierung 

> (ältere Versionen: noacl fehlt, Rechte-Konflikte) 


B: ZFS und Shadow Image (et. al.) 

• Statt SI Benutzung von zfs snapshot/send/receive 

• ODER: 

> Storage Subsystem: Shadow Image einrichten 

> Solaris: zfs snapshot 

> Solaris: sync 

> Solaris: Warten bis I/O gesettled (~2 Transaktionen) 

> Storage Subsystem: Shadow Image trennen 

> Solaris: zpool import (auf anderem System) 

> Solaris: zfs rollback auf snapshot 

(auf anderem System) 

• unterschiedliche Rechner, da zpool-ID ist gleich 


ZFS - Zusammenfassung 

• Einfach – Macht einfach das, was der Administrator vor hat. 

• Mächtig – Pooled storage, Snapshots, Clones, Compression, Scrubbing, RAID-Z 

• Sicher – Entdeckt und Korrigiert (!!!) stille Daten-Korruption. 

• Schnell – Dynamisches Striping, Intelligentes Prefetch, Pipelined I/O 

• Offen – Source und Diskussion unter http://www.opensolaris.org/os/community/zfs 

• Kostenfrei 


ARC – Adaptive Recovery Cache 

• FIFO – Seite fliegt raus, wenn schon lange allokiert 

• LRU – Seite fliegt raus, wenn lange unbenutzt 

> Das Beste! (bei Gleichverteilung der Nutzung der Seiten) 

... ABER: Reale Rechner haben keine Gleichverteilung! 

• Häufigkeiten sind bei 2 Punkten der Statistik 

> Seite wird häufig wieder benutzt 

> Seite wird genau einmal benutzt, dann lange Zeit nicht mehr 

• ARC erkennt das automatisch 

> Nichtbenutzung für eine gewisse Zeit: Seite fliegt raus 

> Mehr Platz für wiederbenutzte Seiten! 


Hierarchische Caches 

Was ist ein Cache? 

> Puffert Informationen in schnellem Speicher 

> Benutzt Statistik um Platz zu schaffen 

Hierarchische Caches 

> Ohne zentrale Kontrolle: 

– Hierarchische Caches können nicht funktionieren 

– Die Statistik stimmt nicht! 

> CPU: L1-, L2-, (L3-) Cache vs. Memory 

– Hier: von der CPU gesteuert 

> Buffercache im Hauptspeicher vs. Platte 

– Vom Filesystem gesteuert 


Storage Subsystem Cache 

• Hat falsche Statistik: 

> häufig Benutztes (Buffercache) ist dort schon rausgeflogen! 

> Würde nur wirken, wenn wesentlich größer als Buffercache 

– Früher war das der Fall 

– Heute ist die Bedingung seltener erfüllt 

• Ist so teuer wie Hauptspeicher im Rechner 

• Wird auch als Schreibcache benutzt 

> Teilweise ggs. Störung 


OpenStorage Lösung mit ZFS 

• Readzilla: SSDs für schnelles Lesen 

• Nutzung als L2ARC: Level 2 ARC Cache 

> ZFS kontrolliert mit seiner Statistik die Inhalte des Readzilla 

Überblick: 

> Read/Write-Cache im System: ARC im Hauptspeicher 

> Write-Cache Nutzung in den Platten 

> Optionaler Write-Cache mit Logzilla 

> Optionaler Read-Cache mit Readzilla 

> Logzilla und Readzilla sind an Bedarf anpassbar 

> SSDs sind günstiger als Hauptspeicher 


Fragen? 

Ulrich Gräf 

Ulrich.Graef@Sun.COM 

http://blogs.sun.com/Solarium 

http://blogs.sun.com/blug 

98 98

Ulrich Gräf Senior SE / OS Ambassador Platform Technology ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?