在號碼攜帶系統(tǒng)中，CSMS（集中管理系統(tǒng)）匯總著全國所有運營商號碼攜帶用戶的基本數(shù)據(jù)和號碼攜帶規(guī)則，扮演著號碼攜帶業(yè)務(wù)提供管理者和仲裁者的角色，地位十分重要。CSMS和運營商的號碼攜帶營業(yè)生產(chǎn)系統(tǒng)一起，實時為用戶提供號碼攜帶申請業(yè)務(wù)，必須按照電信級系統(tǒng)的要求，提供24h×7d×365d時間內(nèi)99.99%的服務(wù)可用性。因此，CSMS系統(tǒng)的高可用性方案十分重要。

　　高可用性（High Availability）一般是指通過盡量縮短系統(tǒng)停機時間，提高系統(tǒng)和應(yīng)用的可用性。為了提高系統(tǒng)可用性，一種方法是提高計算機各個部件的可靠性，但這種方法并不可靠，因為單一服務(wù)器可靠性再高也存在單點故障的潛在隱患，所以目前業(yè)界比較成熟的做法是采用集群（CluSTer）的方案。它通過加入冗余設(shè)備使得在一個設(shè)備出錯而停止服務(wù)的時候，這些冗余的設(shè)備可以繼續(xù)提供服務(wù)。本文中，高可用性的含義還包括“快速恢復”，即一旦由于系統(tǒng)中止并重啟后，業(yè)務(wù)應(yīng)用能夠盡快恢復。

　　本文主要介紹了在CSMS中為了實現(xiàn)系統(tǒng)的整體高可用性，在各個層面可以采用的集群技術(shù)。

　　2? 系統(tǒng)高可用技術(shù)的應(yīng)用范圍

　　在號碼攜帶系統(tǒng)中，從和運營商接口側(cè)到CSMS的核心數(shù)據(jù)層主要包括以下功能層，高可用方案主要圍繞這些層面來展開。

　　（1）網(wǎng)絡(luò)層：是和運營商連接的部分，主要需要考慮，如何避免傳輸單點故障，如何避免網(wǎng)絡(luò)設(shè)備單點故障？

　　（2）Web服務(wù)器層：如何保證Web服務(wù)器的單點故障？如果提供多臺Web服務(wù)器，如何在之間進行資源協(xié)調(diào)？

　　（3）應(yīng)用服務(wù)器層：Web服務(wù)器提交請求給應(yīng)用服務(wù)器后，如何避免應(yīng)用服務(wù)器的單點故障及多臺應(yīng)用服務(wù)器的資源協(xié)調(diào)？

　　（4）數(shù)據(jù)庫服務(wù)器層：應(yīng)用服務(wù)器向數(shù)據(jù)庫服務(wù)器提交請求時，如何避免數(shù)據(jù)庫服務(wù)器的單點故障及多臺之間的資源協(xié)調(diào)？

　　（5）應(yīng)用軟件：即使我們采取了各種措施，還是存在服務(wù)器硬件宕機的可能性。在系統(tǒng)重啟后，我們應(yī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)絡(luò)方案

