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

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

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

　　2? 系統高可用技術的應用范圍

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

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

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

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

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

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

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

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

　　3? 高可用性技術研究

　　3.1? CSMS系統架構

　　圖1所示的是CSMS系統組織架構。

圖1? CSMS系統組織架構

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

　　3.2? 網絡方案

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

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

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

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

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

　　（1）單點接入

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

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

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

　?。?）健康檢查

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

　　（4）會話粘滯

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

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

　?。?）會話失敗轉移

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　3.5? 數據庫服務器方案

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

　　3.5.1? HA軟件

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

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

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

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

　　3.5.2? 數據庫集群軟件

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

　　（1）共享磁盤

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

　?。?）每一個Instance都有自己的SGA（系統全局區）。

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

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

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

　　RAC也不能使用傳統的文件系統，因為傳統的文件系統不支持多系統的并行掛載，必須將文件存儲在沒有任何文件系統的裸設備或是支持多系統并發訪問的文件系統中。

　　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環境中，每個實例的內存結構和后臺進程都是相同的，它們看起來像單一系統的一樣。每個實例的SGA內有一個緩沖區，使用Cache Fusion技術，每個實例就像使用單一緩存一樣使用集群實例的緩存來處理數據庫。Cache Fusion技術可以最大限度地降低磁盤I/O，優化數據讀寫。節點之間會產生不小的網絡通信和CPU的開銷，因此雙節點RAC的性能不會是單節點性能的兩倍。

　?。?）透明應用切換

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

　　3.6? 應用軟件的系統恢復方案

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

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

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

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

　?。?）恢復申請流程。

　?。?）恢復注銷流程。

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

　?。?）恢復審計流程。

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

　?。?）檢查當天的同步。

　　（8）檢查當月的同步。

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

　　●Init（初始）。

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

　　●Wait Send（等待發送）：ACK超時重發。

　　●Sent（發送成功）：收到ACK信息。

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

　　對于CSMS接收到的NP消息，狀態包括：

　　●Init（初始）。

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

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

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

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

　　●Complete（完成）：系統收到該消息的ACK信息。

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

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

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

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

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

　　4? 結束語

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