QNAP 高可用性測試：TS-h765eU 兩台裝置實現亞分鐘級故障切換

高可用性已從資料中心的奢侈品變為常規彈性規劃中的一項重要內容。小型企業和邊緣站點現在運行著銷售點系統、監控系統和共享存儲，這些系統每宕機一分鐘都會造成損失，然而傳統的解決方案——雙控制器企業級陣列——其規模和價格是針對數據中心而非分支機構機房或壁掛式機架設計的。這種不匹配導緻小型 IT 部門只能依靠備份和快照來保護數據，而無法保障業務連續性：單控制器 NAS，無論設計多麼精良，仍然是單點故障。

高可用性對 QNAP 來說並非新鮮事物，該公司一直提供雙控制器硬體和基於複製的恢復方案。 QuTS hero h6.0的變革在於效率。全新的高可用性管理器將叢集功能整合到普通硬體的作業系統中，使兩台相同的 NAS 設備能夠在同一個 IP 位址後組成一個主備叢集。這樣，當一台設備發生故障時，另一台設備可以立即接管，客戶端幾乎感覺不到任何變化。對於希望合理配置 IT 投資的企業而言，這意味著只需一台 NAS 設備即可實現高可用性，而無需購買第二套基礎架構。

這就是我們的方案：為了檢驗其在實際應用中的表現，我們在實驗室建立了一個高可用性集群，該集群由兩台配備希捷IronWolf Pro硬碟和QNAP E1.S SSD快取的QNAP TS-h765eU系統組成。然後，我們模擬邊緣節點發生故障的情況，對其進行測試。我們在傳輸過程中斷開了活動節點的電源。我們也斷開了其網路連接，但保持心跳訊號暢通。在這兩種情況下，問題都是一樣的：檔案傳輸能否成功？故障節點恢復後，系統會如何恢復？

QNAP TS-h765eU 概述

TS-h765eU 之所以成為建置高可用性 (HA) 系統的理想選擇，正是因為其硬體相對簡單。這款 1U 短深度機架式 NAS 機箱深度僅為 292.1 毫米（12 吋），專為小型媒體櫃、壁掛式網路機架以及無法安裝全深度機殼的邊緣部署環境而設計。每個單元正面提供四個 3.5 英寸 SATA 硬碟位，背面則配備三個 E1.S/M.2 PCIe NVMe 插槽，使其具備混合存儲特性：機械硬碟提供大容量存儲，閃存則用於緩存或高速存儲。

QNAP 也將其指定為長期供應模式，保證供應至 2031 年，這對跨站點採用統一平台的組織來說非常重要。

TS-h765eU 內部搭載英特爾凌動 x7405C 四核心處理器，最高主頻可達 3.4GHz，配備 8GB DDR5 記憶體（可升級至 16GB），支援 ECC 糾錯。網路連接方面，標配兩個 2.5GbE 端口，可透過將 E1.S 插槽更換為 QNAP 的 QXG-ES10G1T 模組來實現 10GbE 連接。

規格	QNAP TS-h765eU
中央處理器	英特爾凌動 x7405C 四核心處理器，最高主頻 3.4GHz
記憶體應用	8GB DDR5內存，可升級至16GB（內ECC）
驅動器托架	4 個 3.5 英寸 SATA
快閃記憶體插槽	3 個 E1.S / M.2 PCIe NVMe
網路相關	2 個 2.5GbE 端口，可透過可選的 QXG-ES10G1T E1.S 模組實現 10GbE 端口
外形	1U 短深度機架式安裝，深度 292.1 公釐（12 吋）
操作系統	QuTS hero h6.0（基於 ZFS）
庫存情況	2031年之前的長期供應模式

 

