兩地三中心容災解決方案

兩地三中心容災解決方案 2010 12 26 兩地三中心容災解決方案 第 2 頁 目目 錄錄 1 兩地三中心兩地三中心 容災系統(tǒng)建設的功能目標容災系統(tǒng)建設的功能目標 3 2兩地三中心兩地三中心 容災系統(tǒng)技術方案容災系統(tǒng)技術方案 4 2 1總體設計方案 4 2 2容災方案實現(xiàn) 5 2 2 1同城應用級容災方案 5 2 2 2異地數(shù)據(jù)級災備方案 6 3基于基于 SHAREPLEX 的容災方案的容災方案 7 3 1SHAREPLEX FOR ORACLE產(chǎn)品介紹 7 3 2SHAREPLEX主要技術指標 8 4成功案例成功案例 10 4 1銀聯(lián)數(shù)據(jù) 10 4 2山西移動 12 4 3北京地稅 15 4 4SHAREPLEX國內部分客戶 18 兩地三中心容災解決方案 第 3 頁 1 兩地三中心兩地三中心 容災系統(tǒng)建設的功能目標容災系統(tǒng)建設的功能目標 理想目標 在確保系統(tǒng)穩(wěn)定安全的前提下 顛覆 切換時長 數(shù)據(jù)丟失 平時不用 浪費投資 決策困難 影響巨大 演練復雜 風險增加 的傳統(tǒng) 災備 模式 創(chuàng)建全新 容災 理念 使新增投資平時發(fā)揮生產(chǎn)效力 實現(xiàn)容納各種災難 確保業(yè)務連續(xù)和數(shù)據(jù) 安全的嶄新模式 同城應用級容災 覆蓋能被客戶直接感知的各類業(yè)務 平時與主機房同時運行 負載 均衡使用 可分擔各查詢業(yè)務流量 當容災機房或主機房任何一處出現(xiàn)災難造成的非計劃 內停機 則另一個機房都能在保證不丟失數(shù)據(jù)的前提下 繼續(xù)對外提供同樣的服務 對業(yè) 務或對客戶的感覺影響極低 異地容災 異地容災機房 存放一臺存儲設備和一臺核心業(yè)務驗證服務器 異步存儲 數(shù)據(jù) 容許 0 15 分鐘數(shù)據(jù)丟失 發(fā)生城市級災難時仍可以有效恢復生產(chǎn)系統(tǒng)核心數(shù)據(jù)和 最終實際目標 以系統(tǒng)穩(wěn)定 安全 高效為基本前提 經(jīng)嚴格論證和實測 可以逐步 退守 直至實現(xiàn)一定投資下 高可用性和高安全性 的平衡 容災系統(tǒng)將能夠應對下述的災難和風險 確保數(shù)據(jù)安全性和業(yè)務連續(xù)性 災災難難發(fā)發(fā)生生的的百百分分比比統(tǒng)統(tǒng)計計 電源問題 硬件 軟件 程序故障 機房其它基礎設施故障 系統(tǒng)設計失誤 小失誤 故障長期累加 人為操作失誤或瀆職 蓄意破壞 病毒 黑客 網(wǎng)絡 線路故障 技術失敗 大規(guī)模自然災害 其它 0102030405060708090100 Number of Declarations 兩地三中心容災解決方案 第 4 頁 2兩地三中心兩地三中心 容災系統(tǒng)技術方案容災系統(tǒng)技術方案 2 1總體設計方案總體設計方案 生產(chǎn)系統(tǒng)的容災系統(tǒng)擬建成 兩地三中心 模式 同城雙中心是指在同城或鄰近城市建立兩個可獨立承擔關鍵系統(tǒng)運行的數(shù)據(jù)中心 雙 中心具備基本等同的業(yè)務處理能力并通過高速鏈路實時同步數(shù)據(jù) 日常情況下可同時分擔 業(yè)務及管理系統(tǒng)的運行 并可切換運行 災難情況下可在基本不丟失數(shù)據(jù)的情況下進行災 備應急切換 保持業(yè)務連續(xù)運行 同城應用級容災的主要目標為業(yè)務連續(xù)性 同城雙中心需要數(shù)據(jù)實時同步或準同步 RPO 0 同城范圍有效保證了數(shù)據(jù)的安全性和業(yè)務連續(xù)性 異地災備中心是指在異地的城市建立一個備份的災備中心 用于雙中心的數(shù)據(jù)備份 當雙中心出現(xiàn)自然災害等原因而發(fā)生故障時 異地災備中心可以用備份數(shù)據(jù)進行業(yè)務的恢 復 異地災備系統(tǒng)的主要目標為數(shù)據(jù)安全性 復制距離較遠 容災距離 一般 200 公里以 兩地三中心容災解決方案 第 5 頁 上 主要應對地區(qū)級數(shù)據(jù)風險 本方案中計劃在?？诮惖氐臄?shù)據(jù)備份中心 在異地復 制方案中 一般采用異步復制技術 需要盡可能降低數(shù)據(jù)丟失機率 帶寬要求低 減少維 護性成本 數(shù)據(jù)庫同步方案 在本方案中 建議使用 SharePlex for Oracle 軟件來實現(xiàn)生產(chǎn)系統(tǒng)數(shù)據(jù)庫到同城災備中 心和異地災備中心的數(shù)據(jù)準實時同步 非結構化數(shù)據(jù)同步方案 對于目前生產(chǎn)系統(tǒng)中的非結構化數(shù)據(jù) 同城的災備中心可使用同時上傳的方式 即應 用程序每次將文件上傳時 要求必須同時上傳到生產(chǎn)中心和同城的災備中心 以保證應用 切換后 所有非結構化數(shù)據(jù)均可在同城容災中心訪問 異地的災備中心 因僅需要實現(xiàn)數(shù)據(jù)的異地備份功能 則可以考慮使用腳本定期將生 產(chǎn)系統(tǒng)產(chǎn)生的非結構化數(shù)據(jù)傳輸?shù)疆惖貫膫渲行牡姆绞綄崿F(xiàn) 文件的更新頻率可根據(jù)生產(chǎn) 系統(tǒng)業(yè)務量 以及容災需求來確定 本方案中建議每 30 分鐘同步一次增量的文件 同步方 式可使用 FTP 腳本或其他第三方文件同步工具實現(xiàn) 2 2容災方案實現(xiàn)容災方案實現(xiàn) Oracle 異異地地災災備備數(shù)數(shù)據(jù)據(jù)庫庫 SharePlex RAC Oracle 生生產(chǎn)產(chǎn)數(shù)數(shù)據(jù)據(jù)庫庫同同城城災災備備數(shù)數(shù)據(jù)據(jù)庫庫 RAC Oracle SharePlex 終端客戶 網(wǎng)絡切換設備 兩地三中心容災解決方案 第 6 頁 2 2 1 同城應用級容災方案同城應用級容災方案 由于目前生產(chǎn)系統(tǒng)才用的均為 C S 結構的應用 因此 本方案中 同城的應用接管建 議使用網(wǎng)絡層面的切換來實現(xiàn) 當生產(chǎn)中心數(shù)據(jù)庫主機出現(xiàn)系統(tǒng)級故障 暫時不可用時 可使用網(wǎng)絡設備 通過 地址或域名解析的方式 將所有終端客戶重新指引到同城的災 備中心數(shù)據(jù)庫服務器 實現(xiàn)業(yè)務的全面接管 切換決策切換決策 本方案中建議采用專用的負載均衡設備來實現(xiàn) 地址或主機域名的切換 該設備 通常可自動檢測數(shù)據(jù)庫是否可用等狀態(tài) 并可實現(xiàn)自動的切換 但本方案中 考慮 到整個系統(tǒng)的安全性和穩(wěn)定性 建議最終的切換決策必須手工確認 如使用網(wǎng)絡設 備自動實現(xiàn) 則可能在某些特殊的情況下增加以外的切換風險 正向接管和反向回切 正向接管和反向回切 在出現(xiàn)問題后 SharePlex 解決方案可以進行應用接管 而當原系統(tǒng)恢復正常時 可 以將接管期間的增量數(shù)據(jù)反向同步回去 平滑地實現(xiàn)接管和反向回切 切換步驟及時間切換步驟及時間 本方案中的應用接管將主要包括網(wǎng)絡切換和數(shù)據(jù)庫的切換步驟 網(wǎng)絡切換可有硬件 設備自動完成 數(shù)據(jù)庫切換則需要在切換前確認容災數(shù)據(jù)庫的運行狀態(tài) 并執(zhí)行一 些相關的切換腳本 所有步驟均可在方案部署時統(tǒng)一編寫腳本 確保整個切換步驟 簡單 迅速 根據(jù)現(xiàn)有生產(chǎn)系統(tǒng)的實際情況 切換時間可控制在 分鐘以內 終端用戶影響終端用戶影響 生產(chǎn)系統(tǒng)現(xiàn)有的用戶主要通過 C S 方式訪問系統(tǒng) 因此 在生產(chǎn)系統(tǒng)數(shù)據(jù)庫出現(xiàn)故 障時所有用戶會出現(xiàn)數(shù)據(jù)庫連接中斷的錯誤 當災備數(shù)據(jù)庫實現(xiàn)接管后 僅需要重 新連接數(shù)據(jù)庫服務器即可繼續(xù)使用 不需要任何額外的切換或操作步驟 2 2 2 異地數(shù)據(jù)級災備方案異地數(shù)據(jù)級災備方案 生產(chǎn)系統(tǒng)異地災備系統(tǒng)的設計目標是發(fā)生城市級災難時仍可以有效恢復數(shù)據(jù)和柜面行 內業(yè)務 即實現(xiàn)數(shù)據(jù)安全保護和核心業(yè)務的業(yè)務連續(xù)性 提供可恢復能力 數(shù)據(jù)保護能力數(shù)據(jù)保護能力 建立異地災備系統(tǒng)最重要的目標是保障核心業(yè)務系統(tǒng)的數(shù)據(jù)安全 規(guī)避數(shù)據(jù)風險 保障數(shù)據(jù)在任何情況下萬無一失 通過 SharePlex 進行數(shù)據(jù)復制 目標系統(tǒng)是一個打 開的 看得見 摸得著 數(shù)據(jù)庫 不會出現(xiàn)基于硬件方式復制在極端情況下無法打 開數(shù)據(jù)庫的風險 可以最大程度地保障寶貴數(shù)據(jù)的安全性 網(wǎng)絡帶寬使用網(wǎng)絡帶寬使用 帶寬使用較少不僅可以減少電信網(wǎng)絡的租用費用 還可以滿意日后數(shù)據(jù)增長的擴展 性需求 通過 SharePlex 進行數(shù)據(jù)復制 對帶寬使用只有日志文件 1 3 的內容 而且 平均分布到所有時間點 可以極大地節(jié)省帶寬租用的成本 不僅可以滿足現(xiàn)有的需 求 還可以滿意日后數(shù)據(jù)增長的擴展性需求 復制延遲復制延遲 數(shù)據(jù)延遲關系到災難發(fā)生時的數(shù)據(jù)丟失多少 對于異地災備來說 任何復制技術必 然會數(shù)據(jù)延遲和數(shù)據(jù)損失 數(shù)據(jù)損失越少越好 SharePlex 解決方案隨時解析聯(lián)機日 兩地三中心容災解決方案 第 7 頁 志 存儲到自己的隊列并傳輸?shù)侥繕讼到y(tǒng) 然后加載到數(shù)據(jù)庫中 這個過程的延遲 非常小 兩地三中心容災解決方案 第 8 頁 3基于基于 SharePlex 的容災方案的容災方案 3 1 SharePlex for Oracle產(chǎn)品介紹產(chǎn)品介紹 下圖所示為 SharePlex for Oracle 的基本結構 數(shù)據(jù)捕獲數(shù)據(jù)捕獲 SharePlex for Oracle 由捕獲進程來收集發(fā)生變化的數(shù)據(jù) 捕獲進程駐留在源系統(tǒng)上 自動讀取 Oracle 的在線日志文件 這種讀操作是從操作系統(tǒng)的角度來完成的 而不是通過 數(shù)據(jù)庫 通過將日志文件作為獲取變化信息的源泉 Quest 可以完成數(shù)據(jù)的復制而不會給 生產(chǎn)系統(tǒng)帶來額外的開銷 由于 Oracle 將所有的事物變化記錄到日志中并使用日志文件進 行系統(tǒng)恢復 因此 Shareplex for Oracle 可以通過解析日志文件保障數(shù)據(jù)的一致性 捕獲進程連續(xù)監(jiān)控日志文件用以捕捉變化信息 當日志文件中出現(xiàn)一條新記錄時 兩地三中心容災解決方案 第 9 頁 SharePlex 判斷其是否屬于被復制對象 如果是 則 SharePlex 為該條記錄加入用于決定 此記錄將被發(fā)向那個主機的地址信息并將包含地址信息的記錄存放到自己的隊列中 存儲 隊列存在于數(shù)據(jù)庫之外 發(fā)生改變的數(shù)據(jù)被立即處理并被發(fā)送到目標系統(tǒng)中而不等待提交 或回滾動作的完成 因為等待提交或回滾完成將帶來延遲 當提交或回滾信息被寫入日志 文件時 它們也將被發(fā)送到目標系統(tǒng)中 從而在目標系統(tǒng)中完成相對應的操作 捕獲進程具有如下特點 捕獲進程從 Oracle 日志文件中讀取信息 因此復制過程不會給生產(chǎn)數(shù) 據(jù)庫實例帶來性能問題 只有發(fā)生改變的數(shù)據(jù)被傳輸 而不是日志文件中的全部信息 因此 SharePlex 的網(wǎng)絡負載非常小 盡管需要在 Oracle 數(shù)據(jù)庫中安裝少量的對象用來存儲有關復制的一些 基本信息 但源數(shù)據(jù)庫不需要參與到數(shù)據(jù)捕獲和傳輸過程中 SharePlex 的捕獲進程不但可以讀取在線的日志文件 而且可以讀取歸檔日志 甚至 當歸檔日志文件被移動到其它設備上時 SharePlex 會發(fā)出提示信息 正是這種能力極大 地增強了系統(tǒng)的冗余功能 例如 如果捕獲進程由于某種原因被停止 當它重新啟動后數(shù) 據(jù)同步不會受到影響 數(shù)據(jù)傳輸數(shù)據(jù)傳輸 SharePlex for Oracle 在基于 TCP IP 協(xié)議的網(wǎng)絡環(huán)境完成源和目標系統(tǒng)之間的數(shù)據(jù)傳 輸 其相關的進程確保數(shù)據(jù)的正確接收和網(wǎng)絡數(shù)據(jù)包的正確順序 從而提供網(wǎng)絡傳輸冗余 確保數(shù)據(jù)的完整 整個數(shù)據(jù)傳輸過程無需其它的中間件 應用數(shù)據(jù)應用數(shù)據(jù) 應用進程將傳送到目標系統(tǒng)中的信息轉化為 SQL 語句 然后發(fā)送給 Oracle 執(zhí)行 SharePlex 能夠實現(xiàn)精確復制的一個重要原因就是其能保證從源數(shù)據(jù)庫到目標數(shù)據(jù)庫 的 Oracle 讀一致性 不但按順序復制事務 而且也復制上下文信息 將源數(shù)據(jù)庫中發(fā)生變 化的全部事務信息都復制到目標數(shù)據(jù)庫中 3 2 Shareplex主要技術指標主要技術指標 Shareplex 產(chǎn)品的主要技術指標見下表 兩地三中心容災解決方案 第 10 頁 指標指標描述描述 技術原理技術原理 讀取 Oracle 的日志文件 獲取數(shù)據(jù)的變化信息 傳輸?shù)侥繕讼?統(tǒng) 然后解析成 SQL 語句 在目標系統(tǒng)中執(zhí)行 復制的基本單位復制的基本單位為表 也可以選定表的行或列進行復制 支持的 復制內容見 Shareplex 的 Release Notes 支持的復制模式單向 雙向 一對多 多對一 級聯(lián)復制 對 DML 的支持支持所有 DML 操作 對 DDL 的支持 支持大部分的DDL 操作 提供靈活的配置選項 可以設置 復制或者不復制相關的DDL 操作 對集群和 RAC 的支持支持各種集群 支持 RAC 目標系統(tǒng)支持的操作目標系統(tǒng)支持 Read Write 操作 對系統(tǒng)性能的影響對主系統(tǒng) CPU 占用率 5 數(shù)據(jù)延遲和事物處理的類型 事物量 機器性能 優(yōu)化配置有關 對于 每天日志量 40G 以內的 OLTP 系統(tǒng)來說 一般延遲在 60s 以內 網(wǎng)絡資源的使用和復制表的數(shù)量有關 傳輸量最多為日志文件的 1 3 最大距離沒有限制 對異構環(huán)境的支持支持不同的存儲 主機 操作系統(tǒng) Oracle 數(shù)據(jù)庫的不同版本 兩地三中心容災解決方案 第 11 頁 4成功案例成功案例 SharePlex for Oracle 產(chǎn)品面世已經(jīng)有十年時間 目前在全球范圍內有 1000 家以上 的成功案例 其中中國大陸地區(qū)有 70 家 4 1銀聯(lián)數(shù)據(jù)銀聯(lián)數(shù)據(jù) 銀聯(lián)數(shù)據(jù)服務有限公司是中國銀聯(lián)股份有限公司 簡稱 中國銀聯(lián) 的子公司 公 司成立六年來 以銀行卡發(fā)卡數(shù)據(jù)處理外包服務為突破口 秉承 市場第一 客戶第一 服務第一 的企業(yè)理念 積極進取 勇于開拓 贏得了廣大客戶的信任和尊重 在國內發(fā) 卡數(shù)據(jù)處理外包服務市場處于絕對領先地位 截止 2009 年 6 月 30 日 公司已經(jīng)與興業(yè)銀 行 民生銀行 華夏銀行 中國郵政儲蓄銀行 花旗銀行 東亞銀行等境內外 66 家機構 簽署發(fā)卡外包服務合同 其中 58 家機構已經(jīng)在銀聯(lián)數(shù)據(jù)發(fā)卡系統(tǒng)上發(fā)卡運營 卡量累計 1700 萬張 公司主要業(yè)務包括 貸記卡業(yè)務 銀聯(lián)數(shù)據(jù)為客戶銀行提供發(fā)卡業(yè)務的一攬子解決方案 包括客戶銀 行的信用卡中心設計 業(yè)務規(guī)劃 系統(tǒng)建設 業(yè)務培訓和咨詢 7X24 小時運營 全程服務 目前 已經(jīng)與銀聯(lián)數(shù)據(jù)合作以外包模式發(fā)卡 和正在積極籌建中的合 作方已有郵政儲蓄銀行 華夏銀行 民生銀行 興業(yè)銀行 東亞銀行等四十余家 銀行 借記卡業(yè)務 是一個以處理卡片支付為主線 處理整個零售銀行業(yè)務的系統(tǒng) 已 經(jīng)過多年的實際生產(chǎn)驗證 該系統(tǒng)具有客戶管理 產(chǎn)品定義 卡片管理 賬務處 理與會計核算 業(yè)務處理和風險控制等基本功能 支持轉賬與支付 儲蓄存款 小額信貸 個人理財?shù)攘闶坫y行業(yè)務處理 提供有靈活的卡產(chǎn)品 業(yè)務產(chǎn)品定義 和卡片 客戶個性化服務定制功能 銀聯(lián)數(shù)據(jù)預付卡業(yè)務 是一個專門用于發(fā)行和管理小額支付卡的系統(tǒng) 能夠支持 國內外金融機構 非金融機構發(fā)行支付卡的業(yè)務處理 系統(tǒng)具有產(chǎn)品定義 卡片 管理和行業(yè)支付等基本功能 提供有靈活的卡片個性化服務定制功能 業(yè)務挑戰(zhàn)業(yè)務挑戰(zhàn) 為了提高為各個銀行提供卡業(yè)務的服務質量 銀聯(lián)數(shù)據(jù)計劃在北京建設異地災備系統(tǒng) 技術需求如下 兩地三中心容災解決方案 第 12 頁 接管時間 RTO 2 小時 數(shù)據(jù)恢復點目標 RPO 15 分鐘 目標系統(tǒng)平時能夠承擔查詢業(yè)務 實時可用 對網(wǎng)絡帶寬的使用小 節(jié)省電信網(wǎng)絡租用費用 提高投資回報 不影響源系統(tǒng)的運行 可擴展性強 能夠支持未來三年的數(shù)據(jù)量 解決方案解決方案 銀聯(lián)數(shù)據(jù)在與其它方案進行了仔細對比以后 確定選用 Quest 公司的 SharePlex 解決 方案 SharePlex 具有對帶寬要求低 對源系統(tǒng)性能影響小 容易部署等特點 SharePlex 解決方案如下圖 生產(chǎn)系統(tǒng)采用了 Sun 25K 建立了四個分區(qū) 每個分區(qū)上運行 1 到多個 Oracle 實例 包括不同公司的信用卡 貸計卡信息 針對每個實例 建立從上海到北京的復制鏈路 O Or ra ac cl le e R RA AC C O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e R RA AC C O Or ra ac cl le e O Or ra ac cl le e S Sh ha ar re eP Pl le ex x O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e 分分區(qū)區(qū)A A 分分區(qū)區(qū)B B 分分區(qū)區(qū)C C 分分區(qū)區(qū)D D S SF F 2 25 5K K S SF F 1 15 5K K S Sh ha ar re eP Pl le ex x S Sh ha ar re eP Pl le ex x S Sh ha ar re eP Pl le ex x S Sh ha ar re eP Pl le ex x S Sh ha ar re eP Pl le ex x 生生產(chǎn)產(chǎn)數(shù)數(shù)據(jù)據(jù)庫庫災災備備數(shù)數(shù)據(jù)據(jù)庫庫I In nt te er rn ne et t 上上 海海 北北 京京 兩地三中心容災解決方案 第 13 頁 通過 Shareplex 建立生產(chǎn)中心到災備中心的異地數(shù)據(jù)復制 當災難發(fā)生時 通過災備庫進行容災接管 災備庫可以在平時運行查詢業(yè)務 生產(chǎn)中心每臺機器上可能有多個數(shù)據(jù)庫 與目標端的數(shù)據(jù)庫一一對應 用戶收益用戶收益 銀聯(lián)數(shù)據(jù)異地災備項目實施后通過部署 Shareplex 解決方案 用戶獲得了以下收益 1 實現(xiàn)了容災系統(tǒng)建設目標 解決方案充分實現(xiàn)了容災系統(tǒng)的建設目標 目標數(shù)據(jù)庫出于打開的狀態(tài) 能夠確保目 標數(shù)據(jù)的安全性 經(jīng)過了幾次容災演習 非常順利地實現(xiàn)應用接管和反向回切 RTO 和 RPO 滿足大大低于預訂目標 2 網(wǎng)絡帶寬使用少 維護成本低 銀聯(lián)數(shù)據(jù)采用從上海到北京的復制 在目前帶寬為 4M 的情況下能夠保障復制的實時 性 Shareplex for Oracle 方案對帶寬的使用只有日志文件 1 3 對帶寬占用較少減少了 每年租用帶寬的成本 提供了總體投資回報 全面提升了銀聯(lián)數(shù)據(jù)的服務能力 容災系統(tǒng)建設后 為銀聯(lián)數(shù)據(jù)的中小銀行的信用卡和貸計卡提供了容災服務 服務的 提升可以避免現(xiàn)有客戶的流失 保持企業(yè)競爭力 4 2山西移動山西移動 用戶概述用戶概述 中國移動通信集團山西有限公司 簡稱中國移動山西公司 于 1999 年 9 月 1 日成立 2002 年 7 月在香港和紐約成功上市 成為中國移動 香港 有限公司的全資子公司 注冊 資本 28 億元人民幣 資產(chǎn)規(guī)模超過 80 億元 服務的用戶數(shù)接近 1500 萬 山西移動主要經(jīng)營移動話音 數(shù)據(jù) IP 電話和多媒體業(yè)務 計算機信息網(wǎng)絡國際聯(lián)網(wǎng) 和基于移動通信業(yè)務的各類增值業(yè)務 除提供基本話音業(yè)務外 還提供數(shù)據(jù) 傳真 IP 電 話 無線上網(wǎng) 寬帶接入 視訊通 移動辦公 信息點播 彩鈴 彩信 手機證券等多種 增值業(yè)務 擁有 全球通 神州行 動感地帶 等著名服務品牌 目前全省已建成了以營業(yè)廳服務 1860 電話服務及互聯(lián)網(wǎng)服務 大客戶個性化服務為 兩地三中心容災解決方案 第 14 頁 主體的客戶服務體系 營業(yè)網(wǎng)點達到 4200 多個 業(yè)務挑戰(zhàn)業(yè)務挑戰(zhàn) 集中化管理是 IT 系統(tǒng)發(fā)展的一個趨勢 山西公司在完成 BOSS 系統(tǒng)的集中化管理后 大大提高了系統(tǒng)的可維護性 可管理性 可擴充性 但正如把一筐雞蛋放進一個籃子里一樣 集中化管理也帶來了一定的風險 而且 近 幾年隨著業(yè)務的發(fā)展 集中的 BOSS 系統(tǒng)所支撐的客戶規(guī)模劇增 如何提高系統(tǒng)運行的高 可靠性 抵抗災難 提高業(yè)務連續(xù)運行的能力就成為山西省移動公司現(xiàn)階段面臨的一個挑 戰(zhàn) 解決方案解決方案 山西移動根據(jù)業(yè)務的迫切需求 在與其它方案進行了仔細對比以后 確定選用 Quest 公司的 基于 SharePlex 業(yè)務支撐系統(tǒng)應急 報表解決方案 SharePlex 具有對源系統(tǒng)性能 影響小 復制延遲小 并能快速的實現(xiàn)關鍵業(yè)務的接管與反向回切 以及分擔查詢報表等 業(yè)務等特點 SharePlex 解決方案如下圖 兩地三中心容災解決方案 第 15 頁 生產(chǎn)系統(tǒng)數(shù)據(jù)庫 Oracle Standby 生產(chǎn)應用服務器 Oracle Oracle 查詢應用服務器 Oracle SharePlex 備份磁帶庫 查詢 應急數(shù)據(jù)庫 RAC Archive log 生產(chǎn)系統(tǒng)使用采用 Oracle RAC 架構 由兩個節(jié)點共同承擔業(yè)務的訪問 生產(chǎn)系統(tǒng)的數(shù)據(jù)安全主要有本地的磁帶備份與基于 Oracle Standby 技術的容災數(shù)據(jù)庫 保障 應急 報表數(shù)據(jù)庫采用 SharePlex 數(shù)據(jù)復制技術 實施的同步生產(chǎn)系統(tǒng)中交費等關鍵業(yè) 務 以及報表業(yè)務所需數(shù)據(jù) 應急 報表數(shù)據(jù)庫一直處于可用狀態(tài) 可分擔生產(chǎn)系統(tǒng)的查詢業(yè)務 以減輕生產(chǎn)系統(tǒng) 數(shù)據(jù)庫的負擔 當生產(chǎn)數(shù)據(jù)庫出現(xiàn)系統(tǒng)故障 無法對外提供服務時 可由應急 報表數(shù)據(jù)庫在 3 5 分 鐘內實現(xiàn)關鍵業(yè)務的接管 用戶收益用戶收益 山西移動的應急 報表方案能夠解決各種發(fā)生概率較高的系統(tǒng)故障 保護關鍵業(yè)務應 用在 7X24 小時內不間歇運行 從技術上保障了業(yè)務系統(tǒng)的連續(xù)性和數(shù)據(jù)的安全性 獨立 的報表 查詢數(shù)據(jù)庫也大大減輕了生產(chǎn)系統(tǒng)的負擔 使得高峰期業(yè)務辦理的性能有了大幅 度的提高 快速應用接管和反向回切快速應用接管和反向回切 山西移動應急方案充分考慮到了應用 數(shù)據(jù)和系統(tǒng)各級的保護 當生產(chǎn)系統(tǒng)出現(xiàn)任何 兩地三中心容災解決方案 第 16 頁 軟件 硬件或其他不可知故障時 占整個業(yè)務量 75 以上的關鍵業(yè)務能迅速的實現(xiàn)應用的 接管 接管步驟可在幾分鐘內完成 當應用切換到應急系統(tǒng)后 SharePlex 的數(shù)據(jù)復制會 自動切換成由應急系統(tǒng)到生產(chǎn)系統(tǒng)的反向復制 并把切換之后產(chǎn)生的數(shù)據(jù)變化 以對列文 件的形式緩存在 SharePlex 獨立的隊列文件系統(tǒng)中 而當生產(chǎn)系統(tǒng)數(shù)據(jù)庫恢復后 可將切 換后所有的數(shù)據(jù)變化 反向增量同步回生產(chǎn)數(shù)據(jù)庫 同時應用可以迅速切換回生產(chǎn)數(shù)據(jù)庫 運行 SharePlex 的應急解決方案大大的降低了切換時間 切換風險以及切換操作的成本 為山西移動的業(yè)務支撐系統(tǒng)提供了有效的業(yè)務連續(xù)性保障 報表及查詢業(yè)務的分擔報表及查詢業(yè)務的分擔 通過應用和中間件雙重靈活配置 充分保證了各種情況下報表打印和數(shù)據(jù)查詢的正確 性 即達到了降低生產(chǎn)數(shù)據(jù)庫的額外壓力 又滿足了前臺業(yè)務人員對業(yè)務數(shù)據(jù)即財務數(shù)據(jù) 稽核的要求 根據(jù)報表中心遷移到應急數(shù)據(jù)后對營業(yè)數(shù)據(jù)庫性能分析 正常時段內 營業(yè)數(shù)據(jù)庫的 等待事件平均下降了 10 業(yè)務高峰時段內等待事件下降了 20 左右 以前月初由于月 報表打印導致回滾段資源緊張的情況已經(jīng)不再出現(xiàn) 由于報表的分離 目前前臺核心業(yè)務 報表的打印速度提升了 30 左右 4 3北京地稅北京地稅 用戶概述用戶概述 北京市地方稅務局是主管北京市地方稅收工作的市政府直屬機構 于 1994 年 8 月 15 日正式成立 業(yè)務上接受國家稅務總局的指導 它主要負責組織實施北京市各稅 費 種 的征收和管理 不包括已明確由國家稅務機關負責征收的地方稅部分 同時進行稅務法規(guī) 宣傳等方面的等方面的工作 北京地方稅務局于 1995 開始建設稅務管理信息系統(tǒng) 已經(jīng)形成了連接全市 23 個區(qū)縣 分局及 217 個稅務所的三級稅務專網(wǎng) 實現(xiàn)了稅收征管 辦公及綜合管理業(yè)務的電子化 目前北京地方稅務局已經(jīng)具備了進一步利用新技術 發(fā)展新的電子化應用 拓寬稅收征管 信息化應用領域 開展基于互聯(lián)網(wǎng)技術的高度統(tǒng)一 嚴格規(guī)范的納稅服務的條件 北京地稅的容災系統(tǒng)于 2004 年開始建設 其核心復制軟件 Quest Software 的 SharePlex 不但達到了系統(tǒng)的高可用性的目標 而且實現(xiàn)了投資收益的最大化 兩地三中心容災解決方案 第 17 頁 業(yè)務挑戰(zhàn)業(yè)務挑戰(zhàn) 隨著最終客戶網(wǎng)上納稅的開通 網(wǎng)上納稅的服務內容包括網(wǎng)上申報 企業(yè)年檢審批 綜合查詢等業(yè)務 以及數(shù)據(jù)集中機制的施行 鑒于稅務行業(yè)的特點 最終客戶對業(yè)務連續(xù) 性和企業(yè)數(shù)據(jù)安全性的要求也越來越高 建設一個可靠而高效的容災系統(tǒng)成為當務之急 另外由于數(shù)據(jù)量的不斷增加 市局和各個區(qū)縣的查詢業(yè)務 已經(jīng)嚴重的影響了生產(chǎn)系統(tǒng)的 性能 很多查詢業(yè)務只能等到晚上才能運行 用戶希望在保護已有軟 硬件投資的前提下 通過高效的容災系統(tǒng) 實現(xiàn)系統(tǒng)的高可用性 全力保障系統(tǒng) 24X7 的可用性 同時為區(qū)縣 級市局的查詢業(yè)務提供一個專用的與生產(chǎn)數(shù)據(jù)庫準時是同步的查詢數(shù)據(jù)庫 解決方案解決方案 北京地稅根據(jù)自己對其它 Quest 產(chǎn)品已有的應用感受 在與其它方案進行了仔細對比 以后 確定選用 Quest 公司的 SharePlex 解決方案 SharePlex 具有對源系統(tǒng)性能影響小 獨立性強 充分利用現(xiàn)有軟 硬件資源和容易部署等特點 SharePlex 解決方案如下圖 DBS01 SharePlex for Oracle SharePlex for Oracle HACMP DBS02 CP690 車公莊生產(chǎn)中心 昌平容災中心 應用服務器 應用服務器 區(qū)縣應用服務器 生產(chǎn)系統(tǒng)使用 IBM HACMP 雙機技術 兩個節(jié)點各自運行不同數(shù)據(jù)庫 并互相進 行本地的容災 同時使用 SharePlex 實現(xiàn)兩個生產(chǎn)數(shù)據(jù)庫的異地容災復制 兩地三中心容災解決方案 第 18 頁 容災數(shù)據(jù)庫在本次實施中使用單機環(huán)境 在主系統(tǒng)發(fā)生災難時 可實現(xiàn)關鍵業(yè)務 數(shù)據(jù)的恢復 容災數(shù)據(jù)庫一直處于可用狀態(tài) 可分擔生產(chǎn)系統(tǒng)的查詢業(yè)務 以減輕生產(chǎn)系統(tǒng)數(shù) 據(jù)庫的負擔 容災數(shù)據(jù)庫為區(qū)縣稅務局提供查詢業(yè)務的數(shù)據(jù)源 用戶收益用戶收益 北京地稅容災方案能夠解決各種導致計算機系統(tǒng)失效的意外情況 保護業(yè)務應用在 7X24 小時內不間歇運行 從技術上保障了業(yè)務系統(tǒng)的連續(xù)性和