none
Cluster/ DAG Fehler - Datenbankserver melden sich aus dem Cluster ab RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Liebe Mitadministratoren,

    seit ein paar Tagen stehe ich vor dem Problem, dass die DAG verrücktspielt.

    Vermeintlich ohne Ankündigung verabschiedet sich der DAG Cluster.

    Unsere Konfiguration:

    2 CAS-Server mit Windows LNB

    2 Datenbankserver in einer DAG

    Der Vollständigkeit halber: wir betreiben zwar noch einen weiteren Standort, allerdings haben wir aufgrund der Leitungsperformance gegen die Einbindung des Servers am 2. Standort entschieden. Von daher kann er außer Acht gelassen werden.

    Die Netzwerkkonfiguration:

    Funktion/ Servername

    DNS

    IP-Adresse

    NLB (CAS)

    MSX

    10.10.10.10/ 24

    DAG

    MSXDAG

    172.17.130.40/ 16

    CAS-Server 1

    MX1

    10.10.10.160/ 24

    192.168.10.160/ 24

    CAS-Server 2

    MX2

    10.10.10.180/ 24

    192.168.10.180/ 24

    DB-Server 1

    MXDB1

    10.10.10.170/ 24

    172.17.130.170/ 16

    DB-Server 2

    MXDB2

    10.10.10.190/ 24

    172.17.130.190/ 16

    DC/ Witness-Share für DAG

    172.17.130.123/ 16

    Alle Server haben 2 Netzwerkkarten.

    Die Netzwerkkarten der Datenbankserver 172.17.130.170 und 190 sind über die Clusterkonfiguration MSXDAG mit der IP 172.17.130.40 eingebunden,
    die CAS Server über NLB per IP 192.168.10.160 und 180 auf die IP 10.10.10.10.

    Die Fehler, die bei der DAG auftreten haben keine zeitliche Regelmäßigkeit. Sie treten zu unterschiedlichen Zeiten auf. Backup konnte ich aufgrund des mangelnden zeitlichen Zusammenhangs ausschließen.

    Die Fehler in der Chronologie (exemplarisch):

    03:00:31         Microsoft-Windows-FailoverClustering Fehler 1135          auf MXDB1
    „Der Clusterknoten "MXDB2" wurde aus der aktiven Failovercluster-Mitgliedschaft entfernt. Möglicherweise wurde der Clusterdienst auf dem Knoten beendet […]“

    03:00:32         Microsoft-Windows-FailoverClustering Fehler 1135          auf MXDB2
    „Clusterknoten MXDB1 wurde aus der aktiven Failovercluster-Mitgliedschaft entfernt. Möglicherweise wurde der Clusterdienst auf dem Knoten beendet. […]“

    03:00:45         Microsoft-Windows-FailoverClustering Fehler 1049          auf MXDB2
    „Die Cluster-IP-Adressressource "IPv4 Static Address 1 (Clustergruppe)" kann nicht online geschaltet werden, da eine doppelte IP-Adresse "172.17.130.40" im Netzwerk erkannt wurde. Stellen Sie sicher, dass alle IP-Adressen eindeutig sind.“

    03:00:45         Microsoft-Windows-FailoverClustering Fehler 1069          auf MXDB2
    „Bei der Clusterressource "IPv4 Static Address 1 (Clustergruppe)" im geclusterten Dienst oder in der geclusterten Anwendung "Clustergruppe" ein Fehler aufgetreten.“

    03:01:32         Microsoft-Windows-FailoverClustering Fehler 1564          auf MXDB1
    „Die Dateifreigabe-Zeugenressource "File Share Witness (\\witness.domain.lan\MSXDAG.domain.lan)" konnte nicht für die Dateifreigabe "\\witness.domain.lan\MSXDAG.domain.lan" vermitteln. Stellen Sie sicher, dass die Dateifreigabe "\\witness.domain.lan\MSXDAG.domain.lan" vorhanden ist und dass der Cluster darauf zugreifen kann.“

    03:01:32         Microsoft-Windows-FailoverClustering Fehler 1069          auf MXDB1
    „Bei der Clusterressource "File Share Witness (\\witness.domain.lan\MSXDAG.domain.lan)" im geclusterten Dienst oder in der geclusterten Anwendung "Clustergruppe" ein Fehler aufgetreten.“

    03:01:32         Microsoft-Windows-FailoverClustering Fehler 1177          auf MXDB1
    „Der Clusterdienst wird heruntergefahren, da die Quorumverbindung getrennt wurde. Dies kann darauf zurückzuführen sein, dass die Netzwerkverbindung zwischen einigen oder allen Knoten im Cluster unterbrochen wurde oder dass ein Zeugendatenträgerfailover stattgefunden hat.
    Führen Sie den Konfigurationsüberprüfungs-Assistenten aus, um die Netzwerkkonfiguration zu prüfen. Wenn das Problem weiterhin besteht, prüfen Sie, ob Hardware- oder Softwarefehler in Bezug auf den Netzwerkadapter vorliegen. Prüfen Sie auch, ob andere Netzwerkkomponenten fehlerhaft sind, an die der Knoten angeschlossen ist, z. B. Hubs, Switches oder Brücken.“

    Ich habe die komplette Konfiguration geprüft und keinen Punkt gefunden, an dem ich schrauben könnte.

    Ich habe auch eine Clusterüberprüfung durchgeführt. Hier beanstandet der Server:

    „Die Eigenschaft "HostRecordTTL" für den Netzwerknamen "Name: MSXDAG" wurde auf 300 ( 5 Minuten) festgelegt. Für lokale Cluster ist der vorgeschlagene Wert 1200 (20 Minuten).“

    Diese Einstellung habe ich bisher nicht angefasst. Ist das das Problem?

    Andere Lösungsansätze? Im Moment ist es eher Stochern im Nebel und ich möchte Ausfallzeiten so gering wie möglich halten.

    Ich bin für jede Hilfe dankbar…

    Gruß

    André

    André Hoppenkamps

    Donnerstag, 28. Januar 2016 08:04
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    der Grund, warum Microsoft möchte, dass Trausted Subsystem in den lokalen Admins ist, findest Du sogar im verlinkten Artikel:

    > so that Exchange can create, manage, and repair the FSW on its own.

    Ich muss also sehr genau wissen, was das Produkt da macht. Wenn ich das nicht kann, und in diesem Fall ist es nicht dokumentiert, muss ich davon ausgehen, dass der Hersteller sich bei seiner Aussage was bei gedacht hat und nicht einen Work-Around suchen.

    Es kann also für Dein Problem wichtig sein - oder auch nicht. Aber da außerhalb von Microsoft das keiner bestätigen kann, würde ich das so bauen, wie es korrekt ist. Und wenn dann das Problem bestehen bleibt, gibt es auch keinen Ärger mit Microsoft, wenn man deren Support anruft.

    In der Microsoft-Sprache nennt sich das "best-effort".

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 28. Januar 2016 15:33
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden
    Moin,

    fangen wir mal mit den Grundlagen an:

    Über welche Exchange-Version reden wir denn genau?
    http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

    > DC/ Witness-Share für DAG

    Die Benutzung eines DC als FSW ist unglücklich, weil es massive Sicherheitslöcher reisst. MSFT empfiehlt einen HT/CAS (bis 2010 SP 1) oder einen normalen Fileserver (wenn man das ab 2010 SP 2 empfohlene Multi-Role einsetzt), wobei es bis auf ein Server-Betriebssystem keine besonderen Anforderungen gibt.

    Wenn Du beim DC bleibst: Ist die Gruppe "Exchange Trusted Subsystem" Mitglied der "builtin/administrators"?

    > „Die Cluster-IP-Adressressource "IPv4 Static Address 1 (Clustergruppe)" kann nicht online geschaltet werden, da eine doppelte IP-Adresse "172.17.130.40" im Netzwerk erkannt wurde. Stellen Sie sicher, dass alle IP-Adressen eindeutig sind.“

    Ist sichergestellte, dass die Adresse wirklich nicht doppelt ist?

    Ansonsten fürchte ich, dass man diesen Fehler nicht in einem Forum wird klären können. Dafür braucht man zu viele interne Infos, die Du nicht öffentlich machen würdest und muss sich zu viele Dinge anschauen. Ich würde mir zum Beispiel die DCs anschauen, DNS, Netzwerk, Routing, die verwendete Hardware, usw. usf. Es bringt nichts, wenn wir Dich fragen, ob in DNS alles ok ist und Du sagst "ja", weil Dir die Erfahrung fehlt, die potentiellen Fehler überhaupt zu sehen.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 28. Januar 2016 08:29
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Robert, danke für die schnelle Antwort.

    Um Deine Fragen zu beantworten:

    1. Wir haben Exchange 2010 SP3 RU11 (Version 14.3 Build 123.4) im Einsatz.
    2. Die Gruppe „Exchange Trusted Subsystem“ ist nicht Mitglied der Gruppe „Domänenadministratoren“
    3. Ja, ich kann sicher sagen, dass die IP-Adresse nicht doppelt vergeben ist. DHCP-Bereiche sind außerhalb der Range der genannten IP-Adresse und manuell ist keine solche Adresse vergeben.

    Nehmen wir mal den Ansatz FSW. Das Witness auf einem CAS/HT einrichten. Da je ein CAS Server mit einem DB-Server auf einem ESX Server betrieben werden, hätten wir keine Hochverfügbarkeit mehr, für den Fall, dass der ESX Server gewartet werden muss, geschweige denn ausfällt. Daher auch kein guter Ansatz.

    Die Gruppen „Exchange Trusted Subsystem“ war nie Mitglied der Gruppe „Domänenadministratoren“, hat allerdings Vollzugriff auf die Freigabe auf dem DC (Freigabeberechtigung MSXDAG$ = Vollzugriff, NTFS-Berechtigungen „Exchange Trusted Subsystem“ = Vollzugriff und Besitzer dieses Ordners)

    Die Freigabe wurde bei Einrichtung Exchange durch unseren Dienstleister so eingerichtet. Referenz: http://www.thecabal.org/2010/08/manually-creating-a-dag-fsw-for-exchange-2010/

    Für mich nicht nachvollziehbar ist, dass der Fehler erst seit kurzer Zeit auftritt. Es wurden keine Änderungen an der Gruppenkonfiguration bzgl. Exchange Trusted Subsystem vorgenommen. Einzig die Installation des RU11 liegt im zeitlich nächsten Zusammenhang.

    Einen Fehler der Hardware (Netzwerk oder Server) kann ich nicht ausschließen, es gibt allerdings keinerlei Hinweise.

    Gruß

    André

    André Hoppenkamps

    Donnerstag, 28. Januar 2016 09:39
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    der Grund, warum Microsoft möchte, dass Trausted Subsystem in den lokalen Admins ist, findest Du sogar im verlinkten Artikel:

    > so that Exchange can create, manage, and repair the FSW on its own.

    Ich muss also sehr genau wissen, was das Produkt da macht. Wenn ich das nicht kann, und in diesem Fall ist es nicht dokumentiert, muss ich davon ausgehen, dass der Hersteller sich bei seiner Aussage was bei gedacht hat und nicht einen Work-Around suchen.

    Es kann also für Dein Problem wichtig sein - oder auch nicht. Aber da außerhalb von Microsoft das keiner bestätigen kann, würde ich das so bauen, wie es korrekt ist. Und wenn dann das Problem bestehen bleibt, gibt es auch keinen Ärger mit Microsoft, wenn man deren Support anruft.

    In der Microsoft-Sprache nennt sich das "best-effort".

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 28. Januar 2016 15:33
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    um den Fehler als gelöst zu betrachten, hier mal die Einstellungen, die ich vorgenommen habe:

    Zum Einen, Dank an Robert Wille, Berechtigungen für das Quorum.
    Freigabe und NTFS-Rechte für "Exchange Trusted Subsystem" = Vollzugriff und der Gruppe Domain\Administratoren hinzugefügt.
    Scheinbar war das Quorum korrupt und konnte nicht repariert werden.

    Ja ich gebe zu, dass die Benutzung des DCs nicht besonders glücklich gewählt ist, allerdings war das mal erste Wahl in der Erstkonfiguration, weil immer verfügbar.

    Eine weitere Fehlermöglichkeit war das Timing der DAG. Es wurden auch noch Snapshot-Fehler gemeldet.

    Gefunden habe ich dann dies hier:
    http://desktopfeedbag.com/2012/02/23/fixed-exchange-2010-sp1sp2-dag-fail-over-with-veeam/
    Nein, wir arbeiten nicht mit Veeam, aber der Ansatz des Timings war ausschlaggebend, hier die Werte anzupassen.

    Punktum: Jetzt funktioniert es wieder reibungslos.

    Danke für die Hilfe.

    Gruß

    André

    André Hoppenkamps

    Mittwoch, 10. Februar 2016 15:14
    |