　　在網(wǎng)絡(luò)方案上，系統(tǒng)和每個運營商之間的專線采用155M POS或者MSTP雙光纜接入，利用傳輸網(wǎng)絡(luò)的冗余和自愈能力，保證系統(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服務(wù)器的負載均衡器方案

　　從客戶端的請求經(jīng)過網(wǎng)絡(luò)設(shè)備后，將首先到達Web服務(wù)器。從系統(tǒng)的高可用性設(shè)計角度出發(fā)，系統(tǒng)將部署多臺Web服務(wù)器進行集群。Web服務(wù)器之間進行集群包括Web負載均衡和會話的失敗轉(zhuǎn)移兩個方面。

　　負載均衡可以采用多種技術(shù)，比如采用硬件負載均衡器，也可以在某個Web服務(wù)器上部署負載均衡軟件，由這臺Web服務(wù)器兼作負載均衡器。負載均衡器最主要的特征包括：

　　（1）單點接入

　　從客戶端的角度看，多臺Web服務(wù)器只有一個地址，就是負載均衡器的服務(wù)地址。這樣做的好處有兩點：一是客戶端不需要配置多個Web服務(wù)器地址，比較方便；二是可以向客戶端網(wǎng)絡(luò)屏蔽網(wǎng)內(nèi)具體的設(shè)備的地址信息，對網(wǎng)絡(luò)保護具有一定作用。

　　（2）實現(xiàn)負載均衡算法

　　當客戶端請求到來的時候，負載均衡器能夠決定把這個請求轉(zhuǎn)發(fā)到后臺的哪個Web服務(wù)器進行處理。主流算法包括：輪循算法，隨機算法和權(quán)重算法，無論哪種算法，負載均衡器總是試圖讓每個服務(wù)器實例分擔等同的壓力。

　　（3）健康檢查

　　一旦某一個Web服務(wù)器停止工作，負載均衡器能夠檢測到并且不再把請求轉(zhuǎn)發(fā)到這個服務(wù)器。同樣，當這個失敗的服務(wù)器重新開始工作的時候，負載均衡器也能夠檢測到，并且開始向它轉(zhuǎn)發(fā)請求。

　　（4）會話粘滯

　　所有的Web應(yīng)用都會有一些會話狀態(tài)，比如號碼攜帶系統(tǒng)中某個流程是否結(jié)束的信息，某條請求消息是否接收到對應(yīng)的ACK信息或者響應(yīng)信息等。因為HTTP協(xié)議本身是無狀態(tài)的，所以會話狀態(tài)就需要記錄在某個地方，并且和客戶端關(guān)聯(lián)，以便于下次請求的時候能夠很方便地取出來。當進行負載均衡的時候，對于某一個確定的會話來說，把請求轉(zhuǎn)發(fā)到上一次它所請求到的服務(wù)器實例是一個很好的選擇，否則的話，可能會導致應(yīng)用不能正常工作。

　　因為一般來說會話狀態(tài)是存儲在某個Web服務(wù)器實例的內(nèi)存中的，所以對于負載均衡器來說，“會話粘滯”的特征非常重要。但是，如果某個Web服務(wù)器由于某種原因失敗，那么在這個服務(wù)器上的會話狀態(tài)就會全部丟失。負載均衡器能夠檢測到這個錯誤并且不再把請求轉(zhuǎn)發(fā)到這個服務(wù)器，但是由于會話狀態(tài)的丟失，可能會引發(fā)其他錯誤。因此，負載均衡器必須還要有另一個重要功能“會話失敗轉(zhuǎn)移”。

　　（5）會話失敗轉(zhuǎn)移

　　會話失敗轉(zhuǎn)移的實現(xiàn)機制是在某個Web服務(wù)器在收到某個客戶端請求后，將會話對象備份到某個地方，以保證服務(wù)器失敗的時候會話狀態(tài)不會丟失。

　　如何備份會話數(shù)據(jù)也有不同的方案，比較主流的方案包括數(shù)據(jù)庫方案和內(nèi)存復制方案。

　　數(shù)據(jù)庫方案就是在合適的時間讓Web服務(wù)器將會話數(shù)據(jù)存儲到數(shù)據(jù)庫中。當失敗轉(zhuǎn)移發(fā)生時，另外可用的Web服務(wù)器實例接替失敗的服務(wù)器，從數(shù)據(jù)庫中將會話狀態(tài)恢復加載進來。數(shù)據(jù)庫方案的優(yōu)點是：

　　●易于實現(xiàn)。將請求處理和會話備份分離開來使得集群更健壯、更易于管理。

　　●即使整個集群都失敗了，會話數(shù)據(jù)仍然可以保存下來，可以在系統(tǒng)重啟時繼續(xù)使用。

　　數(shù)據(jù)庫事務(wù)的缺點是比較消耗資源，當會話中的數(shù)據(jù)量較大時就會受到性能的限制。

　　內(nèi)存復制方案是在備用服務(wù)器的內(nèi)存中保存會話信息，而不是在數(shù)據(jù)庫中進行持久化。和數(shù)據(jù)庫方案相比，這種方案的性能較高，在原始服務(wù)器和備份服務(wù)器之間直接進行網(wǎng)絡(luò)通訊的消耗很小，這種方案節(jié)省了會話數(shù)據(jù)“恢復”的階段，因為會話信息已經(jīng)在備份服務(wù)器的內(nèi)存中了。

　　3.4? 應(yīng)用服務(wù)器基于J2EE的方案

　　介紹應(yīng)用服務(wù)器的集群方案之前，有必要介紹一下J2EE，因為J2EE已經(jīng)是一個分布式企業(yè)級應(yīng)用開發(fā)與部署的事實標準，應(yīng)用服務(wù)器的集群方案實際上是基于J2EE的某些標準實現(xiàn)的。

　　在J2EE中，業(yè)務(wù)邏輯被封裝成可復用的組件，組件在分布式服務(wù)器的組件容器中運行，容器間通過相關(guān)的協(xié)議進行通訊，實現(xiàn)組件間的相互調(diào)用。所以，我們看到的網(wǎng)絡(luò)上客戶端或者Web服務(wù)器和應(yīng)用服務(wù)器之間的通信過程，在J2EE實現(xiàn)上是組件之間的調(diào)用或者是組建對容器服務(wù)的調(diào)用。這種調(diào)用在J2EE的規(guī)范中分為兩個階段，一是對JNDI服務(wù)器訪問，獲得要調(diào)用的EJB組件的代理（EJB Stub），二是對EJB組件的調(diào)用。

　　對JNDI訪問的集群方案分為共享全局JNDI樹方案，獨立的JNDI方案和具有高可用性的中央集中JNDI方案，每種方案都可以實現(xiàn)JNDI服務(wù)提供的高可用性。

　　而在對EJB組件的調(diào)用階段，客戶端實際上只能調(diào)用一個叫做“Stub”的本地對象，這個本地的“Stub”和遠程的EJB有相同的接口，起到代理的作用。Stub知道如何通過RMI/IIOP協(xié)議在網(wǎng)絡(luò)上找到真正的對象。對于在調(diào)用EJB Stub過程中的集群方案，主要有以下3種方式：

　　●Smart Stub：在Stub代碼中加入特殊的行為，但是這些代碼對于客戶端而言又是透明的（客戶端程序?qū)@些代碼一無所知），這些代碼包含了一個可訪問的目標服務(wù)器的列表，也能夠檢測到目標服務(wù)器的失敗，同時還包含了很復雜的負載均衡和失敗轉(zhuǎn)移的邏輯來分發(fā)請求。

