冗餘架構

基本的冗餘架構分為兩種,一種是主動式冗餘,另一種就是被動式冗餘。

基本介紹

  • 中文名:冗餘結構
  • 外文名:無
  • 分類:主動式冗餘,被動式冗餘
  • 科目:計算機學
背景,需求,設計原理,設計原則,

背景

長時間以來,由於軟體的固有特性:不會磨損、錯誤如果不被發現就永遠存在、相同的版本在相同的條件下錯誤也是相同的。促使人們認為軟體的冗餘是沒有意義的。但隨著軟體系統的複雜性增大、分散式套用的廣泛部署,使軟體賴以運行的環境越來越複雜,運行環境的可靠性必須通過冗餘實現。這樣就使得,雖然軟體本身冗餘沒有意義,但要在冗餘的硬體及作業系統中運行,軟體也必須支持冗餘功能。分散式軟體的冗餘特性就這樣被重視起來。

需求

在關鍵控制系統中,比如衛星控制系統、飛機及機場控制系統、鐵路控制系統等,對系統的可靠性有苛刻地要求。在這些系統中,所有組件都要求有冗餘設計,包括任何硬體及軟體環節,要求任何單點故障不影響系統正常運行,即使是關鍵節點故障,系統中其他部分也要求具備基本的應急功能。
在系統中,抽象層次越高的節點,其支持更多的接口,包含更多的信息和處理邏輯,所以複雜度也越高。同時,複雜度越高的節點,支持冗餘的難度越大。這就是硬體節點容易冗餘,而軟體節點不容易冗餘的原因。
對冗餘節點的最基本的要求是,在主節點發生故障時,備用節點自動接管主節點,完成所有的功能及提供的所有的服務。對冗餘的更進一步的要求是,在主備節點切換的過程中,不允許有信息的丟失,切換過程中的發生的任何事件都不允許丟失。
對冗餘功能的性能要求分兩個方面,一個是主節點故障允許時間T1,也就是在主節點不能正常相應的多長時間後,才認為是主節點失敗,進入主備節點切換程式;另一個是備節點接管的時間T2,也就是備節點在決定要接管責任後,需要多長時間才能進入正常的操作狀態。這樣系統對該節點的故障允許時間T就是T1和T2之和。一般大型的控制系統中,在跟操作員直接相關的軟體節點層次,故障允許時間一般在秒級,比如在筆者參與的一個捷運控制系統中,該時間要求是2秒。

設計原理

被動式冗餘主要由服務的請求者實現,基於失敗重試原理,在可用的服務提供者之間重試,直到找到一個可用的提供者。被動式冗餘是簡單的,但也有很大的局限性,它要求冗餘節點只是作為信息的處理者,完全作為C/S架構中的S,而不可能作為信息的發起者。這類冗餘在事務處理系統(MIS)中比較常見,因為這類系統總是回響用戶的操作,而很少會有自動收集信息並處理的業務。
控制系統中的冗餘架構,基本都是主動式冗餘架構。它要求冗餘節點能夠自動檢查主備節點的運行狀態,並且在主節點失敗時自動切換到備節點。
主動冗餘架構也有兩種實現方式,一是主備節點間設有交換運行狀態的通訊通道,由他們自行協商何時進行主備切換,可以稱為自控方式。另一種是基於一個中心的冗餘控制器,冗餘控制器分別與主備節點通訊,並決定何時進行主備切換,可以稱為集控方式。
在筆者參與的捷運控制系統中,兩個與硬體直接通訊的主備RTU(REMOTE TERMINAL UNIT)之間就採用自控方式。當兩個RTU之間不能通訊時,或者當前系統中僅有一個RTU時,它們會將自己設定為主節點,提供所有服務。當兩個RTU建立了通訊連線後,它們會就誰是主節點進行協商,主節點條件包括,是否連線有更多的外圍設備,是否正在對外圍系統提供服務等等。當確定誰是主節點後,兩個RTU就會自覺把自己設定為相應的工作狀態。自動方式中的主備節點,要求它們在系統中具有不同的邏輯地址,以讓它們的客戶端能夠分別找到它們,並且確定它們的工作狀態,並對它們提供的信息進行不同的處理。
在集控方式的實現中,主備節點在運行時都向冗餘控制器註冊,由冗餘控制器確定他們的運行方式,另外冗餘控制器還擔任監視主備節點運行狀態的責任。當主節點在設定的時間內沒有回響時,冗餘控制器則重新設定主備節點的運行方式,備節點代替主節點處理內部信息、回響請求。在這種情況下,主備節點具有使用相同的邏輯地址,它們的運行狀態對客戶程式是透明的,所有的客戶請求都通過冗餘控制器轉發給主節點。
在基於構件軟體架構中,比如J2EE, CORBA, .NET, WEBSERVISE等,任一軟體構件都具有唯一的構件標識,使構件的客戶端可以準確地定位構件的位置,並請求服務。這就跟構件冗餘系統產生衝突,冗餘系統要求所有構件都要有主備節點,並且要求其主備模式對構件的客戶端是透明的。這樣,支持主備構件的定址服務就成為系統不可缺少的基礎服務,它可以解析客戶的定址請求,並把服務請求轉發給主節點構件。
支持冗餘的構件本身,為了滿足苛刻的系統切換性能要求,必須針對具體情況特別設計。但有一點是共同的,就是主備構件的數據同步。在任何情況下,當主節點故障,備節點接管後,要能夠保持與主節點故障前同樣的內部狀態信息。一種情況是主備節點中,同時只有一個節點從外部獲得信息並對外提供服務,這樣主備節點之間的數據同步,就需要同步所有的動態數據,而且只能通過主備節點間的通訊實現。由於主備節點通常不在相同的物理位置上,其間的通訊只能通過網路實現,這樣就必須保證主備節點間數據同步的高效,不能占用大量的網路頻寬。另一種情況是主備節點可以同時從外部獲得信息,但同時只有一個節點對外提供服務,這樣主備節點間的數據同步就會減少,只需要同步少量運行狀態信息,但同樣會有缺點,它要求信息提供者可以支持同時給主備節點提供相同的信息。

設計原則

1,平衡主節點故障允許時間T1和主備節點切換時間T2。由於對於整個系統而言,需求被定位在節點的故障允許時間T。當T1太長、T2太短時,系統用來監視主備節點運行狀態的消耗就少些,但對主備節點的切換性能要求高,這隻有在主備節點間數據同步很充分的時候,才能做到,所以就提高了對數據同步要求。
2,減少需要同步的數據量。一方面,對構件信息進行良好歸類,分離出靜態信息和可以自行獲得的信息,不需要對這些信息進行同步。另一方面,增大構件的尺寸,把內部聯繫緊密的構件聚合成較大的構件,這樣就減少了需要跟外部交換的信息,也可以減少需要同步的數據量。

相關詞條

熱門詞條

聯絡我們