一、WSFC 的偵測邏輯：偏「淺層」
Windows Server Failover Clustering（WSFC，Windows 容錯移轉叢集）判斷節點或服務是否健康，主要依靠以下訊號：
- 作業系統層級的心跳（Heartbeat）：叢集各節點週期性互發網路封包，確認彼此「還活著」。若某節點在一段時間內無回應，WSFC 會認定其失效並轉移服務。
- 服務（Service）是否在執行：透過資源監控（Resource Monitor）檢查所管理的資源（如 SQL Server 服務），常見方式為確認 Process 是否存在，以及 IsAlive / LooksAlive 健康檢查是否通過。
二、問題出在哪裡：「卡死但沒死」
關鍵限制：如果服務「卡死（Hung）」但處理程序（Process）還在，WSFC 可能無法及時察覺並觸發切換。
這就是所謂的「灰色失效（Gray Failure）」或「殭屍狀態」。情境是：
- 資料庫服務的 Process 仍在執行（工作管理員看得到 sqlservr.exe，OS 也正常）。
- 但該服務已無法正常回應請求——可能是執行緒全卡在鎖死（deadlock）、I/O 停滯、記憶體耗盡而無法處理新連線。
從 WSFC 的視角：OS 心跳正常、Process 存在、表面健康檢查可能也勉強通過，因此判定一切正常、不觸發容錯移轉。但對應用程式而言，這個資料庫等同掛掉，因為它根本不回應。
比喻：心跳偵測像是只確認警衛「還有沒有呼吸、人在不在椅子上」。但警衛可能人在、有呼吸，卻睡死了——任何人闖進來都沒反應。光看「活著」這個淺層指標，分不出「清醒能工作」與「昏睡無作為」。
三、WSFC 與 Neverfail 的差異
Neverfail 的設計理念正好補上 WSFC「淺層心跳」的盲點。兩者都做高可用性（HA），但架構哲學完全不同。
核心差異一：偵測的「深度」
WSFC 偏基礎設施層級（OS 心跳、服務存活、Process 存在），服務卡死但 Process 還在時容易漏判。Neverfail 則走應用程式感知（Application-Aware）路線，代理程式會主動探測應用程式的實際反應能力，因此對「殭屍／卡死」狀態的偵測正是其設計目標。（有趣的是，Neverfail 早期核心產品就叫 Neverfail Heartbeat，但它的「心跳」探得比 WSFC 深得多。）
核心差異二：資料的共享 vs 複製
這是架構上最根本的分野。WSFC 傳統上是「多台主機搶用同一份資料」；Neverfail 是「每台主機各有一份，靠即時複製保持同步」。
| 比較面向 | WSFC（傳統叢集） | Neverfail |
| 偵測深度 | OS 心跳、服務存活、Process 是否存在（偏淺層） | 應用程式感知，主動探測實際反應能力 |
| 卡死（Hung）偵測 | Process 還在時容易漏判 | 設計目標即可偵測殭屍/卡死狀態 |
| 儲存架構 | 多節點共享儲存（SAN）或 S2D | 無共享儲存，採即時資料複製 |
| 資料副本 | 共享磁碟只有一份資料 | 主機／備機各有獨立副本 |
| 單點故障 | 共享儲存本身可能成為單點故障 | 無共享儲存的單點風險 |
| 地理分散 / DR | 跨站台較複雜（需延伸式叢集） | 天生支援跨站點（WAN）複製 |
| 產品定位 | Microsoft 內建、免費、與 OS 深度整合 | 第三方商業軟體，主打持續可用性 |
核心差異三：產品定位
WSFC 是 Microsoft 內建於 Windows Server 的功能，免費、與 OS 深度整合，但綁定 Windows 生態，原生偵測能力較淺。Neverfail 是第三方商業軟體，主打「持續可用性（Continuous Availability）」，強調以較簡單的架構（不需 SAN、不需企業版叢集授權）達到應用層級的保護，常見於保護 Exchange、SQL Server、檔案伺服器等。
四、整體理解
- WSFC 回答的是「這台機器／這個服務還在不在?」——著重基礎設施可用性。
- Neverfail 想回答的是「這個應用程式還能不能正常服務使用者?」——著重應用程式可用性，且因走複製架構，同時也是一套 DR（災難復原）方案。
兩者並非單純「誰比較好」，而是保護層次不同。實務上也有人把 WSFC 用於資料庫叢集（搭配 SQL Server Always On 補強偵測），把 Neverfail 用在不適合做叢集、但又需要應用層保護與異地複製的系統。
備註：Neverfail 為商業產品，其具體功能與支援的應用程式版本可能隨版本更新而變動；實際導入評估時應參考其最新產品線與支援矩陣。