【文章內(nèi)容簡介】 最佳 從性能上來分析，在操作系統(tǒng)一級進行鏡像，數(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 到復(fù)制協(xié)議的轉(zhuǎn)換過程，無論在流程上和反應(yīng)時間上都會比直接鏡像造成更多的延時，對應(yīng)用系統(tǒng)有更大的影響。 另外，在邏輯卷這個層面，我們可以根據(jù)需要對鏡像的數(shù)據(jù)靈活設(shè)置，我們不需將所有磁盤進行鏡像，而只需鏡像必要的邏輯卷（Volume） 。這種靈活性在實際使用過程中將大大減少數(shù)據(jù)遠程復(fù)制的數(shù)量，從而避免對系統(tǒng)不必要的影響。同 城 應(yīng) 用 容 災(zāi) 系 統(tǒng) 方 案 第 18 頁 共 41 頁 對 系 統(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)廠商人為的夸大了。具體的事實我們可以通過簡單的測試得到，我們可以設(shè)置這樣一個測試，就一目了然了：1）在測試系統(tǒng)上，往一個沒有鏡像的邏輯卷 Copy 一個大文件，察看 CPU 使用率；2）在測試系統(tǒng)上，往一個有鏡像的邏輯卷上 Copy 一個大文件，察看 CPU 使用率。 事實上，處理鏡像需要的 CPU 時間是非常非常小的，原因是磁盤 I/O 操作的速度是毫秒（ms）級的，磁盤系統(tǒng) Cache I/O 的速度是受限于光纖通道的 100200MB（8bit*10ns）帶寬和距離（15公里 == ）的，而相反的，高端主機總線的寬度一般是 64128Byte，甚至更高，主機 CPU 的處理速度更是在千兆的水平（ns 級） ，所以 I/O 對主機 CPU 的消耗往往都是可以忽略不計的，如果說需要關(guān)心的話，也主要針對象 RAID5 這樣的技術(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)生的負面作用，而是“距離” ，正如前面提到的，在 Cache 命中率較高的系統(tǒng)中，距離對寫操作的影響較大，這和光的傳播速度有關(guān)，光在 150 公里距離上的一個來回需要 1ms，在 15KM 距離上一個來回需要 ，我們列出一個對照表，供大家參考。本對照表不包含設(shè)備協(xié)議轉(zhuǎn)換和光在光纖中的折射等因素。同時，我們知道，100MB 光纖對應(yīng)的速度是 ns 級的。同 城 應(yīng) 用 容 災(zāi) 系 統(tǒng) 方 案 第 19 頁 共 41 頁距離 光傳輸距離 傳輸時間 說明15 km 30 km 100us 同城容災(zāi)中心的距離級別150 m 300 m 1us15 m 30 m 100ns 一個機房的內(nèi)部距離 m 3 m 10ns 一個主板的內(nèi)部距離本地 Cache 寫的時間 ns~us 級本地磁盤寫的時間 us~ms 級 綜上所述，我們的結(jié)論是，只要是數(shù)據(jù)復(fù)制方式的同步方式能夠做的系統(tǒng)，采用鏡像方式也一定能做，而且會做的更好。 容 災(zāi) 案 例? 中國銀聯(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 提供的這套超遠程容災(zāi)方案是國內(nèi)目前業(yè)界唯一真正已實施的超遠程容災(zāi)方案。要實現(xiàn)這種方案，我們只需要在現(xiàn)有的 Volume Manager的基礎(chǔ)上增加 VVR 模塊，體現(xiàn)了技術(shù)和方案的延續(xù)性。? 上海熱線的容災(zāi)系統(tǒng)? 公安部某應(yīng)用系統(tǒng)從上海到廣東南海的遠程容災(zāi)項目同 城 應(yīng) 用 容 災(zāi) 系 統(tǒng) 方 案 第 20 頁 共 41 頁、 構(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ī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)上輸入幾個命令來完成的，而集群軟件為這種需要提供了行之有效的方法。 本地的主服務(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)故障” ，它可能是任何情況。所以災(zāi)備中心的接管流程要求：同 城 應(yīng) 用 容 災(zāi) 系 統(tǒng) 方 案 第 21 頁 共 41 頁1）全面，包括簡單的，也包括復(fù)雜的；2）盡量提供簡單的流程。? 管理難度大生產(chǎn)中心和災(zāi)備中心兩套系統(tǒng)完全孤立，沒有辦法同時監(jiān)控，更不用說在一個界面上對這些系統(tǒng)統(tǒng)一監(jiā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)建的集群系統(tǒng)在邏輯上也是完全相同的。 城域范圍內(nèi)和鏡像技術(shù)配套的集群技術(shù)，和用于遠程復(fù)制技術(shù)下構(gòu)建遠程集群的技術(shù)不同，我們這里推薦的城域范圍的集群系統(tǒng)不是傳統(tǒng)的遠程集群模式，而是傳統(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)的可靠性。下圖為利用 VERITAS 集群軟件 VERITAS Cluster Server (VCS) 進行集群管理的一個界面示意，通過該界面，我們可以知道，利用 VCS，我們可以非常方便的管理生產(chǎn)中心和災(zāi)備中心的系統(tǒng)，并將生產(chǎn)中心和災(zāi)備中心納入到統(tǒng)一個集群管理體系內(nèi)進行統(tǒng)一管理。同 城 應(yīng) 用 容 災(zāi) 系 統(tǒng) 方 案 第 22 頁 共 41 頁當(dāng)然，在我們構(gòu)建這個“準(zhǔn)本地集群系統(tǒng)”的時候，我們還是要正視由“距離”引起的一切問題，我們需要在技術(shù)層面去解決它，這也是為什么我們在方案中建議的集群軟件是和本地集群完全相同的 VERITAS Cluster Server 軟件，但卻稱這種集群模式為準(zhǔn)本地集群模式的原因。 建 立 覆 蓋 災(zāi) 備 中 心 的 統(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)的功能上有新的擴展，以便滿足城域環(huán)境下的特殊要求。我們現(xiàn)在分析一下同城集群系統(tǒng)和本地集群系統(tǒng)的區(qū)別，然后再來分析需要怎樣的技術(shù)擴展。同 城 應(yīng) 用 容 災(zāi) 系 統(tǒng) 方 案 第 23 頁 共 41 頁 在磁盤鏡像結(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)詳細闡述，這里不再說明）：1． 集群系統(tǒng)的心跳線需要跨越幾十公里，而不是幾十米2． 同城生產(chǎn)中心和災(zāi)備中心的網(wǎng)絡(luò)更容易因意外而中斷，其中包括心跳線 這兩個因為距離而產(chǎn)生的新問題，需要我們在構(gòu)建集群系統(tǒng)時，不得不從技術(shù)層面仔細分析，以便保證我們推薦的方案的可靠性和可行性。下面，我們就這兩個問題從技術(shù)層面展開討論。 跨 越 幾 十 公 里 的 心 跳 技 術(shù) 支 持 城域集群將跨越幾十公里，這對集群心跳的技術(shù)要求非常簡單，就是要求集群軟件能夠支持跨越幾十公里的心跳技術(shù)。 VERITAS Cluster Server 能夠很好的支持遠程心跳通道，VCS 對遠程心跳通道只有一個要求，就是支持廣播。也就是說，只要兩個 Site 之間有不經(jīng)過路由器、橋這樣的設(shè)備的通道，就可以支持 VCS 的心跳。 需要說明的是，我們這里需要心跳的動機和傳統(tǒng)的心跳技術(shù)的目的不同，傳統(tǒng)的集群心跳的目的包括：1． 同步集群配置信息和集群狀態(tài)信息2． 監(jiān)控 Active 的業(yè)務(wù)服務(wù)器是否運行正常3． 根據(jù)監(jiān)控信息，激發(fā)集群在主業(yè)務(wù)服務(wù)器系統(tǒng)沒有相應(yīng)的時候，自動切換服務(wù)器。 但是，我們這里需要心跳的目的只包含前兩條，而不包含最后一條，原因是我們的生產(chǎn)中心災(zāi)難后的切換，應(yīng)該是在人工確認后手動發(fā)起的，我們不需要自動切換。但不管怎樣，我們還是需要心跳來構(gòu)建這樣的集群系統(tǒng)。同 城 應(yīng) 用 容 災(zāi) 系 統(tǒng) 方 案 第 24 頁 共 41 頁 為 什 么 需 要 人 工 確 認 災(zāi) 難 我們好像已經(jīng)已經(jīng)習(xí)慣了“生產(chǎn)中心到災(zāi)備中心的切換需要人工確認的”這個規(guī)則了，我們也已經(jīng)習(xí)慣了“如果不經(jīng)過人工確認，就有可能導(dǎo)致誤操作”這種說法了，但是為什么本地集群系統(tǒng)就可以自動切換呢？我們的“準(zhǔn)本地集群系統(tǒng)”和真正的本地集群系統(tǒng)在邏輯上是相同的，為什么我們還是需要堅持采用“災(zāi)難人工確認”原則呢？ 其實，在“沒有必要自動切換”的說法背后，其真正原因是：凡是遠距離的集群系統(tǒng)，都無法象本地集群系統(tǒng)那樣，可以提供足夠可靠的心跳通道。 我們知道，本地集群系統(tǒng)可以提供多種冗余技術(shù)，保證心跳通道不在同一時間一起中斷，常見的心跳冗余技術(shù)有：1． 采用雙以太網(wǎng)卡作為冗余心跳通道2． 采用雙 RS232 端口作為冗余心跳通道3． 采用公網(wǎng)（業(yè)務(wù)以太網(wǎng)通道）作為輔助冗余心跳通道4． 采用共享磁盤作為輔助冗余心跳通道 相對而言，遠程集群系統(tǒng)除了能夠利用遠距離以太網(wǎng)連接作為心跳以外，就沒有其他冗余措施了，我們知道，城域范圍的網(wǎng)絡(luò)本身的可靠性要比一個信息中心內(nèi)部的專用網(wǎng)絡(luò)的可靠性低很多的，而且具有更多的不確定性，比如，一次光纖事故就可能會導(dǎo)致所有的心跳通道同時中斷。 如果我們無法保證心跳通道的可靠性，那么就有可能出現(xiàn)因為心跳通道本身的故障而引起的“虛假災(zāi)難” ，也就是說，當(dāng)主業(yè)務(wù)系統(tǒng)實際在正常運行的情況下，備用系統(tǒng)卻因為無法收到對方的心跳而認為對方已經(jīng)“停止運行” ，