同城應(yīng)用容災(zāi)系統(tǒng)方案

1、同同城城應(yīng)應(yīng)用用容容災(zāi)災(zāi)系系統(tǒng)統(tǒng)方方案案 目目 錄錄 同城應(yīng)用容災(zāi)系統(tǒng)方案同城應(yīng)用容災(zāi)系統(tǒng)方案.1 目目 錄錄.2 一、容災(zāi)系統(tǒng)需求一、容災(zāi)系統(tǒng)需求.4 二、容災(zāi)技術(shù)的選擇二、容災(zāi)技術(shù)的選擇.5 2.1 基于 SAN 城域網(wǎng)的鏡像技術(shù).5 2.2 構(gòu)建容災(zāi)系統(tǒng)的技術(shù)要求.7 三、容災(zāi)系統(tǒng)建議解決方案拓?fù)鋱D和配置說明三、容災(zāi)系統(tǒng)建議解決方案拓?fù)鋱D和配置說明.8 四、四、VERITAS 基于鏡像技術(shù)的容災(zāi)方案及其實現(xiàn)基于鏡像技術(shù)的容災(zāi)方案及其實現(xiàn).9 4.1、數(shù)據(jù)容災(zāi)方案的實現(xiàn).9 4.1.1方案的結(jié)構(gòu)原理.9 4.1.2數(shù)據(jù)系統(tǒng)故障和災(zāi)難的響應(yīng).11 4.1.3方案的技術(shù)優(yōu)勢.15 4.1.4對

2、系統(tǒng)性能的影響.18 4.1.5容災(zāi)案例.19 4.2、構(gòu)建完整的應(yīng)用級災(zāi)備中心.20 4.2.1純手工應(yīng)用災(zāi)備的問題.20 4.2.2建立覆蓋災(zāi)備中心的統(tǒng)一集群體系.22 4.2.3跨越幾十公里的心跳技術(shù)支持.23 4.2.4為什么需要人工確認(rèn)災(zāi)難.24 4.2.5建立一個滿足災(zāi)備需要的集群系統(tǒng).25 4.2.6業(yè)務(wù)系統(tǒng)故障和災(zāi)難的響應(yīng).26 4.2.7方案的優(yōu)勢.30 五、五、VERITAS CLUSTER SERVER 簡介簡介.31 5.1 業(yè)界領(lǐng)先的高可用應(yīng)用解決方案.31 5.2VERITAS CLUSTER SERVER產(chǎn)品要點.31 5.3VERITAS CLUSTER SER

3、VER的先進(jìn)性.33 5.4VERITAS CLUSTER的特點和好處.35 六、六、STORAGE FOUNDATION FOR ORACLE RAC 概述概述.37 6.1Veritas Storage Foundation for Oracle RAC概述.37 6.2雙磁盤陣列實現(xiàn)RAC系統(tǒng)存儲支持案例.41 一一、容容災(zāi)災(zāi)系系統(tǒng)統(tǒng)需需求求 ( (在在此此插插入入用用戶戶情情況況介介紹紹) ) IT 系統(tǒng)是職能正常運轉(zhuǎn)的重要支撐?？紤]到IT 系統(tǒng)的重要性，為了保 證 IT 系統(tǒng)的正常運轉(zhuǎn)，保證和提高的服務(wù)能力，準(zhǔn)備建立現(xiàn)有IT 核心業(yè) 務(wù)系統(tǒng)的應(yīng)用容災(zāi)系統(tǒng)。 目前，的核心業(yè)務(wù)系統(tǒng)主要為

4、數(shù)據(jù)庫系統(tǒng)為Oracle ，運行在兩臺小型 機系統(tǒng)上?？紤]到核心數(shù)據(jù)庫系統(tǒng)的安全和可靠，準(zhǔn)備在同城建立現(xiàn)有數(shù)據(jù)庫 系統(tǒng)的數(shù)據(jù)容災(zāi)系統(tǒng)，并可以簡單地實現(xiàn) 生產(chǎn)系統(tǒng)的應(yīng)用級容災(zāi)。 二二、容容災(zāi)災(zāi)技技術(shù)術(shù)的的選選擇擇 2.1 基于 SAN 城域網(wǎng)的鏡像技術(shù) 目前實現(xiàn)容災(zāi)的技術(shù)方案看起來很多，不過目前比較通用的和實用的容災(zāi)技術(shù)，主要有兩類， 一種是基于主機的容災(zāi)方案，一種是基于磁盤系統(tǒng)的數(shù)據(jù)復(fù)制的容災(zāi)方案。 而隨著光纖存儲網(wǎng)絡(luò)技術(shù)的成熟和在距離上的拓展，光纖城域存儲網(wǎng)絡(luò)的實現(xiàn)已經(jīng)趨于成熟， 這就使得我們今天可以不再需要依賴復(fù)雜的數(shù)據(jù)復(fù)制技術(shù)，就可以實現(xiàn)同城容災(zāi)了。新的容災(zāi)方案 所利用的，是最為傳統(tǒng)的磁

5、盤鏡像技術(shù)，也就是說我們可以利用基于城域 SAN 存儲網(wǎng)上的鏡像技術(shù)， 輕松實現(xiàn)數(shù)據(jù)容災(zāi)，然后在此基礎(chǔ)上，我們可以利用先進(jìn)的集群軟件，構(gòu)建應(yīng)用級的容災(zāi)系統(tǒng)，以 滿足對容災(zāi)的需要。 為什么我們建議選擇基于鏡像技術(shù)的容災(zāi)方案？為什么我們建議選擇基于鏡像技術(shù)的容災(zāi)方案？ 成熟性：鏡像技術(shù)是從磁盤容錯技術(shù)中最成熟、歷史最悠久、可靠性最高的數(shù)據(jù)保護技術(shù)。 簡單性：鏡像技術(shù)是實現(xiàn)最為簡單的數(shù)據(jù)容錯技術(shù) 異構(gòu)性：鏡像技術(shù)不僅可以在磁盤陣列內(nèi)部實現(xiàn)，也可以跨越不同磁盤系統(tǒng)來實現(xiàn)，鏡像 技術(shù)完全不依賴于磁盤系統(tǒng)的品牌和型號。所以，利用鏡像技術(shù)實現(xiàn)容災(zāi)，我們就可以保 留在任何時候自由、靈活的選擇磁盤系統(tǒng)的權(quán)利。

6、為什么以前比較少用鏡像做容災(zāi)，而用復(fù)制做容災(zāi)？為什么以前比較少用鏡像做容災(zāi)，而用復(fù)制做容災(zāi)？ 在 SCSI 技術(shù)時代，SCSI 只能支持 25 米的距離，所以雖然基于磁盤系統(tǒng)間的鏡像被廣泛 采用，但無法實現(xiàn)遠(yuǎn)距離容災(zāi) 遠(yuǎn)程復(fù)制技術(shù)可以很好的解決遠(yuǎn)距離和低帶寬帶來的問題，所以一直以來，是容災(zāi)方案的 主要選擇。 FC 光纖存儲出現(xiàn)以后，為遠(yuǎn)距離鏡像提供了可能，隨著同城光纖存儲網(wǎng)絡(luò)的普及，利用 鏡像技術(shù)構(gòu)建同城容災(zāi)系統(tǒng)，將是一個即簡單、又實用的容災(zāi)解決方案。 為什么現(xiàn)在不建議采用基于磁盤系統(tǒng)的復(fù)制來構(gòu)建容災(zāi)系統(tǒng)？為什么現(xiàn)在不建議采用基于磁盤系統(tǒng)的復(fù)制來構(gòu)建容災(zāi)系統(tǒng)？ 數(shù)據(jù)復(fù)制技術(shù)所能解決的距離和帶寬

7、的問題，當(dāng)前已經(jīng)不再是問題了 利用數(shù)據(jù)復(fù)制技術(shù)實現(xiàn)容災(zāi)，由于其技術(shù)本身的局限性，必然導(dǎo)致容災(zāi)系統(tǒng)的結(jié)構(gòu)要比沒 有容災(zāi)系統(tǒng)的時候復(fù)雜得多。 同時，這樣的容災(zāi)系統(tǒng)的故障環(huán)節(jié)不可避免的會增加，導(dǎo)致維護難度、維護成本的增加。 基于磁盤系統(tǒng)的數(shù)據(jù)復(fù)制技術(shù)，要求生產(chǎn)中心和災(zāi)備中心選用同一個廠商的磁盤系統(tǒng)，甚 至要求選用同一系列、同一型號的磁盤系統(tǒng)，用戶完全失去討價還價的余地，完全失去了 在任何時候自由、靈活地選擇合作廠商和磁盤系統(tǒng)的權(quán)利，必然給用戶造成被動和經(jīng)濟上 的損失。 總上所述，針對的容災(zāi)系統(tǒng)建設(shè)，我們認(rèn)為，既然我們可以提供基于光纖的城域 SAN 網(wǎng)絡(luò)，那么， 我們就沒有必要再采用過時的基于磁盤系統(tǒng)

