RGAC高可用群集技術白皮書

RGAC高可用群集技術是一種提供高可用性、改善性能和增強應用軟件可管理性的有效途徑。隨著IT運營管理的規范，系統安全和重要性的日益增加，集群技術必將會有著極為廣闊的應用前景。

發布時間：2009-11-04
點擊量：
點贊：

分享至

我想評論

發展趨勢以及面臨的挑戰

隨著計算機在社會各個領域的廣泛使用，人們已習慣于計算機系統帶來的便捷和高效率，但計算機系統也非常脆弱，它會受各種因素的影響，如硬件系統本身的故障，電源故障，病毒，自然災害或人為的惡意破壞，都會導致系統無法正常運行。現有很多系統均是單主機工作環境，任何一個單點故障，都會影響IT運維業務的正常運轉，而且產生很多不良后果。

在高校校園數字化校園管理中，核心的業務應用系統越來越多，這些系統都是關系到高校管理的核心業務，如：財務系統、辦公系統、精品課程系統、安全管理認證系統等，尤其是安全管理認證系統，這個系統是管控所有上網用戶的最基本的核心系統，是所有高質量網絡服務的基礎，高穩定和高性能歷來是高校網絡中心管理者的首要考慮的問題。
不能穩定運行和低性能的系統常導致

1. 用戶滿意度非常極差，從而影響用戶的使用感受，極大的降低了用戶對網絡中心信任和依賴；

2. IT部門承受極大的壓力，一方面要保證系統的穩定性，另一方面，系統一旦出現故障，必須在盡可能短的時間內讓系統再次運行，但這往往又無法保證的；

3. 可能導致數據的不完整和不一致，甚至部分數據的丟失，尤其在大規模數據應用環境中尤為突出；

4. 當業務大量增加時，用戶使用系統性能嚴重下降，但是用戶不認為是由于業務大量拓展導致的，而是認為網絡中心提供的服務質量不好造成的；
以上這些問題頻繁如果出現，則會引起高校領導對網絡中心服務的不信任，從而可能促使高校領導考慮網絡中心業務外包，所以解決網絡管理的穩定和擴展性已成為網絡運維管理的重要任務。

2 技術背景

2.1 負載均衡

在計算機硬件價格下降和計算機網絡拓撲發展的情況下。分布式計算機系統給用戶提供了一個豐富的資源集合。人們在研究分布式系統時就注意到這樣一個問題：在一個由網絡連接起來的多計算機環境中，在某一時刻。一些計算機的負載過重。而另外一些計算機的負載較輕，平衡各計算機之間的負載是任務分配與調度的一個主要目標。它能夠提高整個系統的性能。

為了改善系統的性能，通過在多臺計算機之間合理地分配負載，使各臺計算機的負載基本達到均衡，這種計算能力共享的形式通常被稱為負載平衡或負載共享。

負載均衡建立在現有網絡結構之上，它提供了一種廉價有效的方法擴展服務器帶寬和增加吞吐量，加強網絡數據處理能力，提高網絡的靈活性和可用性。

現代負載均衡技術通常操作于網絡的第四層或第七層。負載均衡器可以根據實際的響應時間制定優先級交付決策，從而實現高性能、智能化流量管理，達到最佳的服務器群性能。采用第七層應用控制還可以減少通信高峰期的錯誤信息，因為差錯控制和流量管理技術可以偵測到一些錯誤信息并透明地將會話重定向到另一個服務器，使用戶順利地進行使用。

由于采用了負載均衡技術，自動故障恢復得以實現，服務的時間可以延長，24×7可靠性和持續運行成為可能。另外，負載均衡器一般也支持路徑外返回模式，即繞過流量分配器，為那些焦急等待大量數據文件請求響應的客戶提供更快的響應時間。

在最新的負載均衡產品中，智能化越來越明顯。一些智能化的負載均衡器能夠偵測到像數據庫錯誤、服務器不可用等信息，從而采取措施使會話恢復和重定向服務器使電子商務能夠得以順利進行。多址負載均衡器可以對客戶發來的訪問請求進行解析，計算出最佳地址，然后將該地址返回客戶，使客戶自動連接到對其請求來說最佳的數據中心。

