Почему WinDRBD становится бездисковым/автономным (оба узла)

У меня есть вопрос.

В настоящее время этой ОС является Windows Server 2019. Конфигурация тома — Raid-5. Два сервера соединены пульсирующей сетью. Оба узла были зеркалированы с помощью WinDRBD. Оба узла имеют одинаковую конфигурацию. Я оставил неформатированный G: и установил D: так, чтобы он был виден основному узлу.

мой ресурс ниже

включить "global_common.conf";

ресурс "foo" {
    протокол А;

    сеть {
        использовать-rle нет;
    }
    на узле1 {
        адрес XXX.XXX.XXX.XXX:7600;
        идентификатор узла 1;
        том 1 {
            диск "Г:";
            устройство минор 1;
            метадиск внутренний;
        }
    }
    на узле2 {
        адрес XXX.XXX.XXX.XXX:7600;
        идентификатор узла 2;
        том 1 {
            диск "Г:";
            устройство минор 1;
            метадиск внутренний;
        }
    }
}

Оба узла работали нормально. Испытания завершались обменом ролями. ( первичный -- вторичный / вторичный -- первичный )

Однако проблема возникла после загрузки.

После загрузки статус выглядит следующим образом. (оба узла)

foo роль:Вторичная
  объем: 1 диск: бездисковый
  соединение node2: автономный

Я много думал и искал, но не мог найти ответ.

Было несколько вещей, в отношении которых я сомневался.

Интересно, это потому, что я пытался до того, как буква G: была назначена диску. Если мои мысли верны, есть ли обходной путь?

Если теперь это мое мнение, но вышеуказанная проблема продолжает возникать, в чем причина?

Когда-то она решалась следующим образом. Но хочется найти причину и точно ее устранить.

drbdadm вниз foo
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