Enterprise-Level Mail Systems Große Mailsysteme, kleine Schmerzen?

Präsentation zum Thema: "Enterprise-Level Mail Systems Große Mailsysteme, kleine Schmerzen?"—  Präsentation transkript:

1 Enterprise-Level Mail Systems Große Mailsysteme, kleine Schmerzen?

2 Copyright ©2002 by NetUSE AG2 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?

3 Copyright ©2002 by NetUSE AG3 Hardwarekonzept Mailserver doppelt –Jede Maschine kann für beide übernehmen Storage doppelt –jedes Array hat alle Daten Multipathing –Mehrere NICs –Mehrere Kabelwege System 1System 2 Storage 1 Storage 2 System 1 Storage 1 Storage 2 System 1System 2 Storage 2

4 Copyright ©2002 by NetUSE AG4 LDAP Replica Perdition Proxy 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 sendmail Cyrus master Cyrus imapd Cyrus pop3d Cyrus lmtpd Outside Mail Anwender Inside Mail Auth Routing SMTP POP3 IMAP4 POP3 IMAP4 LMTP SMTP

5 Copyright ©2002 by NetUSE AG5 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 5 mal seltener als die vorhergehende 10 mal seltener als die vorhergehende

6 Copyright ©2002 by NetUSE AG6 Skalierbarkeit II Anwendungsbeispiel: –~5000 User 700 zugleich verbunden 100 davon mit IMAP ergeben: –1400 MB RAM –3800 MB Swap –700+ MHz 27-63 GB Mailstore –kleines Modell (27 GB) 4500*2 MB 450*20 MB 45*200 MB –großes Modell (63 GB) 4500*2 MB 900*20 MB 180*200 MB

7 Copyright ©2002 by NetUSE AG7 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

8 Copyright ©2002 by NetUSE AG8 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

9 Copyright ©2002 by NetUSE AG9 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

10 Copyright ©2002 by NetUSE AG10 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