號碼攜帶集中管理系統的高可用技術(shù)應用

　?。?）健康檢查

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

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

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

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

　?。?）會(huì )話(huà)失敗轉移

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　3.5.1 HA軟件

　　HA軟件的工作過(guò)程大致如下：

　?。?）在一個(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ò )即應用客戶(hù)端和服務(wù)器之間互相通*問(wèn)的公共網(wǎng)，非TCP/IP網(wǎng)絡(luò )是HA軟件的私有網(wǎng)絡(luò )，最簡(jiǎn)單的可以是一條“Heart-Beat”線(xiàn)，HA技術(shù)利用私有網(wǎng)絡(luò )，對HA環(huán)境中的各節點(diǎn)進(jìn)行監控替代TCP/IP的通訊路徑。

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

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