Tutorial

ZFS Best Practices

Franz Haberhauer
Chief Technologist & Principal Engineer
Global Systems Engineering
Sun Microsystems GmbH
 Agenda
• Technologische Grundlagen
• Einführung in die Administration von ZFS
• Best Practices bei Konfiguration und
für spezifische Lasten
> Hybride Speicherarchitekturen mit ZFS
Transparente Nutzung von Flash-Speichern und SSDs
> iSCSI
> NFS
> CIFS
> DBMS
 Solaris ZFS Best
Mehr als nur ein lokales Dateisystem File System

der nächste Generation

End-to-End Immense
Software
Data Integrität Kapazität
Developer

Prüfsummen und Copy- ZFS ZFS ZFS 128-Bit Dateisystem

on-Write Transaktionen.
Integrierte
Fehlerbehandlung über Storage Pool
Abstraktionsebenen. Performance-
Potential

Einfache Performance in der

Administration Architektur – entworfen
für Charakteristika
Pooled Storage Modell – Kein Volume Manager. heutiger Platten.
Snapshots, Clones, Kompression, Ermöglicht die
Filesystem Quota and Reservierungen. transparente Nutzung von
OpenSolaris Timeslider SSDs.

Teil von Solaris 10 und OpenSolaris – jetzt auch für das root Filesystem
Innovation in Solaris über OpenSolaris

14.06.2005 Alle 2 Wochen

.org Solaris Express
„Indiana“ Community Release
snv_99, snv_100, ...

Alle 6 Monate
OpenSolaris
2008.05, 2008.11,
2009.06
Spezifisch für
Appliances
z.B. S7000
2008.Q4.2.1 (1.0.5)
2009.Q2.0.0
Alle 3-9 Monate
Solaris 10
5/08, 10/08,5/09, ...
Warum ein neues
lokales Dateisystem?
• Existierende lokale Dateisysteme sind 20-40 Jahre alt
> Kein umfassendes Konzept gegen Datenkorruption
> Optimierungen für nicht mehr existente Hardware-Konzepte
und überholte Charakteristika
> CPU teuer, Größenordnung der Platten-Kapazität
> Vielzahl von Limits
● Grösse, Anzahl Dateien etc.

> Aufwändig zu verwalten

● fsck, /etc/fstab, partitions, volumes

●
Zu viele Stellschrauben für manuelles Tunen
• Trennung von Dateisystem und Volume Manager
verhindert durchgängige Optimierungen und
Mechanismen zur Gewährleistung von Datenintegrität
ZFS – mehr als ein Dateisystem
Traditionelle Architektur ZFS Pooled Storage
• Abstraktion: Virtuelle Platte • Abstraktion: malloc/free
• Partition/Volume pro Filesystem • Keine Partitionen zu verwalten
• Fragmentierte Kapazität und • Flexible Zuteilung der
Bandbreite Gesamtkapazität durch Quoten
und Reservierungen
• Manuelles Erweitern/Schrumpfen
• Integrierte Fehlerbehandlung über
Abstraktionsebenen hinweg
• Snapshots, Clones, Kompression

FS FS FS ZFS ZFS ZFS

Volume Volume Volume Storage Pool

 Traditonelle Architektur vs. ZFS
Dir
Dir Dir File
Filesystem:
Dir File File
File File File
Posix-Interface:
UFS: ZFS:
Dateisystem FS ZPL
(ZFS Posix Layer)
Prüfsummen
Block-I/O Transaktionen
DMU
(Data Management Unit)

Abstraktion: Volume
Dynamic Striping
Eine große SPA
VM
virtuelle (Storage Pool Allocator)
Kompression
Platte
Self-Healing
Bitmuster ...
... HW-Optimierung
Traditionelle Architektur
• 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 das physikalische Layout (z.B. Spiegel)
=> Zugriff zu intaktem Spiegel nur manuell

• Hoher Administrationsaufwand
> Ein Filesystem erfordert (nacheinander!):
– Partitionieren
– Volume erzeugen (Wartezeit)
– Filesystem erzeugen (Wartezeit)
– vfstab Eintrag für lokalen Mount
– dfstab Eintrag für Export
> Größenänderungen (grow/shrink) sind aufwändig
Design Prinzipen des ZFS
• End-to-end Datenintegrität durch Prüfsummen
• Durchgängige Verwendung
> des Transaktionsparadigmas
> Copy on Write
> Daten werden nicht überschrieben, sondern neu geschrieben
> On-Disk Image ist immer konsistent
> kein fsck nötig
• Potential für überlegene Performance
• Immense Kapazität (128 Bit)
• Einfach zu verwalten
Copy-On-Write Transaktionen
1. Konsistenter Zustand 2. Dateien schreiben

3. Zufügen Metadaten 4. Schreiben uberblock (= Commit)

ZFS Snapshot
●
Readonly Point-in-Time Kopie eines File Systems
●
Copy-on-write ist als Mechanismus bereits vorhanden
●
Sofort verfügbar – alte Version zugänglich machen
●
Platzsparend - nur Änderungen werden gespeichert
Snapshot root
Live root
 Durchgängige Daten-Integrität
Prüfsummen in Datenblöcken ZFS Daten Integrität
●
Prüfsummen bei Datenblock ●
Prüfsumme bei Adresse
●
Einige Fehler bleiben unentdeckt ●
Gemeinsamer Fehler: unwahrscheinlich

Address Address
Checksum Checksum

Address Address
Data Data Checksum Checksum

Checksum Checksum
Data Data

Nur Fehler auf Medium erkennbar ZFS validiert alle Blöcke

