VMware HCX可透過四種方式進行批次大量虛機傳輸，但實務上將虛機在兩個站點間進行移轉時，這些虛機接取的底層業務網路應當如何處理？倘若兩個站點沒有同樣的業務網路，把虛機移轉過去可能也無法讓業務連通。這時，透過HCX Network Extension就能夠處理這些狀況。
部署VMware HCX時，可能是地（資料中心）對空（公有雲）也可能是地對地，或許來源與目的端在不同資料中心，也可能在同一個資料中心。無論如何，當要把虛機透過前幾篇文章中討論的各種機制大規模批次移轉到目的端時，一定會面對一個問題：來源端的業務網路與目的端的業務網路是不是同一個，簡單來說，在虛機轉移過去之後，「要不要改IP與閘道（Gateway）」？
IP/Gateway改或不改移轉方式大不同
對於客戶的重要業務機器來說，移到新環境時是不是一定需要採用原本的IP地址，本身就是個大哉問，這不單牽涉到技術，還包含到原本AP的設計及維運。有些舊AP連開發團隊都不在了，裡面構件間的IP關聯也寫死沒有用FQDN，拜託客戶改IP像是要他們的命一樣。
而且這邊的決定未必是Infra團隊可以自行討論，通常一定要以AP維運團隊的意見為主。所以通常在業務移轉過程中，會需要開好幾次會，做下列的選擇：
‧業務虛機在移轉的過程中「可以停機，IP也可以異動」。此時最簡單，來源與目的端環境可以使用不同的IP業務網段，這些機器無論是採用HCX內的Cold Migration或Bulk Migration都沒問題。在前面關於Bulk Migration的介紹中大家也看到，HCX本身就有設計可以在移轉時進行各個虛機IP/Gateway的修改，過程中可以自動執行網路異動的作業。
‧業務虛機在移轉的過程中因為種種因素「IP不能異動，最好移轉時也不要停機」。此時要滿足上述的條件，業務網路勢必需要在來源與目的地間可以二層延伸，且通常會在HCX內採用vMotion、RAV的方式進行虛機移轉。
如果在與AP團隊討論後的結論是IP地址無法更動，此時就會進入下一個課題，需要找網路團隊一同討論：這種將來源業務網路延伸至目的端的需求要怎麼達成呢？一般來說有下面幾種選擇的機制：
最簡單的方式，就是底層的業務網段，可以vlan整個大二層延伸到新環境內，Gateway也停留在原本的來源端實體網路設備上。這架構超級簡單容易理解，但重點在客戶網路團隊的實體環境能否支援，很可能會因為設備與實際機房配置的狀況做不到，或是需要非常複雜的組態異動。
而且上面即使可行，也通常僅在單一資料中心的不同機櫃間。如果要討論跨資料中心的二層網路延伸，那有幾種手段。一般來說，大部分會先提出的不外乎兩種：首先是能否與電信商租用指定線路，直接把二層網路透過指定線路拉到另一端。這是可行的，但通常費用相當高，要異動的設備也很多。
另一種機制是在兩邊的設備間以軟硬體網路設備的方式透過封裝，例如OTV、VXLAN+BGP，或用NSX的邏輯網路封裝。這種方式有些會牽涉到須採購特定的網路設備，或是碰到底層電信商網路的限制，如MTU無法加大等，也不易進行。而且想一想，兩邊都是客戶自己的資料中心也就算了，如果目的端環境是公有雲，客戶有可能自己在公有雲端擺個實體網路設備與來源端做OTV嗎？應該可以看出這邊的限制也很多。
一個比較簡單的方式可能是採用L2VPN，NSX本身就有支援，客戶也可以透過某些支援的硬體廠商設備功能來做。但手動設定L2VPN又很複雜，在大規模虛機移轉時若牽涉到很多業務網路，光配VPN就配不完。
所以，這就是HCX Network Extension能夠解決的問題：
採用HCX的環境中，目的端網路一定有NSX。HCX可以極為方便地在來源端與目的端以NSX技術快速建立二層網路延伸（且無須手動設定複雜的L2VPN配置），將來源端的VLAN or Overlay網路延伸到目的地的NSX Overlay網路。除此之外，虛機以不同機制移轉到目的地NSX Overlay網路內，由於目的與來源業務網路已做成二層連通，虛機移轉過程中無須改動IP/Gateway。
而在所有此網段的業務虛機都移轉完成後，客戶可以考慮直接把整個業務網路Gateway移轉到目的NSX上。此時，不僅是虛機移轉完成，連業務網段都一起切換到目的地。
HCX Network Extension運作說明
怎麼做到的呢？用下面的例子來說明HCX Network Extension的運作方式。在圖1中，左邊來源端的環境有172.16.23.0/24網段是vlan 23的實體網路，網段內有重要的業務機器，而Gateway是直接位於實體路由器上，所有進出此網段的Traffic是走左邊的路徑。右邊是HCX目的端，已經建置NSX-T環境且配置了必要的T0/T1閘道器。
圖1 HCX Network Extension展示流程—原始狀態。
在HCX內，要延伸這個網路非常簡單。在圖2內，選擇要對A-PG-vlan23這個Port Group進行Network Extension，HCX會自行帶入這個網路的vlan ID，管理者需要填入的僅有兩個值：這個Port Group裡的Gateway，以及如果延伸過去，在目的端這個延伸網路需要接到哪個T1閘道器上。
圖2 選擇將A-PG-vlan23這個Port Group進行Network Extension。
相關的值填入確認後，HCX就會自動由來源到目的端建立一個Network Extension通道，來源端就是原本的Port Group，而在目的端，HCX會在現有的T1上自動建立一個新的Logical Segment，然後把這兩個網段以HCX的底層技術橋接起來，如圖3所示。
圖3 HCX會自動由來源到目的端建立一個Network Extension通道。
圖4是到目的端的NSX介面來看由HCX產出的邏輯交換器。這個Segment的重點除了在於HCX自動產出，還可以看到上面其實有被指派（Assign）了Gateway IP，但是Connectivity的配置是Off。
圖4 到目的端的NSX介面查看由HCX產出的邏輯交換器。
什麼意思呢？用圖5的示意圖就比較清楚。此時左邊的Port Group與右邊新產出的Overlay Segment透過Network Extension二層連通，但是網段的Gateway仍在左邊的實體路由器上，此網段與右邊目的地的T1 Gateway並沒有連接。此時，所有網段Traffic當然都還是由左邊來源端進出。
圖5 HCX Network Extension展示流程—建立Network Extention。
但橫跨來源目的地的二層網段已經建立了，就可以用各種手段（Bulk Migration、vMotion、RAV等等）把這個網段內的虛機批次移轉到目的地。
在移轉過程中，虛機的IP與Gateway不需要修改，如果採用vMotion/RAV的方式，虛機就不需要關機，虛機間與用戶到虛機的Traffic都可以持續連通。但當然，所有的網段進出Traffic都是在來源端，如圖6所示。
圖6 HCX Network Extension展示流程—機器移轉。
接下來討論一個問題：前面的步驟已經把延伸網路接好，所有虛機也送到目的端，過程沒有改IP也不斷線。那之後呢？這個Network Extension的通道就一直擺著嗎？這或許也是一種選擇，但如果所有這個網段的虛機都已經被轉移到目的地，來源實體網路上已經沒有機器，這樣的架構還一直要持續擺著嗎？
一般的考量應該會是把Network Extension拆掉，然後把這個網段的進出口改到右邊目的端。在NSX-T + HCX的架構內這個運作非常簡單，只需要下列步驟：
1. 在HCX內把Network Extension移除。
2. 手動（在NSX介面內）或自動（由HCX呼叫）將目的地的Overlay網路接到T1上，也就是前面提到的Connectivity由Off改為On。此時，NSX T1 Gateway會把這個網路往上發布，透過如BGP等告知企業網路，企業網路內的路由就會知道往172.16.23.0/24網路要透過右邊的路由器。
3. 同時當然不要忘掉，網路管理者要把左邊實體路由器上的172.16.23.254閘道移除。
此時，如圖7所示，包含業務網段與虛機就都轉移到目的地環境內運作了。
圖7 HCX Network Extension展示流程—更改Gateway至目的端。
希望由前面的介紹，大家對HCX Network Extension的運作模式有更進一步的理解。這邊列出幾個Network Extension的注意事項給大家參考：
‧來源端的網路支援標準的VDS Port Group（VDS需5.1版以上），也可以是NSX for vSphere的Logical Switch（NSX-V需6.4版以上），或是NSX-T的Overlay/VLAN segment。
‧HCX Network Extension的目的端一定是Overlay Segment，不會是vlan Segment。如果管理者想要延伸到目的地的實體網路，例如把來源端的vlan 23延伸到目的地的vlan 23，需要採用其他的實體方法，並非採用Network Extension的情境。
‧Network Extension只能用來延伸業務網路，不能用來延伸管理網路（如Management、vMotion、vSAN等等）。
HCX方案疑難排解
到此，此系列文章已經把VMware HCX的相關功能，包含功能簡述、四種主要移轉機制以及Network Extension架構等進行了討論。最後，想把與客戶介紹HCX方案時，經常被詢問到的問題一一與大家進行說明。
HCX的授權要怎麼買呢？是來源端與目的端所有vSphere都得具備HCX的授權嗎？
首先要區分是在哪種環境內的HCX方案。如果是地對空，在VMware的合作夥伴那裡應會將HCX方案以內含或加值的方式，提供在公有雲租用的項目裡面。以VMC on AWS為例，當企業租用這個服務，HCX功能是內含在租用費用裡面。若有興趣請與VMware的合作夥伴聯繫。
在地對地部分，至少在本文寫作的時間，HCX的授權並沒有單獨銷售。HCX Advanced（基礎功能）是內含在NSX Data Center Enterprise Plus或是vCloud Foundation Enterprise的授權內。而如果想要使用到HCX Enterprise（如前文提到的Replication Assisted vMotion這些功能），須在取得HCX Advanced授權後，進一步透個額外Add-on的方式提供。
但若要購買NSX/VCF的授權，僅需要購買目的端的授權即可。舉個例子說明，企業原有24台x86伺服器上面跑vSphere 5.5的環境。而在新專案內，此企業會新購12台新的但更強大的x86伺服器，上面跑vCenter/vSphere 7.0加上NSX Data Center 3.1版。此時，在新的12台伺服器上只要有NSX Data Center Enterprise Plus或是VCF Enterprise的授權即可，原本24台舊的x86伺服器並不需要。
另外有一點要特別注意的是，在目的地的vCenter內，「每一個Cluster」都需要有HCX的授權。如果目的地環境vCenter內有兩組以上Cluster，只有一組有購買HCX授權，另一組沒有，這樣是會出問題的。
HCX要運作，是不是目的與來源環境都需要安裝NSX才行？
目的地的環境必須要有NSX Manager安裝，HCX在目的端安裝時會要求輸入NSX的資訊。來源端這邊有沒有NSX都是可以的。但如果有，無論是NSX for vSphere或NSX-T的版本，HCX都可以抓取到在NSX Logical Switch/Segment裡面的虛機，並提供轉移服務
HCX可否在實體隔離（Air-Gapped）、沒有Internet的環境內運作？
抱歉不行。HCX的安裝很特殊，無論是在目的地以及來源端安裝，都會連接到Internet上特定的網站，進行包含授權Activation以及新版本下載更新等作業。HCX允許透過Proxy的方式連接到這些外部網站，但在完全沒有Internet、離線的環境，HCX是無法安裝完成的。
最後，想提供幾個重要的鏈結讓大家參考。如果想對VMware HCX有進一步的了解，這些是很好的參考資料：
‧HCX User Guide（https://docs.vmware.com/en/VMware-HCX/services/hcx-user-guide.pdf）
這份不單純是安裝文件，裡面的章節有解釋不同HCX的轉移方式、限制以及機制細節，值得一讀。
‧HCX.Design（https://hcx.design/）
這個網站的作者是VMware負責HCX的產品經理，所以大家可以把裡面發布的內容視為某種程度的正式資訊。網站內資源豐富，包含HCX的功能、架構等等均有討論。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路、微分段安全防護技術，以及新應用遞送方案的介紹與推廣。＞