為什麼 WinDRBD 變成 Diskless/StandAlone（兩個節點）
我有個問題。
目前，此作業系統為 Windows Server 2019。卷配置為 Raid-5。兩台伺服器通過心跳網路連接 兩個節點都使用 WinDRBD 進行鏡像。兩個節點具有相同的配置。我留下了未格式化的 G: 並將 D: 設置為對主節點可見。
我的資源在下面
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; } } }兩個節點都正常工作。測試是通過轉換角色來完成的。（初級→次級/次級→初級）
但是，問題出現在啟動後。
啟動後，狀態顯示如下。（兩個節點）
foo role:Secondary volume:1 disk:Diskless node2 connection:StandAlone我想了很多，搜尋了很多，但找不到答案。
有幾件事我很懷疑。
我想知道是不是因為我在將 G: 字母分配給驅動器之前嘗試過。如果我的想法是正確的，是否有解決方法？
如果是現在我的看法，但是上面的問題還是繼續出現，那是什麼原因呢？
一旦通過以下方式解決。但我想找到原因並準確修復它。
drbdadm down foo drbdadm up foo在此先感謝您的幫助。
WinDRBD 失去心跳，導致您看到的問題。切斷 h/b 的電線，您將輕鬆重現該問題。寫在牆上：至少現在不要在生產中使用 WinDRBD。很脆弱。
@BaronSamedi1958 實際上有一點：WinDRBD 不是原生 Windows 解決方案，它是在模擬 Linux 核心 API 的包裝器的幫助下公然從 Linux 移植到 Windows 的。
https://linbit.com/windrbd-replicated-disk-drives-for-windows/
“從技術上講，WinDRBD Windows 驅動程序包含一個薄的 Linux 兼容層，它模擬 Windows 平台的 DRBD 驅動程序使用的 Linux 核心 API。在這一層內，原始 DRBD 引擎（帶有一些特定於編譯器的更新檔）正在工作。 “
結果，WinDRBD 對它在做什麼以及正在發生什麼一無所知。在初始化時，它嘗試建立與夥伴節點的網路連接並失敗，因為…在 Windows 核心生態系統中，儲存堆棧在網路堆棧完全啟動並執行之前啟動！WinDRBD 無法 ping 合作夥伴節點，因此它假定出現問題並且不會啟動儲存池來保護它並避免數據損壞。
有幾種方法可以解決這個問題：
- 將 windrbd 驅動程序的啟動依賴項放在控制 WinDRBD 使用的 NIC 的 NDIS 微型埠上。
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/specifying-driver-load-order
實際上，這是一種不穩定的方式，因為更改網路適配器會破壞配置。+ NDIS 微型埠上方有一大堆驅動程序，例如 NDIS 過濾器（防火牆？）、NDIS 協議驅動程序（TCP/IP？）等，您不太了解，您將不得不使用您可能會使用的特殊工具進行遍歷不熟悉。
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-driver-stack
- 避免自動啟動 WinDRBD 並使用一些與登錄相關的腳本來偽自動啟動它。在登錄過程中，所有核心組件都準備好了，在最壞的情況下，您可以將不成功的驅動程序啟動問題記錄到一些日誌文件中，對其進行分析，腳本重試等等。
這當然可以完成，但需要對 PowerShell 進行一些修改。您可以從下面的討論執行緒中獲得一些好的起點。
https://stackoverflow.com/questions/27599287/powershell-disable-and-enable-a-driver
- 從頭開始使用為 Windows 設計的東西，例如 fe StarWind vSAN Free 或 Microsoft 自己的內置 SDS，比如 AzS HCI。