Microsoft Exchange 2016 Enterprise komplett hochverfügbar bereitstellen
Hallo Zusammen,
Ziel ist es den bestehenden einen Exchange 2010 SP3 zur aktuellen Exchange 2016 Enterprise Edition zu migrieren.
Der neue Exchangeserver muss hochverfügbar sein, sodass E-Mail etc. immer verfügbar sind.
Angedacht sind zwei physische Server mit je lokalem Storage auf denen Windows Server 2016 Standard mit Exchange 2016 Enterprise betrieben wird.
Sind um Exchange 2016 komplett hochverfügbar bereitzustellen DAGs ausreichend oder bedarf es auch bestimmte Rollen in einem Microsoft Failovercluster zu betreiben?
Im WWW haben ich bisher speziell dazu noch keine Informationen finden können.
Danke im Voraus für Eure Tipps!
Gruß
Ziel ist es den bestehenden einen Exchange 2010 SP3 zur aktuellen Exchange 2016 Enterprise Edition zu migrieren.
Der neue Exchangeserver muss hochverfügbar sein, sodass E-Mail etc. immer verfügbar sind.
Angedacht sind zwei physische Server mit je lokalem Storage auf denen Windows Server 2016 Standard mit Exchange 2016 Enterprise betrieben wird.
Sind um Exchange 2016 komplett hochverfügbar bereitzustellen DAGs ausreichend oder bedarf es auch bestimmte Rollen in einem Microsoft Failovercluster zu betreiben?
Im WWW haben ich bisher speziell dazu noch keine Informationen finden können.
Danke im Voraus für Eure Tipps!
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 334130
Url: https://administrator.de/forum/microsoft-exchange-2016-enterprise-komplett-hochverfuegbar-bereitstellen-334130.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
10 Kommentare
Neuester Kommentar
Guckst du mal hier:
https://technet.microsoft.com/de-de/office/dn756393.aspx
https://technet.microsoft.com/de-de/office/dn756393.aspx
moin...
ja schon, allerdings hat DAG nix mit hochverfügbar bereitstellen zu schaffen...
es wäre ja auch zu klären was man sich unter hochverfügbar vorstellt!
ein loadbalacing zwischen den diensten mittels windows loadbalancing funktioniert allerdings nicht, denn fail-over cluster und windows loadbalancing auf dem gleichen server schließen sich gegenseitig aus!
also braucht der TO ersteinmal einen loadbalancer...
mindesten alles an Switchen doppelt, 2 SAN´s... und ich sach mal 4 CPU bleche minimum- USV´s und alles an mindestens 2 brandabschnitten...
und und und...
war es das was du dir unter hochverfügbar vorstellt
Frank
ja schon, allerdings hat DAG nix mit hochverfügbar bereitstellen zu schaffen...
es wäre ja auch zu klären was man sich unter hochverfügbar vorstellt!
ein loadbalacing zwischen den diensten mittels windows loadbalancing funktioniert allerdings nicht, denn fail-over cluster und windows loadbalancing auf dem gleichen server schließen sich gegenseitig aus!
also braucht der TO ersteinmal einen loadbalancer...
mindesten alles an Switchen doppelt, 2 SAN´s... und ich sach mal 4 CPU bleche minimum- USV´s und alles an mindestens 2 brandabschnitten...
und und und...
war es das was du dir unter hochverfügbar vorstellt
Frank
Loadbalancer vor die beiden Server stellen dürfte das Sinnvollste sein.
Daraus resultiert dann Switches doppelt und Internet Router und Leitung doppelt mit Link Balancing auf unterschiedliche Provider. Separate Hauseinführung sowieso.
Ohne das wäre eine Hochverfügkarkeit nur der Exchange Server und das dann vermeintliche Denken das allein das reicht um Email hochverfügbar zu machen, natürlich sinnfreier Blödsinn.
sodass E-Mail etc. immer verfügbar sind.
Wie Kollege Vision2015 oben schon richtig bemerkt bedingt das dann natürlich auch eine Hochverfügbarkeit der Infrastruktur, sprich lokales Netzwerk UND Internet Zugang.Daraus resultiert dann Switches doppelt und Internet Router und Leitung doppelt mit Link Balancing auf unterschiedliche Provider. Separate Hauseinführung sowieso.
Ohne das wäre eine Hochverfügkarkeit nur der Exchange Server und das dann vermeintliche Denken das allein das reicht um Email hochverfügbar zu machen, natürlich sinnfreier Blödsinn.
Moin,
Gruß,
Dani
Normalerweise reicht ein DAG und DNS-Roundrobin. Sonst haste ja wieder den Loadbalancer als Singlepoint of Failure.
DNS Round Robin bringt ein paar Nachteile mit sich- Evtl. keine gleichmäßige Lastverteilung auf die Backends
- kein aktive Überwachung via TCP möglich
- Clients welche nur einen DNS-Namen sprechen können (z.B. 3rd Party Software)
Gruß,
Dani