[postfix-users] [OT] amavisd-new: Loadbalancer oder nicht?

[Stefan Foerster]

Ich bin momentan wirklich unschlüssig, wie man die Sache mit
amavisd-new (oder genereller: SMTP-fähige Inhaltsfilter) eigentlich am
besten abhandelt. Die Sache mit den Miltern lasse ich aus, da kann
Patrick mehr dazu sagen, aber ich würde mich generell über jede
Meinung und jedes Feedback freuen.

Fangen wir mal mit der einachsten Sache an: Ein post-queue Filter.
Hier stellt sich die Frage nach dem Loadbalancing auf den ersten Blick
nicht. Man setzt im internen DNS eine Zone wie z.B.
"filter.example.com" auf:

$ORIGIN filter.example.com
.   IN  MX  10  filter1.example.com
.   IN  MX  10  filter2.example.com

Für den Filter-Eintrag des entsprechenden SMTP-Servers setzt man in
der master.cf dann

-o content_filter=filter:filter.example.com:10024

(NB: ohne eckige Klammern) und definiert bei dem filter-Transport
passende Werte für Timeouts, Prozesszahl etc. Für amavisd-new reichen
Wildcards ('smtp:*:*') oder so, die Seite mit der Doku tut hier gerade
nicht) für $forward_method und schon filtert er mehr oder weniger im
RR-Betrieb. Hier ist mir jetzt vor allem eine Sache unklar:

Merkt sich Postfix eigentlich, daß ein bestimmter Server tot ist?
Ich weiß, daß Postfix in der Lage ist, bestimmte Ziele für tot zu
erklären und alle Mail dahin erstmal in die deferred queue zu stellen,
aber gilt das auch für einzelne MXe? Wo ist das dokumentiert? In der
Manpage zum qmgr findet sich nur:

,----[ man 8 qmgr ]
|        destination status cache
|                      The queue manager avoids unnecessary delivery
|                      attempts by maintaining a short-term, in-memory
|                      list of unreachable destinations.
`----

"Destination" könnte aber auch durchaus eine ganze Zieldomain sein und
nicht nur ein MX.

Wenn das nicht funktioniert, dann würde im dem Fall, das ein Filter
ausfällt, die Hälfte der Verbindungen erstmal auf einen Timeout
warten. Unübersichtlich finde ich auch das Finetuning des
Filter-Transports ab einer gewissen Größe der Installation, seien es
nun Trivialitäten wie (s|l)mtp_mx_session_limit oder aufwändigerer
Kram wie TRANSPORTNAME_destination_concurrency_failed_cohort_limit /
TRANSPORTNAME_destination_concurrency_limit. Und nicht vergessen darf
man auch, daß das ja nur "RR für Arme ist" - evt. verschärft durch
connection caching, was dann schonmal dazu führen kann, daß ein Filter
fast immer busy ist und der andere sich langweilt (BTDT).

Noch viel unübersichtlicher wird es meiner Meinung nach bei einem
smtpd_proxy_filter. Es ist auf der einen Seite zwar so, daß mit den
2.7er-Versionen endlich die nötige Funktionalität implementiert ist,
mit der man eine Mail erst dann dem Proxy vorwirft, wenn sie komplett
empfangen wurde, aber was immer noch nicht geht ist eine Spezifikation
des Filters mit Transport- und Nexthop. Kann man hier _überhaupt_
irgendwie Redundanz erreichen (pro smtpd!), ohne einen Loadbalancer zu
benutzen? Ich habe hier beisher noch jedes Mal auf solch einen
zurückgegriffen (Cisco ACE, ldirectord).

Wie handhabt ihr das denn so? Und wisst ihr zufällig, wie andere MTAs
(Exim, Exchange in der Edge-Rolle) das machen?


Stefan