✔ Bit rot
✔ Bit rot
✗ Phantom writes
✔ Phantom writes
✗ Misdirected reads and writes
✔ Misdirected reads and writes
✗ DMA parity errors
✔ DMA parity errors
✗ Driver bugs
✔ Driver bugs
✗ Accidental overwrite
✔ Accidental overwrite
Traditionelles Volume/FS Modell
1. Read liefert defekten Block 2. Falsche Metadaten: 3. Falsche Daten:
Filesystem hat Probleme, Applikation bekommt Probleme
Absturz OS möglich oder rechnet falsch
(ggf. unbemerkt!!!)

Application Application Application

FS FS FS

xxVM mirror xxVM mirror xxVM mirror

Self-Healing in ZFS
1. Read liefert defekten Block 2. ZFS berechnet Prüfsumme; 3. ZFS liefert korrekte Daten an
da diese falsch ist, die Applikation;
wird der Spiegel gelesen UND korrigiert defekten Block!
(Metadaten sind also korrekt)

Application Application Application

ZFS mirror ZFS mirror ZFS mirror

Traditionell: RAID-4 and RAID-5
●
Daten-Blöcke + Parity Block (hier: 4+1)
^ ^ ^ ^ =0

●
Partial Stripe Writes (zB. bei Stromausfall)
●
Daten des Stripe sind inkonsistent (write hole):

^ ^ ^ ^ <> 0
●
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
●
Dynamischer Größe des Stripe
●
Dynamischer Block-Größe
●
Immer full-stripe write (kein read-modify-write): Performance
●
Neuer Zustand durch COW-Transaktion (write hole entfällt)
●
RAID-Z braucht keinen Cache mit Batterie
●
Datenkorruption wird wie bei Spiegel erkannt
●
RAID-Z2 (ab Solaris 10 11/06) – 2 Parity Disks
●
Sichere und performante RAID-Implementierung in Software
●
“ZFS loves cheap disks”
Dynamic Striping
●
Automatische Migration von 4- auf 5-fach Stripes
●
Hinzufügen von 5. Spiegelpaar -> ●
Stripe über 5 Plattenpaare für neue
Daten
●
Existierende Daten bleiben bestehen
ZFS ZFS ZFS ZFS ZFS ZFS

Storage Pool Storage Pool

1 2 3 4 1 2 3 4 5
Wieviele Platten in RAID-Z(2)?
●
Nicht zu viele (3-9) – insbesondere bei Random I/O!
●
Beispiel: 100 Platten mit je 100GB, 200 IOPS
Config Blocks Available Random FSBlocks /sec
------------ --------------------- -------------------------------
Z 1 x (99+1) 9900 GB 200
Z 2 x (49+1) 9800 GB 400
Z 5 x (19+1) 9500 GB 1000
Z 10 x (9+1) 9000 GB 2000
Z 20 x (4+1) 8000 GB 4000
Z 33 x (2+1) 6600 GB 6600

M 2 x (50) 5000 GB 20000

S 1 x (100) 10000 GB 20000
[Link]
●
Beispiel: X4500 – 48 Platten % 2 Boot-Platten

● 5x(7+2), 1 hot spare, 17.5 TB

4x(9+2), 2 hot spares, 18.0 TB
6x(5+2), 4 hot spares, 15.0 TB
ZFS und Disk-Arrays
> LUN vom Storage Subsystem (dort Raid-5 mit hot spare)
> zpool create pool lun1
> Redundanz vom Storage Subsystem
> Integritätscheck via ZFS
> ZFS: Verzicht auf Self Healing

Solaris Host

Storage Subsystem Raid 5

lun1
1 2 3 P Hot Spare
ZFS und Disk-Arrays
> 2 LUNs vom Storage Subsystem (dort Raid-5 mit hot spare)
> zpool create pool mirror lun1 lun2
> ZFS: mit Self Healing
> Redundanz vom Storage Subsystem und vom ZFS
Solaris Host

lun1 lun2

Storage Subsystem Raid 5 Storage Subsystem Raid 5

1 2 3 P Hot Spare 1 2 3 P Hot Spare

mehrere LUNs mit

wenigen Disks
ggf. Brandmauer optimieren
ZFS I/O-Scheduling
ZFS und “Smart” Storage Services
• Ein auf pyhsischer Ebene 1:1 replizierter Zpool kann
am selben Host nicht ein zweites Mal importiert werden
> Instant Image, TrueCopy etc.
> Gesplittete Spiegel
> umgehängte Remote Mirror (SNDR, ShadowImage etc.)
• Konsistenz beachten
> Konsistente Snapshots über mehrere LUNs
> Write Ordering
> Konsistenz bei asynchronen Kopien
> ggf. logischer ZFS-Snapshot der Quelle und anschliessend
Rollback darauf am Ziel
• Alternative: zfs send/receive
ZFS und (NV)RAM-Caches
• ZFS aktiviert (flüchtige) Write-Caches von Platten
> falls Platte als ganzes im Zpool (keine Slices), ansonsten “as-is”
• Konsistenz durch force-write-cache SCSI-Kommando
> beim Schreiben des Uberblock, bei synchronen Schreiboperationen
• Storage Systeme mit NVRAM sollten force-write ignorieren
> teilweise konfigurierbar (SS61x0,65x0 s. CR6578220)
> Solaris 10 ab 5/09 versucht NVRAM-Devices zu erkennen und
schickt an diese keine force-write-cache
> für einzelne Devices via [Link] konfigurierbar
– ZFS_Evil_Tuning_Guide#Cache_Flushes
> Global über zfs:zfs_nocacheflush=1
> Gefahr von Dateninkonsistenz für Pools ohne NVRAM!
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
●
Transaktionen umfassen auch die Daten im FS
●
Journaling überflüssig!
●
Prüfsummen auf jedem Block des Filesystems
●
Daten und Metadaten
●
Uberblock via Seriennummer und CRC
●
Filesystem Header
●
Metatdaten für Zpools und Datasets werden in mehreren Kopien gehalten
●
Datenblöcke optional
Disk Scrubbing
●
Alle Daten werden gelesen und ggf. korrigiert
●
mirror: alle Spiegel-Seiten
●
raidz: alle Daten und Parity-Blöcke

