簡介
本文檔介紹了以應用為中心的基礎設施(ACI)故障生成的高級流程,以及如何防止特定故障生成。本文檔通過兩個示例演示了這一點。
如何產生故障以及如何選擇性防止故障產生
高級機制
- 每個故障是類faultInst(或faultDelegate)的託管對象(MO)。 此故障MO由另一個MO(通常是其父項)生成,因為違反了某些規則。
- 樹中可生成故障的每個MO都有一個屬性monPolDn,該屬性指向另一個作為監控策略對象的MO。此對象允許修改該屬性,並允許觸發器生成錯誤。監視策略對象有多個類,例如:
- MonInfraPol — 處理基礎設施策略(VMM管理器、訪問埠策略、物理埠等) — 位於Fabric > Access Policies > Monitoring policies
- monFabricPol — 處理交換矩陣監控 — 位於Fabric > Fabric Policies > Monitoring policies
- monEPGPol — 處理租戶監控>位於「租戶」>「監控策略」選單中
- 通常它是預設監控對象。但是,通過轉到對象模型的特定區域,您可以為任何監視策略類建立特定的使用者定義的監視策略。
- 您可以修改這些監視策略的許多屬性。此示例將說明如何防止為其應用監視策略的所有對象生成給定的故障。但是,您還可以修改故障生命週期計時器(保留時間、浸泡時間等)。
- 為了修改錯誤嚴重性或防止生成錯誤,您需要選擇與生成此對象的MO的類相對應的監視對象(例如,錯誤的父級)。
- 然後,在此類下,選擇要修改的故障代碼,並選擇值的初始嚴重性「壓制」。
這可以防止分配給此特定監視策略的MO生成該代碼的任何故障。
示例1 — 租戶中的故障
每個故障都與一個對象相關聯。
admin@apic:~> moquery -d "uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11]/fault-F0879"
Total Objects shown: 1
# fault.Inst
code : F0879
ack : no
cause : resolution-failed
changeSet :
childAction :
created : 2015-01-22T00:05:00.286+01:00
descr : Failed to form relation to MO uni/tn-RD/ap-App_RD1/epg-EPG_RD11 of class fvAEPg
dn : uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11]/fault-F0879
domain : infra
highestSeverity : warning
lastTransition : 2015-01-22T00:05:00.286+01:00
lc : raised
modTs : never
occur : 1
origSeverity : warning
prevSeverity : warning
rn : fault-F0879
rule : dbgac-rs-to-epg-resolve-fail
前一個故障是類故障的MO。Inst,代碼為F0879。
該故障與終端組(EPG)對象相關聯,如下所示。
此對象是故障的父級的可分辨名稱(DN)。此父對象屬於dbg.RsToEpg類。
admin@apic:~> moquery -d uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11]
Total Objects shown: 1
# dbgac.RsToEpg
tDn : uni/tn-RD/ap-App_RD1/epg-EPG_RD11
childAction :
dn : uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11]
forceResolve : no
lcOwn : local
modTs : 2014-12-05T12:56:29.340+01:00
monPolDn : uni/tn-RD/monepg-RD_Monitoring
rType : mo
rn : rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11]
state : missing-target
stateQual : none
status :
tCl : fvAEPg
tType : mo
uid : 15374
您可以看到此EPG對象與monPolDn對象相關聯。樹中的大多數對象由監控對象監控。
以下是使用dn的類monEPGPol的用戶定義的監視對象。
uni/tn-RD/monepg-RD_Monitoring
以下是用於監控的完整對象。
admin@apic:~> moquery -d uni/tn-RD/monepg-RD_Monitoring
Total Objects shown: 1
# mon.EPGPol
name : RD_Monitoring
childAction :
descr :
dn : uni/tn-RD/monepg-RD_Monitoring
lcOwn : local
modTs : 2014-11-13T15:41:45.326+01:00
monPolDn : uni/tn-RD/monepg-RD_Monitoring
ownerKey :
ownerTag :
rn : monepg-RD_Monitoring
status :
uid : 10673
monEPGPol對象在租戶監控策略下配置,您可以在其中建立新策略或修改預設策略。以下是monEPGPol名稱RD_Monitoring的示例。
可以選擇故障嚴重性分配策略並按一下鉛筆(在Monitoring對象旁邊)。
然後,如果您在該監視策略的監視對象清單中選擇建立故障的類(此處dbgac.RsToEpg)。
您可以看到與該特定類關聯的所有故障(此處顯示的唯一故障是F0789)。
故障F0789是故障在示例開頭顯示的代碼。
您可以選擇此故障,如果將初始Severity設定為squeled(可以保留Target Severity繼承),則假定此類故障是由具有您剛才修改的監視策略連結的對象生成的,這樣可以防止將來生成此類故障。
然而,它不能清除現有故障,只能清除新故障。
示例2 — 物理故障
在此範例中,由於枝葉上的連線埠1/25為admin up,但其中沒有SFP,因此產生錯誤。
admin@apic:~> moquery -c faultInst -f 'fault.Inst.code == "F1678"'
Total Objects shown: 2
# fault.Inst
code : F1678
ack : no
cause : port-failure
changeSet : usage (New: epg)
childAction :
created : 2015-01-19T14:26:13.862+01:00
descr : TEST FAULT -- Port is down, reason:sfpAbsent(connected), used by:EPG,
lastLinkStChg:1970-01-01T01:00:00.000+01:00, operSt:down
dn : topology/pod-1/node-101/sys/phys-[eth1/25]/phys/fault-F1678
domain : access
highestSeverity : critical
lastTransition : 2015-01-19T14:28:41.668+01:00
lc : raised
modTs : never
occur : 1
origSeverity : critical
prevSeverity : critical
rn : fault-F1678
rule : ethpm-if-port-down-infra-epg-test
severity : critical
status :
subject : port-down
type : communications
uid :
這與物理埠相關聯。以下是產生該錯誤的父MO。
admin@apic:~> moquery -d topology/pod-1/node-101/sys/phys-[eth1/25]/phys
Total Objects shown: 1
# ethpm.PhysIf
accessVlan : vlan-1
allowedVlans :
backplaneMac : 50:87:89:A2:2A:C1
bundleBupId : 1
bundleIndex : unspecified
cfgAccessVlan : vlan-1
cfgNativeVlan : vlan-1
childAction :
currErrIndex : 4294967295
diags : none
dn : topology/pod-1/node-101/sys/phys-[eth1/25]/phys
encap : 3
errDisTimerRunning : no
errVlanStatusHt : 0
errVlans :
hwBdId : 0
intfT : phy
iod : 29
lastErrors : 0
lastLinkStChg : 1970-01-01T01:00:00.000+01:00
media : 2
modTs : never
monPolDn : uni/infra/moninfra-default
nativeVlan : vlan-1
這與如下所示配置的monInfraPol對象相關聯。
admin@apic:~> moquery -c monInfraPol
Total Objects shown: 4
# mon.InfraPol
name : default
childAction :
descr :
dn : uni/infra/moninfra-default
lcOwn : local
modTs : 2014-08-06T07:58:19.494+01:00
monPolDn : uni/infra/moninfra-default
ownerKey :
ownerTag :
rn : moninfra-default
status :
uid : 0
在Fault Severity Assignment(故障嚴重性分配)策略下,按一下monitoring object(監控對象)下拉選單旁的工作窗格中的鉛筆。新增可以在其中修改監視屬性的類。然後選擇生成故障的對象的類,即ethmPhysIf。
選擇此類並按一下+圖示以檢視為該對象生成的每個故障。
在此示例中,可以看到故障F1678,其屬性可以修改。如果選擇Initial severity Squeled和target severity inherit,則會防止應用此監視策略的對象生成該代碼的新錯誤。
進行變更後,如果您啟用沒有SFP的連線埠1/25,將不會產生任何故障!
註:在低於軟體版本2.2的版本中:不會清除現有故障(即使在「清除」保留模式下)。
註:在軟體版本2.2及更高版本中:即使現有故障也會受到新策略的影響。