簡介
本文檔介紹對以應用為中心的基礎設施(ACI)升級問題進行故障排除的步驟以及在升級過程之前和期間應遵循的最佳實踐。
ACI升級包括更新應用策略基礎設施控制器(APIC)軟體和交換機（枝葉和主幹）。交換機升級通常非常簡單，但是APIC升級可能涉及一些群集問題。以下是思科建議在開始升級前準備的一些預先檢查。
升級之前
開始ACI升級之前，請確保執行一些預檢查，以避免任何意外行為。
APIC升級前要採取的措施
- 清除所有故障
ACI交換矩陣狀態存在許多故障，例如存在無效或衝突策略，甚至介面斷開連線等。開始升級之前，請瞭解觸發器並清除它們。請注意，這些錯誤例如 encap already been used 或 Routed port is in L2 mode 可能導致意外的中斷。升級交換器時，會從零開始從APIC下載所有原則。因此，意外的策略可能會接管可能導致中斷的預期策略。
- 清除VLAN池重疊
VLAN池重疊表示相同的VLAN ID是兩個或多個VLAN池的一部分。如果在屬於不同VLAN池的多個枝葉交換機上部署相同的VLAN ID，則這些交換機上將有不同的VXLAN ID。由於ACI使用VXLAN ID進行轉送，因此目的地為特定VLAN的流量最終可能位於不同的VLAN中，或被捨棄。由於枝葉在升級後從APIC下載配置，因此VLAN的部署順序起著重要作用。因此，這可能會導致某些VLAN中的端點出現中斷或間歇性連線遺失。
開始升級之前，請務必檢查VLAN ID重疊情況並更正錯誤。建議一個VLAN ID僅屬於一個VLAN池，並在需要時重複使用VLAN池。
- 確認支援的升級路徑
APIC升級涉及從內部執行的一個版本到另一個版本的資料轉換。為了使資料轉換成功，需要解決一些版本相容性問題。請務必檢查思科是否支援從您當前的ACI版本直接升級到您要升級到的新目標版本。有時，您必須經過多個躍點才能到達目標版本。如果升級到不受支援的版本，可能會導致群集問題和配置問題。
支援的升級路徑一律列在思科ACI升級指南中。
- 備份APIC配置
在開始升級之前，請確保將配置備份匯出到遠端伺服器。如果在升級後丟失所有配置或出現資料損壞，則可以使用匯出的備份檔案在APIC上恢復配置。
附註：如果啟用備份加密，請確保儲存加密金鑰。否則，包括admin密碼在內的所有使用者帳戶密碼將無法正確匯入。
- 確認APIC CIMC訪問
思科整合管理控制器(CIMC)是遠端控制檯訪問APIC的最佳方式。如果APIC在重新啟動後沒有恢復或進程停滯，則可能無法通過APIC的帶外或帶內管理連線到APIC。在此階段，您可以登入CIMC並連線到KVM控制檯，以便進行APIC的一些檢查並對問題進行故障排除。
- 檢查並確認CIMC版本相容性
在開始ACI升級之前，請始終確保運行與目標ACI版本相容的思科建議CIMC版本。請參閱建議的APIC和CIMC版本。
- 確認APIC進程未鎖定
在APIC中運行的名為Appliance Element(AE)的過程負責觸發APIC中的升級。CentOS智慧平台管理介面(IPMI)中存在一個已知的錯誤，該錯誤可能會鎖定APIC中的AE進程。如果AE進程被鎖定，APIC韌體升級將不會啟動。此過程每10秒查詢一次機箱IPMI。如果AE進程在最近10秒內未查詢機箱IPMI，這可能意味著AE進程被鎖定。
您可以檢查AE進程的狀態以瞭解最後一個IPMI查詢。在APIC CLI中，輸入命令 date 以檢查當前的系統時間。現在輸入以下命令 grep "ipmi" /var/log/dme/log/svc_ifc_ae.bin.log | tail -5 並檢查AE進程上次查詢IPMI的時間。將時間與系統時間進行比較，以檢查上次查詢是否在系統時間的10秒視窗內。
如果AE進程在系統時間的最後10秒內無法查詢IPMI，您可以在開始升級之前重新啟動APIC以恢復AE進程。
附註：請勿同時重新啟動兩個或多個APIC以避免任何群集問題。
- 檢查並確認NTP可用性
從每個APIC ping並確認與NTP伺服器的可達性，以避免由於APIC時間不匹配而導致的已知問題。有關這方面的更多詳情，請參見本文的故障排除部分。
- 檢查APIC運行狀況狀態
在開始升級之前，檢查並確認集群中APIC的運行狀況。健康得分為255表示APIC是健康的。輸入命令 acidiag avread | grep id= | cut -d ' ' -f 9,10,20,26,46 從任何APIC CLI檢查APIC運行狀況狀態。如果任何APIC的運行狀況得分不是255，請不要開始升級。
- 評估新版本的影響
在開始升級之前，請檢視目標ACI版本的發行說明，並瞭解適用於交換矩陣配置的任何行為更改，以避免升級後出現任何意外結果。
- 在實驗室中準備升級
思科建議在實際生產交換矩陣之前，先在實驗室或測試交換矩陣中嘗試升級，以便熟悉新版本中的升級和行為。這也有助於評估升級後您可以運行到的任何可能問題。
交換器升級前要做的事項
- 將虛擬埠通道(vPC)和冗餘枝葉對置於不同的維護組中
ACI APIC具有從特定版本和更新版本檢查和延遲vPC對枝葉節點升級的機制。但是，最佳做法是將vPC對交換機置於不同的維護組中，以避免兩個vPC交換機同時重新啟動。
在非vPC交換機冗餘的情況下（如邊界枝葉），請確保將它們放在不同的埠組中，以避免任何中斷。
疑難排解升級問題
如果升級停滯或失敗，請始終開始排除APIC1故障。如果APIC1升級尚未完成，則在APIC2和APIC3中不要執行任何操作。APIC升級過程是遞增的，因此，APIC2僅在APIC1完成升級並通知APIC2有關升級等操作之後才會升級。因此，違反此規則可能會使群集處於中斷狀態，資料庫已損壞，您可能需要重建群集。
案例：APIC ID 2或更高版本停滯在75%
在此案例中，您會看到APIC1已成功升級，但APIC2仍停滯在75%。如果未將APIC1升級版本資訊傳播到APIC2或更高版本，則會發生此問題。請注意 svc_ifc_appliance_director 進程負責APIC之間的版本同步。
如何疑難排解
步驟1:確保APIC1可以使用其TUNNEL End Point(TEP)IP地址對其餘APIC執行ping操作，因為這將確定您是需要從枝葉交換機進行故障排除，還是需要從APIC本身繼續。如果APIC1無法ping通APIC2，您可能需要致電技術支援中心(TAC)對交換機進行故障排除。如果APIC1可以ping通APIC2，請繼續執行第二步。
步驟2:由於APIC可以相互ping通，因此APIC1的版本資訊應該被複製到對等裝置，但不知何故未被對等裝置接受。版本資訊由版本時間戳標識。您可以從CLI和APIC2 CLI確認APIC1的版本時間戳，後者正在等待75%。
在APIC1上
apic1# acidiag avread | grep id=1 | cut -d ' ' -f20-21
version=2.0(2f) lm(t):1(2018-07-25T18:01:04.907+11:00)
在APIC2上
apic2# acidiag avread | grep id=1 | cut -d ' ' -f20-21
version=2.0(1m) lm(t):1(2018-07-25T18:20:04.907+11:00)
如您所見，在此示例中運行版本2.0(1m)的APIC2(18:20:04)的版本時間戳高於運行版本2.0(2f)的APIC1(18:01:04)的版本時間戳。 因此，APIC2安裝程式進程認為APIC1升級尚未完成，等待75%。當APIC1的版本時間戳高於APIC2的版本時間戳時，APIC2升級將開始。但是，基於時間差異，這可能非常等待。若要將光纖從該狀態中復原，您可以開啟TAC案例，以取得協助來從APIC1進行疑難排解和修正問題。
意見