同城應(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和配置說(shuō)明三、容災(zāi)系統(tǒng)建議解決方案拓?fù)鋱D和配置說(shuō)明.8 四、四、VERITAS 基于鏡像技術(shù)的容災(zāi)方案及其實(shí)現(xiàn)基于鏡像技術(shù)的容災(zāi)方案及其實(shí)現(xiàn).9 4.1、數(shù)據(jù)容災(zāi)方案的實(shí)現(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)勢(shì).15 4.1.4對(duì)

2、系統(tǒng)性能的影響.18 4.1.5容災(zāi)案例.19 4.2、構(gòu)建完整的應(yīng)用級(jí)災(zāi)備中心.20 4.2.1純手工應(yīng)用災(zāi)備的問(wèn)題.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建立一個(gè)滿足災(zāi)備需要的集群系統(tǒng).25 4.2.6業(yè)務(wù)系統(tǒng)故障和災(zāi)難的響應(yīng).26 4.2.7方案的優(yōu)勢(shì).30 五、五、VERITAS CLUSTER SERVER 簡(jiǎn)介簡(jiǎn)介.31 5.1 業(yè)界領(lǐng)先的高可用應(yīng)用解決方案.31 5.2VERITAS CLUSTER SERVER產(chǎn)品要點(diǎn).31 5.3VERITAS CLUSTER SER

3、VER的先進(jìn)性.33 5.4VERITAS CLUSTER的特點(diǎn)和好處.35 六、六、STORAGE FOUNDATION FOR ORACLE RAC 概述概述.37 6.1Veritas Storage Foundation for Oracle RAC概述.37 6.2雙磁盤陣列實(shí)現(xiàn)RAC系統(tǒng)存儲(chǔ)支持案例.41 一一、容容災(zāi)災(zāi)系系統(tǒng)統(tǒng)需需求求 ( (在在此此插插入入用用戶戶情情況況介介紹紹) ) IT 系統(tǒng)是職能正常運(yùn)轉(zhuǎn)的重要支撐。考慮到IT 系統(tǒng)的重要性，為了保 證 IT 系統(tǒng)的正常運(yùn)轉(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ù)庫(kù)系統(tǒng)為Oracle ，運(yùn)行在兩臺(tái)小型 機(jī)系統(tǒng)上?？紤]到核心數(shù)據(jù)庫(kù)系統(tǒng)的安全和可靠，準(zhǔn)備在同城建立現(xiàn)有數(shù)據(jù)庫(kù) 系統(tǒng)的數(shù)據(jù)容災(zāi)系統(tǒng)，并可以簡(jiǎn)單地實(shí)現(xiàn) 生產(chǎn)系統(tǒng)的應(yīng)用級(jí)容災(zāi)。 二二、容容災(zāi)災(zāi)技技術(shù)術(shù)的的選選擇擇 2.1 基于 SAN 城域網(wǎng)的鏡像技術(shù) 目前實(shí)現(xiàn)容災(zāi)的技術(shù)方案看起來(lái)很多，不過(guò)目前比較通用的和實(shí)用的容災(zāi)技術(shù)，主要有兩類， 一種是基于主機(jī)的容災(zāi)方案，一種是基于磁盤系統(tǒng)的數(shù)據(jù)復(fù)制的容災(zāi)方案。 而隨著光纖存儲(chǔ)網(wǎng)絡(luò)技術(shù)的成熟和在距離上的拓展，光纖城域存儲(chǔ)網(wǎng)絡(luò)的實(shí)現(xiàn)已經(jīng)趨于成熟， 這就使得我們今天可以不再需要依賴復(fù)雜的數(shù)據(jù)復(fù)制技術(shù)，就可以實(shí)現(xiàn)同城容災(zāi)了。新的容災(zāi)方案 所利用的，是最為傳統(tǒng)的磁

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

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

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

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

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

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

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

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

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

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

