【正文】 ． 采用雙以太網卡作為冗余心跳通道2． 采用雙 RS232 端口作為冗余心跳通道3． 采用公網（業(yè)務以太網通道）作為輔助冗余心跳通道4． 采用共享磁盤作為輔助冗余心跳通道 相對而言，遠程集群系統(tǒng)除了能夠利用遠距離以太網連接作為心跳以外，就沒有其他冗余措施了，我們知道，城域范圍的網絡本身的可靠性要比一個信息中心內部的專用網絡的可靠性低很多的，而且具有更多的不確定性，比如，一次光纖事故就可能會導致所有的心跳通道同時中斷。但不管怎樣，我們還是需要心跳來構建這樣的集群系統(tǒng)。 需要說明的是，我們這里需要心跳的動機和傳統(tǒng)的心跳技術的目的不同，傳統(tǒng)的集群心跳的目的包括：1． 同步集群配置信息和集群狀態(tài)信息2． 監(jiān)控 Active 的業(yè)務服務器是否運行正常3． 根據(jù)監(jiān)控信息，激發(fā)集群在主業(yè)務服務器系統(tǒng)沒有相應的時候，自動切換服務器。 VERITAS Cluster Server 能夠很好的支持遠程心跳通道，VCS 對遠程心跳通道只有一個要求，就是支持廣播。下面，我們就這兩個問題從技術層面展開討論。我們現(xiàn)在分析一下同城集群系統(tǒng)和本地集群系統(tǒng)的區(qū)別，然后再來分析需要怎樣的技術擴展。 建 立 覆 蓋 災 備 中 心 的 統(tǒng) 一 集 群 體 系 為了有效的管理災備中心，同時保證在災難發(fā)生的時候，能夠在要求的時間里快速的恢復系統(tǒng)的正常運行，我們需要建立一個橫跨業(yè)務中心和災備中心的“準本地集群系統(tǒng)” ，這里，我們建議采用通用的本地高可用集群軟件（也稱 HA 軟件） ，構建的應用容災系統(tǒng)。下圖為利用 VERITAS 集群軟件 VERITAS Cluster Server (VCS) 進行集群管理的一個界面示意，通過該界面，我們可以知道，利用 VCS，我們可以非常方便的管理生產中心和災備中心的系統(tǒng)，并將生產中心和災備中心納入到統(tǒng)一個集群管理體系內進行統(tǒng)一管理。 “準本地集群”模式實際上和大家非常熟悉的本地集群模式是一樣的，在這種模式下，生產中心的系統(tǒng)和災備中心的系統(tǒng)將被納入同一個集群主體中，從而我們可以非常輕松的實現(xiàn)對兩個中心的統(tǒng)一管理。實際上，它所采用的軟件產品和基本技術，完全就是本地集群軟件，只是，我們需要這些集群軟件提供必要的功能擴展，以滿足城域范圍的特定的需要。就如同我們在一開始所講的，在城域 SAN 網絡上構建的鏡像系統(tǒng)和在同一個機房內部構建的鏡像系統(tǒng)在邏輯上是完全相同的，同樣的，我們要推薦的在城域 SAN 網絡上構建的集群系統(tǒng)和在同一個機房內部構建的集群系統(tǒng)在邏輯上也是完全相同的。? 管理難度大生產中心和災備中心兩套系統(tǒng)完全孤立，沒有辦法同時監(jiān)控，更不用說在一個界面上對這些系統(tǒng)統(tǒng)一監(jiān)控和管理了，我們難以同時對兩地配置進行跟蹤和修改，無謂的增加了災備系統(tǒng)維護的難度和強度。我們知道，我們建設的是“災難”備用系統(tǒng)，災難的定義不是簡單的“磁盤系統(tǒng)故障” ，它可能是任何情況。這種手工操作方式不利于災備中心的可靠性、穩(wěn)健性。一個系統(tǒng)對另外一個系統(tǒng)的順利接管，需要日常的、長期的維護和精心的準備，而不是簡單的在備用系統(tǒng)上輸入幾個命令來完成的，而集群軟件為這種需要提供了行之有效的方法。這種風險將直接導致災備中心在災難發(fā)生時不能準確、及時地接管業(yè)務系統(tǒng)，這和我們建立該容災中心的基本要求“必須保證容災中心在一小時以內全面接管生產中心的作用”是相背的。? 兩套系統(tǒng)配置難以完全同步的風險 對兩套系統(tǒng)的管理是孤立的，而這兩套系統(tǒng)應該是在各方面都相同的并嚴格的一一對應的。要實現(xiàn)這種方案，我們只需要在現(xiàn)有的 Volume Manager的基礎上增加 VVR 模塊，體現(xiàn)了技術和方案的延續(xù)性。? 蕪湖卷煙廠信息系統(tǒng)的同城容災項目 另外，VERITAS 擁有豐富的容災系統(tǒng)實施經驗，我們參與的容災項目除了采用鏡像方式的，還有利用傳統(tǒng)的數(shù)據(jù)復制方式構建的容災系統(tǒng)，包括：? 中國聯(lián)通光傳輸網絡系統(tǒng)中國聯(lián)通光傳輸網絡的容災系統(tǒng)是由 VEITAS 通過華為提供的，這個方案是跨省際的，其中一個容災項目的生產中心和災備中心分別在北京和廣州。同 城 應 用 容 災 系 統(tǒng) 方 案 第 19 頁 共 41 頁距離 光傳輸距離 傳輸時間 說明15 km 30 km 100us 同城容災中心的距離級別150 m 300 m 1us15 m 30 m 100ns 一個機房的內部距離 m 3 m 10ns 一個主板的內部距離本地 Cache 寫的時間 ns~us 級本地磁盤寫的時間 us~ms 級 綜上所述，我們的結論是，只要是數(shù)據(jù)復制方式的同步方式能夠做的系統(tǒng)，采用鏡像方式也一定能做，而且會做的更好。本對照表不包含設備協(xié)議轉換和光在光纖中的折射等因素。? I/O 的延遲效應（特別是寫操作的延遲效應） 采用 VERITAS Volume Manager 的鏡像技術構建容災系統(tǒng)，其對系統(tǒng) I/O 的延遲效應要小于任何一種數(shù)據(jù)復制技術，不管是基于磁盤系統(tǒng)的硬件數(shù)據(jù)復制技術，還是基于主機軟件的數(shù)據(jù)復制技術，這在上一節(jié)中已經闡述。具體的事實我們可以通過簡單的測試得到，我們可以設置這樣一個測試，就一目了然了：1）在測試系統(tǒng)上，往一個沒有鏡像的邏輯卷 Copy 一個大文件，察看 CPU 使用率；2）在測試系統(tǒng)上，往一個有鏡像的邏輯卷上 Copy 一個大文件，察看 CPU 使用率。同 城 應 用 容 災 系 統(tǒng) 方 案 第 18 頁 共 41 頁 對 系 統(tǒng) 性 能 的 影 響 大家都比較關心容災系統(tǒng)建立以后對原有業(yè)務系統(tǒng)性能的影響，考察容災系統(tǒng)對業(yè)務系統(tǒng)性能的影響，主要從兩個方面衡量，一是 CPU 資源的消耗，二是 I/O，特別是寫操作的延遲效應。 另外，在邏輯卷這個層面，我們可以根據(jù)需要對鏡像的數(shù)據(jù)靈活設置，我們不需將所有磁盤進行鏡像，而只需鏡像必要的邏輯卷（Volume） 。數(shù)據(jù)可寫入過程是兩組并行的操作，即本地寫和完成信號返回+異地寫和完成信號返回。另外，由于在災難發(fā)生時，數(shù)據(jù)庫系統(tǒng)的復制是即刻停止的，數(shù)據(jù)庫系統(tǒng)沒有經過正常的 Shutdown，所以不僅不可避免的導致部分交易的損失，甚至還有可能導致數(shù)據(jù)庫的損壞。同 城 應 用 容 災 系 統(tǒng) 方 案 第 17 頁 共 41 頁? 應對災難，應用不中斷，數(shù)據(jù)不丟失 VERITAS 建議的容災方案，不會因為生產中心（或者災備中心）磁盤系統(tǒng)的故障和災難而導致應用和數(shù)據(jù)庫的異常中止，這不僅避免了對應用系統(tǒng)正常運作的影響，還避免了發(fā)生數(shù)據(jù)庫損壞的可能。 VERITAS Volume Manager VEA 提供企業(yè)范圍內全局的邏輯卷管理視圖，通過任何一臺安裝有Volume Manager 或者其 Console 的系統(tǒng)，我們就可以訪問我們想要訪問的系統(tǒng)的（被授權）邏輯卷，這意味著，我們可以將同一個應用的生產系統(tǒng)和災備系統(tǒng)的邏輯卷置于同一個管理視圖中，從而實現(xiàn)對生產中心和災備中心存儲的統(tǒng)一管理。同 城 應 用 容 災 系 統(tǒng) 方 案 第 16 頁 共 41 頁? 技術的完整性 VERITAS Volume Manager 擁有一個容災方案必須的所有技術特性，它不僅可以提供可靠的鏡像技術，實現(xiàn)跨磁盤系統(tǒng)的數(shù)據(jù)容災，同時，我們可以利用 Volume Manager 的 DCO 和 FMR 技術，保證該容災系統(tǒng)的可維護性。? 存儲開放性 利用 VERITAS Volume Manager 的鏡像技術，我們構建容災方案時，不再要求生產系統(tǒng)和災備系統(tǒng)的存儲系統(tǒng)必須是同一個品牌的，對具體型號更沒有任何要求，體現(xiàn)了存儲平臺選擇的開放性。事實上，基于主機的復制技術存在同樣的問題。 比如基于磁盤系統(tǒng)復制技術的容災方案，我們必須在磁盤系統(tǒng)內部專門配置相應的接口卡，使用該磁盤系統(tǒng)專有的復制軟件，才可以構建容災系統(tǒng)。? 結構簡單 VERITAS 推薦的基于鏡像的容災方案較任何一種容災方案為簡單。利用 DCO 和 FMR，針對同樣的鏈路問題，我們的應對步驟如下：1． SAN 鏈路發(fā)生故障2． 生產中心的 Volume Manager 利用 DCO 日志記錄 Volume : Plex 1 因業(yè)務數(shù)據(jù)的變化而變化的數(shù)據(jù)塊，災備端 Volume : Plex 2 的數(shù)據(jù)不會作廢3． 一旦 SAN 鏈路恢復正常，Volume Manager 的 FMR 功能模塊，會根據(jù) DCO 日志記錄的情況，將 Volume : Plex 1 中鏈路中斷后更新的業(yè)務數(shù)據(jù)拷貝到災備端 Volume : Plex 2，實現(xiàn)增量更新。 為了解決這個問題，VERITAS Volume Manager 提供了 DCO+FMR 技術，其中 DCO（Data Change Object）是一種針對鏡像的 Log 技術，該技術允許 Volume Manager 在鏡像鏈路中斷后記錄邏輯卷的數(shù)據(jù)變化情況，以便在鏡像鏈路恢復后，由 FMR 實現(xiàn)數(shù)據(jù)的增量恢復。 這將對業(yè)務系統(tǒng)的 I/O 性能造成不必要的影響，鏈路方面的故障如果經常發(fā)生，我們就需要不斷的重復將生產中心的數(shù)據(jù)全部同步到災備中心的磁盤系統(tǒng)上，實際上，這種方案不具有可實施性和可維護性，是不現(xiàn)實的。而對于鏈路故障，直接導致的就是業(yè)務數(shù)據(jù)在寫到本地磁盤系同 城 應 用 容 災 系 統(tǒng) 方 案 第 13 頁 共 41 頁統(tǒng)的同時，無法寫到災備系統(tǒng)中，對于鏡像技術而言，這又成為一個新的課題。這個問題其實是由“距離”引起的，正如我們在前面討論的那樣，雖然在原理上，基于城域 SAN 網絡實現(xiàn)的鏡像技術和基于本地 SAN 網絡實現(xiàn)的鏡像技術完全一樣，但是，我們還是不得不承認，他們是有區(qū)別的，因為我們很少會擔心一個機房內部不同磁盤系統(tǒng)之間的鏡像會遭遇鏈路故障，而在城域范圍，我們是無法回避這個問題的。生產中心和災備中心 SAN 鏈路故障 這種故障也是災備系統(tǒng)建立以后出現(xiàn)的新問題。這是基于磁盤系統(tǒng)間復制技術構建的容災系統(tǒng)無法實現(xiàn)的。 生產中心磁盤系統(tǒng)故障之后，我們只需要更換損壞的磁盤系統(tǒng)，然后利用 Volume Manager 重新生成鏡像即可，重新生成鏡像的過程，實際上就是將數(shù)據(jù)從災備中心磁盤系統(tǒng)復制到生產中心磁盤系統(tǒng)的過程。從上圖我們看到，業(yè)務系統(tǒng)可以通過城域 SAN 網絡直接訪問災備中心的磁盤系統(tǒng)的數(shù)據(jù)，而不需要有任何針對業(yè)務系統(tǒng)的動作。 下面，我們來看一下，在各種數(shù)據(jù)系統(tǒng)（本節(jié)暫時不討論應用系統(tǒng)全面災難的應對，我們把它放到下一節(jié)中另行展開討論）故障和災難情況下，容災系統(tǒng)是怎樣響應的。同 城 應 用 容 災 系 統(tǒng) 方 案 第 11 頁 共 41 頁采用這種方式，生產中心的磁盤陣列與同城容災中心的磁盤陣列對于兩地的主機而言是完全同等的。這里，邏輯卷“Volume A”是業(yè)務系統(tǒng)訪問磁盤的邏輯設備名，在 VERITAS Volume Manager 管理下的磁盤系統(tǒng)，所有業(yè)務系統(tǒng)對磁盤系統(tǒng)的訪問，都將通過 Volume 實現(xiàn)。 利用光纖將生產中心和災備中心的 SAN 網絡連接起來，構成城域 SAN 網絡以后，利用 VERITAS Volume Manager 的先進的邏輯卷管理功能，我們就可以非常方便的實現(xiàn)生產中心磁盤系統(tǒng)和災備中心磁盤系統(tǒng)之間的鏡像了。然后，我們就可以通過 Volume Manager 提供的非常成熟的跨陣列磁盤鏡像技術來實現(xiàn)同城容災了，容災方案的結構如下圖所示：同 城 應 用 容 災 系 統(tǒng) 方 案 第 10 頁 共 41 頁 從原理上講，在城域 SAN 存儲網絡上的兩套磁盤系統(tǒng)之間的鏡像，和在一個機房內的 SAN 上的兩個磁盤系統(tǒng)之間的鏡像并沒有任何區(qū)別。、 數(shù) 據(jù) 容 災 方 案 的 實 現(xiàn) 方 案 的 結 構 原 理 VERITAS 建議利用 VERITAS Volume Manager 軟件的鏡像技術，來構建 IT 系統(tǒng)的容災方案。每臺服務器需要配置 1 個 LICENSE.同 城 應 用 容 災 系 統(tǒng) 方 案 第 9 頁 共 41 頁四 、 VERITAS 基 于 鏡 像 技 術 的 容 災 方 案 及 其 實 現(xiàn) 基于鏡像技術實現(xiàn)容災，從技術實現(xiàn)上，分為兩個部分，其一是數(shù)據(jù)的容災實現(xiàn)，其二是應用級容災實現(xiàn)。同時 Veritas 高速文件系統(tǒng)也能提高數(shù)據(jù)訪問和讀寫的性能。有關問題和解決方法，我們會在下一節(jié)中詳細論述，這里我們先簡單的把要求提出來，供參考。距離會影響我們管理一個系統(tǒng)的復雜性和現(xiàn)場感 遠距離災備系統(tǒng)永遠都是生產中心的附屬品，如果我們不能將其用直觀的方式納入到日常的管理體系中，很快我們就會發(fā)現(xiàn)我們對生產系統(tǒng)和災備系統(tǒng)的管理會脫節(jié)，所以，容災系統(tǒng)肯定不僅僅是鏡像那么簡單，他需要一個完整的、直觀的管理界面去管理，才能形成一個行之有效有的災備系統(tǒng)。不是說我們已經解決了距離的問題嗎？是的，我們在技術上已經解決了遠距離數(shù)據(jù)鏡像的問題，但是，有幾個問題是任何技術都必須考慮的，不管是鏡像技術還是復制技術，包括：距離決定了鏈路的可靠性。同 城 應 用 容 災 系 統(tǒng) 方 案 第 7 頁 共 41 頁 構 建 容 災 系 統(tǒng) 的 技 術 要 求 基于磁盤鏡像技術構建容災系統(tǒng)，在數(shù)據(jù)系統(tǒng)容錯實現(xiàn)的邏輯上，和本地磁盤系統(tǒng)間的鏡像沒有任何區(qū)別，所以我們大可以放心的去構建這樣的系統(tǒng)。? 基于磁盤系統(tǒng)的數(shù)據(jù)復制技術，要求生產中心和災備中心選用同一個廠商的磁盤系統(tǒng)，甚至要求選用同一系列、同一型號的磁盤系統(tǒng)，用戶完全失去討價還價的余地，完全失去了在任何時候自由、靈活地選擇合作廠商和磁盤系統(tǒng)的權利，必然給用戶造成被動和經濟上