© Deutsche Post

Mehrere unterschiedlich konfigurierte Instanzen eines Postfix-Servers auf einer Maschine – mit der neuesten Version kein Problem. Der neue Multiple-Instance-Manager verteilt die Sendungen.

Mailserver gehören zu jenen Servern, die am meisten unter Stress stehen. Besonders ärgerlich ist es dann, wenn überlastete SMTP-Partner die Mailzustellung ausbremsen. Dann stecken auch schnell zustellbare Sendungen in der Warteschlange fest, während der Server die den Stau auslösenden Mails an die Mailingliste in Lummerland eigentlich auch nachts zustellen könnte, ohne großes Aufsehen zu verursachen.

Multiple Instance

Mit dem jüngst erschienenen Mailserver Postfix 2.6 ([1], [2]) lassen sich derartige Konzepte erstmals einfach und unabhängig umsetzen. Der eingebaute Multiple-Instance-Manager (MIM, [3]) verwaltet mehrere, unterschiedlich konfigurierte Postfix-Instanzen auf ein und demselben Server [4]. Der Administrator arrangiert mit ihm ehemals kopfzerbrechend komplexe Konfigurationen in einfachen, leicht zu verwaltenden Setups.

Diese Instanzen laufen nahezu vollständig getrennt voneinander, jede hat ihre eigene Konfiguration in einem eigenen Verzeichnis und ihre eigene Warteschlange. Gemeinsam nutzen sie Ressourcen nur dann, wenn es ökonomischer ist, zum Beispiel beim Zugriff auf die Postfix-Binaries (Smtpd, Qmgr, Smtp) und die Dokumentation.

Das Ganze lohnt sich in der Regel immer dann, wenn ein Mailserver mehrere unterschiedliche Aufgaben verrichtet, also praktisch fast immer. Dementsprechend zahlreich sind die Einsatzmöglichkeiten, ein zweigeteiltes Postfix (siehe Abbildung 1) nutzt beispielsweise eine Instanz, um Mail vom Intranet in die Welt zu versenden. Die zweite Instanz besitzt eine völlig eigenständige Konfiguration (und Warteschlange) und führt für alle eingehenden Mails die Spam- und Viren-Erkennung beim Transport vom Internet ins Intranet durch.

Abbildung 1: Zwei getrennte Instanzen eines Postfix-Servers kontrollieren unabhängig voneinander Mail-Eingang und -Ausgang. Dabei bleiben Ressourcen wie Warteschlangen vollständig getrennt.

So verfügt der Postmaster über zwei sauber getrennte Instanzen und Queues, die er separat kontrolliert. Ein Stopp, Start oder gar Flush betrifft immer nur die ein- oder die ausgehenden Mails.

Fast Lane

Gerade rund ums Content Filtering lassen sich mit den unabhängigen Instanzen interessante Konstrukte bauen: In der Postfix-Dokumentation (»MULTI_INSTANCE_README«, [3]) findet sich ein Beispiel mit einer Instanz vor und einer hinter einem »content_filter«. Das folgende Setup dagegen soll zeigen, wie sich die Performance des Mailservers verbessern lässt, indem der Admin Postfix in zwei Instanzen aufteilt und so den Durchsatz des Servers steigert.

Eine aggressiv konfigurierte Instanz versucht Nachrichten so schnell wie möglich auszuliefern. Gelingt ihr das nicht im ersten Anlauf, reicht sie die Nachricht via »$smtp_fallback_relay« an die zweite, konservativ konfigurierte Instanz weiter. Die unternimmt in aller Ruhe weitere Zustellungsversuche und bounct die Nachricht auch an den Absender, falls das Ziel gar nicht erreichbar ist.

Getunt

