Share via


Exchange Server Active Manager

Microsoft Exchange Server enthält eine Komponente namens Active Manager, die die Hochverfügbarkeitsplattform verwaltet, die die Datenbankverfügbarkeitsgruppe (DAG) und Postfachdatenbankkopien enthält. Active Manager wird innerhalb des Microsoft Exchange-Replikationsdiensts (MSExchangeRepl.exe) auf allen Postfachservern ausgeführt. Auf Postfachservern, die nicht Mitglied einer DAG sind, gibt es eine einzelne Active Manager-Rolle: eigenständiger Active Manager.

Auf Servern, die zu einer DAG gehören, gibt es zwei Active Manager-Rollen: Primary Active Manager (PAM) und Standby Active Manager (SAM). PAM ist die Active Manager-Rolle in einer DAG, die entscheidet, welche Kopien aktiv oder passiv sind. Ein PAM ist zuständig für den Empfang von Benachrichtigungen zu Topologieänderungen und für das Reagieren auf Serverfehler. Das Mitglied der DAG mit der PAM-Rolle entspricht immer dem Mitglied, das derzeit die Clusterquorumressource (Standardclustergruppe) besitzt. Wenn der Server mit der Clusterquorumressource ausfällt, wird die PAM-Rolle automatisch auf einen funktionierenden Server verschoben, der den Besitz der Clusterquorumressource übernimmt. Wenn Sie den Server, auf dem die Clusterquorumressource gehostet wird, zu Wartungs- oder Upgradezwecken offline schalten müssen, müssen Sie zunächst die PAM-Rolle auf einen anderen Server in der DAG verschieben. Der PAM steuert alle Wechsel der Bezeichnung "Aktiv" zwischen den Kopien einer Datenbank. (Nur eine Kopie kann jeweils aktiv sein, und diese Kopie kann entweder eingebunden oder nicht eingebunden sein.) Der PAM führt außerdem die Funktionen der SAM-Rolle auf dem lokalen System durch (Erkennen von Fehlern der lokalen Datenbank und des lokalen Informationsspeichers).

Der SAM enthält Informationen dazu, welcher Server die aktive Kopie einer Postfachdatenbank für andere Komponenten von Exchange hostet, auf denen eine Active Manager-Clientkomponente ausgeführt wird (z. B. Clientzugriffs- oder Transportdienste). Der SAM erkennt Fehler der lokalen Datenbanken und des lokalen Informationsspeichers. Er reagiert auf Fehler, indem er den PAM zum Einleiten eines Failovers auffordert (falls die Datenbank repliziert wird). Ein SAM bestimmt nicht das Ziel des Failovers und aktualisiert auch nicht den Speicherort der Datenbank im PAM. Er greift auf den aktuellen Speicherortzustand der aktiven Datenbankkopie zu, um eingehende Abfragen nach der aktiven Datenbankkopie zu beantworten.

Hinweis

Exchange Server ist keine gruppierte Anwendung. Instead, it uses the cluster library functions implemented in clusapi.dll for cluster, group, cluster network (heartbeating), node management, cluster registry, and a few control code functions. In addition, Active Manager stores current mailbox database information (for example, active and passive data, and mounted data) in the cluster database (also known as the cluster registry). Although the information is stored directly in the cluster database, it isn't accessed directly by any other components.

In Exchange Server überwacht der Microsoft Exchange-Replikationsdienst regelmäßig die Integrität aller eingebundenen Datenbanken. Dieser überwacht außerdem die ESE (Extensible Storage Engine) auf E/A-Fehler oder Ausfälle. Wenn der Dienst einen Fehler erkennt, benachrichtigt er Active Manager. Anschließend bestimmt Active Manager, welche Datenbankkopie eingebunden werden soll und was dazu erforderlich ist. Zusätzlich wird die aktive Kopie einer Postfachdatenbank (basierend auf der zuletzt eingebundenen Kopie der Datenbank) verfolgt, und die Ergebnisse dieser Verfolgung werden den Clientzugriffsdiensten auf dem Postfachserver bereitgestellt, mit dem der Client verbunden ist.

Auswahl der besten Kopie