●
Daten-Integrität wird validiert
●
Inkonsitenzen möglichst früh entdeckt
●
auch für lange unbenutzte Daten
●
Mechanismus wird auch für Wiederherstellung von Spiegeln benutzt
“resilvering”
Transaktionen + Self Healing vs. fsck
Traditionell: Filesystem Check (fsck)
●
Operationen auf Dateisystemstruktur sind nicht atomar
●
Nach Systemcrash potentiell strukturelle Inkonsitenzen
●
fsck vor Mount
●
Optimierung durch Journaling/Logging
●
Keine Handhabe gegen transiente Fehler, inkonsistente Spiegel etc.

ZFS: Transaktionen
●
Erkennt online defekte Daten und Metadaten
●
Online check möglich (zpool scrub)
●
fsck (~= zpool scrub) vor mount nicht nötig
Booten von ZFS
●
Kernfunktionalität in OpenSolaris
Option seit Solaris 10 10/08
●
Elegante Verwaltung alternativer Boot-Umgebungen
●
Snapshot vor heiklen Änderungen, bei Problemen Rollback
●
Rootpool muß auf Slices aufgesetzt werden
●
Booten erfordert VTOC (SMI-Label)
●
Spiegeln ist möglich, einfache Konkatenation,RAID-Z/RAID-Z2 nicht
ZFS Skalierbarkeit
●
Immense Kapazität (128-bit)
●
Moore's Law: Bit 65 bis 2020 notwendig
●
Zettabyte = 70-bit (ISO Präfix für 1 Milliarde TB)
●
tera = 1012 ≈ 240 heutige Disks
●
peta = 1015 ≈ 250 Jährlicher Datenanfall am LHC: 15 PB
●
exa = 1018 ≈ 260
●
zetta = 1021 ≈ 270 maximales ISO-Präfix
●
??? = 1036 ≈ 2128 maximale Größe eines ZFS
●
Max Dateigröße 263-1 (noch) durch Posix API limitiert
●
Metadaten: dynamisch, automatisch anpassend
●
Einstellungen: online durch Attribute
ZFS Performance
●
Copy-on-write Design
●
Auch geänderte Daten werden immer neu geschrieben
(sonst sind Transaktionen nicht rücksetzbar)
●
Viele kleine random Writes => wenige größere sequentielle I/Os
●
Multiple Blockgrößen
●
Automatische Anpassung nach Datenaufkommen
●
Voreinstellung: 128KB
●
Für spezifische Lasten (z.B. DBMS) konfigurierbar
●
Pipelined I/O
●
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
 Performancevergleich
UFS vs. ZFS

Galaxy 4200 utilizing 90GB stripe configuration

306.3
100
90
80 77.3

70
elapsed time [s]

60
50
40 35.1
30
19.2 20.1
20
10.8
10
2.5 1.9 4.2 2.4 1.9 1.8
0
create 50.000 create 50.000 write 1000 files a read 1000 files a unlink 50.000 unlink 50.000
files links 1.6MB 1.6MB links files

UFS (default) ZFS (default)

© März 2006, Thomas Nau, kiz, Universität Ulm

 Performancevergleich
UFS vs. ZFS

© März 2006, Thomas Nau, kiz, Universität Ulm

ZFS Administration
●
Pooled storage
●
Wie Volume Gruppen / Disk Gruppen
●
Nur Filesysteme, Volumes entfallen
●
Freie Kapazität für alle Filesysteme verfügbar
●
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 anlegen ist schnell
●
Alles Online
ZFS Administration auf Solaris 10 per BUI
Browser-basiertes graphisches User Interface unter
[Link]

Ggf. Webserver aktivieren (persistent über Reboot):

● /usr/sbin/smcwebserver enable
● /usr/sbin/smcwebserver start
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
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

●
Quota (Limit nach oben)
# zfs set quota=10g tank/home/eschrock

●
Reservierung (garantierter Platz)
# zfs set reservation=20g tank/home/tabriz

●
Kompression (gesamter zpool)
# zfs set compression=on tank
Komprimierende Datasets

●
Kompression (gesamter zpool)
# zfs set compression=on tank

●
Kompression (neues Dataset mit gzip)
# zfs create -o compression=gzip tank/franz

● Reservation (garantierter Platz)

# zfs get compressratio tank/franz
NAME PROPERTY VALUE SOURCE
tank/franz compressratio 1.13x -
Performance-Charakteristika von
Kompressionsalgorithmen
●
Kompression (neues Dataset mit gzip)
# zfs create -o compression=gzip tank/franz

[Link]
ZFS Snapshots
●
Snapshot ist readonly (sofort und beliebig viele)
●
quasi: Kopie des uberblock
●
Platz wird nur für die Unterschiede gebraucht
● Snapshot ist sichtbar in .zfs/snapshot im Root des Filesystems
● Benutzer haben direkt Zugriff auf alten Stand
●
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
OpenSolaris TimeSlider
OpenSolaris TimeSlider
OpenSolaris TimeSlider
OpenSolaris TimeSlider
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/solaris_beta

●
Clone Promotion (ab Solaris 10 11/06)
●
Orginales Dateisystem und Clone tauschen Rolle
# zfs promote tank/solaris_beta
# zfs rename tank/solaris /tank/solaris_0601
# zfs rename tank/solaris_beta /tank/solaris
# zfs destroy tank/solaris_0601
ZFS und Solaris Container

Zone A Zone B Zone C

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

tank

