基于OSI標準的網絡故障管理系統的設計與實現

◆李維峰

基于OSI標準的網絡故障管理系統的設計與實現

◆李維峰

（中國飛行試驗研究院 陜西 710089）

由于受管網絡設備的數量龐大以及涉及的管理目標眾多，網絡管理已經成為通信網絡設計和維護中討論的核心問題。但是當前網絡管理工具和技術的使用不當或效率低下使得管理員對于某些網絡通信系統的有效管理幾乎不可能實現。這些趨勢只會增加對有效網絡管理的迫切需求，上述情況的迫切性也促使許多組織與國際標準化組織（ISO）合作定義網絡管理框架。本文基于OSI標準設計了一種網絡故障管理系統。

網絡管理；故障管理；OSI

0 引言

開放系統互連（OSI）網絡管理分為五個特定管理功能區（SMFAS）。它們分別是故障管理、配置管理、計費管理、性能管理和安全管理。這些功能區通常被稱為FCAPS，彼此互相配合，共同完成所有網絡管理任務。但是，本文主要集中在故障管理功能區。網絡管理中首先要提到的內容就是故障管理。它的主要作用是確保網絡的高可用性。因此，需要一個預防和避免網絡故障的系統，并且在不能避免故障的情況下，該系統需要采取必要的步驟來遏制這種損害并且解決對網絡的影響。該系統的功能應包括自動檢測并通知故障發生的能力、隔離故障的能力以及盡可能糾正故障的能力。由于標準化進程緩慢，用戶缺乏故障管理應用系統，多個組件的間歇性故障，需要特定的監測和故障排除工具。本文選擇研究和解決故障管理問題，希望找到故障發生 的真正原因，通過接收到的大量告警和執行故障診斷所需的信息，預測網絡故障的發生，從而可以縮短故障間隔時間和故障恢復時間。

1 網絡故障管理

在本節中，我們提供與網絡故障相關的一些術語的定義，并介紹執行故障管理時可能遇到的典型問題。

1.1術語及故障特征

fault，error和failure這三個術語經常被混淆，這些條款的錯誤解釋可能會導致錯誤的使用。fault是系統中的軟件或硬件缺陷，會干擾通信或降低性能。error是系統組件的錯誤輸出，如果組件產生error，我們說組件失敗，這是組件故障。failure是組件故障對應于由該組件產生的錯誤。我們必須區分上述條款，fault是產生錯誤的直接或間接原因，error是錯誤的表現形式，fault是故障的總體結果。但是，如果組件產生錯誤，我們不能斷定組件中存在錯誤。網絡故障的特點可能包括其癥狀，例如：傳播（從一個組件到另一個組件的錯誤傳輸）、網絡持續時間和嚴重程度等幾個方面。雖然網絡故障可以通過它們的特點加以區分，但是值得注意的是，由于它們受到控制和管理的方式不同，所以難以準確地測量這些特性。用戶可能因為error而導致某些網絡組件產生的癥狀來檢測到fault的發生。故障癥狀可以分為四種類型:定時錯誤、及時錯誤、調試錯誤和遺漏錯誤。這些癥狀可能表現為以下形式之一：

（1）具有預期值的輸出要么太早，要么太遲：這種情況是由于定時錯誤造成的。當用戶的應用受到故障的間接影響時，通常被用戶看作是緩慢的響應或超時。

（2）在指定的時間間隔內出現意外值：這種情況是由于及時錯誤造成的，通常表現在應用程序或底層軟件和硬件中出現輕微故障。

（3）在指定的時間間隔之外出現意外值：這是由于調試錯誤造成的，如果沒有產生響應，則與遺漏錯誤相關聯。遺漏錯誤可被視為調試錯誤的特例，調試錯誤通常意味著網絡出現嚴重故障。

如果觀察到這些癥狀，則可能在網絡中某處發生故障，導致組件產生錯誤的輸出（error）。一個組件中的故障可能對其他相關組件造成影響。除了系統自己以外，它可能會傳播到其他組件，進而影響整個系統。這樣，單個組件中的故障可能具有全局影響，在網絡上，這種現象被稱為故障傳播。發生在孤立系統中的故障可能不會影響其他系統，因為它們之間沒有交互作用。但是，當孤立系統通過通信連接在一起時，由故障產生的錯誤可能在分組中傳播到其他系統。一個組件可能由于其中的錯誤和其他組件中的錯誤而產生錯誤，這是網絡故障的主要特征之一。

