網絡設備的虛擬化管理方法與流程

本發明涉及一種虛擬化管理方法，特別是涉及一種網絡設備的虛擬化管理方法。

背景技術：

當前網絡環境由接入設備、匯聚設備和核心設備組成。接入設備主要職責是提供終端用戶的網絡的接入工作，匯聚設備的主要職責是對接入設備進行網絡匯聚工作，核心設備主要職責是對數據分發及傳輸使數據能夠正確的達到目的地。其中接入設備的數量相比匯聚設備和核心設備又非常的龐大。

隨著互聯網的迅猛發展，越來越多的網絡設備被投入使用，使得ipv4的網絡地址迅速的消耗，而ipv6的發展相對較為緩慢無法完全地替代ipv4網絡的使用。而接入設備因為其數量非常龐大，成為了消耗ipv4的主力軍。

在實際網絡布置中為了節約ipv4地址的使用，很多網絡提供商都放棄了對入設備進行ipv4地址的分配，從而放棄了直接網管接入設備，這樣就導致很多接入設備處于無法網管的狀態。這樣就帶來了終端設備出現故障無法及時感知，無法及時解決故障。這樣勢必會影響最終用戶的網絡體驗。

技術實現要素：

本發明所要解決的技術問題是提供一種網絡設備的虛擬化管理方法，其能夠實現接入設備在無ip的情況下進行設備管理、故障檢測及告警機制。

本發明是通過下述技術方案來解決上述技術問題的：一種網絡設備的虛擬化管理方法，其特征在于，其包括以下步驟：

步驟一，主系統收集下聯的實際子系統信息，將實際子系統在主系統上進行虛擬化，使實際子系統成為主系統的虛擬子系統；

步驟二，在完成實際子系統的虛擬化以后，主系統對虛擬子系統進行網管管理、監控及故障告警。

優選地，所述步驟二在完成實際子系統的虛擬化以后，主系統和實際子系統成一個整體系統給一個網管系統，網管系統直接的對實際子系統進行管理以及監控。

優選地，所述虛擬子系統主要負責存儲實際子系統相應的配置信息、故障信息以及告警信息。

優選地，所述網管系統管理及監控實際子系統采用以下步驟：

步驟十一：網管系統需要訪問實際子系統，會將請求信息發送到主系統，并告知主系統網管系統請求的是實際子系統；

步驟十二：主系統根據網管請求中的設備索引確定請求是本地還是實際子系統，如果是實際子系統會將請求信息發送到本地虛擬化的實際子系統上處理；

步驟十三：主系統上的虛擬化實際子系統收到處理請求以后會向真實的實際子系統發起信息請求，并從真實的實際子系統上獲取相應信息返回給主系統；

步驟十四：實際子系統檢測到本地故障以后，需要向主系統進行通告，實際子系統首先將故障信息發送到主系統的虛擬子系統上；

步驟十五：虛擬子系統收到來自真實實際子系統的故障信息以后，會通過主系統將故障信息發送到網管系統；

步驟十六：主系統將帶有實際子系統信息的故障信息發送給網管系統。

優選地，所述主系統會給虛擬子系統分配一個全局唯一的實際子系統號。

優選地，所述實際子系統號是根據實際子系統與主系統所連接的主系統上的物理端口號進行設置，這樣做的好處是方便的知道所述實際子系統下掛在主系統上的那個端口上。

優選地，所述主系統監聽到實際子系統發送來的hello報文，通過hello報文來確定實際子系統存在并建立主系統與實際子系統之間的連接關系。

優選地，所述建立主系統與實際子系統之間的連接關系采用以下步驟：

步驟二十一：實際子系統周期性的發送hello報文，通告自己的存在；

步驟二十二：主系統收到實際子系統hello請求以后會向實際子系統通告自己已經收到對端請求，并給出回應報文，讓實際子系統進行下一步操作；

步驟二十三：實際子系統在收到主系統的hello報文回應以后，將停止hello報文的，并對主系統發起加載實際子系統的請求報文給主系統；

步驟二十四：主系統在收到實際子系統的加載請求以后檢測主系統與實際子系統之間的數據通道是否正常穩定；

步驟二十五：實際子系統在收到主系統的配置消息以后會根據配置消息的相應內容進行配置，成功以后實際子系統與主系統之間的握手就完成了；此時需要向主系統告知自己配置成功，并開啟本地的超時定時器，該定時器的目的是在一定時間內未收到任何主系統的報文后進行超時處理，并將自己置于初始狀態，并重新開始發送hello報文；

步驟二十六：主系統在收到實際子系統配置成功消息以后就完成了所有握手操作；此時主系統需要根據實際子系統相應信息對實際子系統進本地虛擬化操作，將所有實際子系統信息虛擬到本地軟件上。

