Exchange 2010: Probleme bei der Einrichtung einer DAG

Die Einrichtung einer Database Availability Group in Exchange 2010 ist gut dokumentiert. Das entsprechende Hintergrundwissen und eine sorgfältige Planung vorausgesetzt, lässt sich die Implementation einer DAG relativ schnell über die Bühne bringen.

Was nicht so gut dokumentiert ist: Zur Vorbereitung gehört auch die Installation diverser Hotfixe, die Microsoft für den Betrieb eines Failover Clusters empfiehlt und die deshalb für Server einer DAG ebenfalls empfehlenswert sind. Informationen zu den Hotfixes gibt es hier und hier.

Dass eine gute Vorbereitung aber keine Garantie für eine völlig problemlose Umsetzung ist, zeigt die Einrichtung einer DAG mit zwei Servern vom letzten Wochenende:

Seeding neuer Datenbankkopien schlägt fehl

Beim Seeden neuer Datenbankkopien über die EMC kam es wiederholt zu folgendem Fehler:

Error:
A source-side operation failed. Error An error occurred while performing
the seed operation. Error: Failed to open a log truncation context to
source server 'ex01.layer9.local'. Hresult: 0xfffffae7. Error: The database
was either not found or was not replicated.. [Database: MBDB001, Server:
ex02.layer9.local]

Failed to open a log truncation context to source server 'ex01.layer9.local'.
Hresult: 0xfffffae7. Error: The database was either not found or was not
replicated. Click here for help...

Danach befand sich die neu angelegte Kopie im Zustand „Suspended“ oder „Failed and Suspended“. Geholfen hat ein anschließendes, manuelles Update der Kopie mittels PowerShell:

[PS] C:\>Update-MailboxDatabaseCopy -Identity MBDB001\EX02

Unter Umständen kann es eine Weile dauern, bis das manuelle Update funktioniert. Sollte das alleine nicht helfen, kann zusätzlich die aktive Datenbank heruntergefahren und alle Transaktionslogs gelöscht werden. Spätestens dann sollte das Seeding klappen.

ContentIndex State der Kopie steht auf „Crawling“, hohe CPU Last durch msftefd.exe

Bei einigen Kopien verblieb der ContentIndex State auf „Crawling“ und die CPUs des Servers, der die Kopien hostet, wurde durch den Prozess msftefd.exe vollständig ausgelastet.

In diesem Fall muss auf dem betreffenden Server der Dienst „Microsoft Exchange Search Indexer“ neu gestartet und anschließend der Content Index der betreffenden Datenbankopien manuell aktualisiert werden:

[PS] C:\Update-MailboxDatabaseCopy –Identity MBDB001\EX02 –CatalogOnly

Wenn sich der Dienst nicht mehr beenden lässt, kann der Prozess msftefd.de im Task Manager einfach beendet werden. Nach dem Aktualisieren des Content Index sollte der Status von „Crawling“ auf „Healthy“ wechseln und die hohe CPU-Last verschwinden.

Unerwarteter Failover des Owner Nodes im Cluster und IP Adressen Konflikt

Die DAG bzw. der Cluster besteht aus den zwei Exchange Servern EX01/EX02 und einem Fileserver mit dem Witness-Share. Am Abend nach der Einrichtung kam es zu einem zunächst nicht nachvollziehbaren Failover des OwnerNodes der Clustergruppe von Server EX02 zu EX01. Darüberhinaus wurde auf der Konsole von EX01 ein IP-Konflikt angezeigt:

ip-conflict

Auf EX01 wurden in diesem Zusammenhang nacheinander folgende Cluster Events protokolliert:

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:10:50
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster node 'EX02' was removed from the active failover cluster membership. 
The Cluster service on this node may have stopped. This could also be due to
the node having lost communication with other active nodes in the failover
cluster. Run the Validate a Configuration wizard to check your network
configuration. If the condition persists, check for hardware or software
errors related to the network adapters on this node. Also check for failures
in any other network components to which the node is connected such as hubs,
switches, or bridges.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:04
Event ID:      1049
Task Category: IP Address Resource
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster IP address resource 'Cluster IP Address' cannot be brought online
because a duplicate IP address '172.16.1.2 was detected on the network. Please
ensure all IP addresses are unique.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:04
Event ID:      1069
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster resource 'Cluster IP Address' in clustered service or application 'Cluster
Group' failed.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:12
Event ID:      1049
Task Category: IP Address Resource
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster IP address resource 'Cluster IP Address' cannot be brought online
because a duplicate IP address '172.16.1.2' was detected on the network. Please
ensure all IP addresses are unique.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:12
Event ID:      1069
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster resource 'Cluster IP Address' in clustered service or application 'Cluster
Group' failed.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:11:13
Event ID:      1205
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
The Cluster service failed to bring clustered service or application 'Cluster
Group' completely online or offline. One or more resources may be in a failed
state. This may impact the availability of the clustered service or application.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:19:28
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex01.layer9.local
Description:
Cluster node 'EX02' was removed from the active failover cluster membership. The
Cluster service on this node may have stopped. This could also be due to the node
having lost communication with other active nodes in the failover cluster. Run the
Validate a Configuration wizard to check your network configuration. If the condition
persists, check for hardware or software errors related to the network adapters on
this node. Also check for failures in any other network components to which the node
is connected such as hubs, switches, or bridges.

