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

我們在和客戶與經銷夥伴討論NSX於Cross-VC架構的方案時，一個時常被詢問的問題是：NSX的Controller Cluster必須要放置在同一個資料中心內。在考慮災害發生的狀況下，此時NSX Controller都在同一個地理資料中心，如果火災了怎麼辦？所有NSX Controller都失效，是不是我們的整個邏輯網路架構，包含跨中心的環境，都會停擺呢？我們能不能把NSX Controller分散到不同的資料中心內？

這邊網誌就要和大家討論這個問題。首先請讀者回憶一下：在NSX生產環境架構內我們要求要有三台NSX Controller虛機，建立起2+1備援架構。如果今天NSX Controller出事了，狀況是怎麼樣？

  • 失效一台：此時環境內仍有兩台NSX Controllers，邏輯網路環境正常運作
  • 失效兩台：此時Controller Cluster會進入Read-Only狀態 (NSX內的專有名詞叫做此時Controller無法組成Cluster Majority)，邏輯網路架構不能進行異動
  • 全部失效：如同失效兩台的狀況，邏輯網路架構不能進行異動

這邊我們要做更進一步的討論：當真的發生有兩台以上的NSX Controller失效時，所謂的邏輯網路不能異動，到底是指什麼？對用戶的實際影響如何？

  • 現有環境已經存在的虛機：正常連線沒有問題
  • 現有環境已經存在的虛機做了vMotion：

– 假設此虛機接取在Logical Switch 5000號。如果此虛機vMotion到一台原本就有其他虛機接在Logical Switch 5000號的vSphere Host上（在5000號邏輯交換器的VTEP Table內有目的地vSphere Host的VTEP資訊），那這台虛機就能正常運作。

– 但如果此虛機vMotion到一台沒有任何虛機接在Logical Switch 5000號的vSphere Host（在5000號邏輯交換器的VTEP Table內沒有目的地vSphere Host的VTEP資訊），此時在Controller失效兩台以上的狀況下，VTEP Table不會更新，沒人知道這台虛機到底在哪邊，這個虛機就網路失聯了。 新增一台虛機，或啟動一台虛機在Logical Switch 5000號上：如果這台虛機所在的vSphere Host上原本並沒有任何虛機接在Logical Switch 5000號的vSphere Host（在5000號邏輯交換器的VTEP Table內沒有目的地vSphere Host的VTEP資訊），那狀況同上，沒人知道這台虛機到底在哪邊，這個虛機就網路失聯了。

上面的狀況如果出現那當然很不好。因此，NSX生產環境內，不希望有Controller同時失效兩台以上的狀況。在任何的架構設計討論場合，我們都會與客戶與經銷夥伴說明，三台Controller應該要各自放在不同的vSphere Host上，且Datastore有必要的話應該分開，避免有Host / Storage / link失效時，同時影響到兩台以上的NSX Controller。

但在跨中心的架構考量時，必須思考可能整個資料中心都會出現失效的狀況。此時，除非NSX的三個Controller可以各自獨立放在三個不同的資料中心，不然同時兩台NSX Controller失效的狀況都難以完全避免。但要將三個Controller分開放，有下列的現實狀況

  • 企業的環境內必須要有三個獨立的資料中心：相當巨大的投資
  • NSX Controller間要求應該是LAN等級的網路連接，這代表三個資料中心間的網路頻寬必須很大（至少1Gbps），Latency必須很低（好歹也低於5ms）。這也是相當巨大的投資

考量到這樣的問題，NSX於6.3版本後推出了一個新功能：CDO (Controller Disconnected Operation) 模式。管理者可以於部署NSX時，無論有沒有使用Cross-VC功能，在Transport-Zone內選擇是否要啟用CDO模式。當CDO啟用時，

  • 如果有兩台以上NSX Controllers失效，此時Controller無法組成Cluster Majority，任一台vSphere Host內的netcpa Agent就無法與NSX Controller正常連接了。此時這些vSphere Host會自動將要發送的網路封包自動複製到Transport-Zone內的所有其他vSphere Host
  • 此時，當任何一台虛機進行vMotion或Power-On，所在的vSphere Host就算連不上NSX Controller，VTEP-Table內沒有紀錄，但因為進出的網路封包會以廣播的方式複製出來，這台虛機仍然可以與其他虛機溝通。

好，說白話文。NSX的CDO模式代表的是，一旦NSX Controller Cluster失效，此時所有在邏輯交換器上交換的網路封包，都會由底層廣播到所有的vSphere Host內。此時，雖然會造成底層大量的頻寬與負擔，但是在Controller Cluster失效的緊急狀況，即使有虛機出現了vMotion動作，或是有虛機開機或產出，管理者仍然可以確保邏輯網路內的連通。像是NSX在Cross-VC的設計內，如果出現了主中心全毀，NSX Controller Cluster整個失效的罕見狀況，管理者可以在業務機器仍然正常連線運作，沒有那麼大壓力的狀況下，進行包含NSX在內的整體資料中心回復。

我們建議，在進行大型跨中心NSX邏輯網路架構設計時，把CDO模式考量在整體架構方案內。但幾點要提醒讀者：

  • CDO功能在NSX 6.3.2版後才算正式GA。因此任何考量採用CDO模式的NSX環境，務必要採用最新版本的NSX進行部署
  • CDO模式會佔用極為大量的網路頻寬。
  • 大家可能會問，既然沒有Controller的狀況下NSX邏輯網路也能用廣播方式正常運作，那為什麼要安裝NSX Controller，或是NSX Controller是不是不用回復？當然不是。NSX Controller失效的狀況下

– 任何邏輯交換器新增、刪除、異動的動作無法進行

– 邏輯路由器的路由更新動作無法進行

因此管理者當然仍然應該在最短時間內完成NSX控制器的復原。

下篇網誌會是本系列討論跨中心NSX運作的最後一篇，我們要和大家介紹在Cross-VC NSX架構內，採用通用分散式防火牆進行微分段保護的功能。