優選地，所述虛擬子系統與實際子系統之間采用可靠傳輸機制進行數據交互。

優選地，所述虛擬子系統與實際子系統之間進行數據交互的步驟如下：

步驟三十一：主系統在收到網管系統獲取實際子系統的命令以后，首先會訪問本地是否有相應的實際子系統的虛擬子系統存在，如果存在就將獲取命令交由對應虛擬子系統處理；

步驟三十二：虛擬子系統從通信適配層獲取通信id，該id是一個臨時id，用于標識當前操作；成功獲取通信id以后會將該id封裝在數據報文中并和命令一起通過可靠傳輸發送到實際子系統；

步驟三十三：虛擬子系統將臨時通信id、命令字、索引等信息封裝成數據報文通過可靠傳輸協議發送給實際子系統；

步驟三十四：實際子系統收到虛擬子系統發送過來數據請求以后，首先對其數據報文中的命令字進行解析，然后根據解析出來的命令字及索引信息從本地獲取數據；在獲取完數據以后，實際子系統會將獲取的數據返回值，數據及通信id封裝成數據報文發送給虛擬子系統；

步驟三十五：虛擬子系統收到實際子系統收到的回應報文以后，先對報文進行解析，解析出其中的通信id；然后查找是否有線程正在等待該通信id的回應信息，如果有則將從實際子系統收到的返回值及數據交給等待的線程處理，如果沒有線程等待該通信id，那么直接忽略掉該回應報文；

步驟三十六：虛擬子系統從實際子系統獲取數據時進入等待狀態以后，如果在規定的等待時間內收到實際子系統回應，那么將從實際子系統收到的回應返回給上層軟件，如果在規定等待時間內未收到回應則認為超時失敗，將失敗結果返回給上層軟件。

優選地，所述虛擬子系統與實際子系統之間采用的命令字與數據結構必須保持一致。

本發明的積極進步效果在于：本發明能夠實現接入設備在無ip的情況下進行設備管理、故障檢測及告警機制。本申請能夠很好的實現匯聚設備與接入設備的集中管理。

附圖說明

圖1是本申請實施通過網管系統管理及監控實際子系統的流程圖。

圖2是本申請實施主系統如何實現實際子系統與主系統鏈接及虛擬化的流程圖。

圖3是本申請實施虛擬子系統如何從實際子系統獲取數據的流程圖。

具體實施方式

為使本申請的目的、技術方案及優點更加明確，以下參考附圖詳細的解說相應流程及細節部分。

本發明網絡設備的虛擬化管理方法包括以下步驟：

步驟一，主系統收集下聯的實際子系統信息，將實際子系統在主系統上進行虛擬化，使實際子系統成為主系統的虛擬子系統；

步驟二，在完成實際子系統的虛擬化以后，主系統對虛擬子系統進行網管管理、監控及故障告警等。

在完成實際子系統的虛擬化以后，主系統和實際子系統成一個整體系統給一個網管系統，網管系統可以直接的對實際子系統進行管理以及監控，使用方便。

虛擬子系統主要負責存儲實際子系統相應的配置信息、故障信息以及告警信息等。

第一實際子系統在與主系統進行協商完成以后，主系統會根據協商過程中獲取的相應信息對實際子系統進行虛擬化操作，并在自己的軟件系統上建立一個虛擬的第一實際子系統。此時虛擬的第一實際子系統存放的軟件信息與第一實際子系統完全一致，其中包括所有端口的信息及配置、全局的cpu及內存使用情況、故障檢測情況等。

第一實際子系統在主系統上虛擬化成一個虛擬子系統以后，主系統會給虛擬子系統分配一個全局唯一的實際子系統號，該實際子系統號是為了唯一標識實際子系統的，便于網管系統能夠區分。實際子系統號的編號是根據實際子系統與主系統相連的主系統上的物理端口的索引來進行確定的。主系統上的物理端口分為端口類型，槽位號，實際子系統號，端口號，其中實際子系統號為0，用于表示為主系統端口。虛擬子系統通過主系統上的物理口索引來計算出虛擬子系統索引的好處在于網管系統能夠明確的知道所訪問的實際子系統是下掛到主系統那個物理端口下的，并且能夠明確知道訪問實際子系統時數據報文從那個主系統上的物理接口發送。

網管系統在登入主系統以后，會從主系統上獲取其所存儲的虛擬子系統信息，而此時網管系統就能夠在其管理系統上看到主系統及所有的實際子系統的信息，并能夠根據需求做出相應的配置及監控需求。

