[Postfixbuch-users] Amavisd-new Loadbalancing bei smtpd_proxy_filter

[Peer Heinlein]

Am Mittwoch 17 September 2008 schrieb Rainer Frey:


> Was aber wäre das Problem dabei, Loadbalancing per A-Records zu
> machen, also in etwa:
>
> filter.example.com.		IN A	192.168.1.101
> filter.example.com.		IN A	192.168.1.102
> filter.example.com.		IN A	192.168.1.103
> filter.example.com.		IN A	192.168.1.104

Im Prinzip die Argumentation ab Seite 356 und insb. 358 Mitte.

*) Es mag vielleicht Loadbalancer sein, aber kein Fail-Over. Ist eine 
Maschine tot, wird Postfix den gesamten feed an diese "eine" Maschine 
(aka: alle vier!) herunterfahren und *NICHTS* geht mehr für eine 
gewisse Zeit. 

*) Das mag also geeignet sein um weitere Last mit wegzuschaufeln, nicht 
aber, um Ausfallsicherheit und Stabilität reinzubringen.

*) Umgekehrt ist es kein Problem, Postfix mit vier IP-Adressen 
auszustatten und dann die vier Filter jeweils einzeln anzudocken, wie 
in Kapitel 17.13.2 beschrieben. 

Da ich davon ausgehe, daß es nicht soooo viel Aufwand ist Postfix mit 
weiteren IPs auszustatten, sollte man hier mit einem sehr geringen 
Aufwand alle Probvleme lösen. Darum stellt sich mir die Frage, warum 
man für wesentlich weniger Arbeit dann die Risiken und Probleme der 
Round-Robin-A-Records in Kauf nehmen soll. Das lohnt sich IMHO einfach 
nicht, auch wenn es "prinzipiell" natürlich gehen würde.

Allenfalls würde ich akzeptieren, daß Postfix *zwei* IP-Adressen hat und 
jede dieser Postfix IP dann einen Loadbancer-Namen mit zwei oder drei 
A-Records hat. Also eine Mischform aus beidem. Fällt ein 
Round-Robin-Knoten dann aus, dann sind nur 50% der kapazität lahmgelegt 
und der mailempfang soltle über die zweite Postfix-IP weiter 
funktionieren.

> Caching im Resolver? Caching in Postfix? Kein Round-Robin bei der
> Rückgabe der Ergebnisse? Ich weiss, ist mehr 'ne DNS- als
> Postfix-Frage, aber hier hat das doch sicher schon mal jemand
> durchgedacht :-)

Meine Antwort: Suboptimale Stabilität und Zuverlässigkeit ohne triftige 
Notwendigkeit.

Ansonsten aber machbar. Ja. Aber nicht "Best Practice" sondern dreckig 
getrickst und die Nachteile (hoffentlich) wissentlich in Kauf genommen. 


Mit freundlichen Grüßen

Peer Heinlein


-- 
Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de
Tel: 030 / 40 50 51 - 0  ***  Fax: - 19

Die 3. Secure Linux Administration Conference am 10. - 12.12.2008
http://www.heinlein-support.de/slac

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg, 
Geschäftsführer: Peer Heinlein  --  Sitz: Berlin