Grundlegendes zu Active Manager

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2015-03-09

Microsoft Exchange Server 2010 bietet mit Active Manager eine neue Komponente. Die Funktionalität von Active Manager ersetzt das Ressourcenmodell und die Funktionen zur Failoververwaltung, die durch die Integration mit dem Clusterdienst in früheren Versionen von Exchange bereitgestellt wurden. In Exchange wird zum Erzielen einer hohen Verfügbarkeit nicht mehr das Clusterressourcenmodell verwendet. Alle von exres.dll bereitgestellten Exchange-Clusterressourcen wurden entfernt, einschließlich des so genannten Postfachclusterservers. Ein Windows-Failovercluster wird von Exchange verwendet, es gibt jedoch keine Clustergruppen für Exchange und keine Speicherressourcen im Cluster. Wenn Sie daher den Cluster mithilfe von Clusterverwaltungstools untersuchen, werden nur die Kernclusterressourcen (IP-Adresse und Netzwerkname sowie, bei Bedarf, die Quorumressource) angezeigt. Auch Clusterknoten und Netzwerke sind vorhanden, diese werden jedoch von Exchange und nicht von Clustern oder Clustertools verwaltet.

Active Manager wird auf allen Postfachservern als Rolle ausgeführt. Auf Postfachservern, die nicht für eine hohe Verfügbarkeit konfiguriert sind, gibt es mit Eigenständiger Active Manager nur eine Active Manager-Rolle. Auf Servern, die zu einer Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) gehören, gibt es zwei Active Manager-Rollen: Primary Active Manager (PAM) und Standby Active Manager (SAM). PAM ist der Active Manager in einer Datenbankverfügbarkeitsgruppe, der 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 Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe verschieben. Der PAM steuert alle Bewegungen der Aktiv-Bezeichnung 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 stellt anderen Komponenten von Exchange, auf denen eine Active Manager-Clientkomponente ausgeführt wird (z. B. RPC-Clientzugriffsdienst oder Hub-Transport-Server), Informationen darüber bereit, auf welchem Server die aktive Kopie einer Postfachdatenbank gehostet wird. 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

Bei Exchange 2010 handelt es sich nicht um eine Clusteranwendung. Stattdessen werden die in clusapi.dll implementierten Clusterbibliotheksfunktionen für Cluster-, Gruppen-, Clusternetzwerk- (Taktintervalle), Knotenverwaltungs-, Clusterregistrierungs- und einige Steuerungscodefunktionen eingesetzt. Außerdem speichert Active Manager aktuelle Informationen zur Postfachdatenbank (beispielsweise Aktiv- und Passiv- sowie Eingebunden-Daten) in der Clusterdatenbank. Auch wenn die Informationen direkt in der Clusterdatenbank abgelegt werden, greifen andere Komponenten nicht direkt darauf zu.

In Exchange 2010 wird die Integrität aller eingebundenen Datenbanken in regelmäßigen Abständen vom Microsoft Exchange-Replikationsdienst überwacht. Dieser überwacht außerdem 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 Ergebnisinformationen der Verfolgung werden der RPC-Clientzugriffskomponente auf dem Clientzugriffsserver bereitgestellt, mit dem der Client verbunden ist.

Active Manager-Auswahl der besten Kopie

Wenn ein Ausfall auftritt, der sich auf eine replizierte Postfachdatenbank auswirkt, führt Active Manager mehrere Schritten zur Wiederherstellung durch, indem die bestmögliche zu aktivierende Kopie der ausgefallenen Datenbank ausgewählt wird. Der allgemeine Prozess erfolgt in der folgenden Reihenfolge:

1. Active Manager erkennt den Ausfall.

2. Der primäre Active Manager führt einen internen Algorithmus aus, der "Auswahl der bestmöglichen Kopie genannt wird".

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 Failover gehostet hat.

