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

包含在這網誌之前的系列文章討論，VMware在外面研討會的介紹，以及實際於台灣與國外客戶的部署案例，大家應該滿清楚NSX的幾個重要常見使用情境：快速於VMware資源池內提供需求的網路及安全功能，搭配API，達成IT自動化與敏捷式開發；或是以微分段技術完整於虛機前進行東西向安全防護，協助客戶打造最安全的虛擬化資源池。但其實NSX有另一個使用情境或許大家比較少採用，我們也較少與大家討論的，是NSX跨多個資料中心間的應用方式。在接下來的幾篇網誌，我們希望與大家討論下面幾個與NSX跨中心應用相關的議題，包含：

  • 虛擬化環境跨中心的方案應用有分成哪幾種
  • 採用NSX邏輯網路跨中心與其他的方案相比間的優缺點
  • 以NSX進行Cross-vCenter跨中心方案時的架構討論
  • 以NSX進行Cross-vCenter跨中心接取方案的路由控制方式
  • 以NSX進行Cross-vCenter跨中心接取方案的微分段防護架構

在NSX於跨中心方案的相關議題，VMware已經有對應的白皮書進行完整的討論，這幾篇網誌可以視為比較簡化的導讀。有興趣或實務上需要應用到跨中心方案的讀者，請到https://communities.vmware.com/docs/DOC-32552 內下載完整的文件，我們也很樂意與大家就此方案進行更進一步的介紹與討論。

所以首先第一個議題：我們到底在討論哪一種跨中心方案？通常在和客戶討論時，大家在這邊的名詞都很混淆，我們現在討論的是一個雙中心、還是主備援中心，還是兩地三中心？事實上不同的需求有不同的架構與因應方式，而且討論此事情時其實很複雜：一個跨中心的方案不僅包括虛擬化環境如何架構，當然也包含還停留在實體環境內的業務，資料如何同步與備份、網路如何在失效時進行切換以及路徑的設計等不同問題。但針對一個雲平台 / 虛擬化環境管理者，我們所關心的跨中心虛擬化環境架構大概可以分成下列幾種模式：

延伸式叢集 (Stretched Cluster)：

延伸式叢集會橫跨兩個地理上分開的資料中心，如下圖內的Stretched Cluster B有橫跨Data Center 1與Data Center 2。因為在vCenter架構內這些地理上分開的實體伺服器是建置在同一個叢集內，因此包含在單一叢集內可以使用的vMotion / HA / DRS等功能都可以跨資料中心實現。這代表著當客戶要建立延伸式叢集時，可以直接取得虛擬化業務機器跨中心自動防護、遷移與業務負載平衡的功能。

在延伸式叢集內

  • 底層的儲存必須完全同步。用戶必須選擇可以符合vMSC (vSphere Metro Storage Cluster) 架構的儲存設備如EMC VPLEX或是vSAN來進行跨中心間的資料同步
  • 且為了滿足儲存同步的條件，一般來說兩地間的網路Latency必須小於5 ms，傳輸頻寬必須大於10 Gbps。以台灣這邊的實際部署案例，大概是最多台北到彰化間的距離。也因此，這個方案大部分應用於短距離，或甚至同個廠區、校區間不同機房的建置方案
  • 由於上述的需求，延伸式叢集方案都是在硬體設備投資以及底層網路租用費用上相當高貴的方案，但同時當然，也是效益最顯著的方案
  • 兩地間的vSphere伺服器因為屬於同一叢集，所以當然必須由同一個vCenter、同一個管理者來進行管理

而在延伸式叢集內，業務虛機可以任意地跨中心進行建立與轉移，因此這些虛機所接取的業務網路 (Application Network) 當然必須要能夠二層跨中心連接。虛機無論時因為手動或自動飄移到另一個中心，或是由於實體伺服器損壞、單一中心災害發生要切換到另一個中心去，都必須要能夠接在同一個二層網路內並持續與其他構件連通，無需手動進行任何的網路重新配置。此時，兩個中心間的業務二層網路連通當然是大家在考慮此架構時必須要能夠達成的。

單一vCenter管理不同資料中心內叢集 (Single vCenter with Seperated Cluster)：

