接續前文，繼續說明在NSX for vSphere版本內，若要支援跨中心、多個vCenter的架構內，要延伸二層業務網路的Cross-VC NSX方案（NSX Cross-vCenter方案），該如何進行，以及有那些須要注意的事項。
考量到這樣的問題，NSX於6.3版本後推出了一個新功能：CDO（Controller Disconnected Operation）模式。管理者可以於部署NSX時，無論有沒有使用Cross-VC功能，在Transport-Zone內選擇是否要啟用CDO模式。
啟用Controller Disconnected Operation模式
當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內沒有紀錄，但因為進出的網路封包會以廣播的方式複製出來，這台虛機仍然可以與其他虛機溝通。
 |
| ▲圖6 CDO（Controller Disconnected Operation）模式運作示意圖。 |
簡單來說，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架構的管理構件關聯，以及為了避免災備發生時單點失效而設計的新功能CDO模式。
在下一篇文章將會討論在Cross-VC NSX方案內的通用邏輯交換器、邏輯路由器功能，以及如何在跨中心方案內將路徑最佳化。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