4. Nach Abschluss des ACLL-Vorgangs sendet der primäre Active Manager ü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:

   1. Die Datenbank wird bereitgestellt und den Clients zur Verfügung gestellt, oder

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

Bei der Suche nach der bestmöglichen Kopie verwendet der PAM bis zu zehn einzelne Kriteriensätze, um die beste zu aktivierende Kopie zu bestimmen. Nach Auffinden der bestmöglichen Kopie wird der ACLL-Vorgang ausgeführt. Nach Abschluss dieses Vorgangs wird die Datenbank, sofern alle fehlenden Protokolldateien aus der vorherigen aktiven Kopie kopiert wurden, ohne Datenverlust bereitgestellt. Dies wird als verlustfreies Failover bezeichnet. Wenn der ACLL-Vorgang nicht erfolgreich ist, wird der konfigurierte Wert für AutoDatabaseMountDial abgerufen. Weitere Informationen zu AutoDatabaseMountDial finden Sie unter Set-MailboxServer. Liegt die Anzahl verloren gegangener Protokolle innerhalb des für AutoDatabaseMountDial konfigurierten Werts, wird die Datenbank eingebunden. Liegt die Anzahl verloren gegangener Protokolle außerhalb des für AutoDatabaseMountDial konfigurierten Werts, wird die Datenbank erst eingebunden, wenn fehlende Protokolldateien wiederhergestellt wurden oder wenn ein Administrator die Datenbank explizit einbindet und den größeren Datenverlust akzeptiert. Wenn die Datenbank nicht automatisch eingebunden wird, wählt der primäre Active Manager die nächste bestmögliche Kopie (sofern vorhanden) aus. Es gibt mindestens drei Gründe, warum die anfänglich ausgewählte Datenbankkopie nicht automatisch eingebunden wird:

1. Die Anzahl der verloren gegangenen Protokolldateien ist größer als der für AutoDatabaseMountDial konfigurierte Wert.

2. Der Server, auf dem der Einbindungsversuch erfolgt ist, wurde mit einem „weichen“ Maximum für die aktiven Anzahl von Datenbanken konfiguriert, und die maximale Anzahl aktiver Datenbankkopien auf dem Server wurde erreicht.

3. Die Datenbankkopie wurde zur Aktivierung angehalten.

Auswahl der bestmöglichen Kopie

Active Manager beginnt den Prozess zur Auswahl der bestmöglichen Kopie mit dem Erstellen einer Liste mit Datenbankkopien, die potenzielle Kandidaten für die Aktivierung sind. Datenbankkopien, die nicht erreichbar sind oder deren Aktivierung vom Administrator gesperrt wurde (über die Eigenschaft DatabaseCopyAutoActivationPolicy des Cmdlets Set-MailboxServer), werden ignoriert und nicht während des Auswahlprozesses verwendet. Die Reihenfolge in der Liste hängt von der Exchange 2010-Version ab:

• In der RTM-Version (Release to Manufacturing) von Exchange 2010 sortiert Active Manager die resultierende Liste anhand der Länge der Kopiewarteschlange als Primärschlüssel. Die Berechnung basiert auf dem Wert von LastLogInspected (aus Sicht der Kopie), sodass die Liste potenzieller Kopien anhand des höchsten Werts für LastLogInspected sortiert wird (bei der es sich um die Kopie mit der kürzesten Länge der Kopiewarteschlange handelt). Active Manager sortiert die Liste ein zweites Mal, und zwar anhand des Werts von ActivationPreference als Sekundärschlüssel. Die Kopie mit dem niedrigsten Wert für ActivationPreference hat in der Liste die höchste Priorität.

• Das Verhalten in Exchange 2010 Service Pack 1 (SP1) entspricht dem der RTM-Version außer für Server, deren Wert für AutoDatabaseMountDial auf Lossless festgelegt ist. Bei Verwenden der Einstellung Lossless sortiert Active Manager die resultierende Liste in aufsteigender Reihenfolge anhand des Werts für ActivationPreference als Primärschlüssel. Dieses Verhalten ist beabsichtigt, sodass Unausgewogenheiten bei Datenbanken mithilfe von Verschiebungsvorgängen minimiert werden (z. B. durch Switchover oder bei Ausführung von StartDagServerMaintenance.ps1).

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.

