知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 上海移動容災(zāi)系 統(tǒng) 方案設(shè)計報 告 IBM 公司上海分公司 Version 5.0 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 IBM專 有 信息 聲 明 本設(shè)計報 告 屬商業(yè)機 密 文件，書 中 的所有信 息 均 為 IBM機 密信息， 僅 供上 海 移動容災(zāi)項目使用 。務(wù)請妥善保管并且僅在與項目有關(guān)人員范圍內(nèi)使用 ，未經(jīng) IBM 公司明確做出的書面許可 ， 不得為任何目的 、 以任何形式或手 段 （包括電子 、 機 械 、 復(fù)印 、 錄音或其他形式 ） 對本文檔的任何部分進(jìn)行復(fù)制 、 存儲 、 引入檢索系 統(tǒng)或 者傳播。 盡管 IBM已 經(jīng)盡力保 證 本文檔內(nèi) 容 的完整性 和 有效性， 但 仍可能存 在 某 些 方 面不夠 準(zhǔn)確 的地方 或印 刷錯誤 。若 需求有 所變 化， IBM將 對有關(guān) 內(nèi)容 進(jìn)行相對 應(yīng) 的調(diào)整，并在本報告的未來版本中體現(xiàn)。 IBM是國 際 商業(yè)機器 公 司的注冊 商 標(biāo)。本文 檔 提及的其 他 公 司 、產(chǎn) 品 和服 務(wù) 的名稱，可能是其他公司的商標(biāo)或服務(wù)的標(biāo)志。 Copyright IBM China Company Limited All rights reserved 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 關(guān)于本文檔 文檔信息 文 檔 名 稱 上海移動容災(zāi)系統(tǒng)方案設(shè)計報告 作者 IBM全球服務(wù)部 說明 本文檔是上海移動容災(zāi)系統(tǒng)方案設(shè)計報告 ， 由 IBM公司上海 分公司和上海移動容災(zāi)系統(tǒng)項目組共同編寫。 文 件 名稱 上海移動容災(zāi)系統(tǒng)方案設(shè)計報告 v5.0.doc 怱 訂 歷史 (REVISION HISTORY) Rev Section Type Date Author Remarks 1.0 All New 2004-09-13 IBM SHMCC team 創(chuàng) 建 方 案 第 一 版 本。 2.0 All Revis ed 2004-09-22 IBM SHMCC team 根據(jù) 客戶 反饋 怱 改 而成 3.0- 3.1 All Revis ed 2004-09-27 IBM SHMCC team 根據(jù) 客戶 反饋 怱 改 而成， 增 加 存 儲管 樅 和 災(zāi) 難 恢 復(fù) 計 劃，網(wǎng) 絡(luò) 設(shè)計考 慮 多種方案 4.0 ALL Revis ed 2004-10-08 IBM SHMCC team 整樅版本 5.0 All Revis ed 2004-10-25 IBM SHMCC team 加入 摘要 ，加 強 存 儲管樅內(nèi)容。 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 內(nèi)容范圍 本文檔是上海移動容災(zāi)系統(tǒng)方案設(shè)計報告，屬于機密文件。 適用的對象 本文檔適用于參與上海移動容災(zāi)項目組的決策者、評估者。 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 目錄 1 摘要 7 2 容災(zāi)系統(tǒng)建設(shè)意義 8 3 容災(zāi)技術(shù)方案選型 12 3.1 容災(zāi)系統(tǒng)架構(gòu)方案設(shè)計范圍 12 3.2 容災(zāi)技術(shù)方案設(shè)計方法 12 3.3 容災(zāi)系統(tǒng)建設(shè)目標(biāo) 12 3.4 容災(zāi) 7 層技術(shù)模型介紹 13 3.5 容災(zāi)技術(shù)方案選型考慮 16 4 容災(zāi)系統(tǒng)方案設(shè)計 23 4.1 上海移動系統(tǒng)現(xiàn) 狀 23 4.2 容災(zāi)架構(gòu)整體設(shè)計 24 4.3 容災(zāi)系統(tǒng)詳細(xì)設(shè)計 31 4.3.1 本地數(shù)據(jù)庫容災(zāi) 31 3.3.2 容災(zāi)系統(tǒng)主機設(shè)計 32 4.3.2 容災(zāi)系統(tǒng)存儲設(shè)計 46 3.3.4 容災(zāi)系統(tǒng)網(wǎng)絡(luò)設(shè)計 53 4.4 容災(zāi)系統(tǒng)備份方案設(shè)計 71 4.4.1 數(shù)據(jù)備份概述 71 4.4.2 備份系統(tǒng)現(xiàn)狀分析 73 4.4.3 容災(zāi)備份系統(tǒng)邏輯設(shè)計 75 4.4.4 容災(zāi)備份系統(tǒng)配置設(shè)計 82 4.4.5 容災(zāi)備份系統(tǒng)專業(yè)服務(wù) 84 4.5 容災(zāi)系統(tǒng)管理方案設(shè)計 86 4.5.1 存儲資源管理 86 4.5.2 存儲網(wǎng)絡(luò)管理 91 5 容災(zāi)系統(tǒng)實施計劃 94 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 5.1 災(zāi)難恢復(fù)計劃 94 5.2 上海移動容災(zāi)項目實施計劃 95 6 附錄 96 6.1 機房工程技術(shù)說明 96 6.2 上海移動業(yè)務(wù)支撐系統(tǒng)平臺現(xiàn)狀概況一覽表。 105 6.3 IBM 項目管理服務(wù) 107 6.4 支持多廠商的網(wǎng)絡(luò)存儲通用管理軟件 SANavigator 版本 114 6.5 容災(zāi)系統(tǒng)管理方案設(shè)計 121 6.5.1 系統(tǒng) 管理現(xiàn)狀 121 6.5.2 系統(tǒng)管理需求 122 6.5.3 系統(tǒng)管理架構(gòu)建議 123 6.5.4 事件管理 126 6.5.5 網(wǎng)絡(luò)管理 128 6.5.6 數(shù)據(jù)庫管理 129 6.5.7 主機系統(tǒng)監(jiān)控 131 6.5.8 SLA 管理 133 6.5.9 BOSS 應(yīng) 用 管理 134 6.5.10 流程管理 134 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 1 摘要 一、項 目 背景 隨著電信市場的開放以及中國加入 WTO 進(jìn)程的進(jìn)行，中國移動通信面臨著前 所未有的發(fā)展機遇和挑戰(zhàn)。作為一個電 信運營商，其 IT 系統(tǒng)的應(yīng)用直接關(guān)乎管 理、服務(wù)、成本、效率等各個重要環(huán)節(jié)，并最終全面影響運營商的競爭力。電信 行業(yè)是一個講究系統(tǒng)高可用性的行業(yè)，它要求關(guān)鍵應(yīng)用服務(wù)器必須 24 7 的不間 斷運行，以滿足超大量用戶的實時訪問，任何潛在的單點故障都有可能導(dǎo)致整個 系統(tǒng)的癱瘓。為了保證信息系統(tǒng)的穩(wěn)定和數(shù)據(jù)的安全，提高業(yè)務(wù)運營系統(tǒng)的服務(wù) 質(zhì)量，確保在日益激烈的市場競爭中確立主導(dǎo)地位，上海移動決定在現(xiàn)有業(yè)務(wù)運 營支撐系統(tǒng)的基礎(chǔ)上，結(jié)合自身的特點和實踐經(jīng)驗進(jìn)行上海移動業(yè)務(wù)運營支撐容 災(zāi)系統(tǒng)工程的建設(shè)。 本次上海移動 業(yè)務(wù)運營支撐容災(zāi)系統(tǒng)工程的目標(biāo)，是按照移動集團公司 BOSS 系統(tǒng)容災(zāi)備份技術(shù)規(guī)范和業(yè)務(wù)規(guī)范，主要考慮中國移動業(yè)務(wù)支撐網(wǎng)中的 BOSS 系統(tǒng)，兼顧經(jīng)營分析系統(tǒng)。對于 BOSS 系統(tǒng)，將主要考慮其中的營帳子系統(tǒng)， 計費子系統(tǒng)，充值子系統(tǒng)， 1860 子系統(tǒng) ,綜合結(jié)算中的網(wǎng)間結(jié)算子系統(tǒng)。整個容災(zāi)系統(tǒng)建設(shè)將遵循統(tǒng)一規(guī)劃，分步實施的原則。 二、本 設(shè) 計報告 內(nèi) 容結(jié)構(gòu) 本容災(zāi)設(shè)計報告主要分為四大部分：容災(zāi)系統(tǒng)建設(shè)意義、容災(zāi)技術(shù)方案選型、 容災(zāi)系統(tǒng)方案設(shè)計以及容災(zāi)系統(tǒng)實施計劃。 容災(zāi)系統(tǒng)建設(shè)意義部分主要從行業(yè)競爭需要、 業(yè)務(wù)穩(wěn)定需要和企業(yè)管理需要 三方面闡述了容災(zāi)系統(tǒng)的建設(shè)意義。 容災(zāi)技術(shù)方案選型部分主要根據(jù)上海移動 BOSS 系統(tǒng)的現(xiàn)狀和將來的發(fā)展并 滿足對應(yīng)用和在用系統(tǒng)影響最小以及生產(chǎn)系統(tǒng)變動的需要推薦使用存儲層 +數(shù)據(jù) 庫層的復(fù)合容災(zāi)方案。 容災(zāi)系統(tǒng)方案設(shè)計部分主要針對上海移動 BOSS 系統(tǒng)的各個子系統(tǒng)提出了各 自的容災(zāi)架構(gòu)設(shè)計，根據(jù)各子系統(tǒng)的實時性恢復(fù)要求提出對于營帳數(shù)據(jù)庫，充值 數(shù)據(jù)庫和 1860 數(shù)據(jù)庫實施兩層容災(zāi)設(shè)計；對于計費，經(jīng)營分析，網(wǎng)間結(jié)算，批 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 價等提出存儲層的容災(zāi)設(shè)計。另外還從容災(zāi)系統(tǒng)的主機、存儲、網(wǎng) 絡(luò)、備份方案 以及存儲資源和存儲網(wǎng)絡(luò)管理方案方面作了詳細(xì)的設(shè)計。 容災(zāi)系統(tǒng)實施計劃部分介紹了如何系統(tǒng)的實施災(zāi)難恢復(fù)計劃以保證災(zāi)難發(fā) 生時業(yè)務(wù)操作地連續(xù)性。 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 2 容災(zāi)系統(tǒng)建設(shè)意義 中國有句古話叫做“天有不測風(fēng)云，人有旦夕禍?！?，充分說明災(zāi)難的不可 測性。 911 事件是對這句話的最好注腳，在里面辦公的 286 家公司的 5 萬多名員 工是根本不會想到好端端的坐在辦公室里居然會有飛機撞過來。在這種近乎毀滅 性的局部災(zāi)難面前，是否有異地容災(zāi)系統(tǒng)就變成了關(guān)乎企業(yè)生存的現(xiàn)實問題。最 近國內(nèi)也發(fā)生了類 似災(zāi)難，大連某個銀行的生產(chǎn)中心突然著火，因為沒有災(zāi)備系 統(tǒng)，造成全部業(yè)務(wù)停止兩天，這還是不幸中的萬幸，因為絕大多數(shù)機器設(shè)備經(jīng)過 修復(fù)還可以使用，尤其是存儲設(shè)備，否則，后果真是不堪設(shè)想。 很多企業(yè)是從 911 事件后開始真正認(rèn)真考慮容災(zāi)的，以往容災(zāi)系統(tǒng)的建設(shè)往 往被視為錦上添花的項目而不是一個業(yè)務(wù)可持續(xù)性運行的必須項目。我們可以吸 取的教訓(xùn)是一定要建立核心數(shù)據(jù)和業(yè)務(wù)的容災(zāi)系統(tǒng)，并且平時要加強管理和演 習(xí)，加強人員的培訓(xùn)，核心管理人員和技術(shù)的分散，以提高計算機系統(tǒng)因為天災(zāi) 或人為因素等意外事故導(dǎo)致系統(tǒng)毀壞無法運 行時的抵御能力，至少將局部地區(qū)核 心業(yè)務(wù)支持在系統(tǒng)故障時的損失減至最小。 無論是國內(nèi)還是國外的用戶，無論是政府還是企業(yè)，現(xiàn)在都在思考這樣一個 問題，那就是，假設(shè)我們的企業(yè)發(fā)生了類似的情況，我們是否有足夠的備份措施， 企業(yè)的數(shù)據(jù)是否有足夠的保障？在美國、日本等一些發(fā)達(dá)國家，對于關(guān)乎國計民 生的行業(yè)，有專門的法律要求該企業(yè)必須有災(zāi)難保護(hù)方案，（如美國是 BCC 177） 并且每年都會進(jìn)行審計和稽核。國內(nèi)因為目前還沒有類似的法律約束，很多企業(yè) 對于應(yīng)用比較重視，但是對于整體系統(tǒng)的可用性考慮得不多，甚至是一些金融企 業(yè)，當(dāng)有類似數(shù)據(jù)庫出錯等故障發(fā)生時，還依然只能通過倒磁帶的方式恢復(fù)數(shù)據(jù)。 這種情況下，丟失數(shù)據(jù)就是不可避免的了，并且由于恢復(fù)時間的漫長，對廣大客 戶承諾的服務(wù)水平又如何能夠達(dá)到？現(xiàn)在，隨著中國加入 WTO，一些國內(nèi)先進(jìn)的 有前瞻性的企業(yè)也在這方面給予了足夠的重視，如上海移動等單位。 隨著上海移動業(yè)務(wù)的飛速發(fā)展，業(yè)務(wù)對 IT 系統(tǒng)的依賴性也隨之增加，越來 越多的業(yè)務(wù)集中到生產(chǎn)主機上，對主機和存儲設(shè)備都造成了較大的壓力。當(dāng)一個 單位越來越依賴于數(shù)據(jù)處理去進(jìn)行它的業(yè)務(wù)行為時，數(shù)據(jù)處理的高可靠性和高可 用性就尤為 關(guān)鍵，大部分單位的業(yè)務(wù)處理需要數(shù)據(jù)處理的高可用性。用戶發(fā)現(xiàn)如 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 果沒有了數(shù)據(jù)處理，業(yè)務(wù)的開展變得極端困難，也許手工操作還可以使用，但那 只能用于短期的應(yīng)付，一個計算機系統(tǒng)的長期停止運轉(zhuǎn)將直接導(dǎo)致明顯的業(yè)務(wù)后 果，也許還會被追究管理責(zé)任。更為重要的是，一旦數(shù)據(jù)由于某種原因永久性丟 失，不但會給企業(yè)的運作帶來極大的困難，企業(yè)的商業(yè)信譽必將受到致命的打擊， 在競爭中處于劣勢，造成不可估量的后果。 基于這種考慮，中國移動總部提出了在各省建設(shè) BOSS 系統(tǒng)容災(zāi)備份的要求， 這個報告書就是為上海移動的容災(zāi)系統(tǒng)進(jìn)行方案設(shè) 計。本方案中將重點討論 BOSS 系統(tǒng)的詳細(xì)容災(zāi)方案，兼顧其他業(yè)務(wù)系統(tǒng)，同時根據(jù)上海移動的實際情況 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 分步實現(xiàn)。 當(dāng)然，我們考慮容災(zāi)系統(tǒng)建設(shè)時，也應(yīng)該實事求是，從實際出發(fā)。能夠防御 所有災(zāi)難的方案是不存在的，也是不現(xiàn)實的。我們認(rèn)為，計算機系統(tǒng)的災(zāi)難定義 是可以由用戶自己來定義的，各個行業(yè)可以有不同的要求。設(shè)計容災(zāi)系統(tǒng)時，應(yīng) 該基于一個合理的前提假設(shè)，譬如，在主機房發(fā)生故障時，備份機房可以保證數(shù) 據(jù)的完整性，并且可以在最短時間內(nèi)完成應(yīng)用、網(wǎng)絡(luò)和數(shù)據(jù)的接管。本方案中的 容災(zāi)系統(tǒng)正是基于這種前提來設(shè)計，我們 暫不考慮那種同時損壞主備機房的可能 性。 讓我們再來看看容災(zāi)系統(tǒng)建設(shè)的意義，這個在移動總部的容災(zāi)系統(tǒng)建設(shè)規(guī)范 中也有多次強調(diào)： 行業(yè)競爭的需要 美國明尼蘇達(dá)大學(xué)研究機構(gòu)的統(tǒng)計結(jié)果表明，對于銀行，金融，證券，電信 等行業(yè)的企業(yè)而言，如果業(yè)務(wù)停頓時間長達(dá)兩天或更長，那么 25% 的企業(yè)將立 刻因信譽和業(yè)務(wù)問題而倒閉， 40% 的企業(yè)將因為受不斷的后續(xù)因素的影響導(dǎo)致綜 合競爭力的下降而在今后兩至五年內(nèi)被淘汰，五年以后僅有 7% 的企業(yè)能夠繼續(xù) 在此行業(yè)內(nèi)生存。 目前，在國內(nèi)，通訊行業(yè)內(nèi)的競爭本來就很激烈，加之 WTO 之后，國外實力 雄厚的企業(yè)對國內(nèi)市場的窺視，將不可避免地造成企業(yè)爭奪客戶群的白熱化的局 面，因此企業(yè)總體服務(wù)的水平將是影響競爭結(jié)果的重要因素。試想，一個時不時 就會抱歉地對客戶說：“對不起，由于我們的主機系統(tǒng)有問題，您要求的業(yè)務(wù)暫 時無法辦理”的企業(yè)將無法贏得挑剔的客戶的芳心。即使在發(fā)生眾所周知的 災(zāi)害，如果系統(tǒng)也是長時間的無法恢復(fù)，也會帶來極嚴(yán)重的后果。所以， IT 系 統(tǒng)的完善程度是激烈競爭的一個最重要的前提，在此基礎(chǔ)上，企業(yè)才能開發(fā)豐富 多樣的業(yè)務(wù)品種，提供高質(zhì)量的服務(wù)水平，在競爭中取得優(yōu)勢 。不久前發(fā)生在南 京的“愛立信跳槽事件”已經(jīng)表明了中國加入 WTO 后行業(yè)競爭的殘酷性和現(xiàn)實性。 根據(jù)業(yè)務(wù)的不同，對各種程度的中心系統(tǒng)可靠性要求也不同，如從最高等級 的 X X服務(wù)，到在指定時間內(nèi)恢復(fù)。為了滿足這些要求，更好地為客 戶服務(wù)，上海移動應(yīng)當(dāng)未雨綢繆，盡早制定和建立完備的災(zāi)難恢復(fù)計劃系統(tǒng)，以增強系統(tǒng)的知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 抗災(zāi)能力，最大限度地減小損失。 業(yè)務(wù)穩(wěn)定的需要 時至今日，企業(yè)業(yè)務(wù)運營對信息系統(tǒng)的運作的依賴性越大，就對信息系統(tǒng)運 作的穩(wěn)定性和可靠性的要求越高。 而信息系統(tǒng)可用的定義已不再局限于主機設(shè) 備的可用，而是從主機，存儲，用戶終端，網(wǎng)絡(luò)設(shè)備整體的物理可用，到系統(tǒng)，數(shù)據(jù)庫，應(yīng)用軟件，用戶數(shù)據(jù)的 邏輯可用。 然而，由于各種因素的影響，小至一般性的硬件故障，大到區(qū)域性的自然災(zāi) 害，從物理的設(shè)備不可用，到邏輯的人為失誤和破壞，都可能造成整個信息系統(tǒng) 的全面癱瘓，從而導(dǎo)致業(yè)務(wù)運營的停頓。因此，同一機房中的雙主機恢復(fù)系統(tǒng)有 很多企業(yè)已經(jīng)覺得不能滿足需求，特別是因為應(yīng)用的要求而作了區(qū)域集中或全國 大集中的企業(yè)，在享受數(shù)據(jù)集中帶來的諸多好處時，同時也承擔(dān)著數(shù)據(jù)丟失或者 IT 系統(tǒng)不可用帶來的巨大風(fēng)險。從以下這份國外的 研究報告中我們可以知道這 些擔(dān)憂不是杞人憂天。這是 1996 年 Source Contingency Planning Research Inc 。 對于各種因素包括自然災(zāi)害：水災(zāi)、風(fēng)災(zāi)、地震、大雪、野火 結(jié)構(gòu)破壞：電力中斷、火災(zāi)、爆炸 操作問題：硬件問題、病毒入侵、操作失誤、人為破壞。 讓我們暫時拋開滿腦子的災(zāi)難，來考慮一下即使是機器沒有發(fā)生故障是否也是 7小時可用呢？我們認(rèn)為，現(xiàn)實環(huán)境中，這種情況也是不現(xiàn)實的，我們 經(jīng)常會進(jìn)行一些正常的日常維護(hù)活動。假設(shè)我們認(rèn)為，所有災(zāi)難都是屬于非計劃 中的系統(tǒng)不 可用，那么還有很大一部分系統(tǒng)不可用時間是屬于計劃中的，從下圖 中我們可以看到非計劃宕機只是占了 IT 系統(tǒng)不可用的 10%，而計劃中的宕機占了 90%。 如果我們有了容災(zāi)系統(tǒng)，起碼我們可以將很多計劃中的停機事件避免，如數(shù)據(jù)備份，完全可以在容災(zāi)中心進(jìn)行，同時，我們可以利用容災(zāi)中心做許多諸如新 的應(yīng)用程序測試，壓力測試等等，若是結(jié)合第二份數(shù)據(jù)鏡像功能，我們完全可以 輕松自如的在容災(zāi)中心進(jìn)行數(shù)據(jù)查詢，數(shù)據(jù)挖掘等業(yè)務(wù)。當(dāng)然，這些業(yè)務(wù)在只有 一份遠(yuǎn)程鏡像時也可以實現(xiàn)，只是需要較為仔細(xì)和復(fù)雜的操作，并且有可能暫時 中斷 鏡像等，相比之下沒有前者操作方便簡單，對生產(chǎn)系統(tǒng)的沖突更小。知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 Definition of Outages Most Customer Outages are caused by D ata Base Backup and C hange Control Planned Outages 90.0% Unplanned Outages 10.0% DB Backup 52.0% Operations 25.0% Software 30.0% Other 9.0% Application 8.0% Hardware 8.0% Software 13.0% Network 10.0% Hardware 15.0% Other 3.0% Application 27.0% l a n n e d n p la n n e d 圖：造成系統(tǒng)不可用的因素 企 業(yè) 管理的需要 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 美國 911 恐怖襲擊事件之后，華爾街上幾乎所有的金融機構(gòu)都未受到致命的 影響，這都要歸功于企業(yè)制定的業(yè)務(wù)持續(xù)性計劃。企業(yè)管理標(biāo)準(zhǔn)要求，每個企業(yè) 應(yīng)該具 備一套保證企業(yè)在發(fā)生緊急事故時能夠從容應(yīng)對的管理計劃，這就是業(yè)務(wù) 持續(xù)性計劃。這套計劃將使得客戶能夠在災(zāi)難時啟動相關(guān)的備份設(shè)備，協(xié)調(diào)人員 流動，應(yīng)對媒體訪問，確保業(yè)務(wù)的正常運營。 作為業(yè)務(wù)持續(xù)性計劃的一部分，信息系統(tǒng)的災(zāi)難恢復(fù)計劃的制定是非常重要 和關(guān)鍵的，它將直接決定企業(yè)業(yè)務(wù)應(yīng)用的恢復(fù)時間，制定信息系統(tǒng)的容災(zāi)計劃也 是對現(xiàn)有投資的保護(hù)。信息系統(tǒng)設(shè)備，軟件的購買和應(yīng)用是為了能更好的處理業(yè) 務(wù)，由此獲得的客戶滿意和競爭實力不應(yīng)該因為一次嚴(yán)重的故障而喪失殆盡。信 息系統(tǒng)的容災(zāi)計劃將使企業(yè)在緊急狀況下仍能夠正常營 業(yè)，從而顯示出更強于其 它企業(yè)的競爭力。 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 需 求 分 析 方 案 設(shè) 計 核核核核 心心心心 業(yè)業(yè)業(yè)業(yè) 務(wù)務(wù)務(wù)務(wù) 及及及及 其其其其 關(guān)關(guān)關(guān)關(guān) 聯(lián)聯(lián)聯(lián)聯(lián) 業(yè)業(yè)業(yè)業(yè) 務(wù)務(wù)務(wù)務(wù) 習(xí) 、 測 試 、 維 護(hù) 方 案 實 施 需 求 分 析 方 案 設(shè) 計核核核核 心心心心 業(yè)業(yè)業(yè)業(yè) 務(wù)務(wù)務(wù)務(wù) 及及及及 其其其其關(guān)關(guān)關(guān)關(guān) 聯(lián)聯(lián)聯(lián)聯(lián) 業(yè)業(yè)業(yè)業(yè) 務(wù)務(wù)務(wù)務(wù)習(xí) 測 試 維 護(hù) 方 案 實 施3 容災(zāi)技術(shù)方案選型 3.1 容災(zāi)系統(tǒng)架構(gòu)方案設(shè)計范圍 根據(jù)上海移動的要求，本次容災(zāi)系統(tǒng)架構(gòu)方案設(shè)計將主要考慮中國移動業(yè)務(wù) 支撐網(wǎng)中的 BOSS 系統(tǒng)，兼顧經(jīng)營分析系統(tǒng)。對于 BOSS 系統(tǒng)，將主要考慮其中的 營帳子系統(tǒng)，計費子系統(tǒng)，充值子系統(tǒng)， 1860 子系統(tǒng) ,綜合結(jié)算中的網(wǎng)間結(jié)算子 系統(tǒng)。整個容災(zāi)系統(tǒng)建設(shè)將遵循統(tǒng)一規(guī)劃，分步實施的原則，而不是一蹴而就的。 3.2 容災(zāi)技術(shù)方案設(shè)計方法 移動總部的容災(zāi)系統(tǒng)業(yè)務(wù)規(guī)范建議容災(zāi)系統(tǒng)按 照以下的方法論進(jìn)行，本設(shè)計 是具體的方案設(shè)計部分。 人 員 調(diào) 控 需 求 分 析核 心 業(yè) 務(wù) 及 其 關(guān) 聯(lián) 業(yè) 務(wù)方 案 設(shè) 計 En te rp ri 演 習(xí) 、 測 試 、 維 護(hù) 驅(qū) 動 方 案 實 施 計 劃 流 程 技 術(shù) 映 射 3.3 容災(zāi)系統(tǒng)建設(shè)目標(biāo) 業(yè)界在建設(shè)容災(zāi)系統(tǒng)時，主要考慮以下的目標(biāo)參數(shù)： 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 恢復(fù)時間目標(biāo)（ RTO） 在系統(tǒng)不可用的情況下，你可以忍受多長時間？這 個參數(shù)定義了系統(tǒng)能夠容忍的最長停機時間； 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 恢復(fù)點目標(biāo)（ RPO）當(dāng)系統(tǒng)被恢復(fù)時，你可以忍受多少數(shù)據(jù)需要重新建立？ 這個參數(shù)定義了系統(tǒng)能夠容忍的最多數(shù)據(jù)丟失； 網(wǎng)絡(luò)恢復(fù)目標(biāo)（ NRO） 需要多長時間才可以切換網(wǎng)絡(luò)？這個參數(shù)定義了系 統(tǒng)能夠容忍的最長網(wǎng)絡(luò)停機時間。 一個應(yīng)用的完全恢復(fù)應(yīng)該包括主機，數(shù)據(jù)庫，應(yīng)用程序，網(wǎng)絡(luò)連接，應(yīng)用服 務(wù)器和應(yīng)用界面的完全可用。所以具體到一個特定的應(yīng)用，具體的技術(shù)指標(biāo)會不 一樣。在移動總部的規(guī)范中將 BOSS 的容災(zāi)恢復(fù)指標(biāo)定義為 2 級。根據(jù)上海移動 的具體實際，我們認(rèn)為，將聯(lián)機交易處理類的應(yīng)用如營帳， 1860，充值 等業(yè)務(wù)的 恢復(fù)目標(biāo)定義為 2 小時以內(nèi)，非聯(lián)機交易如計費的恢復(fù)時間定在 4 小時以內(nèi)是比 較現(xiàn)實的。（這個時間沒有包括決策是時間，但是包括網(wǎng)絡(luò)切換時間）。 3.4 容災(zāi) 7層技術(shù)模型介紹 首先讓我們看看業(yè)界公認(rèn)的容災(zāi)技術(shù)方案等級，災(zāi)難備援技術(shù)方案的七個級 別： 7 Tiers for Disaster Recovery Solution，是指根據(jù)國際標(biāo)準(zhǔn) SHARE 78 的定義，災(zāi)難備援技術(shù)方案可以根據(jù)以 下主要方面所達(dá)到的程度而分為七級： 1、 備份 /恢復(fù)的范圍 2、 災(zāi)難恢復(fù)計劃的狀態(tài) 3、 應(yīng)用站點與備援站點之間的 距離 4、 應(yīng)用站點與備援站點之間是如何相互連接的 5、 數(shù)據(jù)是怎樣在兩個站點之間傳送的 6、 允許有多少數(shù)據(jù)被丟失 7、 怎樣保證更新的數(shù)據(jù)在備援站點被更新 8、 備援站點可以開始備援工作的能力 即從低到高有七種不同層次的災(zāi)難恢復(fù)解決方案。 如下圖所示，該七個級別的災(zāi)難備援的技術(shù)方案分別是： 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 Tier 1 - PTAM“卡車”運送訪問方式 (Pickup Truck Access Method) Tier 2 - PTAM 卡車運送訪問方式 +熱備份站點 (PTAM + Hotsite) Tier 3 - 電 子鏈接方式 (Electronic Vaulting) Tier 4 - 數(shù)據(jù)庫鏡像和日志方式 (Batch/Online Database Shadowing & Journaling) Tier 5 - 兩點兩階段提交 (Two-Site Two-Phase Commit) Tier 6 - 無數(shù)據(jù)丟失 (Zero Data Loss) Tier 7 - 無數(shù)據(jù)丟失和應(yīng)用自動切管 （ Zero Data Loss + App Automatic takeover） 以上七個級別的災(zāi)難備援 的技術(shù)方案的特點和區(qū)別，可以參照如下描述： 七層模型的可恢復(fù)性比較 有無室 內(nèi) 備份 ? Y/N N Y Y Y Y Y Y Y 容災(zāi)層次 0 1 2 3 4 5 6 7 保存的 信 息 (數(shù) 據(jù)，指 令 ，文 檔 ) N Y/N Y Y Y Y Y Y Determination of requirements N Y Y Y Y Y Y Y 專用的 容 災(zāi)硬 件 和機房 N Y/N Y Y Y Y Y Y 災(zāi)難恢 復(fù) 計劃 N N Y Y Y Y Y Y 選擇性 的 異地 數(shù) 據(jù)保存 N N Y Y Y Y Y Y 支持危 機 時候 的 足夠的 硬 件和 網(wǎng) 絡(luò)設(shè)備 N N Y Y Y Y Y Y 至少部 分 信息 的 電子方 式 的備份 N N N Y Y Y Y Y Active management of recovery data by a processor at the recovery site N N N N Y Y Y Y 雙向恢復(fù) N N N N Y Y Y Y 物理分離 N N N N Y Y Y Y 所選數(shù) 據(jù) 的鏡像 N N N N N Y Y Y 異地部 分 或全 部 的硬件 備 份 N N N N N Y Y Y 主備中 心 數(shù)據(jù) 即 時異地 傳 輸 N N N N N N Y Y 根據(jù)策 略 自動 切 換到災(zāi) 備 中心 N N N N N N N Y 典 型 恢 復(fù) 時 間 Upto Never 1 week 1 day 1 day 1 day 12 hours 6 hours Few Mins. Tier 1 - PTAM“卡車” 運 送訪問方式 (Pickup Truck Access Method) Tier 1 的 災(zāi)難恢復(fù) 方 案必須設(shè) 計 一個嚴(yán)格 的 數(shù)據(jù)備份 方 案，能夠 備 份所 需 要的信息并將它遞送存放在異地 ， 然后根據(jù)恢復(fù)的具體需求 ， 有選擇地建立 備份平臺，但不提供數(shù)據(jù)處理的硬件。 PTAM 是 一種被用于 許 多中心的 備 份的標(biāo)準(zhǔn) 的 方式，數(shù) 據(jù) 在完成寫 操 作的 一 些時候 ， 將會被送到遠(yuǎn)離本地的地方 ， 同時準(zhǔn)備有數(shù)據(jù)恢復(fù)的程序 。 在災(zāi)難 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 發(fā)生后 ， 一整套安裝需要在一臺未開啟的計算機上重新完成 。 系統(tǒng)和數(shù)據(jù)可 以被恢 復(fù)并 重新與 網(wǎng)絡(luò) 相連。 這種 災(zāi)難恢 復(fù)方 案相對 來說 成本較 低 (僅僅 需 要傳輸 工具 的消耗 以及 存儲設(shè) 備的 消耗 )。但 同時有 這樣 的問題 ， 那 就是 難 于管理，即很難知道什么樣的數(shù)據(jù)在什么樣的地方。 Tier 2 - PTAM 卡車運送 訪 問方式 +熱 備份站點 (PTAM + Hotsite) Tier 2 相當(dāng)于 Tier 1 再加上熱備份中心能力的進(jìn)一步的災(zāi)難恢復(fù)。熱備份 中心擁有足夠的硬件和網(wǎng)絡(luò)設(shè)備去支持關(guān)鍵應(yīng)用的安裝需求 ， 這樣的應(yīng)用是 十分的關(guān)鍵的 ， 它必須在災(zāi)難發(fā)生的同時 ， 在異地有與生產(chǎn)環(huán)境相類似的硬 件提供支持 。 這種災(zāi)難恢復(fù)的方式依賴于 PTAM 方法去將日常數(shù)據(jù)放入倉庫， 當(dāng)災(zāi)難發(fā)生的時候 ， 數(shù)據(jù)再被移動到一個熱備份的中心 。 雖然移動數(shù) 據(jù)到一 個熱備份中心增加了成本，但卻明顯降低了災(zāi)難恢復(fù)時間。 Tier 3 - 電 子 鏈接方式 (Electronic Vaulting) Tier 3 是在 Tier 2 的基礎(chǔ)上用電子鏈路取代了卡車進(jìn)行數(shù)據(jù)的傳送的進(jìn)一 步的災(zāi)難恢復(fù)。接收方的硬件必須與主中心物理地相分離，在災(zāi)難發(fā)生后， 存儲的數(shù)據(jù)用于災(zāi)難恢復(fù)，由于熱備份中心要保持持續(xù)運行，增加了成本。 但消除了傳輸工具的需要，提高了災(zāi)難恢復(fù)速度。 Tier 4 - 數(shù)據(jù)庫 鏡 像和日 志 方 式 (Batch/Online Database Shadowing & Journaling) Tier 4 是在 Tier3 的基礎(chǔ)上，以數(shù)據(jù)庫遠(yuǎn)程備份為基礎(chǔ)。災(zāi)難恢復(fù)具有兩 個中心同時處于活動狀態(tài)并管理彼此的備份數(shù)據(jù) ， 允許備份行動在任何一個 方向發(fā)生。接收方硬件必須保證與另一方平臺物理地分離，在這種情況下， 工作負(fù)載可能在兩個中心之間分享，中心 1 成為中心 2 的備份，反之亦然。 在兩個中心之間 ， 彼此的在線關(guān)鍵數(shù)據(jù)的拷貝不停地相互傳送著 。 在災(zāi)難發(fā) 生時 ， 需要的關(guān)鍵數(shù)據(jù)通過網(wǎng)絡(luò)可迅速恢復(fù) ， 通過網(wǎng)絡(luò)的切換 ， 關(guān)鍵應(yīng)用的 恢復(fù)也可降低到小時級。 Tier 5 - 兩 點 兩階段提交 (Two-Site Two-Phase Commit) Tier 5 在 Tier 4 的基礎(chǔ)上管理著被選擇的數(shù)據(jù) (根據(jù)單一 commit 的范圍在 本地和 遠(yuǎn)程 數(shù)據(jù)庫 中同 時更新 數(shù)據(jù) )，也 就是 說，在 更新 請求被 認(rèn)為 是滿 意 之前， Tier 5 需要 生 產(chǎn)中心與 備 份中心的 數(shù) 據(jù)都被更 新 。我們可 以 想象 這 樣一種情景，數(shù)據(jù)在兩個中心之間相互映像，由遠(yuǎn)程 two-phase commit 來 同步 。 Tier5 為關(guān)鍵應(yīng)用使用了雙重在線存儲 ， 在災(zāi)難發(fā)生時 ， 僅僅傳送中 的數(shù)據(jù)被丟失，恢復(fù)時間被降低到分鐘級。 Tier 6 - 無 數(shù) 據(jù)丟失 (Zero Data Loss) Tier 6 可 以實現(xiàn)零 數(shù) 據(jù)丟失率 ， 同時保證 數(shù) 據(jù)立即自 動 地被傳輸 到 恢復(fù) 中 心 。 Tier6 被認(rèn)為是災(zāi)難恢復(fù)的相當(dāng)高的級別 ， 通過使用文件系統(tǒng)或存儲硬 件底層的數(shù)據(jù)同步 /異步鏡像功能，保證數(shù)據(jù)的實時一致性和完整性。 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 Tier 7 - 無 數(shù) 據(jù)丟失和 應(yīng) 用自動切管 （ Zero Data Loss + App Automatic takeover） Tier 7 在 Tier 6 的基礎(chǔ)上，在本地和遠(yuǎn)程的所有數(shù)據(jù)被更新的同時，利用 了雙重在 線活動的主機 ， 備份數(shù)據(jù)和完全的網(wǎng)絡(luò)切換能力 ， 實現(xiàn)應(yīng)用程序的 實時監(jiān)控和接管 。 Tier7 是災(zāi)難恢復(fù)中最昂貴的方式 ， 但也是需人工干預(yù)最 少，速度最快的恢復(fù)方式。 3.5 容災(zāi)技術(shù)方案選型考慮 首先讓我們確定一下此次容災(zāi)建設(shè)的一些背景條件： 1. 移動總部發(fā)布了 BOSS 1.5 規(guī)范，上海移動正在加緊進(jìn)行 BOSS 應(yīng)用的改 造 。 這個說明在容災(zāi)系統(tǒng)實施的同時 ， 業(yè)務(wù)環(huán)境也在發(fā)生變化 。 所以對 于具體選用何種技術(shù)就有很高的要求 ， 譬如說通過應(yīng)用程序?qū)觼韺崿F(xiàn)容 災(zāi)就不現(xiàn)實了 ， 因為一旦業(yè)務(wù)改動就需要改動容災(zāi) 方案 ， 基本上是不可 能的事情。 2. 局方同時可能會啟動 BOSS 網(wǎng)管項目，整個業(yè)務(wù)支撐平臺的系統(tǒng)管理都 會在網(wǎng)管項目中考慮 ， 所以在這個方案設(shè)計報告中就不對系統(tǒng)管理這一 塊內(nèi)容加以詳細(xì)闡述。 3. 本方案設(shè)計書將闡述 BOSS 網(wǎng)管沒有具體規(guī)定的存儲和存儲網(wǎng)的管理。 在我們的設(shè)計報告中 ， 我們首先對整個容災(zāi)系統(tǒng)的架構(gòu)進(jìn)行設(shè)計 ， 然后對其 中的各個要素分別加以闡述。 容災(zāi)系統(tǒng)建設(shè)中很重要的是如何將生產(chǎn)數(shù)據(jù)傳輸或復(fù)制到容災(zāi)中心 ， 我們需 要考慮 的是 在系統(tǒng) 的那 一個層 次上 的復(fù)制 數(shù)據(jù) 和采用 何種 機制 。 技 術(shù)的 發(fā)展 讓 我們有了更多更好的選擇而不必受一些具體產(chǎn)品的約束 。 下圖是目前業(yè)界最常用 的成熟的技術(shù)。 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 我們認(rèn)為 ， 首先需要一種技術(shù)方案 ， 它的建設(shè)實施對應(yīng)用和在用系統(tǒng)影響最 小 ， 同時又能滿足生產(chǎn)系統(tǒng)變動的需要 。 而對于某些特定應(yīng)用 ， 如果僅僅采用其 中的一種方案是可能不能完全滿足恢復(fù)需要 ， 如一些聯(lián)機的實時交易的應(yīng)用 ， 一 種方式顯得太單薄 ， 所以對這些應(yīng)用 ， 我們建議用復(fù)合式的容災(zāi)技術(shù)方案 。 究竟 以那種技術(shù)為主，那種為輔，應(yīng)該考慮實際情況。 下圖 是最近移動欽州機房發(fā)生影響生產(chǎn)的故障統(tǒng)計： 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 2004年 1月到 8月影 響 生產(chǎn)的故障統(tǒng)計 26% 39% 6% 26% 3% 數(shù) 據(jù) 庫 故 障 應(yīng) 用 故 障 網(wǎng) 絡(luò) 故 障 主 機 故 障 例 行 維 護(hù) 從中可以看出 ， 發(fā)生頻率最高 ， 對生產(chǎn)造成最大影響的是數(shù)據(jù)庫故障 ， 其次 是至少每月一次的例行維護(hù)和較高的網(wǎng)絡(luò)故障 ，而應(yīng)用故障和主機故障相對影響 較小 。 其中的數(shù)據(jù)庫故障大多時候都可以通過重啟數(shù)據(jù)庫來解決 ， 這些本身可能 由于 Oracle 8 版本軟件的缺陷造成，數(shù)據(jù)庫重啟時往往涉及到 recovery 過程， 如果有些意 外發(fā)生時 ， recovery 的過程會 很 長，可能 幾 個小時才 能 完成， 這時 重啟數(shù)據(jù)庫就遠(yuǎn)遠(yuǎn)不能滿足業(yè)務(wù)需求 。 針對這種情況 ， 我們認(rèn)為 ， 保持?jǐn)?shù)據(jù)庫的 高可用 性是 最重要 的， 其次是 網(wǎng)絡(luò) ，在上 海移 動， IP 網(wǎng) 絡(luò)目前 的故 障較多， 而 光網(wǎng)路相對來說比較穩(wěn)定，這也為采用存儲層的使用 DWDM 技術(shù)的方案提供的基 礎(chǔ)保證 。 就數(shù)據(jù)本身而言 ， 字節(jié)程度的一致性的重要性比不上交易程度的一致性 來得重要，所以，我們應(yīng)該強調(diào)當(dāng)生產(chǎn)數(shù)據(jù)庫發(fā)生故障時，可以最快速度恢復(fù)。 基于以上考慮我們給出下表的推薦， 5 為最高 ， 1 為最低。 容災(zāi)技術(shù) 技術(shù) 成熟 度 數(shù)據(jù)丟失 情況 硬件要求 實施難 易程度 對在用系 統(tǒng)影響 推薦程度 （ 1 5） 存儲服務(wù)器層 （ tier 6） 成熟 不丟或少 量 同一品牌 存儲 較易 較少 4 SAN 層 (tier 6) 成熟 不丟或少 量 FC 連接 較易 較少 3 操作系統(tǒng)層 (tier 6 or 7) 成熟 不丟或少 量 同一品牌 主機 較易 較大 3 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 數(shù)據(jù)庫層 (tire 4 or 5) 成熟 部分丟失 較易 較大 3.5 由表中可以看出 ， 對于建議采用復(fù) 合方式的應(yīng)用來說 ， 我們推薦使用數(shù)據(jù)庫 層和存儲層結(jié)合的復(fù)合方案 。存儲層可以在存儲產(chǎn)品層 ，也可以在 SAN 交換機層。 手 動 /自動啟 動 容災(zāi) 我們知道，自動容災(zāi)技術(shù)可以自動識別災(zāi)難的發(fā)生并且自動啟動恢復(fù)程序， 將應(yīng)用在容災(zāi)中心自動重啟 。 可是結(jié)合國內(nèi)實情 ， 自動容災(zāi)方式并不是很適合上 海移動，因為是否啟動容災(zāi)系統(tǒng)不僅僅是一個技術(shù)問題，其中有一個決策過程， 還有一個切換的程度的問題。采用手動切換，可以將主動權(quán)握在手里。 傳 統(tǒng) 磁盤遠(yuǎn)程 鏡 像的基本 概 念 傳統(tǒng)基 于磁 盤的鏡 像方 式是由 存儲 設(shè)備控 制通 過數(shù)據(jù) 通道 ，以邏 輯卷 為 基 本單位， 將 本地磁盤 陣 列上的數(shù) 據(jù) 鏡像到遠(yuǎn) 端 的同構(gòu)磁 盤 陣列上 比 如 IBM 的 PPRC 和 EMC 的 SRDF。 基于磁盤的鏡像功能傳統(tǒng)上提供 2 種工作方式，同步（左圖）和異步方式 （右圖）： 在同步方式下 ， 磁盤鏡像功能只有在本地和遠(yuǎn)程磁盤都完成寫操作后才會向 主機發(fā)回“ IO 完成”消息，以確保源卷和目的卷的數(shù)據(jù)徹底一致。 好處是： 可以保證數(shù)據(jù)不會丟失 可以保證數(shù)據(jù)的一致性 缺點是： 對網(wǎng)絡(luò)和距離要求很高：需要高帶寬和距離一般不能超越城域 對生產(chǎn)系統(tǒng)的性能影響也比較大 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 在異步工作方式下 ， 磁盤鏡像功能能夠在遠(yuǎn)端更新未完成的情況下 ， 只要本 地更新成功就可以向主機返回“寫成功”信號。 好處是： 對網(wǎng)絡(luò)和距離的要求非常低 對性能的影響非常小 壞處是： 數(shù)據(jù)一般情況下會丟失 普通異步方式無法保證 IO 的次序，所以在進(jìn)行異步操作時，遠(yuǎn)程鏡 像卷始終處于異步造成 的 “不一 致 ” 狀態(tài) ， 直 到所有數(shù) 據(jù) “全部傳遞 完畢”。如果應(yīng)用是 7*24 小時不間斷的，就無法達(dá)到數(shù)據(jù)“全部傳 遞完畢 ” 狀 態(tài) 。 所以 ， 異步備份一般只用于數(shù)據(jù)移植 ， 或 者和磁盤本 地鏡像結(jié)合，用于傳遞相對 靜止的數(shù)據(jù) 保 證 數(shù)據(jù)一致 性 的異步遠(yuǎn) 程 鏡像 為了同時利用同步的數(shù)據(jù)一致性優(yōu)勢和異步的性能/距離優(yōu)勢 ， 各個存儲廠 商都推出了一些能夠保證數(shù)據(jù)一致性的異步遠(yuǎn)程鏡像方式，主要是 IBM 的 PPRC GM 和 EMC 的 SRDF/A。 為了 100%的保證數(shù)據(jù)一致性和可用性 ， 所有類似的技術(shù)都必須采用 3 份數(shù) 據(jù)的方式進(jìn)行操作（本地 1 份，遠(yuǎn)程 2 份 ）。 IBM PPRC GM 的 工作方式 如 下： 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 工作方式如下（其中綠色為生產(chǎn)站點磁盤 ，橙色 和藍(lán)色 為容災(zāi)站點磁盤 ）： 1. 綠色和橙色磁盤之間進(jìn)行 PPRC-XD 異步操作 2. 綠色磁盤組根據(jù)預(yù)先設(shè)置的時間，生成“一致性組 ”（ Consistency Group），并記錄狀態(tài) 3. 采用 PPRC-XD 異步操作方式，將且只將“一致性組”記錄下來的數(shù)據(jù) 傳遞從綠色磁盤組傳遞到橙色磁盤組 4. 3 完成后，立刻將橙色磁盤組數(shù)據(jù) FlashCopy 到藍(lán)色磁盤組，進(jìn)行一 致性數(shù)據(jù)保留 5. 4 完成后，回到步驟 1 由于有“一致性組”的保護(hù)，雖然采用 異步方式，一旦每一個“一致性組” 數(shù)據(jù)包傳遞成功的那一時刻 ， 橙色磁盤組的數(shù)據(jù)是一致的 ； 由于步驟 4， 藍(lán)色磁 盤組將能夠保留最近一 次 “一致性完全 ” 的數(shù)據(jù) 。 一旦出現(xiàn)災(zāi)難 ， 客戶丟失 的 是 兩次生成“一致性組”間隔之間的數(shù)據(jù)。 如果網(wǎng) 絡(luò)發(fā) 生故障， PPRC GM 會 等 待網(wǎng)絡(luò) 恢復(fù) ，重新 生成 “一致 性組 ”（ 對 于經(jīng)歷的較長時間網(wǎng)絡(luò)故障的系統(tǒng)而言 ， 只是新 的 “一致性組 ” 中的數(shù)據(jù)會比較 大而已 ），繼續(xù)進(jìn)行 PPRC GM 的正常操作。 PPRC GM 能夠每 3 5 秒生成一 次 “一致性組 ”， 意味著客戶即使采用異步方 式 ，也有可能只丟失 3 5 秒的數(shù)據(jù)。 EMC SRDF/A 的 工作方式 如 下： 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 SRDF/A 使用“增量集”來短期維護(hù)一組寫入操作。增量集是 SRDF/A 所 提供的所有功能的基礎(chǔ)。 SRDF/A 使 用四 種 類 型 的增 量 集 來 管理 數(shù) 據(jù) 流 處理 過 程 。 SRDF/A 的 數(shù) 據(jù) 流可歸結(jié)為幾個步驟 : 源位置的增量集： 捕 獲 - 在 緩存 中 捕 獲 所有 傳 入 到 SRDF/A 組 所涉 及 的 源 卷 的寫 入 操 作。 完 成 此“ 捕 獲 增量 集 ” 后， 該 集 合中 的 寫 入操 作 將被“ 折 疊”， 并升 級為“ 傳 輸 增量集 ”， 同時開 始傳 輸其中 的內(nèi) 容 。（ 然 后另外創(chuàng)建一個新的 捕獲增量集 ，來維護(hù)下一個寫入操作增 量 集 。） 傳 輸 - 將 內(nèi)容從 源系 統(tǒng)傳輸 到目 標(biāo)系統(tǒng) ，僅 傳輸最 近的 寫入操 作 集。 目標(biāo)位置的增量集： 接收 - 接收增量集位于目標(biāo)系統(tǒng)上 ， 用于接收由源位置的 傳輸增 量集傳來的數(shù)據(jù) 。 接收到全部數(shù)據(jù)后 ， 它將升級為 應(yīng)用增量集 。 應(yīng)用 - 將增量集中的寫入操作應(yīng)用到目標(biāo)卷，以創(chuàng)建一致的可重新 啟動的遠(yuǎn)程拷貝。這就完成了增量集循環(huán)。 如果網(wǎng)絡(luò)發(fā)生故障 ， 由于 SRDF/A 使用 “ 增量集 ” 存在于磁盤系 統(tǒng)的高速緩存 中，一 定時 間的故 障會 造成高 速緩 存溢出 ，此 時必須 中斷 SRDF/A，等待網(wǎng)絡(luò) 恢 復(fù)。從網(wǎng)絡(luò)故障到恢復(fù)之間的數(shù)據(jù)只能夠采用傳統(tǒng)的 SRDF 異步方式傳遞，為了 防止異步傳遞被異常中斷而造成對遠(yuǎn)程數(shù)據(jù)庫的破壞 ， 在傳遞數(shù)據(jù)之前必須采用 TimeFinder 保護(hù)一下遠(yuǎn)程的數(shù)據(jù)，然后才能夠繼續(xù)操作。 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 4 容災(zāi)系統(tǒng)方案設(shè)計 4.1 上海移動系統(tǒng)現(xiàn)狀 上海移動目前主要有兩個生產(chǎn)機房 ， 一個在欽州 ， 一個在橫浜 ， 業(yè)務(wù)分布如 下圖所示： 欽州路生產(chǎn)中心： 營帳 、計費、網(wǎng) 間結(jié) 算 、充 值 、 經(jīng) 營 分 析 和 OnDemand 橫浜路生產(chǎn)中心： 1860客服 系 統(tǒng) 上海移動目前的主要應(yīng)用系統(tǒng)均運行在 AIX 433和 Oracle 8174下，部分業(yè)務(wù) 運行在 AIX 5.1/5.2下，但數(shù)據(jù)庫依然為 oracle 8i；存儲設(shè)備有 IBM ESS 和 7133 也有 EMC存儲。部分產(chǎn)品將根據(jù)實際情況升級，但不在本方案中具體涉及。 系統(tǒng) 主 機 設(shè)備 /地點 存 儲 設(shè)備 /地點 營帳 S85x2/欽州 ，2004年 4季度將 F20/欽州 ,2004年 4季度 更新為 p5-570x2 將新增一臺 ESS800,計 費與營帳的存儲 將分 開。 計費 S85x2/欽州 F20/欽州 1860 P650x2/橫浜 E20/ 橫浜 經(jīng)營分析 P690x2/欽州 EMC/ 欽州 充值 p630x2/欽州 7133/欽州 采集 H85x1/欽州 F20/ 欽州 網(wǎng)間結(jié)算 M80x2/欽州 F20/橫浜 下面將會對這些系統(tǒng)的容災(zāi)方案進(jìn)行具體闡述。 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 4.2 容災(zāi)架構(gòu)整體設(shè)計 容 災(zāi) 系統(tǒng)總體 架 構(gòu)設(shè)計 綜合以上要求 ， 我們實際如下的容災(zāi)系統(tǒng)整體架構(gòu) ， 在這個架構(gòu)中 ， 對實時 性恢復(fù)要求高的核心業(yè)務(wù) 的數(shù)據(jù)庫 ， 我們考慮了兩層容災(zāi)設(shè)計 。 這里的核心業(yè)務(wù) 我們認(rèn)為是營帳數(shù)據(jù)庫 ， 充值數(shù)據(jù)庫和 1860數(shù)據(jù)庫 。 對于計費 ， 經(jīng)營分析 ， 網(wǎng) 間 結(jié)算，批價等，我們考慮存儲層的容災(zāi)。 由于從實際業(yè)務(wù)中 ， 以下具體應(yīng)用模塊和數(shù)據(jù)庫是關(guān)鍵性的 ， 所以單獨對這 些模塊進(jìn)行進(jìn)一步說明 。 由于 BOSS 1.5的具體稱呼有些變化 ， 但鑒于目前為止改 造項目并沒有實施完成 ， 所以 ， 我們主要從數(shù)據(jù)庫和數(shù)據(jù)一層考慮業(yè)務(wù)的具體特 性和容災(zāi)方式。 營 帳 系統(tǒng) 營帳系統(tǒng)是移動業(yè)務(wù)中的核心系統(tǒng) ， 實時性要求高 ， 對于容災(zāi)系統(tǒng)的要求也 是最高 ， 所以在此我 們考慮使用數(shù)據(jù)庫備份模式加上存儲層數(shù)據(jù)鏡像模式 。 使用 業(yè)界成熟流行的數(shù)據(jù)庫實時抽取技術(shù)或者 standby database技術(shù) ， 在生產(chǎn)中心隨 時保留一個與生產(chǎn)庫基本同步的數(shù)據(jù)庫 ， 該數(shù)據(jù)庫是處于 open狀態(tài)的 。 這樣可以 在發(fā)生數(shù)據(jù)庫邏輯可以快速接管 。 這種方案的缺點是可能會有一些數(shù)據(jù)需要在事 后進(jìn)行補錄，但丟失的數(shù)據(jù)是非常少的。具體容災(zāi)架構(gòu)如下圖： 知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 營帳系統(tǒng)容災(zāi)架構(gòu)圖 所有營帳數(shù)據(jù)庫里的數(shù)據(jù)都會通過存儲層的方案鏡像到金橋中心。 本 地通過數(shù)據(jù)抽取另生成一個 active的數(shù)據(jù)庫，與源數(shù)據(jù)庫近乎同步， 一旦需要，可立即將應(yīng)用切換過來。如果本地有兩個物理存儲，考慮到 高可用性，可以將抽取出來的數(shù)據(jù)放到另外一個存儲設(shè)備上。 目前計劃進(jìn)行營帳系統(tǒng)“瘦身”計劃，擬將目前營帳數(shù)據(jù)庫中的歷史庫 剝離開，營