Die Konfiguration einer Exchange 2016 DAG ist nahezu identisch mit der Konfiguration einer DAG mit Exchange 2013. Prinzipiell ist es sogar etwas einfacher, denn die Frage, ob die Rollen getrennt werden sollen, oder ob alle Rollen auf einem Server installiert werden können, stellt sich bei Exchange 2016 nicht mehr. Es gibt ja nur noch die Mailbox Rolle. Ein Loadbalacing zwischen den CAS Dienst mittels Windows Loadbalancing Feature funktioniert allerdings weiterhin nicht, denn Fail-Over Cluster und Windows Loadbalancing auf dem gleichen Server schleißen sich gegenseitig aus. Es empfiehlt sich also nach wie vor einen Loadbalancer vorzuschalten, da die Anforderungen seitens Exchange 2016 an einen Loadbalancer gering sind (Layer 4 reicht völlig aus), gibt es zu gut Open Source Lösungen. Nun aber zur DAG. Ich habe ein Testnetzwerk aus 4 VMs erstellt:
Alle VMs laufen mit Windows Server 2012 R2. FWDC1 ist der Domain Controller mit einer Netzwerkkarte in das Produktions VLAN, FWFS1 ist ein Memberserver, bisher ohne besondere Konfiguration mit einer Netzwerkkarte im Produktions VLAN. FWEX1 und FWEX2 sollen die DAG Mitglieder werden, die beiden Server haben jeweils 2 Netzwerkkarten, eine im Produktions VLAN und eine dedizierte Netzwerkkarte für die Replikation der DAG.
Das Active Directory ist bereits installiert und konfiguriert, fangen wir also an mit der Konfiguration der beiden Exchange Server.
Die Netzwerkkarte für das Replikationsnetzwerk wird wie folgt fonfiguriert:
Es wird nur eine feste IP Adresse aus einem anderen Subnetz wie das Produktions Netzwerks vergeben, alle Protokolle bis auf TCP/IPv4 werden deaktiviert.
Zusätzlich wird der Haken bei „Adressen dieser Verbindung in DNS registrieren“ entfernt. Für die Datenbanken wird ein zusätzliches Laufwerk erstellt, in meinem Fall Laufwerk D: (muss auf beiden Servern identisch sein)
Das Laufwerk für die Datenbanken und die Logfiles wird mit ReFS formatiert:
Das waren auch schon alle Vorbereitungen für die Exchange Server. Exchange kann jetzt auf dem ersten Server installiert werden. Die Exchange Installation ist identisch mit meiner Anleitung die hier zu finden ist:
https://www.frankysweb.de/exchange-2016-installation-auf-windows-server-2012-r2/
Nachdem Exchange 2016 auf beiden Servern installiert ist, kann der FileServer (FWFS1) vorbereitet werden. Die Gruppe „Exchange Trusted Subsystem“ muss zur lokalen Gruppe „Administratoren“ hinzugefügt werden
Zusätzlich müssen folgende Firewall Regeln aktiviert werden, wenn nicht bereits geschehen:
- Datei- und Druckerfreigabe (SMB eingehend)
- Windows-Verwaltungsinstrumentation (WMI eingehend)
- Windows-Verwaltungsinstrumentation (DCOM eingehend)
- Windows-Verwaltungsinstrumentation (ASync eingehend)
Jetzt kann das Computerkonto für die DAG vorbereitet werden, dazu wird im Active Directory ein Computer Konto erstellt, welches den Namen der DAG trägt. In meinem Fall ist das FWDAG1, das Computer Konto muss nach dem Erstellen deaktiviert werden.
Auf das Computerkonto der DAG bekommt ebenfalls die Gruppe „Exchange Trusted Subsystem“ Vollzugriff
Hinweis: Wer den Reiter Sicherheit nicht sieht, muss unter Ansicht die „erweiterten Features“ aktivieren.
Bevor die DAG konfiguriert werden kann, müssen noch die Datenbanken an ihren Bestimmungsort verschoben werden, dabei lässt sich auch gleich der Name anpassen:
Get-MailboxDatabase -Server FWEX1 | Set-MailboxDatabase -Name MBDB01 Get-MailboxDatabase -Server FWEX2 | Set-MailboxDatabase -Name MBDB02
Danach kann die Datenbank verschoben werden, das Verschieben funktioniert nur auf dem Exchange Server, der gerade die Datenbank hostet, der folgende Befehl muss also auf jeweiligen Exchange Server ausgeführt werden:
Get-MailboxDatabase -Server FWEX1 | Move-DatabasePath -EdbFilePath d:\MBDB01\MBDB01.edb -LogFolderPath d:\MBDB01 Get-MailboxDatabase -Server FWEX2 | Move-DatabasePath -EdbFilePath d:\MBDB02\MBDB02.edb -LogFolderPath d:\MBDB02
Jetzt sollte es in der EAC ungefähr so aussehen:
Jeder Exchange Server hostet seine eigene Datenbank, MBDB01 ist auf FWEX1 aktiv und MBDB02 auf FWEX2. Jetzt kann die DAG angelegt werden:
Als Database Availability Group Name wird der Name des eben erstellten Computer Kontos angegeben, Zeugenserver ist FWFS1 und das Zeugenverzeichnis soll unter C:\Wittness liegen (oder wo auch immer). Mit Exchange 2016 soll es möglich sein, die DAG auch ohne Cluster IP zu betreiben, ich vermute aber mal das wird sich auf Server 2016 beziehen, ich musste sie angeben.
Der frisch angelegten DAG müssen jetzt die Exchange Server zugewiesen werden:
Beide Exchange Server auswählen und hinzufügen:
Das Hinzufügen der Server dauert etwas
In der EAC sollte es jetzt so aussehen, FWEX1 und FWEX2 sind Mitglieder der DAG.
Zum Schluss müssen noch die Datenbankkopien konfiguriert werden:
Hinweis: Wer den Menüpunt „Datenbankkopie hinzufügen“ nicht sieht, einmal EAC neustarten.
Für beide Datenbanken den jeweils anderen Server hinzufügen und Speichern
Die DAG ist jetzt fertig. Die Tests können beginnen.
Der nächste Beitrag wird sich dann um das Loadbalancing drehen.
Ich schaffe es nicht die verfluchten DCOM 10028 Meldungen aus den Eventlogs zu verbannen, hat dazu vielleicht jemand eine Lösung?
Das AD Computer Objekt DAGxxx ist deaktiviert, interessiert den Servermanager aber nicht. Ich entferne den virtuellen DAGComputer aus dem Servermanager und er taucht wieder auf, so auch die Fehlermeldungen:
DCOM konnte über keines der konfigurierten Protokolle mit dem Computer XXXDAG.local kommunizieren. Während der Aktivierung von CLSID {8DF3A05B-D86B-11D0-A075-00C04FB5682A} von PID 31f4 (C:\Windows\system32\ServerManager.exe) angefordert.
Hi erstmal großes Lob an Franky wie immer für seine Super Anleitungen.
Wir hatten vor einiger Zeit auch 2 Exchange 2016 eingerichtet, jetzt sollten die in einer DAG zusammengefasst werden.
alles komplett nach Anleitung eingerichtet, Zertifikate alles valid,DAG Replikations-Netzwerk laut Cluster alles up und gut aber ich schaffe es nicht eine DB Kopie zu erstellen,
es kommt immer der Fehler das keine sicherer Kanal eingerichtet werden kann.
beim Test am Server1 mit: Test-ReplicationHealth -Identity server2
TcpListener *FEHLER* Fehler beim Statustest des TCP-Listeners für den Microsoft
Exchange-Replikationsdienst auf Server ’server2′. Dieser
Server kann erst an der Replikation teilnehmen, nachdem der
Fehler behoben wurde. Fehler: Fehler beim Kommunizieren mit dem
Server ’server2′. Fehler: Es konnte kein sicherer Kanal
eingerichtet werden.
beim Test am Server 1 kommt ganz normal
TasksRpcListener Prüfung
bestanden
Was hat es mit dem sicheren Kanal auf sich, dass das seeden einer Datenbank verhindert?
Hallo Frank, ich habe mittlerweile schon einige deiner Artikel umgesetzt und auch als Basis (natürlich mit Verweis auf deine Seite) für meine Blogbeiträge genommen unter http://www.leibling.de .
Nun befasse ich mich mit dem Thema HA eines Netzwerkes, unter anderem mit dem Thema DAG – jedoch finde ich keine Informationen zu folgenden Themen:
a) FSW, wenn ich das an EINEN Server binde, ist das dann nicht ein Single Point of Failure?
b) Was passiert wenn der Witness-Server nicht da ist?
c) Kann ich das FSW nicht auf eine DFS Freigabe zeigen lassen?
Weiterhin würde mich interessieren, warum bei den vielen beispielen oft eine IP lose Konfiguration bevorzugt wird?
Danke dir vielmals :).
Hi Peter,
der Witness ist prinzipiell ja nur im Fehlerfall zur Bildung eines gültigen Quorums nötig. Deswegen wird z.B. bei ungeraden Knotenzahlen größer zwei gar kein Witness benötigt (und daher im FSW auch kein Verzeichnis angelegt), da sich in dieser Konstellation die Knoten selber einigen können, wer denn nun „weg“ ist. Das Problem eines Clusters und die Notwendigkeit des Witness sieht man am besten bei zwei Knoten (und damit prinzipiell auch jeder anderen geraden Knotenanzahl): ist die Verbindung zwischen beiden unterbrochen, kann kein Knoten von sich aus sagen, wer denn nun ausgefallen ist (z.B. wenn beide Server noch laufen und bei einem die Netzwerkkabel gezogen wurden). Es kann jedoch nur noch der eine *mit* Kabel die Dienste anbieten. Bei drei wäre es klar, da können sich dann zwei noch unterhalten und damit ihr „Leben“ feststellen. Da kommt dann bei zweien der Witness ins Spiel. Wer den noch erreichen kann, ist der lebende, der andere muss die Ressourcen loslassen und ggf. seine Dienste runterfahren.
Das betrachtend führt ein fehlender Witness im laufenden Betrieb zu keinen Problemen, allenfalls zu Warnmeldungen. Nur, wenn in diesem Moment der Cluster ein Problem hat, wird es schwierig(er), ein gültiges Quorum zu bilden.
Idealerweise nimm eine ungerade Knotenanzahl, dann wird das auch gar nicht benötigt :)
Hat jemand eine Idee zu der Fehlermeldung
„Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. “
es werden keine Eigenschaften der DAG auf der Detailseite angezeigt
Hi Michael,
ich würde dir dafür einen Loadbalancer empfehlen, z.B. den Kemp (https://kemptechnologies.com/de/), gibt es zum Probieren auch als freie Variante oder auch den HAProxy (http://www.haproxy.org/) als freie Alternative. Es gibt natürlich auch noch viele andere, die beiden haben wir hier im Einsatz.
Damit kannst du deinen Traffic aber gut verteilen und hast für alle Services einen Einstiegspunkt. Dort kannst du dein Autodiscover dann ausfallsicher auflaufen lassen und auch deine MXen darauf setzen, egal, wie viele DAG-Member du dahinter hast. Auch sehr angenehm, wenn man mal z.B. zur Wartung einen rausnehmen will.
Hallo,
ich möchte gerne meine erste DAG machen, bevor ich beginne habe ich noch die Frage wie es mit dem MX Record und Autodiscover funktioniert. Derzeit verweist mein MX Record auf den einen Exchange 2016 Server den ich habe gleich gilt auch für das Autodiscover, wenn ich jetzt einen weiteren Exchange Server installiere benötige ich dann einen weiteren MX Record und autodiscover Link? Bzw. wie finden die eingehenden Mails den Weg zum Client wenn der Server auf den der MX Record zeigt down ist?
Vielen Dank Franky für die tolle Seite, sie ist super erklärt und hilfreich.
Vielen Dank.
LG Michael
Nee, das geht nicht. Guck mal hier: https://docs.microsoft.com/en-us/exchange/high-availability/database-availability-groups/database-availability-groups
Zweiter Absatz: In einer DAG müssen alle Server in der gleichen Version sein. Daher kannst du eine 2013er DAG auch nicht „weich“ in eine 2016er migrieren, sondern musst eine neue 2016er aufsetzen, dann die Postfächer rüberschieben und am Ende die leere 2013er DAG wegschmeißen.
Hallo zusammen,
habe folgende Situation:
Exchange Version 15.0 (Build 1365.1) CU19
und
Exchange Version 15.1 (Build 1415.2) CU8
Folgenden Fehler gibt er raus:
„EX02“ kann der Datenbankverfügbarkeitsgruppe „DAGtest“ nicht hinzugefügt werden, weil mindestens eins der aktuellen Mitglieder eine andere Exchange-Version hat. Version von „EX01“: Version 15.0 (Build 1365.1). Version von „EX02“: Version 15.1 (Build 1415.2).
Geht es gar nicht? oder habe ich etwas nicht beachtet?
Hallo zusammen,
ich habe das gleiche Problem wie Udo, nach dem hinzufügen des ersten Server in die DAG. „Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt“
Hat da einer schon eine Lösung?
Hallo Frank,
wie immer Top Anleitung. Ich hätte tatsächlich noch eine Frage und sogar eine Anmerkung.
Zur Frage:
Wofür wird die Cluster IP eigentlich benötigt? Sollte man die Cluster IP vielleicht im DNS für das Autodiscover hinterlegen oder hat die Cluster IP nichts mit einem Balancing zu tun sondern ist nur organisatorisch?
Dann eine Anmerkung:
Auch wenn man extra eine Netzwerkkarte für die Replikation anlegt, so kann auch die Karte im Produktiv Netz dafür genutzt werden, ist mir ganz zufällig aufgefallen.
Mit Get-DatabaseAvailabilityGroupNetwork -Identity DAGNAME wird es dann deutlich. Wir haben die Konfiguration von automatisch auf manuell geändert und für die Replikation ausschließlich die extra angelegte Netzwerkkarte zugewiesen.
Das haben wir so erledigt:
Set-DatabaseAvailabilityGroup DAGNAME -ManualDagNetworkConfiguration:$true
Set-DatabaseAvailabilityGroupNetwork -Identity „DAGNAME\MapiDagNetwork“ -ReplicationEnabled:$false -IgnoreNetwork:$true
Ist vielleicht ein nice to know!
Super Artikel, danke dafür!
Ich hab ein Problem bei meiner Installation: wenn ich die DAG angelegt und den ersten Server hinzugefügt habe, steht im EAC, wenn ich die DAG markiere, die Meldung „Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.“ und es werden keine Eigenschaften der DAG auf der Detailseite angezeigt.
Ich hab schon überall gesucht, konnte dazu aber nirgends was finden. Kennt das einer? Wie bekomme ich das weg?
Hallo Frank,
wieder mal eine tolle Anleitung die wir demnächst in unserer Testumgebung mal nachbauen werden.
Uns drängt sich aber eine Frage auf:
Wenn wir einen Datenbankschwenk auslösen, was passiert mit den Anmeldungen der Clients am Exchange? Müssen diese Outlook schließen und wieder öffnen weil die Anmeldung ja jetzt eigentlich am zweiten Exchange erfolgen muss? Oder wird beim Datenbank Schwenk auch die Anmeldung durchgereicht?
Wäre schön wenn du mir das kurz beantworten könntest.
Grüße
Andreas
Hallo Frank.
Vielen Dank für deine Hilfestellung. In der Zwischenzeit konnte ich das Problem lösen, und bin deinem Rat gefolgt, indem ich die Postfächer verschoben habe. Die Ursache waren die Systemkonten „Federated und Migration“ außerdem hatte ich in der AD noch verwaißte Syystemkonten der alten 2010er DAG gefunden, obwohl ich diese sauber aus dem AD entfernt hatte und die Exchange 2010 deinstalliert hatte. Naja, ich habe also sämtliche Systemkonten deinstaliert und anschließend aus de, exchange/bin Verzeichnis eine erneutes prepareAd ausgeführt und im Anschluss die neuen Sytemkonten konfiguriert. Danach funktionierte alles wieder.
Gruß, Michael
Hallo Frank.
Danke für die Antwort. Die Idee hatt ich auch schon. Allerdings habe ich folgendes Problem: Beim verschieben eines Postfachs von Mailbox1 zu Mailbox2 bkomme ich folgende Fehlermeldung:“Für diese Organisation wurden mehrere potenzielle Migrationspostfächer gefunden.
Geben Sie bitte ein bestimmtes Partitionspostfach an, das verwendet werden soll.“
Bisher gemacht habe ich folgendes: Systemmailboxes gelöscht und neu angelegt; In der AD nach Migrationsmailbox gesucht, fazit: Es ist nur eine zu finden.
Insofern ich dazu keine Lösung habe, möchte ich die Datenbanken auf neue Volumes verschieben. Da bin ich mir aber nicht sicher wie der beste Weg aussieht.
Gruß, Michael.
Hi Michael,
Ich würde dir empfehlen das Problem mit dem Verschieben der Postfächer zu lösen und dann neue Datenbanken auf dem neuen Storage zu erstellen. (Der neue Storage bzw. das Verschieben der Datenbanken wird nicht das Problem mit dem Verschieben der Postfächer beheben, falls das die Intention für das Verschieben der Datenbanken ist). Das Problem mit Verschieben der Postfächer lässt sich aber meist einfach lösen. Schick doch mal die Ausgabe von „get-mailbox -Arbitration | fl name,PersistedCapabilities“. Dann kannst du ja immer noch entscheiden ob du die Datenbanken lieber offline nehmen willst und dann verschieben, oder neue Datenbanken erstellst und die Postfächer verschiebst.
Gruß, Frank
Nochmal ich.
MIr ist ein kleiner Schreibfehler unterlaufen: Es soll natürlich heissen nach dem verschieben der Datenbanken…und dann neue Kopien erstellen.
Hallo Michael,
du kannst zwar die Datenbanken verschieben, aber wäre es nicht einfacher eine neue Datenbank am neuen Speicherort zu erstellen und dann die Postfächer zu verschieben? Dann brauchst du keine Downtime…
Gruß, Frank
Hallo zusammen.
Auch von mir ein dickes Lob an Franky und seine Website. Tolle Erklärungen und Ideen, und zudem ein sehr schöner Erfahrungstausch.
Ich betreibe der zeit eine 2016 DAG mit 2 Exchangeservern und einem Whitness, die jeweils 6 Datenbanken verwalten. Eingebunden auf Mountpoints.
Leider besteht mitlerweile die Notwendigkeit, dass ich die Datenbanken auf neue Volumes verschieben muss. Hier bin ich mir bezüglich der Vorgehensweise etwas unsicher und würde mich über Hilfestellung freuen.
Ich gehe davon aus das ich die Bindung der Datenbanken aufheben muss und die Logs wohl gelöscht werden müssen…Stimmt das soweit? Aber was mache ich mit den Datenbankkopien? Auch löschen und nach dem Verschieben der Datenbankkopien wieder einbinden?
Ich bedanke mich schon mal im Vorraus für jede Hilfestellung.
Beste Grüße, Micha.
Hi,
wir haben Server 2012 R2 mit Exchange 2016 (4 Stück) mit jeh 2 Netzwerkkarten (Mapi und Replication).
Die DAG-Netzwerke haben wir automatisch konfigurieren lassen, allerdings auch mit einer IP und keine IP-less-DAG
Der DAG haben wir nun eine IP aus dem selben Subnet wie das MAPI netz gegeben. (10.0.253.27/24)
Braucht die DAG auch eine IP im Replikationsnetzwerk, oder nur im MAPI (10.10.10.0/24)
Grüße
Tobias
@Roland
Du kannst mittels „Set-DatabaseAvailabilityGroup EXCHDAG01 -ManualDagNetworkConfiguration:$true“ die manualle Configuration aktivieren und dann für das entsprechende Netzwerk die Replikation bzw. die MAPI zugriffe deaktivieren „Set-DatabaseAvailabilityGroupNetwork -Identity „EXCHDAG01\MapiDagNetwork“ -ReplicationEnabled:$false -IgnoreNetwork:$true“
Guck mal hier:
http://www.admin-enclave.com/en/articles/exchange/206-migrate-from-exchange-2010-to-exchange-2016.html
Bei Punkt 13f
Hallo und Guten Tag,
mich würde einmal interessieren, woher weiß der Exchange oder die DAG denn nun, dass es zur Replizierung der Datenbank jetzt das andere Netzwerk nehmen soll?
Habt Ihr da eine Info für mich?
Vielen Dank
Gruß
Roland
Wenn die Datenträger / Partitionen / Volumes für die Exchange DBs im ReFs Layout vorliegen muss die DAG entsprechend so konfiguriert werden. „[PS] C:\>Set-DatabaseAvailabilityGroup -FileSystem ReFs“
Hallo & guten Abend,
als erstes möchte ich erstmal ein ganz großes Lob an Franky aussprechen. Das sind super How-To’s wo sich der Hersteller mal eine Scheibe abschneiden könnte. Echt prima. Vielen lieben Dank für die Mühe.
Ich hab ein Problem mit einer Failoback Situation einer 2016er Exchange CU3 DAG auf 3 Server 2012 R2 mit allen Updates & Hotfixes. Microsoft Ticket ist schon seit gut 2 Wochen in Bearbeitung, aber da fehlt es meiner Meinung nach am grundlegenden Sachverstand. Deswegen meine Frage hier an die echten Pros:
Folgende Situation:
1 * MAPI Netzwerk IP im LAN
1 * Replikations IP im isolierten Netz nur für die Exchange Server
DAG über 3 Server angelegt mit je einer IP im selben Netz (LAN & Repliaktion)
Je Server eine Mailboxdatenbank angelegt
Je eine Replikationen auf die 2 verbleibenden Server
Dann ist alles grün. DAG funktioniert in jeglicher Hinsicht & beide IP-Adressen der DAG aus den Netzen (LAN & Replikation) sind pingbar, Failover-Cluster Manager ist auch alles bestens.
Dann simuliere ich einen Failover und starte den ersten Server im Bunde neu. Der hat anscheinend eine Art Master Quorum Funktion.
Danach fehlt dieser Knoten logischerweise erstmal bis er wieder online ist. Die Replikationen werden in der Zwischenzeit aktiviert & alles läuft weiter bis auf den Ping auf die Replikations-IP.
Wenn der Knoten dann wieder on ist und ich im Failover-Cluster Manager dann die Replikations-IP wieder aktivieren will kommt folgender Fehler zur Replikations-IP der DAG:
Die Cluster-IP-Adressressource „Cluster-IP-Adresse „10.254.0.74““ kann nicht online geschaltet werden, da die Konfiguration des Clusternetzwerks „Clusternetzwerk 2“ den Clientzugriff nicht zulässt. Verwenden Sie das Snap-In „Failovercluster-Manager“, um die konfigurierten Eigenschaften des Clusternetzwerks zu prüfen.
Im Ereignis-Log gibt’s das noch dazu:
[RES] IP Address : Cannot bring resource online because network 95b417df-430b-4ab1-ad36-3d73bd2e495b (Clusternetzwerk 2) has role 1.
[RHS] Resource Cluster-IP-Adresse „10.254.0.74“ has indicated that it cannot come online on any node.
[RCM] HandleMonitorReply: ONLINERESOURCE for ‚Cluster-IP-Adresse „10.254.0.74“‚, gen(0) result 5943/0.
Wie gesagt vor dem Restart des ersten Knoten war noch alles gut. Danach bekomm ich das Teil nicht mehr Online. Somit findet keine Replikation mehr statt da dies auf keinen Fall über das LAN laufen darf.
Wenn Ihr mir bei diesem Problem zur Seite stehen könntet….Ich wäre Euch unendlich Dankbar.
Vielen Dank noch mal für die super Anleitung & hoffentlich für kompetente Hilfe ;)
Das Problem überschreitet die Kompetenzen des Microsoft Supports. Leider traurig aber wahr.
Dann wünsche ich allen Pros einen schönen Feierabend & VG
Christoph
Eine IP-lose DAG kannst du erstellen, indem du als IP die 255.255.255.255 angibst. Das funktioniert ab Server 2012 R2.
Ich habe irgendwo gelesen das Exchange 2016 nur noch eine NIC haben sollte und nicht mehr zwei … sprich die Auftrennung in das Normale LAN und in ein Replications LAN entfällt. Du hast es aber aufgetrennt. Was macht man jetzt am besten?
Hi Bernd,
technische gesehen funktioniert es auch mit einer Netzwerkkarte, auf dem Exchange Team Blog unter dem Punkt „DAG Network Design“ findet sich auch der entsprechende Hinweis:
http://blogs.technet.com/b/exchange/archive/2015/10/12/the-exchange-2016-preferred-architecture.aspx
Im TechNet liest sich es schon wieder etwas anderes, hier ist der Punkt „Network requirements“ interessant:
https://technet.microsoft.com/en-us/library/dd638104(v=exchg.160).aspx
Ich tendiere immer noch zur Trennung zwischen MAPI und Replikations Netzwerk, also im Prinzip klassisch FrontEnd und BackEnd, so kommt sich nichts in die Quere falls mal etwas unvorhergesehenes passiert.
Allerdings haben 2 Netzwerkkarten auch Nachteile, es lässt sich nur ein Default Gateway setzen, andere Netze müsssen ggf. per Routen gepflegt werden, wenn eine DAG beispielsweise über mehrere Standorte gespannt wird. Das ist natürlich komplexer und somit auch anfälliger für Fehler. Es kommt also wie so oft auf die Umgebung und die Anforderungen an.
Gruß, Frank
Schau dir mal Kemp (http://kemptechnologies.com/de/) an. Mit dem arbeite ich die meiste Zeit.
Gruß
Patric
Hi Patric,
ja, ich hab einen F5 BigIP LTM und einen Kemp Loadmaster mit ESP stehen. Mir gefallen die F5 persönlich besser, aber das wird Geschmackssache sein.
Ich werde das Loadbalacing noch gesondert betrachten.
Gruß, Frank
Hallo André,
schau Dir mal HA-Proxy oder loadbalancer.org an.
Gruß
Marcel
Super Beitrag!
Was für eine OpenSource LoadBalancer Lösung kannst du empfehlen. Ich habe bisher immer nur Exchange CAS (in CAS-Array) über MS NLB betrieben ohne weitere Rollen auf diesen CAS – Servern.
Danke und Gruss aus der Schweiz!
André
Hi André,
da wäre auch noch Zen: http://www.zenloadbalancer.com/
Gruß, Frank