網絡故障的持續時間雖然被認為是其重要標準之一，但有時難以衡量。這是由于三個原因：首先，直到產生錯誤才會感覺到錯誤。其次，一個特定的錯誤可能需要很長時間才能被感知。最后，故障排除后，網絡故障的影響可能不會自動消除。他們將保持一段時間，直到整個系統運行穩定為止。因此，網絡故障一般根據其持續時間分為永久性、間歇性和瞬時性三類。網絡中將存在永久性故障，直到采取修復措施。間歇性故障以不連續和周期性的方式發生，其結果將是當前進程的失敗。這意味著在短時間內服務水平有很大程度的降低，短暫的故障會暫時導致服務水平的輕微下降。第一種類型的故障將導致事件報告被發出，并在網絡配置中進行改變，以禁止進一步利用該資源。對于第二種類型的故障，如果這種故障的過度發生變得顯著，則故障的嚴重程度可以從間歇性轉變為永久性。最后，網絡協議的錯誤恢復過程通常會掩蓋瞬態錯誤，因此用戶可能不會觀察到。故障管理系統的設計者必須具備故障特征的知識，這是因為不是所有的故障都會有相同的優先級，故障管理系統設計者將必須決定哪些故障必須被管理。

1.2故障管理流程

一些文獻認為綜合故障管理系統由監測、報告、記錄、故障單、過濾、關聯、診斷和恢復活動組成。本節試圖討論故障管理系統將運行的領域，為便于討論，我們選擇將與故障管理有關的活動分為檢測、隔離、糾正和管理四大類。錯誤檢測提供了識別錯誤的能力，它包含監測和報告活動。監控設備提供的信息必須是最新的、及時的、準確的、相關的和完整的。報告活動包括調查需要通知的關鍵標準和報告生成機制，還涉及確定發送通知的適當目的地。

檢測的目的是為了隔離實際的故障，給出了一些可能的故障假設。

隔離包括四個活動：過濾、解釋、關聯和診斷。過濾涉及分析管理信息以便識別新的故障或者之前是否發生故障，以更新其計數。過濾丟棄沒有意義的管理信息通知，并將適用的通知路由到系統內適當的目的地。

隔離后，必須通過旁路和恢復將故障的影響降至最低，這就是糾正。在適用的情況下，必須采取措施確保問題不再發生。這個程序包括三個活動：重新配置、恢復和修復。重新配置或旁路包括激活專門分配給關鍵實體備份、暫停服務或將冗余資源重新分配到更重要的用途，目標是減少失敗的直接影響。這個功能可能是手動，半自動和自動程序的混合。

故障管理是為了確保故障不會丟失或被忽略。這部分工作包括監控故障記錄，維護故障信息檔案、分析趨勢、跟蹤成本、教育人員和執行單位關于問題解決的政策。它由三個活動組成：記錄、跟蹤和趨勢分析。記錄維護網絡中發生故障的事件報告日志。這將用于趨勢分析，報告和將來的類型相同或類似故障診斷。跟蹤是指跟蹤現有的問題和負責人或每個人的工作，促進問題解決實體之間的溝通，并防止問題重復出現。趨勢分析可能意味著需要重新設計通信環境、更換劣質設備、增強解決問題的專業知識，獲得新的解決問題的工具，改進解決問題的程序、改進教育，重新協商服務水平等工作。

1.3典型問題

故障監測的最關鍵問題之一是不可觀測的故障，在這種情況下，特定故障的內部聯系是難以觀察到的。加之缺乏自動化測試工具：測試隔離故障困難、昂貴且耗時。它需要設備行為和工具的重要專業知識來進行測試。即使像沿著虛擬電路來跟蹤分組進程一樣簡單的任務，通常也是不可能完成的。這導致經驗性的操作規則是“測試虛擬電路是否正常工作的唯一方法，就是把它拿下來”[1]。

恢復過程通常包括自動本地重置與手動恢復過程的組合。恢復提出了一些有趣的技術挑戰。其中包括自動恢復作為故障的來源：由于大多數網絡設備或進程設計為從本地故障自動恢復，這也可能是故障的來源。故障管理中的問題是維護故障報告日志，由于缺少創建或刪除記錄的功能，故障報告日志變得困難。日志記錄工具通常以靜態方式執行，其中日志記錄特征是停滯的。因此，一些重要的故障事件不能被記錄。如果可以更改日志屬性值，則日志記錄行為也可能會改變。

2 系統設計