　　●IIOP運行庫：負載均衡和失敗轉(zhuǎn)移的邏輯集成在IIOP運行庫中，這樣就使得Stub很小并且不摻雜其他代碼。

　　●LSD（LocatiON Service Daemon）：LSD的作用是EJB客戶端的代理，在這種方案中，EJB客戶端通過查找JNDI獲取一個Stub，這個Stub中包含的路由信息指向LSD，而不是指向真正的擁有這個EJB的應(yīng)用服務(wù)器。所以，LSD收到客戶端的請求之后，根據(jù)其負載均衡和失敗轉(zhuǎn)移的邏輯將請求分發(fā)到不同的應(yīng)用服務(wù)器實例。

　　3.5? 數(shù)據(jù)庫服務(wù)器方案

　　對于數(shù)據(jù)庫服務(wù)器的集群方案，一般的方法有兩種：一種是基于操作系統(tǒng)提供的集群軟件，比如各種HA軟件等；另一種是數(shù)據(jù)庫軟件本身提供的集群軟件。

　　3.5.1? HA軟件

　　HA軟件的工作過程大致如下：

　　（1）在一個HA網(wǎng)絡(luò)環(huán)境中，將網(wǎng)絡(luò)分成TCP/IP網(wǎng)絡(luò)和非TCP/IP網(wǎng)絡(luò)。TCP/IP網(wǎng)絡(luò)即應(yīng)用客戶端和服務(wù)器之間互相通*問的公共網(wǎng)，非TCP/IP網(wǎng)絡(luò)是HA軟件的私有網(wǎng)絡(luò)，最簡單的可以是一條“Heart-Beat”線，HA技術(shù)利用私有網(wǎng)絡(luò)，對HA環(huán)境中的各節(jié)點進行監(jiān)控替代TCP/IP的通訊路徑。

　　（2）在一個HA網(wǎng)絡(luò)上，各個節(jié)點上的TCP/IP網(wǎng)絡(luò)、非TCP/IP網(wǎng)絡(luò)會不斷地發(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)絡(luò)上其他節(jié)點的ARP的刷新，這樣就實現(xiàn)了網(wǎng)卡的可靠性保證。

