杭州華三分布式雙活數(shù)據(jù)中心解決方案 ,前言2 ,分布式雙活數(shù)據(jù)中心大二層網絡設計在分布式數(shù)據(jù)中心解決方案中，為了實現(xiàn)跨中心計算資源的動態(tài)調配，一

杭州華三分布式雙活數(shù)據(jù)中心解決方案

前言

2

分布式雙活數(shù)據(jù)中心大二層網絡設計

在分布式數(shù)據(jù)中心解決方案中，為了實現(xiàn)跨中心計算資源的動態(tài)調配，一般采用虛擬機遷移技術（H3C DRS，VMWare VMotion），同時采用服務器高可靠性集群計算實現(xiàn)跨數(shù)據(jù)中心的應用級容災，這兩種應用場景統(tǒng)稱為“分布式數(shù)據(jù)中心（Distributed Data Center）部署方式”，其特點是一個應用系統(tǒng)在IP 地址不變的情況下可以在不同數(shù)據(jù)中心對外提供服務，但同一時段此應用只出現(xiàn)在一個數(shù)據(jù)中心，數(shù)據(jù)中心的訪問用戶不感知這種變化。虛擬化從根本上改變了數(shù)據(jù)中心網絡架構的需求，最重要的一點就是，虛擬化引入了虛擬機動態(tài)遷移技術，從而要求網絡支持大范圍的二層域，大二層網絡技術應運而生，以幫助解決二層網絡的擴展。

成本高，同時MPLS 網絡配置復雜，同時也需要設計STP 域隔離及VRRP 報文隔離，維護困難，隨著二層域的擴大，廣播域擴展到多個中心。

○ 基于IP 網絡的VLL Over GRE或VPLS Over GRE方案與

基于MPLS 網絡的VLL 或VPLS 技術的區(qū)別僅僅是承載網變?yōu)镮P 網絡，其他設計完全一樣，所以也面臨同樣的設計及運維問題。

H3C 新一代大二層網絡設計

針對傳統(tǒng)數(shù)據(jù)中心二層網絡擴展技術面臨的問題，H3C 推出了一種新型的大二層擴展技術EVI （Ethernet Virtual Interconnection ），他是一種MAC Over IP的二層互聯(lián)技術，承載在現(xiàn)有的IP 網絡之上，適應性強，價格低廉，同時針對數(shù)據(jù)中心大二層擴展面臨的問題，做了針對性的設計，能夠天然解決傳統(tǒng)大二層網絡擴展帶來的各種問題，并對ARP 泛洪等應用進行了優(yōu)化，且配置部署非常簡單，EVI 典型組網方案如下：

圖2 雙活數(shù)據(jù)中心大二層網絡

傳統(tǒng)大二層網絡設計所面臨的問題

傳統(tǒng)大二層擴展技術包括裸光纖二層互聯(lián)技術、基于MPLS 網絡的VLL 或VPLS 技術，基于IP 網絡的VLL Over GRE或VPLS Over GRE方案（具體設計見IP 領航數(shù)據(jù)中心特刊《數(shù)據(jù)中心間二層互聯(lián)》），通過特殊的配置和手段，這三種技術都能夠實現(xiàn)數(shù)據(jù)中心二層互聯(lián)并且能夠解決端到端的環(huán)路問題，但是部署起來也面臨非常大的問題：

○ 基于裸光纖的二層互聯(lián)技術前提要求必須有裸光纖資

圖3 EVI典型組網

EVI 部署時，為了不影響現(xiàn)有數(shù)據(jù)中心網絡，同時由于跨中二層信息交互比較頻繁，所以一般情況是在數(shù)據(jù)中心匯集設備上旁掛兩臺（不考慮冗余也可以是一臺）EVI 設備進行EVI 互聯(lián)，當數(shù)據(jù)中心站點EVI 設備上線時，原有的EVI 節(jié)點不需要做任何改變就能夠自動完成所有EVI 虛鏈路的建立，進而實現(xiàn)大二層網絡的擴展。