15、中心和災(zāi)備中心的兩個(gè)磁 盤系統(tǒng)上。 采用這種方式，生產(chǎn)中心的磁盤陣列與同城容災(zāi)中心的磁盤陣列對(duì)于兩地的主機(jī)而言是完全同等的。 利用城域 SAN 存儲(chǔ)網(wǎng)絡(luò)和 VERITAS Volume Manager 鏡像功能，我們可以非常輕松的實(shí)現(xiàn)數(shù)據(jù)系統(tǒng) 的異地容災(zāi)。 下面，我們來(lái)看一下，在各種數(shù)據(jù)系統(tǒng)（本節(jié)暫時(shí)不討論應(yīng)用系統(tǒng)全面災(zāi)難的應(yīng)對(duì)，我們把它 放到下一節(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 個(gè)地方（請(qǐng)注意，沒有建立容 災(zāi)系統(tǒng)時(shí)，數(shù)據(jù)系統(tǒng)的主要故障點(diǎn)是 1 個(gè)

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)的根本目的，對(duì)于這樣的 災(zāi)難，我們來(lái)看一下我們推薦的容災(zāi)方案是如何響應(yīng)的，見下圖： 當(dāng)生產(chǎn)中心的磁盤系統(tǒng)發(fā)生故障（災(zāi)難）時(shí)，由于同城容災(zāi)中心的磁盤是它的鏡像，所以操作 系統(tǒng)會(huì)自動(dòng)隔離生產(chǎn)中心的磁盤，轉(zhuǎn)而對(duì)容災(zāi)中心的數(shù)據(jù)進(jìn)行訪問(wèn)。從上圖我們看到，業(yè)務(wù)系統(tǒng)可 以通過(guò)城域 SAN 網(wǎng)絡(luò)直接訪問(wèn)災(zāi)備中心的磁盤系統(tǒng)的數(shù)據(jù)，而不需要有任何針對(duì)業(yè)務(wù)系統(tǒng)的動(dòng)作。 也就是說(shuō)，生產(chǎn)中心磁盤系統(tǒng)的災(zāi)難，對(duì)業(yè)務(wù)系統(tǒng)是透明的，應(yīng)用和數(shù)據(jù)庫(kù)不會(huì)因?yàn)樯a(chǎn)中心磁盤 系統(tǒng)的故障而停止；更重要的是，因?yàn)閼?yīng)用和數(shù)據(jù)庫(kù)不會(huì)

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

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

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

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

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

22、MR 技術(shù)實(shí)現(xiàn)增量同步的過(guò)程如下圖所示： 4.1.3 方方案案的的技技術(shù)術(shù)優(yōu)優(yōu)勢(shì)勢(shì) 和其他容災(zāi)方案相比，VERITAS 容災(zāi)方案具有明顯的優(yōu)勢(shì)，這些優(yōu)勢(shì)不僅僅表現(xiàn)在技術(shù)實(shí)現(xiàn)方 面，還表現(xiàn)在開放性、可維護(hù)性等各個(gè)方面。 結(jié)構(gòu)簡(jiǎn)單結(jié)構(gòu)簡(jiǎn)單 VERITAS 推薦的基于鏡像的容災(zāi)方案較任何一種容災(zāi)方案為簡(jiǎn)單。在一個(gè)使用邏輯卷管理的應(yīng) 用系統(tǒng)中（邏輯卷管理的好處我想大家已經(jīng)深有體會(huì)，我想我在這里就不需要重復(fù)了） ，我們只是 利用了其中最常用、最成熟的鏡像功能，就可以實(shí)現(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)。明顯的，該方法增加了一個(gè)在非容災(zāi)系統(tǒng)中 完全不需要的環(huán)節(jié)，不僅增加了故障源，同時(shí)也增加了維護(hù)強(qiáng)度。事實(shí)上，基于主機(jī)的復(fù)制技術(shù)存 在同樣的問(wèn)題。 技術(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)上，同時(shí)也被廣泛用于磁盤系統(tǒng)內(nèi)部作為企業(yè)級(jí)解決方案，象 EMC、HDS、HP、IBM、SUN、Compaq 等眾多存儲(chǔ)設(shè)備生產(chǎn)廠

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

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

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

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

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

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

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

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

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