8、數(shù)據(jù)復(fù)制的容災(zāi)方案，采用基于主機鏡像技術(shù)來實現(xiàn)容 災(zāi)方案，應(yīng)該是一個更好的選擇。 2.2 構(gòu)建容災(zāi)系統(tǒng)的技術(shù)要求 基于磁盤鏡像技術(shù)構(gòu)建容災(zāi)系統(tǒng)，在數(shù)據(jù)系統(tǒng)容錯實現(xiàn)的邏輯上，和本地磁盤系統(tǒng)間的鏡像沒 有任何區(qū)別，所以我們大可以放心的去構(gòu)建這樣的系統(tǒng)。 但是，在實際應(yīng)用環(huán)境中，我們還是發(fā)現(xiàn)了一個不同的地方，是我們在考慮容災(zāi)方案的時候必 須解決的，那就是“距離” 。不是說我們已經(jīng)解決了距離的問題嗎？是的，我們在技術(shù)上已經(jīng)解決 了遠(yuǎn)距離數(shù)據(jù)鏡像的問題，但是，有幾個問題是任何技術(shù)都必須考慮的，不管是鏡像技術(shù)還是復(fù)制 技術(shù)，包括： 距離決定了鏈路的可靠性。距離決定了鏈路的可靠性。 我們在短距離（比如一個機

9、房內(nèi)）可以忽略不計的鏈路故障（可以通過鏈路冗余解決）在長距 離上就無法忽略了，比如，我們無法保證我們的光纖不會被野蠻施工挖斷。 距離會影響我們管理一個系統(tǒng)的復(fù)雜性和現(xiàn)場感距離會影響我們管理一個系統(tǒng)的復(fù)雜性和現(xiàn)場感 遠(yuǎn)距離災(zāi)備系統(tǒng)永遠(yuǎn)都是生產(chǎn)中心的附屬品，如果我們不能將其用直觀的方式納入到日常的管 理體系中，很快我們就會發(fā)現(xiàn)我們對生產(chǎn)系統(tǒng)和災(zāi)備系統(tǒng)的管理會脫節(jié)，所以，容災(zāi)系統(tǒng)肯定不僅 僅是鏡像那么簡單，他需要一個完整的、直觀的管理界面去管理，才能形成一個行之有效有的災(zāi)備 系統(tǒng)。 所以，我們在構(gòu)建容災(zāi)系統(tǒng)的時候，必須考慮由距離引起的問題給我們的技術(shù)方案造成的各種 負(fù)面影響，并要很好的解決它。有關(guān)問

10、題和解決方法，我們會在下一節(jié)中詳細(xì)論述，這里我們先簡 單的把要求提出來，供參考。 對磁盤鏡像容災(zāi)管理的要求：可視化磁盤管理和容災(zāi)管理 應(yīng)對鏈路故障引起的各種問題：實現(xiàn)增量鏡像和避免 Split-Brain 等 三三、容容災(zāi)災(zāi)系系統(tǒng)統(tǒng)建建議議解解決決方方案案拓拓?fù)鋼鋱D圖和和配配置置說說明明 配置：Veritas Storage Foundation Enterprise HA/DR for Oracle RAC *4 說明：Veritas Storage Foundation Enterprise HA/DR for ORACLE RAC 可以實現(xiàn)本地數(shù)據(jù)和異 地數(shù)據(jù)的卷級鏡像，實現(xiàn)數(shù)據(jù)的快速同

11、步，并可以實現(xiàn) ORACLE 數(shù)據(jù)庫安裝在文件系統(tǒng)上而且具有 裸設(shè)備的性能。同時 Veritas 高速文件系統(tǒng)也能提高數(shù)據(jù)訪問和讀寫的性能。該 license 中包括 的 Veritas Cluster server 可以實現(xiàn) ORACLE 數(shù)據(jù)庫的切換，并和應(yīng)用服務(wù)器相結(jié)合實現(xiàn)應(yīng)用級容 災(zāi)。每臺服務(wù)器需要配置 1 個 LICENSE. 四四、V VE ER RI IT TA AS S 基基于于鏡鏡像像技技術(shù)術(shù)的的容容災(zāi)災(zāi)方方案案及及其其實實現(xiàn)現(xiàn) 基于鏡像技術(shù)實現(xiàn)容災(zāi)，從技術(shù)實現(xiàn)上，分為兩個部分，其一是數(shù)據(jù)的容災(zāi)實現(xiàn)，其二是應(yīng)用 級容災(zāi)實現(xiàn)。下面，我們就分別從這兩個方面入手，論述 VERITA

12、S 的容災(zāi)方案。 4.1、數(shù)數(shù)據(jù)據(jù)容容災(zāi)災(zāi)方方案案的的實實現(xiàn)現(xiàn) 4 4. .1 1. .1 1 方方案案的的結(jié)結(jié)構(gòu)構(gòu)原原理理 VERITAS 建議利用 VERITAS Volume Manager 軟件的鏡像技術(shù)，來構(gòu)建 IT 系統(tǒng)的容災(zāi)方案。利 用 VERITAS Volume Manager 的鏡像技術(shù)構(gòu)建容災(zāi)系統(tǒng)是非常簡單的，它只有一個條件，就是將生 產(chǎn)中心和災(zāi)備中心之間的 SAN 存儲區(qū)域網(wǎng)絡(luò)通過光纖連接起來，建立城域 SAN 存儲網(wǎng)絡(luò)。然后，我 們就可以通過 Volume Manager 提供的非常成熟的跨陣列磁盤鏡像技術(shù)來實現(xiàn)同城容災(zāi)了，容災(zāi)方 案的結(jié)構(gòu)如下圖所示： 從原理上講，在

13、城域 SAN 存儲網(wǎng)絡(luò)上的兩套磁盤系統(tǒng)之間的鏡像，和在一個機房內(nèi)的 SAN 上的 兩個磁盤系統(tǒng)之間的鏡像并沒有任何區(qū)別。就如上圖，如果我們把“同城容災(zāi)中心”幾個字去掉， 我們就無法分辨左邊的系統(tǒng)和右邊的系統(tǒng)到底是在同一個機房，還是遠(yuǎn)在幾十公里以外。 利用光纖將生產(chǎn)中心和災(zāi)備中心的 SAN 網(wǎng)絡(luò)連接起來，構(gòu)成城域 SAN 網(wǎng)絡(luò)以后，利用 VERITAS Volume Manager 的先進(jìn)的邏輯卷管理功能，我們就可以非常方便的實現(xiàn)生產(chǎn)中心磁盤系統(tǒng)和災(zāi)備 中心磁盤系統(tǒng)之間的鏡像了。如下圖所示。這里，邏輯卷“Volume A”是業(yè)務(wù)系統(tǒng)訪問磁盤的邏輯 設(shè)備名，在 VERITAS Volume Man

14、ager 管理下的磁盤系統(tǒng)，所有業(yè)務(wù)系統(tǒng)對磁盤系統(tǒng)的訪問，都將 通過 Volume 實現(xiàn)。 我們可以看到，利用 VERITAS Volume Manager，我們可以創(chuàng)建任意一個邏輯卷（Volume）供 業(yè)務(wù)主機使用，比如“Volume A” ，這個“Volume A”實際上是由兩個完全對等的，容量和 “Volume A”相同的磁盤片構(gòu)成的，我們這里可以稱在生產(chǎn)中心磁盤系統(tǒng)上的磁盤片為“Volume A : Plex 1” ，而稱在災(zāi)備中心磁盤系統(tǒng)上的磁盤片為“Volume A : Plex 2” ，這兩個磁盤片上的數(shù)據(jù) 完全一樣，業(yè)務(wù)主機對該 Volume 的任意修改，都將同時被寫到位于生產(chǎn)

