☰

Warum wird WinDRBD Diskless/StandAlone (beide Knoten)

tag-icon • tag-icon drbd window-server-2019
Warum wird WinDRBD Diskless/StandAlone (beide Knoten)

Ich habe eine Frage.

Derzeit ist dieses Betriebssystem Windows Server 2019. Die Volume-Konfiguration ist Raid-5. Die beiden Server sind über ein Heartbeat-Netzwerk verbunden. Beide Knoten wurden mit WinDRBD gespiegelt. Beide Knoten haben dieselbe Konfiguration. Ich habe G: unformatiert gelassen und D: so eingestellt, dass es für den primären Knoten sichtbar ist.

meine Ressourcen sind unten

include "global_common.conf";

resource "foo" {
    protocol    A;

    net {
        use-rle no;
    }
    on node1 {
        address     XXX.XXX.XXX.XXX:7600;
        node-id 1;
        volume 1 {
            disk        "G:";
            device      minor 1;
            meta-disk   internal;
        }
    }
    on node2 {
        address     XXX.XXX.XXX.XXX:7600;
        node-id 2;
        volume 1 {
            disk            "G:";
            device      minor 1;
            meta-disk   internal;
        }
    }
}

Beide Knoten funktionierten normal. Die Tests wurden durch Rollentausch abgeschlossen. ( primär → sekundär / sekundär → primär )

Das Problem trat jedoch nach dem Booten auf.

Nach dem Booten wird der Status wie unten angezeigt. (beide Knoten)

foo role:Secondary
  volume:1 disk:Diskless
  node2 connection:StandAlone

Ich habe viel nachgedacht und gesucht, konnte aber keine Antwort finden.

Es gab ein paar Dinge, die mir misstrauisch waren.

Ich frage mich, ob es daran liegt, dass ich es versucht habe, bevor dem Laufwerk der Buchstabe G: zugewiesen wurde. Wenn meine Vermutung richtig ist, gibt es dann eine Problemumgehung?

Wenn es meiner Meinung nach nun doch so ist, das oben genannte Problem weiterhin auftritt, was ist die Ursache?

Einmal ließ es sich folgendermaßen lösen. Aber ich möchte die Ursache finden und genau beheben.

drbdadm down foo
drbdadm up foo

Vielen Dank im Voraus für Ihre Hilfe.

Antwort1

WinDRBD verliert den Heartbeat, was zu dem angezeigten Problem führt. Schneiden Sie die Kabel für h/b ab, und Sie können das Problem problemlos reproduzieren. Die Zeichen stehen an der Wand: Verwenden Sie WinDRBD zumindest noch nicht in der Produktion. Es ist fragil.

Antwort2

@BaronSamedi1958 hat tatsächlich recht: WinDRBD ist keine native Windows-Lösung, sondern wurde offensichtlich mithilfe von Wrappern, die Linux-Kernel-APIs emulieren, von Linux auf Windows portiert.

https://linbit.com/windrbd-replicated-disk-drives-for-windows/

„Technisch gesehen besteht der WinDRBD-Windows-Treiber aus einer dünnen Linux-Kompatibilitätsschicht, die die vom DRBD-Treiber für die Windows-Plattform verwendeten Linux-Kernel-APIs emuliert. Innerhalb dieser Schicht funktioniert die ursprüngliche DRBD-Engine (mit einigen compilerspezifischen Patches).“

Infolgedessen hat WinDRBD keine Ahnung, was es tut und was vor sich geht. Bei der Initialisierung versucht es, eine Netzwerkverbindung zum Partnerknoten herzustellen, und schlägt fehl, weil ... innerhalb des Windows-Kernel-Ökosystems der Speicherstapel gestartet wird, BEVOR der Netzwerkstapel vollständig einsatzbereit ist! WinDRBD kann den Partnerknoten nicht anpingen, geht also davon aus, dass etwas schief läuft, und ruft den Speicherpool nicht auf, um ihn zu erhalten und Datenbeschädigungen zu vermeiden.

Es gibt mehrere Möglichkeiten, dieses Problem zu lösen:

  1. Platzieren Sie eine Startabhängigkeit für den Windrbd-Treiber auf dem NDIS-Miniport, der die von WinDRBD verwendeten Netzwerkkarten steuert.

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/specifying-driver-load-order

Dies ist tatsächlich eine unzuverlässige Methode, da durch Ändern des Netzwerkadapters die Konfiguration zerstört wird. + Es gibt eine ganze Reihe von Treibern über dem NDIS-Miniport, z. B. NDIS-Filter (Firewall?), NDIS-Protokolltreiber (TCP/IP?) usw., über die Sie nicht viel wissen, und zu denen Sie mit Spezialtools zurückkehren müssen, mit denen Sie möglicherweise nicht vertraut sind.

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-driver-stack

  1. Vermeiden Sie den automatischen Start von WinDRBD und verwenden Sie ein anmeldeabhängiges Skript, um es pseudoautomatisch zu starten. Während des Anmeldevorgangs sind alle Kernelkomponenten bereit und im schlimmsten Fall können Sie Ihre erfolglosen Treiberstartprobleme in eine Protokolldatei protokollieren, analysieren, das Skript erneut versuchen usw.

Dies ist natürlich möglich, erfordert aber etwas Herumprobieren mit PowerShell. Einige gute Ausgangspunkte finden Sie in diesem Diskussionsthread unten.

https://stackoverflow.com/questions/27599287/powershell-disable-and-enable-a-driver

  1. Verwenden Sie etwas, das von Grund auf für Windows entwickelt wurde, wie beispielsweise StarWind vSAN Free oder Microsofts eigenes integriertes SDS mit beispielsweise AzS HCI.

https://www.starwindsoftware.com/starwind-virtual-san-free

https://docs.microsoft.com/en-us/azure-stack/hci/overview

Antwort3

Möglicherweise möchten Sie Ihre WinDRBD-Version aktualisieren. Die von Ihnen verwendete Version ist noch ein Release Candidate (1.0.0-rc14 oder so, geschätzt aus dem Datum Ihres Beitrags). Bitte aktualisieren Sie auf ein neueres WinDRBD. Vorkompilierte Installationsprogramme finden Sie unter:

https://linbit.com/linbit-software-download-page-for-linstor-and-drbd-linux-driver/

Zum Zeitpunkt des Schreibens dieses Artikels ist die neueste Version 1.1.10.

Wenn das Laufwerk G: Ihr Sicherungsgerät ist, ist diese Einstellung korrekt.

Wenn das Problem weiterhin besteht, lassen Sie es mich bitte wissen.

verwandte Informationen