號(hào)碼攜帶集中管理系統(tǒng)的高可用技術(shù)應(yīng)用分析

1  引言

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

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

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

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

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

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

　?。?）Web服務(wù)器層：如何保證Web服務(wù)器的單點(diǎn)故障？如果提供多臺(tái)Web服務(wù)器，如何在之間進(jìn)行資源協(xié)調(diào)？

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

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

　?。?）應(yīng)用軟件：即使我們采取了各種措施，還是存在服務(wù)器硬件宕機(jī)的可能性。在系統(tǒng)重啟后，我們應(yīng)用軟件如何設(shè)計(jì)保證系統(tǒng)能快速恢復(fù)？

　?。?）數(shù)據(jù)層：如何保證數(shù)據(jù)存儲(chǔ)安全可靠？

　　為了回答上述問題，我們需要對各種高可用性技術(shù)進(jìn)行研究和總結(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)單點(diǎn)故障，系統(tǒng)的每個(gè)功能層在硬件設(shè)備上都采用冗余配置，同時(shí)通過各種軟件方案設(shè)計(jì)，實(shí)現(xiàn)系統(tǒng)高可用性。

　　3.2  網(wǎng)絡(luò)方案

　　在網(wǎng)絡(luò)方案上，系統(tǒng)和每個(gè)運(yùn)營商之間的專線采用155M POS或者M(jìn)STP雙光纜接入，利用傳輸網(wǎng)絡(luò)的冗余和自愈能力，保證系統(tǒng)物理接入線路的高可用性。每個(gè)運(yùn)營商的兩條光纜分別接入到系統(tǒng)的兩臺(tái)接入路由器上，盡量避免路由器設(shè)備的單點(diǎn)故障。每臺(tái)路由器分別配置了多個(gè)網(wǎng)卡分別接入多個(gè)運(yùn)營商的專線，防止出現(xiàn)單板卡故障影響到更多的運(yùn)營商接入。

　　在路由器對運(yùn)營商側(cè)的方案設(shè)計(jì)上，需要采用動(dòng)態(tài)路由協(xié)議，當(dāng)某臺(tái)路由器到某個(gè)運(yùn)營商的某條缺省配置路由出現(xiàn)故障時(shí)（比如線路故障或板卡故障），需要將備選路由廣播到所有相關(guān)設(shè)備上，新的通信連接則按照新的路由進(jìn)行通信。在路由器對防火墻的方案設(shè)計(jì)上，需要采用VRRP協(xié)議進(jìn)行動(dòng)態(tài)IP地址綁定，即兩臺(tái)路由器下聯(lián)到防火墻的IP為一個(gè)虛擬地址，缺省時(shí)綁定在某個(gè)路由器的實(shí)際地址上，當(dāng)需要切換時(shí)，將虛擬地址綁定在另外一臺(tái)路由器的實(shí)際地址上，而對于防火墻來說，不需要做任何改變就完成了通信的切換過程。

　　3.3  Web服務(wù)器的負(fù)載均衡器方案

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

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

　?。?）單點(diǎn)接入

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

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

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

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

　?。?）會(huì)話粘滯

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

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

　?。?）會(huì)話失敗轉(zhuǎn)移

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　3.5.1  HA軟件

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

　?。?）在一個(gè)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é)點(diǎn)進(jìn)行監(jiān)控替代TCP/IP的通訊路徑。

　?。?）在一個(gè)HA網(wǎng)絡(luò)上，各個(gè)節(jié)點(diǎn)上的TCP/IP網(wǎng)絡(luò)、非TCP/IP網(wǎng)絡(luò)會(huì)不斷地發(fā)送并接收Keep-Alive消息，一旦向某個(gè)HA節(jié)點(diǎn)連續(xù)發(fā)送一定數(shù)量包都丟失后就可確認(rèn)對方節(jié)點(diǎn)發(fā)生故障。當(dāng)某個(gè)節(jié)點(diǎn)的主用網(wǎng)卡（Service Adapter）發(fā)生故障時(shí)，該節(jié)點(diǎn)的HA代理就會(huì)進(jìn)行網(wǎng)卡切換，將原來Service Adapter的IP地址轉(zhuǎn)移到新的Standby Adapter上，而Standby的地址轉(zhuǎn)移到故障網(wǎng)卡上，同時(shí)進(jìn)行網(wǎng)絡(luò)上其他節(jié)點(diǎn)的ARP的刷新，這樣就實(shí)現(xiàn)了網(wǎng)卡的可靠性保證。

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

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

　?。?）共享磁盤

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

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

　?。?）每一個(gè)Instance都有自己的Background Process。

　?。?）每一個(gè)Instance都有自己的Redo Logs。

　?。?）每一個(gè)Instance都有自己的Undo表空間。

　　RAC也不能使用傳統(tǒng)的文件系統(tǒng)，因?yàn)閭鹘y(tǒng)的文件系統(tǒng)不支持多系統(tǒng)的并行掛載，必須將文件存儲(chǔ)在沒有任何文件系統(tǒng)的裸設(shè)備或是支持多系統(tǒng)并發(fā)訪問的文件系統(tǒng)中。

　　RAC操作要求在所有Instance中對控制共享資源的訪問進(jìn)行同步。RAC使用Global Resource Directory來記錄Cluster Database中資源的使用信息，Global Cache Service（GCS）和Global Enqueue Service（GES）管理GRD中的信息。每個(gè)Instance在進(jìn)行讀寫操作后，要由GCS或者GES按照嚴(yán)格的流程同步到其他Instance的Buffer中。