這也是常見架構，企業在不同的資料中心內各自建立獨立的叢集，但由於管理的方便性，跨中心的不同叢集由同一個vCenter進行管理。這個架構內，不同中心內的叢集是資源獨立的，有自己的儲存、自己的運算資源。

這個架構內，HA / DRS功能限制於單一資料中心的叢集內，各資源池自己管好自己就好。但架構上需要問一個問題：你希不希望虛機可以跨中心跨Cluster進行遷移？舉例來說，可能你想把測試叢集內的業務機器轉移到生產叢集內 (Workload Mobility)，或是左邊資料中心資源池的容量不夠，你希望能夠將機器飄移到具備充足資源的右邊資料中心去 (Resource Pooling)？

  • 如果不需要，兩邊資料中心的業務網路可以完全獨立沒有關聯，各自管好自己就好，只要實體網路能夠讓vCenter跨中心連接到遠端叢集內的伺服器進行管理就可以。
  • 如果需要具備跨資料中心飄移的功能，此時第一，兩個中心的各叢集間必須要能支援vMotion功能。這代表你必須要規劃一個跨中心的實體二層或三層vMotion網路連線，限制是頻寬要大於1 Gbps，且網路延遲時間應小於150 ms。
  • 同時，當業務機器進行飄移時，大家一定不希望還要改IP、改配置，甚至業務持續online不要下線。因此，業務網路應該要跨中心二層打通，如上圖內一樣。

不同vCenter各自管理不同資料中心內叢集 (Cross-vCenter Architecture)：

與第二種架構不同的是，各自的資料中心內有自己的vCenter，而在不同資料中心內的資源池由不同vCenter進行管理。企業為何會採用這種架構有很多原因，比如說

  • 建立不同業務或不同部門間的獨立資源池以及管理區隔，達到權責與資源的分離
  • 第二個資料中心是災備中心，用戶手動或是搭配SRM，讓主中心的完整虛擬化資源能夠於必要時在另一個中心進行災難復原

企業併購了其他的公司，因此不同的組織未合併前自然地就有多個資源池存在。

與前面的架構同樣，用戶是這樣的環境時，架構師應該思考

  • 虛機要不要能夠跨中心、跨資源池Cluster進行vMotion，達成業務負載行動化與資源池互為支援？
  • 即使不考慮vMotion，這樣的環境內如果要支援災備架構，無論是手動或是採用SRM，也應該要考慮，當災備啟用，業務由一邊切換到另外一邊時，備援的機器要不要改IP？防火牆配置要不要改？負載平衡器設定要不要改？如果業務網路能跨中心兩邊完全使用同樣的二層網路，甚至三層路由及防火牆配置都能統一，此時在虛擬化環境的災備設計上，就會變得非常簡單。

此時，跨中心間的網路要考慮，

  • 同前，如果需要具備跨資料中心飄移的功能，於vCenter 6之後vSphere就已經支援Cross-VC vMotion的功能了。但網路上必須要具備跨中心的實體二層或三層vMotion網路連線，頻寬要大於1 Gbps，且網路延遲時間應小於150 ms。
  • 而無論是要跑on-line vMotion或是搭配備援機制，如果業務網路能夠跨中心二層打通，會具備極大的管理便利性。

大家可能會詢問，在自己的企業環境內，有可能在單一地理資料中心內有多個vCenter / 多個獨立的資源池，那這是哪一種。這樣的架構基本上與我們提到的Cross-VC Architecture是一致的，且由於是單一中心，跨資源池間的vMotion網路需求更容易達成。但同樣的，要不要在跨vCenter的不同資源池間把業務網路打通呢？這邊的需求會與上面相同。

在本篇網誌，我們和大家討論了三種不同的跨資料中心虛擬化資源池架構，也討論了在三種架構內，是不是有把業務網路 (Application Network) 二層連通的需求。如果大家在規劃時認為業務的二層網路連通是有好處的，那接下來的網誌就要討論下一個議題：

如果我們想把多個資料中心間的業務網路二層連通，讓虛機能夠跨中心轉移或是災備時不要改IP，那麽有哪些方式能夠做到呢？是否一定要用NSX呢？