基于MAPS監控策略的FC交換機自動化運維方案設計

張璇, 陳瑛

(上海杉達學院 信息科學與技術學院，上海 201209)

0 引言

存儲區域網絡(Storage Area Network，SAN)作為目前應用最為廣泛的存儲通道連接技術，核心在于通過FC交換機連接存儲設備和服務器主機，建立用于數據存儲的區域網絡。隨著SAN被廣泛應用于銀行、保險、運營商等企業的大型數據中心生產場景，FC交換機的自動監控和人工干預技術始終是運維人員重點關注的問題之一[1-6]。

在交換機的監控管理領域，使用最廣泛的網絡監控管理協議是簡單網絡管理協議SNMP(Simple Network Management Protocol)，其相關的研究或文獻也屢見不鮮。如趙琳、吳姣等[7]設計了一套基于SNMP的FC網絡管理軟件，把FC網絡上各個節點和交換機定義為MIB庫中的實例對象，通過對自擴展的網絡管理信息庫進行操作和維護，通過FC網絡發送查詢命令以及相應回復判斷網絡系統狀態，為網絡管理者提供決策依據；楊明光、張云飛等[8]利用Python語言編程實現了一種基于SNMP協議的網絡交換機狀態的監測系統；武韡、石亞軍[9]在Windows平臺上采用MySQL數據庫，通過ODBC連接，從底層開發實現基于SNMP協議的網絡預警系統。

但是對于特定產品如FC交換機，SNMP的監控粒度過大，交互能力不足，無法應對突發故障并做出及時響應處理。因此，在日常運維中，客戶普遍依賴于各廠家提供的專用工具，或是基于SNMP協議開發的第三方集中監控平臺。博通(Broadcom)公司旗下的博科(Brocade)系列交換機(FC Switch)作為目前市場的主流產品，因其可靠性、安全性和高性價比而聞名。然而，受限于Brocade市場推廣策略、培訓課程及參考資料的不足，國內對于其FC交換技術及其網絡設備應用領域的研究并不多見。

本文將以MAPS(Monitoring and Alerting Policy Suite)監控策略為切入點，探討博科(Brocade)DCX8510 FC交換機(Fabric OS 7.4.2a)的自動運維及干預策略。

1 相關技術

1.1 Monitoring and Alerting Policy Suite

博科FC交換機采用自主研發的Fabric OS系統，自Fabric OS 7.2.0開始，引入了Monitoring and Alerting Policy Suite(MAPS)網絡監控策略。通過這套監控策略機制，系統可以實時獲取硬件狀態、觸發錯誤報警，并自動運行各種預定義的保護策略[10]。

(1)MAPS可監控狀態

MAPS將其可監控的狀態進行歸類，共劃分為11類，如表1所示。

表1 MAPS監控狀態

這些狀態劃分保證了MAPS對FC交換機系統各模塊的詳細監測，用戶可以根據這些監測值來設計不同的策略及應對動作，以適應各種突發狀況。

(2)MAPS默認策略

監控策略(Policy)是針對監控對象所定義的一組規則(Rule)的集合。MAPS默認包含3項策略，涵蓋了常用監控狀態及其相應閾值，這些默認策略按照監控強度和閾值靈敏度進行劃分，旨在簡化用戶配置流程，以便用戶使用時可以在其基礎上進行規則的自定義。

1.2 MAPS監控策略與SNMP協議的比較

簡單網絡管理協議(SNMP)是目前使用最為廣泛的網絡管理及設備通訊協議，該協議具有兼容性高、可擴展性強、二次開發度便利等優點。同SNMP協議相比，MAPS存在以下幾點明顯優勢。

(1)部署簡單。SNMP采用客戶端服務器架構，且需要維護管理信息庫(MIB)的內容。相比之下，MAPS僅需要根據不同需求創建策略即可。

(2)針對性強。相比于SNMP的廣泛兼容性，MAPS的針對性更強，可以完全滿足FC交換機的日常維護要求。

(3)故障處理及時。同使用SNMP的監控平臺相比，MAPS可以在發現故障的第一時間實現動作干預，而無需與后臺服務器進行通訊響應。

(4)節約成本。同搭建SNMP監控平臺相比，使用MAPS的成本及維護時間更少。

2 基于MAPS的FC交換機自動化運維策略

對于FC交換機而言，鏈路錯誤(Link Layer Issue)是一類最常見且對用戶影響最大的故障。生產環境中對于SAN鏈路錯誤的判定和排查，通常有3個判定依據場景。

(1)對應鏈路存在CRC報錯且具有“good_eof”標識

(2)對應鏈路存在大量ENC_OUT、ITW或Link reset事件

(3)對應Port連接的光電轉換模塊SFP(Small Form-factor Pluggable)存在發送/接收功率(RXP/TXP)異常

其中，場景(2)通常依賴于運維人員的經驗判斷，而(1)和(2)則可以通過設計監控策略來實現自動運維。本文主要針對(3)即鏈路錯誤中常見的RXP/TXP異常設計監控策略，設計FC交換機的自動化運維方案并實現。

