號碼攜帶集中管理系統(tǒng)的高可用技術(shù)應用
1 引言
在號碼攜帶系統(tǒng)中,CSMS(集中管理系統(tǒng))匯總著全國所有運營商號碼攜帶用戶的基本數(shù)據(jù)和號碼攜帶規(guī)則,扮演著號碼攜帶業(yè)務提供管理者和仲裁者的角色,地位十分重要。CSMS和運營商的號碼攜帶營業(yè)生產(chǎn)系統(tǒng)一起,實時為用戶提供號碼攜帶申請業(yè)務,必須按照電信級系統(tǒng)的要求,提供24h×7d×365d時間內(nèi)99.99%的服務可用性。因此,CSMS系統(tǒng)的高可用性方案十分重要。
高可用性(High Availability)一般是指通過盡量縮短系統(tǒng)停機時間,提高系統(tǒng)和應用的可用性。為了提高系統(tǒng)可用性,一種方法是提高計算機各個部件的可靠性,但這種方法并不可靠,因為單一服務器可靠性再高也存在單點故障的潛在隱患,所以目前業(yè)界比較成熟的做法是采用集群(CluSTer)的方案。它通過加入冗余設(shè)備使得在一個設(shè)備出錯而停止服務的時候,這些冗余的設(shè)備可以繼續(xù)提供服務。本文中,高可用性的含義還包括“快速恢復”,即一旦由于系統(tǒng)中止并重啟后,業(yè)務應用能夠盡快恢復。
本文主要介紹了在CSMS中為了實現(xiàn)系統(tǒng)的整體高可用性,在各個層面可以采用的集群技術(shù)。
2 系統(tǒng)高可用技術(shù)的應用范圍
在號碼攜帶系統(tǒng)中,從和運營商接口側(cè)到CSMS的核心數(shù)據(jù)層主要包括以下功能層,高可用方案主要圍繞這些層面來展開。
?。?)網(wǎng)絡層:是和運營商連接的部分,主要需要考慮,如何避免傳輸單點故障,如何避免網(wǎng)絡設(shè)備單點故障?
?。?)Web服務器層:如何保證Web服務器的單點故障?如果提供多臺Web服務器,如何在之間進行資源協(xié)調(diào)?
(3)應用服務器層:Web服務器提交請求給應用服務器后,如何避免應用服務器的單點故障及多臺應用服務器的資源協(xié)調(diào)?
?。?)數(shù)據(jù)庫服務器層:應用服務器向數(shù)據(jù)庫服務器提交請求時,如何避免數(shù)據(jù)庫服務器的單點故障及多臺之間的資源協(xié)調(diào)?
?。?)應用軟件:即使我們采取了各種措施,還是存在服務器硬件宕機的可能性。在系統(tǒng)重啟后,我們應用軟件如何設(shè)計保證系統(tǒng)能快速恢復?
(6)數(shù)據(jù)層:如何保證數(shù)據(jù)存儲安全可靠?
為了回答上述問題,我們需要對各種高可用性技術(shù)進行研究和總結(jié)。
3 高可用性技術(shù)研究
3.1 CSMS系統(tǒng)架構(gòu)
圖1所示的是CSMS系統(tǒng)組織架構(gòu)。
圖1 CSMS系統(tǒng)組織架構(gòu)
為了保證系統(tǒng)的高可用性,防止出現(xiàn)單點故障,系統(tǒng)的每個功能層在硬件設(shè)備上都采用冗余配置,同時通過各種軟件方案設(shè)計,實現(xiàn)系統(tǒng)高可用性。
3.2 網(wǎng)絡方案
在網(wǎng)絡方案上,系統(tǒng)和每個運營商之間的專線采用155M POS或者MSTP雙光纜接入,利用傳輸網(wǎng)絡的冗余和自愈能力,保證系統(tǒng)物理接入線路的高可用性。每個運營商的兩條光纜分別接入到系統(tǒng)的兩臺接入路由器上,盡量避免路由器設(shè)備的單點故障。每臺路由器分別配置了多個網(wǎng)卡分別接入多個運營商的專線,防止出現(xiàn)單板卡故障影響到更多的運營商接入。
在路由器對運營商側(cè)的方案設(shè)計上,需要采用動態(tài)路由協(xié)議,當某臺路由器到某個運營商的某條缺省配置路由出現(xiàn)故障時(比如線路故障或板卡故障),需要將備選路由廣播到所有相關(guān)設(shè)備上,新的通信連接則按照新的路由進行通信。在路由器對防火墻的方案設(shè)計上,需要采用VRRP協(xié)議進行動態(tài)IP地址綁定,即兩臺路由器下聯(lián)到防火墻的IP為一個虛擬地址,缺省時綁定在某個路由器的實際地址上,當需要切換時,將虛擬地址綁定在另外一臺路由器的實際地址上,而對于防火墻來說,不需要做任何改變就完成了通信的切換過程。
3.3 Web服務器的負載均衡器方案
從客戶端的請求經(jīng)過網(wǎng)絡設(shè)備后,將首先到達Web服務器。從系統(tǒng)的高可用性設(shè)計角度出發(fā),系統(tǒng)將部署多臺Web服務器進行集群。Web服務器之間進行集群包括Web負載均衡和會話的失敗轉(zhuǎn)移兩個方面。
負載均衡可以采用多種技術(shù),比如采用硬件負載均衡器,也可以在某個Web服務器上部署負載均衡軟件,由這臺Web服務器兼作負載均衡器。負載均衡器最主要的特征包括:
?。?)單點接入
從客戶端的角度看,多臺Web服務器只有一個地址,就是負載均衡器的服務地址。這樣做的好處有兩點:一是客戶端不需要配置多個Web服務器地址,比較方便;二是可以向客戶端網(wǎng)絡屏蔽網(wǎng)內(nèi)具體的設(shè)備的地址信息,對網(wǎng)絡保護具有一定作用。
?。?)實現(xiàn)負載均衡算法
當客戶端請求到來的時候,負載均衡器能夠決定把這個請求轉(zhuǎn)發(fā)到后臺的哪個Web服務器進行處理。主流算法包括:輪循算法,隨機算法和權(quán)重算法,無論哪種算法,負載均衡器總是試圖讓每個服務器實例分擔等同的壓力。
?。?)健康檢查
一旦某一個Web服務器停止工作,負載均衡器能夠檢測到并且不再把請求轉(zhuǎn)發(fā)到這個服務器。同樣,當這個失敗的服務器重新開始工作的時候,負載均衡器也能夠檢測到,并且開始向它轉(zhuǎn)發(fā)請求。
?。?)會話粘滯
所有的Web應用都會有一些會話狀態(tài),比如號碼攜帶系統(tǒng)中某個流程是否結(jié)束的信息,某條請求消息是否接收到對應的ACK信息或者響應信息等。因為HTTP協(xié)議本身是無狀態(tài)的,所以會話狀態(tài)就需要記錄在某個地方,并且和客戶端關(guān)聯(lián),以便于下次請求的時候能夠很方便地取出來。當進行負載均衡的時候,對于某一個確定的會話來說,把請求轉(zhuǎn)發(fā)到上一次它所請求到的服務器實例是一個很好的選擇,否則的話,可能會導致應用不能正常工作。
因為一般來說會話狀態(tài)是存儲在某個Web服務器實例的內(nèi)存中的,所以對于負載均衡器來說,“會話粘滯”的特征非常重要。但是,如果某個Web服務器由于某種原因失敗,那么在這個服務器上的會話狀態(tài)就會全部丟失。負載均衡器能夠檢測到這個錯誤并且不再把請求轉(zhuǎn)發(fā)到這個服務器,但是由于會話狀態(tài)的丟失,可能會引發(fā)其他錯誤。因此,負載均衡器必須還要有另一個重要功能“會話失敗轉(zhuǎn)移”。
?。?)會話失敗轉(zhuǎn)移
會話失敗轉(zhuǎn)移的實現(xiàn)機制是在某個Web服務器在收到某個客戶端請求后,將會話對象備份到某個地方,以保證服務器失敗的時候會話狀態(tài)不會丟失。
如何備份會話數(shù)據(jù)也有不同的方案,比較主流的方案包括數(shù)據(jù)庫方案和內(nèi)存復制方案。
數(shù)據(jù)庫方案就是在合適的時間讓Web服務器將會話數(shù)據(jù)存儲到數(shù)據(jù)庫中。當失敗轉(zhuǎn)移發(fā)生時,另外可用的Web服務器實例接替失敗的服務器,從數(shù)據(jù)庫中將會話狀態(tài)恢復加載進來。數(shù)據(jù)庫方案的優(yōu)點是:
●易于實現(xiàn)。將請求處理和會話備份分離開來使得集群更健壯、更易于管理。
●即使整個集群都失敗了,會話數(shù)據(jù)仍然可以保存下來,可以在系統(tǒng)重啟時繼續(xù)使用。
數(shù)據(jù)庫事務的缺點是比較消耗資源,當會話中的數(shù)據(jù)量較大時就會受到性能的限制。
內(nèi)存復制方案是在備用服務器的內(nèi)存中保存會話信息,而不是在數(shù)據(jù)庫中進行持久化。和數(shù)據(jù)庫方案相比,這種方案的性能較高,在原始服務器和備份服務器之間直接進行網(wǎng)絡通訊的消耗很小,這種方案節(jié)省了會話數(shù)據(jù)“恢復”的階段,因為會話信息已經(jīng)在備份服務器的內(nèi)存中了。
3.4 應用服務器基于J2EE的方案
介紹應用服務器的集群方案之前,有必要介紹一下J2EE,因為J2EE已經(jīng)是一個分布式企業(yè)級應用開發(fā)與部署的事實標準,應用服務器的集群方案實際上是基于J2EE的某些標準實現(xiàn)的。
在J2EE中,業(yè)務邏輯被封裝成可復用的組件,組件在分布式服務器的組件容器中運行,容器間通過相關(guān)的協(xié)議進行通訊,實現(xiàn)組件間的相互調(diào)用。所以,我們看到的網(wǎng)絡上客戶端或者Web服務器和應用服務器之間的通信過程,在J2EE實現(xiàn)上是組件之間的調(diào)用或者是組建對容器服務的調(diào)用。這種調(diào)用在J2EE的規(guī)范中分為兩個階段,一是對JNDI服務器訪問,獲得要調(diào)用的EJB組件的代理(EJB Stub),二是對EJB組件的調(diào)用。
對JNDI訪問的集群方案分為共享全局JNDI樹方案,獨立的JNDI方案和具有高可用性的中央集中JNDI方案,每種方案都可以實現(xiàn)JNDI服務提供的高可用性。
而在對EJB組件的調(diào)用階段,客戶端實際上只能調(diào)用一個叫做“Stub”的本地對象,這個本地的“Stub”和遠程的EJB有相同的接口,起到代理的作用。Stub知道如何通過RMI/IIOP協(xié)議在網(wǎng)絡上找到真正的對象。對于在調(diào)用EJB Stub過程中的集群方案,主要有以下3種方式:
●Smart Stub:在Stub代碼中加入特殊的行為,但是這些代碼對于客戶端而言又是透明的(客戶端程序?qū)@些代碼一無所知),這些代碼包含了一個可訪問的目標服務器的列表,也能夠檢測到目標服務器的失敗,同時還包含了很復雜的負載均衡和失敗轉(zhuǎn)移的邏輯來分發(fā)請求。
●IIOP運行庫:負載均衡和失敗轉(zhuǎn)移的邏輯集成在IIOP運行庫中,這樣就使得Stub很小并且不摻雜其他代碼。
●LSD(LocatiON Service Daemon):LSD的作用是EJB客戶端的代理,在這種方案中,EJB客戶端通過查找JNDI獲取一個Stub,這個Stub中包含的路由信息指向LSD,而不是指向真正的擁有這個EJB的應用服務器。所以,LSD收到客戶端的請求之后,根據(jù)其負載均衡和失敗轉(zhuǎn)移的邏輯將請求分發(fā)到不同的應用服務器實例。
3.5 數(shù)據(jù)庫服務器方案
對于數(shù)據(jù)庫服務器的集群方案,一般的方法有兩種:一種是基于操作系統(tǒng)提供的集群軟件,比如各種HA軟件等;另一種是數(shù)據(jù)庫軟件本身提供的集群軟件。
3.5.1 HA軟件
HA軟件的工作過程大致如下:
(1)在一個HA網(wǎng)絡環(huán)境中,將網(wǎng)絡分成TCP/IP網(wǎng)絡和非TCP/IP網(wǎng)絡。TCP/IP網(wǎng)絡即應用客戶端和服務器之間互相通*問的公共網(wǎng),非TCP/IP網(wǎng)絡是HA軟件的私有網(wǎng)絡,最簡單的可以是一條“Heart-Beat”線,HA技術(shù)利用私有網(wǎng)絡,對HA環(huán)境中的各節(jié)點進行監(jiān)控替代TCP/IP的通訊路徑。
(2)在一個HA網(wǎng)絡上,各個節(jié)點上的TCP/IP網(wǎng)絡、非TCP/IP網(wǎng)絡會不斷地發(fā)送并接收Keep-Alive消息,一旦向某個HA節(jié)點連續(xù)發(fā)送一定數(shù)量包都丟失后就可確認對方節(jié)點發(fā)生故障。當某個節(jié)點的主用網(wǎng)卡(Service Adapter)發(fā)生故障時,該節(jié)點的HA代理就會進行網(wǎng)卡切換,將原來Service Adapter的IP地址轉(zhuǎn)移到新的Standby Adapter上,而Standby的地址轉(zhuǎn)移到故障網(wǎng)卡上,同時進行網(wǎng)絡上其他節(jié)點的ARP的刷新,這樣就實現(xiàn)了網(wǎng)卡的可靠性保證。
?。?)如果TCP/IP網(wǎng)絡和非TCP/IP網(wǎng)絡上的K-A全部丟失,則HA軟件判斷該節(jié)點發(fā)生故障,并產(chǎn)生資源接管,即共享磁盤陳列上的資源由備份節(jié)點接管;同時發(fā)生IP地址接管,即HA軟件將故障節(jié)點的Service IP AddrESS轉(zhuǎn)移到備份節(jié)點上,使網(wǎng)絡上的Client仍然使用這個IP地址。同樣發(fā)生應用接管,該應用在接管節(jié)點上自動重啟,從而使系統(tǒng)能繼續(xù)對外服務。
3.5.2 數(shù)據(jù)庫集群軟件
我們以O(shè)RACLE的真正應用集群(Real Application Cluster,RAC)軟件為例,介紹數(shù)據(jù)庫集群軟件的主要特點。
?。?)共享磁盤
與Single-Instance Oracle的存儲方式最主要的不同之處在于RAC存儲必須將所有RAC中數(shù)據(jù)文件存放在共享設(shè)備中,以便訪問相同Database的Instance能夠共享。同時,為了能夠使每個Instance能夠獨立操作,也為了系統(tǒng)恢復時其他Instance能找到相關(guān)的操作痕跡,RAC數(shù)據(jù)庫與單實例數(shù)據(jù)庫在存儲結(jié)構(gòu)上還存在以下不同:
?。?)每一個Instance都有自己的SGA(系統(tǒng)全局區(qū))。
?。?)每一個Instance都有自己的Background Process。
?。?)每一個Instance都有自己的Redo Logs。
?。?)每一個Instance都有自己的Undo表空間。
RAC也不能使用傳統(tǒng)的文件系統(tǒng),因為傳統(tǒng)的文件系統(tǒng)不支持多系統(tǒng)的并行掛載,必須將文件存儲在沒有任何文件系統(tǒng)的裸設(shè)備或是支持多系統(tǒng)并發(fā)訪問的文件系統(tǒng)中。
RAC操作要求在所有Instance中對控制共享資源的訪問進行同步。RAC使用Global Resource Directory來記錄Cluster Database中資源的使用信息,Global Cache Service(GCS)和Global Enqueue Service(GES)管理GRD中的信息。每個Instance在進行讀寫操作后,要由GCS或者GES按照嚴格的流程同步到其他Instance的Buffer中。
?。?)緩存融合(Cache Fusion)
在RAC環(huán)境中,每個實例的內(nèi)存結(jié)構(gòu)和后臺進程都是相同的,它們看起來像單一系統(tǒng)的一樣。每個實例的SGA內(nèi)有一個緩沖區(qū),使用Cache Fusion技術(shù),每個實例就像使用單一緩存一樣使用集群實例的緩存來處理數(shù)據(jù)庫。Cache Fusion技術(shù)可以最大限度地降低磁盤I/O,優(yōu)化數(shù)據(jù)讀寫。節(jié)點之間會產(chǎn)生不小的網(wǎng)絡通信和CPU的開銷,因此雙節(jié)點RAC的性能不會是單節(jié)點性能的兩倍。
(3)透明應用切換
當RAC群集中的一個節(jié)點發(fā)生了故障,故障節(jié)點上所有保存在內(nèi)存中運行的事務會丟失,Oracle將故障節(jié)點所擁有數(shù)據(jù)塊的控制權(quán)限重新轉(zhuǎn)交給正常節(jié)點,此過程稱為全局緩存服務重置。在全局緩存服務重置發(fā)生時,RAC中所有服務器都會被凍結(jié),所有應用程序?qū)⒈粧炱?,GCS將不會響應群集中任何節(jié)點發(fā)出的請求;重置后,Oracle讀取日志記錄,確定并鎖定需要恢復的頁面,并執(zhí)行回滾,此時數(shù)據(jù)庫恢復可用。
3.6 應用軟件的系統(tǒng)恢復方案
即使我們采取了前面所有的措施,也需要考慮在前面方案失敗的情況下,即系統(tǒng)底層軟件或者硬件發(fā)生錯誤而導致系統(tǒng)重啟時的處理辦法。
系統(tǒng)在重啟前,系統(tǒng)中正在運行的有若干個流程,每個流程都處于不同的狀態(tài),應用軟件的恢復方案就是要保證系統(tǒng)重啟后,這些狀態(tài)都能夠恢復并自動運行到結(jié)束狀態(tài)。為此,系統(tǒng)在運行過程中,所有消息和流程的狀態(tài)都需要在修改的時候保存在數(shù)據(jù)庫中,而不能僅僅保存在內(nèi)存中,在System Recover的時候,需要檢查數(shù)據(jù)庫中所有沒有到最終狀態(tài)的消息和流程并進行后續(xù)處理。
CSMS在System Recover后實現(xiàn)過程如下:
?。?)恢復所有消息:恢復CSMS發(fā)出的消息,恢復CSMS收到的消息。
?。?)恢復申請流程。
?。?)恢復注銷流程。
?。?)恢復停機相關(guān)流程。
?。?)恢復審計流程。
?。?)檢查當天的生效廣播。
?。?)檢查當天的同步。
(8)檢查當月的同步。
系統(tǒng)恢復的關(guān)鍵就是要清楚每個流程的不同狀態(tài),比如在消息的恢復中,對于從CSMS發(fā)送出去的NP消息,狀態(tài)包括:
●Init(初始)。
●Sending(發(fā)送中):該消息已經(jīng)發(fā)送給SOA/LSMS,等待ACK。
●Wait Send(等待發(fā)送):ACK超時重發(fā)。
●Sent(發(fā)送成功):收到ACK信息。
●Complete(完成):收到該NP消息(請求/指示)的回復(響應/確認),并已經(jīng)成功發(fā)送相應的ACK。
對于CSMS接收到的NP消息,狀態(tài)包括:
●Init(初始)。
●Processing(處理中):表示系統(tǒng)正在處理該NP消息,主要包括將該NP消息保存入系統(tǒng),根據(jù)該NP消息的類型,選擇需要處理的方式。
●Processed(處理結(jié)束):表示系統(tǒng)已經(jīng)處理結(jié)束該NP消息。
●Replying(正在發(fā)送回復消息):系統(tǒng)將組織好的NP回復消息已經(jīng)發(fā)送到SOA/LSMS,該消息沒有收到ACK。
●Wait Reply(等待回復):ACK超時等待重發(fā)。
●Complete(完成):系統(tǒng)收到該消息的ACK信息。
對于系統(tǒng)的其他恢復流程,方法類似不再贅述。
3.7 磁盤陣列的RAID和磁帶庫備份方案
系統(tǒng)高可靠性最后的考慮就是存儲設(shè)備,以目前的技術(shù)而言,有效的存儲方案不僅可以保證存儲數(shù)據(jù)的安全可靠,還能夠提高硬盤讀寫的速度,常用的技術(shù)就是RAID。
RAID技術(shù)按照級別可以分為RAID0,RAID1,RAID5等,不同級別RAID的存儲效率不同,當硬盤出現(xiàn)故障時能夠恢復的時間也不相同,具體技術(shù)可以參考相關(guān)技術(shù)文檔。
為了進一步增加數(shù)據(jù)存儲的保護功能,系統(tǒng)一般還會有其他介質(zhì)的備份方案,如磁帶庫備份。磁盤陣列的數(shù)據(jù)按照一定的規(guī)則備份到磁帶庫上,一方面可以增加存儲設(shè)備的容量,同時對數(shù)據(jù)保護又增加了一層保障。
4 結(jié)束語
作為號碼攜帶集中管理系統(tǒng)的重要性能指標之一,高可用性具有十分重要的意義。因為高可用性需要考慮到系統(tǒng)的各個層面,相對也比較復雜。尤其在各種新的IT技術(shù)層出不窮的今天,研究各種高可用性技術(shù),選擇合適的高可用性技術(shù)方案,應作為系統(tǒng)架構(gòu)設(shè)計者和相關(guān)技術(shù)研究人員的重點研究內(nèi)容。本文僅作為拋磚引玉,對號碼攜帶集中管理系統(tǒng)的各種高可用技術(shù)進行了簡單的分析和總結(jié),相信這些高可用性技術(shù)對類似系統(tǒng)的設(shè)計具有一定的參考意義。