Damit nicht genug, auch die Warteschlangen der aggressiven Instanz sind auf Geschwindigkeit getrimmt. Die Queue hat der Admin in den Arbeitsspeicher verlegt, um den Engpass der vergleichsweise langsamen Festplattenzugriffe aufzubohren. Offensichtliches Problem an dieser Lösung ist jedoch, dass der Inhalt des Arbeitsspeichers flüchtig ist. Die bei einem Servercrash in der RAM-Queue abgelegten E-Mails wären verloren.

In der alltäglichen Praxis scheint diese Nebenwirkung erträglich, vor allem weil sich eine Mail nur kurze Zeit in der ersten Instanz befindet. Entweder sie kommt sofort zur Zustellung und landet damit auf einem entfernten Server oder Postfix reicht sie nach dem ersten, erfolglosen Versuch umgehend an die zweite, konventionelle und damit Queue-sichere Instanz durch. Das Risiko scheint den Autoren gering angesichts des Geschwindigkeitsgewinns.

Schnell fällt dem Admin die simple Konfiguration der Instanzen auf, die sich kaum von der gewohnten Postfix-Konfiguration unterscheidet. Die konservative, konventionell konfigurierte Instanz entspricht ohnehin weitgehend der Standardinstallation. Nur die aggressive Komponente verlangt ein wenig Vorarbeit, vor allem wegen der Verlagerung der Queues in den Arbeitsspeicher. Als Mountpoint der RAM-Disk bietet sich der Name der Instanz an, zum Beispiel mit »/var/spool/postfix-ram«. »/etc/fstab« legt die Rahmenbedingungen fest:

/dev/shm/var/spool/postfix-ram tmpfs defaults,noexec,nodev,nosuid,noatime,size=50m,mode=770,uid=0,gid=0 0 0

Die RAM-Disk braucht nicht sonderlich groß ausgelegt zu sein, die 50 MByte im Beispiel reichen meistens völlig. Schließlich ist es weder erwünscht noch zu erwarten, dass sich die Mails lange in ihr aufhalten. Aus demselben Grund verschwendet der Fstab-Eintrag auch keine Schreibzugriffe und aktiviert »noatime«.

Abschließend verwendet der Admin »mount«, um damit die RAM-Disk einzubinden und den Erfolg zu kontrollieren:

# mount | grep ram
/dev/shm on /var/spool/postfix-ram type tmpfs (rw,noexec,nosuid,nodev,noatime,size=50m,mode=770,uid=0,gid=0)

Als Nächstes geht er daran, den Multiple-Instance-Support zu aktivieren.

Kontrollierte Aggression

Dazu dient das neue Postmulti-Kommando »postmulti -e init«. Es fügt in der Konfigurationsdatei »main.cf« Hauptinstanz-Einträge für »multi_instance_wrapper« und »multi_instance_enable« ein, sodass Postfix jetzt auch bereitwillig Antwort über die Anzahl laufender Instanzen geben kann:

# postmulti -l -a
- - y /etc/postfix
(...)

In dieser kurzen Tabelle steht jede Reihe für eine Postfix-Instanz. Die Spalten benennen Name, Gruppe, Betriebszustand (aktiv/nicht aktiv) und Konfigurationsverzeichnis.

Die Instanzen lassen sich in Gruppen zusammenfassen und auf Wunsch in einem Rutsch über »postmulti« ansprechen. Das neue Kommando legt auch die neue aggressive Instanz »postfix-ram« an, zum Beispiel mit »postmulti -I postfix-ram -e create«:

-           - y /etc/postfix
postfix-ram - n /etc/postfix-ram

Jetzt zeigt die Tabelle in der Ausgabe von »postmulti -l -a« die neuen Instanzen zwar an, sie sind aber nicht automatisch aktiv. Postfix startet sie aus Sicherheitsgründen mit deaktivierten Inetd-Diensten (Smtpd, Qmqpd) und Mail-Einlieferung (Sendmail, Postdrop). Der Name der Instanz dient automatisch als Name für das Konfigurationsverzeichnis unterhalb von »/etc«.

