Schlagwort-Archive: Exchange

Exchange Server

Failover VS Switchover – Exchange HA

★ von

Exchange 2013Bei redundanten Systemen, die eine Dienstunterbrechung über eine Übernahme der Ressourcen durch ein weiteres System abfedern, wird oft von Failover und Failback gesprochen.
Mit Exchange Server 2010 und 2013 wird der Begriff Switchover als gesteuertes Umschalten eingeführt.

Dabei ist ein absichtlicher Wechsel der Ressourcen durch den Administrator gemeint, vornehmlich in einem Wartungsfenster.
Microsoft spricht hierbei immer von Exchange als Cluster Workload im Zusammenhang von Switchover, allerdings hat auch bei einer Hyper-V Live Migration ein geplanter Failover (Switchover) eine andere Auswirkung als z.B. ein Failover im Fehlerfall eines Servers.

Exchange 2013 auf einem Cluster ist darauf ausgelegt mit Failover und Switchover umzugehen, dabei unterscheidet es nach unterschiedlichen Kriterien.
Folgende Arten von Switchover werden unterstützt:

  • Database switchover (Datenbankswitchover)
  • Server switchover (Serverswitchover)
  • Datacenter switchover (Datencenterswitchover)

Bei einem Datenbankswitchover und Serverswitchover werden einzelne Datenbanken einer DAG oder alle Datenbanken auf ein weiteres DAG Mitglied verschoben bzw. aktiviert.

Eine Datencenterswitchover erfordert eine komplexere Infrastruktur, um Ausfallsicherheit für Standorte zu erreichen: So werden mindestens drei Exchange Standorte vorausgesetzt. An einem dritten Standort reicht es i.d.R. einen Witness Server (Zeugenserver) bereit zu halten, hier kann auch » Azure in Form einer Cloud Witness als DAG-Zeugenserver agieren.

Weitere Notwendigkeiten und das Prozedere eines Datencenterswitchover ist hier beschrieben:
» https://technet.microsoft.com/(…)/dd351049%28v=exchg.150%29.aspx

Eine Übersicht in welchem Fehlerfall welche Aktion automatisch ausgelöst wird oder manuell auszulösen ist gibt es hier:
» https://technet.microsoft.com/(…)dd298067(…)150 (siehe Abschnitt Failover)
Gut über 25 Szenarien sind hier übersichtlich tabellarisch aufbereitet.

Eine detaillierte Beschreibung der Unterstützung von Switchover und Failover für Exchange 2010 ab SP2 ist hier zu finden:
» https://technet.microsoft.com/(…)dd298067(…)141

Stay tuned,
N.Own

Netzwerkeinstellungen auf einem Cluster

★ von

„Best Practice“ Empfehlungen sind nicht immer passend zu jeder Lösung, die man aufbauen kann. Im Falle von Hyper-V gibt es recht klare Richtlinien bzgl. der Netzwerkkonfiguration auf einem Cluster, die man berücksichtigen sollte:

  • Trennung und Isolation der Netzwerke nach Einsatzzweck: Management, Live Migrations, Storage, Client Access, Backup etc.
  • Anpassung der Adapter und Bindungen (Network Binding Order)
  • Anpassung der Quality of Service Policy hinsichtlich der Prioritäten ab W2K12

Siehe folgenden Artikel für Hyper-V Cluster:
» http://technet.microsoft.com/library/dn550728.aspx

Bei Nutzung von Cluster Shared Volumes (CSV) sollte man die Metric überprüfen, i.d.R. wählt der Cluster das passende CSV Netzwerk selbst aus – eine Kontrolle kann nicht schaden:
» http://technet.microsoft.com/en-us/library/ff182335%28WS.10%29.aspx

Für Exchange 2013 sowie 2010 Verfügbarkeitsgruppen (Database Availability Groups – DAG) gibt es jeweils einen Artikel:
Exchange 2013: » http://technet.microsoft.com/(…)exchg.150%29.aspx#Dat
Exchange 2010: » http://technet.microsoft.com/(…)exchg.141%29.aspx#Dat

Grundlegende Empfehlungen, die für jeden Cluster gelten, sind hier zu finden:
TechNet Blog: » http://blogs.technet.com/(…)configuring-windows-failover-cluster-networks.aspx
MSDN Channel 9: » http://channel9.msdn.com/Events/TechEd/(…)

Die Empfehlungen des Herstellers sollte man mindestens prüfen und idealerweise entsprechend umsetzen, außer es gibt triftige Gründe gewisse Einstellungen anders zu wählen für den eigenen Anwendungsfall.

Stay tuned,
N.Own

Exchange 2010 DAG: Database Availability Groups

★ von

Mit dem Erscheinen von » Exchange 2010 Anfang des Monats häufen sich die Fragen ‚rund um das Exchange Clustering und den neuen Exchange DAG („Database Availability Groups“).

Mit den Database Availability Groups wurde die Exchange Architektur hinsichlich Clustering weiterhin verbessert, die Installation und Verwendung der Failover Cluster Komponenten geschieht nun weitestgehend im Hintergrund, ebenso die Konfiguration.

Wie steht es um die bisherigen und neuen Cluster Möglichkeiten?
Die schlechte Nachricht: LCR („Local Continuous Replication“) und SCR („Single Copy Cluster“) sind mit Exchange 2010 passé.

Die gute Nachricht: Exchange Hochverfügbarkeit wird einfacher, CCR („Cluster Continuous Replication“) und SCR („Standby Continuous Replication“) wurden konsequent fortgeführt und zu DAG zusammengefasst.

Das Limit für DAG liegt bei 16 Exchange Nodes, die über verschiedene Sites verteilt sein dürfen.

Welche Quorum Modelle werden verwendet?
Database Availability Groups verwendet nach wie vor ein Subset von Windows Server Failover Cluster Komponenten und bietet folgende Quorum Möglichkeiten:
Node Majority
Bei einer ungeraden Anzahl an Servern (Nodes) kommt dieses Model zur Verwendung. Eine Mehrheit an Votes ist über die Nodes gegeben.
Node & File Share Majority
Bei einer geraden Anzahl an Nodes wird ein File Share Witness eingerichtet, damit eine Mehrheit an Votes besteht.
Die Auswahl des passenden Quorum Models geschieht ebenfalls im Hintergrund.

Weitere Informationen zu den Failover Cluster Quorum Modellen:
» https://www.cluadmin.de/index.php?p=500

Weiterführende Informationen zu den Exchange 2010 Database Availability Groups:
» http://technet.microsoft.com/en-us/library/dd298065.aspx

Exchange 2010 bringt interessante Möglichkeiten zum Thema Hochverfügbarkeit mit und vereinfacht den Einsatz von Exchange Clustering immens.

Stay tuned,
N.Own

Exchange 2007 SP1 erschienen

★ von

Letzten Freitag ist Exchange 2007 SP1 erschienen:

» D. Melanchthon: Exchange Server 2007 SP1 fertig

» TechNet: What’s New in Exchange Server 2007 SP1

Inj Bezug auf Clustering ist besonders das feature Standby Continuous Replication spannend, eine gute Möglichkeit, um einem Exchange CCR Cluster zusätzliche Redundanz hinzuzufügen und damit die Verfügbarkeit im Falle des Ausfalls einer ganzen Site weiterhin zu erhöhen.

» TechNet: Standby Continuous Replication

SCR bietet einem die Möglichkeit einen weiteren Exchange Server an einer anderen Lokation verfügbar zu halten – ein Feature, daß einem sonst nur klassische GeoCluster bieten.

Stay tuned,
N.Own