2.1 RXP/TXP異常監控策略設計思路

本策略主要針對RXP/TXP異常情況處理，通過配置Brocade DCX8510交換機端口(FC Port)的最大發送/接收功率的經驗閾值，定義“強制停用對應端口”(Fence)的應對動作(Action)。一旦MAPS監控到功率達到或超過了定義閾值，會自動將對應端口設置為禁用狀態(Disable)，這樣既能夠定位并處置了故障端口，也能避免其他設備受到故障鏈路的影響。

RXP/TXP異常監控策略的設計思路與流程如圖1所示。

圖1 RXP/TXP異常監控策略設計流程

2.2 RXP/TXP異常監控策略實現

步驟1：查看系統當前監控閾值

該步驟的目的在于確定系統MAPS默認策略定義的端口最大發送/接收功率(RXP/TXP)監控閾值，并根據當前使用的SFP類型確定合適的監控范圍。

系統MAPS默認最大發送、接收功率如圖2、圖3所示。

圖2、圖3說明對于不同速率的SFP模塊系統默認的RXP和TXP的監控范圍。由于當前監控閾值范圍過大，遠遠大于判定故障的經驗值100，因此需要重新進行設置，詳見步驟3。

圖2 系統MAPS默認最大發送功率

圖3 系統MAPS默認最大接收功率

步驟2：創建監控策略并關聯至相應對象組

為了更好地對監控對象進行管理和劃分，MAPS將其監控對象進行了分組(Group)管理，用戶可以根據需要創建不同的對象組。對象組具有不同的類型(Type)，該類型可以保證組內監控對象的一致性，避免不同對象混用造成的策略設計失誤。

查看系統監控對象組、關聯策略如圖4、圖5所示。

圖4 查看系統監控對象組

圖5 查看系統關聯策略

在圖4與圖5中，使用logicalgroup——show命令和mapspolicy-show-summary命令列出并查看系統現有的監控對象組(Group)及關聯策略(Policy)，請注意對象組的類型(Type)標志了FC交換機上不同的硬件，如“Port”“Fan”“Power Supply”“WWN”“Sfp”“Blade”“Flash”等，而RXP/TXP監控需要將 “Sfp”作為監控對象的類型。

步驟3：創建規則

監控策略(Policy)是我們針對監控對象所定義的一組規則(Rule)集合。對象組(Group)創建后我們可以將其與設計好的監控策略(Policy)進行關聯。為了監控最大發送/接收功率(RXP/TXP)，需要分別創建LowRXP和LowTXP兩條規則，其采樣監測間隔為1小時且該值無法修改，規則觸發后的應對動作(Action)為強制停用對應端口(Fence)并將其加入到對應策略(Policy)中。

1.LowRXP規則的創建過程如下。

(1)判定條件：RXP<100時發送SNMP trap。

(2)監控策略：copy_dflt_moderate_policy，采樣監測間隔為1小時且該值無法修改，規則觸發后的應對動作(Action)為強制停用對應端口(Fence)。

(3)配置命令：

DCX:FID128:admin> mapsrule--create LowRXP-monitor RXP-group ALL_SFP-op l-value 100-action fence-policy copy_dflt_moderate_policy

Rule has been created but policy is not present.

2.LowTXP規則的創建過程如下。

(1)判定條件：TXP<100時發送SNMP trap。

(2)監控策略：copy_dflt_moderate_policy，采樣監測間隔為1小時且該值無法修改，規則觸發后的應對動作(Action)為強制停用對應端口(Fence)。

(3)配置命令：

DCX:FID128:admin> mapsrule--create LowTXP-monitor TXP-group ALL_SFP-op l-value 100-action fence-policy copy_dflt_moderate_policy

Rule has been created but policy is not present.

步驟4：將步驟3規則導入新策略并啟用

上述規則創建后會出現系統提示“Rule has been created but policy is not present”，說明規則已經創建但是策略尚未啟用，因此需要使用下列命令啟用該策略。

DCX:FID128:admin> mapspolicy--enable < copy_dflt_moderate_policy >

規則和策略創建完成后需要進行可用性測試，如測試出現異常可使用如下命令進行刪除回退操作。

DCX:FID128:admin> mapsrule--delete LowRXP

DCX:FID128: admin> mapsrule--delete LowTXP

2.3 MAPS的全局應對動作

2.2針對發送/接收功率(RXP/TXP)異常情況定義的動作為“強制停用對應端口”，即“Fence”應對動作。事實上，除了“Fence”“Decommissioning”等針對不同平臺及監控對象定義的10余種應對動作外，MAPS還可以自定義全局應對動作。

使用mapsconfig--actions raslog，snmp,email,sfp_margina命令和mapsconfig--show命令可以添加并驗證全局MAPS應對動作，如圖6所示。

圖6 添加并驗證全局MAPS應對動作

特別需要注意的是，全局MAPS應對動作的優先級要高于規則中定義的應對動作，一旦兩者產生沖突，系統會按照全局動作的設置來進行應對動作。

3 MAPS與第三方監控平臺的交互

