伺服器叢集的故障轉移方案
一、故障轉移解決方案考慮因素
1、使用者希望在試用應用程式時這些應用程式可以使用,並且能夠做出響應。
2、不間斷的連續執行日益成為普遍的業務要求。
3、應用程式故障可能會造成嚴重的經濟損失。
4、應用程式基礎機構中的所有系統都需要維護。
各個系統必須既能夠適應硬體升級,又能夠適應軟體升級,而不會導致應用程式停止執行。例如,需要釋出修補程式,以修補程式,以修復執行於某伺服器(提供了應用程式)上的元件的安全性。如果僅有此伺服器,則應用程式停止執行。如果該伺服器時一系列伺服器之一,則僅該伺服器將會停止執行,而應用程式不會停止執行。
5、會增加硬體可能會增加解決方案的成本和複雜程度。例如,對新硬體或功能更強的硬體需求提供開發和測試費用,才能使應用程式寵妃利用功能更強的環境。另外,管理更為複雜的環境也需要增加維護和培訓成本。
二、故障轉移原理:
1、檢測故障
在充分考慮了以上影響因素後,還必須設計一套故障檢測方案。要讓備用伺服器變成活動伺服器,必須設法確定活動伺服器是否不再正常工作。
通常,系統使用下列某些常規型別的心跳機制來做到這一點:
1)傳送訊號:
對於傳送訊號,活動伺服器以定義好的時間間隔將制定訊號傳送到備用伺服器。如果備用伺服器在某個時間間隔內為受到訊號,則確定活動伺服器發生了故障並擔任活動角色。例如,活動伺服器每隔30s將狀態訊息傳送到備用伺服器,如果設定的備用伺服器注意到90s(3個小時間隔)內未收到任何狀態訊息,那麼它會接管活動伺服器的工作。
2)接收訊號:
對於接收訊號,備用伺服器向活動傳送請求。如果活動伺服器沒有響應,則備用伺服器按特定次數重複傳送此請求。如果活動伺服器仍然沒有響應,則備用伺服器接管活動伺服器的工作。例如,備用伺服器可能每一分鐘將Get Customer Details訊息傳送給活動伺服器。如果備用伺服器傳送Get Customer Details請求3次,但未收到響應,此時備用伺服器獎接管活動伺服器的工作。
叢集可以使用多個級別的訊號。例如,叢集可以在伺服器級別使用傳送訊號,並在應用程式級別使用一組接收訊號。在此配置中配置中,每當活動伺服器啟動並連線到網路時它都將心跳訊息傳送到備用伺服器。這些心跳訊息是按比較頻繁的時間間隔(如每隔Ss)傳送的,而備用伺服器可能同程式設計設定為僅當未收到兩個心跳訊息,就接管活動伺服器的工作。也就是說,在活動伺服器發生故障後不超過10s的時間內,備用伺服器將檢測到這一故障並啟動備用程式。
以上傳送和接收訊號是透過專用通訊通道傳送的,以使網路擁塞和一般網路問題不會導致假的故障轉移。此外,備用伺服器可能將查詢訊息傳送到執行在活動伺服器上的一個或多個關鍵應用程式,並在指定的時間間隔內等待響應。如果備用伺服器收到正確的響應,則不採取任何進一步的行動。為了將對活動伺服器效能的影響減少到最小,應用程式級別的查詢通常要經過比較長的時段,如每隔一分鐘或更長。備用伺服器可能透過程式設計設定為:一直等待至少已經傳送5次請求但未收到響應,然後才接管活動伺服器的工作。這意味著,可能在長達5min之後,備用伺服器才會啟動公章轉移程式。所以,叢集故障轉移也是有一個時間間隔,並不能保證無縫接管。
2、同步狀態
在叢集服務系統中,在正是接管活動伺服器的工作前,首先要將備用伺服器的狀態與發生故障的伺服器的狀態進行同步,然後才能開始處理事務。
主要有3中不同的同步方法:
1)事務日誌
在事務日誌方法中,活動伺服器將對其狀態的所有更改記錄到日誌中。同步實用工具定期處理此日誌,以更新備用伺服器的狀態,使其與活動伺服器的狀態一致。當活動伺服器發生故障時,備用伺服器必須使用此同步實用處理自上次更新以來事務日誌中的任何新增內容。同步之後,備用伺服器就成為活動伺服器,並開始處理事務。這種同步方式所需的切換時間較長,伺服器應用要停頓的時間也較長。
2)熱備用
在特備用方法中,將把活動伺服器內部狀態的更新立即複製到備用伺服器。因為備用伺服器的狀態是活動伺服器狀態的克隆,所以備用伺服器可以立即成為活動伺服器,並開始處理事務。很明顯,這種同步方式所需的切換時間較短,可用性較高。
3)共享儲存
在共享儲存方法中,兩臺伺服器都在共享儲存裝置(如儲存區域網路或雙主機磁碟陣列)上記錄其狀態。這樣,因為不需要進行狀態同步,故障轉移可以立即發生。這種同步方式所需的切換時間也較短,可用性也較高。
3、確定活動伺服器
對於指定一組應用程式,只存在一臺活動伺服器,這是極其重要的。如果多臺伺服器都像是活動伺服器,則通常會導致資料損壞和死鎖。解決此問題的常見方法是使用“活動令牌”概念的某個變體。令牌在其最簡單級別上是一個標誌,用來將伺服器標識為某個應用程式的活動伺服器。對於每組應用程式;來說,只存在一個活動令牌。因此,只有一塔伺服器可以擁有令牌。伺服器啟動時。它會驗證其合作伙伴是否擁有活動令牌。如果擁有,則該伺服器將作為備用伺服器啟動。如果它未檢測到活動令牌,則會取得活動令牌的所有權,並作為活動伺服器啟動。當備用伺服器成為活動伺服器時,故障轉移程式將把活動令牌交給備用伺服器。
在大多數情況下,當備用伺服器成為活動伺服器時,對於它正在支援的應用程式或使用者來說它是透明的。如果在事務處理過程中發生了故障,則可能必須重試該事務以使其成功完成。這就是在編寫的用程式程式碼時使故障轉移程式保持透明顯得更為重要。
此外,大多數伺服器使用ip地址進行通訊。因此,為了使故障轉移成功,基礎結構必須能夠支援將IP地址從一臺伺服器轉移到另一臺伺服器。比如,可以使用能夠支援IP地址轉移(把故障機的IP地址轉移給接管伺服器使用)的網路交換機。如果系統的基礎結構不支援這一轉移功能,則可能需要使用負載均衡叢集,而不是故障轉移叢集。
4、擴充套件故障轉移叢集伺服器
故障轉移叢集中的可伸縮性通常是透過擴充套件叢集內的單個伺服器,或向其中新增更多功能來實現的,所以這種叢集系統的可伸縮能力非常有限。
godadly海外伺服器
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69953442/viewspace-2704999/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【Redis】Redis Cluster-叢集故障轉移Redis
- SQL Server 2008的故障轉移叢集概述UBSQLServer
- ES 筆記三十一:分片與叢集的故障轉移筆記
- 基於istio實現單叢集地域故障轉移
- docker搭建redis叢集和Sentinel,實現故障轉移DockerRedis
- Windows Server2012 故障轉移叢集之動態仲裁(Dynamic Quorum)WindowsServer
- windows故障轉移叢集 “群集事件” 經常出現 1135 錯誤的解決Windows事件
- Karmada跨叢集優雅故障遷移特性解析
- redis叢集 資料遷移方案Redis
- Redis 故障轉移、高可用方案,都在這了!Redis
- impala 資料表在叢集間遷移方案
- WebSphere 叢集建立及故障排除Web
- 分散式叢集伺服器時間同步方案分散式伺服器
- mongodb叢集節點故障的切換方法MongoDB
- 記一次Kafka叢集的故障恢復Kafka
- Oracle 12c叢集啟動故障Oracle
- redis cluster 叢集故障恢復操作思路Redis
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 3模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 6模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 5模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 4模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 2模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 1模式
- 【知識分享】伺服器叢集和伺服器叢集技術伺服器
- Mysql MHA部署-05故障轉移MySql
- Oracle Dataguard故障轉移(failover)操作OracleAI
- MySQL叢集搭建方案(PXC)MySql
- hbase 故障的處理方案。 (轉載文章)
- kubernets叢集節點NotReady故障 分析報告
- 一個線上問題的思考:Eureka註冊中心叢集如何實現客戶端請求負載及故障轉移?客戶端負載
- 網易Airtest叢集方案大揭秘:小型行動式叢集方案來啦AI
- 【故障公告】Kubernetes 叢集節點當機造成部落格站點故障
- redis健康檢查與故障轉移Redis
- Sentinel哨兵模式解決故障轉移模式
- 5 切換和故障轉移操作
- SQLServer 2012 AG強制故障轉移SQLServer
- 玩轉Redis叢集(上)Redis
- Oracle的三種高可用叢集方案Oracle