33、的鏡像技術(shù)來(lái)構(gòu) 建的，其生產(chǎn)中心和災(zāi)備中心分別位于上海市的浦東和浦西，兩地相距超過(guò) 30 公里。 蕪湖卷煙廠信息系統(tǒng)的同城容災(zāi)項(xiàng)目 另外，VERITAS 擁有豐富的容災(zāi)系統(tǒng)實(shí)施經(jīng)驗(yàn)，我們參與的容災(zāi)項(xiàng)目除了采用鏡像方式的，還 有利用傳統(tǒng)的數(shù)據(jù)復(fù)制方式構(gòu)建的容災(zāi)系統(tǒng)，包括： 中國(guó)聯(lián)通光傳輸網(wǎng)絡(luò)系統(tǒng) 中國(guó)聯(lián)通光傳輸網(wǎng)絡(luò)的容災(zāi)系統(tǒng)是由 VEITAS 通過(guò)華為提供的，這個(gè)方案是跨省際的，其中一個(gè)容 災(zāi)項(xiàng)目的生產(chǎn)中心和災(zāi)備中心分別在北京和廣州。VERITAS 提供的這套超遠(yuǎn)程容災(zāi)方案是國(guó)內(nèi)目前 業(yè)界唯一真正已實(shí)施的超遠(yuǎn)程容災(zāi)方案。要實(shí)現(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)項(xiàng)目 4 4. .2 2、構(gòu)構(gòu)建建完完整整的的應(yīng)應(yīng)用用級(jí)級(jí)災(zāi)災(zāi)備備中中心心 4.2.1 純純手手工工應(yīng)應(yīng)用用災(zāi)災(zāi)備備的的問(wèn)問(wèn)題題 本次需要構(gòu)建的不僅僅是數(shù)據(jù)容災(zāi)中心，我們需要構(gòu)建的是應(yīng)用級(jí)的同城災(zāi)備中心，所以除了 要考慮在災(zāi)備中心購(gòu)置等量的存儲(chǔ)用于數(shù)據(jù)災(zāi)備以外，我們還需要購(gòu)置同等處理能力的服務(wù)器系統(tǒng) 作為災(zāi)備應(yīng)用和數(shù)據(jù)庫(kù)服務(wù)器，以便在災(zāi)難發(fā)生時(shí)，能夠完整的接管整個(gè)業(yè)務(wù)系統(tǒng)，包括數(shù)據(jù)和業(yè) 務(wù)處理能力。 兩套系統(tǒng)配置難以完全同步的風(fēng)險(xiǎn) 對(duì)兩套系統(tǒng)的管理是孤立的，而這兩套系統(tǒng)應(yīng)該是在各方面都相

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

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

37、單的“磁盤系統(tǒng)故障” ，它可能是任何情況。所以災(zāi)備中心的接管流程要求： 1）全面，包括簡(jiǎn)單的，也包括復(fù)雜的；2）盡量提供簡(jiǎn)單的流程。 管理難度大 生產(chǎn)中心和災(zāi)備中心兩套系統(tǒng)完全孤立，沒有辦法同時(shí)監(jiān)控，更不用說(shuō)在一個(gè)界面上對(duì)這些系統(tǒng)統(tǒng) 一監(jiān)控和管理了，我們難以同時(shí)對(duì)兩地配置進(jìn)行跟蹤和修改，無(wú)謂的增加了災(zāi)備系統(tǒng)維護(hù)的難度和 強(qiáng)度。 解決以上問(wèn)題的辦法是：在生產(chǎn)中心和災(zāi)備中心之間構(gòu)建高可用集群系統(tǒng)。 就如同我們?cè)谝婚_始所講的，在城域 SAN 網(wǎng)絡(luò)上構(gòu)建的鏡像系統(tǒng)和在同一個(gè)機(jī)房?jī)?nèi)部構(gòu)建的鏡像系 統(tǒng)在邏輯上是完全相同的，同樣的，我們要推薦的在城域 SAN 網(wǎng)絡(luò)上構(gòu)建的集群系統(tǒng)和在同一個(gè)機(jī) 房?jī)?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)的本地機(jī)群技術(shù)的擴(kuò)展。實(shí) 際上，它所采用的軟件產(chǎn)品和基本技術(shù)，完全就是本地集群軟件，只是，我們需要這些集群軟件提 供必要的功能擴(kuò)展，以滿足城域范圍的特定的需要。在這里，我們稱這種模式為“準(zhǔn)本地集群”模 式，也可以稱為“Campus Model” 。 “準(zhǔn)本地集群”模式實(shí)際上和大家非常熟悉的本地集群模式是一樣的，在這種模式下，生產(chǎn)中 心的系統(tǒng)和災(zāi)備中心的系統(tǒng)將被納入同一個(gè)集群主體中，從而我們可以非常輕松的實(shí)現(xiàn)對(duì)兩個(gè)中心

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

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

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

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

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

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

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

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

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

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

49、推薦的這種方式要平滑的多，并可以更 好的保證災(zāi)備系統(tǒng)在計(jì)劃的時(shí)間內(nèi)順利投入運(yùn)行。 本方案推薦的 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)難的種類很多，不過(guò)我們只要解決了一下幾個(gè)問(wèn)題，其他的問(wèn)題就不是問(wèn)題 了，下面，我們就這幾個(gè)問(wèn)題分別予以闡述。 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ù)器單點(diǎn)故障，利用 VCS 集群軟件， 我們可以非常簡(jiǎn)單的在生產(chǎn)中心內(nèi)部完成應(yīng)用從服務(wù)器 A 到服務(wù)器 B 的自動(dòng)切換。如下圖： 同樣的，在服務(wù)器 A 的故障修復(fù)以后，我們可以繼續(xù)讓應(yīng)用運(yùn)行在服務(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ā)生故障時(shí)，就遇到了我們所謂的服務(wù)器系統(tǒng)災(zāi)難，這個(gè)時(shí)候， 服務(wù)器系統(tǒng) C 發(fā)現(xiàn)服務(wù)器 A、B

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

52、響，之后，我 們?cè)谏a(chǎn)中心仍然保持一個(gè)由服務(wù)器 A 和服務(wù)器 B 構(gòu)成的集群。 與此同時(shí)，在災(zāi)備中心，災(zāi)備服務(wù)器同樣會(huì)認(rèn)為生產(chǎn)中心發(fā)生災(zāi)難，從而將服務(wù)器 A 和服務(wù)器 B 從集群中隔離，保留自身構(gòu)成單節(jié)點(diǎn)集群。由于我們預(yù)先定義的策略是災(zāi)備系統(tǒng)不自動(dòng)接管業(yè)務(wù)， 所以災(zāi)備系統(tǒng)不會(huì)試圖接管任何和業(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 支持動(dòng)態(tài)的集群節(jié)點(diǎn)

53、加入，所以，事件的整個(gè)過(guò)程對(duì)業(yè)務(wù)系統(tǒng)不會(huì) 產(chǎn)生任何影響。相反的，其他我們以前使用的集群軟件，在遇到上述情況后，恢復(fù)該集群新節(jié)點(diǎn)時(shí) 是需要暫停應(yīng)用的。 4)生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用 生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用，這種情況一般只有在真正的災(zāi)難的情況下才會(huì)發(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)同時(shí)發(fā)生了故障。這種情況 會(huì)帶來(lái)一個(gè)新問(wèn)題，那就是在一個(gè)邏輯卷鏡像的一個(gè) Plex 損壞的情況下，我們需要將該邏輯卷所 在

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

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

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

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

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

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

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