De ce WinDRBD devine Diskless/StandAlone (ambele noduri)

Am o intrebare.

În prezent, acest sistem de operare este Windows Server 2019. Configurația volumului este Raid-5. Cele două servere sunt conectate printr-o rețea heartbeat Ambele noduri au fost reflectate folosind WinDRBD. Ambele noduri au aceeași configurație. Am lăsat G: neformatat și am setat D: să fie vizibil pentru nodul primar.

resursa mea sunt mai jos

includ „global_common.conf”;

resursa „foo” {
    protocolul A;

    net {
        use-rle nr;
    }
    pe nodul 1 {
        adresa XXX.XXX.XXX.XXX:7600;
        nod-id 1;
        volumul 1 {
            disc „G:”;
            dispozitiv minor 1;
            meta-disc intern;
        }
    }
    pe nodul 2 {
        adresa XXX.XXX.XXX.XXX:7600;
        nod-id 2;
        volumul 1 {
            disc „G:”;
            dispozitiv minor 1;
            meta-disc intern;
        }
    }
}

Ambele noduri au funcționat normal. Testele au fost finalizate prin schimbarea rolurilor. ( primar â secundar / secundar â primar )

Cu toate acestea, problema a apărut după pornire.

După pornire, starea apare ca mai jos. (ambele noduri)

Rol foo:Secundar
  volum:1 disc:Fără disc
  conexiune nod2: StandAlone

M-am gândit și am căutat mult, dar nu am găsit un răspuns.

Au fost câteva lucruri despre care am fost suspicios.

Mă întreb dacă este pentru că am încercat înainte ca litera G: să fie atribuită unității. Dacă gândirea mea este corectă, există o soluție?

Dacă acum este părerea mea, dar problema de mai sus continuă să apară, care este cauza?

Odată rezolvată în felul următor. Dar vreau să găsesc cauza și să o repar cu exactitate.

drbdadm jos foo
drbdadm up foo

Multumesc anticipat pentru ajutor.

@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