Fallstricke und Vorsichtsmaßnahmen einer mid-sized Mail Infrastruktur

Transkript

1 Fallstricke und Vorsichtsmaßnahmen einer mid-sized Mail Infrastruktur Thomas Nau, kiz Page 1

2 Übersicht Vorstellung alte Mailserver Konfiguration und deren Probleme Nachbesserungen Putting it together Zusammenfassung Q&A Page 2

3 Nein, es geht nicht um Diskussionen über SPAM, Viren, sendmail vs. Postfix, Page 3

4 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 Beschäftigte uns ca Studenten die Universitäten Stuttgart und Konstanz Page 4

5 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 Anschlüssen unter Einsatz von VoIP und 2-Draht Technik Ausbildung von 6 Azubis Page 5

6 Warnung... Im Bezug auf sind wir ein bisschen paranoid... auch wenn manche der Meinung sind wäre tot. Universal Pictures Page 6

7 Mail Facts Solaris x86 als Grundlage eingetragene Nutzer Mailboxen Mailaufkommen: 2005: 2007: 2010: SMTP-Verbindungen pro Tag SMTP-Verbindungen pro Tag SMTP-Verbindungen pro Tag Daten-Volumen: 2005: 2006: 2007: 2009: 2010: 2011: Page Dateien / 50GB Dateien Dateien / 560GB Dateien / 1TB Dateien / 1.9 TB Dateien / 2.6 TB PDF/DOC PDF/DOCSeuche Seuche

8 Jahresstatistik 3/2010-3/2011 Page 8

9 Pre 03/2006 Mailserver 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

10 Pre 03/2006 Mailserver Server 1 Server 2 Page 10

11 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

12 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

13 Was schief gehen kann wird schief gehen! Page 13

14 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

15 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

16 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

17 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

18 Evolution: Wegerecht Standort #1 FC Switch Standort #2 FC Switch FC Switch FC Switch ZFS Page 18 ZFS

19 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/c4t600d f0905ddbb6a6271b100d0s2 Total Path Count: 2 Operational Path Count: 2 /dev/rdsk/c4t600d a7d03f41f73a3b64b00d0s2 Total Path Count: 2 Operational Path Count: 2 Page 19

20 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

21 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

22 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

23 Kleiner ZFS Ausflug zum späteren besseren Verständnis Page 23

24 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

25 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: config: NAME data raidz2-0 c7t1d0 c8t1d0... Page 25 STATE ONLINE ONLINE ONLINE ONLINE READ WRITE CKSUM

26 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

27 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

28 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"

29 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

30 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

31 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

32 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

33 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)

34 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

35 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

36 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

37 Ergebnis: Nagios Jahresstatistik 3/2010-3/2011 HA gli tc h es Page 37 we rde n nic ht e rf ass t

38 Danke! Page 38