Sobald eine oder mehrere Kopien gefunden wurden, die einen oder mehrere Kriteriensätze erfüllen, wird der ACLL-Vorgang ausgeführt, bei dem Protokolldateien aus der Originalquelle in die potenzielle neue aktive Kopie kopiert werden. Nach Abschluss des ACLL-Vorgangs sendet der primäre Active Manager eine Einbindungsanforderung ab. Die Datenbank wird entweder eingebunden und Clients zur Verfügung gestellt, oder die Datenbank wird nicht eingebunden, woraufhin der primäre Active Manager die nächste bestmögliche Kopie sucht (sofern vorhanden).

Beispiele für die Auswahl der bestmöglichen Kopie

Im folgenden Abschnitt werden anhand einiger Beispiele die Auswahl der bestmöglichen Kopie und der Aktivierungsvorgang veranschaulicht.

Beispiel 1: Standardszenario

In diesem Beispiel sind vier Kopien der Postfachdatenbank DB1 vorhanden. DB1 ist gegenwärtig auf Server1 aktiv, auf dem es zu einem Hardwareausfall kommt. Die folgende Tabelle zeigt den aktuellen Status der Datenbankkopien von DB1 auf Server2, Server3 und Server4 an.

Datenbankkopie	Aktivierungseinstellung	Länge der Kopiewarteschlange	Länge der Wiedergabewarteschlange	Inhaltsindexstatus	Datenbankstatus	Aktivierung blockiert
Server2\DB1	2	4	0	Healthy	Healthy	Nein
Server3\DB1	3	2	2	Healthy	DisconnectedAndHealthy	Nein
Server4\DB1	4	10	0	Crawling	Healthy	Nein

Die Sortierung der verfügbaren Kopien basierend auf der Länge ihrer Warteschlangen (mithilfe von Aktivierungseinstellung, falls erforderlich) führt zur folgenden geordneten Liste:

• Server3\DB1

• Server2\DB1

• Server4\DB1

In dieser Liste erfüllen nur zwei Datenbankkopien den ersten Kriteriensatz für die Aktivierung:

• Die Kopie auf Server3 mit dem Datenbankstatus DisconnectedandHealthy, einer Länge der Kopiewarteschlange kleiner als 10, einer Länge der Wiedergabewarteschlange kleiner als 50 und einem fehlerfreien Inhaltsindex.

• Die Kopie auf Server2 mit dem Datenbankstatus Healthy, einer Länge der Kopiewarteschlange kleiner als 10, einer Länge der Wiedergabewarteschlange kleiner als 50 und einem fehlerfreien Inhaltsindex.

Von diesen beiden hat die Kopie auf Server3 die kürzeste Warteschlangenlänge, weshalb die Kopie auf Server3 als zu aktivierende Kopie ausgewählt wird, da sie die geringste Menge an fehlenden Daten aufweist.

Nach Aktivierung der Kopie auf Server3 führt der Microsoft Exchange-Replikationsdienst auf Server3 den ACLL-Vorgang durch und versucht, fehlende Protokolldateien vom vorherigen aktiven Server (in diesem Fall Server1) zu kopieren. Nach Abschluss des ACLL-Vorgangs wird der primäre Active Manager über die Ergebnisse des ACLL-Vorgangs informiert. Nachdem alle Protokolle erfolgreich kopiert wurden, wird die Datenbank als aktive Kopie markiert und ohne Datenverluste bereitgestellt. Wenn ein oder mehrere Protokolle fehlen, wird der Parameter AutoDatabaseMountDial überprüft. Wenn der Datenverlust innerhalb des konfigurierten Werts liegt, wird die Datenbank als aktive Kopie markiert und ohne Datenverluste eingebunden. Die Mehrzahl fehlender Daten wird aus dem Transportdumpster wiederhergestellt.

