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

1、同城應(yīng)用容災(zāi)系統(tǒng)方案 PAGE 第 PAGE 48 頁 共 NUMPAGES 48 頁同城應(yīng)用容災(zāi)系統(tǒng)方案目 錄 TOC o 1-4 h z u HYPERLINK l _Toc485651052 1容災(zāi)系統(tǒng)需求 PAGEREF _Toc485651052 h 3 HYPERLINK l _Toc485651053 2容災(zāi)技術(shù)的選擇 PAGEREF _Toc485651053 h 3 HYPERLINK l _Toc485651054 2.1基于SAN城域網(wǎng)的鏡像技術(shù) PAGEREF _Toc485651054 h 3 HYPERLINK l _Toc485651055 2.2構(gòu)建容災(zāi)系統(tǒng)的技

2、術(shù)要求 PAGEREF _Toc485651055 h 5 HYPERLINK l _Toc485651056 3容災(zāi)系統(tǒng)建議解決方案拓?fù)鋱D和配置說明 PAGEREF _Toc485651056 h 6 HYPERLINK l _Toc485651057 4VERITAS基于鏡像技術(shù)的容災(zāi)方案及其實現(xiàn) PAGEREF _Toc485651057 h 7 HYPERLINK l _Toc485651058 4.1數(shù)據(jù)容災(zāi)方案的實現(xiàn) PAGEREF _Toc485651058 h 7 HYPERLINK l _Toc485651059 4.1.1方案的結(jié)構(gòu)原理 PAGEREF _Toc485651

3、059 h 7 HYPERLINK l _Toc485651060 4.1.2數(shù)據(jù)系統(tǒng)故障和災(zāi)難的響應(yīng) PAGEREF _Toc485651060 h 10 HYPERLINK l _Toc485651061 4.1.2.1生產(chǎn)中心數(shù)據(jù)系統(tǒng)故障 PAGEREF _Toc485651061 h 10 HYPERLINK l _Toc485651062 4.1.2.2災(zāi)備中心數(shù)據(jù)系統(tǒng)故障 PAGEREF _Toc485651062 h 11 HYPERLINK l _Toc485651063 4.1.2.3生產(chǎn)中心和災(zāi)備中心SAN鏈路故障 PAGEREF _Toc485651063 h 11 HY

4、PERLINK l _Toc485651064 4.1.3方案的技術(shù)優(yōu)勢 PAGEREF _Toc485651064 h 14 HYPERLINK l _Toc485651065 4.1.4對系統(tǒng)性能的影響 PAGEREF _Toc485651065 h 18 HYPERLINK l _Toc485651066 4.1.5容災(zāi)案例 PAGEREF _Toc485651066 h 19 HYPERLINK l _Toc485651067 4.2構(gòu)建完整的應(yīng)用級災(zāi)備中心 PAGEREF _Toc485651067 h 21 HYPERLINK l _Toc485651068 4.2.1純手工應(yīng)用災(zāi)

5、備的問題 PAGEREF _Toc485651068 h 21 HYPERLINK l _Toc485651069 4.2.2建立覆蓋災(zāi)備中心的統(tǒng)一集群體系 PAGEREF _Toc485651069 h 24 HYPERLINK l _Toc485651070 4.2.2.1跨越幾十公里的心跳技術(shù)支持 PAGEREF _Toc485651070 h 25 HYPERLINK l _Toc485651071 4.2.2.2為什么需要人工確認(rèn)災(zāi)難 PAGEREF _Toc485651071 h 26 HYPERLINK l _Toc485651072 4.2.2.3建立一個滿足災(zāi)備需要的集群系統(tǒng)