Dementsprechend stellt der Admin in »/etc/postfix-ram/main.cf« jetzt aggressivere Timeouts ein und legt das »smtp_fallback_relay« auf die konservative Instanz fest. Tabelle 1 zeigt in Spalte 2 zunächst einen Blick auf die Standard-Timeouts, wie sie die konservative Instanz anwendet. Spalte 3 dagegen enthält die Werte, die dem Kommunikationspartner Druck machen. Die Konfiguration der »postfix-ram«-Instanz drückt die relevanten Wartezeiten auf bis zu ein Zehntel des Ausgangswerts.

Für das Anpassen dieser Werte hat der Admin bei Postfix auch mit dem MIM zwei Alternativen zur Wahl. Entweder er passt die Konfigurationsdatei direkt mit dem Texteditor seiner Wahl an oder er nimmt Postmulti in Kombination mit dem altbekannten »postconf -e«-Aufruf zur Hand, zum Beispiel für ein Edit des »smtp_connect_timeout«-Parameters:

# postmulti -i postfix-ram -x postconf -e "smtp_connect_timeout = 3s"
# postmulti -i postfix-ram -x postconf smtp_connect_timeout
smtp_connect_timeout = 3s

Ohne die Angabe »-e« für Edit lässt sich so auch schnell die aktuelle Konfiguration überprüfen.

Limitieren

In vielen Fällen ist es sinnvoll, den Smtpd-Server der durchsatzoptimierten Instanz Beschränkungen zu unterwerfen. Im vorliegenden Beispiel soll er nur auf Localhost erreichbar sein und auf Port 10025 lauschen, weil dort ein Mailinglistenmanager die Mails einkippt. Diese Änderung findet – wie bei Postfix üblich – in »master.cf« statt, allerdings im Verzeichnis der Instanz »/etc/postfix-ram/«:

#smtp           inet  n - n - - smtpd
localhost:10025 inet  n - n - - smtpd

Damit ist die aggressive Instanz betriebsbereit und wartet auf ihre Aktivierung über »master_server_disable«, entweder in »/etc/postfix-ram/main.cf« oder mit Postconf.

Ausweichserver

Jetzt sollte der Admin der RAM-Instanz noch mitteilen, wohin sie Nachrichten durchreichen soll, wenn diese nicht beim ersten Versuch zustellbar sind. Postfix kennt derartige Zweitserver als »smtp_fallback_relays«, zum Beispiel mit Postmulti/Postconf: »postmulti -i postfix-ram -x postconf -e “smtp_fallback_relay = [194.126.158.237]”«. Abschließend bindet der Admin jede Instanz an eine eigene IP, damit es keine Probleme der Art »loops back to myself”« gibt:

# postmulti -i postfix-ram -x postconf -e"inet_interfaces = 194.126.158.238"
# postconf -e "inet_interfaces = 194.126.158.237"

Root aktiviert die neue Postfix-Instanz mit »postmulti -i postfix-ram -e enable«. Ab sofort kann auch Postmulti diese verwalten:

# postmulti -i postfix-ram -p start
postfix-ram/postfix-script: starting the Postfix mail system
# postmulti -l -a
-           - y /etc/postfix
postfix-ram - y /etc/postfix-ram

Brav listet Postmulti die Instanz jetzt als aktiv, der Multiple-Instance-Manager hat das Ruder übernommen. Auch in der Protokolldatei »/var/log/mail« oder »/var/log/mail.log« vermerkt Postfix den Start der neuen Instanz mit einem lakonischen »daemon started«:

Jun  5 14:46:42 hanni postfix-ram/postfix-script[23331]: starting the Postfix mailsystem
Jun  5 14:46:42 hanni postfix-ram/master[23332]: daemon started -- version 2.6.2,configuration /etc/postfix-ram

