Hallo zusammen,
nach diversen Problemen mit unserem VMWare Storage Cluster, haben wir uns entschlossen zumindest übergangsweise ein DAG aufzusetzen.
Das läuft aktuell schon, allerdings hatten wir einen Switch zum 2. Server obwohl eigentlich alles online war und lief.
Auf dem Server1 kamen heute Früh diese Meldung:
1. Worker process manager timed out after 30 seconds while waiting for a retired process handles to close (process id : 5476 ).
2. Information Store - DB2019 (9420,D,19,15.02.1118.007) DB2019: Ungültiger Seitenlink (Fehler -327) in B-Tree (ObjectId: 1222, PgnoRoot: 1130155) von Datenbank C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1885743355\Mailbox Database 1885743355.edb (7251881 => 7251882, 3873).
3. The feature component "BigFunnelPostingListIngestion" (14512450-cdd9-4eaa-b0cc-d39f5c4b5622) caused a crash on database "DB2019" (e2dd72a2-be82-4384-905f-aad04700d012).
4. Microsoft Exchange Information Store worker process (9420) has encountered a fatal database exception (Microsoft.Isam.Esent.Interop.EsentBadPageLinkException: Database corrupted
....
5. At '09.08.2022 07:23:30' the Exchange store database 'DB2019' copy on this server appears to be inconsistent with the active database copy or is corrupted. For more details about the failure, consult the Event log on the server for other storage and "ExchangeStoreDb" events. A successful failover restored service.
6. Database redundancy health check failed.
Database copy: DB2019
Redundancy count: 1
Error: Fehler bei der Datenbankredundanzprüfung für die Datenbank 'DB2019'. Diese Fehler können bewirken, dass die Redundanz der Datenbank verringert und so das Risiko von Datenverlust vergrößert wird. Redundanzanzahl: 1. Erwartete Redundanzanzahl: 2. Ausführliche Fehlerinformationen:
Die Datenbank lief dann nahtlos am Server2 weiter.
Aktuell läuft ein resseeding, um die DB wieder auf dem Server1 in Betrieb zu nehmen.
Der Check der DB mit ESE Util inkl. der Logs war aber ohne befund.
Beide Server sind VMs unter VMWare 6.5
Server 1 auf VMWare Node 2, zudem die Disk auf Datenspeicher0 (Läuft in einen JoviaDSS Cluster)
Server 2 auf VMWare Node 1, zudem die Disk auf Datenspeicher1 (Läuft in einen JoviaDSS Cluster)
Zeugenverzeichnis liegt auf einem physikalischem Server im LAN.
Das ganze läuft aktuell mangels LoadBalancer noch mit DNS round Robin für autodiscover.
Wir wollten mit dem Kommando: cluster /cluster:DAG1 /prop den Cluster status anzeigen, bekommen aber diesen Fehler:
Systemfehler 1722 ist aufgetreten (0x000006ba).
Der RPC-Server ist nicht verfügbar.
lt. Get-DatabaseAvailabilityGroup DAG1 -Status | fl scheint aber alles ok zu sein.
RunspaceId : fb1741f5-eec9-4c2f-b9b5-4c94afbb4bcc
Name : DAG1
Servers : {Server2, Server1}
WitnessServer : fileserver1.domain.local
WitnessDirectory : C:\DAG1
AlternateWitnessServer :
AlternateWitnessDirectory :
NetworkCompression : InterSubnetOnly
NetworkEncryption : InterSubnetOnly
ManualDagNetworkConfiguration : False
DatacenterActivationMode : Off
StoppedMailboxServers : {}
StartedMailboxServers : {}
DatabaseAvailabilityGroupIpv4Addresses : {255.255.255.255}
DatabaseAvailabilityGroupIpAddresses : {255.255.255.255}
AllowCrossSiteRpcClientAccess : False
ActivityState :
FileSystem : NTFS
OperationalServers : {Server1, EXCHANGE}
PrimaryActiveManager : EXCHANGE
ServersInMaintenance : {}
ServersInDeferredRecovery : {}
ThirdPartyReplication : Disabled
ReplicationPort : 64327
NetworkNames : {MapiDagNetwork}
WitnessShareInUse : Primary
DatabaseAvailabilityGroupConfiguration :
AutoDagSchemaVersion : 1.0
AutoDagDatabaseCopiesPerDatabase : 1
AutoDagDatabaseCopiesPerVolume : 1
AutoDagTotalNumberOfDatabases : 0
AutoDagTotalNumberOfServers : 0
AutoDagDatabasesRootFolderPath : C:\ExchangeDatabases
AutoDagVolumesRootFolderPath : C:\ExchangeVolumes
AutoDagAllServersInstalled : False
AutoDagAutoReseedEnabled : True
AutoDagDiskReclaimerEnabled : True
AutoDagBitlockerEnabled : False
AutoDagFIPSCompliant : False
AutoDagAutoRedistributeEnabled : True
AutoDagSIPEnabled : False
ReplayLagManagerEnabled : True
MailboxLoadBalanceSellableStorage :
MailboxLoadBalanceRelativeLoadCapacity :
MailboxLoadBalanceComputeCapacity :
MailboxLoadBalanceOverloadedThreshold :
MailboxLoadBalanceUnderloadedThreshold :
MailboxLoadBalanceEnabled :
SiloName :
DistributedStoreConfig :
RequestedDistributedStoreConfig :
DxStoreWitnessServers :
DistributedStoreMembershipConfig :
DistributedStoreMembershipConfigOverride :
DxStoreSpareServers :
PreferenceMoveFrequency : 01:00:00
MetaCacheDatabaseVolumesPerServer :
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
DistinguishedName : CN=DAG1,CN=Database Availability Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Erste
Organisation,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local
Identity : DAG1
Guid : 5f09e855-2b9e-4166-9b47-34dbc260a97e
ObjectCategory : domain.local/Configuration/Schema/ms-Exch-MDB-Availability-Group
ObjectClass : {top, msExchMDBAvailabilityGroup}
WhenChanged : 08.08.2022 18:22:08
WhenCreated : 08.08.2022 18:22:08
WhenChangedUTC : 08.08.2022 16:22:08
WhenCreatedUTC : 08.08.2022 16:22:08
OrganizationId :
Id : DAG1
OriginatingServer : fileserver12.domain.local
IsValid : True
ObjectState : Unchanged
Habt ihr hierzu eine Idee?
Zudem frag ich mich, ob es sinn macht ein 2. Zeigenverzeichnis auf einem weiteren Fileserver zu haben. Das dies redundant ist. Das scheint aber nicht so einfach zu sein.
Danke
Michi
Könnte bitte ein Mod den Typo aus dem Titel korrigieren?
mach --> nach
cluster /cluster:DAG1 /prop
Habt ihr ne ip-less dag eingerichtet?
Afair wird der Befehl dann nicht funktionieren. ;)
Ok, danke.
Lesen macht schlau, hab ich gerade auch bei MS gelesen.
Die Frage ist nur, warum nach ein paar minuten der Switch zum Server2 erfolgt. Vorhin wieder.
Ich lasse jetzt mal einen reseed vom Server2 zum eigentlich Server1 laufen.
Dann werde ich nicht zurück switchen und sehen, ob diese Kopie in sync bleibt.
Habt ihr noch andere Ideen?
Hat der Server1 evtl. ein anderes Problem?
Danke
Michi
Update:
Wir haben 3 Datenbanken im DAG.
Eine fast leere, mit 300 MB und eine mit rund 60 GB. Die laufen normal. Diese sind nach der synchronisation passiv und fehlerfrei. Ein switch erfolgte nicht.
Die 3. Datenbank mit rund 350 GB wechselt kurz nach erfolgtem seeding zum Node, auf dem Sie kopiert wurde und springt in der Quelle auf fehlerhaft.
Den Pingpong hab ich jetzt 2x durch.
Nach dem Sync kommt diese Meldung:
The active copy of DB2019 has a missing or corrupted log file (E0000001349.log). As a result, existing log files and any partial data will be moved to a new directory (C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1885743355\IgnoredLogs\SkippedLogs\2022-08-09T12-49-01). These files and data will be automatically deleted from the directory after 30 days.
Dann switcht sie rüber. Das kam auf beiden Nodes.
Irgend eine Idee? So wirklich kaputt scheint mir die nicht zu sein, da wir sie erst Sonntag geprüft haben. Seitdem kein Crash, oder Cluster switch.
Zwar reboot der Server, aber sauber ohne Fehler und die DB wurde auch direkt gemounted.
So jedenfalls würde ich die DB aus dem DAG nehmen, oder nur als zeitlich verzögerte passive kopie.
Ideen oder Vorschläge?
Danke
Michi
Noch ein Update:
Der Sync der DB auf den Server 2 hat nun geklappt.
Seit 15 Minuten ist es durch und die DB ist noch auf dem Server1 aktiv.
Allerdings ist mir aufgefallen, das beide auf Server1 aktiven Datenbanken keinen aktuellen Zeitstempel haben.
Die LOG Dateien sind aber aktuell.
Auf dem Server, der über die Kopie verfügt, ist die EDB aber aktuell.
Nur während ich diese Nachricht schreibe, ist die DB wieder zurück geswitcht.
Läuft wieder auf Server2 und ist nun vom Zeitstempel der im Server1 wieder aktuell.
Wie sind denn die Aktivierungsprioritäten gesetzt?
Für die DB2019 für den Server1 auf 1 und den Server2 auf 2.
Das gleiche für die 2. Datenbank, die 60 GB groß ist. Die switcht nicht automatisch.
Bei der dritten, die sehr klein ist, steht der Server 2 an erster Stelle, der Server 1 an zweiter. Auch hier wird nicht geswitcht.
Get-MailboxDatabaseCopyStatus -Identity DB2019 | Format-List
zeigt dann folgendes:
SuspendComment : Die Datenbankkopie wurde aufgrund einer Fehlerelementverarbeitung automatisch angehalten mit dem Fehlerelementtag "Corruption". At
'09.08.2022 19:17:39' the Exchange store database 'DB2019' copy on this server appears to be inconsistent with the active database copy
or is corrupted. For more details about the failure, consult the Event log on the server for other storage and "ExchangeStoreDb"
events. A successful failover restored service.
Jetzt läuft wieder ein Seeding von Server 2 auf Server 1. Mal sehen ob die dann wieder direkt zurück switcht.
Falls mit der Datenbank doch etwas sein sollte, würde das Seeding nicht durch laufen?
Oder sollte man die DB offline nehmen und nochmal mit ESEUTIL prüfen, auch ob alle logs verarbeitet wurden und nicht korrupt sind?
Wäre aber komisch, wenn Exchange einen inkonsistente DB spiegeln würde.
An deiner Stelle würde ich die Postfächer aus db 1 einfach in db 2 oder 3 verschieben, danach db1 wegwerfen und neu anlegen. ;) Alternativ temporär db4 anlegen, dann wachsen 2 und 3 nicht unnötig an.
Hi,
da hast Du absolut recht. Ich hatte auch schon mit dem Gedanken gespielt.
Ich habe eine neue DB auf dem 2. Server angelegt und verschiebe gerade alle Postfächer. Dann wird die erste DB gelöscht.
Arbitration und co schiebe ich zum Schluss, aktuell erst mal die Userpostfächer.
Danke
Michi