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

前面一篇我們先討論了若企業已經採用了NSX for vSphere，需要開始規劃進行由V版到T版的移轉。通常在這裡大家就會問了，那VMware是不是有出V到T的『移轉工具』，管理者只要在移轉工具內按一按，然後現在V的環境就是自動變成NSX-T了呢？

有的，NSX-T內有移轉工具，叫做NSX V2T Migration Coordinator，使用上是採用圖形介面精靈的方式，步驟上也不複雜。我們在後面的篇幅，當然也會和大家就Migration Coordinator進行相關的討論。但是，但是，ＢＵＴ（很重要所以說三次），採用這個工具前，需要完整的前置作業與規劃討論，並選擇合適的步驟。只有在經過了完善的規劃與測試後，客戶才能期待有一個平順，而且不影響生產環境的轉置作業。

上圖內是我們通常在進行V2T移轉的五個準備動作。這裡我們分別進行說明：

現行環境確認：

客戶目前有在使用NSX for vSphere，那麼，生產環境內有使用到哪些NSX功能？只使用微分段，或是有採用邏輯網路？有整合第三方方案？有採用VPN？在這些功能內的運作機制與配置又是怎麼做呢？比如說如果客戶採用微分段，來源與目的是採用IP地址，採用群組，還是規則內有用像是vSphere Cluster作為來源與目的地？與實體間網路的介接是用靜態路由還是OSPF還是BGP做動態路由交換？

上面的問題聽起來很繁瑣很無聊，但在移轉前了解環境內用了什麼NSX for vSphere的功能是極為重要的，因為下一個步驟：這些生產環境內有用的功能，在NSX-T內可支援嗎？移轉工具能支持嗎？

NSX-T功能測試：

雖然我們和大家說NSX-T已經cover了NSX for vSphere的絕大部分功能，但這是兩個獨立的產品，在同樣功能的支援方法上也會有差異。因此在前面的步驟內確認了生產環境需要使用的NSX功能，這邊的步驟就要了解這些功能在T版是否有支援。而如果沒有支援，是否有哪些workaround讓業務需求可以滿足？

舉個例子，NSX-T內當然有支援微分段，有支援群組、標籤，但在T版內，vCenter Inventory像是Cluster / Resource Pool等等這些，是不能拿來做防火牆來源與目的地的。另外，像是身份識別防火牆 (identity firewall)，V版內有支援對應AD的Security Log Scraping，但在NSX-T 3.1版內是採用VMtools的登入登出紀錄，那這樣的機制能否滿足企業要求？

此外，某些功能是NSX-T內有支援，但是Migration Coordinator工具還未支持的。比如說如果客戶是採用OSPF作為動態路由協定，在NSX-T 3.1.1後開始有支持OSPF，可是Migrator Coordinator內還沒有辦法支持。那如果企業要進行轉移，這邊就需要討論，移轉的環境是要改成BGP協議，或是這部分要手動來移轉嗎？

因此在此階段，需要確認現行的功能在NSX-T的支援程度，也可能要在測試環境內先行進行移轉工具測試，確認是否有某些移轉條件無法滿足。

客戶教育訓練與Workshop：

客戶已經很熟悉V版的操作，但未必了解T版的架構、安裝需求及介面。因此在實際移轉前，可能透過教育訓練、Workshop等不同的方式，讓管理者了解完整的產品與功能，以及後續實際部署時的架構設計考量。

生產共存：

甚至不僅是PoC，大型客戶通常會希望導入staging環境進行NSX-T的初期生產部署，並且放幾個真正的應用在這個環境內試車。過程內，也會進一步了解在V與T版間的功能與維運差異，客戶也可進行內部的維運機制 / 對應文件的修正。

實際移轉：

在真正大型移轉前，客戶應該要確認：
* 採用哪種移轉的方式，以及移轉前的環境軟硬體準備已經完成
* 業務移轉的步驟，哪些資源池 / 業務先進行，確實的步驟與流程為何
* 對業務可靠性的影響，是否會停機，若有停機要在什麼時間進行以及內部預告
* 對應技術人員的資源安排與作業時程

計畫完成後，才繼續按部就班進行需求的移轉作業。

我不知道前面五個步驟這樣談大家是否有感覺，下圖是一個VMware大型客戶實際的例子：

此客戶因為Scale以及NSX-V功能限制等問題，從2020年3月開始規劃要進行V轉T的作業。在前期的規劃以及測試大概花了整整半年的時間，2020年10月開始以NSX Migration Coordinator進行第一次的非生產環境虛機移轉。在10~11月兩次移轉沒問題後，12月開始正式進行生產環境虛機移轉。到2021年2月時，在近5個月的時間內，移轉了七千多個虛機改為NSX-T 3.0.2環境運作。

大家可以看到，整個時程內前期準備花了半年，後續的移轉進行與業務觀察也花了約半年。即使有工具，整個V2T Migration仍是一個需要謹慎規劃，小心執行的作業。通常我們會建議企業進行此工作時，需要與VMware PSO或是熟悉NSX的服務夥伴一同合作，進行完整的測試與規劃。而且足夠的lead time是很重要的，以避免在沒有足夠測試下，在移轉時出現各種未預期的狀況，甚至影響到生產環境的運作。

接下來要進入一些技術面的部分，在V2T Migration內有不同的架構與移轉方式，有哪幾種，彼此之間又有什麼差異呢？待下篇與各位進行介紹。