源，同時距離不得超過100KM ，使用成本高昂，STP 域隔離設計復雜，隨著二層域的擴大，廣播域擴展到多個中心。

○ 基于MPLS 網絡的VLL 或VPLS 技術，要求承載網為

MPLS 網絡，其中MPLS

網絡可以自建也可以是運營商提供，

3

基于DNS 發(fā)布業(yè)務的前端網絡雙活設計

當業(yè)務系統(tǒng)基于DNS 域名方式對外發(fā)布時，可通過動態(tài)DNS 可以實現(xiàn)訪問流量的智能分發(fā)調配無需增加廣域網開銷。該方案有兩個關鍵技術，一是“網關分離”，在本文前一章節(jié)有詳細說明，此處不再贅述。另一關鍵技術是“動態(tài)DNS 解析技術”，同一個虛機在不同數(shù)據(jù)中心通過NAT （由SLB 設備實現(xiàn)）呈現(xiàn)不同的服務IP 地址。GSLB 作為DNS 服務器，虛機的遷移事件可觸發(fā)vCenter 上的可執(zhí)行腳本，遠程修改GSLB 上虛機對應的DNS 記錄，由此實現(xiàn)新上線用戶的三層路徑優(yōu)化。

如圖6所示，數(shù)據(jù)中心1、數(shù)據(jù)中心2的服務器采用了VMware 虛擬化技術，vCenter 部署在數(shù)據(jù)中心1，網絡匯聚層實現(xiàn)二層互聯(lián)，兩個數(shù)據(jù)中心同時部署同一個網段的網關，網關IP 地址相同，虛機就近選擇本數(shù)據(jù)中心的網關進行三層流量轉發(fā)；匯聚層設備上旁掛主備方式部署的SLB 設備，匯聚于核心路由器間部署主備方式的防火墻；廣域網中部署了基于DNS 技術的GSLB 設備，客戶機端通過域名方式訪問數(shù)據(jù)中心的業(yè)務系統(tǒng)。當管理員通過數(shù)據(jù)中心1中的vCenter 將業(yè)務系統(tǒng)app.h3c.com 對應的虛擬機從數(shù)據(jù)中心1遷移至數(shù)據(jù)中心2時，當前已在線用戶的訪問流量不中斷（可以存在三層方案次優(yōu)路徑），而新上線訪問app.h3c.com 的用戶選擇三層最優(yōu)路徑訪問位于數(shù)據(jù)中心2的虛機。

○ 步驟3：SLB1設備對用戶A 的流量做NAT （地址轉

換），報文的源IP 被改為SLB1的接口地址IP-1地址，目的地址被改為虛機的真實地址VM-IP 。

○ 步驟4：虛機到用戶A 的回程報文的源IP 是VM-IP ，目

的IP 是SLB 的接口地址IP-1。由于虛擬機的網關指向匯聚交換機，從虛擬機到用戶A 的回程流量經匯聚交換機轉發(fā)到主SLB1上。

○ 步驟5：SLB1查會話表，將該IP 報文的源地址改為VIP-

1，將目的地址改為用戶A 的實際IP ，最后該IP 報文經核心廣域網轉發(fā)到用戶A 。

如圖7所示，某時刻，數(shù)據(jù)中心1的管理員在將app.h3c. com 對應的虛擬機通過vCenter 遷移至數(shù)據(jù)中心2，此時有兩個制約因素要求用戶A 訪問虛擬機的流量仍然將數(shù)據(jù)中心1作為訪問流量的入口：

圖7 虛擬機遷移后已上線用戶流量

由于用戶A 的終端設備（PC ）具有本地DNS 緩存，在DNS 緩存超時之前，用戶A 的終端仍然將app.h3c.com 解析成VIP-1。

由于從用戶A 的終端設備到提供app.h3c.com 業(yè)務的虛機

