在NSX V2T Migration Coordinator內採用「先建後拆、僅移轉防火牆配置」的移轉流程是眾多用戶適合採用的方式，但其實Migration Coordinator還提供了其他不同的移轉流程，本文將針對這一部分做說明，並特別針對一些常見的問題進行解答。
在前篇系列文章就NSX V2T Migration Coordinator內採用「先建後拆、僅移轉防火牆配置」的移轉流程進行了較詳細的說明，這種方式會有眾多用戶適合採用，但Migration Coordinator也提供了其他不同的移轉流程。
當管理者在NSX-T Manager的命令列輸入「start service migration-coordinator」指令後，在UI介面就會看到包含「STANDARD MIGRATION MODES」和「ADVANCED MIGRATION MODES」在內共有六種不同可選的移轉方式。除了前篇討論的Distributed Firewall流程之外，大家可以看到還有其他的選項，如圖1～2所示。
圖1 六種不同的移轉方式之一。
圖2 六種不同的移轉方式之二。
在「STANDARD MIGRATION MODES」內，有以下三種機制：
‧ NSX for vSphere是採用原地移轉（In Place），移轉所有配置的方法。如同前面介紹，這是在相同的硬體資源池內，直接將NSX-V版改為T版，並且會移轉包含網路以及安全的所有支援配置。
‧ vSphere Networking與V2T無關，這邊是將純vSphere環境中的Virtual Distributed Switch內的配置以及對應網卡，轉到NSX-T的Segment之中。
‧ NSX for vSphere with vRealize Automation：顧名思義，這是搭配vRealize Automation 8.4之後的V2T移轉機制，屬於In-Place，全功能移轉。
「ADVANCED MIGRATION MODES」內，則有另外三種機制：
‧ Edge Cutover是專門搭配vCloud Foundation使用，作為VCF後續由3.X的V版環境移轉至4.X後的T版環境使用。
‧ Distributed Firewall是Lift and Shift，僅移轉安全相關配置，就是前篇文章內所介紹的。此架構內，雖然僅移轉安全相關構件，但網路配置仍可以採用手動方式進行。
‧ Distributed Firewall, Host and Workload是In Place架構，僅移轉安全相關配置。此架構內的網路配置可以採用手動方式進行。
以下就上面的第一種NSX for vSphere - 原地重建（後面會用「全部轉移」來稱呼）的流程多談一點。這其實是V2T Migration Coordinator內最早開發的流程，在此機制中會：
‧移轉所有的NSX配置，包含網路以及安全部分。
‧原地移轉（In Place），客戶無須採購新的vSphere伺服器，移轉流程會將vSphere內的NSX-V構件重新安裝為NSX-T的構件。
聽起來很理想，適合所有企業移轉時使用吧！但在使用「全部轉移」方案時需要非常非常嚴謹的規劃。在原地移轉機制這邊要考量的風險，在系列文第一篇有仔細討論過。此處要討論另一件事：採用全部轉移這種機制時，安全不用談，所有網路配置包含V版內的Edge、DLR、Logical Switch、NAT、VPN等等都會轉。但也因為什麼都轉，此時就會碰到以下幾個問題：
碰到移轉工具目前未支援的功能，造成無法移轉的可能性變大
舉個例子，L2 Bridge是在Overlay網路內常用的功能，做現有實體網路與Overlay網路的介接。但如果環境內有L2 Bridge，在流程中檢查就會停住告知有問題。另一個例子是，在本文寫作的同時（NSX-T 3.1.2版），OSPF協議也還沒有在Migration Coordinator的支援範圍內。
進行此方式時，極為重要的是務必要事前確認各項功能在V2T Migration Coordinator內是否有支援，沒有支援的話，必須預先排除。NSX-T Migration Guide裡面有超過30頁專門在講哪些Feature於工具內有支援，哪些沒有。這些沒有的Feature，都可能會是擋住移轉精靈順暢運作的阻礙，請務必詳細檢視。
全部轉移流程僅支援特定網路拓樸
採用此流程時，原本的V版環境必須只能是四種拓樸的一種，如圖3～6所示，截圖自NSX-T Migration Guide。
圖3 拓樸1：移轉前及移轉後。
圖4 拓樸2：移轉前及移轉後。
圖5 拓樸3：移轉前及移轉後。
圖6 拓樸4：移轉前及移轉後。
簡而言之，V版內環境的路由機制只能用BGP或是靜態路由；V版的現有網路架構內，客戶必須採用Edge、DLR、Logical Switch，而且長相必須是上面的架構之一；其他的服務如Load Balancer、VPN、NAT等等，在上面各種拓樸內，各有特定支援的做法，必須要符合要求。
這也是要跟大家強調，事前規劃與測試極為重要的主要原因。各位現有的V版環境可能採用了不同的功能與架構，想要採用「全部轉移」流程時，就需要做現有架構的修改以符合支援拓樸。舉個例子，V版環境內雖然有使用Edge，但沒有採用Overlay網路，架構不符合，在「全部轉移」流程內就不支援了。
全部轉移流程完成後的拓樸，未必是最理想化的
舉兩個例子，首先在上面的四個拓樸內，可以看到其實大部分的移轉，在NSX-T這裡只會建立T0-Gateway，沒有T1-Gateway。這與在NSX-T網路設計中，通常將實體網路介接構件（T0-Gateway）以及租戶應用邏輯控制構件（T1-Gateway）分開的架構很不一樣。
其次，比如說目前在負載平衡方案上，會推薦大家使用最先進的NSX Advanced Load Balancer（Avi Networks），但移轉工具只會轉到NSX-T原生的Load Balancer。
這裡想要說什麼呢？如果經過縝密的規劃，採用「全部轉移」這個流程可以符合企業需求，當然歡迎大家使用，但可能碰到哪些風險與阻礙是必須先說清楚的。如果各位考慮採用此流程，務必先到VMware Hands-on-Lab內2103-02-NET這個Lab體驗一下，如圖7所示。這是免費，所有人都可以使用的環境，大約2～3個小時就可以把「全部轉移」流程從頭到尾的步驟、需求配置整個走一遍。
圖7 VMware Hands-on-Lab內的2103-02-NET Lab。
那進一步討論一個問題！前面討論了純移轉防火牆的機制以及全部移轉的機制，如果企業的需求，在這兩種條件都不太符合，還有哪些選擇呢？
‧如果是想要原地改建，但移轉重點在安全配置，網路端配置允許管理員手動自己做。此時可以選擇「Distributed Firewall, Host and Workload」流程，不像「Distributed Firewall」流程採用先建後拆，此流程是原地改建，無須額外購買伺服器硬體。
‧如果NSX for vSphere內的網路建置是由vRA或是vCD呼叫，並不是管理者自行建立的，建議採用對應這些工具的移轉流程。前面的NSX for vSphere with vRealize Automation是可以對應vRA 8.4後的移轉，而vCloud Director有一個叫NSX-T Migration Tool的命令列工具，直接進行vCD環境下的V2T移轉。
常見問題釋疑
相關V2T移轉工具的技術問題就說明到此。本文剩下的篇幅，就NSX V2T Migration Coordinator這個工具以及相關的移轉常見問題，以Q&A的形式與大家進行討論：
什麼時候應該要開始V2T移轉呢？現在已經是時間點了嗎？
是的，現在就已經是時間點了。如前面與大家說明，NSX for vSphere的End of General Support時間會於2022年初結束，而End of Technical Guidance時間則是2023年年初。考量到這個作業運作在生產環境，需要前期的規劃、教育訓練與測試，很多企業會預先抓半年到9個月的Lead Time，建議各位務必要開始V2T的相關移轉規劃準備。
如果不進行V2T移轉，現有NSX for vSphere環境繼續用，會有什麼問題？
在前面可以看到，NSX for vSphere於2022年1月16號End of General Support之後，除非出現特殊狀況，不然不會有新功能以及Bug/Patch修補。而在2023年1月16號End of Technical Guidance後，VMware Global Support Service對於此方案的支援也會停止。
此外，大家看到VMware在NSX Data Center這邊開發的新功能包含容器支援、IDPS、Federation……族繁不及備載，都是在T版提供。一直停留在V版環境，就無法使用這些新功能了。
V2T移轉會不會影響到現有生產業務的可靠性？
在縝密的規劃下，對於生產業務的影響應該能降到最小。如果採用的是先建後拆的方式，管理者可以自行選擇如何進行業務機器在哪個時間進行於新舊資源池間的遷移，而利用vMotion或HCX等機制，也能優化機器移轉時的可靠性影響。
而如果採用的是原地改建，除了在過程中整個南北向由V版Edge要轉移至T版Gateway時會有一陣子的斷線，vSphere上會搭配DRS/Maintenance機制來進行虛機的遷移，也會自動進行虛機在不同版本網路之間的切換。
因此重點是，真正進行V2T作業前，預先的規劃與準備是否足夠呢？如果是，移轉過程中的業務影響應該是在可控制的範圍內。
V2T移轉一定要採用Migration Coordinator嗎？有沒有其他的方式？
V2T Migration Coordinator是官方支援的工具。美國有些服務廠商有提供客製化的工具，但在台灣應沒有提供服務。
進行V2T移轉採用Migration Coordinator是較為自動化、推薦的方式，但當然客戶可以選擇包含新建環境並手動移轉，或是透過API抓取配置以客製化移轉的方式進行。另外如前所述，在vRA/vCD內有特定搭配上層自動化平台的移轉流程；而如果有採用3.X版的vCloud Foundation，後續也會有VCF自己的底層網路移轉機制。
V2T Migration Coordinator是否需要額外的授權？
不需要，在NSX-T每個版本內都包含V2T Migration Coordinator，客戶僅需要在現有授權內建立NSX-T環境，再啟用功能即可。
採用V2T Migration Coordinator是否有對應的NSX版本需求？
有的。請務必確認下列的部署版本要求：
‧NSX for vSphere至少在6.4.4版以上。如果版本低於要求，需要先進行NSX for vSphere本身的升級後，才能進行移轉工作。
‧NSX-T Data Center從2.4版開始支援Migration Coordinator的第一版，但建議採用最新或最低3.1.1之後的版本。Migration Coordinator於3.1.1版後有大幅添增功能，例如前面討論、僅進行防火牆移轉這樣的選擇，是在新版環境中才支援。
‧如果採用的是原地改建，務必確認現有環境的vCenter/vSphere有對應NSX-T支援的版本。V2T Migration Coordinator本身不會進行vCenter/vSphere這邊的升級
對應V2T Migration的資訊及規劃，有哪些資源與協助呢？
首先，應該先找之前協助進行NSX for vSphere建置的經銷夥伴做諮詢。同時，VMware Profession Service針對V2T Migration Service也有專屬的服務。
此外，下面是公開、大家都能直接取得的V2T移轉相關資訊鏈結，可供參考：
‧作業文件 - NSX-T Migration Coordinator Guide：https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-7899A104-2662-4FC9-87B2-F4688FAEBBBA.html
‧VMware Techzone - 官方V2T相關網誌及公開影片收集：https://nsx.techzone.vmware.com/understand-automated-migration-nsx-t
‧白皮書：https://www.vmware.com/content/dam/learn/en/amer/fy21/pdf/740054_VMW_NSX_T_Migration.pdf
‧部落格：https://blogs.vmware.com/networkvirtualization/?s=NSX-T+Migration ‧VMware Hands on Lab：請至「https://labs.hol.vmware.com/HOL/」網站，註冊後搜尋 HOL-2103-02-NET，可以自行演練V2T的「全部轉移」流程。
相關的介紹就到這裡，希望能夠對大家在NSX V到T版的移轉有所幫助。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