Loading ...
Sorry, an error occurred while loading the content.
 

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

Expand Messages
  • 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
    Message 1 of 8 , Apr 21, 2014
      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
    • Viktor Dukhovni
      ... 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
      Message 2 of 8 , Apr 21, 2014
        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.
      • Wietse Venema
        ... Here are some more simple building blocks to encourage clean solutions. - Using similar syntax as the randmap feature, a roundmap feature that implements
        Message 3 of 8 , Apr 21, 2014
          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
        • /dev/rob0
          ... 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:
          Message 4 of 8 , Apr 21, 2014
            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:
          • McDonald, Dan
            ... 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
            Message 5 of 8 , Apr 21, 2014
              On 4/21/14, 8:41 PM, "/dev/rob0" <rob0@...> 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.
            • Robert Schetterer
              ... 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
              Message 6 of 8 , Apr 22, 2014
                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
              • Wietse Venema
                ... 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
                Message 7 of 8 , Apr 22, 2014
                  > 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
                • 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
                  Message 8 of 8 , Apr 22, 2014
                    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
                  Your message has been successfully submitted and would be delivered to recipients shortly.