6、 PAGEREF _Toc485651072 h 27 HYPERLINK l _Toc485651073 4.2.3業(yè)務(wù)系統(tǒng)故障和災(zāi)難的響應(yīng) PAGEREF _Toc485651073 h 29 HYPERLINK l _Toc485651074 4.2.3.1生產(chǎn)中心主業(yè)務(wù)服務(wù)器不可用 PAGEREF _Toc485651074 h 29 HYPERLINK l _Toc485651075 4.2.3.2生產(chǎn)中心所有服務(wù)器不可用 PAGEREF _Toc485651075 h 30 HYPERLINK l _Toc485651076 4.2.3.3生產(chǎn)中心和災(zāi)備中心之間心跳鏈路故障 PAG

7、EREF _Toc485651076 h 31 HYPERLINK l _Toc485651077 4.2.3.4生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用 PAGEREF _Toc485651077 h 32 HYPERLINK l _Toc485651078 4.2.4方案的優(yōu)勢 PAGEREF _Toc485651078 h 33 HYPERLINK l _Toc485651079 5附件：VERITAS Cluster Server簡介 PAGEREF _Toc485651079 h 36 HYPERLINK l _Toc485651080 5.1業(yè)界領(lǐng)先的企業(yè)高可用應(yīng)用解決方案 PAGERE

8、F _Toc485651080 h 36 HYPERLINK l _Toc485651081 5.2VERITAS Cluster Server產(chǎn)品要點 PAGEREF _Toc485651081 h 36 HYPERLINK l _Toc485651082 5.3VERITAS Cluster Server的先進(jìn)性 PAGEREF _Toc485651082 h 38 HYPERLINK l _Toc485651083 5.4VERITAS Cluster的特點和好處 PAGEREF _Toc485651083 h 40 HYPERLINK l _Toc485651084 6VERITAS

9、Storage Foundation for Oracle RAC概述 PAGEREF _Toc485651084 h 42 HYPERLINK l _Toc485651085 雙磁盤陣列實現(xiàn)RAC系統(tǒng)存儲支持案例 PAGEREF _Toc485651085 h 47容災(zāi)系統(tǒng)需求1號線工程經(jīng)國家發(fā)展和改革委員會國家發(fā)展改革委關(guān)于杭州市地鐵1號線工程可行性研究報告的批復(fù)(發(fā)改投資2006684號)核準(zhǔn)同意建設(shè)，并已列為浙江省重點建設(shè)項目。項目建設(shè)規(guī)模為全長54公里，車站33座、總投資約為22076億元人民幣，建設(shè)地址位于杭州市，計劃于2011年建成。而的IT系統(tǒng)是職能正常運轉(zhuǎn)的重要支撐?？紤]到I

10、T系統(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)主要為數(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)技術(shù)的選擇基于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)趨于成熟，這就使得我們今天可以不再需

11、要依賴復(fù)雜的數(shù)據(jù)復(fù)制技術(shù)，就可以實現(xiàn)同城容災(zāi)了。新的容災(zāi)方案所利用的，是最為傳統(tǒng)的磁盤鏡像技術(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ù)是從磁盤容錯技術(shù)中最成熟、歷史最悠久、可靠性最高的數(shù)據(jù)保護(hù)技術(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)，我們就可以保留在任何時候自由、靈活的

12、選擇磁盤系統(tǒng)的權(quán)利。為什么以前比較少用鏡像做容災(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)？數(shù)據(jù)復(fù)制技術(shù)所能解決的距離和帶寬的問題，當(dāng)前已經(jīng)不再是問題了利用數(shù)據(jù)復(fù)制技術(shù)實現(xiàn)容災(zāi)，由于其技術(shù)本身的局限性，必然導(dǎo)致容災(zāi)系統(tǒng)的結(jié)構(gòu)要比沒有

