เหตุใด WinDRBD จึงกลายเป็น Diskless/StandAlone (ทั้งสองโหนด)

ฉันมีคำถาม.

ปัจจุบันระบบปฏิบัติการนี้คือ Windows Server 2019 การกำหนดค่าไดรฟ์ข้อมูลคือ Raid-5 เซิร์ฟเวอร์ทั้งสองเชื่อมต่อกันด้วยเครือข่ายฮาร์ทบีท โหนดทั้งสองถูกมิเรอร์โดยใช้ WinDRBD โหนดทั้งสองมีการกำหนดค่าเหมือนกัน ฉันออกจาก G: ที่ไม่ได้จัดรูปแบบและตั้งค่า D: ให้โหนดหลักมองเห็นได้

ทรัพยากรของฉันอยู่ด้านล่าง

รวมถึง "global_common.conf";

ทรัพยากร "foo" {
    โปรโตคอล A;

    สุทธิ {
        ใช้-rle ไม่;
    }
    บน node1 {
        ที่อยู่ XXX.XXX.XXX.XXX:7600;
        รหัสโหนด 1;
        เล่มที่ 1 {
            ดิสก์ "G:";
            อุปกรณ์รอง 1;
            เมตาดิสก์ภายใน
        }
    }
    บนโหนด 2 {
        ที่อยู่ XXX.XXX.XXX.XXX:7600;
        รหัสโหนด 2;
        เล่มที่ 1 {
            ดิสก์ "G:";
            อุปกรณ์รอง 1;
            เมตาดิสก์ภายใน
        }
    }
}

โหนดทั้งสองทำงานได้ตามปกติ การทดสอบเสร็จสิ้นโดยการสลับบทบาท ( ประถมศึกษา â มัธยมศึกษา / มัธยมศึกษา â ประถมศึกษา )

อย่างไรก็ตาม ปัญหาเกิดขึ้นหลังจากการบูท

หลังจากบู๊ตแล้ว สถานะจะปรากฏขึ้นตามด้านล่าง (ทั้งสองโหนด)

บทบาท foo: รอง
  ไดรฟ์ข้อมูล: 1 ดิสก์: ไม่มีดิสก์
  การเชื่อมต่อ node2:สแตนด์อโลน

ฉันคิดและค้นหามากมาย แต่ไม่สามารถหาคำตอบได้

มีบางสิ่งที่ฉันสงสัย

ฉันสงสัยว่าเป็นเพราะฉันลองก่อนที่จะมีการกำหนดตัวอักษร G: ให้กับไดรฟ์หรือไม่ หากความคิดของฉันถูกต้องมีวิธีแก้ไขหรือไม่?

ถ้าตามความเห็นผมตอนนี้ แต่ปัญหาข้างต้นยังเกิดขึ้นอีก เกิดจากสาเหตุใดครับ?

เมื่อแก้ด้วยวิธีดังนี้แล้ว แต่อยากให้หาสาเหตุและแก้ไขให้ถูกต้อง

drbdadm ลง foo
กรี๊ดดดดดด

ขอบคุณล่วงหน้าสำหรับความช่วยเหลือของ.

@BaronSamedi1958 actually has a point: WinDRBD isn't a native Windows solution, it was blatantly ported to Windows from Linux with a help of the wrappers emulating Linux kernel APIs.

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

"Technically, the WinDRBD Windows driver consists of a thin Linux compatibility layer that emulates the Linux kernel APIs used by the DRBD driver for the Windows platform. Inside this layer, the original DRBD engine (with a few compiler-specific patches) is working."

As a result, WinDRBD has no much clue about what it's doing and what's going on. On initialization it tries to establish a network connection to the partner node and fails because... within Windows kernel ecosystem storage stack starts BEFORE network stack is fully up and running! WinDRBD can't ping the partner node so it assumes something goes wrong and it doesn't bring the storage pool up to preserve it and avoid data corruption.

There are few ways to solve this issue:

1. Put a start dependency for windrbd driver on the NDIS miniport controlling the NICs used by WinDRBD.

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

It's a flaky way actually as changing network adapter will ruin the configuration. + there's a whole bunch of the drivers above NDIS miniport like NDIS filters (firewall?), NDIS protocol drivers (TCP/IP?) etc you don't know much about and you will have to traverse back with a special tools you might be not familiar with.

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

2. Avoid automatic start for WinDRBD and use some logon-dependent script to start it pseudo-automatically. During logon process all the kernel components are ready and in the worst case you can log your unsuccessful driver start issues into some log file, analyze it, script re-tries and so on.

This can be done of course, but it requires some tinkering around with PowerShell. Some good starting points you can get from this discussion thread below.

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

3. Use something designed for Windows from scratch, like f.e. StarWind vSAN Free or Microsoft own SDS builtin with say AzS HCI.

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

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