Click here to load reader

ZFS & Co - doag.org · Seite 2 Thomas Nau, „ZFS & Co” ©2011 Thomas Nau kiz, Kommunikations- und Informationszentrum • Die Aufgaben der "Abteilung Infrastruktur" umfassen

  • View
    213

  • Download
    0

Embed Size (px)

Text of ZFS & Co - doag.org · Seite 2 Thomas Nau, „ZFS & Co” ©2011 Thomas Nau kiz, Kommunikations-...

  • Thomas Nau, „ZFS & Co”Seite 1 ©2011 Thomas Nau

    ZFS & CoDie Vorteile von Solaris für ausfallsichere Mailsysteme

    Thomas Nau, kiz ([email protected])

  • Thomas Nau, „ZFS & Co”Seite 2 ©2011 Thomas Nau

    kiz, Kommunikations- und Informationszentrum

    • Die Aufgaben der "Abteilung Infrastruktur" umfassen– Cluster basierende universitätsweite Mail-, LDAP-, Portal-,

    Datenbank- und File-Services

    – Betreuung von ca. 600 Desktop und Laptop Arbeitsplätzen

    • 25% Linux, 75% Windows

    – Backup Service für die Universitäten Konstanz und Ulm

    – HPC Cluster für die Universitäten in Konstanz, Stuttgart und Ulm

    – 4 lokale Netzwerke plus flächendeckendes Campus WLAN und MAN im Ulmer Stadtbereich

    – Telefonanlage mit ca. 14.000 Anschlüssen unter Einsatz von VoIP und 2-Draht Technik

    – Ausbildung von 6 Azubis

  • Thomas Nau, „ZFS & Co”Seite 3 ©2011 Thomas Nau

    ©Universal Pictures

    Warnung...

    Email ist aus Nutzer Sicht noch immer die Top Anwendung; deshalb sind wir ein bisschen paranoid...

    … auch wenn manche der Meinung sind Email wäre seit der Geburt von Facebook & Co tot.

  • Thomas Nau, „ZFS & Co”Seite 4 ©2011 Thomas Nau

    Wir sind paranoid wenn es darum geht ...

    • nichts von Fehlern zu wissen die in den Daten bzw. dem Filesystem bereits vorhanden sind

    • keine Schutz gegen "fat-fingers" zu haben

    • stundenlang fsck(1M) auf dem Mail-Store laufen zu lassen ohne zu wissen wie lange es wirklich dauert

    • den Mail Server vom Backup zu restaurieren – dabei im Durchschnitt die letzten 12 Stunden zu verlieren

    – nicht zu wissen welche Mails betroffen sind

  • Thomas Nau, „ZFS & Co”Seite 5 ©2011 Thomas Nau

    in Platten Caches deren Firmware „winzige“ Prüfsummen

    RAID Controller mit mehr Firmware Caches und Batterien interner Verkabelung

    Glasfasern, Kabel und Stecker

    OK, alles nur eine Frage des Vertrauens ...

    Betriebssystemenoch mehr Firmwaremehr Kabel, Stecker usw.jede Menge Mikroelektronik"Anwendung"

  • Thomas Nau, „ZFS & Co”Seite 6 ©2011 Thomas Nau

    Was schief gehen kann wird schief gehen!

  • Thomas Nau, „ZFS & Co”Seite 7 ©2011 Thomas Nau

    Pre 03/2006 Mailserver Konfiguration @Ulm

    • Cluster aus redundanten Netzwerkverbindungen, Servern und RAID-5 Storage-Systemen

    • „logging UFS“ in Kombination mit dem Solaris Volume Manager

    • Backups mit „off-site“ Spiegeln

    SAN

  • Thomas Nau, „ZFS & Co”Seite 8 ©2011 Thomas Nau

    Pre 03/2006 Mailserver Konfiguration @Ulm

    Standort 1

    Standort 2

  • Thomas Nau, „ZFS & Co”Seite 9 ©2011 Thomas Nau

    Anfang 2006 … PANIC

    • System panic nach “freeing free inode”;„UFS logging“ hilft in diesem Falle nichts

    • der notwendige Filesystem check fsck(1m) dauerte >10 Stunden ohne die Möglichkeit auf die Daten zuzugreifen; fsck(1m) erfolgreich beendet, Problem gelöst?

    • kurz nach Aktivierung des mail Systems kommt es erneut zur "panic"

    • nach einem weiteren, ebenfalls nicht erfolgreichen, fsck(1m) Versuch wurden alle Daten auf ZFS kopiert; zum Glück konnte lesend auf die Daten zugegriffen werden

    • rsync() dauerte ca. 40 Stunden und ist nach dieser Erfahrung nicht das Tool der Wahl für solche Szenarien

  • Thomas Nau, „ZFS & Co”Seite 10 ©2011 Thomas Nau

    Analyse und offene Fragen

    • wir nehmen an, dass der Auslöser des Problems in einem ca. 4 Wochen zurückliegenden teilweisen Stromausfall und dem damit verbundenen Ausfall von FC-AL Ports gefolgt von einem RAID-System Absturz mit Cache-Verlust zu suchen ist

    • eine der ungeklärten Fragen– kann fsck(1m) im Zusammenspiel mit dem „round-robin“ Zugriff

    des Solaris Volume Managers (oder aller anderen) Probleme überhaupt zuverlässig erkennen und beheben?

  • Thomas Nau, „ZFS & Co”Seite 11 ©2011 Thomas Nau

    Gelernte Lektionen

    • wähle deine Tools sorgfälltig– ein Restore vom Backup hätte ca. 7 Stunden plus wenige Stunden

    für den erforderlichen finalen rsync() Lauf gedauert und hätte damit mindestens einen Tag gespart

    • teste sie

    • teste sie wieder und immer wieder– für unsere regelmäßigen Restore-Tests sind 8 Stunden als

    Obergrenze definiert

  • Thomas Nau, „ZFS & Co”Seite 12 ©2011 Thomas Nau

    Evolution: getrennte Wege gehen

    ZFS

    FC SwitchFC Switch

    ZFS

    FC Switch FC Switch

    Standort #1 Standort #2

  • Thomas Nau, „ZFS & Co”Seite 13 ©2011 Thomas Nau

    I/O Multipathing

    • Multipathing mit scsi_vhci(7D)

    • auch verwendbar mit 3rd party Storage Devices

    • transparentes fail-over bei Netzwerk- (iSCSI) oder Plattenausfällen

    • Statistik mit iostat -X 5

    poseidon:.../# mpathadm list lu /dev/rdsk/c4t600D023000641F0905DDBB6A6271B100d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c4t600D023000740A7D03F41F73A3B64B00d0s2 Total Path Count: 2 Operational Path Count: 2

  • Thomas Nau, „ZFS & Co”Seite 14 ©2011 Thomas Nau

    What about ...

    • IP Multipathing derzeit nicht im Einsatz– bei Solaris 10 im Zusammenspiel mit High Availability Services

    Adressen recht komplex

    – Ausfallwahrscheinlichkeit von NICs, Ports oder TP-Kabeln deutlich geringer als die von Platten, Speicher oder Netzteilen

    – Solaris 11 wird einiges vereinfachen

  • Thomas Nau, „ZFS & Co”Seite 15 ©2011 Thomas Nau

    Mission Critical: wie früh erkenne ich Fehler?

    • RAID Systeme decken nicht den kompletten Pfad der Daten ab, etwa keine FC-HBAs, …

    • Volume Manager können im Allgemeinen nicht entscheiden welcher Spiegel korrekte Daten enthält

    • Daten sind unterschiedlich wichtig– etwa Metadaten vs. Bilddaten oder MP3,

    letztere sind "by design" Verlust behaftet

  • Thomas Nau, „ZFS & Co”Seite 16 ©2011 Thomas Nau

    Troublemaker

    • entkoppelte Volume Manager wissen nichts über die Relevanz der verwalteten Daten– keine interne Replikation

    – keine Verteilung über die Platten oder deren Oberflächen

    – „round robin“ Zugriffe

    • Mathematik– Speicherdichte multipliziert mit der

    Fehlerrate kommt in problematische Größenordnungen

    ©Hawk Films Ltd.

  • Thomas Nau, „ZFS & Co”Seite 17 ©2011 Thomas Nau

    Die derzeit einzige echte Lösung: ZFS

    • erkennt Fehler an Hand "starker" Prüfsummen und korrigiert diese sofern mit Redundanz konfiguriert

    • integriert den Volume Manager– kein round-robin Problem

    • hat Wissen über die Relevanz von Daten– Pool Metadaten vs. "normale" Metadaten vs. Daten

    • senkt den Stresspegel der Administratoren

  • Thomas Nau, „ZFS & Co”Seite 18 ©2011 Thomas Nau

    Kleiner ZFS Ausflug zum besseren Verständnis

  • Thomas Nau, „ZFS & Co”Seite 19 ©2011 Thomas Nau

    ZFS Sicherheitsmechanismen

    • ZFS verwendet starke Prüfsummen (fletcher4, sha256) für alle Daten, nicht nur für Metadaten– diese werden nicht zusammen mit den Daten sondern im „Pointer“

    Bereich abgelegt

    – damit ist die Entscheidung welcher Teil des Spiegels die gültigen Daten enthält einfach zu treffen; alle anderen können ggf. korrigiert werden

    • „zpool scrub“ liest alle Daten, berechnet die Prüfsummen neu und korrigiert ggf. fehlerhafte Komponenten– mit unseren alten FC-AL Switches waren mehrere

    Prüfsummenfehler pro Monat „normal“; mit neuen Switches sind diese verschwunden

    – Tipp: scrub often; neue Versionen verwenden scrub-throttle

  • Thomas Nau, „ZFS & Co”Seite 20 ©2011 Thomas Nau

    Scrubbing eines 15TB Pools

    kronos:.../~# zpool status -v data pool: data state: ONLINE scan: scrub repaired 580K in 7h26m with 0 errors on Sun Oct 23 23:56:46 2011

    config:

    NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 c3t1d0 ONLINE 0 0 0 c4t1d0 ONLINE 0 0 3 212.5 repaired c5t1d0 ONLINE 0 0 0...

  • Thomas Nau, „ZFS & Co”Seite 21 ©2011 Thomas Nau

    ZFS Sicherheitsmechanismen

    • IO wird in Transaktionen mittels „copy-on-write“ (COW) durchgeführt– „Snapshots“ sind eine freie Zugabe

    – damit lassen sich große Datenmengen wie etwa Mail Verzeichnisse einfach und aus Sicht der Anwendung konsistent sichern

    • gültige Daten werden niemals überschrieben; kein fsck(1m)– ZFS garantiert nicht, dass die Daten auf die Platte geschrieben

    werden sondern „nur“ die Integrität (alles oder nichts)

  • Thomas Nau, „ZFS & Co”Seite 22 ©2011 Thomas Nau

    Automatisierte Snapshots

    • Cronjob / Daemon sorgt für regelmäßige Snapshots von ZFS Filesystemen und löscht alte Snapshots

    • es existieren mehrere vordefinierte smf(5) Instanzen– frequent, hourly, daily, weekly und monthly

    – Anzahl ist individuell konfigurierbar, bei uns 24 stündliche und 7 tägliche

    • Clones sind schreibbare Kopien eines Snapshots– nützlich für konsistente Backups sofern die Backup-Software,

    etwa TSM, nicht mit Snapshots zusammenarbeitet

    • erlauben Backup Paradigmenwechsel– unsere Backup Clients benötigen teilweise >16 Stunden um ein

    Filesystem zu durchsuchen

  • Thomas Nau, „ZFS & Co”Seite 23 ©2011 Thomas Nau

    ZFS Sicherheitsmechanismen

    • der integrierte Volume Manager kennt die Art der Daten, ca. 2% sind Metadaten

    • “ditto blocks”– Kopien, zwei- oder dreifach, wichtiger Metadaten

    • neuere ZFS Versionen (OpenIndiana, Solaris 11 Express) unterstützen auch Kopien von Datenblöcken (2 oder 3 fach)

    • poor mans mirror

    – werden über die Platten (vdevs) verteilt da Sektoren im Allgemeinen in größeren Gruppen lokal beieinander liegend ausfallen

    • im Fehlerfall ist dadurch die Navigation im Filesystem(cd, ls, ...) meist möglich

  • Thomas Nau, „ZFS & Co”Seite 24 ©2011 Thomas Nau

    Nützliche SAN Eigenschaften

    • zpools können mittels „import/export“ zwischen Systemen bewegt werden– wichtige HA Grundlage

    – kein paralleler Zugriff mehrerer Systeme; ZFS ist kein Cluster oder paralleles Filesystem

    • ZFS ist unabhängig von der Prozessor Architektur– EFI Labels sind Voraussetzung und werden als Voreinstellung

    verwendet

    – Daten werden immer in der nativen „byte-order“ geschrieben und ggf. beim lesen „korrigiert“

    • dies hat keinen Einfluss auf die Performance da es sich lediglich um die ZFS Metadaten handelt; alle anderen sind Sache der Anwendung

  • Thomas Nau, „ZFS & Co”Seite 25 ©2011 Thomas Nau

    Evolution: n-fach hält besser

    ZFSZFS

    Fiber Channel

    Standort #1 Standort #2

    Standort #1 Standort #2

    ZFSZFS

    iSCSI

    Standort #1 Standort #2

    Standort #1

    IMAP Replication

    unabhängige Technologien

  • Thomas Nau, „ZFS & Co”Seite 26 ©2011 Thomas Nau

    IMAP Replica

    • Feature des Cyrus IMAP-Servers– komplette Synchronisation inklusive der "client-flags"

    • Synchronisation erfolgt auf Anwendungsebene– damit unabhängig von Filesystem Replikation

    – erweiterter Schutz gegen Bugs im Betriebssystem

    • zusätzlich verwenden wir mit der Solaris 11 Implementierung von iSCSI (COMSTAR) eine gänzlich unabhängige Speichertechnologie

  • Thomas Nau, „ZFS & Co”Seite 27 ©2011 Thomas Nau

    Anmerkung am Rande: Rost oder Sand?

    Solid State Disks (SSDs)

    © Jeffrey Baron, Creative Common Attribution ShareAlike 3.0

    Festplatten

    © Dave Indech, GNU Free Documentation License

    • das ZFS intent log der iSCSI Server profitiert stark von SSDs sollte aber auf jeden Fall gespiegelt werden

  • Thomas Nau, „ZFS & Co”Seite 28 ©2011 Thomas Nau

    Evolution: Finger sind oft schneller als das Hirn

    • "delayed expunge" und "delayed mailbox delete"– Dateien bleiben 24 Stunden erhalten und sind damit "garantiert"

    im Snapshot und Backup

    • Probleme können beim Ausfall des Backup Servers entstehen

    – Mailboxen werden umbenannt (hidden) und ebenfalls erst nach einem Tag wirklich gelöscht

    – beide Zeitintervalle sind konfigurierbar

    • automatisierte ZFS Snapshots– 23 stündliche

    – 31 tägliche

  • Thomas Nau, „ZFS & Co”Seite 29 ©2011 Thomas Nau

    [email protected] v2011

    ZFSZFS

    Fiber Channel

    Standort #1 Standort #2

    Standort #1 Standort #2

    IMAP Replication

    unabhängige Technologien

    "gar

    anti

    erte

    s" T

    S M B

    acku

    p

    ZFSZFS

    iSCSI

    Standort #1 Standort #2

    Standort #1

  • Thomas Nau, „ZFS & Co”Seite 30 ©2011 Thomas Nau

    Zusammenfassung

    • IO Multipathing zu zwei Standorten (ca. 1km Entfernung)

    • ZFS– Sicherung von ZFS Clones dadurch in sich konsistente Backups

    – stündliche und tägliche Snapshots

    • IMAP "delayed expunge" und "delayed mailbox delete"– Mails können im Allgemeinen nach dem Löschen leicht und

    schnell wiederhergestellt werden

    – jede Mail findet sich im im Snapshot/Backup und kann für 3 Monate restauriert werden

    • zweiter, unabhängiger ZFS Pool durch IMAP-Replikation– Anbindung an Produktiv-Server als Desaster-Recovery

    vorkonfiguriert

  • Thomas Nau, „ZFS & Co”Seite 31 ©2011 Thomas Nau

    Einige Kennzahlen

    • Solaris 10 x86 (früher SPARC) als Grundlage

    • 15900 eingetragene Nutzer mit 135000 Mailboxen

    • Mailaufkommen:2005: 80000 SMTP-Verbindungen pro Tag2007: 900000 SMTP-Verbindungen pro Tag2010: 300000 SMTP-Verbindungen pro Tag

    • Daten-Volumen:2005: 3.500.000 Dateien / 50GB2006: 5.000.000 Dateien2007: 6.800.000 Dateien / 560GB2009: 12.000.000 Dateien / 1TB2010: 13.500.000 Dateien / 1.9 TB2011: 15.000.000 Dateien / 2.6 TB

    PDF/DOC Seuche;Email dient als

    Dokumentenablage

    PDF/DOC Seuche;Email dient als

    Dokumentenablage

  • Thomas Nau, „ZFS & Co”Seite 32 ©2011 Thomas Nau

    Mail Statistik Oktober 2011

  • Thomas Nau, „ZFS & Co”Seite 33 ©2011 Thomas Nau

    Ergebnis: Nagios Statistik 1/2010 - 10/2011

  • Thomas Nau, „ZFS & Co”Seite 34 ©2011 Thomas Nau

    Ausblick 2011/2012

    • Migration auf Solaris 11 und neue Hardware

    • Ersatz des Backup Konzeptes durch Snapshots und ZFS "remote replication"

    • Aufbau einer virtualisierten Test- und Staging Umgebung auf Basis von Solaris Containern und Crossbow

    • Evaluierung von IP-Multipathing in Solaris 11

    • Alternative zu Email als "Dokumentenablage"

  • Thomas Nau, „ZFS & Co”Seite 35 ©2011 Thomas Nau

    Danke und nicht vergessen ...

  • Thomas Nau, „ZFS & Co”Seite 36 ©2011 Thomas Nau

    ©LucasFilm

    Use TheTools!

    ©LucasFilm

    Folie 1Folie 2Folie 3Folie 4Folie 5Folie 6Folie 7Folie 8Folie 9Folie 10Folie 11Folie 12Folie 13Folie 14Folie 15Folie 16Folie 17Folie 18Folie 19Folie 20Folie 21Folie 22Folie 23Folie 24Folie 25Folie 26Folie 27Folie 28Folie 29Folie 30Folie 31Folie 32Folie 33Folie 34Folie 35Folie 36