15、中心和災(zāi)備中心的兩個磁 盤系統(tǒng)上。 采用這種方式，生產(chǎn)中心的磁盤陣列與同城容災(zāi)中心的磁盤陣列對于兩地的主機而言是完全同等的。 利用城域 SAN 存儲網(wǎng)絡(luò)和 VERITAS Volume Manager 鏡像功能，我們可以非常輕松的實現(xiàn)數(shù)據(jù)系統(tǒng) 的異地容災(zāi)。 下面，我們來看一下，在各種數(shù)據(jù)系統(tǒng)（本節(jié)暫時不討論應(yīng)用系統(tǒng)全面災(zāi)難的應(yīng)對，我們把它 放到下一節(jié)中另行展開討論）故障和災(zāi)難情況下，容災(zāi)系統(tǒng)是怎樣響應(yīng)的。 4.1.2 數(shù)數(shù)據(jù)據(jù)系系統(tǒng)統(tǒng)故故障障和和災(zāi)災(zāi)難難的的響響應(yīng)應(yīng) 在建立了容災(zāi)系統(tǒng)以后，數(shù)據(jù)系統(tǒng)的故障和災(zāi)難主要將發(fā)生在 3 個地方（請注意，沒有建立容 災(zāi)系統(tǒng)時，數(shù)據(jù)系統(tǒng)的主要故障點是 1 個

16、）： 1)生產(chǎn)中心數(shù)據(jù)系統(tǒng)故障生產(chǎn)中心數(shù)據(jù)系統(tǒng)故障 生產(chǎn)中心數(shù)據(jù)系統(tǒng)故障意味著災(zāi)難，這也就是我們現(xiàn)在建立容災(zāi)系統(tǒng)的根本目的，對于這樣的 災(zāi)難，我們來看一下我們推薦的容災(zāi)方案是如何響應(yīng)的，見下圖： 當(dāng)生產(chǎn)中心的磁盤系統(tǒng)發(fā)生故障（災(zāi)難）時，由于同城容災(zāi)中心的磁盤是它的鏡像，所以操作 系統(tǒng)會自動隔離生產(chǎn)中心的磁盤，轉(zhuǎn)而對容災(zāi)中心的數(shù)據(jù)進(jìn)行訪問。從上圖我們看到，業(yè)務(wù)系統(tǒng)可 以通過城域 SAN 網(wǎng)絡(luò)直接訪問災(zāi)備中心的磁盤系統(tǒng)的數(shù)據(jù)，而不需要有任何針對業(yè)務(wù)系統(tǒng)的動作。 也就是說，生產(chǎn)中心磁盤系統(tǒng)的災(zāi)難，對業(yè)務(wù)系統(tǒng)是透明的，應(yīng)用和數(shù)據(jù)庫不會因為生產(chǎn)中心磁盤 系統(tǒng)的故障而停止；更重要的是，因為應(yīng)用和數(shù)據(jù)庫不會

17、因為災(zāi)難而異常中止，從而避免了發(fā)生數(shù) 據(jù)庫損壞的可能。 生產(chǎn)中心磁盤系統(tǒng)故障之后，我們只需要更換損壞的磁盤系統(tǒng)，然后利用 Volume Manager 重 新生成鏡像即可，重新生成鏡像的過程，實際上就是將數(shù)據(jù)從災(zāi)備中心磁盤系統(tǒng)復(fù)制到生產(chǎn)中心磁 盤系統(tǒng)的過程。 值得注意的是：整個過程對應(yīng)用完全透明，不需要也不會中斷業(yè)務(wù)系統(tǒng)的正常運行。這是基于 磁盤系統(tǒng)間復(fù)制技術(shù)構(gòu)建的容災(zāi)系統(tǒng)無法實現(xiàn)的。 災(zāi)備中心數(shù)據(jù)系統(tǒng)故障災(zāi)備中心數(shù)據(jù)系統(tǒng)故障 災(zāi)備中心數(shù)據(jù)系統(tǒng)故障，這是災(zāi)備系統(tǒng)建立以后出現(xiàn)的新問題，這種故障就同上一種故障類似， 但對業(yè)務(wù)系統(tǒng)的影響更小。 生產(chǎn)中心和災(zāi)備中心生產(chǎn)中心和災(zāi)備中心 SAN 鏈路故障鏈

18、路故障 這種故障也是災(zāi)備系統(tǒng)建立以后出現(xiàn)的新問題。相對于以上兩種災(zāi)難，這種故障在容災(zāi)系統(tǒng)建 立以后，出現(xiàn)的概率會更大一些，導(dǎo)致鏈路故障的原因很多，包括光纖斷裂，光端設(shè)備故障等，都 會導(dǎo)致鏈路中斷。這個問題其實是由“距離”引起的，正如我們在前面討論的那樣，雖然在原理上， 基于城域 SAN 網(wǎng)絡(luò)實現(xiàn)的鏡像技術(shù)和基于本地 SAN 網(wǎng)絡(luò)實現(xiàn)的鏡像技術(shù)完全一樣，但是，我們還是 不得不承認(rèn)，他們是有區(qū)別的，因為我們很少會擔(dān)心一個機房內(nèi)部不同磁盤系統(tǒng)之間的鏡像會遭遇 鏈路故障，而在城域范圍，我們是無法回避這個問題的。 一個完整的災(zāi)備系統(tǒng)，除了在數(shù)據(jù)災(zāi)難發(fā)生時，能夠完成災(zāi)備的使命，同時，也需要考慮，災(zāi) 備系統(tǒng)

19、本身的可維護性和可操作性。而對于鏈路故障，直接導(dǎo)致的就是業(yè)務(wù)數(shù)據(jù)在寫到本地磁盤系 統(tǒng)的同時，無法寫到災(zāi)備系統(tǒng)中，對于鏡像技術(shù)而言，這又成為一個新的課題。 傳統(tǒng)的鏡像技術(shù)，在鏡像鏈路被中斷以后，中斷的鏡像會被認(rèn)為完全作廢，在鏈路恢復(fù)以后， 我們不得不將數(shù)據(jù)完整地從“Volume : Plex 1”拷貝一份到“Volume : Plex 2” ，如下圖所示。 這將對業(yè)務(wù)系統(tǒng)的 I/O 性能造成不必要的影響，鏈路方面的故障如果經(jīng)常發(fā)生，我們就需要不 斷的重復(fù)將生產(chǎn)中心的數(shù)據(jù)全部同步到災(zāi)備中心的磁盤系統(tǒng)上，實際上，這種方案不具有可實施性 和可維護性，是不現(xiàn)實的。這也是什么主機廠商雖然也有類似鏡像功能，

20、但不會用于容災(zāi)的的原因。 為了解決這個問題，VERITAS Volume Manager 提供了 DCO+FMR 技術(shù)，其中 DCO（Data Change Object）是一種針對鏡像的 Log 技術(shù)，該技術(shù)允許 Volume Manager 在鏡像鏈路中斷后記錄邏輯卷 的數(shù)據(jù)變化情況，以便在鏡像鏈路恢復(fù)后，由 FMR 實現(xiàn)數(shù)據(jù)的增量恢復(fù)。所謂 FMR，其全稱是 Fast Mirror Resync，意思就是“鏡像的快速再同步” ，F(xiàn)MR 是和 DCO 技術(shù)對應(yīng)的鏡像快速恢復(fù)技術(shù)，利 用 VERITAS Volume Manager 的 DCO 和 FMR 技術(shù)，我們現(xiàn)在可以不用再擔(dān)心容災(zāi)系

21、統(tǒng)本身的可維護 性了。利用 DCO 和 FMR，針對同樣的鏈路問題，我們的應(yīng)對步驟如下： 1 SAN 鏈路發(fā)生故障 2 生產(chǎn)中心的 Volume Manager 利用 DCO 日志記錄 Volume : Plex 1 因業(yè)務(wù)數(shù)據(jù)的變化而變 化的數(shù)據(jù)塊，災(zāi)備端 Volume : Plex 2 的數(shù)據(jù)不會作廢 3 一旦 SAN 鏈路恢復(fù)正常，Volume Manager 的 FMR 功能模塊，會根據(jù) DCO 日志記錄的情況， 將 Volume : Plex 1 中鏈路中斷后更新的業(yè)務(wù)數(shù)據(jù)拷貝到災(zāi)備端 Volume : Plex 2，實現(xiàn) 增量更新。 Volume Manager 用 DCO 和 F