Global Zone
ZFS und Solaris Container
• Zoneroot auf ZFS offiziell seit Solaris 10 10/08 unterstützt
• Dateisystem wird konventionell in Verzeichnisbaum der
Zone eingehängt
> Globaler Administrator kontrolliert Eigenschaften
> Erlaubt Sharing von Dateisystemen zwischen Zonen
• ZFS Datasets werden über zonecfg(1M) exportiert
> Innerhalb der Container können darin weitere
Datasets, Snapshots und Cones erzeugt werden
> Die meisten Properties können geändert werden
> Weder Storage Pools noch Volumes können erzeugt
oder modifiziert werden.
ZFS und Solaris Container
• Erzeugen eines Dataset mit 16GB Quota und export in
einen Container
global# zfs create poolA/web2
global# zfs set quota=16G poolA/web2
global# zonecfg -z web2
zonecfg:web2> add dataset
zonecfg:web2:dataset> set name=poolA/web2
zonecfg:web2:dataset> end
zonecfg:web2> commit
zonecfg:web2> exit
global# zoneadm -z web2 boot
web2# zfs create poolA/web2/opt
web2# zfs set mountpoint=/opt poolA/web2/opt
Delegierte Administration
●
Delegation spezifischer Rechte
# zpool create sandbox c0t1d0
# zfs allow franzh create,mount sandbox
# chmod 1777 /sandbox
franzh$ zfs create sandbox/franzh

●
Rechte-Mengen
# zfs allow -s @set1 \
create,mount,snapshot,clone,promote sandbox
# zfs allow franzh @set1 sandbox/franzh
ZFS Daten Migration
●
Endian-neutrales On-Disk Format
●
Strukturen enthalten Endianness, ZFS interpretiert beide
●
ZFS schreibt in der Endianess des Hosts
●
ZFS enthält alle Verwaltungsinformationen
●
Label, Device Pfade, Striping, Mount-Point, NFS-Share
●
Platten werden unter verschiedenen physischen Pfaden erkannt
(auch als Kopien)

●
Export zpool
old# zpool export tank