　　（2）緩存融合（Cache Fusion）

　　在RAC環(huán)境中，每個(gè)實(shí)例的內(nèi)存結(jié)構(gòu)和后臺(tái)進(jìn)程都是相同的，它們看起來像單一系統(tǒng)的一樣。每個(gè)實(shí)例的SGA內(nèi)有一個(gè)緩沖區(qū)，使用Cache Fusion技術(shù)，每個(gè)實(shí)例就像使用單一緩存一樣使用集群實(shí)例的緩存來處理數(shù)據(jù)庫。Cache Fusion技術(shù)可以最大限度地降低磁盤I/O，優(yōu)化數(shù)據(jù)讀寫。節(jié)點(diǎn)之間會(huì)產(chǎn)生不小的網(wǎng)絡(luò)通信和CPU的開銷，因此雙節(jié)點(diǎn)RAC的性能不會(huì)是單節(jié)點(diǎn)性能的兩倍。

　?。?）透明應(yīng)用切換

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

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

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

　　系統(tǒng)在重啟前，系統(tǒng)中正在運(yùn)行的有若干個(gè)流程，每個(gè)流程都處于不同的狀態(tài)，應(yīng)用軟件的恢復(fù)方案就是要保證系統(tǒng)重啟后，這些狀態(tài)都能夠恢復(fù)并自動(dòng)運(yùn)行到結(jié)束狀態(tài)。為此，系統(tǒng)在運(yùn)行過程中，所有消息和流程的狀態(tài)都需要在修改的時(shí)候保存在數(shù)據(jù)庫中，而不能僅僅保存在內(nèi)存中，在System Recover的時(shí)候，需要檢查數(shù)據(jù)庫中所有沒有到最終狀態(tài)的消息和流程并進(jìn)行后續(xù)處理。

　　CSMS在System Recover后實(shí)現(xiàn)過程如下：

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

　?。?）恢復(fù)申請流程。

　　（3）恢復(fù)注銷流程。

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

　?。?）恢復(fù)審計(jì)流程。

　?。?）檢查當(dāng)天的生效廣播。

　?。?）檢查當(dāng)天的同步。

　?。?）檢查當(dāng)月的同步。

　　系統(tǒng)恢復(fù)的關(guān)鍵就是要清楚每個(gè)流程的不同狀態(tài)，比如在消息的恢復(fù)中，對于從CSMS發(fā)送出去的NP消息，狀態(tài)包括：

　　●Init（初始）。

　　●Sending（發(fā)送中）：該消息已經(jīng)發(fā)送給SOA/LSMS，等待ACK。

　　●Wait Send（等待發(fā)送）：ACK超時(shí)重發(fā)。

　　●Sent（發(fā)送成功）：收到ACK信息。

　　●Complete（完成）：收到該NP消息（請求/指示）的回復(fù)（響應(yīng)/確認(rèn)），并已經(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ā)送回復(fù)消息）：系統(tǒng)將組織好的NP回復(fù)消息已經(jīng)發(fā)送到SOA/LSMS，該消息沒有收到ACK。

　　●Wait Reply（等待回復(fù)）：ACK超時(shí)等待重發(fā)。

　　●Complete（完成）：系統(tǒng)收到該消息的ACK信息。

　　對于系統(tǒng)的其他恢復(fù)流程，方法類似不再贅述。

　　3.7  磁盤陣列的RAID和磁帶庫備份方案

　　系統(tǒng)高可靠性最后的考慮就是存儲(chǔ)設(shè)備，以目前的技術(shù)而言，有效的存儲(chǔ)方案不僅可以保證存儲(chǔ)數(shù)據(jù)的安全可靠，還能夠提高硬盤讀寫的速度，常用的技術(shù)就是RAID。

　　RAID技術(shù)按照級(jí)別可以分為RAID0，RAID1，RAID5等，不同級(jí)別RAID的存儲(chǔ)效率不同，當(dāng)硬盤出現(xiàn)故障時(shí)能夠恢復(fù)的時(shí)間也不相同，具體技術(shù)可以參考相關(guān)技術(shù)文檔。

　　為了進(jìn)一步增加數(shù)據(jù)存儲(chǔ)的保護(hù)功能，系統(tǒng)一般還會(huì)有其他介質(zhì)的備份方案，如磁帶庫備份。磁盤陣列的數(shù)據(jù)按照一定的規(guī)則備份到磁帶庫上，一方面可以增加存儲(chǔ)設(shè)備的容量，同時(shí)對數(shù)據(jù)保護(hù)又增加了一層保障。

　　4  結(jié)束語

　　作為號(hào)碼攜帶集中管理系統(tǒng)的重要性能指標(biāo)之一，高可用性具有十分重要的意義。因?yàn)楦呖捎眯孕枰紤]到系統(tǒng)的各個(gè)層面，相對也比較復(fù)雜。尤其在各種新的IT技術(shù)層出不窮的今天，研究各種高可用性技術(shù)，選擇合適的高可用性技術(shù)方案，應(yīng)作為系統(tǒng)架構(gòu)設(shè)計(jì)者和相關(guān)技術(shù)研究人員的重點(diǎn)研究內(nèi)容。本文僅作為拋磚引玉，對號(hào)碼攜帶集中管理系統(tǒng)的各種高可用技術(shù)進(jìn)行了簡單的分析和總結(jié)，相信這些高可用性技術(shù)對類似系統(tǒng)的設(shè)計(jì)具有一定的參考意義。