Wenn ein Fehler auftritt, der den Zugriff auf die aktive Kopie einer replizierten Postfachdatenbank verhindert, wählt Active Manager die bestmögliche passive Kopie der betroffenen zu aktivierenden Datenbank aus. Dieser Prozess wurde in früheren Versionen von Exchange als beste Kopierauswahl (BCS) bezeichnet und in Exchange 2016 und Exchange 2019 als beste Kopie und Serverauswahl (BCSS) bezeichnet. Der allgemeine Prozess erfolgt in der folgenden Reihenfolge:

  1. Die verwaltete Verfügbarkeit oder Active Manager erkennt einen Fehler, oder ein Administrator leitet ein Switchover ohne Zielangabe ein.

  2. Der PAM führt den internen Algorithmus zur Auswahl der besten Kopie und des besten Servers aus.

  3. Ein Prozess, der Versuch des Kopierens der letzten Protokolle (Attempt Copy Last Logs, ACLL) genannt wird, erfolgt, bei dem versucht wird, alle fehlenden Protokolle vom Server zu kopieren, der die aktive Datenbankkopie vor dem Fehler oder dem Switchover gehostet hat.

  4. Nachdem der ACLL-Prozess abgeschlossen ist, wird der Wert des Parameters AutoDatabaseMountDial für die Postfachserver, die Kopien der Datenbank hosten, mit der Länge der Kopiewarteschlange der zu aktivierenden Datenbank verglichen. An dieser Stelle findet einer der beiden folgenden Vorgänge statt:

    • Die Anzahl der fehlenden Protokolldateien ist kleiner gleich dem Wert von AutoDatabaseMountDial. In diesem Fall wird Schritt 5 ausgeführt.

    • Die Anzahl der fehlenden Protokolldateien ist größer als der Wert von AutoDatabaseMountDial. In diesem Fall versucht Active Manager, die nächste verfügbare beste Kopie zu aktivieren (falls vorhanden).

  5. Der PAM sendet über einen RPC (Remote Procedure Call, Remoteprozeduraufruf) eine Einbindungsanforderung an den Microsoft Exchange-Informationsspeicher. An dieser Stelle findet einer der beiden folgenden Vorgänge statt:

    • Die Datenbank wird bereitgestellt und den Clients zur Verfügung gestellt.

    • Die Datenbank wird nicht eingebunden, und der PAM führt die Schritte 3 und 4 für die nächste bestmögliche Kopie (falls vorhanden) durch.

In früheren Versionen von Exchange wertete der BCS-Prozess verschiedene Aspekte der einzelnen Datenbankkopien aus, um zu ermitteln, welche Kopie am besten aktiviert werden sollte. Hierzu gehörten:

  • Länge der Kopiewarteschlange

  • Länge der Wiedergabewarteschlange

  • Status der Datenbank

  • Inhaltsindexzustand

In Exchange Server durchläuft Active Manager alle gleichen BCS-Überprüfungen und -Phasen, umfasst jetzt aber auch die Verwendung einer Einschränkung der abnehmenden Reihenfolge der Integritätszustände. BcSS enthält insbesondere mehrere neue Integritätsprüfungen, die Teil der integrierten Komponenten für die Überwachung der verwalteten Verfügbarkeit in Exchange Server sind. Active Manager führt vier zusätzliche Prüfungen durch (hier in der Ausführungsreihenfolge aufgeführt):

  1. Alle fehlerfrei: Sucht nach einem Server, auf dem eine Kopie der betroffenen Datenbank gehostet wird, auf dem alle Überwachungskomponenten in einem fehlerfreien Zustand sind.

  2. Bis zu Normal fehlerfrei: Sucht nach einem Server, der eine Kopie der betroffenen Datenbank hosten soll, der alle Überwachungskomponenten mit normaler Priorität in einem fehlerfreien Zustand aufweist.

  3. Alles besser als Quelle: Sucht nach einem Server, auf dem eine Kopie der betroffenen Datenbank gehostet wird, der Überwachungskomponenten in einem Zustand aufweist, der besser ist als der aktuelle Server, auf dem die betroffene Kopie gehostet wird.

  4. Identisch mit Quelle: Sucht nach einem Server, auf dem eine Kopie der betroffenen Datenbank gehostet wird, die Überwachungskomponenten in einem Zustand aufweist, der dem aktuellen Server entspricht, auf dem die betroffene Kopie gehostet wird.

Wenn die Auswahl der besten Kopie und des besten Servers aufgrund eines Failovers aufgerufen wird, der von einer Überwachungskomponente (z. B. von einem Failoverantwortdienst) ausgelöst wurde, wird eine zusätzliche obligatorische Einschränkung erzwungen, bei der die Komponentenintegrität des Zielservers einen besseren Wert als die des Servers aufweisen muss, auf dem das Failover aufgetreten ist. Wenn z. B. ein Outlook im Web-Fehler ein Failover über einen Failoverantwortdienst auslöst, dann muss die Auswahl der besten Kopie und des besten Servers einen Server auswählen, der eine Kopie der betroffenen Datenbank hostet, auf dem Outlook im Web fehlerfrei ist.

Auswahl der bestmöglichen Kopie