13、容災(zāi)系統(tǒng)的時候復(fù)雜得多。同時，這樣的容災(zāi)系統(tǒng)的故障環(huán)節(jié)不可避免的會增加，導(dǎo)致維護(hù)難度、維護(hù)成本的增加?；诖疟P系統(tǒng)的數(shù)據(jù)復(fù)制技術(shù)，要求生產(chǎn)中心和災(zāi)備中心選用同一個廠商的磁盤系統(tǒng)，甚至要求選用同一系列、同一型號的磁盤系統(tǒng)，用戶完全失去討價還價的余地，完全失去了在任何時候自由、靈活地選擇合作廠商和磁盤系統(tǒng)的權(quán)利，必然給用戶造成被動和經(jīng)濟(jì)上的損失?？偵纤?，針對的容災(zāi)系統(tǒng)建設(shè)，我們認(rèn)為，既然我們可以提供基于光纖的城域SAN網(wǎng)絡(luò)，那么，我們就沒有必要再采用過時的基于磁盤系統(tǒng)數(shù)據(jù)復(fù)制的容災(zāi)方案，采用基于主機鏡像技術(shù)來實現(xiàn)容災(zāi)方案，應(yīng)該是一個更好的選擇。構(gòu)建容災(zāi)系統(tǒng)的技術(shù)要求基于磁盤鏡像技術(shù)構(gòu)建容災(zāi)系統(tǒng)，

14、在數(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ù)，包括：距離決定了鏈路的可靠性。我們在短距離（比如一個機房內(nèi)）可以忽略不計的鏈路故障（可以通過鏈路冗余解決）在長距離上就無法忽略了，比如，我們無法保證我們的光纖不會被野蠻施工挖斷。距離會影響我們管理一個系統(tǒng)的復(fù)雜性和現(xiàn)場感遠(yuǎn)距離災(zāi)備系統(tǒng)永遠(yuǎn)

15、都是生產(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)問題和解決方法，我們會在下一節(jié)中詳細(xì)論述，這里我們先簡單的把要求提出來，供參考。對磁盤鏡像容災(zāi)管理的要求：可視化磁盤管理和容災(zāi)管理應(yīng)對鏈路故障引起的各種問題：實現(xiàn)增量鏡像和避免Split-Brain等容災(zāi)系統(tǒng)建議解決方案拓?fù)鋱D和配置說明配置：V