Und auf Server EX02 wurden diese Ereignisse protokolliert:

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:10:50
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
Cluster node 'ex01' was removed from the active failover cluster membership. The Cluster
service on this node may have stopped. This could also be due to the node having lost
communication with other active nodes in the failover cluster. Run the Validate a
Configuration wizard to check your network configuration. If the condition persists,
check for hardware or software errors related to the network adapters on this node. Also
check for failures in any other network components to which the node is connected such
as hubs, switches, or bridges.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:12:04
Event ID:      1564
Task Category: File Share Witness Resource
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
File share witness resource 'File Share Witness (\\witness.layer9.local\DAG001.layer9.local)'
failed to arbitrate for the file share '\\\\witness.layer9.local\DAG001.layer9.local'. Please
ensure that file share '\\witness.layer9.local\DAG001.layer9.local' exists and is accessible
by the cluster.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:12:04
Event ID:      1069
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
Cluster resource 'File Share Witness (\\witness.layer9.local\DAG001.layer9.local)' in clustered
service or application 'Cluster Group' failed.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:12:04
Event ID:      1177
Task Category: Quorum Manager
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
The Cluster service is shutting down because quorum was lost. This could be due to
the loss of network connectivity between some or all nodes in the cluster, or a
failover of the witness disk. Run the Validate a Configuration wizard to check your
network configuration. If the condition persists, check for hardware or software errors
related to the network adapter. Also check for failures in any other network components
to which the node is connected such as hubs, switches, or bridges.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:19:28
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
Cluster node 'ex01' was removed from the active failover cluster membership. The Cluster
service on this node may have stopped. This could also be due to the node having lost
communication with other active nodes in the failover cluster. Run the Validate a Configuration
wizard to check your network configuration. If the condition persists, check for hardware
or software errors related to the network adapters on this node. Also check for failures
in any other network components to which the node is connected such as hubs, switches, or
bridges.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:20:29
Event ID:      1564
Task Category: File Share Witness Resource
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
File share witness resource 'File Share Witness (\\witness.layer9.local\DAG001.layer9.local)'
failed to arbitrate for the file share '\\witness.layer9.local\DAG001.layer9.local'. Please
ensure that file share '\\witness.layer9.local\DAG001.layer9.local' exists and is accessible
by the cluster.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:20:29
Event ID:      1069
Task Category: Resource Control Manager
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
Cluster resource 'File Share Witness (\\witness.layer9.local\DAG001.layer9.local)' in
clustered service or application 'Cluster Group' failed.
Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          16.02.2013 21:20:59
Event ID:      1177
Task Category: Quorum Manager
Level:         Critical
Keywords:      
User:          SYSTEM
Computer:      ex02.layer9.local
Description:
The Cluster service is shutting down because quorum was lost. This could be due
to the loss of network connectivity between some or all nodes in the cluster, or
a failover of the witness disk. Run the Validate a Configuration wizard to check
your network configuration. If the condition persists, check for hardware or
software errors related to the network adapter. Also check for failures in any
other network components to which the node is connected such as hubs, switches,
or bridges.

Anschließend wurde der Cluster Service auf EX02 neu gestartet und der Cluster funktionierte wieder. Aber wie kam es zu dem unerwarteten Failover und dem Konflikt der DAG-IP-Adresse?

Beide Server sind virtuelle Maschinen und waren dauerhaft online. Und eine doppelt vergebene IP-Adresse konnte definitiv ausgeschlossen werden. Also noch mal einen Blick in die Logfiles werfen und überlegen, was zu dieser Uhrzeit alles so im Netzwerk passiert sein konnte.

Und da kam eigentlich nur eins in Frage: Das Backup der virtuellen Maschinen mit Veeam Backup & Replication.

Beim Blick in die Logfiles von Veeam stellte sich dann tatsächlich heraus, dass kurz vor dem ersten Clusterfehler um 21:10:50 das Backup von EX02 startete. Nämlich genau 24 Sekunden vorher um 21:10:26:

veeam-ex02

Dabei auffällig ist die mit 16 Sekunden relativ lange Zeit, die für den Snapshot der virtuellen Maschine anfiel.

Und genau hier liegt die Ursache für das ganze Problem: Offenbar kam es aufgrund einer durch das Backup und den Snapshot bedingten sehr hohen I/O-Last zu einem kurzen Timeout von EX02 und damit zu einem Failover des Cluster Owner Nodes von EX02 zu EX01.

Die IP-Adresse der DAG bzw. des Clusters gehört immer dem Owner Node, war also bis zum Failover an die NIC von EX02 gebunden. Im Rahmen des Failovers wanderte die IP-Adresse demnach ordnungsgemäß zu EX01.

Aber jetzt kommt es: Da EX02 aufgrund des Snapshots für kurze Zeit de facto „eingefroren“ und wenige Sekunden später wieder online war, existierte die IP-Adresse dort ebenfalls noch. Ergebnis: IP-Adress-Konflikt und die daraus resultierenden Probleme im Cluster.

