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

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

前言

2

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

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

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

○ 基于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è)計(jì)完全一樣，所以也面臨同樣的設(shè)計(jì)及運(yùn)維問(wèn)題。

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

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

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

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

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

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

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

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

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

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

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

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

3

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

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

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

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

換），報(bào)文的源IP 被改為SLB1的接口地址IP-1地址，目的地址被改為虛機(jī)的真實(shí)地址VM-IP 。

○ 步驟4：虛機(jī)到用戶A 的回程報(bào)文的源IP 是VM-IP ，目

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

○ 步驟5：SLB1查會(huì)話表，將該IP 報(bào)文的源地址改為VIP-

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

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

圖7 虛擬機(jī)遷移后已上線用戶流量

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

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

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

來(lái)的防火墻）。

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

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

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

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

○ 步驟1：某用戶A 希望訪問(wèn)app.h3c.com ，其客戶機(jī)向本

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

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

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

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

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

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

5

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

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

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

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

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

了變化。

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

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

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

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

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

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

6

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

技術(shù)

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

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

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

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

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

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

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

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

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

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

7

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

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

技術(shù)特點(diǎn)是：

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

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

○ 對(duì)客戶端來(lái)說(shuō)，集群只有一個(gè)IP 地址，由Active 節(jié)點(diǎn)響

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

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

應(yīng)ARP ；

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

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

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

○ 因?yàn)閷?duì)外只有一個(gè)虛IP 地址，所有節(jié)點(diǎn)需在一個(gè)網(wǎng)段

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

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

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

圖11 SLB跨中心部署

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

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

SLB IP

SLB IP

SLB IP

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

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

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

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

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

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

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

8

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

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

現(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è)開(kāi)發(fā)區(qū)之江科技工業(yè)園六和路310號(hào)

郵編：310053

電話：0571-86760000

傳真：0571-86760001

北京分部

北京市宣武門(mén)外大街10號(hào)莊勝?gòu)V場(chǎng)中央辦公樓南翼16層

郵編：100052

電話：010-63108666

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

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

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