none
[Exchange 2010 DAG] Event ID 1135; FailoverClustering RRS feed

  • Frage

  • Hi Community,

    gestern Abend scheint etwas mit unserer DAG schief gelaufen zu sein.

    Kurz zuvor wird auf beiden Knoten eine Information geloggt die besagt, dass die Isatap Schnittstelle nicht mehr aktiv ist (Event 4201; Iphlpsvc)

    ---snip---

    Protokollname: System
    Quelle:        Microsoft-Windows-Iphlpsvc
    Datum:         24.10.2016 22:12:11
    Ereignis-ID:   4201
    Aufgabenkategorie:Keine
    Ebene:         Informationen
    Schlüsselwörter:
    Benutzer:      SYSTEM
    Computer:      UNIVERSE-4.DOMAIN.local
    Beschreibung:
    Die Isatap-Schnittstelle isatap.{3AA3587D-DFEE-430E-BAF1-78B5E5B3DFD7} ist nicht mehr aktiv.
    ---snap---

    Danach werden die im og Screenshot geposteten Fehler auf beiden DAG Nodes geloggt. Das ganze dauert nur etwa eineinhalb Minuten, danach kommt noch mal eine Info der isatap Schnittstelle betreffend:

    ---snip---

    Protokollname: System
    Quelle:        Microsoft-Windows-Iphlpsvc
    Datum:         24.10.2016 22:12:31
    Ereignis-ID:   4200
    Aufgabenkategorie:Keine
    Ebene:         Informationen
    Schlüsselwörter:
    Benutzer:      SYSTEM
    Computer:      UNIVERSE-4.DOMAIN.local
    Beschreibung:
    Die Isatap-Schnittstelle isatap.{3AA3587D-DFEE-430E-BAF1-78B5E5B3DFD7} mit der Adresse fe80::5efe:169.254.2.110 wurde hervorgebracht.
    ---snap---

    Die angegebene IPv4 IP Adresse scheint mir eine generische APIPA Adresse zu sein. Diese Meldungen kamen auf diesen Systemen überhaupt nur diesmal in Verbindung mit den Cluster Problemen vor.

    Die Frage ist nun zum einen, was dieses Problem verursacht haben kann? Auffällig ist, dass das Problem zeitlich mit dem Ende der Sicherung des passiven DAG Knotens (UNIVERSE-3) zusammenhängt. Diese Sicherung läuft aber schon länger ohne Probleme:

    Des Weiteren wäre wichtig wie der aktuelle Status des Clusters mittlerweile ist? Ich gehe davon aus, dass der Cluster wieder funktioniert, weil beide Knoten als aktiv markiert sind:

    Und auch die DAG wieder synchronisiert und in einen einwandfreien Zustand ist:

    Diesen Kopierstatus habe ich bei allen Datenbanken und ist eigentlich bei jeder bisherigen Kontrolle so gewesen, daher gehe ich aus, dass das wieder passt.

    Note: Das Client Witnsess Share ist auf einen DC eingerichtet und dieser hat in seinen Logfiles zu dieser Zeit keinerlei auffälligen oder dazu passenden Meldungen mitgeloggt.

    Hat jemand eine Erklärung was da passiert sein könnte?

    Thx & Bye Tom

    Dienstag, 25. Oktober 2016 10:45

Antworten

Alle Antworten

  • Hi Tom,

    hast Du eine Möglichkeit, zu prüfen, wie sich das System bei der letzten Sicherung verhalten hat? Welche Version von Veeam setzt Ihr für die Sicherung ein?


    Liebe Grüße

    Ben

    ____________________________

    MCSA Office 365

    MCSA SQL Server 2014

    MCITP Windows 7

    MCSA Windows 8/10

    MCSE Server Infrastructure

    ____________________________

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort. Danke! :-).

    Dienstag, 25. Oktober 2016 11:28
  • Servus Ben,

    >hast Du eine Möglichkeit, zu prüfen, wie sich das System bei der letzten Sicherung verhalten hat?

    Unauffällig:

    Hier das Anwendungslog des passiven Knotens, der als einziger auch gesichert wird. Die ersten Meldungen sind nicht mehr drauf, die Sicherung beginnt um 22:00 Uhr. Mit der letzten Meldung oben haben die Probleme dann angefangen:

    Und hier der gleiche Zeitraum vom aktiven Knoten, der aber nicht gesichert wird. Hier ist alles sauber bis zum  Ende der Sicherung. Die Fehler die der aktive Knoten loggt, finden sich ausschließlich im System Log und sind im OP schon mal gescreenshotet. Es wird nur der passive Knoten gesichert:

    >Welche Version von Veeam setzt Ihr für die Sicherung ein?

    9.0.0.902

    Thx & Bye Tom

    Dienstag, 25. Oktober 2016 11:58
  • In dem folgenden Veeam-KB-Artikel wird davon gesprochen, dass der Failovercluster-Dienst von Haus aus sehr empfindlich auf Verbindungsverluste oder sonstige "Merkwürdigkeiten" reagiert (ist ja an sich auch gut so).

    Der Artikel nennt die Möglichkeit, die Sensibilität durch Verändern von Registry-Werten ein wenig zu entschärfen (es bezieht sich allerdings auf geografisch aufgesplittete DAGs, vielleicht hilft es aber auch hier...?):

    https://www.veeam.com/blog/how-to-backup-exchange-database-availability-groups-dags-with-veeam-backup-replication.html


    Liebe Grüße

    Ben

    ____________________________

    MCSA Office 365

    MCSA SQL Server 2014

    MCITP Windows 7

    MCSA Windows 8/10

    MCSE Server Infrastructure

    ____________________________

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort. Danke! :-).

    Dienstag, 25. Oktober 2016 12:27
  • Die Clusterkonfig wird auch von VMWare empfohlen, auch für Cluster die nicht gesplitted sind. Als unsere Exchange noch virtuell waren haben wir die Meldung eigentlich jeden Tag gehabt bevor wir die Änderungen gemacht haben. Ist halt ein "Problem" von virtuellen Clustern wenn ein Snapshot passiert.

    Grüße

    Jörg

    Mittwoch, 26. Oktober 2016 07:01
  • Servus Jörg,

    >[...]haben wir die Meldung eigentlich jeden Tag gehabt bevor wir die Änderungen gemacht haben.

    ja gestern Abend hatten wir sie auch wieder. Welche Änderung habt ihr gemacht? Die Registryeinstellungen bzgl. des Timeouts?

    Ich muss zugeben, dass der Host auf dem der passive Knoten der DAG läuft, schon recht ausgelastet ist und es immer wieder mal vorkommt, dass eine Windowsmaschine dauerhaft eine hohe CPU Last erzeugt, weil mal wieder tagelang der Windows Update Prozess Amok läuft. So habe ich heute morgen auch eine Windows 7 VM, die einen Core regelrecht annektiert hat. Ich verschieb jetzt mal zwei VMs auf einen weniger ausgelasteten Host, vielleicht bringt das was.

    Thx & Bye Tom

    Mittwoch, 26. Oktober 2016 07:33
  • Servus Jörg,

    die Änderungen die ihr gemacht habt, welche waren das genau?

    Thx & Bye Tom

    Mittwoch, 26. Oktober 2016 11:17
  • die beiden Werte haben wir gesetzt:

    cluster /cluster:<Clustername> /prop SameSubnetDelay=2000

    cluster /cluster:<Clustername> /prop SameSubnetThreshold=10 

    Grüße

    Jörg



    Mittwoch, 26. Oktober 2016 15:21