虛擬雲網路

網路虛擬化NSX 技術文章系列二百零九: NSX – V轉T事前規劃及工具討論(六)

作者: 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工具這邊經銷夥伴與客戶常詢問的問題進行討論。

相关文章

评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注