Exchange 2016 DAG - Design fragen

[PowerShellAdmin 169]

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

[PowerShellAdmin 169]

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

[NorbertFe 1.928]

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?

[PowerShellAdmin 169]

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

[NorbertFe 1.928]

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. ;)

[PowerShellAdmin 169]

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

[PowerShellAdmin 169]

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

[NorbertFe 1.928]

Stehen die beiden DAG Knoten in einem RZ mit zwei Anschlüssen, oder in zwei RZ mit jeweils einem Anschluß?

[PowerShellAdmin 169]

Ersteres - ist nur eine kleine Umgebung.

[NorbertFe 1.928]

Dann würde _ich_ nicht mit zwei Outbound Gateways arbeiten. ;)

[PowerShellAdmin 169]

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?

[NorbertFe 1.928]

Nein hab ich nicht. Ich bin eher Vertreter von KISS ;)

[PowerShellAdmin 169]

Nein hab ich nicht. Ich bin eher Vertreter von KISS ;)

Und was wäre deiner Meinung nach hier der einfachste Weg ?

[PowerShellAdmin 169]

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

[NorbertFe 1.928]

Wieso solln sich spamfilter verwursteln tun? ;)