的訪問路徑上存在防火墻，且防火墻通常采用基于TCP/UDP狀態(tài)的會話檢查機制，所以對于已經上線的用戶A （防火墻上已建立用戶A 到虛機的會話表項），必須保證虛機遷移后，從用戶A 到虛機的訪問路徑仍然保持原有路徑（經過原

來的防火墻）。

上述限制條件意味著從用戶A 訪問app.h3c.com 的數(shù)據(jù)流在步驟2和步驟3會發(fā)生如下變化：

○ 步驟2：SLB1上經過NAT 處理后的報文被轉發(fā)至數(shù)據(jù)

圖6 基于DNS 發(fā)布業(yè)務雙活方案

如圖6所示，當app.h3c.com 對應的虛擬機運行在數(shù)據(jù)中心1時的流量如下：

○ 步驟1：某用戶A 希望訪問app.h3c.com ，其客戶機向本

中心1的匯聚交換機（有VM-1對應的直連網段路由），該匯聚交換機查ARP 表后，將報文發(fā)往與數(shù)據(jù)中心2的匯聚交換機相連的端口。數(shù)據(jù)中心2的匯聚交換機查MAC 表，完成最終轉發(fā)。

○ 步驟3：由于數(shù)據(jù)中心1的匯聚設備與數(shù)據(jù)中心2的匯

地部署的DNS 服務器發(fā)起查詢請求，通過迭代查詢，最終由作為權威DNS 服務器的GSLB 返回查詢結果：app.h3c.com 對應的IP 地址是數(shù)據(jù)中心1中的SLB1上配置的VIP_1。

○ 步驟2：用戶A 發(fā)起的流量經過核心廣域網的轉發(fā)來到

數(shù)據(jù)中心1的SLB 主設備上。

聚設備采用了網關分離部署方式，所以虛機到用戶A 的回程

5

報文首先發(fā)向數(shù)據(jù)中心2的本地網關（數(shù)據(jù)中心2的匯聚交換機）。數(shù)據(jù)中心2匯聚交換機與數(shù)據(jù)中心1匯聚交換機互聯(lián)的三層接口上已經學到SLB1接口地址IP-1對應的路由，所以回程報文經數(shù)據(jù)中心1匯聚交換機轉發(fā)后回到SLB1。

這種次優(yōu)路徑流量不會一直存在，當用戶A 結束對app. h3c.com 的所有訪問流量后一段時間，本地DNS 緩存超時清空，用戶A 如果再次發(fā)起的TCP/UDP會話，則數(shù)據(jù)流將按照后文所述用戶B 的方式轉發(fā)。圖8是數(shù)據(jù)中心1的服務器管理員通過vCenter

將app.h3c.com 對應的虛擬機遷往數(shù)據(jù)中心2后，新上線用戶B 的流量路徑說明。

○ 步驟1：VMware vCenter 支持“基于事件觸發(fā)的腳

圖8 虛機遷移后新上線用戶的流量示意

了變化。

○ 步驟2：新上線的用戶B 希望訪問app.h3c.com ，其客戶

本技術”，用戶可以給vCenter 上發(fā)生的多種類型的事件（Event ）定義執(zhí)行腳本（TCL/TK）。在本方案中，數(shù)據(jù)中心1的服務器管理員已經為app.h3c.com 對應虛擬機從數(shù)據(jù)中心1到數(shù)據(jù)中心2的動態(tài)遷移事件定義了一個執(zhí)行腳本——“Telnet 到GSLB

上，將app.h3c.com 的DNS 解析改為VIP-2”。而修改之前，GSLB 上是將app.h3c.com 域名解析為VIP-1。因此，當app.h3c.com 對應虛機成功遷移到數(shù)據(jù)中心2時，GSLB 上對app.h3c.com 域名的解析也發(fā)生

端向本地配置的DNS 服務器發(fā)起查詢請求，通過一系列迭代查詢，最終由作為權威DNS 服務器的GSLB 返回查詢結果，app.h3c.com 對應的地址是數(shù)據(jù)中心2中的SLB2上配置的VIP_2