負載均衡，從結構上分為本地負載均衡和地域負載均衡(全局負載均衡)，前一種是指對本地的服務器集群做負載均衡，后一種是指對分別放置在不同的地理位置、在不同的網絡及服務器群集之間作負載均衡。

2.2 群集服務

服務器群集是一組協同工作并運行群集服務的獨立服務器。服務器群集為資源和應用程序提供高可用性、故障恢復、可伸縮性和可管理性。服務器群集允許客戶端在出現故障和計劃中的暫停時，依然能夠訪問應用程序和資源。如果群集中的某一臺服務器由于故障或維護需要而無法使用，資源和應用程序將轉移到可用的群集節點上。

群集服務可以對應用程序和資源進行監控，并能夠自動識別和恢復眾多故障狀況。這為在群集中管理工作負荷提供了靈活性。另外，還提高了整個系統的可用性。

集群技術是一種通用的技術，其目的是為了解決單機運算能力的不足、IO能力的不足、提高服務的可靠性、獲得規模可擴展能力，降低整體方案的運維成本（運行、升級、維護成本）。只要在其他技術不能達到以上的目的，或者雖然能夠達到以上的目的，但是成本過高的情況下，就可以考慮采用集群技術。

采用群集技術可以獲得以下優點：

高可用性：通過服務器群集，資源（例如：磁盤驅動器和Internet協議（IP）地址）的所有權會自動從故障服務器轉移到可用的服務器。當群集中的某個系統或應用程序發生故障時，群集軟件會在可用的服務器上重新啟動故障應用程序，或者將工作從故障節點分散到剩下的節點上。由此，用戶只在瞬間感覺到服務的暫停。

故障恢復：當故障服務器重新回到其預定的首選所有者的聯機狀態時，群集服務將自動在群集中重新分配工作負荷。該特性可配置，但默認禁用。避免了網絡關鍵部位出現單點失效。

可管理性：您可以使用“群集管理器”工具（CluAdmin.exe），將群集作為一個單一的系統進行管理，并對猶如運行于一個單一服務器的應用程序實施管理。您可以將應用程序轉移到群集中的其它服務器。“群集管理器”可用于手動平衡服務器的工作負荷，并針對計劃維護釋放服務器。您還可以監控群集的狀態、所有節點以及來自網絡任何地方的資源。

可伸縮性：群集服務可擴展以滿足需求的增長。當群集監督應用程序的總體負荷超出了群集的能力范圍時，可以添加附加的節點，解決網絡擁塞問題，服務就近提供，實現地理位置無關性。

3 技術特性介紹

3.1 技術概述

高可用的群集技術不但可以有效地解決單服務器的性能限制，而且可以實現故障的快速轉移，保證服務的高可用性以及靈活的擴展性。RGAC（即：RG Application Cluster——銳捷應用群集，下同）方案很好地應用了這一技術，由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具有等價的地位，都可以單獨對外提供服務而無須其他服務器的輔助。通過某種負載均衡技術，將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器獨立地回應客戶的請求。這種技術可以用最少的投資獲得接近于大型主機的性能。

同時，RGAC方案整合了數據庫的事務復制功能，并針對SAM系統提供的服務，自主進行了研發，達到多臺服務器之間的信息同步，在客戶的眼里，SAM系統只有一個，但它所提供的服務，較之單臺，更加快捷，也更加穩定！

3.1.1 NLB

Windows server系統（Windows 2000高級服務器版本、Windows server 2003所有版本）中提供了NLB（即：Network Load Balancing——網絡負載均衡，下同）功能。
NLB技術包含兩大特點：負載均衡和故障轉移。

1. 負載均衡

NLB能將傳入的請求傳播到多達32臺服務器上，即最多可以使用32臺服務器構成一個集群，共同分擔對外的網絡請求服務。該技術保證即使是在負載很重的情況下，服務器也能做出快速響應。

網絡負載均衡對外只需提供一個IP地址，即集群IP，客戶端使用這個IP即可訪問集群。所有的服務器上使用相同的規則，來決定并發的流量被分配到哪一臺上進行處理，從而很大程度上提高了服務器的處理能力。

2. 故障轉移