Wenn Active Manager eine Einbindungsanforderung an den Informationsspeicher sendet und der Einbindungsvorgang keinen Erfolg hat, kehrt Active Manager zur obigen sortierten Liste zurück und versucht, die nächste bestmögliche Kopie (in diesem Fall die auf Server2) zu aktivieren.

Beispiel 2: Zwei Kopien mit derselben Warteschlangenlänge

In diesem Beispiel sind vier Kopien der Postfachdatenbank DB2 vorhanden. DB2 ist gegenwärtig auf Server1 aktiv, auf dem es zu einem Hardwareausfall kommt. Die folgende Tabelle zeigt den aktuellen Status der Datenbankkopien von DB2 auf Server2, Server3 und Server4 an.

Datenbankkopie	Aktivierungseinstellung	Länge der Kopiewarteschlange	Länge der Wiedergabewarteschlange	Inhaltsindexstatus	Datenbankstatus	Aktivierung blockiert
Server2\DB2	2	2	0	Healthy	Healthy	Nein
Server3\DB2	3	2	2	Healthy	DisconnectedAndHealthy	Nein
Server4\DB2	4	10	0	Crawling	Healthy	Nein

Die Sortierung der verfügbaren Kopien basierend auf der Länge ihrer Warteschlangen (mithilfe von Aktivierungseinstellung, falls erforderlich) führt zur folgenden geordneten Liste:

• Server2\DB2

• Server3\DB2

• Server4\DB2

In dieser Liste erfüllen nur zwei Datenbankkopien den ersten Kriteriensatz für die Aktivierung:

• Die Kopie auf Server2 mit dem Datenbankstatus Healthy, einer Länge der Kopiewarteschlange kleiner als 10, einer Länge der Wiedergabewarteschlange kleiner als 50 und einem fehlerfreien Inhaltsindex.

• Die Kopie auf Server3 mit dem Datenbankstatus DisconnectedandHealthy, einer Länge der Kopiewarteschlange kleiner als 10, einer Länge der Wiedergabewarteschlange kleiner als 50 und einem fehlerfreien Inhaltsindex.

Von diesen beiden hat die Kopie auf Server2 dieselbe Warteschlangenlänge wie die Kopie auf Server3, aber einen niedrigeren Wert für Aktivierungseinstellung. Deshalb befindet sich die Kopie auf Server2 oben in der Liste wird als zu aktivierende Kopie ausgewählt, da sie die geringste Menge an fehlenden Daten aufweist und den niedrigeren Wert für Aktivierungseinstellung hat.

Beispiel 3: Kopien mit identischem Datenbankstatus und unterschiedlichem Inhaltsindexstatus

In diesem Beispiel sind vier Kopien der Postfachdatenbank DB3 vorhanden. DB3 ist gegenwärtig auf Server1 aktiv, auf dem es zu einem Hardwareausfall kommt. Die folgende Tabelle zeigt den aktuellen Status der Datenbankkopien von DB3 auf Server2, Server3 und Server4 an.

Datenbankkopie	Aktivierungseinstellung	Länge der Kopiewarteschlange	Länge der Wiedergabewarteschlange	Inhaltsindexstatus	Datenbankstatus	Aktivierung blockiert
Server2\DB3	2	0	3	Crawling	Healthy	Nein
Server3\DB3	3	0	3	Healthy	DisconnectedAndHealthy	Nein
Server4\DB3	4	0	0	Healthy	Healthy	Nein

Die Sortierung der verfügbaren Kopien basierend auf der Länge ihrer Warteschlangen (mithilfe von Aktivierungseinstellung, falls erforderlich) führt zur folgenden geordneten Liste:

• Server2\DB3

