Idea: random map selection (for load balancers etc.)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Idea: random map selection (for load balancers etc.)

Wietse Venema
A possible solution for load balancing is to introduce a new map
type that makes random selection.

randmap:/file/name

    The file contains a list of reponses, one response per line,
    ignoring leading whistespace, trailing whitespace, and empty
    lines.  Each map query returns a randomly-selected response.

randmap:!one!two!three

    Split the text after ":" on the first character, producing a
    list of responses (one, two, three). Each map query returns a
    randomly-selected response.

That should be enough to load-balance deliveries over mail delivery
transports.

The following example will deliver local mail locally and load-balance
non-local mail over smtp0: and smtp1:.

/etc/postfix/main.cf:
    transport_maps = hash:/etc/postfix/transport, randmap:!smtp0:!smtp1:

/etc/postfix/transport:
    example.com         local:
    mail.example.com    local:

To implement different weight factors, repeat smtp0: and smtp1: a
different numbers of times.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Idea: random map selection (for load balancers etc.)

Viktor Dukhovni
On Mon, Apr 21, 2014 at 02:18:41PM -0400, Wietse Venema wrote:

> The following example will deliver local mail locally and load-balance
> non-local mail over smtp0: and smtp1:.
>
> /etc/postfix/main.cf:
>     transport_maps = hash:/etc/postfix/transport, randmap:!smtp0:!smtp1:

One caveat is that the queue manager maintains a 1-element cache
of transport mappings, so if a stream of mail is sent to a single
recipient, the load balacing will not kick in.  MX records are
better.  Instea of using multiple ports on 127.0.0.1 to nat to
remote destinations, use multiple IP addresses of the form 127.0.1.N
and a fixed port, then use an MX record on a multi-homed entry in
/etc/hosts.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Idea: random map selection (for load balancers etc.)

Wietse Venema
In reply to this post by Wietse Venema
Wietse Venema:

> A possible solution for load balancing is to introduce a new map
> type that makes random selection.
>
> randmap:/file/name
>
>     The file contains a list of reponses, one response per line,
>     ignoring leading whistespace, trailing whitespace, and empty
>     lines.  Each map query returns a randomly-selected response.
>
> randmap:!one!two!three
>
>     Split the text after ":" on the first character, producing a
>     list of responses (one, two, three). Each map query returns a
>     randomly-selected response.
>
> That should be enough to load-balance deliveries over mail delivery
> transports.
>
> The following example will deliver local mail locally and load-balance
> non-local mail over smtp0: and smtp1:.
>
> /etc/postfix/main.cf:
>     transport_maps = hash:/etc/postfix/transport, randmap:!smtp0:!smtp1:

Here are some more simple building blocks to encourage clean
solutions.

- Using similar syntax as the randmap feature, a roundmap feature
that implements round-robin selection instead of random selection.

- An smtp_bind_addres_maps feature that searches a map by destination
IP address. This could be combined with randmap or roundmap selection.

- A randmap(8) or roundmap(8) pseudo-delivery agent that selects a
real delivery agent (or transport[:nexthop]?) from a list, with a
user interface similar to randmap/roundmap lookup tables.  This
can, for example, load-balance over arbitrary SMTP client settings.

- An option to disable or limit the use of the one-element cache
in the Postfix address resolver client.

I'm getting tired of questions about relayhost load balancing or
source IP address diffusion.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Idea: random map selection (for load balancers etc.)

/dev/rob0
On Mon, Apr 21, 2014 at 04:26:50PM -0400, Wietse Venema wrote:
> I'm getting tired of questions about relayhost load balancing
> or source IP address diffusion.

I understand the feeling. However, in many cases, the people who
want this are hurting themselves or hurting others:

A. Self hurt:
  1. Greylisting woes: changing your source IP at random, you
     never get through greylisting (like gmail and postscreen
     after-220 tests before 2.11)
  2. Lower volume per IP address inhibits improvement in IP
     reputation (in many cases, the REAL problem is poor/no IP
     reputation)
B. Others hurt:
  1. Snowshoe spammers "flying under the radar" to avoid DNSBL
     listings
  2. Avoidance of receivers' flow control, whether spam or not

Yes, randmap & roundmap sound like interesting ideas, but are
they serving real use cases?
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Idea: random map selection (for load balancers etc.)

McDonald, Dan


On 4/21/14, 8:41 PM, "/dev/rob0" <[hidden email]> wrote:

>On Mon, Apr 21, 2014 at 04:26:50PM -0400, Wietse Venema wrote:
>> I'm getting tired of questions about relayhost load balancing
>> or source IP address diffusion.
>
>I understand the feeling. However, in many cases, the people who
>want this are hurting themselves or hurting others:
>
>A. Self hurt:
>  1. Greylisting woes: changing your source IP at random, you
>     never get through greylisting (like gmail and postscreen
>     after-220 tests before 2.11)
>  2. Lower volume per IP address inhibits improvement in IP
>     reputation (in many cases, the REAL problem is poor/no IP
>     reputation)
>B. Others hurt:
>  1. Snowshoe spammers "flying under the radar" to avoid DNSBL
>     listings
>  2. Avoidance of receivers' flow control, whether spam or not
>
>Yes, randmap & roundmap sound like interesting ideas, but are
>they serving real use cases?

Whether they are serving real wide-spread use cases or not, the
functionality exists today.  I was able to get mysql set up to ³randmap"
the inbound traffic from my ³mail hygiene² servers to my internal servers
without much difficulty and very little googling, once Wietse gave me a
push in that direction.  Had these primitives been there the solution
would have been more obvious, but attempting to block a feature by making
it hard doesn¹t deter either spammers or fools, so might as well make it
easier for people with real corner cases.

