分布式雙活數據中心解決方案

2017-03-27

14676

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

杭州華三分布式雙活數據中心解決方案

前言

分布式雙活數據中心大二層網絡設計

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

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

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

基于MPLS 網絡的VLL 或VPLS 技術的區別僅僅是承載網變為IP 網絡，其他設計完全一樣，所以也面臨同樣的設計及運維問題。

H3C 新一代大二層網絡設計

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

圖2 雙活數據中心大二層網絡

傳統大二層網絡設計所面臨的問題

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

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

圖3 EVI典型組網

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

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

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

MPLS 網絡，其中MPLS

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

基于DNS 發布業務的前端網絡雙活設計

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

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

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

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

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

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

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

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

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

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

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

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

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

來的防火墻）。

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

○ 步驟2：SLB1上經過NAT 處理后的報文被轉發至數據

圖6 基于DNS 發布業務雙活方案

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

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

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

○ 步驟3：由于數據中心1的匯聚設備與數據中心2的匯

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

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

數據中心1的SLB 主設備上。

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

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

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

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

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

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

了變化。

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

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

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

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

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

戶A 第一次訪問數據中心1時的流程相同。

服務器負載均衡與HA

技術

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

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

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

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

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

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

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

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

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

配合能夠很好的實現從數據中心

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

○ GSLB 可針對SLB 、服務器做狀態監測，可消除單點故

技術特點是：

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

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

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

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

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

應ARP ；

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

狀態，對包速率、每秒千字節、磁盤、內存、CPU 利用率以及連接數量等參數進行測量。

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

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

（二層互聯）；

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

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

圖11 SLB跨中心部署

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

表1 常見的HA CLUSTER 產品

SLB IP

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

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

圖12 GSLB和SLB 配合實現服務器健康狀態檢測服務器HA 技術

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

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

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

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