Für den abschließenden Funktionstest bietet sich Telnet an (Listing 1), wenn alles geklappt hat, erläutert das Logfile von Postfix auch den Verlauf der Zustellung (Listing 2). Die durchsatzoptimierte Instanz »postfix-ram« erhält die Fehlermeldung »452 4.4.5 Insufficient disk space« und reicht dann die Nachricht an das vorbestimmte Fallback-Relay durch.

01 Trying 127.0.0.1...
02 Connected to localhost.localdomain.
03 Escape character is '^]'.
04 220 nanni.state-of-mind.de ESMTP Postfix
05 HELO foo
06 MAIL FROM:<postmaster@hanni.state-of-mind.de>
07 RCPT TO:<postmaster@digital.ktu.lt>
08 DATA
09 Test
10 .
11 250 nanni.state-of-mind.de
12 250 2.1.0 Ok
13 250 2.1.5 Ok
14 354 End data with <CR><LF>.<CR><LF>
15 250 2.0.0 Ok: queued as 3B3E92ECA1
16 QUIT
17 221 2.0.0 Bye
18 Connection closed by foreign host.

01 Jun  5 16:00:10 hanni postfix-ram/smtpd[24796]: connect from localhost.localdomain[127.0.0.1]
02 Jun  5 16:00:20 hanni postfix-ram/smtpd[24796]: 3B3E92ECA1: client=localhost.localdomain[127.0.0.1]
03 Jun  5 16:00:20 hanni postfix-ram/cleanup[24799]: 3B3E92ECA1: message-id=<>
04 Jun  5 16:00:20 hanni postfix-ram/qmgr[24794]: 3B3E92ECA1: from=<postmaster@hanni.state-of-mind.de>,size=200, nrcpt=1 (queue active)
05 Jun  5 16:00:20 hanni postfix-ram/smtp[24800]: 3B3E92ECA1: host digital.ktu.lt[193.219.160.140]said: 452 4.4.5 Insufficient disk space; try again later (in reply to MAIL FROM command)
06 Jun  5 16:00:20 hanni postfix-ram/smtp[24800]: 3B3E92ECA1: to=<postmaster@digital.ktu.lt>,relay=194.126.158.237[194.126.158.237]:25, delay=0.24, delays=0.01/0.01/0.21/0.02, dsn=2.0.0,status=sent (250 2.0.0 Ok: queued as 72A6212168)
07 Jun  5 16:00:20 hanni postfix-ram/qmgr[24794]: 3B3E92ECA1: removed
08 
09 Jun  5 16:00:20 hanni postfix/smtpd[24801]: connect from unknown[194.126.158.238]
10 Jun  5 16:00:20 hanni postfix/smtpd[24801]: 72A6212168: client=unknown[194.126.158.238]
11 Jun  5 16:00:20 hanni postfix/cleanup[24804]: 72A6212168: message-id=<>
12 Jun  5 16:00:20 hanni postfix/qmgr[24782]: 72A6212168: from=<postmaster@hanni.state-of-mind.de>,size=402, nrcpt=1 (queue active)
13 Jun  5 16:00:20 hanni postfix/smtpd[24801]: disconnect from unknown[194.126.158.238]
14 Jun  5 16:00:20 hanni postfix/smtp[24805]: 72A6212168: to=<postmaster@digital.ktu.lt>,relay=digital.ktu.lt[193.219.160.140]:25, delay=0.18, delays=0.01/0.01/0.12/0.04, dsn=4.4.5,status=deferred (host digital.ktu.lt[193.219.160.140] said: 452 4.4.5 Insufficient disk space; tryagain later (in reply to MAIL FROM command))

Mächtig und noch viel Potenzial

Mit den geschilderten Beispielen ist das Multi-Instanz-Konzept von Postfix noch lange nicht ausgereizt. Findigen Admins tut sich eine ausgedehnte Spielwiese an Möglichkeiten auf, ihren oder ihre Server zu optimieren. Dabei gefällt die einfache und durchdachte Konfiguration, in der sich auch der Postfix-Einsteiger schnell zurechtfindet. (mfe)