Hinsichtlich der Datenbankfehler (keine Protokollfehler) beginnt Active Manager den Prozess zur Auswahl der bestmöglichen Kopie mit dem Erstellen einer Liste mit Datenbankkopien, die potenzielle Kandidaten für die Aktivierung sind. Alle Datenbankkopien, die nicht erreicht werden können oder für die Aktivierung gesperrt sind, werden ignoriert und während des Auswahlprozesses nicht verwendet. Die Reihenfolge in der Liste hängt vom Wert des Parameters AutoDatabaseMountDial ab:

  • Wenn AutoDatabaseMountDial mit einem anderen Wert als Lossless auf allen Servern konfiguriert ist, auf denen eine Kopie der Datenbank gehostet wird, sortiert Active Manager die resultierende Liste anhand der Länge der Kopierwarteschlange als Primärschlüssel. The calculation is based on LastLogInspected (from the copy's point of view), so the list of potential copies is sorted by the highest value for LastLogInspected (which will be the copy with the lowest copy queue length). If necessary, Active Manager sorts the list a second time, using the value for activation preference as a secondary key to break any tie conditions where two or more passive copies have the same copy queue length. The copy with the lowest activation preference value has the higher priority on the list.

  • Wenn autoDatabaseMountDial auf einem Beliebigen Server, der Lossless eine Kopie der Datenbank hostet, mit dem Wert konfiguriert ist, sortiert Active Manager die resultierende Liste in aufsteigender Reihenfolge, indem der Wert für die Aktivierungseinstellung als Primärschlüssel verwendet wird. Wenn ein Administrator ein verlustfreies Server- oder Datenbankswitchover ohne Angabe eines Ziels ausführt, sortiert Active Manager die Ergebnisliste zusätzlich über den Wert für die Aktivierungseinstellung als primärem Schlüssel in aufsteigender Reihenfolge.

Als Nächstes versucht Active Manager, eine Postfachdatenbankkopie in der Liste mit dem Status Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing oder SeedingSource zu finden, und bewertet anschließend das Aktivierungspotenzial aller Kopien in der Liste anhand einer Reihenfolgenliste mit zehn Kriterien. Active Manager bestimmt, ob ein Kandidat für die Aktivierung den ersten Kriteriensatz erfüllt:

  • Der zugehörige Inhaltsindex besitzt den Status Healthy.

  • Die Länge der Kopiewarteschlange beträgt weniger als zehn Protokolldateien.

  • Die Länge der Wiedergabewarteschlange beträgt weniger als 50 Protokolldateien.

Wenn keine der Datenbankkopien den ersten Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu finden, die den zweiten Kriteriensatz erfüllt:

  • Der zugehörige Inhaltsindex besitzt den Status Crawling.

  • Die Länge der Kopiewarteschlange beträgt weniger als zehn Protokolldateien.

  • Die Länge der Wiedergabewarteschlange beträgt weniger als 50 Protokolldateien.

Wenn keine der Datenbankkopien den zweiten Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu finden, die den dritten Kriteriensatz erfüllt:

  • Der zugehörige Inhaltsindex besitzt den Status Healthy.

  • Die Länge der Wiedergabewarteschlange beträgt weniger als 50 Protokolldateien.

Wenn keine der Datenbankkopien den dritten Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu finden, die den vierten Kriteriensatz erfüllt:

  • Der zugehörige Inhaltsindex besitzt den Status Crawling.

  • Die Länge der Wiedergabewarteschlange beträgt weniger als 50 Protokolldateien.

Wenn keine der Datenbankkopien den vierten Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu finden, die den fünften Kriteriensatz erfüllt:

  • Die Länge der Wiedergabewarteschlange beträgt weniger als 50 Protokolldateien.

Wenn keine der Datenbankkopien den fünften Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu finden, die den sechsten Kriteriensatz erfüllt:

  • Der zugehörige Inhaltsindex besitzt den Status Healthy.

  • Die Länge der Kopiewarteschlange beträgt weniger als zehn Protokolldateien.

Wenn keine der Datenbankkopien den sechsten Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu finden, die den siebten Kriteriensatz erfüllt:

  • Der zugehörige Inhaltsindex besitzt den Status Crawling.

  • Die Länge der Kopiewarteschlange beträgt weniger als zehn Protokolldateien.

Wenn keine der Datenbankkopien den siebten Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu finden, die den achten Kriteriensatz erfüllt:

  • Der zugehörige Inhaltsindex besitzt den Status Healthy.

Wenn keine der Datenbankkopien den achten Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu finden, die den neunten Kriteriensatz erfüllt:

  • Der zugehörige Inhaltsindex besitzt den Status Crawling.

Wenn keine der Datenbankkopien den zweiten Kriteriensatz erfüllt, versucht Active Manager eine Datenbank zu aktivieren, die den Status „Healthy“, „DisconnectedAndHealthy“, „DisconnectedAndResynchronizing“ oder „SeedingSource“ (den zehnten Kriteriensatz) hat. Wird keine Datenbankkopie gefunden, die den zehnten Kriteriensatz erfüllt, kann keine Datenbankkopie automatisch aktiviert werden.

Nachdem eine oder mehrere Kopien gefunden wurden, die einen oder mehrere Kriterien erfüllen, kopiert der ACLL-Prozess alle Protokolldateien aus der ursprünglichen Quelle in die potenzielle neue aktive Kopie. Nachdem der ACLL-Prozess abgeschlossen wurde, gibt das PAM eine Einbindungsanforderung aus, und entweder wird die Datenbank bereitgestellt und wird für Clients bereitgestellt, oder die Datenbank wird nicht eingebunden, und die PAM sucht nach der nächstbesten Kopie (sofern verfügbar).