22、MR 技術(shù)實現(xiàn)增量同步的過程如下圖所示： 4.1.3 方方案案的的技技術(shù)術(shù)優(yōu)優(yōu)勢勢 和其他容災(zāi)方案相比，VERITAS 容災(zāi)方案具有明顯的優(yōu)勢，這些優(yōu)勢不僅僅表現(xiàn)在技術(shù)實現(xiàn)方 面，還表現(xiàn)在開放性、可維護性等各個方面。 結(jié)構(gòu)簡單結(jié)構(gòu)簡單 VERITAS 推薦的基于鏡像的容災(zāi)方案較任何一種容災(zāi)方案為簡單。在一個使用邏輯卷管理的應(yīng) 用系統(tǒng)中（邏輯卷管理的好處我想大家已經(jīng)深有體會，我想我在這里就不需要重復(fù)了） ，我們只是 利用了其中最常用、最成熟的鏡像功能，就可以實現(xiàn)容災(zāi)，而不必像其他容災(zāi)系統(tǒng)那樣增加很多不 必要的環(huán)節(jié)。 比如基于磁盤系統(tǒng)復(fù)制技術(shù)的容災(zāi)方案，我們必須在磁盤系統(tǒng)內(nèi)部專門配置相應(yīng)的接口卡，

23、使 用該磁盤系統(tǒng)專有的復(fù)制軟件，才可以構(gòu)建容災(zāi)系統(tǒng)。明顯的，該方法增加了一個在非容災(zāi)系統(tǒng)中 完全不需要的環(huán)節(jié)，不僅增加了故障源，同時也增加了維護強度。事實上，基于主機的復(fù)制技術(shù)存 在同樣的問題。 技術(shù)成熟技術(shù)成熟 鏡像技術(shù)是比任何數(shù)據(jù)復(fù)制技術(shù)更早使用于高可用系統(tǒng)的成熟的功能，這種功能已經(jīng)廣泛應(yīng)用 于包括 IBM Mainframe、AS400、RS6000、HPUX、Digital Unix、SUN Solaris、Linux、Windows 等 在內(nèi)的所有服務(wù)器系統(tǒng)上，同時也被廣泛用于磁盤系統(tǒng)內(nèi)部作為企業(yè)級解決方案，象 EMC、HDS、HP、IBM、SUN、Compaq 等眾多存儲設(shè)備生產(chǎn)廠

24、商，都將鏡像技術(shù)內(nèi)置于其磁盤系統(tǒng)內(nèi) 部，用于對數(shù)據(jù)可用性要求最高的用戶群。 存儲開放性存儲開放性 利用 VERITAS Volume Manager 的鏡像技術(shù)，我們構(gòu)建容災(zāi)方案時，不再要求生產(chǎn)系統(tǒng)和災(zāi)備系 統(tǒng)的存儲系統(tǒng)必須是同一個品牌的，對具體型號更沒有任何要求，體現(xiàn)了存儲平臺選擇的開放性。 由此，用戶可以獲得在存儲平臺選擇上的主動權(quán)，避免被存儲廠商“綁架”的尷尬。 技術(shù)的完整性技術(shù)的完整性 VERITAS Volume Manager 擁有一個容災(zāi)方案必須的所有技術(shù)特性，它不僅可以提供可靠的鏡 像技術(shù)，實現(xiàn)跨磁盤系統(tǒng)的數(shù)據(jù)容災(zāi)，同時，我們可以利用 Volume Manager 的 DCO

25、和 FMR 技術(shù)， 保證該容災(zāi)系統(tǒng)的可維護性。 容災(zāi)系統(tǒng)的可視化管理容災(zāi)系統(tǒng)的可視化管理 一個災(zāi)備系統(tǒng)和生產(chǎn)系統(tǒng)是一個整體，而不是兩個孤立的系統(tǒng)，一個系統(tǒng)的可視化管理工具， 有利于管理者將兩個系統(tǒng)有機的結(jié)合起來，而不是分別處理兩個獨立的系統(tǒng)。 VERITAS Volume Manager VEA 提供企業(yè)范圍內(nèi)全局的邏輯卷管理視圖，通過任何一臺安裝有 Volume Manager 或者其 Console 的系統(tǒng)，我們就可以訪問我們想要訪問的系統(tǒng)的（被授權(quán)）邏輯 卷，這意味著，我們可以將同一個應(yīng)用的生產(chǎn)系統(tǒng)和災(zāi)備系統(tǒng)的邏輯卷置于同一個管理視圖中，從 而實現(xiàn)對生產(chǎn)中心和災(zāi)備中心存儲的統(tǒng)一管理。VE

26、RITAS VEA 管理界面豐富，下圖為其中一個管理 界面，僅供參考。 應(yīng)對災(zāi)難，應(yīng)用不中斷，數(shù)據(jù)不丟失應(yīng)對災(zāi)難，應(yīng)用不中斷，數(shù)據(jù)不丟失 VERITAS 建議的容災(zāi)方案，不會因為生產(chǎn)中心（或者災(zāi)備中心）磁盤系統(tǒng)的故障和災(zāi)難而導(dǎo)致 應(yīng)用和數(shù)據(jù)庫的異常中止，這不僅避免了對應(yīng)用系統(tǒng)正常運作的影響，還避免了發(fā)生數(shù)據(jù)庫損壞的 可能。 相比較而言，如果采用數(shù)據(jù)復(fù)制的方式（無論是基于磁盤系統(tǒng)的硬件復(fù)制方式還是基于軟件的 數(shù)據(jù)復(fù)制方式） ，都需要在生產(chǎn)中心故障時對數(shù)據(jù)系統(tǒng)進(jìn)行切換操作，反而造成業(yè)務(wù)的停頓。另外， 由于在災(zāi)難發(fā)生時，數(shù)據(jù)庫系統(tǒng)的復(fù)制是即刻停止的，數(shù)據(jù)庫系統(tǒng)沒有經(jīng)過正常的 Shutdown，所 以

27、不僅不可避免的導(dǎo)致部分交易的損失，甚至還有可能導(dǎo)致數(shù)據(jù)庫的損壞。 I/OI/O 效率最佳效率最佳 從性能上來分析，在操作系統(tǒng)一級進(jìn)行鏡像，數(shù)據(jù)會在同一時間寫入到兩地的磁盤。數(shù)據(jù)可寫 入過程是兩組并行的操作，即本地寫和完成信號返回+異地寫和完成信號返回。 而相比較而言，數(shù)據(jù)復(fù)制技術(shù)需要通過以下 4 個步驟才算寫操作完成： 1 數(shù)據(jù)先有操作系統(tǒng)寫入本地磁盤系統(tǒng) 2 磁盤系統(tǒng)將數(shù)據(jù)通過鏈路復(fù)制到異地系統(tǒng) 3 異地磁盤系統(tǒng)完成寫操作，返回信號給本地磁盤系統(tǒng) 4 本地磁盤系統(tǒng)返回信號給操作系統(tǒng) 明顯的，這個過程和直接數(shù)據(jù)鏡像相比，把原先并行的 2 組步驟變成了純串行的 4 個步驟，并 且需要 SCSI

28、到復(fù)制協(xié)議的轉(zhuǎn)換過程，無論在流程上和反應(yīng)時間上都會比直接鏡像造成更多的延時， 對應(yīng)用系統(tǒng)有更大的影響。 另外，在邏輯卷這個層面，我們可以根據(jù)需要對鏡像的數(shù)據(jù)靈活設(shè)置，我們不需將所有磁盤進(jìn) 行鏡像，而只需鏡像必要的邏輯卷（Volume） 。這種靈活性在實際使用過程中將大大減少數(shù)據(jù)遠(yuǎn)程 復(fù)制的數(shù)量，從而避免對系統(tǒng)不必要的影響。 4.1.4 對對系系統(tǒng)統(tǒng)性性能能的的影影響響 大家都比較關(guān)心容災(zāi)系統(tǒng)建立以后對原有業(yè)務(wù)系統(tǒng)性能的影響，考察容災(zāi)系統(tǒng)對業(yè)務(wù)系統(tǒng)性能 的影響，主要從兩個方面衡量，一是 CPU 資源的消耗，二是 I/O，特別是寫操作的延遲效應(yīng)。 CPUCPU 資源消耗資源消耗 采用主機端的軟件鏡

29、像技術(shù)，對 CPU 資源的損耗，實際上是微乎其微的，但很多時候被磁盤系 統(tǒng)廠商人為的夸大了。具體的事實我們可以通過簡單的測試得到，我們可以設(shè)置這樣一個測試，就 一目了然了：1）在測試系統(tǒng)上，往一個沒有鏡像的邏輯卷 Copy 一個大文件，察看 CPU 使用率； 2）在測試系統(tǒng)上，往一個有鏡像的邏輯卷上 Copy 一個大文件，察看 CPU 使用率。 事實上，處理鏡像需要的 CPU 時間是非常非常小的，原因是磁盤 I/O 操作的速度是毫秒（ms） 級的，磁盤系統(tǒng) Cache I/O 的速度是受限于光纖通道的 100-200MB（8bit*10ns）帶寬和距離（15 公里 = 0.1ms）的，而相反的

