Fallstricke und Vorsichtsmaßnahmen einer mid-sized Mail Infrastruktur Thomas Nau, kiz (thomas.nau@uni-ulm.de) Page 1
Übersicht Vorstellung alte Mailserver Konfiguration und deren Probleme Nachbesserungen Putting it together Zusammenfassung Q&A Page 2
Nein, es geht nicht um Diskussionen über SPAM, Viren, sendmail vs. Postfix, Page 3
kiz, Kommunikations- und Informationszentrum 2002 aus den ehemaligen Bereichen Rechenzentrum, Bibliothek, Telekommunikation und der Zentrale für Foto, Grafik und Reproduktion gegründet 100+ Beschäftigte in 5 Abteilungen erbringt Dienstleistungen für 4 Fakultäten Ingenieurwissenschaften und Informatik Mathematik und Wirtschaftswissenschaften Medizin Naturwissenschaften ca. 3.000 Beschäftigte uns ca. 8.000 Studenten die Universitäten Stuttgart und Konstanz Page 4
Abteilung Infrastruktur tolles Team aus 25 Personen kümmert sich unter anderem um Cluster basierende universitätsweite Mail-, LDAP-, Portal-, Datenbank- und File-Services Backup Service für die Universitäten Konstanz und Ulm HPC Cluster für die Universitäten in Konstanz, Stuttgart und Ulm x86 / SPARC Linux / Solaris 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 Page 5
Warnung... Im Bezug auf Email sind wir ein bisschen paranoid... auch wenn manche der Meinung sind Email wäre tot. Universal Pictures Page 6
Mail Facts Solaris x86 als Grundlage 14000 eingetragene Nutzer 120000 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: Page 7 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
Jahresstatistik 3/2010-3/2011 Page 8
Pre 03/2006 Mailserver Konfiguration @Ulm Cluster aus redundanten Servern, RAID-5 Speicher Systemen und Netzwerkverbindungen SAN logging UFS in Kombination mit dem Solaris Volume Manager Backups mit off-site Spiegeln Page 9
Pre 03/2006 Mailserver Konfiguration @Ulm Server 1 Server 2 Page 10
Scenarios that suck! nichts von Fehlern zu wissen die in den Daten bzw. dem Filesystem bereits vorhanden sind stundenlang fsck(1m) auf Ihrem Mail-Store laufen zu lassen den Mail Server vom Backup zu restaurieren und dabei im Mittel die letzten 12 Stunden zu verlieren Page 11
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 Page 12 Betriebssysteme immer noch mehr Firmware mehr Kabel, Stecker usw. jede Menge Mikroelektronik
Was schief gehen kann wird schief gehen! Page 13
Naja, fast Anfang 2006 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 Page 14
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? Page 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. Page 16 Speicherdichte multipliziert mit der Fehlerrate kommt in problematische Größenordnungen
Gelernte Lektion wähle deine Tools sorgfälltig eine 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 wir versuchen bei unseren regelmäßigen Restore-Tests unter der magischen Grenze von 8 Stunden zu bleiben, sportlich oder? Backup Paradigmenwechsel steht bei uns bevor Page 17
Evolution: Wegerecht Standort #1 FC Switch Standort #2 FC Switch FC Switch FC Switch ZFS Page 18 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 Page 19
What about... IP Multipathing bei Solaris 10 im Zusammenspiel mit High Availability Services Adressen recht komplex Ausfallwahrscheinlichkeit von NICs, Ports oder TP-Kabeln deutlich höher als die von Platten, Speicher oder Netzteilen Solaris 11 soll einiges vereinfachen Page 20
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 Page 21
Die derzeit einzige(?) Lösung: ZFS kann Fehler an Hand "starker" Prüfsummen erkennen und darüber informieren ggf. korrigieren integriert den Volume Manager kein round-robin Problem hat Wissen über die Relevanz von Daten Pool Metadaten vs. "normale" Metadaten vs. Daten hilft uns nach dem geschilderten fast GAU wieder besser zu schlafen Page 22
Kleiner ZFS Ausflug zum späteren besseren Verständnis Page 23
ZFS Sicherheitsmechanismen ZFS verwendet 256 Bit Prüfsummen 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 Page 24
Scrubbing eines 15TB Pools kronos# zpool scrub data kronos# zpool status -v data pool: data state: ONLINE scan: scrub repaired 138K in 4h10m with 0 errors on Sat Mar 19 19:37:39 2011 config: NAME data raidz2-0 c7t1d0 c8t1d0... Page 25 STATE ONLINE ONLINE ONLINE ONLINE READ WRITE CKSUM 0 0 0 0 0 0 0 0 0 0 0 0
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) Page 26
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 aufzuhebende Anzahl ist individuell konfigurierbar, bei uns 24 stündliche und 7 tägliche Page 27
Clones schreibbare Kopien eines Snapshots nützlich für konsistente Backups sofern die Backup-Software, etwa TSM, nicht mit Snapshots zusammenarbeitet in dsm.sys: preschedulecmd postschedulecmd /mail/sw/tools/createbackupclone.sh /mail/sw/tools/destroybackupclone.sh CreateBackupClone.sh klont den letzten täglichen Snapshot zfs zfs zfs zfs zfs zfs Page 28 clone "$snap" "$fs/$clone" set mountpoint="$backupdir/$fs" "$fs/$clone" set atime=off "$fs/$clone" set "com.sun:auto-snapshot=false" "$fs/$clone" set "com.sun:auto-snapshot:mail-hourly=false" "$fs/$clone" set "com.sun:auto-snapshot:mail-daily=false" "$fs/$clone"
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 (OpenSolaris, 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 Page 29
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 Metadaten handelt; alle anderen sind Sache der Anwendung Page 30
Evolution: n-fach hält besser Standort #1 Standort #1 Standort #2 IMAP Replication Fiber Channel Page 31 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 eine gänzlich unabhängige Speichertechnologie Page 32
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 Page 33 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 Page 34
Mail@Ulm v2011 Standort #1 Standort #1 Standort #2 "garantiertes" TSM Backup IMAP Replication Page 35 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 Backup von ZFS Clones dadurch in sich konsistente Backups Cyrus-IMAP Features "delayed expunge" und "delayed mailbox delete" Mails können innerhalb eines Tages nach dem Löschen leicht und schnell wiederhergestellt werden jede Mail landet im Snapshot/Backup und kann für ca. 3 Monate restauriert werden zweiter, unabhängiger ZFS Pool durch IMAP-Replikation Anbindung an Produktiv-Server als Desaster-Recovery vorkonfiguriert Page 36
Ergebnis: Nagios Jahresstatistik 3/2010-3/2011 HA gli tc h es Page 37 we rde n nic ht e rf ass t
Danke! Page 38