除了以上通過設置MAPS監控策略實現系統自動運維外，MAPS還預留了與第三方監控平臺的通訊接口，將所有的監控信息利用SNMP協議或郵件文本發送給第三方監控平臺，幫助相關人員在統一平臺下完成決策及維護。

3.1 第三方監控平臺接口設計

SNMP的網絡管理由3部分組成，即SNMP本身、管理信息結構SMI(Structure of Management Information)和管理信息庫MIB(Management Information Base)。SNMP定義了管理站和代理之間所交換的分組格式。SMI定義了命名對象和定義對象類型的通用規則，以及把對象和對象的值進行編碼的規則。MIB在被管理的實體中創建了對象并規定了其類型。即SMI建立規則，MIB對變量進行說明，而SNMP完成網管的動作[11]。在MAPS設計中，每個MAPS Trap都定義了問題嚴重級別并包含在MAPS Config Severity Level變量中,如圖7所示。

圖7 MAPS Traps定義的變量名示意

MAPS Severity Level包含的嚴重程度級別有“None”“Critical”“Error”“Warings”“Informational”“Debug”幾種，通?！癈ritical”和“Error”表明出現較為嚴重的硬件錯誤，需要人工干預，如圖8所示。

圖8 MAPS SeverityLevel

第三方監控平臺可通過SNMP Trap實時抓取數據并進行響應，預警信息通過郵件組進行轉發，可以自動關聯到短信網關通知到運維人員。首先，SNMP Trap接口接收含有OID 與MIB值的字符串；然后，利用MAPS的MIB庫文件，將字符串翻譯成明文；最后，經過判斷找出帶有Critical或Error字段的明文，發送短信。過程如圖9所示。

圖9 MAPS與第三方監控平臺交互設計流程

發送的MAPS短信范例如圖10所示。

圖10 短信內容范例

3.2 第三方監控平臺接口偽代碼

利用Python語言設計MAPS與第三方監控平臺交互接口的偽代碼如下。

(1)使用snmp trap 接口接收oid與mib值

cg = cmdgen.CommandGenerator()#獲取CommandGenerator對象

errorIndication, errorStatus, errorIndex, varBinds = cg.getCmd

(

0代表SNMPv1版本,1代表SNMPv2c版本

cmdgen.CommunityData('myagent', 'public', 1),

cmdgen.UdpTransportTarget(('127.0.0.1', 161)), #傳輸通道

'.1.3.6.1.2.1.1.1.0'#傳送的OID

)

print(str(varBinds[0][1]))#varBinds返回MIB值及獲得值

(2)使用mib查看器翻譯成明文

# Assemble MIB viewer

mibBuilder = builder.MibBuilder()

compiler.addMibCompiler(mibBuilder, sources=['file:///usr/share/snmp/mibs','http://mibs.test.com/test/@mib@'])

mibViewController = view.MibViewController(mibBuilder)

# Pre-load MIB modules we expect to work with

mibBuilder.loadModules('SNMPv2-MIB', 'SNMP-COMMUNITY-MIB')#mib文件的配置

# This is what we can get in TRAP PDU

varBinds =[

('1.3.6.1.2.1.1.3.0', 12345),

('1.3.6.1.6.3.1.1.4.1.0', '1.3.6.1.6.3.1.1.5.2'),

('1.3.6.1.6.3.18.1.3.0', '0.0.0.0'),

('1.3.6.1.6.3.18.1.4.0', ''),

('1.3.6.1.6.3.1.1.4.3.0', '1.3.6.1.4.1.20408.4.1.1.2'),

('1.3.6.1.2.1.1.1.0', 'my system')

]

(3)通過對每一次接收的oid翻譯，通過varBins所獲得的mid值判斷帶有critical或error字段

text = '#oid翻譯明文

for varBind in varBinds:

a = 0

test = varBind[1].prettyPrint()

text = text + test + ' '

if 'critical' in test:

a = 1

elif 'CRITICAL' in test:

a = 1

elif 'error' in test:

a = 1

elif 'ERROR' in test:

a = 1

(4)根據a 的值來決定是否發送短信

from twilio.rest import Client

# Your Account SID from twilio.com/console

account_sid = "your account sid"

# Your Auth Token from twilio.com/console

auth_token = "your token"

client = Client(account_sid, auth_token)

message = client.messages.create(

# 這里中國的號碼前面需要加86

to="+接收者的號碼",

from_="+twilio給你的號碼 ",

body="text")

print(message.sid)

print(call.sid)

# 發送到短信網關實現報警

4 總結

本文提出了一種基于博科(Brocade)MAPS(Monitoring and Alerting Policy Suite)監控策略實現FC交換機自動運維的方案，詳細介紹了MAPS監控策略的創建、定義、關聯及測試回退過程，并嘗試利用SNMP Trap接口，將MAPS預警消息同第三方監控平臺整合，提供了一種交互報警、人工干預的設計思路。本設計方案旨在盡可能節約資金與人力成本的前提下，充分利用交換機的現有機制，及時發現并自動處理常見交換機故障，為自動化運維工程提供了新的研究方向。