30、，高端主機總線的寬度一般是 64-128Byte，甚至更高，主機 CPU 的 處理速度更是在千兆的水平（ns 級） ，所以 I/O 對主機 CPU 的消耗往往都是可以忽略不計的，如果 說需要關(guān)心的話，也主要針對象 RAID-5 這樣的技術(shù)（需要大量計算，從而消耗主機的 CPU 資源） ， 而像鏡像這樣的技術(shù)，是幾乎不需要消耗 CPU 時間的。 I/OI/O 的延遲效應(yīng)（特別是寫操作的延遲效應(yīng)）的延遲效應(yīng)（特別是寫操作的延遲效應(yīng)） 采用 VERITAS Volume Manager 的鏡像技術(shù)構(gòu)建容災(zāi)系統(tǒng)，其對系統(tǒng) I/O 的延遲效應(yīng)要小于任 何一種數(shù)據(jù)復(fù)制技術(shù)，不管是基于磁盤系統(tǒng)的硬件數(shù)據(jù)復(fù)制

31、技術(shù)，還是基于主機軟件的數(shù)據(jù)復(fù)制技 術(shù)，這在上一節(jié)中已經(jīng)闡述。 這里我想要補充的是在整個容災(zāi)系統(tǒng)中，對業(yè)務(wù)系統(tǒng)的性能的影響最大的不是任何一種技術(shù)所 產(chǎn)生的負(fù)面作用，而是“距離” ，正如前面提到的，在 Cache 命中率較高的系統(tǒng)中，距離對寫操作 的影響較大，這和光的傳播速度有關(guān)，光在 150 公里距離上的一個來回需要 1ms，在 15KM 距離上 一個來回需要 0.1ms，我們列出一個對照表，供大家參考。本對照表不包含設(shè)備協(xié)議轉(zhuǎn)換和光在光 纖中的折射等因素。同時，我們知道，100MB 光纖對應(yīng)的速度是 ns 級的。 距離距離光傳輸距離光傳輸距離傳輸時間傳輸時間說明說明 15 km30 km10

32、0us 同城容災(zāi)中心的距離級別同城容災(zāi)中心的距離級別 150 m300 m1us 15 m30 m100ns 一個機房的內(nèi)部距離一個機房的內(nèi)部距離 1.5 m3 m10ns 一個主板的內(nèi)部距離一個主板的內(nèi)部距離 本地 Cache 寫的時間nsus 級 本地磁盤寫的時間本地磁盤寫的時間usmsusms 級級 綜上所述，我們的結(jié)論是，只要是數(shù)據(jù)復(fù)制方式的同步方式能夠做的系統(tǒng)，采用鏡像方式也一 定能做，而且會做的更好。 4 4. .1 1. .5 5 容容災(zāi)災(zāi)案案例例 中國銀聯(lián) IT 中心的同城容災(zāi)中心項目 中國銀聯(lián)的信息中心的同城容災(zāi)中心，就是選擇了 VERITAS Volume Manager

33、的鏡像技術(shù)來構(gòu) 建的，其生產(chǎn)中心和災(zāi)備中心分別位于上海市的浦東和浦西，兩地相距超過 30 公里。 蕪湖卷煙廠信息系統(tǒng)的同城容災(zāi)項目 另外，VERITAS 擁有豐富的容災(zāi)系統(tǒng)實施經(jīng)驗，我們參與的容災(zāi)項目除了采用鏡像方式的，還 有利用傳統(tǒng)的數(shù)據(jù)復(fù)制方式構(gòu)建的容災(zāi)系統(tǒng)，包括： 中國聯(lián)通光傳輸網(wǎng)絡(luò)系統(tǒng) 中國聯(lián)通光傳輸網(wǎng)絡(luò)的容災(zāi)系統(tǒng)是由 VEITAS 通過華為提供的，這個方案是跨省際的，其中一個容 災(zāi)項目的生產(chǎn)中心和災(zāi)備中心分別在北京和廣州。VERITAS 提供的這套超遠(yuǎn)程容災(zāi)方案是國內(nèi)目前 業(yè)界唯一真正已實施的超遠(yuǎn)程容災(zāi)方案。要實現(xiàn)這種方案，我們只需要在現(xiàn)有的 Volume Manager 的基礎(chǔ)上增

34、加 VVR 模塊，體現(xiàn)了技術(shù)和方案的延續(xù)性。 上海熱線的容災(zāi)系統(tǒng) 公安部某應(yīng)用系統(tǒng)從上海到廣東南海的遠(yuǎn)程容災(zāi)項目 4 4. .2 2、構(gòu)構(gòu)建建完完整整的的應(yīng)應(yīng)用用級級災(zāi)災(zāi)備備中中心心 4.2.1 純純手手工工應(yīng)應(yīng)用用災(zāi)災(zāi)備備的的問問題題 本次需要構(gòu)建的不僅僅是數(shù)據(jù)容災(zāi)中心，我們需要構(gòu)建的是應(yīng)用級的同城災(zāi)備中心，所以除了 要考慮在災(zāi)備中心購置等量的存儲用于數(shù)據(jù)災(zāi)備以外，我們還需要購置同等處理能力的服務(wù)器系統(tǒng) 作為災(zāi)備應(yīng)用和數(shù)據(jù)庫服務(wù)器，以便在災(zāi)難發(fā)生時，能夠完整的接管整個業(yè)務(wù)系統(tǒng)，包括數(shù)據(jù)和業(yè) 務(wù)處理能力。 兩套系統(tǒng)配置難以完全同步的風(fēng)險 對兩套系統(tǒng)的管理是孤立的，而這兩套系統(tǒng)應(yīng)該是在各方面都相

35、同的并嚴(yán)格的一一對應(yīng)的。這 種局面除了導(dǎo)致管理復(fù)雜之外，同時還帶來了兩套系統(tǒng)配置不能及時同步、不能完全同步等風(fēng)險。 這種風(fēng)險將直接導(dǎo)致災(zāi)備中心在災(zāi)難發(fā)生時不能準(zhǔn)確、及時地接管業(yè)務(wù)系統(tǒng)，這和我們建立該容災(zāi) 中心的基本要求“必須保證容災(zāi)中心在一小時以內(nèi)全面接管生產(chǎn)中心的作用”是相背的。 事實上，我們在生產(chǎn)中心建立集群系統(tǒng)的時候，集群系統(tǒng)不僅給我們提供了主機故障時的業(yè)務(wù) 接管功能，同時，還給我們提供了保證業(yè)務(wù)主機和備用主機之間配置的一致性的同步資源管理功能。 一個系統(tǒng)對另外一個系統(tǒng)的順利接管，需要日常的、長期的維護和精心的準(zhǔn)備，而不是簡單的在備 用系統(tǒng)上輸入幾個命令來完成的，而集群軟件為這種需要提供

36、了行之有效的方法。 本地的主服務(wù)器和備用服務(wù)器之間尚且如此，那么生產(chǎn)中心和災(zāi)備中心之間該如何處置呢？事 實上，完全靠人工去保持生產(chǎn)中心和災(zāi)備中心這兩個不在同一個機房的系統(tǒng)的配置保持動態(tài)一致， 是一件費力費神的事情，同時還是一件費力不討好的事情。這種手工操作方式不利于災(zāi)備中心的可 靠性、穩(wěn)健性。 災(zāi)備中心接管難度大 由于在災(zāi)備中心和生產(chǎn)中心之間沒有集群系統(tǒng)，災(zāi)備中心對生產(chǎn)中心的接管將完全依賴于手工，這 無謂的加大了災(zāi)備中心接管的難度，在各種因素引起的專業(yè)技術(shù)人員不能及時到位的情況下，這種 難度將直接導(dǎo)致災(zāi)備中心不能及時的、成功的接管業(yè)務(wù)。我們知道，我們建設(shè)的是“災(zāi)難”備用系 統(tǒng)，災(zāi)難的定義不是簡

37、單的“磁盤系統(tǒng)故障” ，它可能是任何情況。所以災(zāi)備中心的接管流程要求： 1）全面，包括簡單的，也包括復(fù)雜的；2）盡量提供簡單的流程。 管理難度大 生產(chǎn)中心和災(zāi)備中心兩套系統(tǒng)完全孤立，沒有辦法同時監(jiān)控，更不用說在一個界面上對這些系統(tǒng)統(tǒng) 一監(jiān)控和管理了，我們難以同時對兩地配置進(jìn)行跟蹤和修改，無謂的增加了災(zāi)備系統(tǒng)維護的難度和 強度。 解決以上問題的辦法是：在生產(chǎn)中心和災(zāi)備中心之間構(gòu)建高可用集群系統(tǒng)。 就如同我們在一開始所講的，在城域 SAN 網(wǎng)絡(luò)上構(gòu)建的鏡像系統(tǒng)和在同一個機房內(nèi)部構(gòu)建的鏡像系 統(tǒng)在邏輯上是完全相同的，同樣的，我們要推薦的在城域 SAN 網(wǎng)絡(luò)上構(gòu)建的集群系統(tǒng)和在同一個機 房內(nèi)部構(gòu)建的集