In diesem Zusammenhang ist von Bedeutung, nach welcher Zeitspanne ein Failover im Cluster stattfindet. Standardmäßig sind es fünf Sekunden [1]:

    By default, regardless of subnet configuration, heartbeat frequency (also known as subnet delay) is once every second (1000 milliseconds). The range for heartbeat frequency is once every 250-2000 milliseconds on a common subnet, and 250-4000 milliseconds across subnets. By default, when a node misses a series of 5 heartbeats, another node will initiate failover, and the range for this value (also known as subnet threshold) is from 3 through 10.

Befinden sich alle Nodes des Clusters im selben Subnet, lässt sich der Timeout mit den Werten „SameSubnetDelay“ und „SameSubnetThreshold“ festlegen. Die im Cluster DAG0001 verwendeten Werte lassen sich in der Eingabeaufforderung wie folgt ermitteln:

cluster /cluster:DAG001 /prop

T  Cluster              Name                           Value
-- -------------------- ------------------------------ -----------------------
DR DAG001               FixQuorum                      0 (0x0)
DR DAG001               PreventQuorum                  0 (0x0)
DR DAG001               IgnorePersistentStateOnStartup 0 (0x0)
SR DAG001               SharedVolumesRoot              C:\ClusterStorage
D  DAG001               AddEvictDelay                  60 (0x3c)
D  DAG001               BackupInProgress               0 (0x0)
D  DAG001               ClusSvcHangTimeout             60 (0x3c)
D  DAG001               ClusSvcRegroupOpeningTimeout   5 (0x5)
D  DAG001               ClusSvcRegroupPruningTimeout   5 (0x5)
D  DAG001               ClusSvcRegroupStageTimeout     7 (0x7)
D  DAG001               ClusSvcRegroupTickInMilliseconds 300 (0x12c)
D  DAG001               ClusterGroupWaitDelay          30 (0x1e)
D  DAG001               ClusterLogLevel                3 (0x3)
D  DAG001               ClusterLogSize                 100 (0x64)
D  DAG001               CrossSubnetDelay               1000 (0xfa0)
D  DAG001               CrossSubnetThreshold           5 (0xa)
D  DAG001               DefaultNetworkRole             2 (0x2)
S  DAG001               Description
D  DAG001               EnableSharedVolumes            0 (0x0)
D  DAG001               HangRecoveryAction             3 (0x3)
D  DAG001               LogResourceControls            0 (0x0)
D  DAG001               PlumbAllCrossSubnetRoutes      0 (0x0)
D  DAG001               QuorumArbitrationTimeMax       90 (0x5a)
D  DAG001               RequestReplyTimeout            60 (0x3c)
D  DAG001               RootMemoryReserved             4294967295 (0xffffffff)
D  DAG001               SameSubnetDelay                1000 (0x7d0)
D  DAG001               SameSubnetThreshold            5 (0xa)
B  DAG001               Security Descriptor            01 00 04 80 ... (164 bytes)
D  DAG001               SecurityLevel                  1 (0x1)
M  DAG001               SharedVolumeCompatibleFilters
M  DAG001               SharedVolumeIncompatibleFilters
D  DAG001               ShutdownTimeoutInMinutes       20 (0x14)
D  DAG001               WitnessDatabaseWriteTimeout    300 (0x12c)
D  DAG001               WitnessRestartInterval         15 (0xf)

Um die Zeitspanne für ein Failover im selben Subnetz auf den Maximalwert von 20 Sekunden zu vergrößern, werden einfach folgende Befehle ausgeführt:

cluster /cluster:DAG001 /prop SameSubnetDelay=2000
cluster /cluster:DAG001 /prop SameSubnetThreshold=10

Anschließend wird ein Failover nicht bereits nach fünf, sondern erst nach 20 Sekunden durchgeführt. Hier sollte dann genügend Luft für entsprechende Timeouts vorhanden sein.

[1] Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster

Fehler „Log Truncation failed“ bei Datenbankkopien

Nach dem Einrichten der Datenbankkopien fiel auf, dass auf dem Server, der die Kopien hostet, für jede Datenbankkopie permanent folgender Fehler im Eventlog protokolliert wurde:

Log Name:      Application
Source:        MSExchangeRepl
Date:          18.02.2013 16:40:11
Event ID:      2137
Task Category: Service
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      ex02.layer9.local
Description:
RPC request to the Microsoft Exchange Information Store service for log truncation
failed for database MBDB005\EX02. Error: 4294965485.

Der Fehler verschwindet nach dem nächsten vollen Backup der aktiven Datenbankkopien und deren Transaktionsprotokollen.

Ansonsten noch ein genereller Tipp: Sollte in der GUI (EMC) irgendwas nicht sofort klappen, erst mal in der EMS mit dem zugrundeliegenden Cmdlet ausprobieren.

0 Responses to “Exchange 2010: Probleme bei der Einrichtung einer DAG”



  1. Schreibe einen Kommentar

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s





%d Bloggern gefällt das: