上下文
您已經決定在設計或修改基礎結構層時使用羣集以提供高度可用的服務。
問題
您應該如何設計一個高度可用的基礎結構層，來防止因單臺服務器或它所運行的軟件出現故障而導致的服務丟失？
影響因素
在設計高度可用的基礎結構層時，請考慮下列影響因素：
硬件組件、應用程序或服務出現故障可以使應用程序無法使用或不可用。 例如，設想一臺正在提供應用程序的服務器出現了電源故障。 如果這是唯一的服務器或服務器中的唯一電源，則存在故障單點，並且應用程序將不可用。
計劃內的服務器停機時間可以影響應用程序的可用性。 例如，如果要更新無備用服務器的一臺數據庫服務器上的操作系統，您可能必須停止應用程序運行才能在服務器上安裝修補程序。
監視和維護多服務器層增加了對系統和網絡資源的要求。
使用故障轉移羣集的應用程序可能需要特殊的編碼，以確保發生故障時故障轉移過程對用戶是透明的，並且應用程序仍然可用。 例如，如果在用來將數據保存到數據庫的代碼中放置超時和重試，則可確保在發生故障轉移時事務將會完成。
解決方案
將 應用程序或服務安裝在配置爲發生故障時彼此接管對方工作的多臺服務器上。 一臺服務器接管發生故障的服務器的過程通常稱爲"故障轉移"。 故障轉移羣集是一組這樣配置的服務器：如果一臺服務器變爲不可用，則另一臺服務器自動接管發生故障的服務器並繼續處理任務。 羣集中的每臺服務器將羣集中至少一臺其他服務器確定爲其備用服務器。
檢測故障
要讓備用服務器變成活動服務器，它必須設法確定活動服務器不再正常工作。 通常，系統使用下列某個常規類型的心跳機制來做到這一點：
發送信號。 對於發送信號，活動服務器以定義好的時間間隔將指定信號發送到備用服務器。 如果備用服務器在某個時間間隔內未收到信號，則確定活動服務器發生了故障並取得活動角色。 例如，活動服務器每隔 30 秒將狀態消息發送到備用服務器。 由於內存泄漏，活動服務器最終用盡內存，然後崩潰。 備用服務器注意到在 90 秒（三個時間間隔）內未收到任何狀態消息，因此它會接管活動服務器的工作。
接收信號。 對於接收信號，備用服務器向活動服務器發送請求。 如果活動服務器沒有響應，則備用服務器按特定次數重複發送此請求。 如果活動服務器仍然沒有響應，則備用服務器接管活動服務器的工作。 例如，備用服務器可能每隔一分鐘將 getCustomerDetails 消息發送到活動服務器。 由於內存泄漏，活動服務器最終崩潰。 備用服務器發送 getCustomerDetails 請求三次，但未收到響應。 此時，備用服務器將接管活動服務器的工作。
羣集可以使用多個級別的信號。 例如，羣集可以在服務器級別使用發送信號，並在應用程序級別使用一組接收信號。 在此配置中，每當活動服務器啓動並連接到網絡時它都將心跳消息發送到備用服務器。 這些心跳消息是按比較頻繁的時間間隔（例如每隔 5 秒）發送的，而備用服務器可能通過編程設置爲如果僅僅未收到兩個心跳消息，它就接管活動服務器的工作。 也就是說，在活動服務器發生故障後不超過 10 秒的時間內，備用服務器將檢測到這一故障並啓動備用進程。
相當常見的情況是，信號是通過專用通信通道發送的，以便網絡擁塞和一般網 絡問題不會導致假的故障轉移。 此外，備用服務器可能將查詢消息發送到運行在活動服務器上的一個或多個關鍵應用程序，並在指定的超時間隔內等待響應。 如果備用服務器收到正確的響應，則它不採取任何進一步行動。 爲了將對活動服務器的性能影響減少到最小，應用程序級別的查詢通常要經過比較長的時段，如每隔一分鐘或更長。 備用服務器可能通過編程設置爲：一直等到至少已經發送五次請求但未收到響應，然後才接管活動服務器。 這意味着，可能在長達 5 分鐘之後，備用服務器纔會啓動故障轉移進程。
同步狀態
備用服務器必須首先將其狀態與發生故障的服務器的狀態進行同步，然後才能開始處理事務。 主要有三種不同的同步方法：
事務日誌。 在 事務日誌方法中，活動服務器將其狀態的所有更改記錄到日誌中。 一個同步實用工具定期處理此日誌，以更新備用服務器的狀態，使其與活動服務器的狀態一致。 當活動服務器發生故障時，備用服務器必須使用此同步實用工具處理自上次更新以來事務日誌中的任何添加內容。 在對狀態進行同步之後，備用服務器就成爲活動服務器，並開始處理事務。
熱備用。 在熱備用方法中，將把活動服務器內部狀態的更新立即複製到備用服務器。 因爲備用服務器的狀態是活動服務器狀態的克隆，所以備用服務器可以立即成爲活動服務器，並開始處理事務。
共享存儲。 在共享存儲方法中，兩臺服務器都在共享存儲設備（如存儲區域網絡或雙主機磁盤陣列）上記錄其狀態。 這樣，因爲不需要進行狀態同步，故障轉移可以立即發生。
確定活動服務器
對 於指定的一組應用程序，只存在一臺活動服務器，這是極其重要的。 如果多臺服務器都像是活動服務器，則通常會導致數據損壞和死鎖。 解決此問題的常見方法是使用"活動令牌"概念的某個變體。 令牌在其最簡單級別上是一個標誌，用來將服務器標識爲某個應用程序的活動服務器。 對於每組應用程序來說，只存在一個活動令牌；因此，只有一臺服務器可以擁有令牌。 當服務器啓動時，它會驗證其合作伙伴是否擁有活動令牌。 如果擁有，則該服務器將作爲備用服務器啓動。 如果它未檢測到活動令牌，則它會取得活動令牌的所有權，並作爲活動服務器啓動。 當備用服務器成爲活動服務器時，故障轉移進程將把活動令牌交給備用服務器。
在大多數情況下，當備用服務器成爲活動服務器時，對於它正在支 持的應用程序或用戶來說，它是透明的。 如果在事務過程中發生了故障，則可能必須重試該事務以使其成功完成。 這就使編寫應用程序代碼時使故障轉移進程保持透明顯得更爲重要。 這樣做的一個示例是，在將數據提交到數據庫時，包括重試和超時。
此外， 大多數服務器使用 Internet 協議 (IP) 地址進行通信，因此，爲了使故障轉移成功，基礎結構必須能夠支持將 IP 地址從一臺服務器轉移到另一臺服務器。 比如，可以使用能夠支持 IP 地址轉移的網絡交換機。 如果系統基礎結構不支持這一轉移功能，則您可能需要使用負載平衡羣集，而不是故障轉移羣集。 有關詳細信息，請參閱Load-Balanced Cluster 模式。
擴展故障轉移羣集服務器
故障轉移羣集中的可伸縮性通常是通過擴展羣集內的單個服務器，或向其中添加更多功能來實現的。 瞭解以下兩點是很重要的：故障轉移羣集必須設計爲處理預期負載，各個服務器的大小應當能夠適應 CPU、內存和磁盤使用的預期增長。 Failover Cluster 服務器通常是高端多處理器服務器，並且它們被配置爲使用多個冗餘子系統來獲得高可用性。 如果解決方案的資源要求超過了羣集中服務器的限制條件，則擴展羣集將是極其困難的。
示例
爲了幫助您更好地瞭解如何使用故障轉移羣集來實現高可用性，下面的討論分步演示瞭如何將已經實現的基本解決方案（它包含單個系統，即故障單點）重構爲高度可用的解決方案。
非故障轉移解決方案
一開始，組織可能只有基本解決方案體系結構（例如，圖 1 中略述的體系結構）。雖然該解決方案可能滿足最初的可用性要求，但是某些因素（如用戶數的增長或需要應用程序停機時間更短）可能迫使您對設計進行更改。
圖 1:具有故障單點的非故障轉移解決方案
在圖 1 中，數據層僅包含一臺爲應用程序層提供服務的數據庫服務器 (Database10)。 如果數據庫服務器或它運行的軟件發生故障，則應用程序服務器將不再能夠訪問用來爲客戶端提供服務的數據。 這將使應用程序對客戶端不可用。
故障轉移羣集解決方案
爲 了提高解決方案的可用性，組織可能決定消除數據層中的單個數據庫服務器造成的潛在故障單點。 爲此，可以將服務器添加到數據層，並利用現有數據庫服務器、新服務器和共享存儲設備創建故障轉移羣集。 在說明該更改的圖 2 中，羣集由連接到共享存儲陣列的兩臺服務器組成。
圖 2:具有故障轉移數據層的解決方案
第 一臺服務器 (Database01) 是處理所有事務的活動服務器。 僅當 Database01 發生故障時，處於空閒狀態的第二臺服務器 (Database02) 纔會處理事務。 羣集將一個虛擬 IP 地址和主機名 (Database10) 在客戶端和應用程序所使用的網絡上公開。
注意：您可以將此設計擴展爲包括多臺活動服務器（除了所示的服務器外），要麼使它們共享單個備用服務器，要麼將每個活動服務器配置爲另一個活動服務器的備用服務器。
結果上下文
Failover Cluster 模式具有的優缺點：
優點
適應計劃內的停機時間。 故障轉移羣集可以允許系統有停機時間，而不會影響可用性。 這樣，就適應了日常的維護和升級需要。
減少計劃外停機時間。 故障轉移羣集通過消除系統和應用程序級別上的故障單點，減少了與服務器和軟件故障有關的應用程序停機時間。
缺點
會增加響應時間。 對於故障轉移羣集設計來說，由於備用服務器上的負載增長，或需要更新多臺服務器的狀態信息，因此會增加響應時間。
增加設備成本。 故障轉移羣集所要求的額外硬件很容易使基礎結構層的成本加倍。