38、群系統(tǒng)在邏輯上也是完全相同的。 城域范圍內(nèi)和鏡像技術(shù)配套的集群技術(shù)，和用于遠(yuǎn)程復(fù)制技術(shù)下構(gòu)建遠(yuǎn)程集群的技術(shù)不同，我 們這里推薦的城域范圍的集群系統(tǒng)不是傳統(tǒng)的遠(yuǎn)程集群模式，而是傳統(tǒng)的本地機群技術(shù)的擴展。實 際上，它所采用的軟件產(chǎn)品和基本技術(shù)，完全就是本地集群軟件，只是，我們需要這些集群軟件提 供必要的功能擴展，以滿足城域范圍的特定的需要。在這里，我們稱這種模式為“準(zhǔn)本地集群”模 式，也可以稱為“Campus Model” 。 “準(zhǔn)本地集群”模式實際上和大家非常熟悉的本地集群模式是一樣的，在這種模式下，生產(chǎn)中 心的系統(tǒng)和災(zāi)備中心的系統(tǒng)將被納入同一個集群主體中，從而我們可以非常輕松的實現(xiàn)對兩個中心

39、的統(tǒng)一管理。其結(jié)果，就是給我們帶來管理的簡單化和災(zāi)備系統(tǒng)的可靠性。下圖為利用 VERITAS 集 群軟件 VERITAS Cluster Server (VCS) 進(jìn)行集群管理的一個界面示意，通過該界面，我們可以知 道，利用 VCS，我們可以非常方便的管理生產(chǎn)中心和災(zāi)備中心的系統(tǒng)，并將生產(chǎn)中心和災(zāi)備中心納 入到統(tǒng)一個集群管理體系內(nèi)進(jìn)行統(tǒng)一管理。 當(dāng)然，在我們構(gòu)建這個“準(zhǔn)本地集群系統(tǒng)”的時候，我們還是要正視由“距離”引起的一切問題， 我們需要在技術(shù)層面去解決它，這也是為什么我們在方案中建議的集群軟件是和本地集群完全相同 的 VERITAS Cluster Server 軟件，但卻稱這種集群模式為

40、準(zhǔn)本地集群模式的原因。 4.2.2 建建立立覆覆蓋蓋災(zāi)災(zāi)備備中中心心的的統(tǒng)統(tǒng)一一集集群群體體系系 為了有效的管理災(zāi)備中心，同時保證在災(zāi)難發(fā)生的時候，能夠在要求的時間里快速的恢復(fù)系統(tǒng) 的正常運行，我們需要建立一個橫跨業(yè)務(wù)中心和災(zāi)備中心的“準(zhǔn)本地集群系統(tǒng)” ，這里，我們建議 采用通用的本地高可用集群軟件（也稱 HA 軟件） ，構(gòu)建的應(yīng)用容災(zāi)系統(tǒng)。 我們都非常熟悉如何利用 HA 軟件來建立集群系統(tǒng)的，目前的許多系統(tǒng)都有各種各樣的 HA 軟件， 那么是否所有的集群軟件都可以支持這種“準(zhǔn)本地集群系統(tǒng)”呢？ 答案是“NO”！ 構(gòu)建“準(zhǔn)本地集群系統(tǒng)” ，我們需要在原有的集群系統(tǒng)的功能上有新的擴展，以便滿足城

41、域環(huán) 境下的特殊要求。我們現(xiàn)在分析一下同城集群系統(tǒng)和本地集群系統(tǒng)的區(qū)別，然后再來分析需要怎樣 的技術(shù)擴展。 在磁盤鏡像結(jié)構(gòu)和集群系統(tǒng)結(jié)構(gòu)上， “城域 SAN+城域 IP 網(wǎng)絡(luò)”的環(huán)境和本地系統(tǒng)沒有什么邏 輯上的區(qū)別，但是就集群系統(tǒng)而言，僅僅是距離的變化，就會導(dǎo)致以下兩個新問題（距離對鏡像技 術(shù)的影響和相應(yīng)的方案，我們在數(shù)據(jù)容災(zāi)一節(jié)已經(jīng)詳細(xì)闡述，這里不再說明）： 1 集群系統(tǒng)的心跳線需要跨越幾十公里，而不是幾十米 2 同城生產(chǎn)中心和災(zāi)備中心的網(wǎng)絡(luò)更容易因意外而中斷，其中包括心跳線 這兩個因為距離而產(chǎn)生的新問題，需要我們在構(gòu)建集群系統(tǒng)時，不得不從技術(shù)層面仔細(xì)分析， 以便保證我們推薦的方案的可靠性和

42、可行性。下面，我們就這兩個問題從技術(shù)層面展開討論。 4.2.3 跨跨越越幾幾十十公公里里的的心心跳跳技技術(shù)術(shù)支支持持 城域集群將跨越幾十公里，這對集群心跳的技術(shù)要求非常簡單，就是要求集群軟件能夠支持跨 越幾十公里的心跳技術(shù)。 VERITAS Cluster Server 能夠很好的支持遠(yuǎn)程心跳通道，VCS 對遠(yuǎn)程心跳通道只有一個要求， 就是支持廣播。也就是說，只要兩個 Site 之間有不經(jīng)過路由器、橋這樣的設(shè)備的通道，就可以支 持 VCS 的心跳。 需要說明的是，我們這里需要心跳的動機和傳統(tǒng)的心跳技術(shù)的目的不同，傳統(tǒng)的集群心跳的目 的包括： 1 同步集群配置信息和集群狀態(tài)信息 2 監(jiān)控 Act

43、ive 的業(yè)務(wù)服務(wù)器是否運行正常 3 根據(jù)監(jiān)控信息，激發(fā)集群在主業(yè)務(wù)服務(wù)器系統(tǒng)沒有相應(yīng)的時候，自動切換服務(wù)器。 但是，我們這里需要心跳的目的只包含前兩條，而不包含最后一條，原因是我們的生產(chǎn)中心災(zāi) 難后的切換，應(yīng)該是在人工確認(rèn)后手動發(fā)起的，我們不需要自動切換。 但不管怎樣，我們還是需要心跳來構(gòu)建這樣的集群系統(tǒng)。 4.2.4 為為什什么么需需要要人人工工確確認(rèn)認(rèn)災(zāi)災(zāi)難難 我們好像已經(jīng)已經(jīng)習(xí)慣了“生產(chǎn)中心到災(zāi)備中心的切換需要人工確認(rèn)的”這個規(guī)則了，我們也 已經(jīng)習(xí)慣了“如果不經(jīng)過人工確認(rèn)，就有可能導(dǎo)致誤操作”這種說法了，但是為什么本地集群系統(tǒng) 就可以自動切換呢？我們的“準(zhǔn)本地集群系統(tǒng)”和真正的本地集群

44、系統(tǒng)在邏輯上是相同的，為什么 我們還是需要堅持采用“災(zāi)難人工確認(rèn)”原則呢？ 其實，在“沒有必要自動切換”的說法背后，其真正原因是：凡是遠(yuǎn)距離的集群系統(tǒng)，都無法 象本地集群系統(tǒng)那樣，可以提供足夠可靠的心跳通道。 我們知道，本地集群系統(tǒng)可以提供多種冗余技術(shù)，保證心跳通道不在同一時間一起中斷，常見 的心跳冗余技術(shù)有： 1 采用雙以太網(wǎng)卡作為冗余心跳通道 2 采用雙 RS232 端口作為冗余心跳通道 3 采用公網(wǎng)（業(yè)務(wù)以太網(wǎng)通道）作為輔助冗余心跳通道 4 采用共享磁盤作為輔助冗余心跳通道 相對而言，遠(yuǎn)程集群系統(tǒng)除了能夠利用遠(yuǎn)距離以太網(wǎng)連接作為心跳以外，就沒有其他冗余措施 了，我們知道，城域范圍的網(wǎng)絡(luò)本

