號碼攜帶集中管理系統(tǒng)的高可用技術應用

　?。?）健康檢查

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

　?。?）會話粘滯

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

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

　?。?）會話失敗轉移

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

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

　　數(shù)據(jù)庫方案就是在合適的時間讓Web服務器將會話數(shù)據(jù)存儲到數(shù)據(jù)庫中。當失敗轉移發(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è)務邏輯被封裝成可復用的組件，組件在分布式服務器的組件容器中運行，容器間通過相關的協(xié)議進行通訊，實現(xiàn)組件間的相互調用。所以，我們看到的網(wǎng)絡上客戶端或者Web服務器和應用服務器之間的通信過程，在J2EE實現(xiàn)上是組件之間的調用或者是組建對容器服務的調用。這種調用在J2EE的規(guī)范中分為兩個階段，一是對JNDI服務器訪問，獲得要調用的EJB組件的代理（EJB Stub），二是對EJB組件的調用。

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

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

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

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

　　●LSD（LocatiON Service Daemon）：LSD的作用是EJB客戶端的代理，在這種方案中，EJB客戶端通過查找JNDI獲取一個Stub，這個Stub中包含的路由信息指向LSD，而不是指向真正的擁有這個EJB的應用服務器。所以，LSD收到客戶端的請求之后，根據(jù)其負載均衡和失敗轉移的邏輯將請求分發(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技術利用私有網(wǎng)絡，對HA環(huán)境中的各節(jié)點進行監(jiān)控替代TCP/IP的通訊路徑。

　?。?）在一個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地址轉移到新的Standby Adapter上，而Standby的地址轉移到故障網(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轉移到備份節(jié)點上，使網(wǎng)絡上的Client仍然使用這個IP地址。同樣發(fā)生應用接管，該應用在接管節(jié)點上自動重啟，從而使系統(tǒng)能繼續(xù)對外服務。