Eigentlich erscheint der Titel des Artikels etwas verwirrend, aber wenn Sie eine DR-Struktur in Ihrer Umgebung haben TAG Möglicherweise möchten Sie verhindern, dass die Kopie der darin enthaltenen Datenbanken automatisch aktiviert wird. Wenn sich die Datenbankkopie in einem ruhenden Rechenzentrum befindet, könnte dies ein Grund dafür sein, dass Sie die automatische Aktivierung verhindern möchten. Sie können dieses Szenario nicht implementieren, weil es die Aufgabe nicht erfüllen kann, sondern weil Sie wahrscheinlich wissen möchten, wann die Datenbank an ein anderes Rechenzentrum übergeben wird, und Sie möchten, dass dies selbst erledigt wird.
Was ist Exchange Server AutoActivationPolicy?
auf Exchange Server AutoActivationPolicy Bei der Funktion handelt es sich um eine Optimierungsoption, die die automatische Aktivierung von Datenbankkopien innerhalb einer bestimmten Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) steuert. Diese Funktion spielt eine wichtige Rolle bei der Verwaltung der DAG, insbesondere in Hochverfügbarkeits- und Fehlertoleranzszenarien.
AutoActivationPolicy Bestimmt, ob DAG-Mitgliedsserver die von ihnen gehosteten passiven Datenbankkopien automatisch aktivieren können. Mit dieser Richtlinie wird gesteuert, welche Server Datenbanken automatisch online schalten, insbesondere bei Wartungsarbeiten oder Hardwareausfällen.
AutoActivationPolicy-Optionen für Exchange Server
- Gesperrt: Diese Einstellung verhindert, dass der Server passive Datenbankkopien automatisch aktiviert. Dies wird häufig bei Wartungsarbeiten oder zur Verwaltung der Serverlast verwendet.
- Nur Intrasite: Mit dieser Einstellung kann der Server passive Kopien nur innerhalb derselben Site aktivieren. Dies wird bevorzugt, wenn bei externen Rechenzentrumsverbindungen Latenz oder hohe Kosten auftreten.
- Uneingeschränkt: Mit dieser Einstellung kann der Server passive Datenbankkopien ohne Einschränkungen aktivieren. Dies ist die flexibelste Option und ermöglicht es dem Server, Hochverfügbarkeitsanforderungen zu erfüllen.
Konfigurieren der AutoActivationPolicy für Exchange Server
Tatsächlich macht Exchange Server die DAG-Struktur mit jeder Version leistungsfähiger, und ich denke, dass DAG ein perfektes Szenario für diese Umgebungen ist.
Sie können sich Ihre Exchange-Umgebung wie die folgende Topologie vorstellen.
Wir haben eine Umgebung, die vier DAG-Mitglieder hostet, zwei auf der primären Site und zwei auf der DR-Site. Ich werde mein Beispiel als einzelne Datenbank DB001 erläutern (um die Erklärung noch etwas zu vereinfachen). Standardmäßig kann die Datenbank DB001 automatisch eine aktive Datenbankmigration zu jedem der verfügbaren DAG-Mitglieder, einschließlich der DR-Site, durchführen. Die Topologie der automatischen aktiven Datenbankmigration ist unten dargestellt.
In unserer Topologie wurden die Server am primären Standort im gesamten Szenario als „Uneingeschränkt“ klassifiziert.
In Ihrer Struktur finden Sie die Informationen auf der DR-Seite (Disaster Recovery). TAG Wenn Sie nicht möchten, dass Mitglieder automatisch oder einfach ein Failover durchführen TAG Wenn Sie möchten, dass „1“ seiner Mitglieder dies übernimmt, können Sie die Failover-Konfiguration mit dem folgenden Befehl ändern.
Dadurch wird die aktive Datenbank automatisch blockiert.
Wenn wir eine kurze Definition der blockierten Komponente geben müssen;
Deaktiviert die automatische Aktivierung auf Postfachservern.
In Exchange 2013 stoppte diese Einstellung Server-Locator-Anfragen an den angegebenen Server und blockierte den gesamten Clientzugriff auf manuell aktivierte Datenbanken auf dem Server, wenn alle DAG-Mitglieder mit dem Wert „Blockiert“ konfiguriert waren. In Exchange Server 2013 CU7 oder späteren Versionen von Exchange Server werden Server-Locator-Anfragen an einen blockierten Server gesendet, wenn kein anderer Postfachserver verfügbar ist, sodass der Clientzugriff nicht beeinträchtigt wird.
Set-MailboxServer –Identity DR-EXC01 -DatabaseCopyAutoActivationPolicy Blocked
Set-MailboxServer –Identity DR-EXC02 -DatabaseCopyAutoActivationPolicy Blocked
Dies ist eigentlich ein typisches Szenario. Der DR-Server ist jedoch so positioniert, dass er nur im Katastrophenfall verwendet werden kann. Dieser Server sollte verwendet werden, wenn der primäre Standort ausgefallen ist und Sie nur möchten, dass die Datenbanken des sekundären Servers extern repliziert werden. In einigen Fällen kann es erforderlich sein, dass Datenbanken nicht manuell bereitgestellt werden, falls der primäre Standort nicht erreichbar ist oder ein Failover erkannt wird. Dies kann an einer instabilen Verbindung oder einem anderen Grund liegen.
Daher müssen Sie die Richtlinie zur automatischen Aktivierung von Datenbankkopien deaktivieren, die verhindert, dass Datenbanken im Falle eines Failovers verbunden werden.
Tatsächlich gibt es ein allgemeines Problem mit der oben vorgenommenen Konfiguration. Dieses Problem tritt beim Failover auf. Der primäre Standort PR-EXC01 muss ein Failover durchführen, PR-EXC02 ist jedoch aufgrund eines Problems oder einer geplanten Wartung offline. Da er jedoch nicht zu den DAGs am DR-Standort wechseln kann, ist die Datenbank offline. Selbst wenn Sie manuell zu DR-EXC01 wechseln, wird sich das zweite hier aufgetretene Problem nicht in DR-EXC02 widerspiegeln, sodass DB weiterhin offline ist.
Hinweis: Sofern das DR-Szenario für Exchange Server nicht professionell konzipiert ist, können solche Probleme immer auftreten.
Um solchen Problemen vorzubeugen, „Nur IntrasiteSie können das ”-Prinzip verwenden. Wir können dieses Prinzip wie folgt kurz definieren:
Datenbankkopie trotzdem Active Directory Ermöglicht die Aktivierung auf den Servern der Site. Diese Konfiguration verhindert ein standortübergreifendes Failover oder eine standortübergreifende Aktivierung (z. B. die Umwandlung einer passiven Kopie in eine Hot-Kopie).
Datenbanken, eine andere Active Directory kann auf diesem Postfachserver nicht für Datenbankkopien aktiviert werden, die auf der Site aktiv sind.
Set-MailboxServer –Identity DR-EXC01 -DatabaseCopyAutoActivationPolicy IntrasiteOnly
Set-MailboxServer –Identity DR-EXC02 -DatabaseCopyAutoActivationPolicy IntrasiteOnly
Mit dieser Konfiguration können wir einen Teil des Problems lösen, das ich zuerst erläutert habe, da wir nur Site-to-Site-Failover zugelassen haben, aber im Katastrophenfall müssen wir die Site-Migration manuell durchführen.
Die Sicherstellung der Geschäftskontinuität ist ebenso wichtig wie die Notfallwiederherstellung. Sie können eine Datenbank verwenden, die ein Failover auf den DR-Standort durchführt, um die Verfügbarkeit des verwendeten Dienstes aufrechtzuerhalten. Wir können die Datenbank auswählen, für die ein Failover vom primären Standort durchgeführt werden soll, und diese Datenbank automatisch zum Failover auf den DR-Standort umstellen.
Wenn Sie möchten, dass die Datenbank nach Bedarf auf den DR-Standort umschaltet, um die Dienstverfügbarkeit aufrechtzuerhalten, die Datenbanken aber lieber am primären Standort aktiv sein sollen, legen Sie die Aktivierungsrichtlinien fest Uneingeschränkt Sie können es stattdessen als und belassen DatabaseCopyActivationDisabledAndMoveNow Besonderheit $wahr Sie können es als festlegen. Dadurch ist ein Failover von Datenbanken möglich. Wenn der primäre Standort wieder verfügbar ist, wird die gesamte Last innerhalb weniger Minuten auf den primären Standort umgeleitet.
DatabaseCopyActivationDisabledAndMoveNow Wenn wir seine Funktion kurz beschreiben müssen;
Der Parameter DatabaseCopyActivationDisabledAndMoveNow gibt an, ob verhindert werden soll, dass Datenbanken eine Verbindung zu diesem Postfachserver herstellen, wenn andere fehlerfreie Kopien der Datenbanken auf anderen Postfachservern vorhanden sind. Wenn das Replikat außerdem vorhanden und fehlerfrei ist, kann es innerhalb weniger Minuten verknüpfte Datenbanken vom Server auf die Server migrieren.
Gültige Eingaben für diesen Parameter sind $true oder $false. Der Standardwert ist $false.
Wenn Sie diesen Parameter auf „$true“ setzen, werden Datenbanken nicht auf einen Server verschoben, bei dem der Parameter „DatabaseCopyAutoActivationPolicy“ auf „Blocked“ gesetzt ist.
Set-MailboxServer DR-EXC01 -DatabaseCopyActivationDisabledAndMoveNow $true -DatabaseCopyAutoActivationPolicy Unrestricted
Set-MailboxServer DR-EXC02 -DatabaseCopyActivationDisabledAndMoveNow $true -DatabaseCopyAutoActivationPolicy Unrestricted
Nachdem die Server am primären Standort als fehlerfrei markiert wurden, werden die Datenbanken auf der DR-Seite innerhalb weniger Minuten inaktiv und die Datenbanken am primären Standort werden aktiv.
