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

在前面兩篇我就NSX V2T Migration Coordinator內，採用『先建後拆、僅移轉防火牆配置』的這種移轉流程進行了較詳細的說明。這種方式會有眾多用戶適合採用，但Migration Coordinator也有提供其他不同的移轉流程。

當管理者在NSX-T Manager內命令列輸入要start service migration-coordinator指令後，於UI介面就會看到包含”STANDARD MIGRATION MODES”以及”ADVANCED MIGRATION MODES”內，共有六種不同可選的移轉方式。除了前篇討論的Distributed Firewall流程，大家可以看到還有其他的選項：

“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.3/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網路的介接。但如果環境內有L2 Bridge，在流程中檢查就會停住告知有問題。另一個例子：在本文寫作的同時 (NSX-T 3.1.1版)，OSPF協議也沒有在Migration Coordinator的支援範圍內。

進行此方式時，極為重要的是務必要事前確認各項功能在V2T Migration Coordinator內是否有支援，沒有支援的話必須預先排除。NSX-T Migration Guide裡面有超過 30 頁，專門在講哪些 feature 於工具內有支援，哪些沒有。這些沒有的feature，都可能會是擋住移轉精靈順暢運作的阻礙，請務必詳細檢視。

全部轉移流程僅支援特定網路拓墣

採用此流程時，原本的V版環境必須只能是下面四種拓墣的一種，下面截圖自NSX-T Migration Guide：

簡而言之，

  • 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)，但移轉工具只會轉到原生的Load Balancer。

這裡想要說什麼呢？如果經過縝密的規劃，採用『全部轉移』這個流程可以符合企業需求，當然歡迎大家使用，但可能碰到哪些風險與阻礙是我們需要先說清楚的。如果各位考慮採用此流程，請務必先到VMware Hands-on-Lab內的2103-02-NET這個Lab體驗一下。這是免費，所有人都可以使用的環境，大約2~3個小時就可以把『全部轉移』流程從頭到尾的步驟、需求配置整個走一遍：

那進一步討論一個問題。前面討論了純移轉防火牆的機制以及全部移轉的機制。如果企業的需求，在這兩種條件都不太符合，還有哪些選擇呢？

  • 如果是想要原地改建，但移轉重點在安全配置，網路端配置允許管理員手動自己做。此時各位可以選擇”Distributed Firewall, Host and Workload”這個流程，不像”Distributed Firewall”流程採用先建後拆，此流程是原地改建，無需額外購買伺服器硬體的。
  • 如果NSX for vSphere內的網路建置是由vRA或是vCD呼叫，並不是管理者自行建立的，建議採用對應這些工具的移轉流程。前面的NSX for vSphere with vRealize Automation是可以對應vRA 8.3 / 8.4的移轉，而vCloud Director有一個叫NSX-T Migration Tool的命令列工具，直接進行vCD環境下的V2T移轉。

就說明到此。接下來是本系列文的最後一篇，我們會就V2T工具這邊經銷夥伴與客戶常詢問的問題進行討論。