　　（3）如果TCP/IP網(wǎng)絡(luò)和非TCP/IP網(wǎng)絡(luò)上的K-A全部丟失，則HA軟件判斷該節(jié)點發(fā)生故障，并產(chǎn)生資源接管，即共享磁盤陳列上的資源由備份節(jié)點接管；同時發(fā)生IP地址接管，即HA軟件將故障節(jié)點的Service IP AddrESS轉(zhuǎn)移到備份節(jié)點上，使網(wǎng)絡(luò)上的Client仍然使用這個IP地址。同樣發(fā)生應(yīng)用接管，該應(yīng)用在接管節(jié)點上自動重啟，從而使系統(tǒng)能繼續(xù)對外服務(wù)。

　　3.5.2? 數(shù)據(jù)庫集群軟件

　　我們以ORACLE的真正應(yīng)用集群（Real Application Cluster，RAC）軟件為例，介紹數(shù)據(jù)庫集群軟件的主要特點。

　　（1）共享磁盤

　　與Single-Instance Oracle的存儲方式最主要的不同之處在于RAC存儲必須將所有RAC中數(shù)據(jù)文件存放在共享設(shè)備中，以便訪問相同Database的Instance能夠共享。同時，為了能夠使每個Instance能夠獨立操作，也為了系統(tǒng)恢復時其他Instance能找到相關(guān)的操作痕跡，RAC數(shù)據(jù)庫與單實例數(shù)據(jù)庫在存儲結(jié)構(gòu)上還存在以下不同：

　　（1）每一個Instance都有自己的SGA（系統(tǒng)全局區(qū)）。

　　（2）每一個Instance都有自己的Background Process。

　　（3）每一個Instance都有自己的Redo Logs。

　　（4）每一個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中。

　　（2）緩存融合（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)絡(luò)通信和CPU的開銷，因此雙節(jié)點RAC的性能不會是單節(jié)點性能的兩倍。

　　（3）透明應(yīng)用切換

　　當RAC群集中的一個節(jié)點發(fā)生了故障，故障節(jié)點上所有保存在內(nèi)存中運行的事務(wù)會丟失，Oracle將故障節(jié)點所擁有數(shù)據(jù)塊的控制權(quán)限重新轉(zhuǎn)交給正常節(jié)點，此過程稱為全局緩存服務(wù)重置。在全局緩存服務(wù)重置發(fā)生時，RAC中所有服務(wù)器都會被凍結(jié)，所有應(yīng)用程序?qū)⒈粧炱穑珿CS將不會響應(yīng)群集中任何節(jié)點發(fā)出的請求；重置后，Oracle讀取日志記錄，確定并鎖定需要恢復的頁面，并執(zhí)行回滾，此時數(shù)據(jù)庫恢復可用。

　　3.6? 應(yīng)用軟件的系統(tǒng)恢復方案

　　即使我們采取了前面所有的措施，也需要考慮在前面方案失敗的情況下，即系統(tǒng)底層軟件或者硬件發(fā)生錯誤而導致系統(tǒng)重啟時的處理辦法。

　　系統(tǒng)在重啟前，系統(tǒng)中正在運行的有若干個流程，每個流程都處于不同的狀態(tài)，應(yīng)用軟件的恢復方案就是要保證系統(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)過程如下：

　　（1）恢復所有消息：恢復CSMS發(fā)出的消息，恢復CSMS收到的消息。

　　（2）恢復申請流程。

　　（3）恢復注銷流程。

　　（4）恢復停機相關(guān)流程。

　　（5）恢復審計流程。

　　（6）檢查當天的生效廣播。

　　（7）檢查當天的同步。

　　（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消息（請求/指示）的回復（響應(yīng)/確認），并已經(jīng)成功發(fā)送相應(yīng)的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ù)方案，應(yīng)作為系統(tǒng)架構(gòu)設(shè)計者和相關(guān)技術(shù)研究人員的重點研究內(nèi)容。本文僅作為拋磚引玉，對號碼攜帶集中管理系統(tǒng)的各種高可用技術(shù)進行了簡單的分析和總結(jié)，相信這些高可用性技術(shù)對類似系統(tǒng)的設(shè)計具有一定的參考意義。