Skalierbarer IMAP-Server mit dem Cyr

Skalierbarer IMAP-Server
mit dem Cyrus Murder Cluster
Entzwei' und gebiete! Tüchtig Wort.
Verein' und leite! Bessrer Hort.
Johann Wolfgang von Goethe, Sprichwörtliches
3. Mailserver-Konferenz, Berlin, 2./3. Juli 2007
Frank Richter, URZ, TU Chemnitz
Ausgangspunkt: Zentraler Mailbox-Server der TU Chemnitz
Einordnung:
Ein zentraler Mailbox-Server - mailbox.hrz.tu-chemnitz.de
Mailboxen und Ordner von ca. 17.000 Benutzern
POP / IMAP, wahlweise SSL/TLS: bis 300 Tsd. Zugriffe / Tag
SMTP, wahlweise SSL/TLS: 35-80 Tsd. E-Mails / Tag
Separat: Webmail-Server: Horde/IMP
Gesamt:
davon
17781
125
46244
6426768
Mailbox-Größe:
Anzahl:
% Platz:
Mails/Mailbox:
Anzahl:
Mailboxen, 354.22 GB,
Gruppen-Mailboxen, 1.72
Subfolder, 13605 Nutzer
Mails,
0
788
0.0%
< 10
2074
< 1k
344
0.0%
./. 19921.1 kB / Mailbox
GB
./.
2.6
/ Mailbox
./. 361.4
/ Mailbox
< 10k < 100k
517
2145
0.0%
0.0%
< 100
6903
< 500
5168
< 1M
2989
0.3%
< 1000
1507
Besonderheiten:
Gruppen-Mailboxen für Funktions-Mailadressen
[email protected] > group.hrz.fax
ACLs: Berechtigungen auf Ordner
Die Anforderungen steigen ständig ...
Alles wächst: Nutzeranzahl, Nutzungsintensität, Speicherplatzbedarf
< 10M
4279
5.4%
<100M
6038
53.8%
< 10000
1422
<1 GB
681
40.4%
> 10000
33
>1 GB
0
0.0%
Monatliche Zugriffszahlen POP / IMAP
1999:
Intel Pentium III, 450 Mhz, 512 MB RAM, 80 GB Arena RAID
Red Hat 6.2 Linux, Cyrus, sendmail
2001:
AMD Athlon, 1 GHz, 1 GB RAM, 2 x 70 GB EIDE intern
Red Hat 6.2 Linux, Cyrus, Exim
2003:
2 x AMD Athlon, 1,8 GHz, 3 GB RAM, RAID System 440 GB
Red Hat 7.3 Linux (1 Standby, Kimberlite cluster), Cyrus, Exim
Wie weiter?
Ziele:
Skalierbares System
Transparent für Nutzer
Höhere Sicherheit vor Ausfällen
Perdition: Mail Retrieval Proxy
http://www.vergenet.net/linux/perdition/
Perdition is a fully featured POP3 and IMAP4 proxy server. It is able to handle Plain-Text, SSL and TLS
connections and connect end-users to a real-server based on a database lookup...
Perdition has many uses. Including, creating large mail systems where an end-user's mailbox may be stored
on one of several hosts, integrating different mail systems together, migrating between different email
infrastructures, and bridging plain-text, SSL and TLS services. It can also be used as part of a firewall.
Zuordnung von User zu realem Server anhand des
username im Login
Kein Zugriff auf shared folders, die auf anderen
Servern liegen
Mail-Zustellung an reale Server muss separat
organisiert werden
Cyrus Murder: IMAP Aggregator
http://cyrusimap.web.cmu.edu/ag.html
The Cyrus IMAP Aggregator transparently distributes IMAP and POP mailboxes across multiple servers.
Unlike other systems for load balancing IMAP mailboxes, the aggregator allows users to access mailboxes
on any of the IMAP servers in the system ...
The Cyrus aggregator takes a murder of IMAP servers and presents a server independent view to the
clients. That is, all the mailboxes across all the IMAP servers are aggregated to a single image, thereby
appearing to be only one IMAP server to the clients.
Frontend-Server:
Vermittelt zwischen
E-Mail-Klienten und
Backend-Servern
(IMAP/POP proxy)
Optional: Organisiert
Mail-Zustellung (LMTP
proxy)
dataless
Backend-Server:
Speichert E-Mails und
Meta-Daten für
Teilmenge der Benutzer
An sich voll funktionaler
IMAP/POP-Server
MUPDATE-Server:
Authoritative Daten über
alle Mailboxen der
Backend-Server
Unified murder:
Backends sind auch Frontend: Eigene Mailboxen selber, andere per proxy an anderen Backend
Replicated murder:
Backends haben vollständige replizierte Kopien aller Mailboxen
/etc/imapd.conf
mupdate_config: unified | replicated
Frontend-Server
POP/IMAP
Kommunikation mit E-Mail-Klienten
Authentisierung via SASL
POP: Weiterleiten zu entsprechendem Backend
IMAP: Protokollanalyse, je nach Request weiter an entsprechenden Backend (Proxy) oder
selber: LIST
evtl. IMAP REFERRAL: Weiterleiten des Klienten an Backend - ausgeschaltet (patch)
Lokalisierung
Kontaktiert MUPDATE-Master-Server: Auf welchem Backend liegt welcher Ordner?
Speichert lokal (MUPDATE-Slave)
SMTP (Exim)
Entgegennahme von lokalen Sendern
Weiterleiten an Relay, oder
lokale Zustellung
LMTP
Lokalisierung Mailbox (MUPDATE)
Zustellung an entsprechenden Backend
Auch auslagerbar auf beliebigen SMTP-Server (LTMP proxy)
Backend-Server
Speichert Mails und Meta-Daten
POP/IMAP:
Authentisierung von Frontend (auch direkt von Klienten) via SASL
IMAP-Operationen bezüglich Ordner (CREATE, DELETE, RENAME, SETACL) in
Abstimmung mit MUPDATE-Server
LTMP
nur authentisiert von LMTP-Proxy (Frontend)
Sieve: Ablegen, Weiterleiten, Verwerfen ...
Ggf. sichern via /etc/hosts.allow
...
# Nur Frontend-Server duerfen LMTP
lmtp
: 134.109.133.154 134.109.133.156
lmtp
: ALL : twist=/bin/echo 221 %H closing connection
MUPDATE-Server
Besitzt authoritative Daten über alle Mailboxen: Namen, Backend-Server, Partition, ACLs
-> mailboxes.db (wiederherstellbar von Backends)
user.fri
1 tiberius.hrz.tu-chemnitz.de!d fri lrswipcda
group.ub.s4 1 augustus.hrz.tu-chemnitz.de!b hot lrswipcda
brantl lrswipd
RFC 3656: The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
Backend-Server stimmen Änderungen (neue/gelöschte Ordner, Änderungen in ACL) ab
Informiert MUPDATE-Slave-Server auf Frontends über Änderungen
Authentisierung der Frontend-/Backend-/LMTP-Proxy-Server via SASL
/etc/cyrus.conf
SERVICES {
# MUPDATE Master:
mupdate
cmd="mupdate -m" listen=3905 prefork=1
...
}
Authentisierung ... SASL
anyon
1. Nutzerauthentisierung
Mail-Klienten gegenüber Frontend
Kerberos5, Plain: PAM -> Kerberos, user_db
Frontend: /etc/imapd.conf
sasl_mech_list: PLAIN GSSAPI
# via saslauthd -> PAM
sasl_pwcheck_method: saslauthd
Daemon: saslauthd -a pam
/etc/pam.d/imap
#%PAM-1.0
auth
auth
account
sufficient
required
required
pam_krb5.so
pam_userdb.so db=/etc/can
pam_permit.so
2. Proxy-Authentisierung
Frontend/LMTP-Proxy gegenüber Backend
Hier: Authentisierung via DIGEST-MD5 (sasldb2), nur ein Admin user
Frontend: /etc/imapd.conf
# So meldet sich der Frontend zum Backend
proxy_authname: frontend
proxy_password: **********
Backend: /etc/imapd.conf
servername: real-host.domain.tld
sasl_pwcheck_method: auxprop
sasl_mech_list: DIGEST-MD5
admins: cyrus frontend
proxyservers: frontend
saslpasswd2 -c -u real-host.domain.tld frontend
3. MUPDATE-Authentisierung
Frontend/Backend gegenüber MUPDATE-Server
Hier: Authentisierung: DIGEST-MD5 (sasldb2), nur ein Admin user
Frontend/Backend: /etc/imapd.conf
# So wird der MUPDATE master erreicht:
mupdate_server: host.domain.tld
mupdate_port: 3905
mupdate_username: mupdate
mupdate_authname: mupdate
mupdate_password: ********
MUPDATE: /etc/imapd.conf
servername: generic.domain.tld
sasl_pwcheck_method: auxprop
sasl_mech_list: DIGEST-MD5
admins: mupdate
saslpasswd2 -c -u generic.domain.tld mupdate
Realisierung an TU Chemnitz
Hardware:
1 Frontend-Server (+ 1 standby): AMD Athlon 64 X2 Dual Core Processor 5200+, 4 GB RAM
/etc/cyrus.conf
/etc/imapd.conf
2 Backend-Server: AMD Athlon 64 X2 Dual Core Processor 5200+, 4 GB RAM, Fiberchannel ->
SAN (Sun StorageTek 6540, z.Z. 1,2 TB, xfs)
/etc/cyrus.conf
/etc/imapd.conf
1 MUPDATE-Server: AMD Athlon MP 2200+, 3 GB RAM
/etc/cyrus.conf
/etc/mupdate-master.conf
/etc/imapd.conf
Betriebssystem:
Linux 2.6.X, Scientific Linux 4
Software:
Cyrus 2.3.X - cyrus-imap RPM von Simon Matter, invoca.ch
Exim 4.X + Virencheck (ClamAV)
Selbst gebaut - Admin-Tools:
Anlegen/Löschen von Mailboxen, Monitoring, Routine-Arbeiten (Quota, restore), Statistik
Migration
Vorbereitung:
E-Mail-Daten + cyrus.* per rsync auf neue Server (nachts im laufenden Betrieb)
Partition a, b -> Backend1 / c, d -> Backend2
Skript zur Aufteilung der Meta-Daten
Anpassung eigener Admin-Skripte ...!
Umstellung:
alter Server: Stop, letztes rsync
DNS umstellen (neue IP-Adresse)
Metadaten (mailboxes.db, Sieve, seen) per Skript "aufteilen"
Start MUPDATE-Server (leer)
Start Backend: ctl_mboxlist -m -a
synchronize the local mailbox list file with the MUPDATE server. local mailboxes file is
authoritiative
Start Frontend
Denkbar:
Bisheriger single Server wird Backend-Server
Ergebnis
3 Stunden downtime -> up and running
Transparenz für Nutzer ... ok, IP-Adressänderung
robust und schnell
Load: Frontend 0.5 - 3.0, Backends < 1, MUPDATE << 1
MUPDATE-Server tunen - /etc/imapd.conf:
mupdate_connections_max: 1024
mupdate_workers_max: 200
mupdate_workers_minspare: 10
mupdate_workers_maxspare: 30
mupdate_workers_start: 15
Ausfallszenarien:
Frontend: Umschaltung auf anderen Frontend (Layer4-Switch)
MUPDATE: keine Mail-Zustellung, keine neuen Ordner
Backend: Mailboxen weg, Frontend "läuft zu"
Probleme:
Mailbox auf anderen Backend verschieben
kleinere Bugs (x86_64 ...)
Sieve: Ablegen in Ordner auf anderem Backend:
fileinto "group.anderer.backend";
Goodies: Backup - Restore
Verzögertes Löschen:
Bei EXPUNGE oder DELE wird Löschwunsch vermerkt: cyrus.expunge
Mail-Dateien bleiben stehen: schnell
Backend: /etc/imapd.conf
expunge_mode: delayed
Wirkliches Löschen zeitgesteuert
/etc/cyrus.conf
EVENTS {
...
# expire messages (delayed expunge) and duplicate delivery database entries
# Mails verwerfen, die vor 7 Tagen vom Nutzer gelöscht wurden
delprune
cmd="cyr_expire -E 3 -X 7" at=0403
}
Zugriff auf gelöschte Mails durch Admin:
/usr/lib/cyrus-imapd/unexpunge ...
Restore von Mails bis 7 Tage sehr schnell
Außer: Löschen eines gesamten Ordners - da ist alles weg
Zusätzlich: rsync auf anderes RAID
Todo ...
Trennung SMTP (+ Virenchecker) und IMAP/POP via Layer4-Switch
redundante Frontends
evtl. Synchronisieren: Spiegeln der Backends gegenseitig
Gruppen-Management für ACLs
notify (VoIP, SMS)
Backup mit Snapshots / ISCSI