Enterprise Mail: große Mailsysteme, kleine Schmerzen

Enterprise Mail
Folien für eine interne Mitarbeiterschulung: Umzug und Erweiterung des Mailsystems bei mobilcom.de; für die evangelische Landeskirche Schleswig-Holstein; für Ver.di.
Was ist Enterprise Level?
Ausfallsicher
- bei Hardwareschaden
- bei Mailwellen
Skalierbar
- über alle User
- pro User
- Mails pro Ordner
- Order pro User
- pro Standort
- pro Domain
Integrierbar
- keine Firma ab einer bestimmten Größe hat ein homogenes Mailsystem
- unterschiedliche Zugänge
- für Anwender: POP3/IMAP4, mit SSL?, über Web?
- Für Anwendungen: Virus-Scanner? Mailinglisten? Pflegeinterfaces?
Mail ist missionskritisch, inhomogen, Lock-In unbedingt vermeiden. Offene Software, offene Protokolle -> freie Wahl der Clients, freie Wahl der Serverkomponenten (Soft- und Hardware)
bessere Skalierbarkeit, bessere Erweiterbarkeit, bessere Integrierbarkeit ins Backend
Hardwarekonzept
Mailserver doppelt
- Jede Maschine kann für beide übernehmen
Storage doppelt
- jedes Array hat alle Daten Multipathing
- Mehrere NICs
- Mehrere Kabelwege
Sehr zufrieden mit dem Hardware-Range von Sun: Hardware für jede Größe von der kleinen X1 bis zur E15K, Software ist portabel über den gesamten Range.
Großer Schwerpunkt auf ausfallsichere Hardware:
- Monitoring
- Multipathing
- Hot Plug
Ausfallszenarien:
- Kiste fällt aus
- Migration der IP
- Migration der Platten
- Platte fällt aus
- RAID 1 (Veritas)
Softwarekonzept
Einsatz von Standardprotokollen
- POP3, IMAP4, LMTP, SMTP, LDAP
Einsatz von Standardsoftware
- sendmail 8.12.1, Cyrus IMAP, perdition Proxy, Veritas (VM, FS, CS), iPlanet Directory 4.x, Interscan Viruswall
iPlanet war vorgegeben, da das führende LDAP iPlanet war.
Veritas war vorgegeben, hat sich als sehr gute Wahl herausgestellt: Entwicklung von failover-Scripten harmlos.
Viruscheck vorgegeben: InterScan im Einsatz bei NetUSE, Kunden arbeiten auch mit Amavis und NAI oder anderen Systemen.
eigentliche Arbeitstiere sind freie Software:
- sendmail 8.12.1 hat bessere LDAP-Integration
- sendmail ist eigentlich ein MTA-SDK :-)
- perdition ist ein sehr leistungsfähiger Proxy
- Plugin-Architektur
- extrem gutmütig im Deployment
- übersichtlicher Code
- cyrus ist ein sehr skalierbarer POP/IMAP-Server
- schlecht dokumentiert
- eigenwillige Authentisierungsbibliothek SASL (Exkurs)
- ordentliche Architektur
Skalierbarkeit
Sizing
- per User: 1 MB RAM, 2 MB Swap, 1 MHz
- IMAP braucht mehr
- SSL braucht mehr!
- angemessen Plattenplatz
Wieviel Plattenplatz ist angemessen?
- 3 Kategorien
- 2 MB, 20 MB, 200 MB
- Jede Kategorie ist
- (großes Modell) 5 mal seltener als die vorhergehende
- (kleines Modell) 10 mal seltener als die vorhergehende
Skalierbarkeit II
Anwendungsbeispiel: ~5000 User
- 700 zugleich verbunden, 100 davon mit IMAP ergeben:
- 1400 MB RAM, 3800 MB Swap, 700+ MHz
27 oder 63 GB Mailstore
- kleines Modell (27 GB)
- 45002 MB + 45020 MB + 45*200 MB
- großes Modell (63 GB)
- 45002 MB + 90020 MB + 180*200 MB
Zahlen wurden auf Linux/Intel ermittelt, und an eigener Cyrus-Installation validiert. Zahlen an der Ist-Installation des Kunden validiert. Skalierbarkeit weitgehend linear. Problem ist partitionierbar.
Migration
Konvertierung
- des vorhandenen Mailstore, der vorhandenen Aliases, der vorhandenen Listeninfrastruktur, der vorhandenen Routingstruktur
Nahtlose Migration durch “Rückzug”:
- “Wechsel von Kopfsteinpflaster auf Autobahn während der Hauptreisezeit”
- Vorbereitung der Konvertierung
- Umstellung auf das neue System
- Durchrouten auf das alte System
- Während der Konvertierung “Rückzug” auf das neue System
Konvertierung des Ist-Bestandes ist aufwendiger, fehleranfälliger als geplant.
System ist grundsätzlich funktionsfähig; Umstellung ist wesentlich holperiger gewesen als intendiert; Umstellungsaufwand auch bei den Anwendern
Migration II
Typische Probleme:
- lustige Ordernamen (IMAP)
- defekte Aliasdaten
- Datenbestand nicht komplett
- wechselndes Mailrouting
- Hosts liefern mit unerwarteten Namen ein
- LDAP-Routing verhält sich anders als statisches Routing
Umstellung für IMAP-Clients nicht transparent
- CAPABILITY
- IMAP Subscriptions
- Ordnernamen
- Lage des Sent-Folders
Umstellung für POP3-Clients weitgehend transparent
- triviales Protokoll
- nicht erweiterbar
- finaler Mailstore auf dem Client
IMAP ist ein modulares Protokoll: Extensions sind nicht kompatibel, Normung ist nicht rigide genug. Propietäre Erweiterungen machen den Wechsel schwer Unterschätze niemals den Einfallsreichtum von Anwendern bei der Vergabe von Ordnernamen. Unterschätze niemals die tägliche Zielverschiebung durch das Tagesgeschäft.
Weitere Szenarien
Verteiltes Setup: 50+ Standorte, Workgroup-Size pro Standort, zentrale Administration, Begrenzte Hardwarekapazität
Großes Setup
- 70 000+ Anwender
- Mailstore im TB-Bereich
- Virenscan
- muß skalierbar sein
- Quota
- Webmail Zugang
- muß skalierbar sein
- zentrale Bulk-Administration
- Integration in existierende Stammdatenverwaltung
Weitere Szenarien II
Zu erwartende Ausbaumöglichkeiten:
- Calendaring
- lokaler Client
- Web Access
- mehr Verschlüsselung
- Key Management
- Storage Management
- Migration alter Mail in Hintergrundspeicher
- Retrieval alter Mail
- Sichere Löschung alter Mail
- Mailtracking