為了解決上述問題，我們設計并實施了FMS（Fault Management System）。它提供了三種類型的故障管理應用程序，如圖1所示，即故障維護應用程序（FMA）、日志維護應用程序（LMA）和診斷測試應用程序（DTA）。這些故障管理應用程序與OSI代理一起在網絡資源上執行故障管理任務。OSI代理充當故障監視代理，它有能力獨立地向FMA報告錯誤，當監控變量超過閾值時，它也可以發出報告，這就使得FMS可以預測故障。另外，它維護事件的日志。這些日志可以通過LMA訪問和操作。DTA提供可由用戶調用的一組診斷測試。這對網絡管理員來說是有利的，只要有人懷疑某些資源不能按照要求工作。

FMA解決了由于供應商設備配置不當而無法觀察到故障的問題。這是通過監視實際資源的關鍵特性來完成的，當發生涉及這些特性的重大事件時，將這些事件報告給FMA，以便開展進一步調查。這些過程包括對事件解釋和過濾，事件關聯，調用預定義的診斷測試以及啟動恢復過程。FMA使用事件或警報來解決觀察點太多的問題。另外，報告標準設計得相當嚴格，以減少FMA收到的警報量。為了達到這個目的，只報告需要注意的事件。因此，在FMS實施中，事件報告等于報警。FMA通過為接收到的每個事件報告安排預定義診斷測試的執行來提供自動化測試，從而使失敗的根源變得明顯。隨后，自動執行與診斷有關的恢復操作。

圖1 系統結構圖

另一方面，DTA提供了允許用戶調用診斷測試的功能。這對有意跳過微不足道的測試的有經驗用戶是有利的，并且只選擇特定的測試可以使管理目的網絡的資源消耗較低。LMA提供的支持克服了缺乏系統審計的適當工具，并有能力啟動錯誤條件（事件）記錄。此外，LMA可以通過設置其日志屬性值來訪問這些日志并控制日志記錄行為。其他支持包括刪除日志和日志記錄的功能，以及審查事件（通過審查日志記錄）以進行診斷或趨勢分析。

3 系統實現

FMS在OSI管理信息服務（OSIMIS）管理平臺上實施。OSIMIS本身是在倫敦大學學院（UCL）開發的，為實施管理系統提供了一個平臺[2,3]。OSIMIS提供OSI管理協議、管理系統實施和運行時平臺，以及一些簡單的管理應用程序。OSIMIS管理的系統平臺被稱為“通用管理系統”（GMS）。GMS平臺提供的支持包括為構建OSI代理提供通用支持，為與真實資源交互提供支持，為生成源（C/C++）代碼的編譯器，以及用于測試目的的一些OSI客戶端應用程序。要使用GMS生成托管系統，實現者必須實現C++對象類，這些類將用于表示托管對象類以及代理的后端與真實資源進行交互。如圖2所示，FMS的實施被分成六個功能組件，即用戶界面、管理應用程序、系統管理器、系統管理代理、管理信息庫和實際資源接口程序。

圖2 系統功能組件圖

3.1用戶界面

由于FMS的用戶可以有不同的職責，例如網絡管理員或網絡運營商，用戶界面為針對不同用戶的各種故障管理應用提供了一個專注的界面，網絡管理員可以啟動或終止FMA。如圖3所示：

圖3 用戶應用程序接口

3.2管理應用程序

管理應用程序是用C++開發的。有三組管理申請、FMA、LMA和DTA，所有這些應用程序都是可執行的形式。管理應用程序使用OSI系統管理器，將管理操作發送到OSI系統管理代理。

（1）FMA

該管理應用程序處理從接收到恢復行動發生之時的事件報告。故障管理程序通過管理功能事件處理、事件關聯、故障診斷和故障恢復來實現。它可以由用戶以管理角色調用。在這種情況下，當網絡管理員需要干預來執行恢復操作時，輸出是以建議的形式給出的。否則，故障恢復將自動進行。

（2）LMA

這個記錄器完成維護事件報告日志的任務。它是趨勢分析和報告的工具，并為相同或類似問題的未來診斷提供了庫。LMA本身是通過三個獨立的程序來實現的。用于記錄和設置日志屬性值的設施由程序LogSet實現，刪除日志和日志記錄的工具是通過DelLogRec程序來實現的，用于查看logRecords的工具由程序RevRec實現。

（3）DTA

此工具的存在是為了方便用戶，由網絡管理員或技術人員負責，它允許用戶對特定的網絡資源執行診斷測試。其目的是檢查診斷測試提供的功能是否正確，或者是通過查看由SMA上的日志記錄的事件日志的歷史記錄來執行診斷例程。

3.3系統管理器

