Oha. Das war aber flott.

Hallo, Herzlich Willkommen alle Miteinander.

Ich war gestern Abend ja doch ziemlich baff, wie schnell sich die
Dovecot-Liste hier mit Leben füllte. Die ersten 50 Eintragungen haben
keine halbe Stunde gedauert, mittlerweile sind’s bereits bis heute
morgen schon 200 Abonennten eingezogen.

Der erste User war sogar schon eingetragen, bevor ich überhaupt die
Einladungen zur Liste rausgeschickt habe. Pff!

Also: Herzlich Willkommen.

Peer


Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

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

  • 18. März 2013

  • Peer Heinlein

  • 15 Antworten

  1. Christian Garling sagt:

    Hallo zusammen,

    ich hatte dieses Thema schonmal in ähnlicher Form auf der Postfix Liste
    gepostet und möchte es gerne nochmal aufgreifen.

    Wir betreiben aktuell einen Mailserver an unserem Haupt-RZ Standort in
    Düsseldorf. Hier laufen grundsätzlich alle Server die wir betreiben. Für
    den Worst-Case haben wir ein Notfallsystem in einem RZ in Aachen stehen,
    welches u.a. auch den Mailbetrieb übernehmen soll.
    Des weiteren gibt es ebenfalls in Düsseldorf und Aachen aber von den
    o.g. RZs örtlich getrennt unsere Büros, dies nur zur Vollständigkeit.

    Die Frage ist nun, wie wir den Notfall-Server in Aachen aufsetzen
    sollen, damit dieser im Ernstfall den vollen Mailbetrieb übernehmen
    kann. Wir dachten anfangs an folgendes:

    * Hauptserver als MX10, Backupserver als MX20
    * Synchronisation der Mails auf Dateisystemebene mit einem ClusterFS
    wie z.B. GFS2
    * Zugriff der Nutzer wird über dienstbezogene Hostnamen
    (imap.example.com / pop3.example.com / smtp.example.com) per DNS auf
    das jeweils aktive System gelenkt, hier würden wir möglichst kurze
    TTL Zeiten im DNS für einen schnellen Wechsel verwenden

    Durch Diskussion auf der Postfix Liste wurde schon klar, das zumindest
    die Wertigkeit der MX Einträge in der Praxis durch die einliefernden
    Mailserver zum Teil ignoriert wird was unser Konzept an der Stelle über
    den Haufen wirft. Hier geht es mir aber im wesentlich auch eher um die
    Frage, wie man standortübergreifend die Mails synchron hält. Muss man im
    Falle von Dovecot etwas besonderes beachten, wenn man z.B. o.g.
    ClusterFS einsetzt? Ist das überhaupt eine gute Idee? Was ist hier
    Best-Practice?

    Viele Grüße, Christian Garling

    • Peer Heinlein sagt:

      Am 18.03.2013 10:52, schrieb Christian Garling:

      Hi,

      > * Hauptserver als MX10, Backupserver als MX20

      Kann man für Mailrelays machen, aber jeder Front-MXer braucht dann ein
      eigenes Routing zum Dovecot-Server. D.h. auch wenn Aachen mal Mails
      kriegt sollen / müssen die trotzdem zunächst zum aktiven Server nach
      Düsseldorf.

      > * Synchronisation der Mails auf Dateisystemebene mit einem ClusterFS

      Ich halte von Cluster-Dateisystemen in dem Zusammenhang so gut wie nichts.

      a) kompliziert & fehleranfällig
      b) selten performant genug
      c) Replizierte Fehler sorgen dann auch zum Ausfall des Backups

      > * Zugriff der Nutzer wird über dienstbezogene Hostnamen
      > (imap.example.com / pop3.example.com / smtp.example.com) per DNS auf
      > das jeweils aktive System gelenkt, hier würden wir möglichst kurze
      > TTL Zeiten im DNS für einen schnellen Wechsel verwenden

      Kann man machen, ich mag pragmatische Ansätze. Man muß dann aber auch
      wissen, daß es dann immer wieder die Erfahrung gibt, daß User Client
      oder sogar Desktop neu starten müssen, damit der auch WIRKLICH neu auflöst.

      Alternativ: NATen in der Firewall (Von DüDo nach Aachen)

      Oder: Tatsächlich ein transparentes IP-Netz über beide Standorte und
      dann eine VIP (Virtual IP) im klassichen Cluster-Setup.

      > den Haufen wirft. Hier geht es mir aber im wesentlich auch eher um die
      > Frage, wie man standortübergreifend die Mails synchron hält. Muss man im
      > Falle von Dovecot etwas besonderes beachten, wenn man z.B. o.g.
      > ClusterFS einsetzt? Ist das überhaupt eine gute Idee? Was ist hier
      > Best-Practice?

      Es gibt da sehr verschiedene Ansätze und je nach Kundensätze kommt auch
      jeder mal dabei raus.

      Am interessantesten ist sicherlich der jetzt im 2.2er Zweig kommende
      Replikations-Dämon von Dovecot. Damit repliziert Dovecot zwischen beiden
      Servern auf Mail-Ebene, was einen von allen Dateisystemproblemen
      darunter befreit.

      Hilfsweise können auch kurze rsync-Zyklen oder eine eigene Lösung mit
      kurzen dsync-Durchläufen sehr pragmatisch-brauchbar sein.

      Prinzipiell würde ich hier der 2.2 noch ein bißchen Zeit geben und dann
      ist das schon SEHR lecker das damit zu machen.

      Peer


      Heinlein Support GmbH
      Schwedter Str. 8/9b, 10119 Berlin

      http://www.heinlein-support.de

      Tel: 030 / 405051-42
      Fax: 030 / 405051-19

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

      • Christian Garling sagt:

        Hallo Peer,

        Am 18.03.2013 14:38, schrieb Peer Heinlein:
        >> * Zugriff der Nutzer wird über dienstbezogene Hostnamen
        >> (imap.example.com / pop3.example.com / smtp.example.com) per DNS auf
        >> das jeweils aktive System gelenkt, hier würden wir möglichst kurze
        >> TTL Zeiten im DNS für einen schnellen Wechsel verwenden
        > Kann man machen, ich mag pragmatische Ansätze. Man muß dann aber auch
        > wissen, daß es dann immer wieder die Erfahrung gibt, daß User Client
        > oder sogar Desktop neu starten müssen, damit der auch WIRKLICH neu auflöst.
        >
        > Alternativ: NATen in der Firewall (Von DüDo nach Aachen)
        Wir gehen ja davon aus das Düsseldorf aus unserer Sicht komplett down
        ist, also fällt NAT von DDorf nach Aachen als Lösung weg.

        >
        > Oder: Tatsächlich ein transparentes IP-Netz über beide Standorte und
        > dann eine VIP (Virtual IP) im klassichen Cluster-Setup.
        Das sind aber unterschiedliche RZ Betreiber, geht das dann trotzdem?
        Habe damit auf dieser Ebene keine Erfahrung.

        >
        >> den Haufen wirft. Hier geht es mir aber im wesentlich auch eher um die
        >> Frage, wie man standortübergreifend die Mails synchron hält. Muss man im
        >> Falle von Dovecot etwas besonderes beachten, wenn man z.B. o.g.
        >> ClusterFS einsetzt? Ist das überhaupt eine gute Idee? Was ist hier
        >> Best-Practice?
        > Es gibt da sehr verschiedene Ansätze und je nach Kundensätze kommt auch
        > jeder mal dabei raus.
        >
        > Am interessantesten ist sicherlich der jetzt im 2.2er Zweig kommende
        > Replikations-Dämon von Dovecot. Damit repliziert Dovecot zwischen beiden
        > Servern auf Mail-Ebene, was einen von allen Dateisystemproblemen
        > darunter befreit.
        Kennst du da zufällig einen Zeitplan wann das kommt? Wir haben uns aber
        im Grunde auch schon dazu entschieden darauf zu warten.
        Danke für die Info das das kommt!

        >
        > Hilfsweise können auch kurze rsync-Zyklen oder eine eigene Lösung mit
        > kurzen dsync-Durchläufen sehr pragmatisch-brauchbar sein.
        >
        > Prinzipiell würde ich hier der 2.2 noch ein bißchen Zeit geben und dann
        > ist das schon SEHR lecker das damit zu machen.
        >
        > Peer
        Gruß, Christian

        • Peer Heinlein sagt:

          Am 18.03.2013 14:58, schrieb Christian Garling:

          > Das sind aber unterschiedliche RZ Betreiber, geht das dann trotzdem?
          > Habe damit auf dieser Ebene keine Erfahrung.

          Wenn Ihr BGP macht: Ja.

          Aber so wie es aussieht macht Ihr das nicht (selbst) und damit: Nein.

          > Kennst du da zufällig einen Zeitplan wann das kommt? Wir haben uns aber
          > im Grunde auch schon dazu entschieden darauf zu warten.
          > Danke für die Info das das kommt!

          Nee, einen genauen Plan habe ich jetzt nicht dazu im Kopf, aber schon
          ASAP/alsbald.

          Peer


          Heinlein Support GmbH
          Schwedter Str. 8/9b, 10119 Berlin

          http://www.heinlein-support.de

          Tel: 030 / 405051-42
          Fax: 030 / 405051-19

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

        • Michael Grimm sagt:

          Hi —

          Christian Garling wrote:
          > Am 18.03.2013 14:38, schrieb Peer Heinlein:

          >> Am interessantesten ist sicherlich der jetzt im 2.2er Zweig kommende
          >> Replikations-Dämon von Dovecot. Damit repliziert Dovecot zwischen beiden
          >> Servern auf Mail-Ebene, was einen von allen Dateisystemproblemen
          >> darunter befreit.

          > Kennst du da zufällig einen Zeitplan wann das kommt?

          Ich benutze replicator/dsync nun schon seit 2.1 zur Synchronisation zweier
          Server (~500km voneinander getrennt). Beide Mailserver (postfix, dovecot)
          langweilen sich zwar zu Tode (~1000 Mails/Tag), aber ich habe das neue
          Replikationsschema unter Laborbedingungen getestet, indem ich Tausende
          Mails auf beiden Servern gleichzeitig lokal eingespeist habe.

          Ab 2.2rc2 [1] komme ich zu dem Schluß, daß replicator/dsync unter meinen
          Bedingungen fertig für die Produktion ist. Seit diesem Release habe ich
          keine Probleme mehr feststellen können, wie sie unter 2.1 noch vorhanden
          waren.

          Ich kann allerdings nicht abschätzen, wie sich dieses Replikationsschema
          auf richtig dicken Mailservern bewähren wird …

          > Wir haben uns aber im Grunde auch schon dazu entschieden darauf zu warten.

          Meines Erachtens könntet ihr mit dem gegenwärtigen Release Candidate schon
          mit Tests beginnen.

          [1] http://www.dovecot.org/list/dovecot-news/2013-February/000243.html

          Gruß,
          Michael