45、身的可靠性要比一個信息中心內(nèi)部的專用網(wǎng)絡(luò)的可靠性低很多的， 而且具有更多的不確定性，比如，一次光纖事故就可能會導(dǎo)致所有的心跳通道同時中斷。 如果我們無法保證心跳通道的可靠性，那么就有可能出現(xiàn)因為心跳通道本身的故障而引起的 “虛假災(zāi)難” ，也就是說，當(dāng)主業(yè)務(wù)系統(tǒng)實際在正常運行的情況下，備用系統(tǒng)卻因為無法收到對方 的心跳而認(rèn)為對方已經(jīng)“停止運行” ，并強行接管數(shù)據(jù)和網(wǎng)絡(luò)系統(tǒng)，這種情況在技術(shù)領(lǐng)域我們稱為 “Split-Brain” ，也就是說一份數(shù)據(jù)，兩個大腦。這種情況對數(shù)據(jù)系統(tǒng)是非常危險的，兩個服務(wù)器 對一個數(shù)據(jù)資源的強制爭用，會導(dǎo)致業(yè)務(wù)數(shù)據(jù)的不一致，更有甚者，會導(dǎo)致業(yè)務(wù)數(shù)據(jù)的不可逆損壞。 一個“

46、假災(zāi)難”會引起“真災(zāi)難”的發(fā)生，這是誰都不會允許的。 除非我們有足夠可靠的心跳安全技術(shù)和策略，否則，為了避免這種“意外災(zāi)難”的發(fā)生，我們 都會建議在災(zāi)備系統(tǒng)的接管策略上，采用“災(zāi)難人工確認(rèn)”原則的。 這里，我想補充說明一下，實際上，我們推薦的 VERITAS Cluster Server 可以提供其他特有的 技術(shù)手段來彌補遠(yuǎn)距離心跳安全性方面的缺陷，嚴(yán)格來講，VCS 可以支持容災(zāi)系統(tǒng)的遠(yuǎn)程自動切換。 通過配置 I/O fencing 仲裁盤方式可以規(guī)避由于心跳原因造成的“裂腦”現(xiàn)象。但是我們原則上還 是建議異地應(yīng)用容災(zāi)采用“災(zāi)難人工確認(rèn)”原則。 4.2.5 建建立立一一個個滿滿足足災(zāi)災(zāi)備備需需

47、要要的的集集群群系系統(tǒng)統(tǒng) 現(xiàn)在新的技術(shù)需求出現(xiàn)了，因為我們需要構(gòu)建這樣一個集群系統(tǒng)： 1 一個集群系統(tǒng)，覆蓋一個應(yīng)用相關(guān)的所有服務(wù)器系統(tǒng)，不僅僅包括生產(chǎn)中心的系統(tǒng)，還需 要包括災(zāi)備中心的備用系統(tǒng)。 2 一個應(yīng)用的集群系統(tǒng)內(nèi)，生產(chǎn)中心內(nèi)的服務(wù)器節(jié)點間是可以自由切換的，并且是需要自動 切換的，而生產(chǎn)中心到災(zāi)備中心的節(jié)點的切換卻是不允許自動發(fā)生的。 我們知道，要統(tǒng)一管理生產(chǎn)中心和災(zāi)備中心的系統(tǒng)，我們必須將同一應(yīng)用的不同服務(wù)器同時納 入同一個集群系統(tǒng)，如下圖。 在集群邏輯上，我們要求這 3 臺服務(wù)器同時屬于同一個應(yīng)用的集群系統(tǒng)，任意對這個應(yīng)用集群 的調(diào)整，其配置信息都將同步的傳遞到這 3 臺服務(wù)器上，

48、同時，這 3 臺服務(wù)器作為集群節(jié)點，都處 于 Enable 狀態(tài)，都在監(jiān)視彼此的活動狀態(tài)，并及時把配置和狀態(tài)信息的變化傳遞給集群內(nèi)部的其 他服務(wù)器系統(tǒng)。 但是從應(yīng)用邏輯上來看，我們對這 3 臺服務(wù)器的角色要求還是有區(qū)別的，我們要求生產(chǎn)中心的 服務(wù)器 A 和 B 之間是允許并要求支持自動切換的，而容災(zāi)中心的服務(wù)器 C，是不允許自動接管生產(chǎn) 中心的業(yè)務(wù)的。 我們要求服務(wù)器節(jié)點 C 對業(yè)務(wù)的接管，需要經(jīng)過人工確認(rèn)，然后我們利用在服務(wù)器節(jié)點 C 上的 接管定義，實現(xiàn)應(yīng)用的單鍵切換。這種要求需要服務(wù)器節(jié)點 C 的各種資源配置始終和生產(chǎn)中心的服 務(wù)器節(jié)點 A 和 B 保持一致。這樣，相對于純手工切換，我們

49、推薦的這種方式要平滑的多，并可以更 好的保證災(zāi)備系統(tǒng)在計劃的時間內(nèi)順利投入運行。 本方案推薦的 VERITAS Cluster Server 軟件可以全面地提供這方面的技術(shù)，滿足這種策略的需 要，從而可以幫助建立覆蓋生產(chǎn)中心和災(zāi)備中心的統(tǒng)一的集群系統(tǒng)。 4 4. .2 2. .6 6 業(yè)業(yè)務(wù)務(wù)系系統(tǒng)統(tǒng)故故障障和和災(zāi)災(zāi)難難的的響響應(yīng)應(yīng) 業(yè)務(wù)系統(tǒng)故障和災(zāi)難的種類很多，不過我們只要解決了一下幾個問題，其他的問題就不是問題 了，下面，我們就這幾個問題分別予以闡述。 1. 生產(chǎn)中心主業(yè)務(wù)服務(wù)器不可用 2. 生產(chǎn)中心所有服務(wù)器不可用 3. 生產(chǎn)中心和災(zāi)備中心之間心跳鏈路故障 4. 生產(chǎn)中心所有服務(wù)器和磁盤

50、系統(tǒng)不可用 1)生產(chǎn)中心主業(yè)務(wù)服務(wù)器不可用生產(chǎn)中心主業(yè)務(wù)服務(wù)器不可用 生產(chǎn)中心主業(yè)務(wù)服務(wù)器 A 發(fā)生故障，這只是常規(guī)意義上的服務(wù)器單點故障，利用 VCS 集群軟件， 我們可以非常簡單的在生產(chǎn)中心內(nèi)部完成應(yīng)用從服務(wù)器 A 到服務(wù)器 B 的自動切換。如下圖： 同樣的，在服務(wù)器 A 的故障修復(fù)以后，我們可以繼續(xù)讓應(yīng)用運行在服務(wù)器 B 上，而把服務(wù)器 A 作為第一備用服務(wù)器；也可以將應(yīng)用回切到服務(wù)器 A，恢復(fù)到故障發(fā)生前的狀態(tài)。 2)生產(chǎn)中心所有服務(wù)器不可用生產(chǎn)中心所有服務(wù)器不可用 當(dāng)生產(chǎn)中心所有的服務(wù)器系統(tǒng)都發(fā)生故障時，就遇到了我們所謂的服務(wù)器系統(tǒng)災(zāi)難，這個時候， 服務(wù)器系統(tǒng) C 發(fā)現(xiàn)服務(wù)器 A、B

51、 均出現(xiàn)了問題，于是做好的了接管應(yīng)用的準(zhǔn)備，但是根據(jù)預(yù)先定義 的規(guī)則，服務(wù)器 C 不會自動接管該應(yīng)用，而是等我們?nèi)斯ご_認(rèn)災(zāi)難的真實性后，由管理員連接到服 務(wù)器 C 的集群系統(tǒng)上，啟動接管流程。集群軟件會根據(jù)我們在集群軟件中定義好的接管流程，依次 啟動該應(yīng)用需要的系統(tǒng)資源、存儲資源、網(wǎng)絡(luò)資源、數(shù)據(jù)庫和應(yīng)用資源，實現(xiàn)應(yīng)用的平滑接管。整 個應(yīng)用接管的過程如下圖： 3)生產(chǎn)中心和災(zāi)備中心之間心跳鏈路故障生產(chǎn)中心和災(zāi)備中心之間心跳鏈路故障 當(dāng)生產(chǎn)中心和災(zāi)備中心之間所有的心跳鏈路同時發(fā)生故障時，生產(chǎn)中心會認(rèn)為災(zāi)備中心的服務(wù) 器 C 發(fā)生故障，并將該服務(wù)器 C 從集群中隔離出去，整個過程對應(yīng)用系統(tǒng)沒有任何影