OSI系統管理器是一個負責一個或多個管理活動的應用程序。它發出管理操作請求（操作）并代表管理應用程序功能接收通知（事件）。因此它包括一組連接OSI系統管理代理程序和檢索管理信息的程序。這些程序是CMIS原語的實現，它們被管理應用程序用來執行各種故障管理功能。OSI系統管理器以CMIS請求形式向OSI系統管理代理發送命令并等待回復。已經實現了五個OSI系統管理器，即執行M-SET原語、M-GET原語、M-EVENT-REPORT原語，用于在OSI上記錄事件記錄的M-SET原語的cmis_set、cmis_get、cmis_evrecv、cmis_setlog和cmis_dellog系統管理代理和M-DELETE原語，分別用于刪除OSI系統管理代理中的現有事件記錄。

3.4系統管理代理

管理員訪問各網絡元素是通過系統管理代理（SMA）進行的，訪問網絡元素涉及收集其統計信息并將其用于管理活動。SMA是作為一個單獨的UNIX進程實現的，是OSIMIS GMS提供的OSI代理支持，支持ISO CMIP協議。它對MIB實例中的對象執行作用域和過濾，并自動處理所有的CMIP功能。它通過管理應用程序傳達的管理操作執行管理操作。其職責還包括發布反映被管理對象行為的通知。SMA充當FMS的最低級功能組件，并通過X.25 MIB提供對X.25網絡的訪問。OSI SMA要執行的任務可以被概括為與執行通信協議的進程進行內部通信，允許通過CMIS遠程訪問被管理對象屬性，從而實現外部控制管理功能。例如，在管理對象內設置閾值，檢測重大事件和超出閾值，以及隨后生成事件報告。

3.5管理信息庫

MIB通過ISO CMIS和CMIP與FMS進行通信，包括讀寫特定管理對象屬性的能力，向“集合值”屬性添加和移除元素的能力，自發生成事件報告以及管理與遠程管理器進程的關聯。系統的管理對象樹隨著網絡活動的變化而變化，實現反映了這一點，必要時創建和銷毀對象。MIB不僅僅是一個被動數據庫，該實現支持定義事件，指定在發生特定網絡事件時要采取的操作。在實施過程中，行動始終是發送報告。計數器和儀表上的閾值也被支持，超過閾值可能會導致生成報告。如前一節所述，MIB由一個稱為系統管理代理的UNIX進程支持，通過實際資源接口程序來訪問這些資源。

3.6真實資源接口程序

這是特定于代表真實資源的特定管理對象的部分。它不僅要適應實際的資源類型，也要適應實際資源如何呈現管理信息的手段。它不是由GMS提供的，必須由MIB實現者來實現。這些真實的資源可能駐留在操作系統的內核、用戶進程或者通過代理管理的遠程系統中。因此，接口程序根據他們想要訪問的實際資源的管理信息而變化。目前，定義了兩種接口程序來從SunOS內核和SunNet X.25軟件中為X25 MIB提取信息。代理收到CMIS請求后，調用執行資源操作的接口程序。同樣，當超時指示真實資源應該匯集時，接口程序被調用。這個過程是有目的地進行的，以更新真實的資源管理信息。作為處理從該接口程序接收到的信息的結果，真實資源管理對象可以確定已經超過閾值并且可能需要通知。如果管理對象確定事件轉發鑒別器過濾器設置為轉發此類通知，則通知SMA。

FMS提供的應用程序是以模塊化的方式設計和實現的，彼此獨立。這個特性證明了一個優點，就是當需要時可以很容易地添加新的應用程序。

4 結論

隨著人們工作和生活越來越依賴計算機網絡。這意味著計算機網絡必須可用，并在大多數時間提供良好的性能。永久性和間歇性故障的發生是不能容忍的，必須避免。因此，在規劃計算機網絡時，主動管理網絡故障是必須包括的重要項目。我們已經描述了OSI網絡管理的概念，并且發現OSI管理的一個重要部分涉及網絡管理應用（FCAPS）。對故障管理功能區及其相關問題進行了詳細的研究。得出的結論是，通過提供基于OSI的故障管理應用程序的支持，可以更好地實現這種環境下的網絡故障管理，幫助網絡管理員和技術人員執行故障管理任務。

[1]Dupuy, J. Schwartz, Y. Yemini, G. Barzilai, A. Cahana, “Network Fault Management A User’s View”, Integrated Network Management I, B. Meandzija and J. Westcott (Editors) Elsevier Science Publishers B.V. (North-Holland), IFIP, 1989.

[2]MIDAS Work Package 2.2.1, “Runtime Support for Interaction with Real Resources in the OSIMIS management platform”, Document MIDAS/ UCL/93/08, February 1993.

[3]Project INCA, “An OSI Network Management System”, G. Night, G. Pavlou, Simon Walton, University College London，1988.