• Server3\DB3

• Server4\DB3

Alle drei auf den obigen Servern gehosteten Datenbankkopien erfüllen die Kriterien für die Aktivierung. Obgleich Server2 einen niedrigeren Wert für Aktivierungseinstellung hat, ist sein Inhaltsindexstatus Crawling. Demzufolge wird, wenn Active Manager die Liste mit dem ersten Kriteriensatz abgleicht (der den Inhaltsindexstatus Healthy umfasst), der Datenbankkopie auf Server3 der Vorzug gegeben, da ihr Inhaltsindexstatus Healthy ist.

Beispiel 4: Auswirkung von "AutoDatabaseMountDial" auf die Auswahl der bestmöglichen Kopie

In diesem Beispiel sind vier Kopien der Postfachdatenbank DB4 vorhanden. DB4 ist gegenwärtig auf Server1 aktiv, auf dem es zu einem Fehler kommt, der einen Neustart erforderlich macht. Die folgende Tabelle zeigt den aktuellen Status der Datenbankkopien von DB4 auf Server2, Server3 und Server4 an. Der Parameter AutoDatabaseMountDial für alle Postfachserver in der Datenbankverfügbarkeitsgruppe ist auf Lossless (Länge der Kopiewarteschlange ist 0) festgelegt.

Datenbankkopie	Aktivierungseinstellung	Länge der Kopiewarteschlange	Länge der Wiedergabewarteschlange	Inhaltsindexstatus	Datenbankstatus	Aktivierung blockiert
Server2\DB4	2	0	4523	Healthy	Healthy	Nein
Server3\DB4	3	100	25	Crawling	Healthy	Nein
Server4\DB4	4	6	62	Healthy	Healthy	Nein

Da der Parameter AutoDatabaseMountDial auf Lossless festgelegt ist, verwendet Active Manager die Aktivierungseinstellung anstelle der Länge der Kopiewarteschlange als primären Sortierschlüssel. Die Sortierung der verfügbaren Kopien basierend auf Aktivierungseinstellung führt zur folgenden geordneten Liste:

• Server2\DB4

• Server3\DB4

• Server4\DB4

Keine der Datenbanken erfüllt den ersten, zweiten oder dritten Kriteriensatz, doch die Datenbank auf Server3 erfüllt den vierten Kriteriensatz (mit dem Inhaltsindexstatus Crawling und einer Länge der Wiedergabewarteschlange kleiner als 50). Die Datenbankkopie auf Server3 hat die Warteschlangenlänge 100, doch da Server1 den Neustart noch nicht abgeschlossen hat, können während des ACLL-Vorgangs diese fehlenden Protokolldateien nicht auf Server3 kopiert werden. Der ACLL-Vorgang informiert den primären Active Manager, dass die Menge der fehlenden Daten nicht innerhalb des für den Parameter AutoDatabaseMountDial konfigurierten Werts liegt, was bewirkt, dass die nächste bestmögliche verfügbare Kopie ausgewählt wird.

Im vorherigen Szenario erfüllen die Datenbankkopien auf Server2 und Server4 den sechsten Kriteriensatz (mit fehlerfreiem Datenbank- und Inhaltsindex und einer Länge der Kopiewarteschlange kleiner als 10). Da sie sich in der sortierten Liste verfügbarer Kopien weiter oben befindet, wird die Datenbankkopie auf Server2 als Nächstes versucht. Der ACLL-Vorgang wird auf Server2 ausgeführt, doch Server1 hat noch immer keine Verbindung mit dem Netzwerk, sodass beim ACLL-Vorgang keine Protokolle kopiert werden können. Da die Länge der Kopiewarteschlange innerhalb des Werts des Parameters AutoDatabaseMountDial liegt, sendet der ACLL-Vorgang eine Erfolgsmeldung an den primären Active Manager, der daraufhin eine Datenbankeinbindungsanforderung per RPC sendet.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.