- 虛擬化伺服器的高可用性結合了叢集、複製和冗餘存儲，以最大限度地減少停機時間。
- RHEL、Hyper-V、HA-DAS 和 QNAP 等 NAS 解決方案根據規模、預算和需求提供不同的高可用性方法。
- 災難復原複製並不能取代真正的高可用性：自動且幾乎無縫的故障轉移需要近乎即時的同步。
- 合理設計架構並滿足硬體、網路和軟體要求是確保服務連續性的關鍵。
對於任何無法承受即使幾分鐘服務中斷的組織而言，虛擬化伺服器的高可用性已成為一項基本要求。我們指的是，即使實體伺服器、磁碟、網路甚至整個資料中心發生故障，也能確保您的虛擬機器、應用程式和資料仍然可存取。這不僅僅是備份的問題，而是要確保服務始終運行，不受任何影響。
當我們將虛擬化、叢集、儲存和災難復原結合起來時，會湧現出許多技術（例如 KVM、Xen、Hyper-V、RHEL HA、RHEV、CSV、NAS、JBOD、副本等），而如何選擇或整合所有這些技術並非總是顯而易見的。本文將深入探討主要的選項和方法：從採用共享儲存的傳統叢集到基於節點間即時複製的現代解決方案，並提供 Red Hat、Microsoft Hyper-V、QNAP 和 HA-DAS 架構的具體範例。
虛擬化環境中高可用性的基本概念
在虛擬化環境中，高可用性 (HA) 指的是即使一個或多個系統元件（伺服器、磁碟、控制器、網路、電源等）發生故障，虛擬機器仍然可存取。這與災難復原 (DR) 不同：HA 的目標是將停機時間降至最低或接近零，而 DR 通常允許一定的停機時間，以便從備份中復原服務。
為了實現這種效能，系統結合了多個元件：硬體冗餘、叢集軟體、容錯儲存以及監控和故障轉移機制。其目標是避免單點故障：如果一個組件發生故障，另一個組件會自動接管，無需人工幹預（或只需極少干預）。
在虛擬化領域，這通常意味著擁有多個共享或複製儲存的實體主機，以及監控節點和虛擬機器狀態的系統。當一台主機發生故障時，虛擬機會在另一台主機上啟動，理想情況下，使用者不會察覺到這個過程，或只會經歷極短的中斷。
區分專為彈性「類雲」環境設計的解決方案和傳統的高可用性平台也至關重要。某些叢集產品配置相對靜態，最大節點數也相對較低，因此不適合建置大規模雲，但它們非常適合保護一組定義明確的關鍵服務。
在雲端或混合環境中，建議審查具體的遷移和連續性策略：例如，雲端遷移可以作為災難復原策略的一部分，但它不能取代本地高可用性。
在 Red Hat Enterprise Linux 和 KVM/Xen 平台上實現高可用性
紅帽生態系統提供了多種使用叢集和高可用性插件來保護虛擬機器的方案。紅帽企業Linux 5和6等版本支援各種虛擬機器管理程式和叢集插件的組合。
RHEL 5 支援兩個虛擬化平台：Xen（從 RHEL 5.0 開始）和 KVM（從 RHEL 5.4 開始）。 RHEL 5 進階平台 (AP) 叢集附加元件可讓您將 Xen 和 KVM 虛擬機器作為叢集資源進行管理，從而使主機的高可用性基礎架構能夠控制節點間虛擬機器的啟動、關閉和故障轉移。
RHEL 6 簡化了虛擬化支援：僅支援 KVM 作為虛擬機器管理程式。但是，RHEL 6 高可用性插件仍然允許將 KVM 虛擬機器視為叢集資源，由主機的 HA 基礎架構進行管理。叢集資源管理器（經典版本中為 rgmanager）負責監控節點，並在偵測到故障時將虛擬機器遷移到不同的實體伺服器。
這種方法通常被稱為「運行在實體主機上的 RHEL 叢集/高可用性 (HA)，實體主機充當虛擬化平台」。 RHEL 叢集本身管理每個虛擬機器的運作位置，並在節點發生故障時接管，確保配置為關鍵的虛擬機器在健康的宿主機器上重新啟動。
一個有趣的方面是，從叢集的角度來看，虛擬機器的客戶作業系統並不那麼重要。在RHEL中，任何與Xen或KVM相容的客戶作業系統都可以被視為高可用性虛擬機器：不同版本的RHEL（3、4、5等）和各種版本的Microsoft Windows，只要它們受到虛擬機器管理程式的支援即可。這在保護混合環境時提供了相當大的靈活性。
然而，紅帽公司本身也建議，在選擇使用RHEL 高可用性附加元件還是更全面的虛擬化平台（例如紅帽企業虛擬化 (RHEV)）來為虛擬機器提供高可用性時，應謹慎行事。兩者都提供高可用性功能，但使用場景不同，必須考慮環境規模和運作模式。
何時使用 RHEL HA 而不是 RHEV 來實現高可用性
在決定是否使用RHEL HA 附加元件或 RHEV 等平台來保護虛擬機器時，關鍵標準之一是實體主機的數量以及虛擬化環境的使用類型。
RHEL 的高可用性附加元件專為規模相對較小、靜態配置的叢集而設計。傳統上，這類叢集的實體節點數量上限約為 16 個，這對於許多企業環境來說已經足夠，但並不適用於擁有數十甚至數百個不斷變化的主機的雲端架構。
因此，紅帽官方文件指出，不建議僅使用 RHEL HA 來建構類雲基礎設施，原因就在於其靜態特性和節點數量限制。對於雲端場景，使用專為此模型設計的平台更為合理，這些平台應具備更彈性、可擴展的資源管理器。
另一方面，如果目標是在一組定義明確的主機上保護數量適中的關鍵虛擬機，RHEL 的 HA 附加元件是一個強大的解決方案：它與作業系統整合良好，依賴成熟的叢集技術，並提供了必要的邏輯來監控虛擬機並在發生故障時遷移虛擬機。
總之，建議查閱最新的 RHEL 文檔，以了解支援的客戶作業系統、虛擬機器管理程式和叢集組合，因為支援會隨著每個版本的發布而不斷發展，因此遵循官方矩陣非常重要。
Hyper-V 中的高可用性：叢集、副本和即時遷移
在微軟環境中，高可用性主要基於Hyper-V 的功能以及 Windows Server 故障轉移群集。其目標是即使在發生硬體故障、網路問題或軟體錯誤的情況下，也能持續存取虛擬機器。
核心組件是Hyper-V 故障轉移群集。這種叢集由一組共享儲存並以協同方式工作的伺服器（節點）組成：如果一個節點發生故障，其上執行的虛擬機器將自動在叢集中的另一個節點上重新啟動。這一切都由共享磁碟技術和特定的內部通訊機制所支援。
為了實現這一點，節點通常透過儲存區域網路 (SAN) 或橫向擴展檔案伺服器 (SOFS) 共用儲存。然後在此層之上建立叢集共用磁碟區 (CSV)，從而允許所有節點同時存取虛擬機器檔案所在的相同磁碟。
各個節點也透過一個名為集群心跳的專用網路進行通訊。該網絡獨立於生產數據網絡，允許每個伺服器報告其運行狀態。如果叢集停止接收來自某個節點的心跳訊號，則該節點被視為發生故障，並啟動故障轉移程式。
另一個基本要素是仲裁配置。仲裁定義了叢集必須有多少個活躍的投票節點（或外部見證節點）才能繼續運作。這可以防止「腦裂」情況的發生，即孤立的節點組錯誤地認為自己是主集群，從而導致資料損壞。選擇合適的仲裁模型（節點、磁碟見證節點、檔案共享見證節點等）是確保穩定性的關鍵。
基於此，Hyper-V 利用叢集功能，以最小的停機時間實現虛擬機器在節點間的即時遷移。在維護或負載平衡期間，虛擬機器可以從一台主機遷移到另一台主機，而不會中斷服務，記憶體、狀態和活動連線都能透明地傳輸。
如果某個節點並非因計畫內維護而發生實際的硬體或軟體故障，叢集就會執行自動故障轉移。運行在該節點上的虛擬機器將部署到另一台可以存取相同共用儲存的主機上。雖然這種故障轉移比即時遷移造成的中斷更大（虛擬機器需要重新啟動），但只需極少的人工幹預即可維持服務的連續性。
除了經典的 SAN 叢集之外，Hyper-V 還融合了其他專注於高可用性和災難復原的技術，特別是Hyper-V 副本和無需共用儲存的即時遷移。
Hyper-V 複製是一種非同步虛擬機器複製功能，它將虛擬機器在主主機和一個或多個副本主機之間進行複製，這些副本主機通常位於不同的網站或資料中心。系統會定期將變更傳送到目標虛擬機，從而建立復原點，以便在主站點發生災難時將虛擬機還原到最近的狀態。
此機制使用Hyper-V 複製代理程式來協調複製流量、管理復原點並集中管理故障轉移操作。它既支援計劃內故障轉移（例如，將生產環境遷移到另一個站點），也支援計劃外故障轉移（當主站點意外宕機時）。
由於其非同步特性，複製更側重於災難復原 ( DR)，而非近乎零停機時間的高可用性 (HA)。發生故障後，必須在副本虛擬機器上啟動故障轉移。儘管該過程相當靈活，但仍會造成一定的停機時間，並且可能會丟失最後幾秒鐘或幾分鐘的數據，具體取決於配置的複製間隔。
同時，Hyper-V 提供「無共享」即時遷移功能，讓您在不共享儲存的主機之間遷移虛擬機器。在這種模式下，每台主機都有自己的本地存儲，實時遷移會在虛擬機保持在線的情況下，透明地將虛擬機的磁碟複製到目標位置，然後將執行切換到新伺服器。
此功能在沒有SAN或共享儲存基礎架構的環境中特別實用，可降低中小企業的前期成本，或適用於不宜維護專用儲存網路的場景。例如，它允許在不關閉現有機器的情況下，以最小的影響重新組織主機或遷移到新硬體。
這些技術（故障轉移叢集、CSV、有或沒有共用儲存的即時遷移和 Hyper-V 複製）的結合，為設計業務連續性和容錯策略提供了廣泛的選擇，可根據不同的預算和需求等級進行客製化。
採用 HA-DAS 和 Windows Server 的高可用性解決方案
除了大型 SAN 環境之外，還有一些架構專為直接連接到伺服器的儲存系統的高可用性而設計（HA-DAS）。這些解決方案利用 Windows Server（例如 2012）和進階 RAID/HBA 控制器來提供高可用性集群，而無需設定傳統的 iSCSI 或 FC SAN。
這種方法使用兩個高可用性叢集節點，共享 JBOD 儲存（即一組磁碟，沒有任何內建智慧）。 JBOD 透過冗餘主機 RAID HBA 控制器連接到兩台伺服器，因此每個節點都能看到相同的磁碟集，並且可以同時存取同一個 RAID 陣列。
這些解決方案可在共用機殼內實現高達 180 TB的儲存容量，並支援不同 RAID 等級的熱插拔硬碟或固態硬碟。 RAID 控制器通常每個都整合 1 GB 緩存，快取資料在控制器間鏡像同步以保持一致性並提升效能，快取保護則採用超級電容而非傳統電池。
控制器之間的通訊通常透過SAS 連結進行，無需使用心跳乙太網路連結進行磁碟狀態同步。這在兩個儲存節點之間提供了一條直接且高度可靠的通訊路徑。
另一個重要特性是，這些架構通常在同一 RAID 陣列上以雙活模式運作。這意味著兩個節點同時提供服務，並充分利用兩台伺服器的運算能力，而不是像雙活模式那樣，讓一個節點處於「待機」狀態，直到另一個節點發生故障。這樣可以避免像雙活集群那樣浪費高達 50% 的硬體投資。
基於Windows Server 2012 （或更高版本）構建，管理員可以利用熟悉的管理環境：熟悉的工具、精靈、管理控制台和權限模型。學習時間得以最大程度地縮短，從而降低實施過程中的營運成本和風險。
這些高可用性分散式應用系統 (HA-DAS) 解決方案針對多種應用情境：Hyper-V 伺服器虛擬化、Windows VDI、SAN/NAS 儲存、交易資料庫 (OLTP)、資料倉儲和高可用性 Web 服務。所有這些都是透過利用單一共享記憶體機箱、兩個冗餘節點和 Windows 叢集邏輯來實現的。
專為 QNAP NAS 陣列和 Virtualization Station 4 設計的高可用性
在NAS領域，像QNAP這樣的廠商開發了先進的功能，以實現儲存和其設備上託管的虛擬機器的高可用性。具體來說，他們將基於ZFS的QuTS hero作業系統與Virtualization Station 4結合，從而在兩台NAS設備之間提供即時複製和故障轉移功能。
一方面，QuTS hero 系統將高可用性 ( HA) 技術整合到 NAS 本身，允許將兩台相同（或類似）的設備配置為高可用性對。如果一台 NAS 發生故障，另一台會接管，確保服務持續運作。這既保護了存儲，也保護了 NAS 的核心服務。
在此基礎上，Virtualization Station 4 中的新高可用性功能（在最近的版本中以測試版形式提供）更進一步：它允許在 NAS 上運行的虛擬機器透過在兩個 QNAP 設備之間進行即時複製來實現高級容錯能力。
此功能僅適用於執行 QuTS hero 和對應版本 Virtualization Station 4 的配備 x86 處理器的 QNAP NAS 裝置。使用 ZFS 和 SnapSync 技術至關重要，因為它可以即時同步兩個 NAS 設備之間的虛擬機器數據，確保複製的虛擬機器始終保持最新狀態。
此運行方案基於兩台相互備份的NAS設備：NAS A和NAS B互為雙向備份節點。每台NAS都可以運行自己的虛擬機，對於標記為高可用性（HA）保護的虛擬機，會在另一台NAS上建立副本。如果其中一台設備發生故障，另一台設備將接管控制權並啟動受影響的虛擬機器。
這實現了NAS伺服器的無縫切換。高可用性（HA）保護可以僅針對特定的關鍵虛擬機器啟用，而不會影響其他NAS服務（例如備份、檔案共用等）。每個NAS都可以在保護指定用於高可用性的虛擬機器的同時，繼續執行其原始功能。
基於 SnapSync 的即時同步技術確保在發生故障時，故障轉移幾乎是瞬間完成且不會遺失資料。與依賴中央共用儲存區域 (SAN) 的傳統架構不同，此解決方案消除了單點故障：每個 NAS 都維護其所保護虛擬機器的完整且一致的副本。
此外，QNAP 定義了多種可觸發故障轉移的故障情況：例如，CPU 長時間過載（例如，超過特定閾值一段時間，例如 80%）、系統溫度過高、即使在 RAID 配置下也可能發生磁碟故障、冗餘電源之一失效等等。系統會評估這些情況，如果 NAS 被認為不可靠，則會將負載轉移到另一個節點。
該系統還提供手動遷移選項，當技術團隊希望以可控的方式將虛擬機器遷移到另一個 NAS 以執行維護任務（例如更換磁碟、更新韌體、更改高級設定等）時，此功能非常有用。遷移速度非常快（不到一秒），使用戶幾乎感覺不到遷移過程。
另一個值得關注的點是，它無需額外的授權費用：Virtualization Station 4 的高可用性功能是應用程式本身的一部分，包含在系統中，而無需為每個節點或虛擬機器支付額外費用。這使其對尋求以合理成本實現高可用性的中小企業和環境極具吸引力。
QNAP高可用性的要求和限制
要成功在 QNAP 上部署此解決方案，必須滿足一定的軟體、硬體和網路要求。這些要求並不十分複雜，但在設計環境之前，請務必清楚了解這些要求。
軟體方面，需要QuTS hero 版本 h5.3 或更高版本以及 Virtualization Station 4.1 或更高版本。只有這些版本包含基於 SnapSync 的虛擬機器高可用性 (VM HA) 功能。此功能在搭載「經典」QTS 或更早版本 Virtualization Station 的 NAS 裝置上不可用。
在硬體層面，兩台NAS設備不必是完全相同的型號，但它們必須使用相同架構和品牌的處理器（要么都是Intel，要么都是AMD）。這簡化了相容性，並確保複製的虛擬機器可以在任一裝置上流暢運作。
在網路方面，至關重要的是，兩台NAS設備必須位於同一網段，並且它們之間必須使用專用的實體網路線進行直接連接，以實現虛擬機器資料同步。這條專用鏈路充當「帶外」複製通道，從而避免干擾正常的用戶流量。
實際上，硬體的實際要求可以歸結為：使用同一系列的 CPU，並且 NAS 設備之間需要直接連接。其他所有配置（磁碟容量、記憶體等）都根據需要保護的虛擬機器數量和預期效能進行擴充。如果滿足這些條件，QNAP 的高可用性 (HA) 設定就相對簡單且非常穩定可靠。
虛擬機器中高可用性與簡單複製/災難復原的區別
虛擬機器複製解決方案作為一種災難復原機制，常常被誤認為是真正意義上的零停機（或極短停機）高可用性。兩者都很重要，但它們解決的是不同的問題。
例如，在 VMware vSphere 環境中，通常會將虛擬機器複製到災難復原 (DR) 站點，以便將主伺服器的磁碟映像複製到災難復原節點。這可以防止主站點完全遺失，但當主站點發生故障時，通常需要手動復原：在 DR 站點啟動虛擬機器、重新配置網路、驗證資料完整性等等。
雖然該流程可以部分自動化，但根據環境和內部流程的複雜程度，停機時間可能從幾分鐘到幾小時不等。這是一種優秀的災難復原策略，但無法達到嚴格意義上的高可用性解決方案所期望的近乎持續可用性的目標。
真正的高可用性需要一種自動或近乎自動的故障轉移機制，能夠將停機時間降至最低，並且在組件發生故障時無需進行複雜的手動操作。此外，活動節點和備份節點之間的資料同步必須足夠緊密，以防止或最大程度地減少近期資訊的遺失。
因此，在設計高可用性虛擬機器環境時，必須合理結合叢集技術、近即時複製、冗餘儲存和主動監控。只有這樣，即使整個伺服器或NAS突然關閉，使用者也能以最小的中斷繼續存取網站、資料庫或企業應用程式。
在實踐中，最常見的做法是將本地高可用性（例如，同一資料中心內的叢集）與位於不同站點的災難復原策略相結合。這樣，既可以應對日常故障（磁碟、伺服器、電源等），也可以應對更嚴重的事件（火災、長時間停電、自然災害）。
這些豐富的解決方案——包括 RHEL 和 Hyper-V 叢集、無 SAN 的 HA-DAS 架構、基於 QNAP NAS 和 Virtualization Station 的專用高可用性方案以及高級虛擬機複製——表明，現在可以設計出高度容錯的虛擬化環境，以滿足不同規模和預算的企業需求。深入了解每種方案之間的差異、限制（例如最大節點數或共享儲存需求）以及技術要求，是選擇合適組合併確保關鍵服務近乎無縫運行的關鍵。
