none
Simulation von Hardwarefehlern im 2008R2-Cluster und Failoververhalten RRS feed

  • Frage

  • Guten Abend,

    bei mir liegt ein Verständnisproblem oder ein Fehler in der Clusterkonfiguration vor:

    Ausgangslage

    Testsystem: Cluster ohne MPIO, W2k8R2 Enterprise, nur einen Shared Datenträger, Firewall aus
    Patchstand:    Nur SP1 und alle regulären Updates (keinerlei Hotfixes)
    Zwei Node Cluster mit Knoten und Datenträgermehrheit und iSCSI Target als Shared Storage

    Netze/Virtuelle Switche:
    Public:        nur IPv4 192.168.000.0/24
    PRIVATE:    IPv4     192.168.100.0/24    (ohne GW, ohne DNS, ohne NETBIOS over TCP ..)
    iSCSI:        IPv4     192.168.010.0/24    (ohne GW, ohne DNS, ohne NETBIOS over TCP ..)

    NIC-Binding:    erst Public, dann Private, dann iSCSI
            Private: nur Clusterkommunikation
            iSCSI: keine Clusterkommunikation

    IPs:
    Node1    192.168.xxx.61    (als Hyper-V)
    Node2    192.168.xxx.62    (als Hyper-V)

    Cluster per Assistent installiert und nichts weiter geändert,
    ausser beim Quorum die Max. Anzahl von Neustarts von 1 auf 10 und den Zeitraum dafür von 15min auf 1min gesetzt,
    damit man die Fehler besser sieht.

    Clustervalidierungstest: komplett grün
    Clustergruppe verschieben klappt
    Nodeumschaltung klappt, wenn der andere Knoten heruntergefahren wird
    ping auf Clusternamen klappt, Cluster scheint auf den ersten Blick OK


    Probleme: Simulation von Hardwarefehlen

    Beim ersten Deaktivieren des virtuellen iSCSI-Switches auf Node1 geht das Quorum auf Node2 über. D.h.,
    das Verhalten ist wie erwartet. Jedenfalls so, wie ich es von W2k3 Clustern her kenne.

    Auf Node1 wird der Switch wieder aktiviert und kontrolliert, ob das Quorum wieder in der Datenträger
    verwaltung auftaucht.

    Fehler:

    Deaktiviert man auf Node2 den iSCSi-Switch passiert leider folgendes (unerwartetes):
    Node2 versucht das Quorum online zu schalten, was natürlich nicht gehen kann, da der iSCSi-Link für das Quorum
    down ist! Das Quorum verfügt über keine Abhängigkeiten.

    Verschiebt man das Quorum wieder auf Node1 und bringt alle iSCSI-Verbindungen online, dann funktioniert
    der Failover auch nicht mehr von Node1 auf Node2 (es geht erst wieder, wenn man Node1 rebootet)

    Rebootet man beide Server so, dass das Quorum auf Node2 liegt, kann man dort den iSCSI-NIC deaktivieren
    und der Failover wird wie erwartet auf Node1 durchgeführt.

    Das Clusterlog hat in dem betreffenden Zeitraum gefühlte 10.000 Zeilen, da komme ich nicht weiter ..
    Im Eventlog steht wie erwartet der Hinweis darauf, dass die iSCSI-Connection weg ist
    und das Failoverclustering meldet folglich Fehler 1127.
    Weiterhin steht dort, dass er den Clusterdatenträger1 (Quorum) nicht online nehemen kann.


    Frage(n):
    A) Warum versucht der Cluster(manager) einen Datenträger online zu nehmen, der nicht vorhanden ist?

    B) Oder gibt es auch hier noch einen Counter (failovercount), der besagt, dass nach einem Hardwarefehler für xx Stunden kein automatisches Failover erfolgen darf?


    Vielen Dank im Voraus
     

    Montag, 23. September 2013 18:57

Alle Antworten

  • Guten Abend,

    das Verhalten ist leider so Standard bei 2008R2. Bei 2003er Clustern konnte man einige Male hin und her schalten.

    Vermutlich will man dadurch erzwingen, das bei einem Hardwarefehler gleich reagiert werden soll,

    was natürlich ins Auge gehen kann, da ich W2k3 Cluster kenne, um die sich keiner kümmert,

    weil sie seit Jahren problemlos laufen.

    Von daher hat sich das Thema erledigt.

    Thomas

    Dienstag, 24. September 2013 22:15
  • Hallo Thoma

    Was heißen Sie virtuelle Switche ? Verwenden Sie drei virtuelle Switche auf Hyper-V ?

    Clustergruppe hat sowieso der Datenträger  Haben Sie es ausprobiert ?

    - Clustergruppe auf Node1 -> neustarten Node2

    - Clustergruppe auf Node2 ->neustarten Node1

    Gibt es auch das Problem wenn Sie der iSCSI-NIC  statt des virtuellen Switch ausprobieren ?

    A) Warum versucht der Cluster(manager) einen Datenträger online zu nehmen, der nicht vorhanden ist?

    Vielleicht ist die verbindung mit Node1 verloren. Können Sie ausprobieren der Private Netzwerk ohne virtuelle switche ?

    B) Oder gibt es auch hier noch einen Counter (failovercount), der besagt, dass nach einem Hardwarefehler für xx Stunden kein automatisches Failover erfolgen darf?

    Oder es geht vielleicht um der Position der ClusterGrouppe.

    viele grüße

    Nathan



    • Bearbeitet TadNa Mittwoch, 25. September 2013 10:55
    Mittwoch, 25. September 2013 10:52
  • Hallo Nathan,

    wie ich es bereits im 2ten Posting beschrieben habe, liegt bei mir KEIN Fehler vor. Es handelte sich daher um ein Verständnisproblem meinerseits, das sich aber auch erledigt hat.

    Das geschilderte Verhalten tritt daher bei allen neu aufgesetzten Clustern auf, die keine Clusterservices besitzen. Es ist quasi Standard. Nur werden es die wenigsten austesten.

    Meine alten Cluster liefen alle auf Windows Server 2003 mit dem alten Quorummodell und verhielten sich so, dass sie beim Abziehen der iSCSi-Kabel wenigstens 6 mal geschwenkt sind.

    Das "Quorummodell" wurde für "Knoten und Datenträgermehrheit" grundlegend geändert. Das ist mir leider erst klar geworden, nachdem ich diesen Threade eröffnet hatte.

    Trotzdem will ich Ihre Fragen beantworten, auch wenn es keinen Sinn macht.

    Da ich nicht auf einem funktionierenden Produktivsystem testen wollte, habe ich alles komplett auf Hyper-V nachgebaut: (DC1, DC2, Node1, Node2 und W2k12 iSCSI-Target [auf MPIO habe ich verzichtet])
    In Hyper-V habe ich natürlich 3 virtuelle Switche verwendet.

    Haben Sie es ausprobiert ?

    - Clustergruppe auf Node1 -> neustarten Node2

    - Clustergruppe auf Node2 ->neustarten Node1

    Ja klar habe ich das ausprobiert:

    wie bereits im ersten Posting beschrieben:

    Zitat:

    Clustervalidierungstest: komplett grün
    Clustergruppe verschieben klappt
    Nodeumschaltung klappt, wenn der andere Knoten heruntergefahren wird
    ping auf Clusternamen klappt, Cluster scheint auf den ersten Blick OK

    Vielen Dank

    Mittwoch, 25. September 2013 13:48