Reply | Threaded
Open this post in threaded view
|

Re: Idea: random map selection (for load balancers etc.)

Robert Schetterer-2
In reply to this post by Wietse Venema
Am 21.04.2014 22:26, schrieb Wietse Venema:

> Wietse Venema:
>> A possible solution for load balancing is to introduce a new map
>> type that makes random selection.
>>
>> randmap:/file/name
>>
>>     The file contains a list of reponses, one response per line,
>>     ignoring leading whistespace, trailing whitespace, and empty
>>     lines.  Each map query returns a randomly-selected response.
>>
>> randmap:!one!two!three
>>
>>     Split the text after ":" on the first character, producing a
>>     list of responses (one, two, three). Each map query returns a
>>     randomly-selected response.
>>
>> That should be enough to load-balance deliveries over mail delivery
>> transports.
>>
>> The following example will deliver local mail locally and load-balance
>> non-local mail over smtp0: and smtp1:.
>>
>> /etc/postfix/main.cf:
>>     transport_maps = hash:/etc/postfix/transport, randmap:!smtp0:!smtp1:
>
> Here are some more simple building blocks to encourage clean
> solutions.
>
> - Using similar syntax as the randmap feature, a roundmap feature
> that implements round-robin selection instead of random selection.
>
> - An smtp_bind_addres_maps feature that searches a map by destination
> IP address. This could be combined with randmap or roundmap selection.
>
> - A randmap(8) or roundmap(8) pseudo-delivery agent that selects a
> real delivery agent (or transport[:nexthop]?) from a list, with a
> user interface similar to randmap/roundmap lookup tables.  This
> can, for example, load-balance over arbitrary SMTP client settings.
>
> - An option to disable or limit the use of the one-element cache
> in the Postfix address resolver client.
>
> I'm getting tired of questions about relayhost load balancing or
> source IP address diffusion.
>
> Wietse
>

Perhaps include some simple "weight" mech too, if possible


Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: Idea: random map selection (for load balancers etc.)

Wietse Venema
> Perhaps include some simple "weight" mech too, if possible

List some responses multiple times:

    # 1/3 one, 2/3 two.
    randmap:!one!two!two

    # 40% one, 60% two.
    randmap:!one!one!two!two!two

As with DNSBL and DNSWL weights, I do not anticipate that there
will be a need for microscropic weight differences.

And randmap would not do negative weights.

        Wietse
Reply | Threaded
Open this post in threaded view
|

random map pseudo-delivery agent for load balancers etc

Wietse Venema
In reply to this post by Wietse Venema
Here are a few examples of how a randmap(8) pseudo-delivery agent
could be used to distribute inbound or outbound mail across multiple
gateways.

(begin flash-back)
    Yesterday I introduced a design for a randmap lookup table,
    which randomly selects lookup results from a file with one
    result per line, like this:
         something = randmap:/file/name

    Small tables can be specified "in-line", like this:
         something = randmap:!result1!result2...
    where text to the right of ":" is split into lookup results,
    using the first character of that text as the separator.
(end flash-back)

The randmap(8) pseudo-delivery agent works as follows: it gets a
mail delivery request, and uses a randmap lookup to determine how
and where to deliver that mail.

First, two examples of outbound mail via one gateway with one or
more A records:

    relayhost = [out-gw.example]
    default_transport = smtp:[out-gw.example]
 
Next, using a randmap(8) pseudo-delivery agent to do the same via
multiple gateways, 1:1 weights:

    relay_transport = randmap:!smtp:[out-gw1.example]!smtp:[out-gw2.example]

Inbound mail via one gateway with multiple A records:

    /etc/postfix/main.cf:
        transport_maps = hash:/etc/postfix/transport

    /etc/postfix/transport:
        example.com   smtp:[in-gw.example]
 
Inbound mail via multiple gateways, 1:1 weights:

    /etc/postfix/main.cf:
        transport_maps = hash:/etc/postfix/transport

    /etc/postfix/transport:
        example.com   randmap:!smtp:[in-gw1.example]!smtp:[in-gw2.example]

Finally, an example with 1:2 weights, for outbound mail via multiple
gateways:

    relay_transport =
        randmap:
            !smtp:[out-gw1.example]
            !smtp:[out-gw2.example]
            !smtp:[out-gw2.example]

(randmap ignores leading and trailing whitespace).

If we build the randmap(8) pseudo-delivery agent into trivial-rewrite(8),
then it can be done with very little code, and it plays nice with the
queue manager's concurrency policy.

The downside of building randmap(8) into trivial-rewrite(8) is that
the trivial-rewrite daemon returns only one next-hop destination
to the queue manager.  If that next-hop destination is dead, mail
will be deferred even though other randmap destinations are working.

Instead one could move randmap lookups into the SMTP client:

    /etc/postfix/main.cf:
        transport_maps = hash:/etc/postfix/transport

    /etc/postfix/transport:
        example.com   smtp:randmap:![in-gw1.example]![in-gw2.example]

The downside of moving randmap lookups into the SMTP client is that
it does not play nice with the queue manager's concurrency policy,
just like specifying multiple hostnames as the SMTP next-hop
destination did not play nice (and therefore was not implemented).

    /etc/postfix/transport:
        example.com   smtp:[in-gw1.example],[in-gw2.example]

Note that none of the above multi-nexthop solutions for inbound
mail take advantage of SMTP connection caching, which can avoid
severe performance degradation when some of several inbound relays
are down.  To fix that, the SMTP client would need built-in awareness
of multiple next-hop destinations, randmap lookups, or equivalent.

        Wietse