本發明涉及一種基礎設施服務層仲裁裝置及方法，包括：接收模塊，用于接收應用層的至少兩個進程發送的主備仲裁請求；仲裁模塊，與所述接收模塊連接，用于根據接收到的各所述主備仲裁請求的時間順序，將最先接收到的主備仲裁請求對應的進程仲裁為主狀態進程，將其它主備仲裁請求對應的進程仲裁為備狀態進程。通過基礎設施服務層仲裁裝置根據接收到的各所述主備仲裁請求的時間順序，將最先接收到的主備仲裁請求對應的進程仲裁為主狀態進程，將其它主備仲裁請求對應的進程仲裁為備狀態進程，根據本發明提供的基礎設施服務層仲裁裝置及方法，能夠使應用層獲得可靠的仲裁服務，提高通信業務的可靠性。

技術領域

本發明涉及通信領域，尤其涉及一種基礎設施服務層仲裁裝置及方法。

背景技術

隨著通信云概念的推廣，業務應用層與基礎設施服務（英文：Infrastructure asa Service，縮寫：IaaS）層分離，解耦的分層架構被廣泛應用到通信系統。硬件設備由IaaS層管理，對業務應用透明，業務應用一般運行在虛擬機（英文：Virtual Machine，縮寫：VM）中。

通信應用的一個典型特征是高可靠，通信系統通常通過業務進程主備互助實現高可靠。例如，VM1上配置的是主進程，VM2上配置的是備進程，主進程處理業務，備進程不處理業務，備進程從主進程同步狀態和數據。同時，部署管理進程，對系統中運行的業務進程進行監控，負責進程狀態管理和主備仲裁。為確保高可靠性，管理進程也會部署主備。在分層架構下，管理進程一般是通過主備管理進程間互發信息進行仲裁。例如，VM1的管理進程與VM2的管理進程互發心跳，根據進程啟動的時間進行主備仲裁，進程啟動時間早的為主進程，啟動晚的為備進程。如果原主管理進程故障了，則原備管理進程變為主進程。

現有技術依賴兩個管理進程之間互發心跳進行主備仲裁，容易產生誤仲裁。VM2管理進程收不到VM1管理進程的心跳，其原因可能有多種，例如VM1管理進程故障、VM1網口故障或VM2網口故障等。如果是因為網口故障導致VM1管理進程與VM2管理進程之間不能互相發送心跳，則兩個管理進程都將認為其為主進程，從而系統將出現兩個主管理進程，導致系統出錯。

發明內容

技術問題

有鑒于此，本發明要解決的技術問題是，應用層的兩個管理進程之間互發心跳進行主備仲裁所產生的誤仲裁，及由此導致的通信業務可靠性降低的問題。

解決方案

為了解決上述技術問題，根據本發明的一實施例，提供了一種基礎設施服務層仲裁裝置，包括：

接收模塊，用于接收應用層的至少兩個進程發送的主備仲裁請求；

仲裁模塊，與所述接收模塊連接，用于根據接收到的各所述主備仲裁請求的時間順序，將最先接收到的主備仲裁請求對應的進程仲裁為主狀態進程，將其它主備仲裁請求對應的進程仲裁為備狀態進程。

在一種可能的實施方式中，所述仲裁模塊被配置為：

當檢測到所述主狀態進程異常時，根據接收到的各所述主備仲裁請求的時間順序，從所述備狀態進程中選擇最先接收到的主備仲裁請求對應的進程作為主狀態進程。

在一種可能的實施方式中，所述接收模塊被配置為：接收應用層的通信業務仲裁地址請求裝置發送的請求仲裁服務地址消息，所述請求仲裁服務地址消息包括所述應用層的至少兩個進程的分組用戶名；所述基礎設施服務層仲裁裝置還包括：

發送模塊，與所述接收模塊連接，用于根據所述分組用戶名，發送返回仲裁服務地址消息至所述仲裁地址請求裝置，所述返回仲裁服務地址消息中攜帶有所述仲裁服務地址，所述主備仲裁請求是所述進程根據所述仲裁服務地址發送的。

在一種可能的實施方式中，所述接收模塊被配置為：