NSX for vSphere就是常聽到的V版或是NSX-V，NSX-T Data Center則稱為T版或是NSX-T。NSX-T Data Center是後續持續支援開發的版本，因此新功能都只會做在T版上。而V版與T版是兩個獨立開發、Code不相通的方案，因此V版與T版間不能做升級，只能夠進行移轉。
講一下古，如果沒記錯的話，NSX for vSphere的第一個正式版本是在2013年中推出的。VMware在2012年底買入當時軟體定義網路的最領先廠商Nicira，而在2013年以NSX for vSphere產品取代Nicira的NVP（Network Virtualization Platform）平台。
當時第一個版本是6.0版（切齊當時vCenter、vSphere的版本），到現在也有8年時間了。
NSX for vSphere是特別針對vSphere上虛機提供網路及安全需求的軟體定義方案，裡面的核心構件包括了：
‧由Nicira繼承而來的網路虛擬化（Overlay Network）、分散式路由以及軟體定義網路機制。
‧VMware原生的vCNS（vCloud Network and Security）產品，提供了基於虛機的網路服務，包含南北向防火牆、NAT、VPN、負載平衡器等機制。
‧在Kernel內運作，保護每個虛機的東西向分散式防火牆機制，並搭配安全群組、標籤做到安全自動化，也就是大家熟知的微分段技術。
‧繼承自vShield Endpoint，並強化做到包含在系統與網路面以及第三方方案整合的Guest/Network Introspection技術。
筆者很榮幸地在NSX for vSphere推出的早期就能接觸此產品，並且與不同的客戶和經銷夥伴進行方案介紹。NSX for vSphere是VMware重要的Hero Product，有相當強勁的銷售數字，與眾多的企業採用此方案在vSphere資源池內提供虛機安全及網路隨需服務。
但在2015年前後，VMware網路部門啟動了新計畫要開發全新版本的NSX。NSX for vSphere雖然功能完整且運作穩定，但在架構上有下列幾個問題：
‧功能僅侷限於vSphere上的虛機機制。雖然vSphere是全世界企業IT採用的主要平台，但不可諱言，因應到IT潮流的變遷，需要一個應用在更廣泛環境的軟體定義網路架構，包含了要對應不同的虛擬化平台、對應虛機以及容器環境、自建私有雲以及公有雲環境、甚至可以支援到實體伺服器。
‧由於各功能繼承自不同的方案及產品，在新功能開發及架構優化上有限制。
‧API需要現代化，並且對應到新的自動化∕組態管理工具、IaaS（Infrastructure as Service）工具整合，以及私有雲管理架構。
NSX for vSphere倒數NSX-T Data Center接棒
基於以上的原因，新產品由基礎開始大幅度重新開發，2017年釋出第一個生產版本NSX-T 2.0，並在2018年的VMworld正式對大眾進行宣傳，這也就是現在所看到的NSX-T Data Center，寫作此時已經是3.1.2版。
因此，同樣是講NSX，但客戶會看到有兩個不同的發行版本，一個是僅能在vSphere上使用的NSX for vSphere，另一個是可以支援虛機、K8s、公有雲與實體機環境的NSX-T Data Center。這兩個方案的關係是：
‧NSX for vSphere就是大家常聽到的V版或是NSX-V，NSX-T Data Center則是稱為T版或是NSX-T。
‧兩個方案提供企業相同的網路及安全功能與效益，僅是可應用的範圍不同。
‧當客戶購買NSX Data Center的授權時，可以選擇安裝NSX for vSphere版，也可以安裝NSX-T Data Center版，只要總數量不要超過授權範圍即可。
‧V版與T版是兩個獨立開發、Code不相通的方案，因此V版與T版間只能夠進行移轉（Migration），而不能進行升級（Upgrade）。
‧NSX-T Data Center是VMware後續會持續支援開發的版本，因此新的功能如IDPS/Federation都只會做在T版上。
當然，若企業考慮要採用的是穩定且安裝簡易的版本，之前仍然可能會採用V版。但隨著T版的功能越來越完善穩定已幾乎可以完全取代原本V版具備的功能，全球部署用戶數目逐漸增多，加上能夠對應企業後續在容器與其他環境的方案需求，大約在2019年中開始，在台灣的NSX Data Center新部署環境已經大多採用NSX-T。
所以，NSX for vSphere逐漸功成身退，將要進入產品週期的尾聲。若在VMware Product Lifecycle網站或文件內進行查詢，可以看到：
‧NSX for vSphere 6.4版會是最後一個大版本（寫作當時最新版為6.4.10），後面不會有6.5版了。
‧NSX for vSphere的End of General Support時間是2022年1月16日。在這個日期之後，將不會有新的產品更新與修補。
‧NSX for vSphere的End of Technical Guidance時間是2023年1月16日。在這個日期之後，客戶除非額外購買特殊支援，不再能取得此產品的VMware技術支援。
NSX for vSphere是一個安裝客戶廣泛與眾多的方案，因此要讓企業能夠平順地進行從現有V版到新的NSX-T Data Center環境移轉，必須要有詳細的規劃、測試以及對應的機制與程序。
在本系列三篇投稿內，針對V版轉T版的移轉作業，後面都會統稱為「V2T Migration」，需要進行的考量以及相關採用的工具，與大家進行說明。同時也會針對目前最被客戶和經銷夥伴關心的微分段防火牆移轉機制如何進行，進行細部的討論。
所以通常介紹到這裡，大家就會問，那VMware是不是有推出V到T的「移轉工具」，只要在移轉工具內按一按，然後現在的V環境就自動變成NSX-T呢？
的確，NSX-T內有移轉工具，叫做NSX V2T Migration Coordinator，使用上是採用圖形介面精靈的方式，步驟上也不複雜。在後面的篇幅，當然也會和大家就Migration Coordinator進行相關的討論。但必須特別注意的是，採用這個工具之前，需要完整的前置作業與規劃討論，並選擇合適的步驟。只有在經過完善的規劃與測試後，客戶才能期待有一個平順而且不影響生產環境的轉置作業。
V2T移轉的五個準備動作
圖1內是一般在進行V2T移轉的五個準備動作，以下分別進行說明：
圖1 進行V2T移轉的五個準備動作。
現行環境確認
客戶若目前使用NSX for vSphere，那麼生產環境內有使用到哪些NSX功能？只使用微分段，或是有採用邏輯網路？有整合第三方方案？有採用VPN？在這些功能內的運作機制與配置又是怎麼做呢？例如，若客戶採用微分段，來源與目的是採用IP地址，採用群組，還是規則內有採用像是vSphere Cluster作為來源與目的地？與實體間網路的介接是用靜態路由？還是OSPF？還是BGP做動態路由交換？
上面的問題聽起來很繁瑣很無聊，但在移轉前了解環境內用了什麼NSX for vSphere的功能是極為重要的，因為下一個步驟是：這些生產環境內有用的功能，在NSX-T內可支援嗎？移轉工具能支援嗎？
NSX-T功能測試
雖然NSX-T已經涵蓋了NSX for vSphere絕大部分的功能，但這是兩個獨立的產品，在同樣功能的支援方法上還是有差異。因此，在前面的步驟內確認了生產環境需要使用的NSX功能，這邊的步驟就要了解這些功能在T版是否有支援。而如果沒有支援，是否有哪些解決方案讓業務需求可以滿足？
舉個例子，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，可是Migration Coordinator內還沒有辦法支援。那如果企業要進行轉移，這裡就需要討論，移轉的環境是要改成BGP協議，或是這部分要手動來移轉嗎？
因此在此階段，需要確認現行的功能在NSX-T的支援程度，也可能要在測試環境內先行進行移轉工具測試，確認是否有某些移轉條件無法滿足。
教育訓練與Workshop
用戶已經很熟悉V版的操作，但未必了解T版的架構、安裝需求及介面，所以在實際移轉前，可能透過教育訓練、Workshop等不同的方式，讓管理者了解完整的產品與功能，以及後續實際部署時的架構設計考量。
生產共存
甚至不僅是PoC，大型客戶通常會希望導入Staging環境進行NSX-T的初期生產部署，並且放幾個真正的應用在這個環境內試車。過程中，也會進一步了解在V與T版間的功能與維運差異，客戶也可進行內部的維運機制∕對應文件的修正。
實際移轉
在真正大型移轉前，客戶應該要確認：
‧採用哪種移轉的方式，以及移轉前的環境軟硬體準備已經完成。
‧業務移轉的步驟，哪些資源池∕業務先進行，確實的步驟與流程為何。
‧對業務可靠性的影響，是否會停機，若有停機要在什麼時間進行以及內部預告。
‧對應技術人員的資源安排與作業時程。
計畫完成後，才繼續按部就班進行需求的移轉作業。
不知道前面五個步驟這樣談，大家是否清楚，舉圖2做說明，這是一個VMware國外大型客戶實際的例子。
圖2 實際移轉示意圖。
此客戶因為Scale以及NSX-V功能限制等問題，從2020年3月開始規劃要進行V轉T的作業。前期的規劃及測試大概花了整整半年的時間，2020年10月開始以NSX Migration Coordinator進行第一次的非生產環境虛機移轉。在10月、11月兩次移轉沒問題後，12月開始正式進行生產環境虛機移轉。到2021年2月時，在近5個月的時間內，移轉了7,000多個虛機改為NSX-T 3.0.2環境運作。大家可以看到，整個時程內前期準備花了半年，後續的移轉進行與業務觀察也花了約半年。即使有工具，整個V2T Migration仍是一個需要謹慎規劃並小心執行的作業。
通常建議企業進行此工作時，需要與VMware PSO或是熟悉NSX的服務夥伴一同合作，進行完整的測試與規劃。而且足夠的Lead Time是很重要的，以避免在沒有足夠測試下，在移轉時出現各種未預期的狀況，甚至影響到生產環境的運作。
接著，進入一些架構面的部分。企業在採用NSX for vSphere時可能會使用不同的功能與搭配各種情境，因此在移轉時，強制只以一種機制去涵蓋所有的場景也不合理。考量到這些，NSX-T內的V2T Migration Coordinator有數種不同的配置，對應到不同的環境與移轉方法。
接下來，就不同方式的優劣點快速進行說明與比較，但其實總歸一句話：各位在進行V2T作業規劃時，是想要採用In Place 原地移轉）或是Lift and Shift（先建後拆）的機制呢？
何謂In Place（原地移轉）
原地移轉方案的重點在於，客戶環境內沒有新的伺服器，要在現有的資源池內原地進行轉換，如圖3所示。舉例來說，原本的環境是10台伺服器安裝了vSphere以及NSX-V，在採用In Place移轉方式時，沒有多餘的硬體，就是在這10台伺服器上安裝NSX-T的需求元件，並在移轉過程中拆除V版的運作模組。
圖3 In Place（原地移轉）。
在In Place架構內的優點很直接，那就是「不需要採購新的硬體，成本低廉」。
雖然省錢，但選擇這種方法時務必仔細規劃，因為在節省成本的同時，這種方法隱藏了很多風險：
‧在現有的硬體內進行移轉，移轉過程中須額外安裝的NSX-T資源需求，現有硬體的計算與儲存容量是否可以滿足？
‧V2T移轉工具本身不會升級vSphere，那現有的vSphere環境是否與T版安裝時有版本適配問題？是否需要先進行vSphere本身的升版？
‧NSX-T本身在底層伺服器硬體上有CPU、網卡效能等的適配性。舉例來說，建議在選擇網卡時，應該要有支援Geneve-Offload、Receive Size Scaling等功能。原本環境內的硬體與對應驅動程式可否滿足這些需求？是否需要做硬體更換與驅動程式升級？
‧因為是在相同的伺服器硬體內，真正移轉發生時，Migration Coordinator會把vSphere上的V版元件移除，並安裝T版驅動工具。這代表什麼呢？代表「無法回頭」，核心移轉一開始，就只能往前走到底。如果過程中有因為上述軟硬體的適配性或是其他奇異的因素，雖然機率很低，但造成某個地方有移轉失敗，生產環境內業務的可靠性非常可能會受到影響。
所以，雖然是個人意見，如果客戶問筆者，一定是建議以下的方法：Lift and Shift （先建後拆）。
建議Lift and Shift（先建後拆）
如同名稱內指出，這個架構就是企業要買新的伺服器，新建一組環境，如圖4所示。這組環境內，完全從頭開始建立vCenter/vSphere以及最新版的NSX-T Data Center，因為是獨立硬體，所有安裝上的問題都不會影響現有原有環境運作。
圖3 In Place（原地移轉）。
接著，進行NSX內的配置移轉，移轉完成之後，以vMotion或HCX等不同機制，逐步將核心業務系統從V版環境移轉到T版環境內。
移轉過程中，兩個環境全部都運作，客戶可以依據實際需求進行移轉時程規劃。
等到業務全部移轉到新環境，運作一段時間都沒有問題後，原本V版環境就能夠移除，伺服器可以轉移到其他的環境使用，或在相容性容許下，用來擴充T版這邊的資源池。
Lift and Shift架構的優點，說明如下：
‧新的環境內，客戶可以採用與T版相容，功能強、CP值最好的硬體，可以安裝最新版本最安全的vCenter、vSphere、NSX-T。
‧整個T版資源池的建立與現有生產環境無關，團隊可以在不會影響生產環境業務的限制下，進行新環境安裝、相容性調適與測試。
‧虛機移轉的作業採用vMotion或是搭配HCX，在客戶允許的時程、流程內逐步移轉。
‧最重要的是，原本V版的環境一直都在，如果T版的環境出現了未預期的問題，業務機器永遠可以轉回V版環境運作。這個架構是可以回頭（Rollback）的。
而Lift and Shift架構缺點，則有兩項：
‧需要花錢買新硬體。
‧在目前版本的V2T Migration Coordinator中，Lift and Shift架構只有支援DFW相關構件的移轉（DFW rule、Security Group、IPSET、Security Tag等等）。網路部分，如Overlay Network、Routing-Gateway的移轉，目前只能利用手動，或是搭配上層自動化系統如vCloud Director環境來移轉。所有配置都「全部轉移」的機制，目前只有在In Place的架構內支援。
但筆者不覺得這是大問題，在台灣的客戶中很多有相當複雜的DFW防火牆規則需要有工具輔助移轉，但絕大部分網路配置都較為單純，手動移轉相對比較不是問題。
結語
上面花這麼大篇幅討論這兩種架構的優缺點，因為這是在移轉前架構最重要的考量點，選擇哪一種，將會直接影響到整個V2T的後續規劃及設計。筆者個人當然推薦先建後拆方式，但不同的客戶有不同的重點考量，在進行V2T作業前，務必針對這裡不同選擇的優缺點進行討論。除了是要先建後拆還是原地改建的差異外，NSX V2T Migration Coordinator還有其他不同的移轉選項，例如要所有配置移轉還是只轉安全這部分、要不要搭配上面的自動化平台等等。不同移轉的方式，後面會繼續做介紹，下一篇就會以「先建後拆，只轉防火牆配置」來做較為詳盡的討論。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