none
Exchange Server 2013 DAG Automatische Aktivierung von Datenbankkopien Ausschalten RRS feed

  • Frage

  • Hallo zusammen,

    ich habe folgendes Problem: Ich verwalte zwei Microsoft Exchange 2013 Server welche innerhalb eines DAG zusammengefasst sind. Die beiden Server befinden sich ca. 4000km voneinander entfernt (einer in Deutschland, der andere im Ausland) und sollen sich gegenseitig abgleichen, um Ausfallsicherheit zu gewährleisten. Konfiguration habe ich vorgenommen, es funktioniert auch bestens. Ich habe also zwei Datenbanken (auf jedem Server eine), welche auf dem jeweils anderen Server gespiegelt sind.

    Nun zu dem Problem: Hardwarebedingt gibt es beim Router in Deutschland jede Nacht einen kurzen Reset (zwischen beiden Standorten existiert eine Interne VPN Verbindung, welche vom Router jede Nacht neu hergestellt wird). Sobald die Verbindung erneuert wird, wird die Datenbankkopie des Deutschen Servers auf dem Server im Ausland aktiviert.

    Dies führt natürlich zu ziemlichen Leistungseinbußen beim Arbeiten mit den Deutschen Mail Accounts, weil sich die Mitarbeiter aus Deutschland automatisch mit dem Server im Ausland verbinden, was aufgrund des geringen Uploads und der Latenz dann natürlich nicht so schön ist.

    Folgende Dinge habe ich bereits ausprobiert, um weiterhin die Datenbanken automatisch synchronisieren zu lassen, aber das automatische Aktivieren der Kopie auf dem Server im Ausland auszuschalten. (Nichts gebracht bedeutet es aktiviert sich Nachts wieder die Kopie)

     - Serverswitchover auf den Server in Deutschland (Nichts gebracht)

     - Manuelles Aktivieren der Datenbankkopie (Nichts gebracht)

     - Suspend-MailboxDatabaseCopy -Identity "Mailbox Database XXXXXXXXXX\XXXXXXXX" -ActivationOnly (Nichts gebracht)

     - Set-MailboxServer -Identity SERVER05 -DatabaseCopyAutoActivationPolicy Blocked (Hier gibts das Problem das nach einem Neustart des Servers die Datenbank gar nicht mehr eingebunden wird)

    Ich würde mich freuen wenn mir jemand helfen kann

    • Bearbeitet BigManda Samstag, 25. Juni 2016 10:11 Formatierung zerschossen
    Samstag, 25. Juni 2016 10:10

