Tại sao WinDRBD trở thành Diskless/StandAlone (cả hai nút)

Tôi có một câu hỏi.

Hiện tại, hệ điều hành này là Windows Server 2019. Cấu hình âm lượng là Raid-5. Hai máy chủ được kết nối bởi một mạng nhịp tim Cả hai nút đều được sao chép bằng WinDRBD. Cả hai nút có cùng cấu hình. Tôi để G: không được định dạng và đặt D: hiển thị với nút chính.

tài nguyên của tôi ở bên dưới

bao gồm "global_common.conf";

tài nguyên "foo" {
    giao thức A;

    bọc lưới {
        sử dụng-rle không;
    }
    trên nút1 {
        địa chỉ XXX.XXX.XXX.XXX:7600;
        nút-id 1;
        tập 1 {
            đĩa "G:";
            thiết bị phụ 1;
            meta-đĩa nội bộ;
        }
    }
    trên nút2 {
        địa chỉ XXX.XXX.XXX.XXX:7600;
        nút-id 2;
        tập 1 {
            đĩa "G:";
            thiết bị phụ 1;
            meta-đĩa nội bộ;
        }
    }
}

Cả hai nút hoạt động bình thường. Các bài kiểm tra đã được hoàn thành bằng cách chuyển đổi vai trò. ( chính â phụ / phụ â chính )

Tuy nhiên, sự cố xảy ra sau khi khởi động.

Sau khi khởi động thì xuất hiện tình trạng như bên dưới. (cả hai nút)

vai trò foo: Trung học
  khối lượng: 1 đĩa: Diskless
  kết nối node2: Độc lập

Tôi đã suy nghĩ và tìm kiếm rất nhiều, nhưng không thể tìm ra câu trả lời.

Có một vài điều tôi đã nghi ngờ về.

Không biết có phải do mình thử trước khi chữ G: được gán cho ổ không. Nếu suy nghĩ của tôi là chính xác, có một cách giải quyết?

Nếu bây giờ theo ý kiến ​​của tôi mà vấn đề trên vẫn tiếp tục xảy ra thì nguyên nhân do đâu?

Một khi nó đã được giải quyết theo cách sau. Nhưng tôi muốn tìm ra nguyên nhân và khắc phục nó một cách chính xác.

drbdadm xuống foo
drbdadm lên foo

Cảm ơn trước sự giúp đỡ của bạn.

@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