新聞中心

        EEPW首頁 > 手機與無線通信 > 設計應用 > 號碼攜帶集中管理系統的高可用技術應用

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

        作者: 時間:2010-08-27 來源:網絡 收藏

          (3)健康檢查

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

          (4)會話粘滯

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

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

          (5)會話失敗轉移

          會話失敗轉移的實現機制是在某個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軟件的工作過程大致如下:

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

          (2)在一個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地址。同樣發生應用接管,該應用在接管節點上自動重啟,從而使系統能繼續對外服務。



        評論


        相關推薦

        技術專區

        關閉
        主站蜘蛛池模板: 黄石市| 红原县| 汤阴县| 峨山| 称多县| 乌鲁木齐市| 德清县| 钟祥市| 林芝县| 务川| 文登市| 衡阳县| 梁河县| 蛟河市| 哈尔滨市| 望江县| 宁海县| 陆河县| 临高县| 奉新县| 商城县| 凤阳县| 灵寿县| 通海县| 青州市| 凤山市| 东源县| 临城县| 龙川县| 柏乡县| 咸丰县| 通州区| 中山市| 吴忠市| 鹿邑县| 巴中市| 吐鲁番市| 东台市| 东阿县| 济源市| 凭祥市|