為了保證虛擬的第一實際子系統與第一實際子系統的相關軟件信息的一致性，實際子系統的任何配置信息都必須由主系統進行配置。通過主系統配置實際子系統相關信息會經過主系統上的虛擬子系統軟件，虛擬軟件會保存相應的修改信息。如果直接配置實際子系統未經過虛擬子系統，那么虛擬子系統軟件就無法知道相應配置信息，導致通過主系統無法正確查看實際子系統信息。

如圖1所示，本申請實施通過網管系統管理及監控實際子系統的過程如下：

步驟101：網管系統需要訪問實際子系統，會將請求信息發送到主系統，并告知主系統網管系統請求的是實際子系統；

步驟102：主系統根據網管請求中的設備索引確定請求是本地還是實際子系統，如果是實際子系統會將請求信息發送到本地虛擬化的實際子系統上處理；

步驟103：主系統上的虛擬化實際子系統收到處理請求以后會向真實的實際子系統發起信息請求，并從真實的實際子系統上獲取相應信息返回給主系統；

步驟104：實際子系統檢測到本地故障以后，需要向主系統進行通告，實際子系統首先將故障信息發送到主系統的虛擬子系統上；

步驟105：虛擬子系統收到來自真實實際子系統的故障信息以后，會通過主系統將故障信息發送到網管系統；

步驟106：主系統將帶有實際子系統信息的故障信息發送給網管系統。

網管系統需要對第二實際子系統進行數據獲取時，具體步驟如下：

網管系統首先需要向主系統發起訪問請求，告知主系統網管系統需要訪問的目的是什么。主系統在收到網管系統的訪問請求以后，判斷出網管系統需要訪問第二實際子系統中的數據信息。

主系統在收到網管系統的第二實際子系統的訪問請求以后，會將請求發送到本地的虛擬第二實際子系統，由虛擬第二實際子系統進行處理。如果網管訪問是配置信息或者非實時需要獲取硬件信息的訪問請求，就將本地虛擬子系統上存儲的軟件信息返回給網管系統。如果網管系統訪問的是需要實時從第二實際子系統中獲取的信息，那么虛擬第二實際子系統將通過訪問第二實際子系統后對網管系統進行答復。

虛擬第二實際子系統存儲了所有了第二實際子系統中的信息，并且定時進行同步操作。這樣可以減小網管系統頻繁獲取實際子系統信息、或者一次獲取多個實際子系統信息時造成大量主系統與實際子系統之系統之間的通信量。并能夠很快的響應數據給網管系統。而對于實時性要求較高的操作則需要從實際子系統中直接獲取，保證網管系統能夠及時看到實際子系統的實時運行情況。

在虛擬第二實際子系統中存在多個線程會對第二實際子系統中一些實時性要求不高的信息進行定時的同步。其中包括第二實際子系統的cpu、內存、端口的光模塊的ddm數據等。而對第二實際子系統端口的流量統計，物理link狀態等實時性要求較高的操作則是通過實時直接從第二實際子系統中獲取。

虛擬第二實際子系統通過可靠傳輸協議從第二實際子系統中定時或者實時獲取相應數據。第二實際子系統在收到主系統上虛擬第二實際子系統的訪問信息給出相應的響應及回復。在虛擬第二實際子系統對第二實際子系統進行訪問時需要對端口等索引信息進行轉換，主系統上為了能夠唯一區分所有實際子系統上的端口索引，所有實際子系統端口索引均帶上了實際子系統號。而在虛擬第二實際子系統對實際子系統進行訪問時需要將索引信息轉換成通用索引，去掉實際子系統號相關信息，這樣實際子系統才能正確獲取對應信息。

第一實際子系統檢測到本地緊急故障以后需要實時向網管系統進行通告。

第一實際子系統在檢測到本地緊急故障以后需要及時的向網管系統發出告警信息，而不能等到網管系統輪詢去獲取。例如物理端口linkdown以后需要及時向主系統及網管系統進行通告。在第一實際子系統檢測到本地出現嚴重故障以后向主系統的虛擬第一實際子系統進行故障告警通告。虛擬第一實際子系統收到第一實際子系統告警以后記錄第一實際子系統處于故障狀態，并通過主系統向網管系統發送告警信息，提醒用戶出現嚴重故障，需要及時進行處理。

如圖2所示，為實際子系統與主系統如何建立鏈接的過程。

為了減小主系統負擔，主系統不會主動的發送探測實際子系統是否在線的報文。而是由實際子系統周期性的發送hello報文，通告自己的存在。在實際子系統與主系統建立物理上的連接以后，主系統就會收到實際子系統的請求上線信息。主系統與實際子系統進行了握手操作以后主系統則會將實際子系統加載成本地的虛擬子系統，具體步驟如下：

步驟201：為實際子系統周期性的發送hello報文，通告自己的存在。在實際子系統與主系統建立穩定的物理連接以后，主系統就會收到實際子系統的發送來的hello報文，并對hello報文做出響應報文。