●
Import nach Umbau der Platten
new# zpool import tank
ZFS User Attribute
• selbst definierbar
> Property Name muss : (Doppelpunkt) enthalten
> z.B. für administrative Daten bei “mobilen” Datasets
• über CLI setz- und abfragbar
# zfs set admin:application="Webportal" tank/db234_01
# zfs set admin:importance="critical" tank/db234_01
# zfs set admin:costcenter="47110815" tank/db234_01
# zfs set admin:application="App-Server Webportal" tank/web234_01
# zfs set admin:costcenter="47110815" tank/web234_01
# zfs get all tank/web234_01 | fgrep admin:
tank/web234_01 admin:application App-Server Webportal local
tank/web234_01 admin:costcenter 47110815 local
# zfs get -H -o value admin:costcenter tank/db234_01
47110815
ZFS Serialisierung
●
Serielle Repräsentation eines ZFS Snapshots
●
Nutzung für Backup und Restore (Snapshot: fixierter 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
Rekursive ZFS Snapshots
●
Rekursiver Snapshot
# zfs snapshot -r tank/home@monday
●
Rekursives Umbenennen
# zfs rename -r tank/home@yesterday @2daysago
●
Rolling Snapshots Made Easy
● [Link]

●
Rekursive Serialisierung von Snapshots
# zfs send -Rv rpool@0602 > \
/net/remote-system/rpool/snaps/rpool.0602
Root Pool Caveats: [Link]
ZFS und Enterprise Backup Clients
●
ZFS hat neuen Typus von ACLs
●
wurde anfangs von den Enterprise Backup Clients nicht unterstützt
●
aktuelle Versionen können auch ACLs sichern
●
Sun StorEdge Enterprise Backup Software (Legato Networker 7.3.2)
●
Symantec Netbackup 6.5 (Fixes in 6.2.5A)
●
IBM TSM 5.3 (bei Sun intern validiert mit [Link])
●
Amanda (OpenSource)
●
2.6.1 mit suntar oder zfs send/receive
● [Link]/blogs/?p=128

● Zmanda Recovery Manager for MySQL nutzt ZFS Snapshots

● [Link]/[Link]

●
NDMP (Network Data Management Protocol) in OpenSolaris (snv_102)
● [Link]/os/project/ndmp/
●
Hinweise unter
ZFS_Best_Practices_Guide#ZFS_Backup_.2F_Restore_Recommendations
● ggf. ZFS Snapshots (.zfs Directories) ausblenden
Monitoring - Health
●
zpool status
# zpool status tank
pool: tank
state: DEGRADED
status: One or more devices has been taken offline by
the administrator.
Sufficient replicas exist for the pool to
continue functioning in a degraded state.
action: Online the device using 'zpool online' or
replace the device with 'zpool replace'.
scrub: none requested
Fehlerstatistik
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror DEGRADED 0 0 0
c1t0d0 ONLINE 0 0 0
c1t1d0 OFFLINE 0 0 0
errors: No known data errors
Monitoring - Health
●
zpool status

# zpool status local

Pool: local
Status: ONLINE
Status: Der Pool wurde mit einer älteren Ondisk-
Version formatiert. Der Pool kann noch immer
verwendet werden, einige Funktionen sind
jedoch nicht verfügbar.
Aktion: Aktualisieren Sie den Pool mit der Option
'zpool upgrade'. Danach kann jedoch nicht
mehr mit älteren Softwareversionen auf den
Pool zugegriffen werden.

...
Troubleshooting
●
Wertvolle Hinweise auf [Link] -> ZFS Troubleshooting Guide
●
Chapter 11 ZFS Troubleshooting and Data Recovery im
Solaris ZFS Administration Guide auf [Link] -> Solaris 10
●
Predictive Self Healing
●
Hardware-Fehlerprotokollierung und Diagnose in der FMA
●
fmdump
●
/etc/zfs/[Link]
●
Bei Bootproblemen Boot in Milestone=None
●
ok boot -m milestone=none
●
Löschen oder Umbenennen vermeidet Zugrif auf korrupte Pools
●
Gesunde Pools einzeln importieren
●
Entfernen von LUNs derzeit nicht allgemein möglich
● zpool remove nur von hot spares
● zpool detach von Spiegelseiten
● zpool replace durch gleiche/größere Disks geht
Monitoring - Performance
●
zpool iostat

# zpool iostat -v 5
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
local 35,1G 1,37G 30 0 1,93M 0
c1t0d0s7 35,1G 1,37G 30 0 1,93M 0
---------- ----- ----- ----- ----- ----- -----
rpool_101 8,24G 1,51G 3 0 339K 0
c1t0d0s4 8,24G 1,51G 3 0 339K 0
---------- ----- ----- ----- ----- ----- -----

...
Performance FAQs: RAM
Filesystem Device Management
GUI
Consumers Consumers Apps

JNI
libzfs
●
Insbesondere früher bei manchen Lasten USER

(teilweise scheinbar) hoher RAM-Konsum KERNEL

Interface ZPL ZVOL /dev/zfs
Layer
●
ARC (Adaptive/Adjustable Replacement Cache)
● ARC limitieren bei Anwendungen mit hohem Transactional ZIL ZAP Traversal
RAM-Bedarf, Nutzung von Large Pages Object
Layer DMU DSL
● /etc/system: set zfs:zfs_arc_max = 1024000000
limitiert ARC auf 1GB ARC
Pooled
● Verbesserungen durch CRs, u.a. Storage
Layer
ZIO
VDEV Configuration
● 6429205 Each zpool needs to monitor its throughput
and throttle heavy writers LDI
● fixed in Solaris 10 10/08

● [Link]/roch/entry/the_new_zfs_write_throttle

● 6488341ZFS should avoiding growing the ARC into trouble

● fixed in snv_107, geplant für Solaris 10 Update 8

● OpenSolaris: primarycache-Attribut: Caching von (Meta-)Daten je Dataset

● mehr im ZFS_Evil_Tuning_Guide#Limiting_the_ARC_Cache
● Monitoring: kstat -m zfs / [Link]/realneel/entry/zfs_arc_statistics
Performance FAQs: Synchrone I/Os
Synchrone I/Os typisch bei NFS, DBMS (O_DYSNC) Filesystem Device Management
● GUI
Consumers Consumers Apps

Filesystem-Struktur-Operationen JNI
libzfs
(Anlegen, Löschen von Dateien, tar etc.!) USER
KERNEL
●
Logging synchroner System Calls im ZIL Interface ZPL ZVOL /dev/zfs
Layer
(ZFS Intent Log) pro Zpool
●
[Link]/os/community/zfs/source/ Transactional ZIL ZAP Traversal
Object
●
Performance-Optimierung durch Layer DMU DSL

●
separierten ZIL auf schnellen Devices ARC
Pooled
●
Platte, NVRAM oder SSD Storage ZIO
Layer
Configuration
●
min. 64MB VDEV

●
benötigt max. ausstehende Writes (x MB/s * 10s) LDI

●
zpool add tank log mirror c1t11d0 c1t12d0
●
Log kann derzeit nur hinzugefügt werden
●
Nützlichkeit vorher prüfen
●
[Link] ([Link]
● [Link]
Wer misst misst Mist?
Filesystem-Benchmarking
●
Trivial-Benchmarks
● Einpacken, Auspacken eines Verzeichnises mit tar
● dd mit unterschiedlichen Parametern
● ggf. parallele Aufrufe
●
Sequentielle Performance vs. Durchsatz vs.
allgemeiner Systemperformance unter Last(Write Throttles)
●
Realistischer Operationsmix?
●
Industrie-/Standard-Benchmarks
● SPECsfs für NFS repräsentiert “Home-Directory-Server”
● Analyse von Bonnie++ gegen Sun Storage 7000
● [Link]

●
Filebench: Open Source File System Benchmark
●
Konfigurierbare IO-Größen, -Muster, -Lasten
● [Link]
●
Einfacher, aber nicht trivial
● [Link]
Nützliche Tools und Utilities
●
zilstat
● von Richard Elling
● [Link]/Home/scripts-and-programs-1/zilstat

●
arcstat
● von Neelakanth Nadgir
● Skript, dass ARC Statistiken aus kstat -m zfs extrahiert

● [Link]
●
ZFSvis
● von Jörg Möllenkamp
● [Link]
Der Hybride Storage Pool

• Speicher wird transparent verwaltet

als ein Pool mit einer optimierten
Hierarchie
• ZFS verbindet die Attribute der
unterschiedlichen Device-Typen zu
einer optimierten Einheit
Trends bei plattenbasierten Speichern

• Schnellere Laufwerke
> 7200 rpm → 10k rpm → 15k rpm
• Performance-Metriken
> Durchsatz, IOPS, Latenz
• (NV-)RAM für bessere
Schreib-Performance
Probleme
• Signifikant höhere Leistungsaufnahme schnellerer
Laufwerke
• $/GB von 15k rpm Laufwerken deutlich schlechter als von
7200 rpm
Der Fluch der steigenden Kapazität
oder ¨Früher war alles besser¨
Die CPU/Storage Lücke
SunFire x4450 ist 500 mal schneller als 8 HDDs
Flash Memory
• Retter in der Not?
> Drei Größenordnungen schneller
> Niedrige Leistungsaufnahme
> Rapide fallende Preise
• Warum jetzt?
> 1980 erfunden von Dr. Fujuo Masuoka bei Toshiba
> 1988/1989 erste Produkte von Intel (NOR) und Toshiba (NAND)
> Heute 92% der Produktion im Consumer-Markt
> MP3-Player, Speicherkarten für Kameras, Memory-Sticks
> Flash SSDs tauchen 2007 im Enterprise-Markt auf.
>SLC versus MLC
Anatomie eines Solid State Drive (SSD)

• Eine SSD besteht aus:

> A) Controller
> B) DRAM
> C) Flash
• Flash ist aus Speicherblöcken aufgebaut
• Schreiben funktioniert nur blockweise !
• Controller ist zuständig für
> Wear Leveling (Schreibzyklen zählen)
> Bit Error Correction
> Bad Block Mapping
> Disk Interface (SATA, SAS, FC)
Vergleich Disk versus SSD
Ein IOPS kostet 70 mal weniger in der SSD