16、eritas 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ù)的快速同步，并可以實現(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個LICENS

17、E.VERITAS基于鏡像技術(shù)的容災(zāi)方案及其實現(xiàn)基于鏡像技術(shù)實現(xiàn)容災(zāi)，從技術(shù)實現(xiàn)上，分為兩個部分，其一是數(shù)據(jù)的容災(zāi)實現(xiàn)，其二是應(yīng)用級容災(zāi)實現(xiàn)。下面，我們就分別從這兩個方面入手，論述VERITAS的容災(zāi)方案。數(shù)據(jù)容災(zāi)方案的實現(xiàn)方案的結(jié)構(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提供的非常成熟的

18、跨陣列磁盤鏡像技術(shù)來實現(xiàn)同城容災(zāi)了，容災(zāi)方案的結(jié)構(gòu)如下圖所示：從原理上講，在城域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)訪問磁盤的邏輯

19、設(shè)備名，在VERITAS Volume Manager管理下的磁盤系統(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的任意修改，都將

20、同時被寫到位于生產(chǎn)中心和災(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)的。數(shù)據(jù)系統(tǒng)故障和災(zāi)難的響應(yīng)在建立了容災(zāi)系統(tǒng)以后，數(shù)據(jù)系統(tǒng)的故障和災(zāi)難主要將發(fā)生在3個地方（請注意，沒有建立容災(zāi)系統(tǒng)時，數(shù)據(jù)系統(tǒng)的主要故障點是1個）：生產(chǎn)中心數(shù)據(jù)系統(tǒng)故障生產(chǎn)中心數(shù)據(jù)系統(tǒng)故障意味著災(zāi)

21、難，這也就是我們現(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ù)庫不會因為災(zāi)難而異常中止，從而避免了發(fā)生數(shù)據(jù)庫損壞的可能。生產(chǎn)中心磁盤系統(tǒng)故障之后，我們只需要更換損壞

22、的磁盤系統(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)備系統(tǒng)建立以后出現(xiàn)的新問題，這種故障就同上一種故障類似，但對業(yè)務(wù)系統(tǒng)的影響更小。生產(chǎn)中心和災(zāi)備中心SAN鏈路故障這種故障也是災(zāi)備系統(tǒng)建立以后出現(xiàn)的新問題。相對于以上兩種災(zāi)難，這種故障在容災(zāi)系統(tǒng)建立以后，出現(xiàn)的概率會更大一些，導(dǎo)致鏈路故障的原因很多，包括光纖斷裂，光端設(shè)備故障等

23、，都會導(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)本身的可維護(hù)性和可操作性。而對于鏈路故障，直接導(dǎo)致的就是業(yè)務(wù)數(shù)據(jù)在寫到本地磁盤系統(tǒng)的同時，無法寫到災(zāi)備系統(tǒng)中，對于鏡像技術(shù)而言，這又成為一個新的課題。傳統(tǒng)的鏡像技術(shù)，在鏡像鏈路被中斷以后，中斷的

24、鏡像會被認(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)上，實際上，這種方案不具有可實施性和可維護(hù)性，是不現(xiàn)實的。這也是什么主機廠商雖然也有類似鏡像功能，但不會用于容災(zāi)的的根本原因。為了解決這個問題，VERITAS Volume Manager提供了DCO+FMR技術(shù)，其中DCO（Data Change Object）是一種針對鏡像的Log技術(shù)，該技術(shù)允許Volu

25、me 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)系統(tǒng)本身的可維護(hù)性了。利用DCO和FMR，針對同樣的鏈路問題，我們的應(yīng)對步驟如下：SAN鏈路發(fā)生故障生產(chǎn)中心的Volume Manager利用 DCO日志記錄Volume : Plex 1 因業(yè)務(wù)數(shù)據(jù)的變化而變化的數(shù)據(jù)塊，災(zāi)備端Volume : Plex 2

26、的數(shù)據(jù)不會作廢一旦SAN鏈路恢復(fù)正常，Volume Manager的FMR功能模塊，會根據(jù) DCO日志記錄的情況，將Volume : Plex 1 中鏈路中斷后更新的業(yè)務(wù)數(shù)據(jù)拷貝到災(zāi)備端Volume : Plex 2，實現(xiàn)增量更新。Volume Manager 用DCO和FMR技術(shù)實現(xiàn)增量同步的過程如下圖所示：方案的技術(shù)優(yōu)勢和其他容災(zāi)方案相比，VERITAS容災(zāi)方案具有明顯的優(yōu)勢，這些優(yōu)勢不僅僅表現(xiàn)在技術(shù)實現(xiàn)方面，還表現(xiàn)在開放性、可維護(hù)性等各個方面。結(jié)構(gòu)簡單VERITAS推薦的基于鏡像的容災(zāi)方案較任何一種容災(zāi)方案為簡單。在一個使用邏輯卷管理的應(yīng)用系統(tǒng)中（邏輯卷管理的好處我想大家已經(jīng)深有體會，我

27、想我在這里就不需要重復(fù)了），我們只是利用了其中最常用、最成熟的鏡像功能，就可以實現(xiàn)容災(zāi)，而不必像其他容災(zāi)系統(tǒng)那樣增加很多不必要的環(huán)節(jié)。比如基于磁盤系統(tǒng)復(fù)制技術(shù)的容災(zāi)方案，我們必須在磁盤系統(tǒng)內(nèi)部專門配置相應(yīng)的接口卡，使用該磁盤系統(tǒng)專有的復(fù)制軟件，才可以構(gòu)建容災(zāi)系統(tǒng)。明顯的，該方法增加了一個在非容災(zāi)系統(tǒng)中完全不需要的環(huán)節(jié)，不僅增加了故障源，同時也增加了維護(hù)強度。事實上，基于主機的復(fù)制技術(shù)存在同樣的問題。技術(shù)成熟鏡像技術(shù)是比任何數(shù)據(jù)復(fù)制技術(shù)更早使用于高可用系統(tǒng)的成熟的功能，這種功能已經(jīng)廣泛應(yīng)用于包括IBM Mainframe、AS400、RS6000、HPUX、Digital Unix、SUN So

28、laris、Linux、Windows等在內(nèi)的所有服務(wù)器系統(tǒng)上，同時也被廣泛用于磁盤系統(tǒng)內(nèi)部作為企業(yè)級解決方案，象EMC、HDS、HP、IBM、SUN、Compaq等眾多存儲設(shè)備生產(chǎn)廠商，都將鏡像技術(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ù)的完整性VERITAS Volume Manager擁有一個容災(zāi)方

29、案必須的所有技術(shù)特性，它不僅可以提供可靠的鏡像技術(shù)，實現(xiàn)跨磁盤系統(tǒng)的數(shù)據(jù)容災(zāi)，同時，我們可以利用Volume Manager 的DCO和FMR技術(shù)，保證該容災(zāi)系統(tǒng)的可維護(hù)性。容災(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)

30、和災(zāi)備系統(tǒng)的邏輯卷置于同一個管理視圖中，從而實現(xiàn)對生產(chǎn)中心和災(zāi)備中心存儲的統(tǒng)一管理。VERITAS VEA管理界面豐富，下圖為其中一個管理界面，僅供參考。應(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)

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

32、應(yīng)時間上都會比直接鏡像造成更多的延時，對應(yīng)用系統(tǒng)有更大的影響。另外，在邏輯卷這個層面，我們可以根據(jù)需要對鏡像的數(shù)據(jù)靈活設(shè)置，我們不需將所有磁盤進(jìn)行鏡像，而只需鏡像必要的邏輯卷（Volume）。這種靈活性在實際使用過程中將大大減少數(shù)據(jù)遠(yuǎn)程復(fù)制的數(shù)量，從而避免對系統(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)。CPU資源消耗采用主機端的軟件鏡像技術(shù)，對CPU資源的損耗，實際上是微乎其微的，但很多時候被磁盤系統(tǒng)廠商人為的夸大了。具體的事實我們可以通過

33、簡單的測試得到，我們可以設(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）的，而相反的，高端主機總線的寬度一般是64-128Byte，甚至更高，主機CPU的處理速度更是在千兆的水平（ns級），所以I/O對主機CPU的消耗往往都是可以忽略不計

34、的，如果說需要關(guān)心的話，也主要針對象RAID-5這樣的技術(shù)（需要大量計算，從而消耗主機的CPU資源），而像鏡像這樣的技術(shù)，是幾乎不需要消耗CPU時間的。I/O的延遲效應(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ù)制技術(shù)，還是基于主機軟件的數(shù)據(jù)復(fù)制技術(shù)，這在上一節(jié)中已經(jīng)闡述。這里我想要補充的是在整個容災(zāi)系統(tǒng)中，對業(yè)務(wù)系統(tǒng)的性能的影響最大的不是任何一種技術(shù)所產(chǎn)生的負(fù)面作用，而是“距離”，正如前面提到的，在Cache命中率較高的系統(tǒng)中，距離對寫操作的影響較大，這和

35、光的傳播速度有關(guān)，光在150公里距離上的一個來回需要1ms，在15KM距離上一個來回需要0.1ms，我們列出一個對照表，供大家參考。本對照表不包含設(shè)備協(xié)議轉(zhuǎn)換和光在光纖中的折射等因素。同時，我們知道，100MB光纖對應(yīng)的速度是ns級的。距離光傳輸距離傳輸時間說明15 km30 km100us同城容災(zāi)中心的距離級別150 m300 m1us15 m30 m100ns一個機房的內(nèi)部距離1.5 m3 m10ns一個主板的內(nèi)部距離本地Cache寫的時間nsus級本地磁盤寫的時間usms級綜上所述，我們的結(jié)論是，只要是數(shù)據(jù)復(fù)制方式的同步方式能夠做的系統(tǒng)，采用鏡像方式也一定能做，而且會做的更好。容災(zāi)案例中

36、國銀聯(lián)IT中心的同城容災(zāi)中心項目中國銀聯(lián)的信息中心的同城容災(zāi)中心，就是選擇了VERITAS Volume Manager的鏡像技術(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è)界唯一真正已實施

37、的超遠(yuǎn)程容災(zāi)方案。要實現(xiàn)這種方案，我們只需要在現(xiàn)有的Volume Manager的基礎(chǔ)上增加VVR模塊，體現(xiàn)了技術(shù)和方案的延續(xù)性。上海熱線的容災(zāi)系統(tǒng)公安部某應(yīng)用系統(tǒng)從上海到廣東南海的遠(yuǎn)程容災(zāi)項目構(gòu)建完整的應(yīng)用級災(zāi)備中心純手工應(yīng)用災(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)該是在各方面都相同的并嚴(yán)格

38、的一一對應(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)的順利接管，需要日常的、長期的維護(hù)和精心的準(zhǔn)備，而不是簡單的在備用系統(tǒng)上輸入幾個命令來完成的，而集群軟件為這種需要提供了行之有效的方法。本地的

39、主服務(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)難的定義不是簡單的“磁盤系統(tǒng)故障”，它可能是任何情況。所

40、以災(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)維護(hù)的難度和強度。解決以上問題的辦法是：在生產(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)建的集群系統(tǒng)在邏輯上也是完全相同的。城域范圍內(nèi)和鏡像技術(shù)配套的集群技術(shù)，和用

41、于遠(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)對兩個中心的統(tǒng)一管理。其結(jié)果，就是給我們帶來管理的簡單化和災(zāi)備系統(tǒng)的可靠性。下圖為利用VERITA

42、S集群軟件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軟件，但卻稱這種集群模式為準(zhǔn)本地集群模式的原因。建立覆蓋災(zāi)備中心的統(tǒng)一集群體系為了有效的管理災(zāi)備中心，同時保證在災(zāi)難發(fā)生的時候，能夠在要求

43、的時間里快速的恢復(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)的功能上有新的擴展，以便滿足城域環(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)沒有

44、什么邏輯上的區(qū)別，但是就集群系統(tǒng)而言，僅僅是距離的變化，就會導(dǎo)致以下兩個新問題（距離對鏡像技術(shù)的影響和相應(yīng)的方案，我們在數(shù)據(jù)容災(zāi)一節(jié)已經(jīng)詳細(xì)闡述，這里不再說明）：集群系統(tǒng)的心跳線需要跨越幾十公里，而不是幾十米同城生產(chǎn)中心和災(zāi)備中心的網(wǎng)絡(luò)更容易因意外而中斷，其中包括心跳線這兩個因為距離而產(chǎn)生的新問題，需要我們在構(gòu)建集群系統(tǒng)時，不得不從技術(shù)層面仔細(xì)分析，以便保證我們推薦的方案的可靠性和可行性。下面，我們就這兩個問題從技術(shù)層面展開討論?？缭綆资锏男奶夹g(shù)支持城域集群將跨越幾十公里，這對集群心跳的技術(shù)要求非常簡單，就是要求集群軟件能夠支持跨越幾十公里的心跳技術(shù)。VERITAS Cluster Se

45、rver能夠很好的支持遠(yuǎn)程心跳通道，VCS對遠(yuǎn)程心跳通道只有一個要求，就是支持廣播。也就是說，只要兩個Site之間有不經(jīng)過路由器、橋這樣的設(shè)備的通道，就可以支持VCS的心跳。需要說明的是，我們這里需要心跳的動機和傳統(tǒng)的心跳技術(shù)的目的不同，傳統(tǒng)的集群心跳的目的包括：同步集群配置信息和集群狀態(tài)信息監(jiān)控Active的業(yè)務(wù)服務(wù)器是否運行正常根據(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)。

46、為什么需要人工確認(rèn)災(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)”和真正的本地集群系統(tǒng)在邏輯上是相同的，為什么我們還是需要堅持采用“災(zāi)難人工確認(rèn)”原則呢？其實，在“沒有必要自動切換”的說法背后，其真正原因是：凡是遠(yuǎn)距離的集群系統(tǒng)，都無法象本地集群系統(tǒng)那樣，可以提供足夠可靠的心跳通道。我們知道，本地集群系統(tǒng)可以提供多種冗余技術(shù)，保證心跳通道不在同一時間一起中斷，常見的心跳冗余技術(shù)有：采用雙以太網(wǎng)卡作為冗余心跳通道采用雙RS232端口

47、作為冗余心跳通道采用公網(wǎng)（業(yè)務(wù)以太網(wǎng)通道）作為輔助冗余心跳通道采用共享磁盤作為輔助冗余心跳通道相對而言，遠(yuǎn)程集群系統(tǒng)除了能夠利用遠(yuǎn)距離以太網(wǎng)連接作為心跳以外，就沒有其他冗余措施了，我們知道，城域范圍的網(wǎng)絡(luò)本身的可靠性要比一個信息中心內(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)域我們稱為“Sp

48、lit-Brain”，也就是說一份數(shù)據(jù)，兩個大腦。這種情況對數(shù)據(jù)系統(tǒng)是非常危險的，兩個服務(wù)器對一個數(shù)據(jù)資源的強制爭用，會導(dǎo)致業(yè)務(wù)數(shù)據(jù)的不一致，更有甚者，會導(dǎo)致業(yè)務(wù)數(shù)據(jù)的不可逆損壞。一個“假災(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 fenci

49、ng仲裁盤方式可以規(guī)避由于心跳原因造成的“裂腦”現(xiàn)象。但是我們原則上還是建議異地應(yīng)用容災(zāi)采用“災(zāi)難人工確認(rèn)”原則。建立一個滿足災(zāi)備需要的集群系統(tǒng)現(xiàn)在新的技術(shù)需求出現(xiàn)了，因為我們需要構(gòu)建這樣一個集群系統(tǒng)：一個集群系統(tǒng)，覆蓋一個應(yīng)用相關(guān)的所有服務(wù)器系統(tǒng)，不僅僅包括生產(chǎn)中心的系統(tǒng)，還需要包括災(zāi)備中心的備用系統(tǒng)。一個應(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ù)器同時屬于同一

50、個應(yīng)用的集群系統(tǒng)，任意對這個應(yīng)用集群的調(diào)整，其配置信息都將同步的傳遞到這3臺服務(wù)器上，同時，這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保持一致。

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

52、規(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)。生產(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均出現(xiàn)了問題，于是做好的了接管應(yīng)用的準(zhǔn)備，但是根據(jù)預(yù)先定義的規(guī)則，服務(wù)器C不會自動接管該應(yīng)用，而是等我們?nèi)斯ご_認(rèn)災(zāi)難的真實性后，由管理員連接到服務(wù)器C的集群系統(tǒng)上，啟動接管流程。集群軟

53、件會根據(jù)我們在集群軟件中定義好的接管流程，依次啟動該應(yīng)用需要的系統(tǒng)資源、存儲資源、網(wǎng)絡(luò)資源、數(shù)據(jù)庫和應(yīng)用資源，實現(xiàn)應(yīng)用的平滑接管。整個應(yīng)用接管的過程如下圖：生產(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)沒有任何影響，之后，我們在生產(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)不會

54、試圖接管任何和業(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é)點加入，所以，事件的整個過程對業(yè)務(wù)系統(tǒng)不會產(chǎn)生任何影響。相反的，其他我們以前使用的集群軟件，在遇到上述情況后，恢復(fù)該集群新節(jié)點時是需要暫停應(yīng)用的。生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用生產(chǎn)中心所有服務(wù)器和磁盤系統(tǒng)不可用，這種情況一般只有在真正的災(zāi)難的情況下才會發(fā)生，包括自然災(zāi)難和人為災(zāi)難。這種情況下，我們需

55、要災(zāi)備系統(tǒng)在確認(rèn)災(zāi)難以后，能夠快速的、準(zhǔn)確地接管所有關(guān)鍵業(yè)務(wù)系統(tǒng)。這種故障和上面第一種情況的不同之處在于，生產(chǎn)中心的磁盤系統(tǒng)同時發(fā)生了故障。這種情況會帶來一個新問題，那就是在一個邏輯卷鏡像的一個Plex損壞的情況下，我們需要將該邏輯卷所在的Disk Group強制Import，這種處理方式和磁盤系統(tǒng)沒有損壞的情況是不同的，對于手動處理，我們需要制動不同的接管命令流程，而對于集群系統(tǒng)，我們則需要集群系統(tǒng)提供針對這個問題的監(jiān)控、判斷的能力，以及選擇合適啟動流程的能力。針對這種情況，VERITAS Cluster Server提供的Campus Agent可以幫助用戶簡化災(zāi)備系統(tǒng)管理程序和災(zāi)難恢復(fù)程

56、序。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)的接管流程的示意圖：方案的優(yōu)勢我們推薦的城域集群方案，為構(gòu)建穩(wěn)定的、可靠的、易于管理的災(zāi)備中心非常有幫助，該方案的優(yōu)勢主要表現(xiàn)在以下幾個方面：有利于保證生產(chǎn)中心和災(zāi)備中心資源配置的一致性有利于簡化災(zāi)備中心災(zāi)難應(yīng)急的流程，保證災(zāi)備中心快速、順利的接管相應(yīng)的應(yīng)用系統(tǒng)。方案在技術(shù)上支持遠(yuǎn)程心跳，可將集群擴展到城域范圍。方案擁有先進(jìn)的Campus Agent，解決城域集群特有的問題。方案支持靈活的集

57、群策略，滿足災(zāi)備中心管理的各種需要。比如自動接管和手動接管并存這種集群模式。圖形化管理，簡單直觀，減輕管理壓力，減少集群系統(tǒng)認(rèn)為事故。方案支持應(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)用切換。支持多平臺，簡化管理，降低管理成本VERITAS Cluster Server支持包括IBM AIX，SUN Solaris，HPUX等在內(nèi)的多種通用的開放平臺，也支持Linux和Windows平臺，不管是現(xiàn)

58、在，還是將來，將集群平臺集中到VCS，可以大大簡化我們的日常集群管理工作。我們的技術(shù)人員不必再需要針對每一種平臺，學(xué)習(xí)不同的集群軟件管理和問題診斷的方法；我們企業(yè)，也不再需要針對每一種平臺，都花錢培養(yǎng)相應(yīng)的集群軟件管理員了。附件：VERITAS Cluster Server簡介業(yè)界領(lǐng)先的企業(yè)高可用應(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)格的正常運行要求。鑒于用戶需要以電子方式獲取更多的服務(wù)，提升應(yīng)用正常運行水平的需求也

59、急劇增長。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)境，靈活地保護(hù)從單一數(shù)據(jù)庫實例到大型多應(yīng)用集群的所有部件。它既能夠獨立使用，又能與許多成龍配套的VERITAS 軟件解決方案相整合，因此在為當(dāng)今的混合型計算環(huán)境提供高可用性和災(zāi)難恢

60、復(fù)方面，發(fā)揮至關(guān)重要的作用。VERITAS Cluster Server產(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ū)站點間或全球范圍內(nèi)，為單一站點的256個集群提供監(jiān)控和遷移。廣泛的應(yīng)用支持當(dāng)前支持廣泛系列的應(yīng)用，其中包括Oracle、Sybase、DB2、I