NLB第二個強大的特性是故障轉移。集群內每臺服務器靠定時發送心跳信息來估定其它服務器的狀態。當有一臺或幾臺服務器不可用時，服務不會中斷，能夠迅速在剩余的服務器中重新指派服務器接管過來，從而對用戶是一直可用的，這個過程叫做“聚合”。這項特性能夠保障服務被不間斷地提供。

3.1.2 信息同步

RGAC方案提供了信息同步功能。

舉個例子，系統中有兩臺設置了NLB的認證服務器A、B，各對應數據庫C、D。一個用戶發起添加500個用戶的請求，這個請求被NLB分配到服務器A進行處理，數據庫C的用戶表中也隨之增加這500個用戶。但對于請求被分配到服務器B處理的用戶來說，服務器B上并沒有這新增的500個用戶，那么，用戶得到的信息就不一致了。不同的用戶，不同的操作，得到的結果可能不同。

在RGAC方案中，通過SQL SERVER數據庫事務復制和內存同步來解決信息同步的問題。在上面的例子中，數據庫C在增加了用戶信息后，會把這一變化同步到數據庫D上，對于請求被分配到服務器B處理的用戶來說，服務器B上也有新增用戶的信息。這樣所有的SAM服務器的信息就是同步一致的。

3.2 群集技術在SAM各業務模塊的應用

3.2.1 報文交互過程

對于SAM來說，來自外部的請求有如下幾大方面：

Radius相關認證，記賬請求報文

Web管理端http請求/https請求

Web自助端http請求/https請求

和交換機之間的SNMP報文交互

和交換機之間的TRAP報文交互

和NTD之間的IPFIX報文交互

和第三方系統之間的JMS消息通信

發送EMAIL的pop3通信

這些報文交互涉及到的SAM功能非常廣泛，各個模塊都有功能涉及。

3.2.2 技術框架

系統（NTD，交換機，路由器等）和SAM之間的在NLB的前提下交互過程。

報文傳輸過程中，涉及到2種流量，HTTP和HTTPS的，NLB是基于IP包的源IP的負載均衡，正常情況下并不會出現什么問題，同一個源IP的HTTP或者HTTPS請求都是如上所述的交互方式。

如圖3-2所示，在正常運行情況下，任何一個固定client都只會和NLB中某臺服務器進行交互，并且在下次請求過程中仍然維持這種1對1的對應關系。對于單純的http和https交互不會出現什么問題。

但需要考慮的是在出現單點故障時，會受到影響的參數主要考慮如下2點：Session、Cookies。

1. 由于Session產生的影響

假設SAM S2出現單點故障時，NLB自動把Client A的http請求發送給SAM S3，如果在SAM S2出現單點故障之前Client A已經在SAM S2上登陸（目前做法是把用戶的信息保存到session中），則在下次http請求到SAM S3之后，會出現SAM S3讓Client A重新登陸認證的情況，因為SAM S2的session信息并沒有轉移到SAM S3上。當SAM S2恢復后，如果NLB自動又把Client A的請求發給SAM S2，則需要看S2上面的session是否已經過期（時間過期或者系統重啟導致被清空），如果過期則仍然需要進行重新登陸，而且起碼在SAM S3中存入Session的相關信息也丟失了。

2. 由于Cookies產生的影響

而對于cookies（可能會用到），由于cookies是保存在Client A上面的，并不會因為服務器的改變而改變，所以cookies的應用是不會受到影響的。
綜上，對于http/https來說，session不能同步是負載均衡帶來的問題，解決方式有如下的一些：

不要向Session中存儲用戶的登陸信息，權限信息以及一些關鍵的信息，避免由于session不同步而導致重登陸或者信息丟失的問題；

把登陸信息，權限信息及其他一些信息存儲到cookies里面或者存儲到數據庫里面，然后通過數據庫同步達到信息同步的目的；

3.2.1 認證模塊

對于認證模塊，涉及到網絡流量有如下一些類型：

Radius認證報文(UDP)

Ipfix的連接認證報文（TCP）

當平常負載均衡正常的情況下，由于數據同步的因素，所以相關設備的信息無論哪個服務器都是一致的，所以不存在什么問題。