High Speed Disk Enterprise SSD

180 Write IOPS 7.000 Write IOPS
320 Read IOPS 35.000 Read IOPS
300 GB 32 GB
18 Watt 3 Watt
2.43 $ pro IOPS 0.04 $ pro IOPS
Die neue Speicherhierarchie
• SSDs heute kein 1:1 Ersatz für HDDs
> bezogen auf die Kapazität wesentlich teurer
> geringere Speicherdichte
> “eigene” Performance-Charakteristika
• Nutzung als neue Hierarchieebene
ZFS: Für Flash optimierter I/O Stack
Filesystem Device Fishworks Higher-Level
Consumers Consumers Management UI Data Services

USER libzfs

KERNEL
Interface ZPL ZVOL /dev/zfs
Layer

Transactional ZIL ZAP Traversal

Object
Layer
DMU DSL

Pooled ARC
Storage
ZIO
Layer
VDEV Configuration

LDI

Logzilla ... Readzilla ... DISK DISK DISK ...

Der Hybride Storage Pool

• Speicher wird transparent verwaltet

als ein Pool mit einer optimierten
Hierarchie
• ZFS verbindet die Attribute der
unterschiedlichen Device-Typen zu
einer optimierten Einheit
[Link]
Konfiguration in ZFS
• zpool(1M), zfs(1M)
# zpool create mypool \
mirror c0d0 c1d0 mirror c2d0 c3d0 \
log mirror c4d0 c5d0
# zpool add mypool cache c2d0 c3d0
# zfs set recordsize=8k mypool/myfs
• [Link]
> [Link]
Home/scripts-and-programs-1/zilstat
L2ARC und Working Set

• Idealerweise Working Set im L2ARC

• Bei sehr großen Working Sets nur Metadaten in den Cache
zfs(1M): primarycache/secondarycache=all | none | metadata
Sun Unified Storage Appliance S7000
Performance eines 7410 Head Node ausgereizt 7410 Cluster
[Link]/brendan/entry/my_sun_storage_7410_perf 288 x 3.5” SATAII Disks*
Up to 287TB* total storage
Hybrid Storage Pool with Read and Write optimized SSD

7410
288 x 3.5” SATAII Disks*
Up to 287TB* total storage
Hybrid Storage Pool with Read and Write optimized SSD
Price

7210
48x 3.5” SATAII Disks
Up to 46TB total storage
Hybrid Storage Pool with Write optimized SSD

7110
16x2.5”SAS Disks, 2.3TB
Standard Storage Pool

[Link]
[Link]
Capacity / /Performance *Up to 575TB soon after release
Logzilla und Readzilla in der S7000
• Logzilla: schreib-optimierte SSD
> 18GB, SLC
220MB/s / 45.000 IOPS Read
115MB/s / 16.000 IPOS Write
20-120us Latenz
• Readzilla: lese-optimierte SSD
> 100GB, SLC
100MB/s / 15.000 IOPS Read
100MB/s / 1.500 IOPS Write
100us Latenz
Sun Unified Storage Appliance S7000
Konfigurationen
7110 (Iwashi) Storage 7210 (Fugu) Storage 7410 (Toro)

Configuration Standard Entry Mid High Entry Mid High

Internal Capacity 2TB 11.5TB 22.5TB 44TB ----- ----- -----

Drive type 2.5” 146GB SAS 250GB SATA 500GB SATA 1TB SATA 1TB SATA

RAM 8GB 32GB 64GB 64GB 16GB 64GB 128GB

Readzilla 100GB ----- ----- ----- ---- ----- 1x100GB 2x100GB

Logzilla 18 GB ----- ----- 1x18GB 2x18GB [1|2|4]x18GB in [1|2|3] J4400 Array

CPU Qty/Speed 1x 1.9G 2x 2.3G 2x 2.3G 4x 2.3G

External Capacity No No J4400 Array (unique P/N, Config)
(future) (future TBD)
Up to 12 arrays (24 with sw 1.1)
- 23x1TB + 1x Logzilla
- 22x1TB + 2x Logzilla
- 20x1TB + 4x Logzilla
- 11x1TB + 1x Logzilla
- 10x1TB + 2x Logzilla
- 24x1TB
- 12x1TB
High Availability No No Yes Yes Yes

Warranty 1 yr 2 yr 3 yr

Price Disc. Category F M M

Analytics
Integrierte System- und Performance-Analysen

• Grafisches User Interface für

automatische System-Analyse
> einfach zu nutzen
• Bietet vielfältige Informationen
zu System-Status und Protokollen
> basiert auf DTrace
• Für Echtzeit-Analyse und
für historische Daten
> kann Daten exportieren für
weiterverarbeitende Tools
Sie wollen eine S7000 mal virtuell probieren?
• [Link]
> [Link]
Open Storage

[Link]
ZFS Volume Emulator (zvol)
●
Erzeugen eines 2GB großen ZFS-Volumes für Swap
# zfs create -V 2g tank/volume
# swap -a /dev/zvol/dsk/tank/volume

