效能管理涉及最佳化網路服務響應時間和管理單個和整個網路服務的一致性和品質。最重要的服務是衡量使用者/應用程式響應時間的需要。對於大多數使用者來說,響應時間是成功獲得效能的關鍵因素。此變數決定使用者和應用程式管理員對網路成功的看法。
容量規劃是用來確定對未來網路資源要求的過程,目的是防止對業務關鍵型應用程式的效能或可用性產生影響。在容量規劃領域,網路基線(CPU、記憶體、緩衝區、輸入/輸出八位元等)可能會影響響應時間。因此,請記住,效能問題通常與容量有關。在網路中,這通常是必須等待隊列中的頻寬和資料,然後才能通過網路傳輸。在語音應用中,這種等待時間幾乎肯定會影響使用者,因為延遲和抖動等因素會影響語音呼叫的品質。
另一個使效能管理複雜化的主要問題是,儘管高網路可用性對大型企業和服務提供商網路來說都是任務關鍵型的,但通常趨勢是尋求短期經濟收益,以承受(經常無法預測的)長期成本增加的風險。在每個預算週期中,網路管理員和專案實施人員都在努力尋求效能與快速實施之間的平衡。此外,網路管理員還面臨著諸多挑戰,包括為了滿足狹窄的市場視窗而快速開發產品、複雜的技術、業務整合、競爭性的市場、計畫外的停機時間、缺乏專業知識以及工具經常不足。
鑑於這些挑戰,效能如何適合網路管理框架?理想的網路管理系統的主要功能是最佳化網路的運行能力。一旦您接受這一點作為網路管理的最終目標,則網路管理的重點是保持網路運行在最高效能。
理想的網路管理系統包括以下原則操作:
通知操作員即將出現效能下降。
在發生效能變差或故障時,提供簡單的備用路由和解決方法。
提供工具來查明效能下降或故障的原因。
充當網路恢復能力和生存能力的主站。
即時交流效能。
基於這個定義,對於一個理想的系統,效能管理對於網路管理變得至關重要。這些效能管理問題至關重要:
使用者效能
應用效能
容量規劃
主動故障管理
必須注意的是,對於語音和影片等較新的應用程式,效能是成功的關鍵變數,如果您無法實現一致的效能,該服務會被視為低價值且出現故障。在其他情況下,使用者會因為應用程式間歇性超時而遭受效能可變的困擾,從而導致工作效率和使用者滿意度下降。
本文檔詳細介紹最關鍵的效能管理問題,包括關鍵成功因素、關鍵效能指標和效能管理的高級流程圖。它還討論了可用性、響應時間、準確性、利用率和容量規劃等概念,並簡要討論了主動故障分析在效能管理和理想網路管理系統中的作用。
關鍵的成功因素確定了實施最佳實踐的要求。要作為關鍵的成功因素進行鑑定,一個流程或過程必須提高可用性,否則缺少過程必然會降低可用性。此外,關鍵成功因素應可衡量,以便組織確定其成功程度。
註:有關詳細資訊,請參閱業績管理指標。
以下是績效管理成功的關鍵因素:
收集網路和應用程式資料的基線。
對網路和應用程式執行模擬分析。
對容量問題執行異常報告。
確定所有建議或潛在網路管理服務的網路管理開銷。
分析容量資訊。
定期審查網路和應用程式的容量資訊以及基線和異常情況。
設定升級或調整程式,以便從被動和長期角度處理容量問題。
績效指標為組織提供了衡量關鍵成功因素的機制。績效計畫的績效指標包括:
記錄網路管理業務目標。這可以是網路管理的正式操作概念,也可以是所需功能和目標的非正式宣告。
制定詳細且可衡量的服務級別目標。
使用圖表或圖表提供服務級別協定文檔,顯示如何在一段時間內滿足這些協定的成敗。
收集基線的變數清單,例如輪詢間隔、產生的網路管理開銷、可能的觸發閾值、變數是否用作陷阱的觸發條件,以及針對每個變數使用的趨勢分析。
定期舉行會議,審查對基線和趨勢的分析。
記錄假設分析方法。這應包括建模和適用時的驗證。
超過閾值時,請編寫有關增加網路資源的方法的文檔。需要記錄的專案是投入額外的WAN頻寬和成本表所需的時間線。
這些步驟提供了效能管理的高級流程:
在為網路定義詳細的效能和容量變數之前,您必須瞭解組織內網路管理的整體運營概念。在定義這一總體概念時,它提供了業務基礎,您可以基於此基礎對網路中所需的功能建立精確的定義。如果您未能制定網路管理的操作概念,可能會導致缺少目標或目標,而這些目標又會因客戶需求而不斷變化。
您通常會將網路管理操作的概念作為網路管理程式的系統定義階段的第一步。其目的是從操作角度描述所需的整體系統特性。本文檔用於協調網路運營、工程、設計、其他業務部門和終端使用者的總體業務(非定量)目標。本文的重點是形成網路管理和運營的遠端運營規劃活動。它也為以後所有定義檔案的編寫提供指導,如服務級別協定。這組最初的定義顯然不能過於狹隘地側重於對具體網路問題的管理,而是側重於那些強調對整個組織的重要性,以及與必須管理的成本相關的專案。一些目標是:
確定高效使用網路基礎設施所需的那些特徵。
確定網路支援的服務/應用程式。
啟動端到端服務管理。
啟動基於效能的指標以改進整體服務。
收集和分發效能管理資訊。
利用使用者的反饋支援網路的戰略評估。
換句話說,網路管理運營概念應側重於整體組織目標和實現這些目標的理念。主要組成部分包括任務的更高層次定義、任務目標、系統目標、組織參與和總體業務理念。
作為網路管理員,您能夠統一使用者通常不一致的效能預期。例如,如果網路的主要要求是將大型檔案從一個位置傳輸到另一個位置,則您想要專注於高吞吐量,而不是互動式使用者的響應時間。請注意不要限制您對效能的看法,除非您考慮各種問題。例如,測試網路時,請檢視所使用的負載級別。負載通常基於非常小的資料包和非常大資料包的吞吐量。其中任一效能測試都可能產生非常積極的效果,但是根據您的網路流量負載,這些測試可能不能真實地顯示效能。研究在儘可能多的工作負載條件下網路效能並記錄效能。
此外,雖然許多網路管理組織都採用有效的警報技術來通知技術人員裝置發生故障,但定義並實施端到端應用程式效能評估流程則更為困難。因此,雖然網路運行中心(NOC)可以快速響應已關閉的路由器或交換機,但可能影響網路效能並影響使用者感知的網路條件可能很容易被忽略,直到感知變為負值為止。雖然非常困難,但此第二個過程可以為業務組織和網路管理提供巨大的好處。
最後,請確保不要對網路效能產生不切實際的期望。當您誤解網路協定或應用的詳細資訊時,通常會產生不切實際的期望。通常情況下,效能不佳不是網路的故障,而是應用設計不佳的結果。記錄和衡量應用程式效能的唯一方法是在安裝應用程式之前建立網路效能基線。
效能管理、持續容量規劃和網路設計的第一步是定義所需的功能和/或服務。此步驟要求您瞭解應用、基本流量、使用者和站點數量以及所需的網路服務。此資訊的第一個用途是確定應用程式對組織目標的重要性。您還可以應用此資訊來建立知識庫,用於邏輯設計,以便瞭解頻寬、介面、連線、配置和物理裝置要求。此初始步驟使網路架構師能夠建立網路模型。
制定解決方案可擴充性目標,以幫助網路工程師設計滿足未來增長需求的網路,並確保提議的設計不會因網路的增長或擴展而遇到資源限制。資源限制可包括:
總流量
音量
路由數
虛擬電路數量
鄰居計數
廣播域
裝置吞吐量
媒體容量
網路規劃人員應確定設計所需的生命週期、設計所需的預期擴展或站點、新使用者的數量以及預期流量或變化。此計畫有助於確保推薦的解決方案在設計預計生命週期內滿足增長要求。
如果不研究解決方案的可擴充性,您可能必須實施重大的被動設計更改。此設計更改可能包括額外的層次結構、介質升級或硬體升級。在那些依靠相當精確的預算週期來購買主要硬體的組織中,這些變更會嚴重阻礙整體成功。在可用性方面,網路可能會遇到意外的資源限制,從而導致不可用和反應性措施週期出現。
互操作性和互操作性測試對新解決方案部署的成功至關重要。互通性是指不同的硬體供應商,或者是在網路實施期間或之後必須相互連線在一起的不同拓撲或解決方案。互通性問題可能包括通過協定棧向上傳送硬體信令到路由或傳輸問題。互操作性問題可能在網路解決方案遷移之前、期間或之後發生。互操作性規劃應包括不同裝置之間的連線以及遷移期間可能出現的拓撲問題。
解決方案比較是指您將不同的潛在設計與其他解決方案要求實踐進行比較。此實踐有助於確保解決方案最適合特定的環境,並且個人偏見不會推動設計過程。比較可以包括不同的因素,例如成本、恢復能力、可用性、風險、互操作性、可管理性、可擴充性和效能。一旦實施設計,所有這些都會對整體網路可用性產生重大影響。您還可以比較介質、分層結構、冗餘、路由協定和類似功能。建立一個圖表,其中包含X軸上的因素和Y軸上的潛在解決方案,以便總結解決方案比較。在實驗室環境中進行詳細的解決方案比較還有助於客觀地調查與不同的比較因素相關的新解決方案和功能。
作為網路管理操作概念的一部分,以所有使用者都能理解的方式定義網路目標和支援的服務至關重要。在制訂業務構想之後開展的活動在很大程度上受到該檔案的品質的影響。
以下是標準效能目標:
響應時間
利用率
吞吐量
容量(最大吞吐率)
雖然這些測量對於簡單的LAN可能很瑣碎,但在交換園區網路或多供應商企業網路中可能非常困難。當您使用深思熟慮的運營計畫概念時,每個績效目標都以可衡量的方式定義。例如,在高峰工作時間,應用程式「x」的最小響應時間為500毫秒或更短。這定義了標識變數的資訊、度量變數的方法,以及網路管理應用程式應在一天中的某段時間內關注變數。
可用性目標定義網路服務的服務級別或服務級別要求。這有助於確保解決方案滿足最終可用性要求。為特定組織定義不同的服務類別,並詳述適合可用性要求的每個類別的網路要求。網路的不同區域可能還需要不同級別的可用性。要實現更高的可用性目標,可能需要增加冗餘和支援程式。在為特定網路服務定義可用性目標並測量可用性時,您的網路組織可以瞭解實現計畫的SLA所需的元件和服務級別。
定義可管理性目標,以確保整體網路管理不缺少管理功能。為了設定可管理性目標,您必須瞭解組織的支援流程和相關網路管理工具。可管理性目標應包括瞭解新解決方案如何適合當前支援和工具模型,並參考任何潛在差異或新要求。這對於網路可用性至關重要,因為支援新解決方案的能力對於部署成功和實現可用性目標至關重要。
可管理性目標應揭示支援潛在網路所需的所有重要MIB或網路工具資訊、支援新網路服務所需的培訓、新服務的人員配備模式以及任何其他支援要求。通常,這些資訊在部署之前不會被發現,並且總體可用性會因缺少分配用於支援新網路設計的資源而受到影響。
效能SLA和指標可幫助定義和測量新網路解決方案的效能,以確保它們滿足效能要求。可以通過效能監控工具或跨建議的網路基礎設施使用簡單ping來衡量建議的解決方案的效能。效能SLA應該包括平均預期流量、峰值流量、平均響應時間和允許的最大響應時間。這些資訊稍後可以在解決方案驗證部分中使用,最終幫助確定所需的網路效能和可用性。
網路設計的一個重要方面是定義使用者或客戶的服務。企業稱之為服務級別協定,而服務提供商稱之為服務級別管理。服務級別管理通常包括對問題型別和嚴重程度的定義以及幫助台的責任,例如上報路徑和每個級別支援級別上報前的時間、開始解決問題的時間,以及根據優先順序結束目標的時間。其他重要因素包括在容量規劃、主動故障管理、變更管理通知、閾值、升級標準和硬體更換方面提供的服務。
如果組織不預先定義服務級別,以後就很難改進或獲得確定的資源需求。此外,要瞭解需要新增哪些資源來幫助支援網路也變得十分困難。在許多情況下,這些資源僅在發現問題之後才應用。
效能管理是一個包含不同效能區域的配置和測量的總稱。本節介紹績效管理的以下六個概念:
大多數企業內部網都有足夠的頻寬。但是,如果沒有足夠的資料,您可能無法排除網路擁塞是導致應用程式效能不佳的一個因素。擁塞或錯誤的一個線索是如果效能不佳是間歇性的或時間相關的。這種情況的例子是,在深夜的表現很出色,但在早晨和上班高峰期表現很慢。
一旦定義了網路管理操作的概念並定義了所需的實施資料,就有必要隨著時間的推移收集這些資料。此類收集是網路基線的基礎。
在新解決方案(應用程式或IOS更改)部署之前和部署之後執行當前網路基線,以度量為新解決方案設定的預期值。此基準有助於確定解決方案是否符合效能和可用性目標以及基準容量。典型的路由器/交換機基線報告包括與CPU、記憶體、緩衝區管理、鏈路/介質利用率和吞吐量相關的容量問題。根據操作概念中定義的目標,還可以包括其他型別的基線資料。例如,可用性基線表明網路環境的穩定性/可用性提高了。在舊環境和新環境之間執行基線比較,以驗證解決方案要求。
另一個專用基線是應用程式基線,當您確定應用網路需求趨勢時,此基線很有價值。此資訊可用於升級週期中的計費和/或預算目的。相對於每個應用程式的首選服務或服務品質,應用程式基線在應用程式可用性方面也很重要。應用程式基線資訊主要包括應用程式每時間段使用的頻寬。某些網路管理應用程式還可以確定應用程式效能的基準。流量型別(Telnet或FTP)的細分對規劃也很重要。在一些組織中,對網路中更重要的資源受限區域進行監控,以監控最大流量生成者。網路管理員可以使用此資訊來預算、規劃或調整網路。調整網路時,可能會修改網路服務或應用的服務品質或隊列引數。
網路管理員使用的主要指標之一是可用性。可用性是衡量網路系統或應用程式對使用者可用的時間。從網路的角度來看,可用性代表網路中各個元件的可靠性。
例如,為了測量可用性,您可以將幫助台電話呼叫與從受管裝置收集的統計資料進行協調。但是,可用性工具無法確定故障的所有原因。
網路冗餘是衡量可用性時要考慮的另一個因素。冗餘丟失表示服務降級,而不是整個網路故障。結果可能是響應時間較慢,並且由於丟包而導致資料丟失。結果也可能出現在效能測量的其他領域,例如利用率和響應時間。
最後,如果根據SLA提供服務,您應該考慮計畫內停機。這些中斷可能是由於移動、新增和更改、工廠關閉或您可能不希望報告的其它事件所導致的。這不僅是一項困難的任務,而且可能是手動任務。
網路響應時間是流量在兩個點之間傳輸所需的時間。通過基線比較或超過閾值時,響應時間比正常值慢可能表示擁塞或網路故障。
響應時間是衡量客戶網路使用的最佳指標,可以幫助您衡量網路的有效性。無論慢響應的來源是什麼,使用者都會因為流量延遲而感到沮喪。在分散式網路中,影響響應時間的因素很多,如:
網路擁塞
到目的地的路由少於期望的路由(或者根本就沒有路由)
網路裝置供電不足
廣播風暴等網路故障
噪音或CRC錯誤
在採用QoS相關排隊的網路中,響應時間測量非常重要,它可以確定正確的流量型別是否如預期一樣通過網路傳輸。例如,當您通過IP網路實施語音流量時,語音資料包必須按時按恆定速率傳送,以便保持良好的語音品質。您可以生成分類為語音流量的流量,以測量對使用者顯示的流量的響應時間。
您可以測量響應時間,以幫助解決應用伺服器和網路管理器之間的爭鬥。當應用程式或伺服器速度慢時,網路管理員通常會被推定為有罪。網路管理員必須證明網路不是問題。響應時間資料收集提供了無可爭辯的手段,可以證明或反駁網路是應用程式故障的根源。
如果可能,您應測量對使用者顯示的響應時間。使用者從按下Enter鍵或按一下按鈕到螢幕顯示的時間開始感知響應。此用時包括每台網路裝置、使用者工作站和目的伺服器處理流量所需的時間。
不幸的是,由於使用者數量和工具匱乏,這一水準的測量幾乎是不可能的。此外,當您結合使用者和伺服器響應時間時,當您確定未來的網路增長或排除網路故障時,它提供的價值很小。
您可以使用網路裝置和伺服器來測量響應時間。您還可以使用ICMP等工具來測量事務,雖然它不會考慮上層處理系統時引入的任何延遲。該方法解決了網路效能知識的問題。
在簡單的層次上,您可以對從網路管理站到網路中的關鍵點(如大型機介面、服務提供商連線的端點或關鍵使用者IP地址)的ping響應進行計時,以測量響應時間。該方法的問題在於它不能準確反映使用者對其機器和目的機器之間響應時間的感知。它只是從網路管理站的角度收集資訊並報告響應時間。此方法還逐跳地遮蔽整個網路中的響應時間問題。
替代以伺服器為中心的輪詢的方法是將工作分佈得更靠近您要模擬進行測量的源和目標。使用分散式網路管理策略並實施Cisco IOS服務保證代理(SAA)功能。您可以在路由器上啟用SAA,以測量路由器和目標裝置(如伺服器或另一台路由器)之間的響應時間。您還可以指定TCP或UDP埠,該埠會強制採用與模擬流量相同的方式轉發和定向流量。
通過在多服務網路上整合語音、影片和資料,客戶在其網路中實施QoS優先順序劃分。簡單的ICMP或UDP測量無法準確反映響應時間,因為不同的應用程式接收不同的優先順序。此外,使用標籤交換時,流量路由可能因特定資料包中包含的應用程式型別而異。因此,ICMP ping在每台路由器處理它的方式上可能收到不同的優先順序,也可能收到不同的低效路由。
在這種情況下,測量響應時間的唯一方法是生成類似於所關注的特定應用程式或技術的流量。這會強制網路裝置按照處理實際流量的方式處理流量。您也許能夠通過SAA或使用第三方應用感知探測器達到此級別。
準確性是衡量不會導致錯誤的介面流量的指標,可以用將一段時間的成功率與總資料包率進行比較的百分比來表示。您必須首先測量錯誤率。例如,如果每100個資料包中有兩個導致錯誤,則錯誤率為2%,準確率為98%。
在早期的網路技術中,特別是在廣域網中,一定程度的錯誤是可以接受的。但是,對於高速網路和當今的WAN服務,傳輸要準確得多,除非存在實際問題,否則錯誤率接近於零。介面錯誤的一些常見原因包括:
超出規格的佈線
電干擾
硬體或軟體故障
使用更低的準確率來觸發更詳細的研究。您可能會發現特定介面出現問題,並決定這些錯誤是可接受的。在這種情況下,應調整此介面的準確度閾值,以反映錯誤率無法接受的位置。在較早的基線中可能已報告了不可接受的錯誤率。
下表所述的變數用於精確度和誤差率公式:
表示法 | 說明 |
---|---|
ΔifInErrors | 收集snmp ifInErrors對象的兩個輪詢週期之間的差值(或差值),它表示出錯的入站資料包計數。 |
ΔIfInUcastPkts | 收集snmp ifInUcastPkts對象(表示入站單播資料包的計數)的兩個輪詢週期之間的增量。 |
ΔifInNUcastPkts | 收集snmp ifInNUcastPkts對象的兩個輪詢週期之間的增量,該對象表示入站非單播資料包(組播和廣播)的計數。 |
錯誤率的公式通常以百分比表示:
錯誤率=(ΔifInErrors)*100
-------------------------------------
(ΔifInUcastPkts +(ΔifInNUcastPkts)
請注意,出站錯誤不在錯誤率和準確度公式中。這是因為裝置決不應故意將存在錯誤的資料包放在網路上,而且出站介面錯誤率決不應增加。因此,入站流量和錯誤是衡量介面錯誤和準確性的唯一標準。
精確度公式採用誤差率並從100中減去它(再次以百分比形式):
精度= 100 -(ΔifInErrors)*100
-----------------------------------------
(ΔifInUcastPkts +(ΔifInNUcastPkts)
這些公式反映了MIB II介面(RFC 2233)通用計數器的錯誤和準確性。結果以一個百分比表示,該百分比將錯誤與看到和傳送的資料包總數進行比較。從100減去結果的誤差率,從而產生精確率。100%的準確率是完美的。
由於MIB II變數以計數器的形式儲存,因此您必須執行兩個輪詢週期並計算兩者之間的差值(因此等式中使用了Delta)。
利用率可衡量一段時間內特定資源的使用情況。度量通常以百分比的形式表示,在該百分比中,資源的使用量與其最大運行能力進行比較。通過利用措施,您可以識別整個網路的擁塞(或潛在擁塞)。您還可以確定未充分利用的資源。
利用率是確定網路管道(鏈路)的完整程度的主要衡量標準。 測量CPU、介面、隊列和其他與系統相關的容量測量值,以確定網路系統資源消耗的程度。
高利用率不一定很差。低利用率可能表示流量在意外的位置。當線路過度使用時,效果會變得顯著。當排隊要通過某個介面傳輸的流量超過該介面可處理的流量時,就會發生過度利用。資源利用率的突然跳動可能表明存在故障情況。
當介面變得擁塞時,網路裝置必須將資料包儲存在隊列中或將其丟棄。如果路由器嘗試將封包儲存在完整佇列中,封包會遭捨棄。當流量從快速介面轉發到較慢的介面時,就會產生丟棄的資料包。此值在公式Q = u /(1-u)中指示,其中u是利用率,而Q是平均隊列深度(假設的隨機流量)。 因此,鏈路上的高利用率級別會導致較高的平均隊列深度,如果您知道資料包大小,就會發現延遲。一些網路報告供應商表示,您可以為廣域網訂購更少的頻寬和更少的費用。但是,如果以95%的利用率運行WAN鏈路,就會出現延遲影響。此外,隨著網路遷移到VoIP,網路管理員可能需要更改策略並以大約50%的利用率運行WAN鏈路。
捨棄封包時,較高層通訊協定可能會強制重新傳輸封包。如果丟棄多個資料包,可能會導致重試流量過大。這種反應可能導致在更下游的裝置上進行備份。為了解決此問題,您可以設定不同程度的閾值。
網路利用率的主要衡量標準是介面利用率。根據您測量的連線是半雙工還是全雙工,使用此表中描述的公式:
表示法 | 說明 |
---|---|
ΔifInOctets | 收集snmp ifInOctets對象的兩個輪詢週期之間的差值(或差值),它表示入站八位位元組的流量計數。 |
ΔifOutOctets | 收集snmp ifOutOctets對象(表示出站八位組流量計數)的兩個輪詢週期之間的增量。 |
ifSpeed | snmp ifSpeed對象中報告的介面速度。請注意,IfSpeed可能無法準確反映WAN介面的速度。 |
共用LAN連線往往是半雙工,主要是因為爭用檢測要求裝置在傳輸之前偵聽。WAN連線通常是全雙工,因為連線是點對點的;兩台裝置可以同時傳送和接收,因為他們知道只有一台其它裝置共用連線。
由於MIB II變數以計數器的形式儲存,因此您必須執行兩個輪詢週期並計算兩者之間的差值(因此等式中使用了Delta)。
對於半雙工介質,使用以下公式計算介面利用率:
(ΔIfInOctets + ΔifOutOctets)* 8 * 100
----------------------------------------------------
(Δ中的秒數)* ifSpeed
對於全雙工介質,利用率計算更為複雜。例如,若使用完整的T-1串列連線,線路速度為1.544 Mbps。這意味著T-1介面可以以3.088 Mbps的組合頻寬接收和傳輸1.544 Mbps。
計算全雙工連線的介面頻寬時,可以使用此公式,在該公式中,取較大的in和out值,並生成利用率百分比:
max(ΔifInOctets,(ΔifOutOctets)* 8 * 100
-----------------------------------------
(Δ中的秒數)* ifSpeed
但是,此方法會隱藏具有較小值的方向的利用率,並且提供的結果也不準確。更準確的方法是分別測量輸入利用率和輸出利用率,例如:
輸入利用率= ΔifInOctets *8 * 100
-------------------------------------
(Δ中的秒數)* ifSpeed
和
輸出利用率= ΔifOutOctets *8 * 100
------------------------------------
(Δ中的秒數)* ifSpeed
雖然這些公式稍加簡化,但它們並未考慮與特定通訊協定相關的額外負荷。有更精確的公式來處理每種協定的獨特方面。例如,RFC 1757包含考慮資料包開銷的乙太網利用率公式。但是,高可用性團隊發現,在大多數情況下,此處提供的通用公式可以在LAN和WAN介面上可靠地使用。
如前所述,容量規劃是確定可能的未來網路資源需求的過程,以防止對業務關鍵型應用程式的效能或可用性產生影響。請參閱容量和效能管理:最佳實踐白皮書,瞭解有關此主題的更多詳細資訊。
主動故障分析對效能管理至關重要。為效能管理收集的資料型別同樣可用於主動故障分析。但是,主動故障管理和效能管理之間的時間安排和使用情況有所不同。
主動故障管理是理想的網路管理系統實現您確定的目標的方式。與績效管理的關係是通過基線和使用的資料變數。主動故障管理整合了定製的事件、事件關聯引擎、故障通知單和基線資料的統計分析,以便將故障、效能和變更管理結合到一個理想、有效的網路管理系統中。
通常每10、15甚至30分鐘完成一次效能資料輪詢,因此故障條件識別的時間間隔必須短得多。一種主動故障管理方法是使用RMON警報和事件組。您可以在未由外部裝置輪詢的裝置上設定閾值,以便閾值更短。本文檔未介紹的另一種方法是,使用分散式管理系統,在本地級別啟用輪詢,在管理員的管理員處聚合資料。
閾值是在特定資料流中定義關注點並在觸發閾值時生成事件的過程。使用網路效能資料設定這些閾值。
有幾種不同型別的閾值,其中一些更適用於某些型別的資料。閾值僅適用於數碼資料,因此可以將任何文本資料轉換為離散的數字值。即使您不知道某個對象的所有可能的文本字串,您仍然可以列舉「有趣的」字串並將所有其他字串賦給一個設定值。
這兩類數值資料具有兩類閾值:連續和離散。連續閾值適用於連續資料或時間序列資料,例如儲存在SNMP計數器或計量器中的資料。離散閾值適用於列舉對象或任何離散數值資料。布林對象是用兩個值列舉的值:真或假。離散資料也可以稱為事件資料,因為事件會標籤從一個值到下一個值的轉換。
如果時間系列對象超過閾值的指定值,連續閾值可能會觸發事件。對象值高於或低於閾值。設定單獨的上升和下降閾值也可以很有用。這種技術稱為滯後機制,可幫助減少此類資料生成的事件數。遲滯機制用於減小在快速變化的時間序列資料上由閾值生成的事件量。這個機制可以和任何閾值技術一起使用在時間序列資料上。
事件數量通過生成以跟蹤對象值的警報來減少。此警報具有上升和下降閾值。僅當超過上升閾值時才觸發警報。一旦超過此閾值,在超過下降閾值之前,不會再次生成上升警報。並且相同的機制防止產生下降閾值,直到再次超過上升閾值。此機制可以顯著減少事件數量,而且不能消除確定是否存在故障所需的資訊。
時序資料可以表示為計數器,其中每個新資料點被新增到先前資料點的總和,或者可以表示為標尺,其中資料被表示為在一個時間間隔內的速率。適用於每種資料型別的連續閾值有兩種不同的形式:絕對連續閾值和相對連續閾值。對儀表使用絕對連續閾值,對計數器使用相對連續閾值。
為了確定網路的閾值,請完成以下步驟:
選擇對象。
選擇裝置和介面。
確定每個對象或對象/介面型別的閾值。
確定每個閾值生成的事件的嚴重性。
要確定在哪些對象(以及哪些裝置和介面)上使用哪些閾值,需要大量工作。 幸運的是,如果您收集了效能資料的基線,您已經完成大量的這項工作。此外,NSA和高可用性服務(HAS)程式可以提出建議,幫助您設定對象和建立範圍。但是,您必須為您的特定網路定製這些建議。
由於您已經收集了網路的效能資料,因此HAS程式建議您按類別將介面分組。這樣可以簡化閾值設定,因為可能需要為每個類別(而不是該裝置上每個裝置和對象)的媒體型別確定閾值。例如,您想為乙太網和FDDI網路設定不同的閾值。一般認為,與共用乙太網網段相比,運行FDDI網路的利用率更接近100%。但是,全雙工乙太網的運行速度可能接近100%,因為它們不會發生衝突。您可能會想要將全雙工連結的衝突閾值設定為非常低,因為您永遠不會看到衝突。
您還可以考慮介面重要性和閾值型別的類別/嚴重性的組合。使用這些因素來設定事件的優先順序,從而設定事件的重要性以及網路操作人員的關注度。
對網路裝置和介面的分組和分類強調得不過分。對閾值事件進行分組和分類的能力越強,就越容易將閾值事件整合到網路管理平台中。將基線用作此資訊的主要資源。請參閱容量和效能管理:最佳實踐白皮書,瞭解更多資訊。
組織應實施網路管理系統,能夠檢測定義的閾值並報告指定時間段內的值。使用一種RMON網路管理系統,該系統可以將閾值消息存檔到日誌檔案中,以便每天檢視,也可以使用一種更完整的資料庫解決方案來搜尋給定引數的閾值異常。該資訊應持續提供給網路操作人員和經理。網路管理實施應包括檢測軟體/硬體崩潰或回溯、介面可靠性、CPU、鏈路利用率、隊列或緩衝區未命中數、廣播容量、載波轉換和介面重置的能力。
與效能管理重疊的最後一個主動故障管理領域是網路運營指標。這些度量為故障管理流程的改進提供了有價值的資料。至少,這些指標應該包括給定時期發生的所有問題的明細。細目應包括如下資訊:
按呼叫優先順序顯示的問題數
每個優先順序的最小、最大和平均關閉時間
按問題型別(硬體、軟體崩潰、配置、電源、使用者錯誤)細分問題
每種問題型別的關閉時間細分
按可用性組或SLA列出的可用性
您達到或錯過SLA要求的頻率
幫助台通常具有能夠生成度量或報告的報告系統。收集此資料的另一種方法是使用可用性監視工具。整體指標應每月提供。應實施基於討論的流程改進,以改進未達到服務級別協定要求或改進某些問題型別的處理方式。
績效指標是組織用來衡量關鍵成功因素的機制。
本文檔可以是網路管理的正式操作概念,也可以是所需功能和目標的非正式說明。但是,在衡量成功與否時,本文檔應該為網路管理員提供幫助。
本文檔是組織網路管理策略,應協調網路運營、工程、設計、其他業務部門和終端使用者的總體業務(非定量)目標。這一重點使組織能夠形成網路管理和運營的長期規劃活動,其中包括預算過程。它還指導如何獲得實現網路管理目標(例如SLA)所需的工具和整合路徑。
這份戰略檔案不能過於狹隘地側重於具體網路問題的管理,而是側重於對整個組織而言重要的專案,其中包括預算問題。例如:
確定具有可實現目標的綜合計畫。
確定需要網路支援的每項業務服務/應用程式。
確定衡量服務所需的那些基於效能的指標。
規劃效能度量資料的收集和分發。
確定網路評估和使用者反饋所需的支援。
有文檔記錄、詳細且可衡量的服務級別目標。
為了正確記錄SLA,您必須完全定義服務級別目標度量。使用者應可使用本文檔進行評估。它提供反饋環路,確保網路管理組織繼續衡量維護服務協定級別所需的變數。
SLA是「有生命的」文檔,因為業務環境和網路本質上是動態的。今天衡量SLA的方法可能在明天就過時了。只有當網路運營部門從使用者處形成反饋環路,並根據該資訊採取行動時,它們才能保持組織所需的高可用性數量。
此清單包括輪詢間隔、產生的網路管理開銷、可能的觸發閾值、變數是否用作陷阱的觸發條件,以及針對每個變數使用的趨勢分析等專案。
這些變數不限於上述服務級別目標所需的指標。它們至少應包括以下變數:路由器運行狀況、交換機運行狀況、路由資訊、特定於技術的資料、利用率和延遲。這些變數定期輪詢並儲存在資料庫中。然後,可以根據此資料生成報告。這些報告可通過以下方式為網路管理運營和規劃人員提供幫助:
使用歷史資料庫通常可以更快地解決被動問題。
效能報告和容量規劃需要此類資料。
服務級別目標可以根據它來衡量。
網路管理人員應舉行會議,定期檢視具體報告。這樣可以提供額外的反饋,並主動解決網路中的潛在問題。
這些會議應包括業務和規劃人員。這為規劃人員提供了機會,使他們能夠接收基準資料和趨勢資料的操作分析。它還讓操作人員進入到一些規劃分析的「循環中」。
要包括在這些會議中的另一類專案是服務級別目標。在接近目標閾值時,網路管理人員可以採取行動以防止失去目標,在某些情況下,這些資料可用作部分預算理由。資料可以顯示,如果不採取適當的措施,服務級別目標會遭到哪些破壞。而且,由於這些目標已經通過業務服務和應用程式確定,因此更容易從財務角度加以論證。
每兩週進行一次稽核,每六至十二週舉行一次更全面的分析會議。通過這些會議,您可以解決短期和長期問題。
假設分析涉及對解決方案進行建模和驗證。在向網路新增新的解決方案(新應用程式或Cisco IOS版本中的更改)之前,請記錄一些替代方案。
此分析的文檔包括主要問題、方法、資料集和配置檔案。要點在於,假設分析是一個實驗,其他人應該能使用文檔中的資訊重新建立這個實驗。
本文檔包括額外的WAN頻寬和有助於增加特定鏈路型別頻寬的成本表。此資訊可幫助組織瞭解增加頻寬所需的時間和成本。通過正式文檔記錄,績效和容量專家可以瞭解提升績效的方式和時間,以及此類工作的時間安排和成本。
定期檢視此文檔,可能是作為季度績效稽核的一部分,以確保它保持最新。
實現理想的網路管理系統的唯一途徑就是將效能管理的各個元件主動地整合到系統中。此目標應包括使用在閾值超出閾值時與通知系統繫結的可用性和響應時間度量。它必須包括使用容量規劃基線,該基線具有到調配和異常報告啟發式模型的連結。它可擁有內建建模或模擬引擎,使模型能夠即時更新,並通過軟體模擬提供規劃和故障排除級別。
儘管這個系統的大部分看似不可能實現的理想,但每個元件目前都已上市。此外,用於整合這些元件的工具也存在於MicroMuse等程式中。我們應該繼續朝著這個理想努力,因為今天這個理想比以往任何時候都更加現實。
修訂 | 發佈日期 | 意見 |
---|---|---|
1.0 |
02-Dec-2013 |
初始版本 |