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

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

前言

2

分布式雙活數(shù)據(jù)中心大二層網(wǎng)絡(luò)設(shè)計

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

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

○ 基于IP 網(wǎng)絡(luò)的VLL Over GRE或VPLS Over GRE方案與

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

H3C 新一代大二層網(wǎng)絡(luò)設(shè)計

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

圖2 雙活數(shù)據(jù)中心大二層網(wǎng)絡(luò)

傳統(tǒng)大二層網(wǎng)絡(luò)設(shè)計所面臨的問題

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

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

圖3 EVI典型組網(wǎng)

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

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

○ 基于MPLS 網(wǎng)絡(luò)的VLL 或VPLS 技術(shù)，要求承載網(wǎng)為

MPLS 網(wǎng)絡(luò)，其中MPLS

網(wǎng)絡(luò)可以自建也可以是運營商提供，

3

基于DNS 發(fā)布業(yè)務(wù)的前端網(wǎng)絡(luò)雙活設(shè)計

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

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

○ 步驟3：SLB1設(shè)備對用戶A 的流量做NAT （地址轉(zhuǎn)

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

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

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

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

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

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

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

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

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

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

來的防火墻）。

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

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

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

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

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

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

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

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

○ 步驟2：用戶A 發(fā)起的流量經(jīng)過核心廣域網(wǎng)的轉(zhuǎn)發(fā)來到

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

聚設(shè)備采用了網(wǎng)關(guān)分離部署方式，所以虛機到用戶A 的回程

5

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

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

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

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

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

了變化。

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

本技術(shù)”，用戶可以給vCenter 上發(fā)生的多種類型的事件（Event ）定義執(zhí)行腳本（TCL/TK）。在本方案中，數(shù)據(jù)中心1的服務(wù)器管理員已經(jīng)為app.h3c.com 對應(yīng)虛擬機從數(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 對應(yīng)虛機成功遷移到數(shù)據(jù)中心2時，GSLB 上對app.h3c.com 域名的解析也發(fā)生

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

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

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

6

服務(wù)器負載均衡與HA

技術(shù)

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

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

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

○ NAT 方式。（如圖10所示）組網(wǎng)更加靈活，后端服務(wù)

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

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

圖10 NAT 方式的服務(wù)器負載均衡

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

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

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

7

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

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

技術(shù)特點是：

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

在同城或較近距離內(nèi)部署；

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

障，并引導(dǎo)流量避開性能較低的站點和服務(wù)器；

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

應(yīng)ARP ；

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

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

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

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

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

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

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

圖11 SLB跨中心部署

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

表1 常見的HA CLUSTER 產(chǎn)品

SLB IP

SLB IP

SLB IP

延時對服務(wù)器集群部署的影響

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

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

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

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

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

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

8

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

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

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

圖13 三站容災(zāi)方案的網(wǎng)絡(luò)圖14 適用于同城容災(zāi)的HA Cluste 工作方式

9

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

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

郵編：310053

電話：0571-86760000

傳真：0571-86760001

北京分部

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

郵編：100052

電話：010-63108666

傳真：010-63108777客戶服務(wù)熱線

Copyright ?2013杭州華三通信技術(shù)有限公司 保留一切權(quán)利

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