UFS iSCSI Raw Swap

ZFS POSIX Layer ZFS Volume Emulator (zvol)

Data Management Unit (DMU)

Storage Pool Allocator (SPA)

Encryption
• ETA in OpenSolaris Q4CY2009
> [Link]/os/project/zfs-crypto/
• Workaround mit Lofi-Encryption (in OpenSolaris 2009.06)
> [Link]/darren/entry/encrypting_zfs_pools_using_lofi
$ export PVOL=rpool/export/home/darrenm/pvol
# zfs create -V 1g $PVOL
$ pktool genkey keystore=pkcs11 label=$PVOL keylen=256 keytype=aes
Enter PIN for Sun Software PKCS#11 softtoken:
$ pfexec lofiadm -a /dev/zvol/rdsk/$PVOL -T:::$PVOL -c aes-256-cbc
# zpool create darrenm -O canmount=off -O checksum=sha256 -O mountpoint=/export/home/darrenm darrenm /dev/lofi/1
# zfs allow darrenm create,destroy,mount darrenm
$ zfs create -o canmount=off darrenm/Documents
$ zfs create darrenm/Documents/Private

That sets things up the first time. This won't be automatically available after a reboot, infact the "darrenm" pool will be known
about but will be in an FAULTED state since its devices won't be present. To make it available again after reboot do this:

$ pfexec lofiadm -a /dev/zvol/rdsk/$PVOL -T :::$PVOL -c aes-256-cbc

$ pfexec zpool import -d /dev/lofi darrenm
$ zfs mount -a
OpenSolaris Storage Projekte

[Link]
iSCSI
• SCSI-Kommandos über TCP/IP-Netze
> Kein separates SAN erforderlich, einfachere Virtualisierung
> IP-Tools können verwendet werden (snoop, tcpdump etc.)
> Hochverfügbarkeit durch IP-Multipathing/Link-Aggregation
• Terminologie:
> iSCSI-Target: Server-Seite - iscsitadm(1M)
> seit Solaris 10 8/07 – wesentlich verbessert in 5/09!!!
> COMSTAR in OpenSolaris
> iSCSI-Initiator: Client-Seite – iscsiadm(1M) (seit Solaris 10)
> IQNs: iSCSI Qualified Names und Aliases
> [Link]-mm.{reversed domain name}:{arbitrary text}
> TPGT: Target Portal Group (IP-Addresse + Port (default 3260)) Tag
> iSNS: Internet Storage Name Service
> ACLs (Access Control Lists), Authentifizierung mit CHAP (RADIUS)
ZFS Volume als iSCSI-Target (1)
●
Einfache Target-Konfiguration
# zfs create -V 2g tank/volumes/v2
# zfs set shareiscsi=on tank/volumes/v2
# iscsitadm list target
Target: tank/volumes/v2
iSCSI Name: [Link]:
02:984fe301-c412-ccc1-cc80-cf9a72aa062a
Connections: 0

●
Konfiguration des Initiator
# iscsiadm add discovery-address [Link]:3260
# iscsiadm modify discovery --sendtargets enable
# devfsadm -i iscsi
# format
# zpool create iscsipool
c2t0100001C42E9F21A00002A0047E39E34d0
zu Windows als Initiator: [Link]
ZFS Volume als iSCSI-Target (2)
●
Komplexe Target-Konfiguration
# iscsitadm modify admin -d /etc/iscsi/target
# zfs create -V 2g tank/volumes/v2
# iscsitadm create target \
-b /dev/zvol/rdsk/data/tank/volumes/v2 v2
# iscsitadm create tpgt 1
...
Konfiguration von TPGTs, ACLs, Authentifizierung
etc.
OpenSolaris Storage Projekte

[Link]
iSCSI mit COMSTAR in OpenSolaris
●
Zur Nutzung von COMSTAR in OpenSolaris werden alternative Services
und Kommandos genutzt:
●
Services: stmf und iscsi/target
●
sbdadm(1M) - SCSI Block Disk command line interface
●
stmfadm(1M) - SCSI target mode framework command line interface
●
itadm(1M) – administer iSCSI targets
● [Link] -> OpenSolaris -> OpenSolaris System Administrator Information (Server Admin by
Topic) -> Storage
● [Link]
NFS (Network File System)
• In den 1980er Jahren von Sun entwickelt
• 1989 NFSv2 (RFC1094)
• 1995 NFSv3 (RFC1813)
> 64 Bit: Dateien > 2GB
> Performance durch asynchrones Schreiben der Clienten
(Sliding Window Protokoll)
> Zahlreiche Plattformen
> auch in Windows Services for UNIX (SFU)
• 2000 NFSv4 (RFC3010)
> Starke Authentifizierung muss implementiert werden
> davor in Secure NFS
> Zusammenfassung von Protokollen
> Verbesserte Interoperabilität, z.B. ACLs
ZFS Access Control Lists (≠ UFS/POSIX ACLs)
siehe chmod(1): chmod (options) A<acl-op> file...
• Subjekte (Für wen?)
> owner@, group@, everyone@ (wie traditionell)
> user:<user>, group:<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
CIFS (Common Internet File System)
• SMB (Server Message Block)
> 1984 als Filesharing-Protokoll auf Basis von NetBIOS eingeführt
von IBM
> 1996 von Microsoft erweitert
• Mehr als ein einfacher Fileservice
> Verwaltung der Mitgliedschaft in Domains oder Workgroups
> Authentifikation von Clienten
> Microsoft Windows Dienste via MS-RPC
• Implementierungen unter UNIX/Linux/Non-Windows
> Samba
> NAS-Appliances
> Sun StorageTek 5300 Linie mit Technologien von Procom
> Basierend auf OpenSolaris: Storage Tek 7000 Linie
OpenSolaris als Multiprotokoll-Fileserver
CIFS/SMB in OpenSolaris

