故障轉移群集
將應用程式或服務安裝在配置為發生故障時彼此接管對方工作的多台伺服器上。 一台伺服器接管發生故障的伺服器的過程通常稱為"故障轉移"。 故障轉移群集是一組這樣配置的伺服器：如果一台伺服器變為不可用，則另一台伺服器自動接管發生故障的伺服器並繼續處理任務。 群集中的每台伺服器將群集中至少一台其他伺服器確定為其備用伺服器。
要讓備用伺服器變成活動伺服器，它必須設法確定活動伺服器不再正常工作。 通常，系統使用下列某個常規型別的心跳機制來做到這一點：
•傳送訊號。對於傳送訊號，活動伺服器以定義好的時間間隔將指定訊號傳送到備用伺服器。 如果備用伺服器在某個時間間隔內未收到訊號，則確定活動伺服器發生了故障並取得活動角色。 例如，活動伺服器每隔 30 秒將狀態訊息傳送到備用伺服器。 由於記憶體洩漏，活動伺服器最終用盡記憶體，然後崩潰。 備用伺服器注意到在 90 秒（三個時間間隔）內未收到任何狀態訊息，因此它會接管活動伺服器的工作。
•接收訊號。對於接收訊號，備用伺服器向活動伺服器傳送請求。 如果活動伺服器沒有響應，則備用伺服器按特定次數重**送此請求。 如果活動伺服器仍然沒有響應，則備用伺服器接管活動伺服器的工作。 例如，備用伺服器可能每隔一分鐘將 getcustomerdetails 訊息傳送到活動伺服器。 由於記憶體洩漏，活動伺服器最終崩潰。 備用伺服器傳送 getcustomerdetails 請求三次，但未收到響應。 此時，備用伺服器將接管活動伺服器的工作。
群集可以使用多個級別的訊號。 例如，群集可以在伺服器級別使用傳送訊號，並在應用程式級別使用一組接收訊號。 在此配置中，每當活動伺服器啟動並連線到網路時它都將心跳訊息傳送到備用伺服器。 這些心跳訊息是按比較頻繁的時間間隔（例如每隔 5 秒）傳送的，而備用伺服器可能通過程式設計設定為如果僅僅未收到兩個心跳訊息，它就接管活動伺服器的工作。 也就是說，在活動伺服器發生故障後不超過 10 秒的時間內，備用伺服器將檢測到這一故障並啟動備用程序。
相當常見的情況是，訊號是通過專用通訊通道傳送的，以便網路擁塞和一般網路問題不會導致假的故障轉移。 此外，備用伺服器可能將查詢訊息傳送到執行在活動伺服器上的乙個或多個關鍵應用程式，並在指定的超時間隔內等待響應。 如果備用伺服器收到正確的響應，則它不採取任何進一步行動。 為了將對活動伺服器的效能影響減少到最小，應用程式級別的查詢通常要經過比較長的時段，如每隔一分鐘或更長。 備用伺服器可能通過程式設計設定為：一直等到至少已經傳送五次請求但未收到響應，然後才接管活動伺服器。 這意味著，可能在長達 5 分鐘之後，備用伺服器才會啟動故障轉移程序。
備用伺服器必須首先將其狀態與發生故障的伺服器的狀態進行同步，然後才能開始處理事務。 主要有三種不同的同步方法：
•事務日誌。在事務日誌方法中，活動伺服器將其狀態的所有更改記錄到日誌中。 乙個同步實用工具定期處理此日誌，以更新備用伺服器的狀態，使其與活動伺服器的狀態一致。 當活動伺服器發生故障時，備用伺服器必須使用此同步實用工具處理自上次更新以來事務日誌中的任何新增內容。 在對狀態進行同步之後，備用伺服器就成為活動伺服器，並開始處理事務。
•熱備用。在熱備用方法中，將把活動伺服器內部狀態的更新立即複製到備用伺服器。 因為備用伺服器的狀態是活動伺服器狀態的轉殖，所以備用伺服器可以立即成為活動伺服器，並開始處理事務。
•共享儲存。在共享儲存方法中，兩台伺服器都在共享儲存裝置（如儲存區域網路或雙主機磁碟陣列）上記錄其狀態。 這樣，因為不需要進行狀態同步，故障轉移可以立即發生。
對於指定的一組應用程式，只存在一台活動伺服器，這是極其重要的。 如果多台伺服器都像是活動伺服器，則通常會導致資料損壞和死鎖。 解決此問題的常見方法是使用"活動令牌"概念的某個變體。 令牌在其最簡單級別上是乙個標誌，用來將伺服器標識為某個應用程式的活動伺服器。 對於每組應用程式來說，只存在乙個活動令牌；因此，只有一台伺服器可以擁有令牌。 當伺服器啟動時，它會驗證其合作夥伴是否擁有活動令牌。 如果擁有，則該伺服器將作為備用伺服器啟動。 如果它未檢測到活動令牌，則它會取得活動令牌的所有權，並作為活動伺服器啟動。 當備用伺服器成為活動伺服器時，故障轉移程序將把活動令牌交給備用伺服器。
在大多數情況下，當備用伺服器成為活動伺服器時，對於它正在支援的應用程式或使用者來說，它是透明的。 如果在事務過程中發生了故障，則可能必須重試該事務以使其成功完成。 這就使編寫應用程式**時使故障轉移程序保持透明顯得更為重要。 這樣做的乙個示例是，在將資料提交到資料庫時，包括重試和超時。
此外，大多數伺服器使用 inter*** 協議 (ip) 位址進行通訊，因此，為了使故障轉移成功，基礎結構必須能夠支援將 ip 位址從一台伺服器轉移到另一台伺服器。 比如，可以使用能夠支援 ip 位址轉移的網路交換機。 如果系統基礎結構不支援這一轉移功能，則您可能需要使用負載平衡群集，而不是故障轉移群集。 有關詳細資訊，請參閱load-balanced cluster
模式。
故障轉移群集中的可伸縮性通常是通過擴充套件群集內的單個伺服器，或向其中新增更多功能來實現的。 了解以下兩點是很重要的：故障轉移群集必須設計為處理預期負載，各個伺服器的大小應當能夠適應 cpu、記憶體和磁碟使用的預期增長。failover cluster 伺服器通常是高階多處理器伺服器，並且它們被配置為使用多個冗餘子系統來獲得高可用性。 如果解決方案的資源要求超過了群集中伺服器的限制條件，則擴充套件群集將是極其困難的。
返回頁首
為了幫助您更好地了解如何使用故障轉移群集來實現高可用性，下面的討論分步演示了如何將已經實現的基本解決方案（它包含單個系統，即故障單點）重構為高度可用的解決方案。
一開始，組織可能只有基本解決方案體系結構（例如，圖 1 中略述的體系結構）。雖然該解決方案可能滿足最初的可用性要求，但是某些因素（如使用者數的增長或需要應用程式停機時間更短）可能迫使您對設計進行更改。
圖 1:具有故障單點的非故障轉移解決方案
在圖 1 中，資料層僅包含一台為應用程式層提供服務的資料庫伺服器 (database10)。 如果資料庫伺服器或它執行的軟體發生故障，則應用程式伺服器將不再能夠訪問用來為客戶端提供服務的資料。 這將使應用程式對客戶端不可用。
為了提高解決方案的可用性，組織可能決定消除資料層中的單個資料庫伺服器造成的潛在故障單點。 為此，可以將伺服器新增到資料層，並利用現有資料庫伺服器、新伺服器和共享儲存裝置建立故障轉移群集。 在說明該更改的圖 2 中，群集由連線到共享儲存陣列的兩台伺服器組成。
圖 2:具有故障轉移資料層的解決方案
第一台伺服器 (database01) 是處理所有事務的活動伺服器。 僅當 database01 發生故障時，處於空閒狀態的第二台伺服器 (database02) 才會處理事務。 群集將乙個虛擬 ip 位址和主機名 (database10) 在客戶端和應用程式所使用的網路上公開。
注意：您可以將此設計擴充套件為包括多台活動伺服器（除了所示的伺服器外），要麼使它們共享單個備用伺服器，要麼將每個活動伺服器配置為另乙個活動伺服器的備用伺服器。
效能和可靠性模式
效能和可靠性模式 本頁內容 滿足執行要求 模式概述 效能和可靠性模式 效能 可伸縮性和可靠性是所有企業應用程式的重要特性。儘管可通過多種方法來改善效能和可靠性，但是此模式群集強調如何將為任意數量的應用程式或使用者提供服 務的系統組合起來，以獲得更好的可伸縮性和可用性。本章中的模式為有效地適應負載和高...
效能測試之穩定性測試（可靠性測試）
最近兩天在系統的複習效能測試方面的知識，結合之前的效能測試經驗有了一些總結，希望寫出來與大家分享，希望多提寶貴意見，共同進步 首先來說說效能測試 效能是軟體的一種非功能特性，他關注的不是軟體是否完成了特定的功能，而是軟體在完成特定功能是展示出來的及時性。及時性從不同的視角代表不同的指標 使用者 響應...
高效能kafka之訊息可靠性分析及常見問題
kfaka發訊息的模式分為同步和非同步,預設是同步的,非同步的吞吐量比較高,但是訊息丟失的概率比較大,同步還是非同步可以通過producer.type屬性進行控制 kafka有三種訊息確認機制,由request.required.acks屬性控制,acks 0時代表不適用確認機制,producer傳...