○ 步驟3、步驟4、步驟5、步驟6的過程與上文介紹的用

戶A 第一次訪問數(shù)據(jù)中心1時的流程相同。

6

服務器負載均衡與HA

技術

為了滿足高性能和高可靠性的服務需求，將多臺服務器通過網絡設備相連組成一個服務器集群，每臺服務器都提供相同或相似的網絡服務。服務器集群前端部署一臺SLB[2] 設備，負責根據(jù)已配置的均衡策略將用戶請求在服務器集群中分發(fā)，為用戶提供服務，并對服務器可用性進行維護。

服務器負載均衡可以工作在L4或L7模式下，一般采用L4模式。負載均衡的工作方式有以下兩種。

○ DR （Direct Routing）方式。（如圖9所示）負載均衡

○ NAT 方式。（如圖10所示）組網更加靈活，后端服務

器可以位于不同的物理位置或不同的局域網內?？蛻舳藢l(fā)往VSIP 的請求發(fā)送至服務器群前端的負載均衡設備，負載均衡設備上的虛服務接收客戶端請求，根據(jù)持續(xù)性功能、調度算法依次選擇真實服務器，再通過網絡地址轉換，用真實服務器地址重寫請求報文的目標地址后，將請求發(fā)送給選定的真實服務器；真實服務器的響應報文通過負載均衡設備時，報文的源地址被還原為虛服務的VSIP ，再返回給客戶，完成整個負載調度過程。

設備對數(shù)據(jù)流量優(yōu)化時，采用旁掛方式部署，在此模式下只有客戶端的請求報文通過負載均衡設備，服務器的響應報文不經過負載均衡設備，從而減輕負載，有效的避免了其成為網絡瓶頸。客戶端請求報文的目的地址為虛服務地址（VSIP ），此地址由負載均衡設備對外呈現(xiàn)。負載均衡設備分發(fā)服務請求時，不改變目的IP 地址，而將報文的目的MAC 替換為實服務的MAC 后直接把報文轉發(fā)給實服務。

圖10 NAT 方式的服務器負載均衡

一般情況下，SLB 更加適合在一個數(shù)據(jù)中心內部部署，而不是跨數(shù)據(jù)中心部署。因為當SLB 跨數(shù)據(jù)中心部署時，會導致跨中心的廣域/城域鏈路承載流量多，而且跨中心轉發(fā)一般延遲高，流量路徑復雜低效，不利于實現(xiàn)高性能的負載均衡集群（如圖11所示）。而GSLB 更加適合實現(xiàn)跨數(shù)據(jù)中心的

圖9 DR方式的服務器負載均衡負載均衡，所以GSLB 和SLB

配合能夠很好的實現(xiàn)從數(shù)據(jù)中心

7

前端到數(shù)據(jù)中心內部全路徑的負載均衡，以及更好的實現(xiàn)服務器健康狀態(tài)檢測（如圖12所示），主要包括：

○ GSLB 可針對SLB 、服務器做狀態(tài)監(jiān)測，可消除單點故

技術特點是：

○ 需要共享存儲資源（磁盤卷或是復制卷），HA 集群可

在同城或較近距離內部署；

○ 對客戶端來說，集群只有一個IP 地址，由Active 節(jié)點響

障，并引導流量避開性能較低的站點和服務器；

○ 通過收集這些設備的性能測量數(shù)據(jù)，GSLB 可了解網絡

應ARP ；

○ 需要一個獨立的網絡做節(jié)點之間的進程通信（心跳）；○ 心跳網絡對傳輸延遲不敏感（如微軟MSCS 要求的最

狀態(tài)，對包速率、每秒千字節(jié)、磁盤、內存、CPU 利用率以及連接數(shù)量等參數(shù)進行測量。

小心跳間隔是1秒），因此兩節(jié)點間的傳輸延遲小于500ms 即可；

○ 因為對外只有一個虛IP 地址，所有節(jié)點需在一個網段

