接續前文，繼續說明在NSX for vSphere版本內，若要支援跨中心、多個vCenter的架構內，要延伸二層業務網路的Cross-VC NSX方案（NSX Cross-vCenter方案），該如何進行，以及有那些須要注意的事項。
如果是要進行Universal DFW的設定呢？如圖4所示，同樣地，管理者用UI或API對Primary NSX Manager下指令（黑色線?），相關的配置會同步到其他台Secondary NSX Manager（深綠色線?），然後各台NSX Manager會把這些防火牆與安全群組的配置送到所管理的本地資源池內（紅色線?）。
 |
| ▲圖4 進行Universal DFW設定。 |
避免NSX Controller同時失效
上面討論了在Cross-VC架構下的NSX管理構件與連動關係，接著繼續下一個問題說明。
在與客戶與經銷夥伴討論NSX於Cross-VC架構的方案時，一個時常被詢問的問題是：架構上NSX的Controller Cluster必須要放置在同一個資料中心內。在考慮災害發生的狀況下，此時NSX Controller都在同一個地理資料中心，如果火災了怎麼辦？
所有NSX Controller都失效，是不是整個邏輯網路架構，包含跨中心的環境，都會停擺呢？能不能把NSX Controller分散到不同的資料中心內？
接下來就與大家討論這個問題。首先請回憶一下：在NSX生產環境架構內，要求要有三台NSX Controller虛機，建立起2+1備援架構。如圖5所示，如果今天NSX Controller出事了，狀況是怎麼樣？
 |
| ▲圖5 兩台以上的NSX Controller失效。 |
‧失效一台：此時環境內仍有兩台NSX Controller，邏輯網路環境正常運作。
‧失效兩台：此時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必須很低（好歹也低於5毫秒），這也是相當巨大的投資。