Alle Antworten

  • Moin,

    a. Sind die beiden Standorte sauber als IP-Subnetze und AD-Sites gepflegt?

    B. Wie sieht die Witness-Platzierung und -Konfiguration aus?

    c. Welcher Knoten ist im Regelbetrieb der Active Manager (Cluster Owner)?

    Du könntest die Elastizität des Clusters etwas erhöhen, aber teile uns doch erst mal die o.g.  Infos mit, vielleicht fällt da schon etwas auf...


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Samstag, 25. Juni 2016 20:12
  • (Die Angaben sind leicht verändert)

    Server1: 192.168.110.10 (Mail Server Deutschland)
    Server2: 192.168.110.11 (Domain Controller / Active Directory Server Deutschland)

    Server3: 192.168.120.12 (Mail Server Ausland)
    Server4: 192.168.120.13 (Domain Controller / Active Directory Server / Zeugenserver Ausland)

    Die Subnetze sind entsprechend im DAG Eingetragen:
    192.168.110.0/24
    192.168.120.0/24

    Das DAG selbst beinhaltet den korrekten Zeugenserver (Server4.unsereDomain.local) und hat die korrekten Mitglieder (Server1 und Server3). Die "Database Availability Group-IP-Adressen" in den Einstellungen sind nicht gesetzt (haben keinen Inhalt), das Zeugenverzeichnis ist auf ein Verzeichnis in Server4 gesetzt und die Einstellung "Database Availability Group-Netzwerke manuell konfigurieren" ist aktiviert.

    Bezüglich der dritten Frage weiß ich jetzt nicht direkt was du meinst. Beide Active Directory Server haben die höchste Stufe und dienen auch der Redundanz (falls das deine Frage beantwortet)

    Bezüglich DNS und Connectivität habe ich bereits auch schon mehrere Test durchgeführt und alle Server haben zueinander uneingeschränkten Zugriff.

    Sonntag, 26. Juni 2016 11:08
  • Das DAG selbst beinhaltet den korrekten Zeugenserver (Server4.unsereDomain.local) und hat die korrekten Mitglieder (Server1 und Server3).

    ...und der Cluster aktiviert die korrekte Kopie, nämlich die im Ausland, denn bei Verbindungsabbruch hat das Auslands-RZ das Quorum und das Deutschland-RZ nicht.

    Du brauchst einen alternativen Zeugenserver auf deutscher Seite (das kann man nur per PowerShell setzen), dann dürfte DAC auch richtig funktionieren und jede Kpie auf der jeweiligen Seite aktiv bleiben, bis die Verbindung wieder hergestellt ist.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Sonntag, 26. Juni 2016 12:54
  • kurze frage eines exchange noobs. Hätte ich dann nicht ein splittbrain? Welche kopie ist dann die vorrangige? Beim reinen cluster z.b. Hype-v hätte ich dann auf allen seiten alle maschienen online.

    danke :)


    Kind regards, Flo

    Sonntag, 26. Juni 2016 18:52
  • Am 26.06.2016 schrieb Florian Klaffenbach:

    kurze frage eines exchange noobs. Hätte ich dann nicht ein splittbrain? Welche kopie ist dann die vorrangige? Beim reinen cluster z.b. Hype-v hätte ich dann auf allen seiten alle maschienen online.

    Würde mich auch interessieren, wie DAC dafür sorgt, dass beide Seiten online bleiben.
    https://technet.microsoft.com/de-de/library/dd979790(v=exchg.150).aspx noch was zum Nachlesen.

    Bye
    Norbert


    Dilbert's words of wisdom #19:
    Am I getting smart with you? How would you know?
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Sonntag, 26. Juni 2016 20:59
  • Ja, ihr habt ja so recht, würde hier im Endeffekt auch nicht helfen. So etwas wäre aber extrem wünschenswert und - auf Datenbankebene - vermutlich sogar machbar ("lass die Preferred Copy aktiv, wenn sie vor dem Konnektivitätsverlust aktiv war, und aktiviere  keine Nicht-Preferred Copy, bis der Node mit der Preferred Copy wieder erreichbar ist"). Vielleicht sehen wir das ja irgendwann.

    Nichtsdestotrotz sollte der alternative Witness auch in diesem Fall gesetzt werden, denn sonst funktioniert DC Switchover nicht. Und vielleicht möchte man diesen auch mal durchführen.

    Somit wäre die Lösung "nach dem Handbuch" in diesem Fall: vier Exchange Server in zwei DAGs, und in jeder DAG wohnt nur eine Datenbank. Und der Witness ist natürlich da, wo auch die Preferred Copy ist.

    Die pragmatische Lösung wäre die Elastizität des Clusters so stark zu erhöhen, dass er die Zwangstrennung im Regelfall ohne Failover überlebt, und den Zeugen auf die Seite zu setzen, wo mehr (und/oder wichtigere) User sind.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Sonntag, 26. Juni 2016 21:53
  • Die Delay Werte des Clusters zu ändern ist glaube ich auch immer noch die Empfehlung wenn man die Exchange virtuell betreibt und z.B mit Veeam sichert. Wenn man das Witness Share jetzt nicht nach DE ziehen kann, wäre das auch meine einzige Idee.
    Montag, 27. Juni 2016 06:50
  • Am 26.06.2016 schrieb Evgenij Smirnov:
    Hi,

    Nichtsdestotrotz sollte der alternative Witness auch in diesem Fall gesetzt werden, denn sonst funktioniert DC Switchover nicht. Und vielleicht möchte man diesen auch mal durchführen.

    sollte? Er muß... ;) Ich finde das Design eine DAG über solche Strecke mit nur zwei Nodes aufzubauen sowieso irgendwie "ungünstig", kenne aber die Hintergründe dafür auch nicht. Im Fehlerfall würde ich aber relativ große Latenzen erwarten, auch bei geplanten Downtimes.

    Somit wäre die Lösung "nach dem Handbuch" in diesem Fall: vier Exchange Server in _zwei_DAGs, und in jeder DAG wohnt nur eine Datenbank. Und der Witness ist natürlich da, wo auch die Preferred Copy ist.

    Korrekt.

    Die pragmatische Lösung wäre die Elastizität des Clusters so stark zu erhöhen, dass er die Zwangstrennung im Regelfall ohne Failover überlebt, und den Zeugen auf die Seite zu setzen, wo mehr (und/oder wichtigere) User sind.

    Oder Office 365 :p ;)

    Bye
    Norbert

    Montag, 27. Juni 2016 07:57
  • Bei O365 hast du nur wieder das Problem mit der one Tenant : one Datacenter Philosophie von Microsoft. 

    Wenn die User zu weit vom O365 Tenant Datacenter weg sind z.B: DC in Amsterdam und User in Saitama, dann brauchst du wieder MPLS und ExpressRoute. Sonst ist die Latenz und User Experience bescheiden. :/  


    Kind regards, Flo

    Montag, 27. Juni 2016 08:24
  • Am 27.06.2016 schrieb Florian Klaffenbach:

    Bei O365 hast du nur wieder das Problem mit der one Tenant : one Datacenter Philosophie von Microsoft.

    Wenn die User zu weit vom O365 Tenant Datacenter weg sind z.B: DC in Amsterdam und User in Saitama, dann brauchst du wieder MPLS und ExpressRoute. Sonst ist die Latenz und User Experience bescheiden. :/

    Unterscheidet sich also wahrscheinlich nicht sonderlich vom bisherigen Zustand. ;)
     -- Dilbert's words of wisdom #19:
    Am I getting smart with you? How would you know?
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Montag, 27. Juni 2016 09:44
  • Ich finde das Design eine DAG über solche Strecke mit nur zwei Nodes aufzubauen sowieso irgendwie "ungünstig",

    Schon, aber was willst Du sonst machen? Eine DAG mit mehr Nodes wird sich bei Ausfall der WAN-Strecke genau so verhalten wie eine 2-Node-DAG: Die Seite ohne Quorum geht offline, und welche Seite das sein wird, steht auch von vornherein fest...


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 27. Juni 2016 10:10
  • Am 27.06.2016 schrieb Evgenij Smirnov:

    Ich finde das Design eine DAG über solche Strecke mit nur zwei Nodes aufzubauen sowieso irgendwie "ungünstig",

    Schon, aber was willst Du sonst machen? Eine DAG mit mehr Nodes wird sich bei Ausfall der WAN-Strecke genau so verhalten wie eine 2-Node-DAG: Die Seite ohne Quorum geht offline, und welche Seite das sein wird, steht auch von vornherein fest...

    Hab ja nicht von mehr Nodes gesprochen, wobei eben bei nur 2-Node DAG sofort negatives Verhalten beim CAS zu erwarten ist. Bei 3 Nodes wirds schon anders aussehen. Ist halt Sache der Konzeption, sowas vorab in Betracht zu ziehen. ;)

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Montag, 27. Juni 2016 11:35