作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化暨分散式安全防護技術方案的介紹與推廣。

當企業認真開始考慮採用網路虛擬化後，NSX的維運、升級、管理方式理所當然的會變成IT單位關注的重點。我不只有一次與客戶討論，當架構轉為軟體定義資料中心、網路與安全功能轉移到虛擬化環境後，如何確保在NSX升級時不會影響到現有資料中心的作業，能夠達到無痛升級的方法。能不能夠達成？當然可以。本篇要和大家討論的重點，就是在初始規劃時有哪些注意事項，能夠讓我們後續進行NSX升級時，對業務的影響最小，IT管理者能夠邊翹腳看棒球，廣告時間再來確認升級完成了沒。

幾個重點我們先寫在前面，後面陸續討論：

• 請詳讀NSX Upgrade Guide，並確認升級後的構件相容性

• 請確保不要把NSX的管理構件與運算機器放在同樣的Cluster。也就是說，規劃時應該要有獨立的Management Cluster放置NSX Manager / NSX Controller以及其他標準管理構件，如vCenter / Operations Manager / Automation等

• 請在Compute Cluster啟用DRS自動轉移機制，而且確保vMotion作業能夠正常運作

• 請於Compute Cluster保留足夠的運算資源，讓vSphere Host陸續關機、重啟時，剩下運作的實體資源可以提供現有的運算資源運作，並且不違反Anti-Affinity Rule

首先第一個請大家要知道的是NSX的升級流程，用下面這張圖進行說明：

本文的重點不是要列出Step-by-Step的安裝步驟，請大家Read the FRIENDLY Menu。我們一定要非常親切地把Menu的網址列出來：http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_upgrade.pdf。升級是一件大事，請各位做這件事前一定要讀喔～

接著幾個重點請大家要注意的：

作業前，請確認升級後的構件相容性

NSX不是一個單一的構件，會和其他虛擬化、管理、安全廠商間的軟體有許多的Interlock。因此請大家務必確認升級NSX到新版時，與這些相關的構件都能維持相容性。VMware有非常方便的網頁可以針對VMware自己的產品相容性進行檢查，請到http://partnerweb.vmware.com/comp_guide/sim/interop_matrix.php 這個網頁，選擇NSX以及要比對的產品，就可以確認之間的相容性，如下圖

大家應該要檢查的VMware產品項目包括：

• vCenter & vSphere ESXi

• vRealize Operations Manager

• vRealize Automation

• vRealize Log Insight

如果上述的VMware產品企業有使用，且未支援升級後NSX的版本，請先將這些產品升級到新版，再做NSX的升級。另外NSX也可能與其他3rd-party協力廠商的產品進行整合，包括：

• 其他廠商的雲平台或Workflow產品

• 安全產品

• 網路方案整合

• 管理與維運產品

上述的第三方產品請各位與對應原廠或經銷商進行詢問，是否採用的產品能對應到升級後的NSX，或是這些原廠產品升級到某個版本後即可對應。

架構設計上，請盡量確保有獨立的Management Cluster放置NSX Manager / Controller

事實上，不僅僅是NSX，所有vSphere的Design Guide都會告訴大家一句話：請有獨立的Management Cluster來放管理構件，包括vCenter，包括Operations Manager，當然也包括了NSX Manager / Controller等。

原因很簡單：升級作業時，我們希望單一步驟不要同時影響到上層的管理構件與底層的虛擬層構件，造成你卡我我卡你的情形，然後升級或維護作業就卡死在那邊。NSX在升級作業時會需要更新vSphere Kernel內的NSX Vib，也會要求vSphere Host進入維護模式 / 重開機。如果大家的vCenter / NSX Manager / Controller等等這些在這些要重開機的Host上，必須飄過去飄過來，又因為什麼因素飄不走，整個升級流程就卡死了。

而有獨立的Management Cluster時，我們不會把NSX Vib安裝到這，而僅會安裝在Compute Cluster上。無論我們進行哪些NSX底層驅動程式的升級作業，都不會影響到在Management Cluster上的管理構件，出問題的狀況大幅減少，而且更重要的是，我們不會因為升級失敗，就影響到管理構件的連接性，要救援也救得起來。

在Compute Cluster啟用DRS自動轉移機制，而且確保vMotion作業能夠正常運作

升級NSX Manager與NSX Controller通常是按手冊一步步施工，很少失敗的狀況。但第三步驟要升級vSphere Host內的NSX Vib時，實際的狀況是

• 管理者於選定的Compute Cluster要求進行升級

• NSX Manager將更新的NSX Vib送入此Cluster內的各台vSphere Host

• 陸續地，此Cluster內的vSphere Host依序進入Maintenance Mode，然後重開機。要進入Maintenance Mode且重開機時，需要將此Host上面的Business VM轉移到Cluster內的其他Host，或是將VM關機

• 此vSphere Host重開後NSX Vib即更新完成，NSX Manager會啟動下一台vSphere Host的重開機動作。當Cluster內所有的vSphere Host都重開機完，就完成升級作業。

上面步驟大家可以看到的重點是，升級過程中NSX Manager會透過vCenter，要求Compute Cluster內的vSphere Host要一台一台進入維護模式並且重開機。因此很明顯的，如果我們不希望影響現有的Business VM，也希望不要管理者手動介入、可以自動完成部署作業，此時的重點必定是：

• Cluster要啟用DRS，當一個Host被要求進入維護模式時，vSphere會自動將上面的VM移轉到其他機器

• 移轉(vMotion)必須成功

如果沒有啟用DRS，那管理者在升級過程中會看到的訊息是要求手動將一台台的Host重開。當然可以這樣做，但就得手動介入比較繁雜，Business VM也較難確保不會有中斷或關機的情形。

同樣的，要讓上面的動作能順利進行，任何會影響VM自動飄移的情境都要想辦法排除，比如說下面的：

確保Compute Cluster於開關機時具備足夠的運算資源

什麼狀況下，NSX Manager將一個DRS啟動且可以正常vMotion的cluster內機器陸續重新開機時會失敗？我們舉幾個常見的例子：

• Business VM有設Reservation等等機制，確保必須保留的運算資源，但當所在的Host要關機，必須飄移到其他剩下的vSphere Host時，剩下的vSphere Host資源並不具備足夠的CPU / Memory / IO Resource…

• Business VM或是像是Edge Service Gateway的Active與Standby機器有設Anti-Affinity Rule，但比如說Compute Cluster只有兩台Host，一台Host關機時，上面的VM因為Anti-Affinity Rule沒法飄到另一台去

在上面的討論其實我們僅圍繞在一個重點上：一個穩定、能夠長期運作、順利升級的NSX環境，前期是需要良好規劃的。如同大家建立一個良好運作的vSphere環境，我們也建議企業在導入NSX，能尋找專業且配合良好的經銷商夥伴，在專案前期以及維運階段都能和大家有緊密且專業的合作。