ZFS & Co Die Vorteile von Solaris für ausfallsichere Mailsysteme Thomas Nau, kiz (thomas.nau@uni-ulm.de) Seite 1
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 Seite 2
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. Universal Pictures Seite 3
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 Seite 4
OK, alles nur eine Frage des Vertrauens... RAID Controller mit mehr Firmware Caches und Batterien interner Verkabelung in Platten Caches deren Firmware winzige Prüfsummen Glasfasern, Kabel und Stecker Seite 5 Betriebssysteme noch mehr Firmware mehr Kabel, Stecker usw. jede Menge Mikroelektronik "Anwendung"
Was schief gehen kann wird schief gehen! Seite 6
Pre 03/2006 Mailserver Konfiguration @Ulm Cluster aus redundanten Netzwerkverbindungen, Servern und RAID-5 Storage-Systemen SAN logging UFS in Kombination mit dem Solaris Volume Manager Backups mit off-site Spiegeln Seite 7
Pre 03/2006 Mailserver Konfiguration @Ulm Standort 1 Standort 2 Seite 8
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 Seite 9
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 CacheVerlust 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? Seite 10
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 Seite 11
Evolution: getrennte Wege gehen Standort #1 FC Switch Standort #2 FC Switch FC Switch FC Switch ZFS Seite 12 ZFS
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 Seite 13
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 Seite 14
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 Seite 15
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 Hawk Films Ltd. Seite 16 Speicherdichte multipliziert mit der Fehlerrate kommt in problematische Größenordnungen
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 Seite 17
Kleiner ZFS Ausflug zum besseren Verständnis Seite 18
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 Seite 19
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 data raidz2-0 c3t1d0 c4t1d0 c5t1d0 STATE ONLINE ONLINE ONLINE ONLINE ONLINE READ WRITE CKSUM 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 212.5 repaired... Seite 20
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) Seite 21
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 Seite 22
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 Seite 23
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 Seite 24
Evolution: n-fach hält besser Standort #1 Standort #1 Standort #2 IMAP Replication Fiber Channel Seite 25 iscsi unabhängige Technologien ZFS ZFS ZFS ZFS Standort #1 Standort #2 Standort #1 Standort #2
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 Seite 26
Anmerkung am Rande: Rost oder Sand? das ZFS intent log der iscsi Server profitiert stark von SSDs sollte aber auf jeden Fall gespiegelt werden Dave Indech, GNU Free Documentation License Jeffrey Baron, Creative Common Attribution ShareAlike 3.0 Festplatten Seite 27 Solid State Disks (SSDs)
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 Seite 28
Mail@Ulm v2011 Standort #1 Standort #1 Standort #2 "garantiertes" TSM Backup IMAP Replication Seite 29 Fiber Channel iscsi unabhängige Technologien ZFS ZFS ZFS ZFS Standort #1 Standort #2 Standort #1 Standort #2
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 Seite 30
Einige Kennzahlen Solaris 10 x86 (früher SPARC) als Grundlage 15900 eingetragene Nutzer mit 135000 Mailboxen Mailaufkommen: 2005: 2007: 2010: 80000 SMTP-Verbindungen pro Tag 900000 SMTP-Verbindungen pro Tag 300000 SMTP-Verbindungen pro Tag Daten-Volumen: 2005: 2006: 2007: 2009: 2010: 2011: Seite 31 3.500.000 Dateien / 50GB 5.000.000 Dateien 6.800.000 Dateien / 560GB 12.000.000 Dateien / 1TB 13.500.000 Dateien / 1.9 TB 15.000.000 Dateien / 2.6 TB PDF/DOC PDF/DOCSeuche; Seuche; Email dient Email dientals als Dokumentenablage Dokumentenablage
Mail Statistik Oktober 2011 Seite 32
Ergebnis: Nagios Statistik 1/2010-10/2011 Seite 33
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" Seite 34
Danke und nicht vergessen... Seite 35
Use The Tools! Seite 36 LucasFilm