52、響，之后，我 們在生產(chǎn)中心仍然保持一個由服務(wù)器 A 和服務(wù)器 B 構(gòu)成的集群。 與此同時，在災(zāi)備中心，災(zāi)備服務(wù)器同樣會認(rèn)為生產(chǎn)中心發(fā)生災(zāi)難，從而將服務(wù)器 A 和服務(wù)器 B 從集群中隔離，保留自身構(gòu)成單節(jié)點集群。由于我們預(yù)先定義的策略是災(zāi)備系統(tǒng)不自動接管業(yè)務(wù)， 所以災(zāi)備系統(tǒng)不會試圖接管任何和業(yè)務(wù)相關(guān)的系統(tǒng)資源。在人工確認(rèn)以后，我們發(fā)現(xiàn)這是由心跳鏈 路故障引起的“假災(zāi)難” ，于是我們可以 Disable 災(zāi)備中心的集群系統(tǒng)，并設(shè)法修復(fù)心跳鏈路，然 后，我們可以再將災(zāi)備中心的服務(wù)器 C 重新加入到由服務(wù)器 A 和 B 構(gòu)成的集群中去。 VERITAS Cluster Server 支持動態(tài)的集群節(jié)點

53、加入，所以，事件的整個過程對業(yè)務(wù)系統(tǒng)不會 產(chǎn)生任何影響。相反的，其他我們以前使用的集群軟件，在遇到上述情況后，恢復(fù)該集群新節(jié)點時 是需要暫停應(yīng)用的。 4)生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用 生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用，這種情況一般只有在真正的災(zāi)難的情況下才會發(fā)生， 包括自然災(zāi)難和人為災(zāi)難。這種情況下，我們需要災(zāi)備系統(tǒng)在確認(rèn)災(zāi)難以后，能夠快速的、準(zhǔn)確地 接管所有關(guān)鍵業(yè)務(wù)系統(tǒng)。 這種故障和上面第一種情況的不同之處在于，生產(chǎn)中心的磁盤系統(tǒng)同時發(fā)生了故障。這種情況 會帶來一個新問題，那就是在一個邏輯卷鏡像的一個 Plex 損壞的情況下，我們需要將該邏輯卷所 在

54、的 Disk Group 強制 Import，這種處理方式和磁盤系統(tǒng)沒有損壞的情況是不同的，對于手動處理， 我們需要制動不同的接管命令流程，而對于集群系統(tǒng)，我們則需要集群系統(tǒng)提供針對這個問題的監(jiān) 控、判斷的能力，以及選擇合適啟動流程的能力。 針對這種情況，VERITAS Cluster Server 提供的 Campus Agent 可以幫助用戶簡化災(zāi)備系統(tǒng)管 理程序和災(zāi)難恢復(fù)程序。VCS Campus Agent 提供了一系列針對城域集群系統(tǒng)的解決方案，利用 VCS Campus Agent，我們可以非常輕松的構(gòu)建一個覆蓋災(zāi)備系統(tǒng)的集群系統(tǒng)。下圖是在生產(chǎn)中心發(fā)生災(zāi) 難的情況下，災(zāi)備系統(tǒng)的接管

55、流程的示意圖： 4.2.7 方方案案的的優(yōu)優(yōu)勢勢 我們推薦的城域集群方案，為構(gòu)建穩(wěn)定的、可靠的、易于管理的災(zāi)備中心非常有幫助，該方案 的優(yōu)勢主要表現(xiàn)在以下幾個方面： 1 有利于保證生產(chǎn)中心和災(zāi)備中心資源配置的一致性 2 有利于簡化災(zāi)備中心災(zāi)難應(yīng)急的流程，保證災(zāi)備中心快速、順利的接管相應(yīng)的應(yīng)用系統(tǒng)。 3 方案在技術(shù)上支持遠(yuǎn)程心跳，可將集群擴展到城域范圍。 4 方案擁有先進(jìn)的 Campus Agent，解決城域集群特有的問題。 5 方案支持靈活的集群策略，滿足災(zāi)備中心管理的各種需要。比如自動接管和手動接管并存 這種集群模式。 6 圖形化管理，簡單直觀，減輕管理壓力，減少集群系統(tǒng)認(rèn)為事故。 7 方案

56、支持應(yīng)用級的監(jiān)控和集群管理。 相對于 HACMP 僅僅提供硬件級的故障監(jiān)控，VCS 可以提供應(yīng)用級的生命監(jiān)控，不僅能在硬件系統(tǒng)發(fā) 生故障時，及時檢測并切換主機，還能判斷象數(shù)據(jù)庫進(jìn)程掛起這樣的應(yīng)用級別的軟故障，并針對這 些故障，提供快速的處理，包括應(yīng)用重啟或應(yīng)用切換。 8 支持多平臺，簡化管理，降低管理成本 VERITAS Cluster Server 支持包括 IBM AIX，SUN Solaris，HPUX 等在內(nèi)的多種通用的開放平臺， 也支持 Linux 和 Windows 平臺，不管是現(xiàn)在，還是將來，將集群平臺集中到 VCS，可以大大簡化我 們的日常集群管理工作。我們的技術(shù)人員不必再需要

57、針對每一種平臺，學(xué)習(xí)不同的集群軟件管理和 問題診斷的方法；我們企業(yè)，也不再需要針對每一種平臺，都花錢培養(yǎng)相應(yīng)的集群軟件管理員了。 五五、V VE ER RI IT TA AS S C Cl lu us st te er r S Se er rv ve er r 簡簡介介 5.1 業(yè)業(yè)界界領(lǐng)領(lǐng)先先的的高高可可用用應(yīng)應(yīng)用用解解決決方方案案 VERITAS Cluster Server是業(yè)界領(lǐng)先的開放式系統(tǒng)集群解決方案，是消除計劃內(nèi)和計劃外停 機時間，簡化服務(wù)器合并，并有效管理多平臺環(huán)境內(nèi)廣泛應(yīng)用的理想選擇。 要保障信息訪問，應(yīng)用和數(shù)據(jù)就必須符合嚴(yán)格的正常運行要求。鑒于用戶需要以電子方式獲取 更多的

58、服務(wù)，提升應(yīng)用正常運行水平的需求也急劇增長。VERITAS Cluster Server 支持 UNIX 和 Windows 集群內(nèi)最廣泛的應(yīng)用程序，為配置基于策略的故障切換方案，滿足正常運行要求和履行為 客戶承擔(dān)的義務(wù)提供了靈活性。除此之外，自動化、智能化工作負(fù)荷管理，允許集群管理員從反應(yīng) 型恢復(fù)轉(zhuǎn)向瞻型可用性管理，從而優(yōu)化利用各種資源。 由于支持存儲局域網(wǎng)（SAN）和傳統(tǒng)客戶機/服務(wù)器環(huán)境內(nèi)的大型集群，VERITAS Cluster Server 能夠在網(wǎng)絡(luò)存儲環(huán)境，靈活地保護從單一數(shù)據(jù)庫實例到大型多應(yīng)用集群的所有部件。它既 能夠獨立使用，又能與許多成龍配套的 VERITAS 軟件解決方案

59、相整合，因此在為當(dāng)今的混合型計 算環(huán)境提供高可用性和災(zāi)難恢復(fù)方面，發(fā)揮至關(guān)重要的作用。 5.2VERITAS Cluster Server 產(chǎn)產(chǎn)品品要要點點 多平臺支持多平臺支持 VERITAS Cluster Server 支持 Microsoft Windows、Sun、Solaris、HP-UX 和 IBM AIX。 簡化管理簡化管理 可以選用基于 Web 或基于 Java 的直觀控制臺，在整個站點范圍監(jiān)控多達(dá) 16 個多平臺集群，并使用 基于 Java 的接口執(zhí)行細(xì)顆粒度集群管理。如果與 VERITAS Global Cluster Manager相整合，就 能夠在不同地區(qū)站點間或全球

60、范圍內(nèi)，為單一站點的 256 個集群提供監(jiān)控和遷移。 廣泛的應(yīng)用支持廣泛的應(yīng)用支持 當(dāng)前支持廣泛系列的應(yīng)用，其中包括 Oracle、Sybase、DB2、Informix、Microsoft SQL Server 和 Microsoft Exchange，同時 VERITAS 還在連續(xù)不斷地開發(fā)新代理。另外，還提供代理開發(fā)工具 箱，以便創(chuàng)建定制代理，這樣就能夠?qū)θ魏螒?yīng)用執(zhí)行監(jiān)控，檢測其故障，并執(zhí)行故障恢復(fù)。 高度可伸縮高度可伸縮 支持 SAN 環(huán)境和傳統(tǒng)客戶機/服務(wù)器環(huán)境內(nèi)的超大規(guī)模集群。而且，VERITAS Cluster Server 還允 許根據(jù)需要，靈活地增加或取消集群內(nèi)的服務(wù)器，不需