VMware NSX V轉T已勢在必行，移轉的方式包括In Place（原地移轉）和Lift and Shift（先建後拆）兩種機制，本文將專注在先建後拆，所使用的NSX V2T Migration Coordinator有不同的移轉選項，本文將實際操作台灣大部分NSX客戶都會使用到的移轉情境「先建後拆，只轉防火牆配置」。
承前篇（網管人第187期：NSX「棄V從T」勢在必行 做好規劃方能平順移轉）討論內容，本篇的重點是要以實際的畫面與大家說明NSX V2T Migration Coordinator內，採用先建後拆（Lift and Shift）的防火牆移轉（DFW_Only）機制。為什麼特別挑這個出來當重點，當然是因為在台灣幾乎全部的NSX客戶都有採用微分段防火牆機制保護核心業務，但網路這邊如Overlay功能反而不一定都會使用到。在V版逐漸步入產品後期，如何協助這些客戶平順地移轉到T版環境，並持續得到相關的安全及網路效益，是後續的工作重點。
移轉前的準備說明
展示的情境請參考圖1，左邊是運作NSX for vSphere的原始生產環境，右邊是新建的NSX-T環境。
圖1 運作NSX for vSphere的原始生產環境與新建的NSX-T環境。
因為是Lift and Shift架構，因此在目的環境內（右邊），客戶要先採購額外的硬體伺服器，然後將vCenter、vSphere、NSX-T安裝完成。
同時，此環境中，在NSX-T內以VLAN形式建立了對應的業務網路（目的地的B-VLAN23-Seg），與來源端的A-PG-vlan23是二層打通的。DFW_Only架構可以支援目的端採用Overlay網路，再以L2-Bridge機制與原本來源端的VLAN網段連通，但這裡採用最簡單的實體VLAN網路機制。
此外，業務機器在原本環境均運作在上述的vlan23實體網路內。如同前項說明，因為此環境內的網路僅採用VLAN，當後續要將業務機器遷移到目的地的vlan23網段（B-VLAN23-Seg），由於是在同樣的二層網路內，IP/Gateway都不用改，管理者可以考慮採用vMotion或是HCX來進行移轉。
在原始環境中，透過NSX for vSphere的DFW進行業務虛機的保護。圖2是在相關安全構件的配置。
圖2 相關安全構件的配置。
環境內配置了一個Security Tag叫v2t-web-tag，並且應用到web-01、web-02這兩個虛機上。同時建立兩個群組：Web-Group這個群組的條件是任何有v2t-web-tag的虛機就要包含在此群組內，因此web-01、web-02兩個機器當然有被包含在內。另外，為了定義「Internet Traffic」，所以定義了一個IPSET集合叫做Non-Internet IPSET，裡面包含了被保留的Intranet/Multicast IP等地址（這裡包含的私有地址範圍很不完整，但只是為舉例方便說明）。
因此，在分散式防火牆規則中，就可以利用群組以及IPSET來定義對應到這些虛機的保護規則：所有SSH的Traffic，包含L4/L7的比對，都要允許。Web-Group內虛機間的相互連線要拒絕，但往Internet的連線可允許，而所有其他的Traffic都要拒絕。
以下幾張圖例是在原始環境NSX for vSphere介面內，對應到上述Security Tag、Security Group、IPSET、DFW Rule的配置。首先是Security Tag，如圖3所示。
圖3 Security Tag設定範例。
Security Group v2t-web-group內的規則是只要有上述v2t-web-02標籤的虛機，就要加入此群組。因此兩個業務虛機都有被包含在內，如圖4所示。
圖4 Security Group v2t-web-group內的規則設定。
另外，建了一個IPSET集合是包含了Intranet/Multicast Addresses，如圖5所示。
圖5 IPSET集合包含Intranet/Multicast Addresses。
然後是分散式防火牆的規則。圖6內比較特殊的是1008號的規則，這裡要定義的是這些受保護的虛機可以到「Internet」，但因為無法建一個集合叫Internet，因此這裡用了否定「Negate」語法，如果是要到任何「沒有」被定義在Non-Internet-IPSET集合的地址，就是要往Internet。
圖6 檢視1008號規則。
以上的防火牆相關規則雖然極為簡單，但這個範例內應該已經包含到許多NSX客戶常用的微分段機制：
‧基於標籤以及群組來動態定義業務構件。
‧基於業務構件來定義防火牆的來源與目的端規則。
‧支援基於IP/IPSET的標準定義。
‧支援基於L4的Protocol/Port服務定義，以及L7的應用識別定義。
‧虛機是運作在VLAN實體網路上。無論虛機在NSX內運作於VLAN網路或是Overlay網路，防火牆都應生效。 接下來，就DFW_Only的V2T移轉流程進行說明。在最前面的架構圖（圖1）中，大家可以看到其中畫了五個步驟，以下將依據這個步驟逐步進行說明。
步驟0：先建新環境
由於這是Lift and Shift先建後拆的架構，因此首先必須建立一個新的vCenter/vSphere資源池，並建立NSX-T Manager及完成vSphere內的Preparation。請注意，V2T Migration Coordinator僅支援全新安裝的NSX-T環境，移轉到一個已經在使用、上面有很多現有配置的環境是不支援的。
另外，NSX-T需要先將來源端這裡的vCenter加入Compute Manager內，這樣在後續Migration Coordinator的步驟中才能抓到來源端的相關資訊。
步驟1：啟用V2T Migration Coordinator
在NSX-T全新安裝完成時，Migration Coordinator服務並沒有啟用，此時管理者在UI介面內也無法執行此功能。因此第一個步驟是管理者需要以SSH登入NSX Manager並啟用服務，如圖7所示。
圖7 以SSH登入NSX Manager並啟用服務。
執行上述指令後，回到NSX-T UI內，在System - Migrate內就可以看到不同的Migration選項了。這裡要執行的是ADVANCED MIGRATION MODES內的Distributed Firewall選項，按一下〔GET STARTED〕按鈕就可以啟動，如圖8所示。
圖8 開啟ADVANCED MIGRATION MODES內的Distributed Firewall功能。
步驟2：移轉前相容性檢查
進入Distributed Firewall的移轉介面後，首先第一個步驟是要讓Migration Coordinator接上來源端的vCenter與NSX for vSphere。此處非常直覺，如圖9所示。
圖9 讓Migration Coordinator接上來源端的vCenter與NSX for vSphere。
上述認證若沒問題，介面上就會顯示來源端VC/NSX for vSphere的相關資訊，並且可以開始將相關的配置進行輸入，如圖10所示。
圖10 顯示來源端VC/NSX for vSphere相關資訊。
接著按下〔CONTINUE〕，Migration Coordinator就會檢查並列出在NSX for vSphere與NSX-T間的差異點，甚至可能需要管理者輸入一些相關在T版環境內的配置值（圖11）。在此步驟內，應該要一條條檢視各項需要注意點，接受或是進行對應需求的修改，如圖12所示。
圖11 列出在NSX for vSphere與NSX-T間的差異點。
圖12 逐一檢視各項需要注意點，接受或是進行對應需求的修改。
步驟3：防火牆配置相關移轉
在前步驟中，當管理者檢視並接受各項差異點後，按下〔CONTINUE〕按鈕來啟動下一步實際的移轉動作。此時，V版的相關配置會真正放到T版環境內，介面內會列出移轉是否成功，以及相關的數據，如圖13所示。此步驟內，想特別提出的是，這裡的過程都有ROLLBACK機制，如果已經執行，都還可以把NSX-T內的配置移除，回復到原有、沒有移轉前的環境。
圖13 檢視是否成功移轉。
步驟4：手動以vMotion或HCX移轉虛機
上面步驟3的操作結束並且按下〔CONTINUE〕按鈕之後，將會跳出說明，要求管理者必須手動進行虛機移轉的作業，如圖14所示。
圖14 要求管理者手動進行虛機移轉。
如圖15所示，在這裡要採用哪種移轉方式、移轉的順序與時間，都由管理者自行決定，例如：
圖15 自行決定採用哪種移轉方式以及移轉的順序與時間。
‧如果在來源與目的端的vCenter使用相同的SSO，就可以在VC介面上直接進行Cross-vCenter vMotion。
‧如果來源與目的端的vCenter是不同的SSO，仍然可以採用vSphere的API進行移轉。
‧如果客戶有HCX授權，以HCX的各種機制，如vMotion、Bulk Migration、Replicated-Assisted-vMotion，當然是更建議的方法。
步驟5：Tag配對、檢查並結束移轉
最後還需要一個動作，目前（3.1.2）還僅能用API的方法執行。當完成將所有虛機由來源端轉移到目的端後，還必須要告訴NSX-T Manager手動移轉已經完成。接著，Manager會把在V版那邊於步驟3拿到的Tag、Group等等資訊，套用到這些移轉完成的虛機上。
圖16所示是用POSTMAN來執行這個finalize_infra動作的API。需要採用POST的HTTP Method，而API是「https://{NSX-Manager}/api/v1/migration?action=finalize_infra」。當然這邊也需要輸入相對的username與password以登入NSX。
圖16 使用POSTMAN來執行finalize_infra動作的API。
當上面的動作執行完畢，看到回應值為200之後，整個DFW_Only的移轉機制就完成了。下面把移轉完後，在T版內的Tag、Group、DFW Rule展示給大家看，請與前篇在V版內的配置放在一起比較。
首先是Tag，在V版內定義的v2t-web-tag正確地出現於T版介面內，並且指定到web-01和web-02兩個虛機上，如圖17所示。其次，V版那邊的群組Web-Group以及IPSET集合也已正確移入T版環境內。而圖18～19 所示，為Web-Group的成員與動態條件配置。接著是Non-Internet-IPSET這個集合，在T版內變成一個配置靜態IP的群組，如圖20所示。最後，如圖21所示，防火牆規則也正確移轉了。
圖17 v2t-web-tag出現於T版介面內，並指定到web-01和web-02虛機上。
圖18 Web-Group的成員配置。
圖19 Web-Group的動態條件配置。
圖20 原Non-Internet-IPSET集合變成一個配置靜態IP群組。
圖21 正確移轉防火牆規則。
結語
希望藉由本文的討論，讓大家可以親眼看到V2T Migration Coordinator工具如何進行DFW_only的配置移轉，包含防火牆規則、群組、標籤等的移轉均能順利達成。下一篇是本系列主題的最後一篇，將針對其他V2T移轉模式，尤其是NSX for vSphere Everything「全部轉移」的機制進行說明，並且針對與客戶討論時常被詢問的相關問題進行回應。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