步驟202：主系統在收到實際子系統hello請求以后會向實際子系統通告自己已經收到對端請求，并給出回應報文，讓實際子系統進行下一步操作。

步驟203：實際子系統在收到主系統的hello回應以后，將停止hello報文的，并對主系統發起加載實際子系統的請求報文給主系統。

步驟204：主系統在收到實際子系統的加載請求以后檢測主系統與實際子系統之間的數據通道是否正常穩定，此時主系統會通過可靠傳輸消息向實際子系統發送配置消息(配置消息可以是時鐘設置，也可以是空)。此消息的主要目的是檢測數據傳輸通道是否正常。

步驟205：實際子系統在收到主系統的配置消息以后會根據配置消息的相應內容進行配置，成功以后實際子系統與主系統之間的握手就完成了。此時需要向主系統告知自己配置成功，并起開本地的超時定時器，該定時器的目的是在一定時間內未收到任何主系統的報文后進行超時處理，并將自己置于初始狀態，并重新開始發送hello報文。

步驟206：主系統在收到實際子系統配置成功消息以后就完成了所有握手操作。此時主系統需要根據實際子系統相應信息對實際子系統進本地虛擬化操作，將所有實際子系統信息虛擬到本地軟件上。在虛擬化過程中會頻繁的獲取實際子系統相應信息，直到所有信息均獲取到。

如圖3所示，虛擬子系統是如何從實際子系統中獲取數據的流程圖，具體步驟如下：

步驟301所示，主系統在收到網管系統獲取實際子系統的命令以后，首先會訪問本地是否有相應的實際子系統的虛擬子系統存在，如果存在就將獲取命令交由對應虛擬子系統處理。除了從網管系統收到相應獲取實際子系統信息的命令外，虛擬子系統也周期性的輪詢實際子系統同步對應的軟件信息，便于網管系統直接從虛擬子系統獲取信息。

步驟302所示，虛擬子系統從通信適配層獲取通信id，該id是一個臨時id，用于標識當前操作。成功獲取通信id以后會將該id封裝在數據報文中并和命令一起通過可靠傳輸發送到實際子系統。

步驟303所示，虛擬子系統將臨時通信id、命令字、索引等信息封裝成數據報文通過可靠傳輸協議發送給實際子系統(這里的所述的可靠傳輸原理與tcp協議類似，采用基于二層的可靠傳輸協議進行)，其中索引信息不能是虛擬子系統上存儲的索引信息，需要轉換成實際子系統對應的實際子系統能夠識別的通用索引信息。數據發送完畢以后該操作進入等待實際子系統回應狀態。

步驟304所示，實際子系統收到虛擬子系統發送過來數據請求以后，首先對其數據報文中的命令字進行解析，然后根據解析出來的命令字及索引信息從本地獲取數據。如果數據獲取成功則將返回值及數據返回給虛擬子系統，如果不成功則將返回值返回給虛擬子系統。在獲取完數據以后，實際子系統會將獲取的數據返回值，數據及虛擬子系統發送下來的通信id封裝成數據報文發送給虛擬子系統。

步驟305所示，虛擬子系統收到實際子系統收到的回應報文以后，先對報文進行解析，解析出其中的通信id。然后查找是否有線程正在等待該通信id的回應信息，如果有則將從實際子系統收到的返回值及數據交給等待的線程處理，如果沒有線程等待該通信id，那么直接忽略掉該回應報文。

步驟306所示，虛擬子系統從實際子系統獲取數據時進入等待狀態以后，如果在規定的等待時間內收到實際子系統回應，那么將從實際子系統收到的回應返回給上層軟件，如果在規定等待時間內未收到回應則認為超時失敗，將失敗結果返回給上層軟件。

上述步驟描述了上層軟件如何從實際子系統獲取數據的過程。而且中值得注意的幾點是：一，虛擬子系統與實際子系統之間交互時的命令字需要完全統一，建議實際子系統與主系統編譯時采用同樣的命令字頭文件，傳輸數據的結構大小及內容也要保持一致。二，虛擬子系統與實際子系統上表示端口的索引值存在差異，虛擬子系統上的端口索引值是加上了虛擬子系統id的信息的，這樣是為了在主系統上唯一標識所有端口。而實際子系統屬于一個單獨的系統，所以所有實際子系統的端口索引id都是通用的，也就是會有重復的出現。在虛擬子系統與實際子系統通信時，需要將索引信息進行轉換成對端能夠識別的正確索引值。

以上所述的具體實施例，對本發明的解決的技術問題、技術方案和有益效果進行了進一步詳細說明，所應理解的是，以上所述僅為本發明的具體實施例而已，并不用于限制本發明，凡在本發明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發明的保護范圍之內。