上海移動容災系統(tǒng)方案設計報告 (2).doc

知識水壩（豆丁網(wǎng)pologoogle）為您傾心整理（下載后雙擊刪除）上海移動容災系統(tǒng)方案設計報告ibm 公司上海分公司version 5.0百度一下知識水壩ibm專有信息聲明本設計報告屬商業(yè)機密文件，書中的所有信息均為ibm機密信息，僅供上海移動容災項目使用。務請妥善保管并且僅在與項目有關人員范圍內使用，未經(jīng)ibm 公司明確做出的書面許可，不得為任何目的、以任何形式或手段（包括電子、機 械、復印、錄音或其他形式）對本文檔的任何部分進行復制、存儲、引入檢索系 統(tǒng)或者傳播。盡管ibm已經(jīng)盡力保證本文檔內容的完整性和有效性，但仍可能存在某些方 面不夠準確的地方或印刷錯誤。若需求有所變化，ibm將對有關內容進行相對應 的調整，并在本報告的未來版本中體現(xiàn)。ibm是國際商業(yè)機器公司的注冊商標。本文檔提及的其他公司、產品和服務 的名稱，可能是其他公司的商標或服務的標志。copyright ibm china company limitedall rights reserved關于本文檔文檔信息文檔名稱上海移動容災系統(tǒng)方案設計報告作者ibm全球服務部說明本文檔是上海移動容災系統(tǒng)方案設計報告，由ibm公司上海分公司和上海移動容災系統(tǒng)項目組共同編寫。文件名稱上海移動容災系統(tǒng)方案設計報告 v5.0.doc怱訂歷史 (revision history)revsectiontypedateauthorremarks1.0allnew2004-09-13ibmshmccteam創(chuàng) 建 方 案 第 一 版本。2.0allrevised2004-09-22ibmshmccteam根據(jù)客戶反饋怱改而成3.0-3.1allrevised2004-09-27ibmshmccteam根據(jù)客戶反饋怱改而成，增加存儲管 樅 和 災 難 恢 復 計 劃，網(wǎng)絡設計考慮多種方案4.0allrevised2004-10-08ibmshmccteam整樅版本5.0allrevised2004-10-25ibmshmccteam加入摘要，加強存儲管樅內容。內容范圍本文檔是上海移動容災系統(tǒng)方案設計報告，屬于機密文件。 適用的對象本文檔適用于參與上海移動容災項目組的決策者、評估者。目錄1摘要72容災系統(tǒng)建設意義83容災技術方案選型123.1容災系統(tǒng)架構方案設計范圍123.2容災技術方案設計方法123.3容災系統(tǒng)建設目標123.4容災 7 層技術模型介紹133.5容災技術方案選型考慮164容災系統(tǒng)方案設計234.1上海移動系統(tǒng)現(xiàn)狀234.2容災架構整體設計244.3容災系統(tǒng)詳細設計314.3.1本地數(shù)據(jù)庫容災313.3.2容災系統(tǒng)主機設計324.3.2容災系統(tǒng)存儲設計463.3.4容災系統(tǒng)網(wǎng)絡設計534.4容災系統(tǒng)備份方案設計714.4.1數(shù)據(jù)備份概述714.4.2備份系統(tǒng)現(xiàn)狀分析734.4.3容災備份系統(tǒng)邏輯設計754.4.4容災備份系統(tǒng)配置設計824.4.5容災備份系統(tǒng)專業(yè)服務844.5容災系統(tǒng)管理方案設計864.5.1存儲資源管理864.5.2存儲網(wǎng)絡管理915容災系統(tǒng)實施計劃945.1災難恢復計劃945.2上海移動容災項目實施計劃956附錄966.1機房工程技術說明966.2上海移動業(yè)務支撐系統(tǒng)平臺現(xiàn)狀概況一覽表。1056.3ibm 項目管理服務1076.4支持多廠商的網(wǎng)絡存儲通用管理軟件 sanavigator 版本1146.5容災系統(tǒng)管理方案設計1216.5.1系統(tǒng)管理現(xiàn)狀1216.5.2系統(tǒng)管理需求1226.5.3系統(tǒng)管理架構建議1236.5.4事件管理1266.5.5網(wǎng)絡管理1286.5.6數(shù)據(jù)庫管理1296.5.7主機系統(tǒng)監(jiān)控1316.5.8sla 管理1336.5.9boss 應用管理1346.5.10流程管理1341 摘要一、項目背景隨著電信市場的開放以及中國加入 wto 進程的進行，中國移動通信面臨著前 所未有的發(fā)展機遇和挑戰(zhàn)。作為一個電信運營商，其 it 系統(tǒng)的應用直接關乎管 理、服務、成本、效率等各個重要環(huán)節(jié)，并最終全面影響運營商的競爭力。電信 行業(yè)是一個講究系統(tǒng)高可用性的行業(yè)，它要求關鍵應用服務器必須 247 的不間 斷運行，以滿足超大量用戶的實時訪問，任何潛在的單點故障都有可能導致整個 系統(tǒng)的癱瘓。為了保證信息系統(tǒng)的穩(wěn)定和數(shù)據(jù)的安全，提高業(yè)務運營系統(tǒng)的服務 質量，確保在日益激烈的市場競爭中確立主導地位，上海移動決定在現(xiàn)有業(yè)務運 營支撐系統(tǒng)的基礎上，結合自身的特點和實踐經(jīng)驗進行上海移動業(yè)務運營支撐容 災系統(tǒng)工程的建設。本次上海移動業(yè)務運營支撐容災系統(tǒng)工程的目標，是按照移動集團公司 boss 系統(tǒng)容災備份技術規(guī)范和業(yè)務規(guī)范，主要考慮中國移動業(yè)務支撐網(wǎng)中的 boss 系統(tǒng)，兼顧經(jīng)營分析系統(tǒng)。對于 boss 系統(tǒng)，將主要考慮其中的營帳子系統(tǒng)， 計費子系統(tǒng)，充值子系統(tǒng)，1860 子系統(tǒng),綜合結算中的網(wǎng)間結算子系統(tǒng)。整個容災系統(tǒng)建設將遵循統(tǒng)一規(guī)劃，分步實施的原則。二、本設計報告內容結構本容災設計報告主要分為四大部分：容災系統(tǒng)建設意義、容災技術方案選型、 容災系統(tǒng)方案設計以及容災系統(tǒng)實施計劃。容災系統(tǒng)建設意義部分主要從行業(yè)競爭需要、業(yè)務穩(wěn)定需要和企業(yè)管理需要 三方面闡述了容災系統(tǒng)的建設意義。容災技術方案選型部分主要根據(jù)上海移動 boss 系統(tǒng)的現(xiàn)狀和將來的發(fā)展并 滿足對應用和在用系統(tǒng)影響最小以及生產系統(tǒng)變動的需要推薦使用存儲層+數(shù)據(jù) 庫層的復合容災方案。容災系統(tǒng)方案設計部分主要針對上海移動 boss 系統(tǒng)的各個子系統(tǒng)提出了各 自的容災架構設計，根據(jù)各子系統(tǒng)的實時性恢復要求提出對于營帳數(shù)據(jù)庫，充值 數(shù)據(jù)庫和 1860 數(shù)據(jù)庫實施兩層容災設計；對于計費，經(jīng)營分析，網(wǎng)間結算，批 價等提出存儲層的容災設計。另外還從容災系統(tǒng)的主機、存儲、網(wǎng)絡、備份方案 以及存儲資源和存儲網(wǎng)絡管理方案方面作了詳細的設計。容災系統(tǒng)實施計劃部分介紹了如何系統(tǒng)的實施災難恢復計劃以保證災難發(fā) 生時業(yè)務操作地連續(xù)性。2 容災系統(tǒng)建設意義中國有句古話叫做“天有不測風云，人有旦夕禍?！?，充分說明災難的不可測性。911 事件是對這句話的最好注腳，在里面辦公的 286 家公司的 5 萬多名員 工是根本不會想到好端端的坐在辦公室里居然會有飛機撞過來。在這種近乎毀滅 性的局部災難面前，是否有異地容災系統(tǒng)就變成了關乎企業(yè)生存的現(xiàn)實問題。最 近國內也發(fā)生了類似災難，大連某個銀行的生產中心突然著火，因為沒有災備系 統(tǒng)，造成全部業(yè)務停止兩天，這還是不幸中的萬幸，因為絕大多數(shù)機器設備經(jīng)過 修復還可以使用，尤其是存儲設備，否則，后果真是不堪設想。很多企業(yè)是從 911 事件后開始真正認真考慮容災的，以往容災系統(tǒng)的建設往 往被視為錦上添花的項目而不是一個業(yè)務可持續(xù)性運行的必須項目。我們可以吸 取的教訓是一定要建立核心數(shù)據(jù)和業(yè)務的容災系統(tǒng)，并且平時要加強管理和演 習，加強人員的培訓，核心管理人員和技術的分散，以提高計算機系統(tǒng)因為天災 或人為因素等意外事故導致系統(tǒng)毀壞無法運行時的抵御能力，至少將局部地區(qū)核 心業(yè)務支持在系統(tǒng)故障時的損失減至最小。無論是國內還是國外的用戶，無論是政府還是企業(yè)，現(xiàn)在都在思考這樣一個 問題，那就是，假設我們的企業(yè)發(fā)生了類似的情況，我們是否有足夠的備份措施， 企業(yè)的數(shù)據(jù)是否有足夠的保障？在美國、日本等一些發(fā)達國家，對于關乎國計民 生的行業(yè)，有專門的法律要求該企業(yè)必須有災難保護方案，（如美國是 bcc 177） 并且每年都會進行審計和稽核。國內因為目前還沒有類似的法律約束，很多企業(yè) 對于應用比較重視，但是對于整體系統(tǒng)的可用性考慮得不多，甚至是一些金融企 業(yè)，當有類似數(shù)據(jù)庫出錯等故障發(fā)生時，還依然只能通過倒磁帶的方式恢復數(shù)據(jù)。 這種情況下，丟失數(shù)據(jù)就是不可避免的了，并且由于恢復時間的漫長，對廣大客 戶承諾的服務水平又如何能夠達到？現(xiàn)在，隨著中國加入 wto，一些國內先進的 有前瞻性的企業(yè)也在這方面給予了足夠的重視，如上海移動等單位。隨著上海移動業(yè)務的飛速發(fā)展，業(yè)務對 it 系統(tǒng)的依賴性也隨之增加，越來 越多的業(yè)務集中到生產主機上，對主機和存儲設備都造成了較大的壓力。當一個 單位越來越依賴于數(shù)據(jù)處理去進行它的業(yè)務行為時，數(shù)據(jù)處理的高可靠性和高可 用性就尤為關鍵，大部分單位的業(yè)務處理需要數(shù)據(jù)處理的高可用性。用戶發(fā)現(xiàn)如 果沒有了數(shù)據(jù)處理，業(yè)務的開展變得極端困難，也許手工操作還可以使用，但那 只能用于短期的應付，一個計算機系統(tǒng)的長期停止運轉將直接導致明顯的業(yè)務后 果，也許還會被追究管理責任。更為重要的是，一旦數(shù)據(jù)由于某種原因永久性丟 失，不但會給企業(yè)的運作帶來極大的困難，企業(yè)的商業(yè)信譽必將受到致命的打擊， 在競爭中處于劣勢，造成不可估量的后果。基于這種考慮，中國移動總部提出了在各省建設 boss 系統(tǒng)容災備份的要求， 這個報告書就是為上海移動的容災系統(tǒng)進行方案設計。本方案中將重點討論 boss 系統(tǒng)的詳細容災方案，兼顧其他業(yè)務系統(tǒng)，同時根據(jù)上海移動的實際情況分步實現(xiàn)。當然，我們考慮容災系統(tǒng)建設時，也應該實事求是，從實際出發(fā)。能夠防御 所有災難的方案是不存在的，也是不現(xiàn)實的。我們認為，計算機系統(tǒng)的災難定義 是可以由用戶自己來定義的，各個行業(yè)可以有不同的要求。設計容災系統(tǒng)時，應 該基于一個合理的前提假設，譬如，在主機房發(fā)生故障時，備份機房可以保證數(shù) 據(jù)的完整性，并且可以在最短時間內完成應用、網(wǎng)絡和數(shù)據(jù)的接管。本方案中的 容災系統(tǒng)正是基于這種前提來設計，我們暫不考慮那種同時損壞主備機房的可能 性。讓我們再來看看容災系統(tǒng)建設的意義，這個在移動總部的容災系統(tǒng)建設規(guī)范 中也有多次強調：行業(yè)競爭的需要美國明尼蘇達大學研究機構的統(tǒng)計結果表明，對于銀行，金融，證券，電信等行業(yè)的企業(yè)而言，如果業(yè)務停頓時間長達兩天或更長，那么 25% 的企業(yè)將立 刻因信譽和業(yè)務問題而倒閉，40% 的企業(yè)將因為受不斷的后續(xù)因素的影響導致綜 合競爭力的下降而在今后兩至五年內被淘汰，五年以后僅有 7% 的企業(yè)能夠繼續(xù) 在此行業(yè)內生存。目前，在國內，通訊行業(yè)內的競爭本來就很激烈，加之 wto 之后，國外實力 雄厚的企業(yè)對國內市場的窺視，將不可避免地造成企業(yè)爭奪客戶群的白熱化的局 面，因此企業(yè)總體服務的水平將是影響競爭結果的重要因素。試想，一個時不時 就會抱歉地對客戶說：“對不起，由于我們的主機系統(tǒng)有問題，您要求的業(yè)務暫 時無法辦理”的企業(yè)將無法贏得挑剔的客戶的芳心。即使在發(fā)生眾所周知的 災害，如果系統(tǒng)也是長時間的無法恢復，也會帶來極嚴重的后果。所以，it 系 統(tǒng)的完善程度是激烈競爭的一個最重要的前提，在此基礎上，企業(yè)才能開發(fā)豐富 多樣的業(yè)務品種，提供高質量的服務水平，在競爭中取得優(yōu)勢。不久前發(fā)生在南 京的“愛立信跳槽事件”已經(jīng)表明了中國加入 wto 后行業(yè)競爭的殘酷性和現(xiàn)實性。 根據(jù)業(yè)務的不同，對各種程度的中心系統(tǒng)可靠性要求也不同，如從最高等級 的xx服務，到在指定時間內恢復。為了滿足這些要求，更好地為客 戶服務，上海移動應當未雨綢繆，盡早制定和建立完備的災難恢復計劃系統(tǒng)，以增強系統(tǒng)的抗災能力，最大限度地減小損失。業(yè)務穩(wěn)定的需要時至今日，企業(yè)業(yè)務運營對信息系統(tǒng)的運作的依賴性越大，就對信息系統(tǒng)運作的穩(wěn)定性和可靠性的要求越高。 而信息系統(tǒng)可用的定義已不再局限于主機設備的可用，而是從主機，存儲，用戶終端，網(wǎng)絡設備整體的物理可用，到系統(tǒng)，數(shù)據(jù)庫，應用軟件，用戶數(shù)據(jù)的 邏輯可用。然而，由于各種因素的影響，小至一般性的硬件故障，大到區(qū)域性的自然災 害，從物理的設備不可用，到邏輯的人為失誤和破壞，都可能造成整個信息系統(tǒng) 的全面癱瘓，從而導致業(yè)務運營的停頓。因此，同一機房中的雙主機恢復系統(tǒng)有 很多企業(yè)已經(jīng)覺得不能滿足需求，特別是因為應用的要求而作了區(qū)域集中或全國大集中的企業(yè)，在享受數(shù)據(jù)集中帶來的諸多好處時，同時也承擔著數(shù)據(jù)丟失或者it 系統(tǒng)不可用帶來的巨大風險。從以下這份國外的研究報告中我們可以知道這 些擔憂不是杞人憂天。這是 1996 年 source contingencyplanning research inc。 對于各種因素包括自然災害：水災、風災、地震、大雪、野火 結構破壞：電力中斷、火災、爆炸 操作問題：硬件問題、病毒入侵、操作失誤、人為破壞。讓我們暫時拋開滿腦子的災難，來考慮一下即使是機器沒有發(fā)生故障是否也是 7小時可用呢？我們認為，現(xiàn)實環(huán)境中，這種情況也是不現(xiàn)實的，我們 經(jīng)常會進行一些正常的日常維護活動。假設我們認為，所有災難都是屬于非計劃 中的系統(tǒng)不可用，那么還有很大一部分系統(tǒng)不可用時間是屬于計劃中的，從下圖 中我們可以看到非計劃宕機只是占了 it 系統(tǒng)不可用的 10%，而計劃中的宕機占了 90%。 如果我們有了容災系統(tǒng)，起碼我們可以將很多計劃中的停機事件避免，如數(shù)據(jù)備份，完全可以在容災中心進行，同時，我們可以利用容災中心做許多諸如新 的應用程序測試，壓力測試等等，若是結合第二份數(shù)據(jù)鏡像功能，我們完全可以 輕松自如的在容災中心進行數(shù)據(jù)查詢，數(shù)據(jù)挖掘等業(yè)務。當然，這些業(yè)務在只有 一份遠程鏡像時也可以實現(xiàn)，只是需要較為仔細和復雜的操作，并且有可能暫時 中斷鏡像等，相比之下沒有前者操作方便簡單，對生產系統(tǒng)的沖突更小。definition of outagesmost customer outages are caused bydata base backup andchange controlplannedoutages90.0%unplannedoutages10.0%dbbackup52.0%operations25.0%software30.0%other9.0%application8.0%hardware8.0%software13.0%network10.0%hardware15.0%other3.0%application27.0% l a n n e d n p la n n e d 圖：造成系統(tǒng)不可用的因素企業(yè)管理的需要美國 911 恐怖襲擊事件之后，華爾街上幾乎所有的金融機構都未受到致命的影響，這都要歸功于企業(yè)制定的業(yè)務持續(xù)性計劃。企業(yè)管理標準要求，每個企業(yè) 應該具備一套保證企業(yè)在發(fā)生緊急事故時能夠從容應對的管理計劃，這就是業(yè)務 持續(xù)性計劃。這套計劃將使得客戶能夠在災難時啟動相關的備份設備，協(xié)調人員 流動，應對媒體訪問，確保業(yè)務的正常運營。作為業(yè)務持續(xù)性計劃的一部分，信息系統(tǒng)的災難恢復計劃的制定是非常重要 和關鍵的，它將直接決定企業(yè)業(yè)務應用的恢復時間，制定信息系統(tǒng)的容災計劃也 是對現(xiàn)有投資的保護。信息系統(tǒng)設備，軟件的購買和應用是為了能更好的處理業(yè) 務，由此獲得的客戶滿意和競爭實力不應該因為一次嚴重的故障而喪失殆盡。信 息系統(tǒng)的容災計劃將使企業(yè)在緊急狀況下仍能夠正常營業(yè)，從而顯示出更強于其 它企業(yè)的競爭力。3 容災技術方案選型3.1 容災系統(tǒng)架構方案設計范圍根據(jù)上海移動的要求，本次容災系統(tǒng)架構方案設計將主要考慮中國移動業(yè)務 支撐網(wǎng)中的 boss 系統(tǒng)，兼顧經(jīng)營分析系統(tǒng)。對于 boss 系統(tǒng)，將主要考慮其中的 營帳子系統(tǒng)，計費子系統(tǒng)，充值子系統(tǒng)，1860 子系統(tǒng),綜合結算中的網(wǎng)間結算子 系統(tǒng)。整個容災系統(tǒng)建設將遵循統(tǒng)一規(guī)劃，分步實施的原則，而不是一蹴而就的。3.2容災技術方案設計方法移動總部的容災系統(tǒng)業(yè)務規(guī)范建議容災系統(tǒng)按照以下的方法論進行，本設計 是具體的方案設計部分。人 員調 控需 求 分 析需 求 分 析方 案 設 計核核核核 心心心心 業(yè)業(yè)業(yè)業(yè) 務務務務 及及及及 其其其其關關關關 聯(lián)聯(lián)聯(lián)聯(lián) 業(yè)業(yè)業(yè)業(yè) 務務務務習 、 測 試 、 維 護方 案 實 施需 求 分 析方 案 設 計核核核核 心心心心 業(yè)業(yè)業(yè)業(yè) 務務務務 及及及及 其其其其關關關關 聯(lián)聯(lián)聯(lián)聯(lián) 業(yè)業(yè)業(yè)業(yè) 務務務務習 、 測 試 、 維 護方 案 實 施核 心 業(yè) 務 及 其 關 聯(lián) 業(yè) 務方 案 設 計en te rp ri演 習 、 測 試 、 維 護驅 動方 案 實 施計 劃流 程技 術映 射3.3容災系統(tǒng)建設目標業(yè)界在建設容災系統(tǒng)時，主要考慮以下的目標參數(shù)：恢復時間目標（rto） 在系統(tǒng)不可用的情況下，你可以忍受多長時間？這 個參數(shù)定義了系統(tǒng)能夠容忍的最長停機時間；恢復點目標（rpo）當系統(tǒng)被恢復時，你可以忍受多少數(shù)據(jù)需要重新建立？這個參數(shù)定義了系統(tǒng)能夠容忍的最多數(shù)據(jù)丟失；網(wǎng)絡恢復目標（nro） 需要多長時間才可以切換網(wǎng)絡？這個參數(shù)定義了系 統(tǒng)能夠容忍的最長網(wǎng)絡停機時間。一個應用的完全恢復應該包括主機，數(shù)據(jù)庫，應用程序，網(wǎng)絡連接，應用服 務器和應用界面的完全可用。所以具體到一個特定的應用，具體的技術指標會不 一樣。在移動總部的規(guī)范中將 boss 的容災恢復指標定義為 2 級。根據(jù)上海移動 的具體實際，我們認為，將聯(lián)機交易處理類的應用如營帳，1860，充值等業(yè)務的 恢復目標定義為 2 小時以內，非聯(lián)機交易如計費的恢復時間定在 4 小時以內是比 較現(xiàn)實的。（這個時間沒有包括決策是時間，但是包括網(wǎng)絡切換時間）。3.4容災 7層技術模型介紹首先讓我們看看業(yè)界公認的容災技術方案等級，災難備援技術方案的七個級 別：7 tiers for disaster recovery solution，是指根據(jù)國際標準 share 78 的定義，災難備援技術方案可以根據(jù)以下主要方面所達到的程度而分為七級：1、 備份/恢復的范圍2、 災難恢復計劃的狀態(tài)3、 應用站點與備援站點之間的距離4、 應用站點與備援站點之間是如何相互連接的5、 數(shù)據(jù)是怎樣在兩個站點之間傳送的6、 允許有多少數(shù)據(jù)被丟失7、 怎樣保證更新的數(shù)據(jù)在備援站點被更新8、 備援站點可以開始備援工作的能力即從低到高有七種不同層次的災難恢復解決方案。 如下圖所示，該七個級別的災難備援的技術方案分別是：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ù)丟失和應用自動切管 （zero data loss + app automatic takeover）以上七個級別的災難備援的技術方案的特點和區(qū)別，可以參照如下描述：七層模型的可恢復性比較有無室內備份? y/nnyyyyyyy容災層次01234567保存的信息 (數(shù)據(jù)，指令，文檔)ny/nyyyyyydetermination of requirementsnyyyyyyy專用的容災硬件和機房ny/nyyyyyy災難恢復計劃nnyyyyyy選擇性的異地數(shù)據(jù)保存nnyyyyyy支持危機時候的足夠的硬件和網(wǎng)絡設備nnyyyyyy至少部分信息的電子方式的備份nnnyyyyyactive management of recovery data by aprocessor at the recovery sitennnnyyyy雙向恢復nnnnyyyy物理分離nnnnyyyy所選數(shù)據(jù)的鏡像nnnnnyyy異地部分或全部的硬件備份nnnnnyyy主備中心數(shù)據(jù)即時異地傳輸nnnnnnyy根據(jù)策略自動切換到災備中心nnnnnnny典型恢復時間uptonever 1week 1day1 day 1day 12hours 6hoursfewmins.tier 1 - ptam“卡車”運送訪問方式 (pickup truck access method)tier 1 的災難恢復方案必須設計一個嚴格的數(shù)據(jù)備份方案，能夠備份所需 要的信息并將它遞送存放在異地，然后根據(jù)恢復的具體需求，有選擇地建立 備份平臺，但不提供數(shù)據(jù)處理的硬件。ptam 是一種被用于許多中心的備份的標準的方式，數(shù)據(jù)在完成寫操作的一 些時候，將會被送到遠離本地的地方，同時準備有數(shù)據(jù)恢復的程序。在災難發(fā)生后，一整套安裝需要在一臺未開啟的計算機上重新完成。系統(tǒng)和數(shù)據(jù)可以被恢復并重新與網(wǎng)絡相連。這種災難恢復方案相對來說成本較低(僅僅需 要傳輸工具的消耗以及存儲設備的消耗)。但同時有這樣的問題，那就是難 于管理，即很難知道什么樣的數(shù)據(jù)在什么樣的地方。tier 2 - ptam 卡車運送訪問方式+熱備份站點 (ptam + hotsite)tier 2 相當于 tier 1 再加上熱備份中心能力的進一步的災難恢復。熱備份 中心擁有足夠的硬件和網(wǎng)絡設備去支持關鍵應用的安裝需求，這樣的應用是 十分的關鍵的，它必須在災難發(fā)生的同時，在異地有與生產環(huán)境相類似的硬 件提供支持。這種災難恢復的方式依賴于 ptam 方法去將日常數(shù)據(jù)放入倉庫， 當災難發(fā)生的時候，數(shù)據(jù)再被移動到一個熱備份的中心。雖然移動數(shù)據(jù)到一 個熱備份中心增加了成本，但卻明顯降低了災難恢復時間。tier 3 - 電子鏈接方式 (electronic vaulting)tier 3 是在 tier 2 的基礎上用電子鏈路取代了卡車進行數(shù)據(jù)的傳送的進一 步的災難恢復。接收方的硬件必須與主中心物理地相分離，在災難發(fā)生后， 存儲的數(shù)據(jù)用于災難恢復，由于熱備份中心要保持持續(xù)運行，增加了成本。 但消除了傳輸工具的需要，提高了災難恢復速度。tier 4 - 數(shù)據(jù)庫鏡像和日志方式 (batch/online database shadowing & journaling)tier 4 是在 tier3 的基礎上，以數(shù)據(jù)庫遠程備份為基礎。災難恢復具有兩 個中心同時處于活動狀態(tài)并管理彼此的備份數(shù)據(jù)，允許備份行動在任何一個 方向發(fā)生。接收方硬件必須保證與另一方平臺物理地分離，在這種情況下， 工作負載可能在兩個中心之間分享，中心 1 成為中心 2 的備份，反之亦然。 在兩個中心之間，彼此的在線關鍵數(shù)據(jù)的拷貝不停地相互傳送著。在災難發(fā) 生時，需要的關鍵數(shù)據(jù)通過網(wǎng)絡可迅速恢復，通過網(wǎng)絡的切換，關鍵應用的 恢復也可降低到小時級。tier 5 - 兩點兩階段提交 (two-site two-phase commit)tier 5 在 tier 4 的基礎上管理著被選擇的數(shù)據(jù)(根據(jù)單一 commit 的范圍在 本地和遠程數(shù)據(jù)庫中同時更新數(shù)據(jù))，也就是說，在更新請求被認為是滿意 之前，tier 5 需要生產中心與備份中心的數(shù)據(jù)都被更新。我們可以想象這 樣一種情景，數(shù)據(jù)在兩個中心之間相互映像，由遠程 two-phase commit 來 同步。tier5 為關鍵應用使用了雙重在線存儲，在災難發(fā)生時，僅僅傳送中 的數(shù)據(jù)被丟失，恢復時間被降低到分鐘級。tier 6 - 無數(shù)據(jù)丟失 (zero data loss)tier 6 可以實現(xiàn)零數(shù)據(jù)丟失率，同時保證數(shù)據(jù)立即自動地被傳輸?shù)交謴椭?心。tier6 被認為是災難恢復的相當高的級別，通過使用文件系統(tǒng)或存儲硬 件底層的數(shù)據(jù)同步/異步鏡像功能，保證數(shù)據(jù)的實時一致性和完整性。tier 7 - 無數(shù)據(jù)丟失和應用自動切管 （zero data loss + app automatictakeover）tier 7 在 tier 6 的基礎上，在本地和遠程的所有數(shù)據(jù)被更新的同時，利用 了雙重在線活動的主機，備份數(shù)據(jù)和完全的網(wǎng)絡切換能力，實現(xiàn)應用程序的 實時監(jiān)控和接管。tier7 是災難恢復中最昂貴的方式，但也是需人工干預最 少，速度最快的恢復方式。3.5容災技術方案選型考慮首先讓我們確定一下此次容災建設的一些背景條件：1. 移動總部發(fā)布了 boss 1.5 規(guī)范，上海移動正在加緊進行 boss 應用的改 造。這個說明在容災系統(tǒng)實施的同時，業(yè)務環(huán)境也在發(fā)生變化。所以對 于具體選用何種技術就有很高的要求，譬如說通過應用程序層來實現(xiàn)容 災就不現(xiàn)實了，因為一旦業(yè)務改動就需要改動容災方案，基本上是不可 能的事情。2. 局方同時可能會啟動 boss 網(wǎng)管項目，整個業(yè)務支撐平臺的系統(tǒng)管理都 會在網(wǎng)管項目中考慮，所以在這個方案設計報告中就不對系統(tǒng)管理這一 塊內容加以詳細闡述。3. 本方案設計書將闡述 boss 網(wǎng)管沒有具體規(guī)定的存儲和存儲網(wǎng)的管理。在我們的設計報告中，我們首先對整個容災系統(tǒng)的架構進行設計，然后對其 中的各個要素分別加以闡述。容災系統(tǒng)建設中很重要的是如何將生產數(shù)據(jù)傳輸或復制到容災中心，我們需 要考慮的是在系統(tǒng)的那一個層次上的復制數(shù)據(jù)和采用何種機制。 技術的發(fā)展讓 我們有了更多更好的選擇而不必受一些具體產品的約束。下圖是目前業(yè)界最常用 的成熟的技術。我們認為，首先需要一種技術方案，它的建設實施對應用和在用系統(tǒng)影響最小，同時又能滿足生產系統(tǒng)變動的需要。而對于某些特定應用，如果僅僅采用其 中的一種方案是可能不能完全滿足恢復需要，如一些聯(lián)機的實時交易的應用，一 種方式顯得太單薄，所以對這些應用，我們建議用復合式的容災技術方案。究竟 以那種技術為主，那種為輔，應該考慮實際情況。下圖是最近移動欽州機房發(fā)生影響生產的故障統(tǒng)計：2004年1月到8月影響生產的故障統(tǒng)計26%39%6%26%3%數(shù)據(jù)庫故障應用故障網(wǎng)絡故障主機故障例行維護從中可以看出，發(fā)生頻率最高，對生產造成最大影響的是數(shù)據(jù)庫故障，其次是至少每月一次的例行維護和較高的網(wǎng)絡故障，而應用故障和主機故障相對影響 較小。其中的數(shù)據(jù)庫故障大多時候都可以通過重啟數(shù)據(jù)庫來解決，這些本身可能 由于 oracle 8 版本軟件的缺陷造成，數(shù)據(jù)庫重啟時往往涉及到 recovery 過程， 如果有些意外發(fā)生時，recovery 的過程會很長，可能幾個小時才能完成，這時 重啟數(shù)據(jù)庫就遠遠不能滿足業(yè)務需求。針對這種情況，我們認為，保持數(shù)據(jù)庫的 高可用性是最重要的，其次是網(wǎng)絡，在上海移動，ip 網(wǎng)絡目前的故障較多，而 光網(wǎng)路相對來說比較穩(wěn)定，這也為采用存儲層的使用 dwdm 技術的方案提供的基 礎保證。就數(shù)據(jù)本身而言，字節(jié)程度的一致性的重要性比不上交易程度的一致性 來得重要，所以，我們應該強調當生產數(shù)據(jù)庫發(fā)生故障時，可以最快速度恢復?；谝陨峡紤]我們給出下表的推薦，5 為最高，1 為最低。容災技術技術成熟 度數(shù)據(jù)丟失情況硬件要求實施難易程度對在用系統(tǒng)影響推薦程度（15）存儲服務器層（ tier 6）成熟不丟或少量同一品牌存儲較易較少4san 層(tier 6)成熟不丟或少量fc 連接較易較少3操作系統(tǒng)層(tier 6 or 7)成熟不丟或少量同一品牌主機較易較大3數(shù)據(jù)庫層(tire4 or 5)成熟部分丟失較易較大3.5由表中可以看出，對于建議采用復合方式的應用來說，我們推薦使用數(shù)據(jù)庫層和存儲層結合的復合方案。存儲層可以在存儲產品層，也可以在 san 交換機層。手動/自動啟動容災 我們知道，自動容災技術可以自動識別災難的發(fā)生并且自動啟動恢復程序，將應用在容災中心自動重啟?？墒墙Y合國內實情，自動容災方式并不是很適合上 海移動，因為是否啟動容災系統(tǒng)不僅僅是一個技術問題，其中有一個決策過程， 還有一個切換的程度的問題。采用手動切換，可以將主動權握在手里。傳統(tǒng)磁盤遠程鏡像的基本概念 傳統(tǒng)基于磁盤的鏡像方式是由存儲設備控制通過數(shù)據(jù)通道，以邏輯卷為基本單位，將本地磁盤陣列上的數(shù)據(jù)鏡像到遠端的同構磁盤陣列上比如 ibm的 pprc 和 emc 的 srdf。基于磁盤的鏡像功能傳統(tǒng)上提供 2 種工作方式，同步（左圖）和異步方式（右圖）：在同步方式下，磁盤鏡像功能只有在本地和遠程磁盤都完成寫操作后才會向 主機發(fā)回“io 完成”消息，以確保源卷和目的卷的數(shù)據(jù)徹底一致。好處是：可以保證數(shù)據(jù)不會丟失可以保證數(shù)據(jù)的一致性 缺點是：對網(wǎng)絡和距離要求很高：需要高帶寬和距離一般不能超越城域對生產系統(tǒng)的性能影響也比較大在異步工作方式下，磁盤鏡像功能能夠在遠端更新未完成的情況下，只要本地更新成功就可以向主機返回“寫成功”信號。好處是：對網(wǎng)絡和距離的要求非常低對性能的影響非常小壞處是：數(shù)據(jù)一般情況下會丟失普通異步方式無法保證 io 的次序，所以在進行異步操作時，遠程鏡 像卷始終處于異步造成的“不一致”狀態(tài)，直到所有數(shù)據(jù)“全部傳遞 完畢”。如果應用是 7*24 小時不間斷的，就無法達到數(shù)據(jù)“全部傳 遞完畢”狀態(tài)。所以，異步備份一般只用于數(shù)據(jù)移植，或者和磁盤本 地鏡像結合，用于傳遞相對靜止的數(shù)據(jù)保證數(shù)據(jù)一致性的異步遠程鏡像 為了同時利用同步的數(shù)據(jù)一致性優(yōu)勢和異步的性能/距離優(yōu)勢，各個存儲廠商都推出了一些能夠保證數(shù)據(jù)一致性的異步遠程鏡像方式，主要是 ibm 的 pprcgm 和 emc 的 srdf/a。為了 100%的保證數(shù)據(jù)一致性和可用性，所有類似的技術都必須采用 3 份數(shù) 據(jù)的方式進行操作（本地 1 份，遠程 2 份）。ibm pprc gm 的工作方式如下：工作方式如下（其中綠色為生產站點磁盤，橙色和藍色為容災站點磁盤）：1. 綠色和橙色磁盤之間進行 pprc-xd 異步操作2. 綠色磁盤組根據(jù)預先設置的時間，生成“一致性組”（consistencygroup），并記錄狀態(tài)3. 采用 pprc-xd 異步操作方式，將且只將“一致性組”記錄下來的數(shù)據(jù) 傳遞從綠色磁盤組傳遞到橙色磁盤組4. 3 完成后，立刻將橙色磁盤組數(shù)據(jù) flashcopy 到藍色磁盤組，進行一 致性數(shù)據(jù)保留5. 4 完成后，回到步驟 1由于有“一致性組”的保護，雖然采用異步方式，一旦每一個“一致性組” 數(shù)據(jù)包傳遞成功的那一時刻，橙色磁盤組的數(shù)據(jù)是一致的；由于步驟 4，藍色磁 盤組將能夠保留最近一次“一致性完全”的數(shù)據(jù)。一旦出現(xiàn)災難，客戶丟失的是 兩次生成“一致性組”間隔之間的數(shù)據(jù)。如果網(wǎng)絡發(fā)生故障，pprc gm 會等待網(wǎng)絡恢復，重新生成“一致性組”（對 于經(jīng)歷的較長時間網(wǎng)絡故障的系統(tǒng)而言，只是新的“一致性組”中的數(shù)據(jù)會比較 大而已），繼續(xù)進行 pprc gm 的正常操作。pprc gm 能夠每 35 秒生成一次“一致性組”，意味著客戶即使采用異步方 式，也有可能只丟失 35 秒的數(shù)據(jù)。emc srdf/a 的工作方式如下：srdf/a 使用“增量集”來短期維護一組寫入操作。增量集是 srdf/a 所提供的所有功能的基礎。srdf/a 使用四種類型的增量集來管理數(shù)據(jù)流處理過程。srdf/a 的數(shù)據(jù) 流可歸結為幾個步驟:源位置的增量集：捕獲 - 在緩存中捕獲所有傳入到 srdf/a 組所涉及的源卷的寫入 操作。完成此“捕獲增量集”后，該集合中的寫入操作將被“折 疊”，并升級為“傳輸增量集”，同時開始傳輸其中的內容。（然 后另外創(chuàng)建一個新的捕獲增量集，來維護下一個寫入操作增量 集。）傳輸 - 將內容從源系統(tǒng)傳輸?shù)侥繕讼到y(tǒng)，僅傳輸最近的寫入操作 集。目標位置的增量集：接收 - 接收增量集位于目標系統(tǒng)上，用于接收由源位置的傳輸增 量集傳來的數(shù)據(jù)。接收到全部數(shù)據(jù)后，它將升級為應用增量集。 應用 - 將增量集中的寫入操作應用到目標卷，以創(chuàng)建一致的可重新 啟動的遠程拷貝。這就完成了增量集循環(huán)。如果網(wǎng)絡發(fā)生故障，由于 srdf/a 使用“增量集”存在于磁盤系統(tǒng)的高速緩存 中，一定時間的故障會造成高速緩存溢出，此時必須中斷 srdf/a，等待網(wǎng)絡恢 復。從網(wǎng)絡故障到恢復之間的數(shù)據(jù)只能夠采用傳統(tǒng)的 srdf 異步方式傳遞，為了 防止異步傳遞被異常中斷而造成對遠程數(shù)據(jù)庫的破壞，在傳遞數(shù)據(jù)之前必須采用 timefinder 保護一下遠程的數(shù)據(jù)，然后才能夠繼續(xù)操作。4 容災系統(tǒng)方案設計4.1 上海移動系統(tǒng)現(xiàn)狀上海移動目前主要有兩個生產機房，一個在欽州，一個在橫浜，業(yè)務分布如 下圖所示：欽州路生產中心：營帳、計費、網(wǎng) 間結算、充值、經(jīng) 營分析和ondemand橫浜路生產中心：1860客服系統(tǒng)上海移動目前的主要應用系統(tǒng)均運行在aix 433和oracle 8174下，部分業(yè)務運行在aix 5.1/5.2下，但數(shù)據(jù)庫依然為oracle 8i；存儲設備有ibm ess 和7133 也有emc存儲。部分產品將根據(jù)實際情況升級，但不在本方案中具體涉及。系統(tǒng)主機設備/地點存儲設備/地點營帳s85x2/欽州，2004年4季度將 f20/欽州,2004年4季度更新為p5-570x2將新增一臺ess800,計 費與營帳的存儲將分 開。計費s85x2/欽州f20/欽州1860p650x2/橫浜e20/橫浜 經(jīng)營分析p690x2/欽州emc/欽州 充值p630x2/欽州7133/欽州 采集h85x1/欽州f20/欽州 網(wǎng)間結算m80x2/欽州f20/橫浜下面將會對這些系統(tǒng)的容災方案進行具體闡述。4.2容災架構整體設計容災系統(tǒng)總體架構設計綜合以上要求，我們實際如下的容災系統(tǒng)整體架構，在這個架構中，對實時 性恢復要求高的核心業(yè)務的數(shù)據(jù)庫，我們考慮了兩層容災設計。這里的核心業(yè)務 我們認為是營帳數(shù)據(jù)庫，充值數(shù)據(jù)庫和1860數(shù)據(jù)庫。對于計費，經(jīng)營分析，網(wǎng)間 結算，批價等，我們考慮存儲層的容災。由于從實際業(yè)務中，以下具體應用模塊和數(shù)據(jù)庫是關鍵性的，所以單獨對這 些模塊進行進一步說明。由于boss 1.5的具體稱呼有些變化，但鑒于目前為止改 造項目并沒有實施完成，所以，我們主要從數(shù)據(jù)庫和數(shù)據(jù)一層考慮業(yè)務的具體特 性和容災方式。營帳系統(tǒng)營帳系統(tǒng)是移動業(yè)務中的核心系統(tǒng)，實時性要求高，對于容災系統(tǒng)的要求也 是最高，所以在此我們考慮使用數(shù)據(jù)庫備份模式加上存儲層數(shù)據(jù)鏡像模式。使用 業(yè)界成熟流行的數(shù)據(jù)庫實時抽取技術或者standby database技術，在生產中心隨 時保留一個與生產庫基本同步的數(shù)據(jù)庫，該數(shù)據(jù)庫是處于open狀態(tài)的。這樣可以 在發(fā)生數(shù)據(jù)庫邏輯可以快速接管。這種方案的缺點是可能會有一些數(shù)據(jù)需要在事 后進行補錄，但丟失的數(shù)據(jù)是非常少的。具體容災架構如下圖：營帳系統(tǒng)容災架構圖所有營帳數(shù)據(jù)庫里的數(shù)據(jù)都會通過存儲層的方案鏡像到金橋中心。本地通過數(shù)據(jù)抽取另生成一個active的數(shù)據(jù)庫，與源數(shù)據(jù)庫近乎同步， 一旦需要，可立即將應用切換過來。如果本地有兩個物理存儲，考慮到 高可用性，可以將抽取出來的數(shù)據(jù)放到另外一個存儲設備上。目前計劃進行營帳系統(tǒng)“瘦身”計劃，擬將目前營帳數(shù)據(jù)庫中的歷史庫 剝離開，營帳庫中僅僅保留核心數(shù)據(jù)，這樣更加適合采用復合方式。如果碰到非數(shù)據(jù)庫邏輯錯，本地接管不能恢復，那么就盡快啟動金橋中 心的備份?？头?860系統(tǒng)1860系統(tǒng)對于移動維系和提高客戶關系和客戶滿意度有著極其重要的意義， 同時1860系統(tǒng)也是一個實時聯(lián)機交易系統(tǒng)。目前有計劃將c/s結構逐步改造成為 w/s結構，這樣本次備份中僅僅考慮數(shù)據(jù)庫服務器。應用服務器可以不必考慮專 用的備份。1860容災系統(tǒng)架構如下圖所示：1860容災系統(tǒng)架構圖所有1860數(shù)據(jù)庫里的數(shù)據(jù)都會通過存儲層的方案鏡像到金橋中心。本地通過數(shù)據(jù)抽取另生成一個active的數(shù)據(jù)庫，與源數(shù)據(jù)庫近乎同步， 一旦需要，可立即將應用切換過來。如果碰到非數(shù)據(jù)庫邏輯錯，本地接管不能恢復，那么就盡快啟動金橋中 心的備份。不必考慮專用的應用服務器，可以共享。計費系統(tǒng) 計費業(yè)務處理屬于boss后臺處理，其業(yè)務中斷對客戶業(yè)務受理不產生直接影響，但是，計費業(yè)務的中斷將間接影響漫游用戶處理、帳務處理、交費、用戶查詢等業(yè)務功能，這將會一定程度上影響客戶滿意度，并導致基于boss的預付費業(yè) 務產生透支及壞帳，所以一旦計費業(yè)務故障發(fā)生，也必須在最短時間內恢復。計 費業(yè)務的數(shù)據(jù)主要分為數(shù)據(jù)庫里的數(shù)據(jù)和文件系統(tǒng)中的原始話單。兩部分數(shù)據(jù)可 以統(tǒng)一用存儲層的技術解決，但是較好的辦法是：數(shù)據(jù)庫里的數(shù)據(jù)用存儲技術實 現(xiàn)，文件系統(tǒng)的話單可以由應用程序增加分發(fā)路徑，多放一份拷貝即可。計費系 統(tǒng)由于數(shù)據(jù)庫龐大，同時實時性沒有聯(lián)機交易系統(tǒng)要求高，所以不考慮standby 數(shù)據(jù)庫的方式。計費系統(tǒng)容災架構如圖所示：計費容災系統(tǒng)架構圖數(shù)據(jù)庫里的數(shù)據(jù)通過存儲技術鏡像到金橋中心。文件系統(tǒng)的話單通過增加分發(fā)路徑傳輸?shù)浇饦蛑行模枰?