• CIFS Integration
> SMB Service im Kernel analog zu NFS
> Samba und SMB-Service schließen sich wechselseitig aus
> Reservierte Ports
> In OpenSolaris integriert (Build 77, Oktober 2007)
> Getting Started
– [Link]
– Solaris CIFS Administration Guide
> 370.000 LOC, kein Plan zur Integration in Solaris 10 Update
Bürger erster Klasse
Windows Identitäten in Solaris
• UNIX-Identitäten
> UID/GID: 32-Bit Signed Integer
• Windows
> Security Identifier (SID)
> Beispiel: S-1-5-12-7623811015-3361044348-030300820-1013
Bürger erster Klasse
Dateisysteme
• ZFS unterstützt u.a.
> Case-sensitive und Case-insensitive Datasets
> DOS and System Attributes
> Hidden, Read-Only, System, Archive
> # zfs create -o casesensitivity=mixed fs_for_cifs
# zfs set sharesmb=on fs_for_cifs
> Bezeichner für den Share
> Name des Dateisystems
– Ungültige Zeichen z.B. „/“ in Pfaden ggf. durch „_“ ersetzt
> Explizite Namen
> # zfs set sharesmb=name=myshare fs_for_cifs
Bürger erster Klasse
Identity Mapping Service
● Namensbasierte Abbildung
● Ein Administrator bildet explizit Windows und Solaris

Benutzernamen aufeinander ab.

● Ephemeral ID Abbildung

● UID/GIDs werden dynamisch für SIDs erzeugt,

für die es keine namensbasierte Abbildung gibt.

● Lokale SID Abbildung

● UID/GID wird auf eine algorithmisch lokal erzeugte SID

abgebildet.
Architektur des Solaris CIFS Service
Einbinden in eine Windows Domain
• DNS Client
• Kerberos Client
> /etc/krb5/[Link] [Link](4)
[libdefaults]
default_realm = [Link]
[realms]
[Link] = { /etc
kdc = [Link]
admin_server = [Link]
kpasswd_server = [Link]
kpasswd_protocol = SET_CHANGE
}
[domain_realm]
.[Link] = [Link]

• Konfiguration von AD via sharectl(1M)

> # sharectl set -p ads_domain=[Link] smb
# sharectl set -p ads_enable=true smb

• Starten des CIFS Service

> # svcadm enable -r smb/server
# smbadm join -u admin-user [Link]
ZFS und DBMS
●
Herausforderungen durch Implementierungskonzepte von DBMS
●
Synchrones Schreiben zur Implementierung des Transaktionsparadigmas
●
Separierter ZIL, ggf. in NVRAM / Flash / SSD
●
Eigene Konzepte zur Optimierung des physischer Layout
●
Manche DB-Lasten profitieren von Kompression im ZFS
●
Eigene Prefetch-Strategien
●
An DBMS-Blockgröße angepasste ZFS-Recordsize
●
zfs set recordsize=8k|16k für Datafiles
●
vor Anlegen zu setzen
● DBMS-Logfiles mit ZFS-Default 128k
● eigener Zpool kann bei JBODs Schreiblatenz verbessern

●
Eigener Datenbank-Puffer im Hauptspeicher, Doppelpufferung im FS-Cache
●
ARC-Cache limitieren
● set zfs:zfs_arc_max = #bytes (in /etc/system)
●
OpenSolaris: zfs create -o primarycache= none | metadata für Datafiles
●
ZFS_Best_Practices_Guide#ZFS_and_Database_Recommendations
ZFS und MySQL
●
Storage-Engine entscheident
●
InnoDB
●
implementiert Transaktionsparadigma
●
ZFS schreibt atomar
● skip-innodb_doublewritebuffer eliminiert unnötige Writes
●
MyISAM
●
Zugriffsmethode auf Dateien
●
verläßt sich auf das Dateisystem zur Pufferung von Daten!
● Mehr in Neelakanth Nadgirs Blog
● [Link]

aus [Link]
 Solaris ZFS Best
Mehr als nur ein lokales Dateisystem File System

der nächste Generation

End-to-End Immense
Software
Data Integrität Kapazität
Developer

Prüfsummen und Copy- ZFS ZFS ZFS 128-Bit Dateisystem

on-Write Transaktionen.
Integrierte
Fehlerbehandlung über Storage Pool
Abstraktionsebenen. Performance-
Potential

Einfache Performance in der

Administration Architektur – entworfen
für Charakteristika
Pooled Storage Modell – Kein Volume Manager. heutiger Platten.
Snapshots, Clones, Kompression, Ermöglicht die
Filesystem Quota and Reservierungen. transparente Nutzung von
OpenSolaris Timeslider SSDs.

Teil von Solaris 10 und OpenSolaris – jetzt auch für das root Filesystem
Weitere Informationen
● ZFS Learning Center
● [Link]

● Handbuch
● [Link] -> Solaris 10 -> System Administrator Collection

● Solaris ZFS Administration Guide

● OpenSolaris
● [Link]/os/community/zfs

● Source Tour

● Forum zfs-discuss

● ZFS Guides auf [Link]

● ZFS Best Practices Guide

● ZFS Evil Tuning Guide

● ZFS Troubleshooting Guide

Weitere Informationen
● Blogs
● Roch Bourbonnais - Performance

● [Link]

● Neelakanth Nadgir – DBMS Performance

● [Link]

● Brendan Gregg – Performance Analysen mit Sun Storage 7000 Analytics

● [Link]

● Adam Leventhal – Sun Storage 7000 Unified Storage Systems

● [Link]

● Deutsches Sun SE-Team über Solaris

● [Link]
Tutorial
ZFS Best Practices
Franz Haberhauer
[Link]@[Link]

[Link]/solarium