mailbox databases dismounting frequently without followable reason

[BroBias 5]

21 minutes ago, Dukel said:

Willst du die Ursache herausfinden / verstehen? Zieh de Microsoft Support hinzu oder einen Dienstleister.

Das hab ich natürlich in der Hinterhand, klar. Aber so ein Thema mit dem MS Support angehen ... no way ... da sind meine Erfahrungen mit MS Support über die letzten 8 Jahre einfach nur miserabel; freundlich ausgedrückt ;) -> Dienstleister ist erstmal die letzte Option.

 

22 minutes ago, Dukel said:

Btw. du musst nicht auf mehrere 100 GB herunter. 2 TB Datenbanken sind auch kein Problem. Hier hast du evtl. ein anderes Thema.

Ich hab bei einem Kunden eine Umgebung mit 24x 2 TB Datenbanken in einer DAG und es gibt keine solchen Probleme.

Theoretisch würde ich das auch so sehen, ja. Die Realität zeigt leider etwas anderes (siehe Beschreibungen hinsichtlich db maintenance die niemals abgeschlossen wird). Dabei weiß ich allerdings, dass weder vm storage/disks (dedicated luns) sauber konfiguriert sind, noch die volumes selbst (file allocation size nur 8 KB + ntfs statt refs). Gleichzeitig läuft auch noch das Netzwerk auf 1 statt 10 GB ... 
Diese Umstände werde ich jedoch erst beheben können mit einer Migration nach 2019 und neue Server (Metall) kommendes Jahr. Deshalb der versuchte workaround auf mehr aber kleinere dbs zu verteilen.

 

25 minutes ago, Dukel said:

Willst du Funktionierende Server / DB's haben? Erstelle (einen) neue(n) Server & Datenbanken und verschiebe die Postfächer dort hinein und entferne den kaputten oder alle bisherigen Server.

Leider sieht es eben momentan so aus, dass der Server auf dem momentan alle Clientanfragen landen, alle dbs stabil laufen usw -> irgendwie korrupte kopien erstellt, selbst von neuen/leeren dbs. Der neue Server würde mir so nur Aufwände bringen, wenn ich im Anschluss nicht einfach hergehen kann und im Hintergrund neue Kopien ziehen lassen kann vom "main server". Dann scheint es mir sinnvoller auf dem aktuellen "Problemserver" den Storage zu erweitern, neue dbs zu erstellen, passive kopien auf den "main server" zu schieben und dann in diese dbs alle mbx verschieben (erfolgreiche switchover tests voraus gesetzt). Sobald das abgeschlossen ist, könnte ich dann die alten dbs wegschmeißen und so hoffentlich wieder in normal Modus übergehen. Jedenfalls würde so der Aufwand "Server neu aufsetzen und bestehende Konfigurationen angleichen" wegfallen.

 

 

Grundsätzlich wäre jedoch schon interessant, wie das sein kann. Ein völlig normal operierender Server erstellt korrupte passive db Kopien auf DAG Mitgliedern ? Was kann dafür verantwortlich sein, will mir nicht einleuchten.

[BroBias 5]

Hey ihr Lieben,

 

nach wie vor ist mein Thema aktuell ^^. Ich habe schlicht auch noch einige andere Themen auf dem Tisch, kommende Woche Urlaub, Festival und Feuerkunst-Kurs .... Da der Hauptserver sauber läuft und Backups ebenfalls stabil bleiben ist die Lage relativ (!) entspannt

 

Pläne sind gefasst weitere Server hochzuziehen, neue DBs zu erstellen, mbx zu migrieren usw. Das sind jedoch eher langfristige Prozesse (gibt auch noch ungeklärtes bzgl. der Wahl der besten Site hierfür, Hardware hierfür - neue Server will ich dann endlich nach BestPractice aufsetzen und nicht mehr mit Kompromissen arbeiten müssen hinsichtlich HW & Dedicated ressources).

 

Eine Rückfrage lässt sich evtl. dennoch noch klären, bevor ich dann in den Urlaub gehe ^^:
 

Im Rahmen der Fehlersuche bin ich auch vor allem an Berechtigungen auf Dateien und Ordneren auf den DB und Log Laufwerken hängen geblieben. Diese waren offensichtlich nicht konsistent und ich hab mich bemüht diese dem was ich auf dem Hauptserver auslesen kann anzupassen. Nun lässt sich auch die eine neue DB nicht mehr mounten, die auf dem Zweitserver erstellt wurde.

Kurzum: Das bestätigt mich in meiner Vermutung, dass mit Datei/Ordner-Berechtigungen irgendetwas nicht stimmt, auch wenn ich es im System nicht (mehr) wirklich erkennen kann.

 

In KBs usw. konnte ich dazu nicht wirklich was finden. Was habt ihr denn für Berechtigungen gesetzt auf DB und Log-Drive und zwar durch die Verzeichnisstruktur bis zu den einzelnen DB -bzw. Logfiles ? Welche Berechtigungen werden vererbt, welche nicht ? Das wäre denk noch sehr hilfreich, dieses Thema mal mit funktionierenden Umgebungen abgleichen zu können. :)

Ganz lieben Dank vorab und nen wundervollen Tag alle miteinander.

[BroBias 5]

7 hours ago, BroBias said:

In KBs usw. konnte ich dazu nicht wirklich was finden. Was habt ihr denn für Berechtigungen gesetzt auf DB und Log-Drive und zwar durch die Verzeichnisstruktur bis zu den einzelnen DB -bzw. Logfiles ? Welche Berechtigungen werden vererbt, welche nicht ? Das wäre denk noch sehr hilfreich, dieses Thema mal mit funktionierenden Umgebungen abgleichen zu können. :)

Noch offen, evtl. mag jemand teilen ? :)

 

Zusätzlich bin ich momentan an der Arbeitshypothese, dass folgendes Error-Event ein Auslöser für den unmittelbaren Dismount nach switchover sein könnte:

"Application - ESE - 489: "msexchangerepl. An attempt to open xxx\yyy.edb for read only access failed with system error 32. Cannot access because being used by another process"

Diese DB ist leer, verstehe nicht woher der Fehler kommen soll. Virenscanner, backup agent oder ähnliches läuft auf diesen Servern entweder nicht, oder ist zum Zeitpunkt inaktiv (backup). Zugriffe auf das edb-file sind standard: system - full, orgamgmt - full, view-only orgamgmt - read/execute und admins - full. 

 

Ist mir schleierhaft woher der file-lock kommen soll und weshalb auf diesem Server aber nicht auf den anderen ... :/

[tesso 373]

Hast du einen Virenscanner der evtl die Datei blockiert?

[BroBias 5]

Nope, da läuft grundsätzlich kein Virenscanner, nichts dergleichen installiert. MS Defender komplett abgeklemmt.

[Dukel 451]

Erstelle doch eine neue DB (ohne vorher die Ordnerstruktur zu erstellen!). Da siehst du wie die Berechtigungen sein sollten.