由于IPFIX是計費模塊的計費采集器，所以該部分放到計費模塊去講，這里主要講Radius認證報文受到的影響。

Radius本身是基于UDP傳輸的，也就是每次一個報文，你來我往，并不像TCP那樣需要建立一個通道，設備認證信息，用戶信息等等都通過數據庫同步達到數據同步，平常正常運行在負載均衡模式下不會出現任何問題，對外就是一臺服務器。而當出現單點故障時，會有如下一些影響：

認證開始之前原定進行該認證報文處理的服務器出現故障，則由NLB自動調整到另外一臺服務器上進行認證報文的處理。從認證開始到結束用戶是不會有什么感覺的。

認證交互過程中處理該認證報文的服務器出現故障，則由NLB自動調整到另外一臺服務器上進行從新開始的一次認證報文。對于1次交互的PAP，CHAP來說，那表現就是Radius服務器沒響應，然后重發認證報文或者認證超時（這里需要看NLB什么時候偵測到單點故障以及調整的速度了）。對于多次交互的認證方式比如EAP，PEAP等將會給用戶予認證失敗的提示，然后需要重新進行認證，那么這里需要考慮如何做？

認證完成之后進行該認證報文處理的服務器出現故障時，對于認證報文來說是沒有任何影響的，因為認證已經完成，相關權限已經下發。

綜述，在認證過程中需要考慮在認證交互過程中出現單點故障時，認證的處理及回饋用戶的信息，如果理論上該段時間可以忽略不計的話，那么該考慮也可以只做說明書說明即可。

3.2.2 計費模塊

對于計費模塊，必須考慮如下內容：

Radius記賬報文采集器

Ipfix流量報文采集器

對于Radius記賬報文采集器來說，它不像認證報文一樣可以丟棄，所以必須用一個Radius記賬臨時表來存儲記賬開始報文信息或者記賬更新報文信息。然后這些信息通過數據庫同步方式來達到各NLB服務器數據同步的目的，進而使得在服務器未收到記賬結束報文之前，仍然能夠根據session id正常的處理記賬結束和記賬更新。并形成臨時計費記錄給計費處理模塊進行計費處理。

對于出現單點故障時，由NLB切換該源IP（交換機）上的所有IP報文到另外一個服務器上去處理，那么此時已經發送出記賬開始/更新報文的信息通過數據庫同步在另外那個服務器上也存在，再次收到記賬更新/結束報文時也能夠正常進行處理。這樣的情況下必須滿足如下條件：

交換機/路由器必須具備Radius記賬報文重發機制

記賬臨時表的數據庫同步必須是實時的，最高優先級的

SAM當收到記賬結束報文卻找不到對應session id時，需要把報文放入延遲處理隊列，避免因為數據庫同步不及時而把重要的計費信息給丟棄了。

對于IPFIX流量報文采集器，在負載均衡中出現單點故障時，由于TCP連接和UDP連接方式不同，TCP連接必須建立TCP通道，然后再在通道中傳輸數據，如果其建立TCP通道的服務器出現單點故障時，相關協議處理模塊必須達到如下要求：

NTD端必須具備TCP通道重連功能

NTD方面沒有成功發出的流量需要保留并且做延遲重發處理
而由于IPFIX流量是通過報文－內存－數據庫臨時表－數據庫記錄表，這樣的層次存儲，所以一旦出現單點故障，則在內存中的流量數據將會丟失，單數據庫臨時表信息由于數據庫同步的存在使得數據能夠共享并繼續完成流量的解析處理。基于此，內存中的流量信息保存時間最大值必須是可控范圍的，需要設定一些策略來保障內存中信息及時更新到數據庫臨時表中。

3.3 技術應用

3.3.1 認證流量負載均衡

采用NLB技術，可以讓多個服務器同時均衡的處理多點并發訪問要求，在不增加每臺服務器配置的情況下，成倍的提高網絡服務的認證管理的性能。

同一高可用群集中的SAM分擔處理認證請求，系統性能倍增。

RGAS可實現技術參數：

單機40用戶/秒

雙機80用戶/秒

四機120用戶/秒

3.3.2 業務實時熱備份