本次評估中，每個節點均配備四塊希捷 IronWolf Pro 30TB 硬碟 (ST30000NT011)，組成 RAID 5 儲存池；另配備兩塊 3.84TB QNAP SSD700 E1.S 硬碟 (SSD700D1-003T QNAP SSD700 E1.S 硬碟 (SSD700D1-003T QNAP SSD700 E1.S 硬碟 (SSD700D1-003T84)，組成 RAID 快取。兩個系統均運行 QuTS hero h6.0.0.3500 和 High Availability Manager 2.0.421。

QuTS hero h6.0 和 HA 管理器架構

高可用性管理器是 QuTS hero h6.0 的核心功能，它採用經典的雙主備架構。一台 NAS（活動節點）負責所有資料和服務。另一台 NAS（備用節點）透過專用的心跳連接與活動節點持續同步，隨時準備接手。用戶端無需直接與任何節點通訊；叢集會提供一個統一的 IP 位址和主機名，目前處於活動狀態的節點會回應該位址和主機名。發生故障轉移時，叢集 IP 會重定向後端流量，因此映射磁碟機、iSCSI 發起程式和備份作業無需重新指向。

心跳鏈路是此設計的核心。 QNAP 要求兩個設備之間直接連接，路徑中不能有任何交換機，它承載著健康檢查流量和節點間區塊級資料同步。一個獨立的群集連線則透過普通網路處理面向客戶端的流量。為了進一步防止腦裂，QNAP 也部署了仲裁伺服器，它是網路上的第三個見證節點，可以幫助節點在心跳停止時判斷是否應該提升自身地位。我們將在本文後續部分詳細介紹腦裂及其部署拓樸結構。

QNAP 表示，h6.0 中超過 90% 的 NAS 服務支援高可用性 (HA)，並且叢集可以透過 JBOD 擴充櫃擴展容量。但也有一些限制。 h6.0 的另一個重要功能——不可變快照，目前在 HA 叢集中不受支持，因此管理員暫時需要在兩種保護措施之間做出選擇。此外，HA 還要求兩台系統完全相同，型號和韌體版本必須一致，配對精靈會強制執行此要求，然後才會允許您繼續。

建置 QNAP 高可用性集群

叢集建立從兩台配置相同的 TS-h765eU 設備開始。從指定的活動節點開始，高可用性管理器精靈會引導您完成一個簡短的配對過程。精靈透過心跳連結發現被動節點，然後要求您為網路介面指派角色：叢集連線作為存取叢集的通訊通道，以及心跳連線（QNAP 指出該連線專用於資料同步，並且必須是裝置之間的直接連結）。在我們的配置中，精靈將心跳連結分配給了適配器 1，將群集連接分配給了適配器 2。

接下來是叢集標識。您需要指派叢集主機名稱和叢集 IP 位址，從那時起，客戶端將使用這兩個位址。我們的群集名為 SR-Test，IP 位址為 176.16.248.34，位於節點 QNAP-HA1 (176.16.248.33) 和 QNAP-HA2 (176.16.254.157) 的前端，這兩個位於實驗室網路中不同的節點向實驗室中將它們配對。

設定確認後，精靈會執行五步驟建置流程：設定心跳連線、設定環境、停止服務、設定係統設定以及啟動服務。使用者介面會強調，在此期間請勿關閉任何裝置。在我們的系統中，建置過程本身大約耗時五分半鐘，之後 HA Manager 會報告叢集已創建，並將我們重新導向到叢集 IP 位址。從開始到結束，將兩台獨立的 NAS 設備遷移到服務集群，嚮導運行時間不到十分鐘。

最繁重的任務是初始同步，在此過程中，活動節點會將其儲存池逐塊複製到被動節點。 HA Manager 在儀錶板頂部清楚地顯示了進度條、項目計數和預計時間，並發出警告，提示在同步完成之前，切換和韌體更新將不可用。在此階段觀察心跳統計數據是整個過程中最令人印象深刻的部分之一：傳輸速度從大約 900 MB/s 到 1.2 GB/s 不等，延遲在幾百微秒，其中一個典型讀數是 1 GB/s 時延遲僅為 232 微秒。我們的初始同步大約花了十分鐘完成，與儀錶板最初預估的九分鐘完全吻合。

同步完成後，儀錶板狀態變為“良好”：集群運行正常，心跳已連接，兩個節點均可見，並並排顯示實時 CPU、內存、磁碟吞吐量和網絡統計信息，下方還顯示每個存儲池的同步狀態。這是一個簡潔明了、資訊豐富的視圖，解答了管理員真正關心的兩個問題：叢集是否運作正常？我的資料是否已同步？

故障轉移測試 1：活動節點斷電

我們遇到的第一個故障場景是直接的：活動節點完全斷電。我們啟動了一個 Windows 檔案複製流程，將客戶端上的檔案複製到叢集 IP 位址上的 SMB 共用資料夾，共 41.1GB，包含六個文件，其中包括 Windows 11 和 Rocky Linux 的 ISO 鏡像以及兩個 Kali Linux 虛擬機器歸檔檔案。複製過程中，我們突然斷開了 QNAP-HA1 的電源。

從客戶端的角度來看，從斷電到資料恢復傳輸，複製過程暫停了不到一分鐘（約 50 秒），而 Explorer 始終沒有顯示任何錯誤；傳輸對話方塊保持進度，然後在 QNAP-HA2 升級為活動節點後恢復運作。 HA Manager 短暫地報告了活動節點角色的故障轉移正在進行中，然後彈出一個警告橫幅：無法偵測到被動節點 QNAP-HA1，並建議確保節點已開啟並連接到網路。在叢集僅運行一個節點的情況下，傳輸繼續以全速通過相同的叢集 IP 進行，這正是 HA 所承諾的「降級但仍可運作」的狀態。

QNAP-HA1 恢復供電後，自動觸發了反向過程。該節點在斷電約十分鐘後啟動並以被動成員身份重新加入集群，HA Manager 開始將數據從活動節點 QNAP-HA2 同步回 QNAP-HA1，進度和預計時間同樣顯示在儀錶板上，而我們的文件複製工作則繼續進行，未受任何干擾。故障復原過程無需人工幹預：重新同步完成後，叢集暫停傳輸約 35 秒，將活動角色切換回 QNAP-HA1，然後讓複製工作運作至完成。運行結束時，叢集狀態恢復正常，傳輸進度達到 100%，成功經歷了硬斷電、單節點運行、節點恢復和故障恢復等一系列操作，所有操作均在單次複製任務中完成。

故障轉移測試 2：網路遺失但心跳訊號保持完整

第二種情況更為微妙，也更常見於實際環境中：活動節點失去了面向客戶端的網路連線（例如交換器連接埠故障、網路線脫落或收發器損壞），但節點本身仍在運行，心跳連結也保持暢通。在這種情況下，腦裂保護至關重要，因為兩個節點都處於活動狀態且可以相互通信，而叢集必須決定哪個節點應該擁有叢集 IP 位址。

我們對叢集 IP 重複了相同的 Windows 檔案複製操作，並中斷了活動節點上的叢集網路介面。傳輸暫停了約 45 秒，期間叢集將服務遷移到另一個節點，然後恢復傳輸且未故障。 HA 管理器準確地標記了故障，警告節點上的叢集網路介面適配器 2 已斷開連接，並建議檢查交換器連接。此外，它還進一步指出，斷開連接的節點無法再透過該介面存取仲裁伺服器。這種明確指出具體介面、節點和後果的方式，比某些 HA 實作所採用的通用降級標誌更具診斷性。

重新連接網路後，節點重新加入集群，故障恢復過程在一分鐘內自動完成：在活動角色恢復到 QNAP-HA1 期間，出現了大約 30 秒的第二次暫停，這是客戶端唯一能察覺到任何變化的跡象。同一個複製作業連續經歷了兩次切換，沒有出現任何檔案遺失的情況。對於任何經歷過 SMB 會話因遠小於此的原因而中斷的人來說，這就是本次演練的主要結果。

正確部署高可用性：腦裂和網路拓撲

像我們這樣的故障轉移測試證明了叢集能夠正常運作，但高可用性 (HA) 對在生產環境中的表現不僅取決於 NAS 設備本身，還取決於周圍的網路環境。 HA Manager 設計用於應對各種場景（例如節點故障、交換器連接埠失效、上行鏈路斷開），所有這些場景都基於一個共同的假設：兩個節點之間至少有一條通訊路徑在故障後仍然有效。確保這個假設的有效性是 HA 部署中最關鍵的決策，因為一旦出現問題，就會發生所有高可用性架構都力求避免的狀況：腦裂。

QNAP 對此場景有文件說明。腦裂是指兩個節點彼此失去通信，但仍各自獨立運行，各自扮演主動角色。兩個節點都認為自己擁有集群，都願意接受寫入操作，這會導致資料不一致或儲存損壞，因為它們可能同時嘗試控制共享資源。文件中記錄的原因正如您所預期的那樣：節點間的網路斷開、心跳失敗以及網路路徑不穩定。請注意這些原因的共同點。腦裂並非由單一節點故障觸發；而是由兩個健康節點之間的所有路徑同時失效觸發。這是一個拓樸問題，可以透過拓樸結構問題來解決。

部署規則如預期生效：

將心跳包直接連接到兩個節點。 QNAP要求心跳包必須透過直線連接線傳輸，原因就在於此。由於路徑中沒有交換器、收發器或共享基礎設施，唯一可能導致心跳包中斷的只有節點本身，而這正是事件故障轉移機制的設計初衷。在同機架部署中，這些短深度的 TS-h765eU 設備很可能會並排安裝，因此無需採取其他措施。

如果節點是分離的，請確保心跳和客戶端流量走物理上獨立的路徑。如果直接連接不切實際，則應將心跳路由到與叢集連接不同的交換器上。一旦兩個連接都經過同一交換機，該交換機就會成為單點故障，能夠同時切斷節點間的所有路徑，從而將普通的交換器故障演變成潛在的腦裂事件。如果共用的基礎架構中的某個元件能夠將兩個 NAS 設備彼此隔離，那麼購買兩個 NAS 設備的意義就蕩然無存了。這就是我們網路故障轉移測試方法背後的邏輯：在保持心跳連接的情況下斷開面向客戶端的連接，可以模擬在正確分離的拓撲結構中實際發生的交換機或線纜故障，而心跳連接則能夠確保故障順利轉移。

啟用仲裁伺服器。 QNAP的第三道安全保障是網路上的見證節點，可在「高可用性管理器」>「設定」>「故障轉移原則」>「仲裁伺服器」中進行設定。如果節點失去直接連接但仍能存取網絡，仲裁伺服器會繼續監控所有節點並轉發它們的狀態，從而為每個節點提供一個獨立的仲裁機制，使其在提升自身地位之前進行判定。仲裁伺服器的連線狀態會與心跳訊號一起持續顯示在高可用性管理器控制面板上，因此可以一目了然地了解其運作狀況。

如果最糟糕的情況仍然發生，QuTS hero 會以防禦性的方式處理腦裂問題。一旦連接恢復，節點可以再次通信，它們會交換狀態信息，識別出雙方都曾擔任活動角色，並主動停止大部分服務（包括 SMB 和 iSCSI），以避免合併兩個不同的數據集。然後，HA Manager 會顯示一個「從腦裂中恢復」精靈，其中包含兩條路徑。第一種路徑會保留您選擇的單一節點上的資料；另一個節點將被擦除，重設為被動成員，然後重新同步。如果您知道哪一側擁有正確的數據，這是最快的路徑。第二種路徑會保留兩個節點上的數據，方法是在一個節點上恢復服務，同時將另一個節點完全從叢集中移除，這樣您就可以在手動重新加入叢集之前驗證和協調資料。這是一個合理的恢復模型，但恢復仍然意味著停機和完全重新同步。腦裂是一種可以透過部署設計來預防的情況，而不是需要計劃如何從中恢復的情況。上述三條規則只需要一條網線和五分鐘的設定面板操作即可。

監控和管理

第二天的維運工作在 HA Manager 應用中進行，該應用程式將叢集狀態、每個節點的資源使用、事件日誌和節點管理（包括手動切換）整合到一個統一的介面中。在我們的測試中，儀錶板的警告橫幅足夠具體，能夠準確指出故障的介面和節點，而不是泛泛的降級標誌，從而起到診斷作用。

QNAP 也將高可用性 (HA) 感知功能整合到了硬體本身。在 HA 叢集中，每台 NAS 上的 LCD 面板都可以顯示叢集名稱、節點目前角色和叢集 IP 位址，狀態 LED 指示燈則能一目了然地指示 HA 狀態：綠色常亮表示活動節點，綠色閃爍表示被動節點，紅色常亮表示 HA 錯誤。在充滿相同型號的短深度 NAS 的機架中，無需打開瀏覽器即可識別活動節點，這項貼心的小功能會讓技術人員倍感欣喜。對於叢集部署，AMIZcloud 還提供了 HA 群組的集中式雲端監控，可跨站點顯示叢集運作狀況、延遲和警報資訊。

最後的思考

高可用性管理器在我們測試的兩種故障模式下兌現了其核心承諾。活動節點斷電導致 Windows 檔案複製進程停滯約 50 秒，但沒有遺失任何檔案；用戶端網路連線中斷導致進程停滯約 45 秒。在這兩種情況下，相同的複製作業都能順利完成節點復原和自動故障轉移，最多只出現不到一分鐘的暫停。客戶端無需重新配置任何內容。在故障轉移之前、期間和之後，應用程式、檔案共用和使用者工作流程都透過同一個 IP 位址和主機名稱繼續運作。設定過程也非常方便；兩個獨立單元在不到十分鐘的嚮導引導下，加上十分鐘的初始同步，就組成了一個服務集群。每次發生故障時，控制面板都會準確地告訴我們應該注意哪個介面、節點和連接。

不過，高可用性 (HA) 的成本也不容忽視。您需要購買兩套設備，而備用節點在需要使用之前一直處於閒置狀態。不可變快照（h6.0 的另一項核心保護功能）在目前的 HA 叢集中無法使用，因此管理員必須在兩者之間做出選擇。此外，硬體配置要求必須完全相同，這意味著升級必須成對進行，這可能會限制預算。

最終的解決方案取決於規模是否合適，而HA Manager最適合小型企業和邊緣部署。與雙控制器企業級陣列相比，兩台短深度的TS-h765eU設備在經濟效益方面截然不同，同時還能應對控制器丟失這種故障場景，而這正是大多數中小企業購買雙控制器陣列的主要原因。與DIY複製方案、快照傳輸、rsync作業和備份恢復相比，區別在於恢復時間：這些方案雖然可以保護數據，但需要花費數小時重建客戶端連接，而HA Manager在我們測試中對客戶端而言最嚴重的故障也只是一分鐘的延遲。同樣重要的是，它無法承受的故障（所有節點間路徑同時中斷）可以透過直接連接心跳線、隔離網路路徑以及啟用仲裁伺服器來避免：只需一條網路線和五分鐘的設定面板配置即可完成拓撲調整。

最後一點是針對雙節點設計的：叢集最脆弱的時期是資料重新同步，此時只有一個節點保存著資料的唯一有效副本，而其他節點的硬碟則處於高負載運轉狀態。因此，在HA叢集中，硬碟的選擇至關重要。這也是為什麼我們搭建的NAS專用硬碟（例如Seagate IronWolf Pro 30TB）在雙節點叢集中比在獨立伺服器上更為重要的原因：它們的作用就是確保資料重新同步期間的穩定性。

QNAP TS-h765eU 和 QNAP Hero h6.0 現已上市。欲了解更多信息，請訪問QNAP TS-h765eU 產品頁面。

本報告由QNAP贊助。本報告中所表達的所有觀點和意見均基於我們對所討論產品的客觀評價。