跨資料中心虛擬化架構多　網路連通規劃細思量

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

如果不需要，兩邊資料中心的業務網路可以完全獨立沒有關聯，各自管好自己就好，只要實體網路能夠讓vCenter跨中心連接到遠端叢集內的伺服器進行管理就可以。

如果需要具備跨資料中心飄移的功能，此時第一件要做的事情是，兩個中心的各叢集間必須要能支援vMotion功能。這代表必須要規劃一個跨中心的實體二層或三層vMotion網路連線，限制是頻寬要大於1Gbps，且網路延遲時間應小於150毫秒。

同時，當業務機器進行飄移時，大家一定不希望還要改IP、改配置，甚至業務持續Online不要下線。因此，業務網路應該要跨中心二層打通，如圖2所示。

▲ 圖2 單一vCenter管理不同資料中心內叢集。

不同vCenter各自管理不同資料中心內叢集

不同vCenter各自管理不同資料中心內叢集（Cross-vCenter Architecture）與第二種架構不同的是，各自的資料中心內有自己的vCenter，而在不同資料中心內的資源池由不同vCenter進行管理（圖3）。企業為何會採用這種架構有很多原因，例如：

▲ 圖3 不同vCenter各自管理不同資料中心內叢集。

‧建立不同業務或不同部門間的獨立資源池以及管理區隔，達到權責與資源的分離。

‧第二個資料中心是災備中心，用戶手動或是搭配SRM，讓主中心的完整虛擬化資源能夠於必要時在另一個中心進行災難復原。

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

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

首先，虛機要不要能夠跨中心、跨資源池Cluster進行vMotion，達成業務負載行動化與資源池互為支援？

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

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

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

前面與大家討論了三種不同的跨資料中心虛擬化資源池架構，也討論了在三種架構內，「基本上都有把業務網路（Application Network）二層連通的需求」。

虛擬化環境跨中心連接介紹

如果大家在規劃時認為業務的二層網路連通是有好處的，那接下來就要討論下一個議題：如果想把多個資料中心間的業務網路二層連通，讓虛機能夠跨中心轉移或是災備時不要改IP，那麼有哪些方式能夠做到呢？當企業環境內的多個資訊系統所使用的業務網路（Application Network or Business Network），要跨中心二層相連時，用不同技術的優缺點是什麼？直接拉光纖嗎？與線路服務提供商租用嗎？用硬體設備來封裝嗎？用NSX的邏輯交換器呢？用L2VPN呢？

向線路服務提供商租用二層線路

向線路服務提供商租用二層線路，可能包含租Dark-Fiber、租用DWDM、租用VPLS等等不同方法。總之，花錢給線路服務提供商，要多少頻寬給多少頻寬，服務提供商直接把線路兩端拉到不同資料中心的客戶網路交換器，大二層直接打通，就像圖4這樣。

這是很多大型企業要跨中心建立二層網路的標準方法，但是可能要考慮以下幾種情形：

這個方式會真正把數十個或數百個二層業務網路延伸到多個資料中心，每個業務網路的Broadcast Domain變得很大，要進行這堆業務VLAN Spanning-Tree管理的設備會相當多。簡而言之，「廣播風暴造成業務停擺的風險會大幅提高」，Spanning-Tree的管理會相當複雜。通常服務提供商、網路設備原廠與SI會和大家打包票，廣播風暴不會發生。個人的經驗是，平均每三個月到半年，就會從某個客戶端聽到又有哪家公司跨中心底層出現廣播風暴，服務掛掉一整天，然後認真地開始討論要將跨中心間的網路架構由二層調整成跨三層方案。

▲ 圖4 向線路服務提供商租用二層線路。

如果業務網路很少而且很固定，那一次安裝後，維運的麻煩應該不大。但是如果業務網路架構時常異動，比如今天多了個新業務要上線加幾個網段，下星期有個新租戶的應用要兩個網段，此時維運面的麻煩就會很大了。考慮一下，要加一個新VLAN，要異動的設備可能包括企業自己的跨中心多台交換器，也很可能會包括服務提供商那裡的設備調整。要申請、要時間、要配置，大家整天做這件事就好了。

此外，尤其是雲服務提供商與大型金融機構，當業務網路因為多租戶多業務系統而要求的數量越來越多時，VLAN上限最多4,096個的問題就會逐漸浮現了。

如果企業只有少數、不常異動的實體網路要二層跨網段，通常不會有太大的問題。但如果大量的Application Network都規劃要跨中心，此時用實體網路的方法可能就會在維運面上常出現狀況了。