PowerShellAdmin 169 Geschrieben 23. September 2016 Melden Teilen Geschrieben 23. September 2016 (bearbeitet) Ich setze derzeit eine Exchange 2016 Umgebung ein und mache mir hier einige Gedanken bzgl. einer für uns sinnvollen Abbildung. Das Thema DAG und HA ist für mich auch etwas neu, also zereißt mich nicht gleich, falls hier schwerwiegende Mängel vorhanden sind. Exchange 2016 DAG - 2 Nodes, 1 Witness Jeder Node hängt an einem IPS Jedes Node läuft auf eigenen Vsphere Server Jeder Node hat eine DB - kreuz gespiegelt. Postfächer ~60 ESET Mail Security Internetanschlüsse: 2 LB: Testweise Kemp VA, vorstellbar auch Sophos UTM - scheint ja auch zu laufen. Intelligentes Loadbalancing: nicht erforderlich 1. Client Access 1.1 Intranet-Company Mail.Domain.tld -Round Robin oder Load Balancer ~ Abwegung läuft Nachteil 2 LB benötigt für HA 1.2 Internet-Außerhalb ->Round Robin auf mail.domain.tld (so wie ich das sehe, auch bei 2 LBs notwendig oder wie konfiguriere ich das hier sinnvoll, jeder Eintrag verweißt auf einen Anschluss) 2. MX Records 2 Records, selbe Prio, mail.domain.tld, mail2.domain.tld -> verweisen auf unterschiedliche IPS, werden vom Router an die Nodes weitergereicht. 3.SMTP 1 SMTP Connector für den Bereich, beide Server als Member zugewiesen. Jeder Server versendet über eigenen ISP raus => Fragen @1.2 => Wie setzt man LBs sinnvoll von außen hinter 2 ISPs sinnvoll ein. MAcht man das üblicherweise bei dem Clientaccess ohne Round Robin und wie bildet man das Ganze dann ab? @3 Der SMTP Connector im Exchange 2016 hat hier a) eine Lastenverteilung und merkt B ) falls ein Server ausfällt => Problem: Wie kann verhält sich das, wenn hier hinter eine Störung auftritt, Verkabelung, Router, IPS? @Greylisting via MailSecurity: Kann ich das in diesem Setup überhaupt sinnvoll einsetzen oder kann es dazu führen, dass die SMTP Zustellung zwischen beiden Nodes springt- idealerweise sollte Mailsecurity ja die Clients koordinieren oder? @LB: Dachte hier an 2 Sophos 120 UTM, die Kosten für die SA müsste ich entsprechend nochmal kalkulieren. So erstmal besten Dank, ich freue mich auf euern Input :) bearbeitet 23. September 2016 von PowerShellAdmin Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 26. September 2016 Autor Melden Teilen Geschrieben 26. September 2016 (bearbeitet) Kleine Ergänzung: Da die MX Records ohne Round Robin umgesetzt werden, müssten diese also Mail01.domain.tld, Mail02.domain.tld lauten. Der Clientaccess würde dann weiterhin via mail.domain.tld über Round Robin laufen bearbeitet 26. September 2016 von PowerShellAdmin Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. September 2016 Melden Teilen Geschrieben 26. September 2016 Wenn du nen Loadbalancer hast, warum setzt du dann die MX Records getrennt? Bringt doch keine sinnvollen Vorteile. Ich würde das LB auf dem Loadbalancer belassen und nicht mit der Sophos hantieren. Wenn du die Sophos HA willst, brauchst du auch zwei Stück, wieso ist das also für den Loadbalancer ein Nachteil? Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 26. September 2016 Autor Melden Teilen Geschrieben 26. September 2016 (bearbeitet) Also der eingesetzte LB ist nur eine freie Instanz von Kemp ohne Support und limitiert. Hier werde ich mir mal Angebote einholen. Ich dachte dass zwei gleichpriorisierte MX Records für diese Konstellation eine saubere Lösung sind. Das andere Thema ist, dass der LB ja über bei Internetanschlüsse von außen ansprechbar sein sollte. Entsprechend war auch meine Annahme, dass ich für den LB am DNS eine RoundRobin mit beiden Anschlüssen setzen muss. bearbeitet 26. September 2016 von PowerShellAdmin Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. September 2016 Melden Teilen Geschrieben 26. September 2016 Na dann wäre es aber besser einfach den A-Record im Public DNS zweimal zu pflegen. ;) Alternativ kann Kemp auch GEO Loadbalancing, wäre aber wahrscheinlich etwas überdimensioniert. So oder so, egal ob du jetzt extern Round Robin für den MX nutzt oder zwei eigene Records, intern würde ich immer Loadbalancing fahren, denn es kann ja einer der beiden Knoten auch mal ausfallen. ;) Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 26. September 2016 Autor Melden Teilen Geschrieben 26. September 2016 (bearbeitet) Na dann wäre es aber besser einfach den A-Record im Public DNS zweimal zu pflegen. ;) Alternativ kann Kemp auch GEO Loadbalancing, wäre aber wahrscheinlich etwas überdimensioniert. So oder so, egal ob du jetzt extern Round Robin für den MX nutzt oder zwei eigene Records, intern würde ich immer Loadbalancing fahren, denn es kann ja einer der beiden Knoten auch mal ausfallen. ;)Danke - dann bleibe ich beim ursprünglichen Ansatz:) Mail eingehend: 2 A Records, Prio 10 mail01.domain.tld , mail02.domain.tld Clientzugriff extern:2x A Records auf mail.domain.tld ( Round Robin auf internen LB) Clientzugriff intern: A Record auf LB Ausgehend 1 SMTP Sendconnector mit beiden Membern - fängt Nodeausfall, aber keine Störung an der Internetleitung ab oder wie intelligent ist das Ganze? bearbeitet 26. September 2016 von PowerShellAdmin Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 26. September 2016 Autor Melden Teilen Geschrieben 26. September 2016 (bearbeitet) So wegen dem SMTP Connector habe ich mir jetzt nochmal Gedanken gemacht. Der Failover klappt ja nur Dienstbezogen nehme ich an, Störungen an Internetanschluss werden so wohl nicht verarbeitet. Lösungsansatz: PS Skript auf jeden Node als Job - Falls bei der Prüfung eine Störung auftritt wird der Node aus dem SMTP Connector entfernt, umgekehrt bei erfolgreicher Verbindung wieder ergänzt. => Kann die Live Umschaltung zu Störungen des Nachrichtenflusses führen? bearbeitet 26. September 2016 von PowerShellAdmin Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. September 2016 Melden Teilen Geschrieben 26. September 2016 Stehen die beiden DAG Knoten in einem RZ mit zwei Anschlüssen, oder in zwei RZ mit jeweils einem Anschluß? Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 26. September 2016 Autor Melden Teilen Geschrieben 26. September 2016 Ersteres - ist nur eine kleine Umgebung. Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. September 2016 Melden Teilen Geschrieben 26. September 2016 Dann würde _ich_ nicht mit zwei Outbound Gateways arbeiten. ;) Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 26. September 2016 Autor Melden Teilen Geschrieben 26. September 2016 Schade mein Ansatz ist doch immerhin "kreativ" und lässt sich einfach integrieren. Intelligenter Router zu Verwaltung beider Verbindungen? Die Leitungen waren bisher organisatorisch getrennt. Wäre aber ein Ansatz - hast du hier eine Hardware-Empfehlung? Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 26. September 2016 Melden Teilen Geschrieben 26. September 2016 Nein hab ich nicht. Ich bin eher Vertreter von KISS ;) Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 27. September 2016 Autor Melden Teilen Geschrieben 27. September 2016 Nein hab ich nicht. Ich bin eher Vertreter von KISS ;) Und was wäre deiner Meinung nach hier der einfachste Weg ? Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 30. September 2016 Autor Melden Teilen Geschrieben 30. September 2016 (bearbeitet) So - sehe ich folgendes richtig - also Round Robin auf den SMTP FQDN, dass hier draus ein Mismatch resultieren kann oder ist das so zulässig? Eine DNS Query auf mail.domain.tld gibt mir zwar beide IPs korrekt zurück, ebenso funktoniert ja auch der PTR ... Aber tun sich hier die Spamfilter verwursteln? SMTP Connector: fqdn:mail.domain.tld Provider: A Record: mail.domain.tld [iP ISP1] A Record: mail.domain.tld [iP ISP2] ISP 1: [PTR IP] mail.domain.tld ISP 2: [PTR IP] mail.domain.tld bearbeitet 30. September 2016 von PowerShellAdmin Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 30. September 2016 Melden Teilen Geschrieben 30. September 2016 Wieso solln sich spamfilter verwursteln tun? ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.