1  引言

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

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

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

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

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

　?。?）網絡層：是和運營商連接的部分，主要需要考慮，如何避免傳輸單點故障，如何避免網絡設備單點故障？

　　（2）Web服務器層：如何保證Web服務器的單點故障？如果提供多臺Web服務器，如何在之間進行資源協調？

　?。?）應用服務器層：Web服務器提交請求給應用服務器后，如何避免應用服務器的單點故障及多臺應用服務器的資源協調？

　?。?）數據庫服務器層：應用服務器向數據庫服務器提交請求時，如何避免數據庫服務器的單點故障及多臺之間的資源協調？

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

　?。?）數據層：如何保證數據存儲安全可靠？

　　為了回答上述問題，我們需要對各種高可用性技術進行研究和總結。

　　3  高可用性技術研究

　　3.1  CSMS系統(tǒng)架構

　　圖1所示的是CSMS系統(tǒng)組織架構。

圖1  CSMS系統(tǒng)組織架構

　　為了保證系統(tǒng)的高可用性，防止出現單點故障，系統(tǒng)的每個功能層在硬件設備上都采用冗余配置，同時通過各種軟件方案設計，實現系統(tǒng)高可用性。

　　3.2  網絡方案

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

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

　　3.3  Web服務器的負載均衡器方案

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

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

　?。?）單點接入

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

　?。?）實現負載均衡算法

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

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

　　（4）會話粘滯

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

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

　　（5）會話失敗轉移

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

　　如何備份會話數據也有不同的方案，比較主流的方案包括數據庫方案和內存復制方案。

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

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

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

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

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

　　3.4  應用服務器基于J2EE的方案

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

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

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

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

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

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

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

　　3.5  數據庫服務器方案

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

　　3.5.1  HA軟件

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

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

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

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

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

　?。?）共享磁盤

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

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

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

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

　　（4）每一個Instance都有自己的Undo表空間。

　　RAC也不能使用傳統(tǒng)的文件系統(tǒng)，因為傳統(tǒng)的文件系統(tǒng)不支持多系統(tǒng)的并行掛載，必須將文件存儲在沒有任何文件系統(tǒng)的裸設備或是支持多系統(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)境中，每個實例的內存結構和后臺進程都是相同的，它們看起來像單一系統(tǒng)的一樣。每個實例的SGA內有一個緩沖區(qū)，使用Cache Fusion技術，每個實例就像使用單一緩存一樣使用集群實例的緩存來處理數據庫。Cache Fusion技術可以最大限度地降低磁盤I/O，優(yōu)化數據讀寫。節(jié)點之間會產生不小的網絡通信和CPU的開銷，因此雙節(jié)點RAC的性能不會是單節(jié)點性能的兩倍。

　?。?）透明應用切換

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

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

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

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

　　CSMS在System Recover后實現過程如下：

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

　?。?）恢復申請流程。

　?。?）恢復注銷流程。

　?。?）恢復停機相關流程。

　?。?）恢復審計流程。

　?。?）檢查當天的生效廣播。

　　（7）檢查當天的同步。

　　（8）檢查當月的同步。

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

　　●Init（初始）。

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

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

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

　　●Complete（完成）：收到該NP消息（請求/指示）的回復（響應/確認），并已經成功發(fā)送相應的ACK。

　　對于CSMS接收到的NP消息，狀態(tài)包括：

　　●Init（初始）。

　　●Processing（處理中）：表示系統(tǒng)正在處理該NP消息，主要包括將該NP消息保存入系統(tǒng)，根據該NP消息的類型，選擇需要處理的方式。

　　●Processed（處理結束）：表示系統(tǒng)已經處理結束該NP消息。

　　●Replying（正在發(fā)送回復消息）：系統(tǒng)將組織好的NP回復消息已經發(fā)送到SOA/LSMS，該消息沒有收到ACK。

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

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

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

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

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

　　RAID技術按照級別可以分為RAID0，RAID1，RAID5等，不同級別RAID的存儲效率不同，當硬盤出現故障時能夠恢復的時間也不相同，具體技術可以參考相關技術文檔。

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

　　4  結束語

　　作為號碼攜帶集中管理系統(tǒng)的重要性能指標之一，高可用性具有十分重要的意義。因為高可用性需要考慮到系統(tǒng)的各個層面，相對也比較復雜。尤其在各種新的IT技術層出不窮的今天，研究各種高可用性技術，選擇合適的高可用性技術方案，應作為系統(tǒng)架構設計者和相關技術研究人員的重點研究內容。本文僅作為拋磚引玉，對號碼攜帶集中管理系統(tǒng)的各種高可用技術進行了簡單的分析和總結，相信這些高可用性技術對類似系統(tǒng)的設計具有一定的參考意義。