（二層互聯(lián)）；

雙節(jié)點的高可用性集群典型的工作方式有以下兩種。主/主( Active/Active) 。集群中兩節(jié)點同時運行各自的應用并且相互監(jiān)控對方的情況， 當一臺主機宕機后，預先設定好的另一臺主機立即接管它的一切工作。這種工作方式允許最大程度的利用硬件資源，一般要求各節(jié)點具有相等或相似的處理能力，所有的服務在故障轉移后仍保持可用。

主/從( Active /Standby) 。主機工作，從機處于監(jiān)控準

圖11 SLB跨中心部署

備狀況。當主機宕機后，從機接管主機的一切工作，繼續(xù)為客戶機提供服務，待主機恢復正常后，用戶可以自行設定以自動或手動方式將服務從Standby 上切換到Active 上，也可不切換。

表1 常見的HA CLUSTER 產品

SLB IP

SLB IP

SLB IP

延時對服務器集群部署的影響

與傳統(tǒng)IP 網絡應用能夠容忍較大的網絡傳輸延時不同，存儲網絡對傳輸延時非常敏感。由于服務器集群成員

圖12 GSLB和SLB 配合實現(xiàn)服務器健康狀態(tài)檢測服務器HA 技術

高可用性集群（High Availability Cluster，HA Cluster）是以減少服務器中斷時間為目的實現(xiàn)故障屏蔽的服務器集群技術，主要包括可靠性和容錯性兩方面。在這種高可用集群環(huán)境下，若某臺服務器出現(xiàn)故障導致服務中斷，預先設定的接管服務器會自動接管相關應用并繼續(xù)對用戶提供服務，具有更高的可用性、可管理性和更優(yōu)異的可伸縮性。HA Clusters是可用于“熱備模式容災”的集群技術（如表1所示），其

一般是共享存儲，所以必須考慮存儲延時對服務器集群部署的影響。

以通信線路SDH 155M鏈路（其中50M 用于存儲業(yè)務）為例，經過測算：光纖距離為50KM （典型的同城距離）時的單向延時為1.51 ms，正常存儲系統(tǒng)能夠接受；光纖距離為1000KM （典型的異地距離）時的單向延時為7.26 ms，將導致共享存儲部署時服務器應用能力急劇下降到不可接受的程度?？梢?，距離因素對傳輸延時的影響巨大。

因此在“兩地三中心”數(shù)據(jù)中心災備方案中，遠距離

8

的異地范圍要部署采用異步復制的暖備災備方案（如圖13所示），即采用廣域鏈路如SDH 、ATM 或IP 相連，通過存儲異步復制方式實現(xiàn)災備功能；同城范圍內則可以部署基于共享存儲的服務器HA 方案（如圖14所示），即兩個中心之間用

裸光纖、波分或SDH 項鏈，通過存儲同步復制方式部署HA Cluster ，在這種部署環(huán)境下，主備中心之間需要二層互聯(lián)以滿足集群成員之間二層通信需求，同時還需要SAN 互聯(lián)以實

現(xiàn)數(shù)據(jù)同步復制。

圖13 三站容災方案的網絡圖14 適用于同城容災的HA Cluste 工作方式

9

400-810-0504杭州華三通信技術有限公司 杭州基地

杭州市高新技術產業(yè)開發(fā)區(qū)之江科技工業(yè)園六和路310號

郵編：310053

電話：0571-86760000

傳真：0571-86760001

北京分部

北京市宣武門外大街10號莊勝廣場中央辦公樓南翼16層

郵編：100052

電話：010-63108666

傳真：010-63108777客戶服務熱線

Copyright ?2013杭州華三通信技術有限公司 保留一切權利

免責聲明：雖然H3C試圖在本資料中提供準確的信息，但不保證資料的內容不含有技術性誤差或印刷性錯誤，為此H3C對本資料中信息的不準確性不承擔任何責任。H3C保留在沒有任何通知或提示的情況下對本資料的內容進行修改的權利。