安全管理認證系統的無故障運行是確保全網用戶能夠隨時使用網絡的關鍵要素，也是網絡中心為全校提供高質量網絡服務的一個重要保證。通過高可用群集技術的支撐，可達成單臺服務不可能實現的全年無故障運行的性能指標。

3.3.3 跨校區帳號漫游

　　各大高校的園區規模不斷擴大，高校的基礎設施建設規模也隨之持續完善，由此產生的在高校各園區之間透明的帳號漫游需求已經成為越來越多高校亟待解決的問題。RGAC解決方案通過提供在不同園區之間、不同接入方式的帳號漫游滿足帳號漫游需求，這種漫游對用戶是完全透明的。在所有部署了RGAC系統的地理區域，網絡接入用戶可以方便使用唯一的帳號接入網絡，而且該帳號下的所有用戶信息與其它園區保持一致。在后臺，網絡中心管理者在進行統一管理，帳號的統一管理極大的提高管理者的工作效率，減輕工作量。
　

3.3.4 數據備份

　由于RGAC具有數據庫實時同步技術，可在各數據庫服務器同步數據。當某一臺數據庫服務出現故障，其它同步的數據庫服務器可實時的替代，不會影響數據的正常使用，而且在故障排除后，系統需要在可控的時間范圍內自動同步缺失的數據到新的數據庫服務器上，從而實現系統容災的特性，確保數據庫單點故障不影響全局系統的正常運行。

4 典型組網案例

4.1 拓撲方案

方案介紹

系統由2臺SAM服務器組成一個RG-AC（銳捷應用群集），它是雙機同時處理認證請求的，具有負載分擔，冗余備份的特點。

4.2 實現應用

4.2.1 數據庫自動同步復制

組成NLB系統的二臺服務器，當一臺服務器數據庫有讀寫操作時，另一臺服務器中自動同步操作。可以實現另一臺服務器上開立的用戶，數據庫自動同步復制正常。

4.2.2 NLB雙機熱備

二臺服務器組成NLB雙機熱備，SAM3.0具有雙機熱備功能。關掉一臺SAM服務器或者離線，用戶可通過認證。

4.2.3 方案效益

通過RGAC技術，可以在較少的投資和不改變原有網絡部署方案的情況下解決以下問題。
峰值問題

SAM系統在上線和下線的高峰期時，這是網絡流量的高峰階段，其它時間網絡流量相對較少。服務器的處理存在“波峰”和“波谷”的變化，而且“波峰”時，業務量大小的變化又不規律，這就使SAM服務器不得不面對“峰值堵塞”問題。原有解決方法為增加服務器的本身硬件配置或實現單機熱備，提高處理能力。但仍存在性能不平衡問題，且這樣做，投資成本大而且本身硬件配置提升對于高校客戶來說是有瓶頸的。

單點故障

單臺SAM服務器的設置，不可避免會出現“單點故障”，需要進行SAM服務器“容錯”。為實現容錯，現在2.x的做法是主服務器旁安置一臺備份服務器做熱備。但這樣做，平時只有一臺服務器工作，另外一臺服務器處于空閑狀態，無法完全利用所有服務器的處理資源，投資得不到充分利用，還是相當于一臺服務器在工作而已。且當出現“峰值堵塞”時，所得到的很可能是“多米諾”效應，即所有服務器連續被“堵”至“死”，互相切換直到最后所有服務器都死掉，最終系統完全癱瘓。并且，當所有服務器都損壞時，無法動態、合理地利用其它資源提供服務或備份。

擴展不便

隨著SAM應用規模不斷的增大，服務器上所要處理的數據量不斷增大，同時在線產生的數據和web管理員需要進行管理的數據也會越來越多。若處理資源不夠，在未超出系統容量時，往往是客戶的請求回應越來越慢，可容納的同時連接數量逐漸減小，系統性能嚴重下降。當超出系統容量后，系統出現故障導致業務中斷。為應對日益增多的業務量，系統的擴展性尤為重要。

5 支持AC技術的產品
　　

集群技術	產品
支持網卡	Intel系列網卡
	3Com系列網卡
	不支持其他如TP LINK等網卡
支持系統	Windows Server 2003
支持數據庫	MS SQL Server 2000