./WORD格式下載可編輯×××單位數據容災備份中心建設方案書〔DSG－Realsync數據復制容災技術迪思杰〔北京數碼技術有限公司DSGdataInc..目錄第一部需求分析71容災項目建設需要注意的幾大問題81.1為什么要建容災系統81.2容災不能替換備份81.3容災項目需要多大的投資？101.4容災項目如何解決投資回收問題111.5容災項目對生產系統性能的影響121.6選擇什么容災技術能保證項目實施成功？122容災項目的建設原則"平戰結合"132.1變成本中心為利潤中心132.2核心業務的災備平臺132.3業務負載分擔132.4容災技術的推薦"DSGRealSync"14DSG-RealSync數據同步復制容災產品應用案例14DSG-SnapAssure高速備份產品應用案例152.5DSGRealSync數據庫復制產品的特點163容災技術對比和分析193.1容災產品概述193.2基于異地備份技術實現容災的分析193.3基于應用層容災技術的分析203.4基于磁盤陣列復制容災技術的分析203.5基于存儲卷復制容災技術的分析223.6基于虛擬化存儲技術的分析233.7基于OracleDataGuard容災技術的分析243.8DSGRealsync容災技術的分析26第二部整體方案設計294方案設計<案例：西部證券>304.1需求分析304.2DSG災備一體化產品線304.3Snapassure與Realsync的關系304.4容災技術的推薦314.5系統結構324.6實時復制軟件realsync配置334.7定時備份軟件snapassure配置334.8功能實現334.9性能和資源需求估算34網絡需求34日志分析速度34每秒鐘復制的操作數34復制數據延遲35CPU資源占用35源端的緩存空間35業務切換35RTO,RPO指標規劃354.10備份和災難恢復策略設計36本地和異地的數據實時備份36本地數據定時備份36災難恢復策略375方案設計的要點385.1OPS/RAC的支持385.2數據完整性保證395.3數據初始化裝載395.4選擇性復制支持415.5支持的復制結構415.6產品規格425.7其他關鍵問題〔DSG－RealSync的關鍵答復426DSG-RealSync解決方案的特點446.1業務功能實現44主備系統數據庫處于雙活狀態44以數據保護為中心,側重于保護業務數據安全44數據延遲44數據損失446.2性能和穩定性45對源系統性能的影響45對網絡資源的使用45數據延遲45對主中心的影響46復制環境的健壯性46事物的完整性和可用性466.3配置和實施47開放性47對源系統的修改工作476.4可擴展性47對系統擴容的影響47業務擴展的影響47對雙機集群的支持477DSG-RealSync產品工作原理487.1日志抓取〔DataCapture487.2日志分析〔Analyze497.3交易合成〔Synthesize507.4交易傳輸517.5數據裝載51用DXF數據格式的裝載：52Rowmapping實現快速定位528DSGSnapAssure備份產品〔可選548.1DSGSnapAssure備份技術概述54選型原則54DSGSnapAssure概述54DSGSnapAssure特點558.2SnapAssure備份產品工作原理56數據抽取57數據壓縮57備份數據的組織58備份數據的訪問58恢復功能59對非歸檔日志模式的支持608.3SnapAssure的模塊組成618.4SnapAssure支持的備份策略62SnapAssure支持的備份類型62備份策略的設計63恢復策略638.5SnapAssure對Oracle備份系統的特殊優勢648.6SnapAssure的案例66SnapAssure在XX聯通的應用：67SnapAssure在新疆電信IBSS系統中的集中備份應用67第三部項目實施及售后服務719項目實施規劃729.1項目管理729.2實施策略規劃739.3測試739.4生產系統實施749.5驗收支持759.6驗收方式759.7驗收小組構成769.8驗收工作流程圖779.9培訓78DSG—RealSync復制容災系統培訓78DSG—SnapAssure備份系統培訓799.10知識轉移809.11項目文檔809.12項目小組8110項目的具體實施步驟8210.1容災項目整體實施階段概述8210.2數據復制軟件本身實施步驟和周期8210.3容災系統狀態定義8210.4環境準備8310.5安裝和配置概述8410.6初始化復制環境、進行初始數據同步84首次全同步分析84全同步實施步驟86時間估算8610.7開始實時復制8710.8災難恢復8710.9數據一致性檢查8710.10容災中心的使用8811容災演習、容災切換和回切8911.1容災演習8911.2切換的方式8911.3數據庫的切換過程90數據庫切換方式：90數據庫切換的步驟9111.4應用服務器切換9211.5網絡切換9211.6系統回切9411.7切換自動化管理工具9412容災系統的維護和人員配置需求9512.1容災管理規劃9512.2復制軟件的日常維護9512.3人員組織結構規劃95容災項目領導小組95容災項目經理96系統專家96網絡專家9613售后服務內容及承諾9713.1服務宗旨與策略9713.2服務體系9813.3技術服務流程9813.4行業戰略級售后服務計劃99工程實施階段的服務99系統售后運行期間的服務內容10013.5服務聯系方式10114附：容災系統術語與定義10314.1災難10314.2災備站點10314.3恢復時間目標〔RTO與恢復點目標〔RPO10314.4業務持續計劃〔BCP與災難恢復計劃〔DRP10314.5系統災難級別定義10414.6災難恢復過程10514.7災難備份技術10614.8災難備份中心10714.9RPO與RTO108第四部DSG公司簡介及案例11015DSG公司簡介11115.1DSG成立和組成11115.2DSG業務范圍11115.3DSG核心技術11215.4DSG公司的業務方向11215.5DSG在國內的主要應用客戶11316附：DSG在類似項目的成功范例和相關經驗11416.1成功案例的列表11416.2成功案例的概況11516.3廣西移動營業和客服數據庫數據復制應急查詢平臺11816.4XX電信的計費查詢平臺應用12116.5XX地稅11地市本地復制和數據集中上收和容災應用12316.6長江證券集中交易系統災備應用12516.7西北證券災備一體化方案12816.8XX聯通的復制應用13116.9XX聯通業務復制應用13316.10XX網通數據復制應用案例13516.11上海松江財政容災系統應用案例13816.12XX聯通計費系統容災及查詢平臺應用14116.13SnapAssure在新疆移動BOSS系統備份的應用14316.14容災異構平臺的經驗14516.15性能指標占用參考145需求分析為什么要建容災系統隨著業務的飛速發展使其單位時間內的業務量、相關的資金密度不斷提高,因此,業務的間斷直接意味著經濟上的損失；另一方面,提供高可靠性、高水準的客戶服務也是保持良好形象的重要手段；隨著IT系統建設的不斷發展,我們在享受IT支撐系統帶來的高效率、高服務的優勢的同時,其業務運作也更加依賴于IT系統的穩定運行,其結果是,一旦發生IT系統停止運行,那么關鍵業務系統將受到嚴重影響,用戶信息、征收記錄等也隨之丟失。隨著應用系統的不斷發展完善,信息化對工商系統的業務影響也越來越明顯,為了更好地保護已有的數據資料,保證信息系統的正常運行,對一些關鍵業務的實時保護就變得異常重要,同時對關鍵數據的保護也變得十分重要。災難恢復就是在這樣的背景下提出的。本方案是根據***單位提出的容災需求,所設計的方案。如有欠缺或遺漏之處,敬請諒解！容災項目建設需要注意的幾大問題為什么要建容災系統隨著業務的飛速發展使其單位時間內的業務量、相關的資金密度不斷提高,因此,業務的間斷直接意味著經濟上的損失；另一方面,提供高可靠性、高水準的客戶服務也是保持良好形象的重要手段；隨著IT系統建設的不斷發展,我們在享受IT支撐系統帶來的高效率、高服務的優勢的同時,其業務運作也更加依賴于IT系統的穩定運行,其結果是,一旦發生IT系統停止運行,那么關鍵業務系統將受到嚴重影響,用戶信息、征收記錄等也隨之丟失。因此,小至一般性的硬件故障,大到區域性的自然災害,從物理的設備不可用,到邏輯的人為失誤和破壞,都可能造成整個信息系統的全面癱瘓,導致業務運營的停頓。災難的定義也從過去的大面積自然災害,轉變為可造成IT系統應用不可用,產生的任何故障和災害。如何才能保證盡量減少企業數據的丟失、將危險與災難的損失降低到最小程度呢？這就需要建立容災系統,包括數據容災以及應用容災。容災系統的核心就在于使用各種技術和管理手段將災難化解,在實踐中主要表現為兩個方面：一是保證企業數據的安全；二是保證業務的連續性。通過在工作站點和災難恢復站點運行同樣的系統,包括操作系統、基礎數據庫和應用軟件,并通過數據復制完成數據復制。假如工作站點發生災難,不能再繼續工作,這時容災中心會將業務數據及時恢復到備用服務器上,并自動將業務切換到備用服務器,然后實現業務的遠程切換,恢復系統不間斷的運行,在容災中心實現應用級容災,這個過程只需要很短的時間；在此基礎上,在災難過后,再將業務系統切換回正常的生產系統,實現業務的災難恢復。因此,業務連續性和容災建設的總體目標是：為關鍵業務系統提供風險預防機制和災難恢復措施,在確保數據安全的基礎上提高業務連續運行能力,降低企業運營風險,將業務損失降低到可接受的程度,提升管理和服務質量,增強企業競爭力。容災不能替換備份1．容災和備份的目的不同容災系統的目的在于保證系統數據和服務的"在線性",即當系統發生故障時,仍然能夠正常地向網絡系統提供數據和服務,以使系統不致停頓。而備份技術的目的與此并不相同,備份是"將在線數據轉移成離線數據的過程",其目的在于應付系統數據中的邏輯錯誤和歷史數據保存。所以,在各種容錯技術非常豐富的今天,備份系統仍然是不可替代的。2．備份是基石備份是指為防止系統出現操作失誤或系統故障導致數據丟失,而將全系統或部分數據集合從應用主機的硬盤或陣列復制到其它的存儲介質的過程。備份是數據高可用的最后一道防線,其目的是為了系統數據崩潰時能夠恢復數據。3．容災不可少那么建設了備份系統,是否就不需要容災系統？這還要看業務部門對RTO〔恢復所需的時間指標/RPO〔能夠恢復到的最新狀態指標的期望值,如果允許1TB的數據庫RTO＝8小時,RPO＝1天,那備份系統就能滿足要求。同時,備份的目的在于應付系統數據中的邏輯錯誤和歷史數據保存。只能夠滿足數據丟失、數據破壞時的數據恢復目的,而不能提供實時的業務接管功能。因此容災系統對于某些關鍵業務而言也是必不可少的。人們談及容災往往是針對當生產系統,不能正常工作時,其業務可由容災系統接替這些業務,繼續進行正常的工作。能夠提供很好的RTO和RPO指標。同時遠程容災系統具備應付各種災難,特別是區域性與毀滅性災難的能力,具備較為完善的數據保護與災難恢復功能,保證災難降臨時數據的完整性及業務的連續性,并在最短時間內恢復業務系統的正常運行,將損失降到最小。4．容災不能替換備份容災系統會完整地把生產系統的任何變化復制到容災端去,包括不想讓它復制的工作,比如不小心把計費系統內的用戶信息表刪除了,同時容災端的用戶信息表也會被完整地刪除。如果是同步容災,那容災端同時就刪除了；如果是異步容災,那容災端在數據異步復制的間隔內就會被刪除。這時就需要從備份系統中取出最新備份,來恢復被錯誤刪除的信息。因此容災系統的建設不能替代備份系統的建設。5．規劃企業安全保障體系考慮的因素對于企業而言到底應該如何建設自己的災備系統,是只建設備份系統、還是只建設容災系統、還是需要二者同時建設、或者是分步驟的建設,誰先誰后等問題,主要根據業務的需求而定：〔1需要防范的災難類型：企業信息系統可能遇到的災難類型及其發生的比例如下：對于"人為錯誤"、"軟件損壞和程序錯誤"加上"病毒"等這些都稱為邏輯錯誤,占總故障的56%,這些錯誤只能通過備份系統才能防范；對于"硬件和系統故障"以及"自然災難"等故障可以通過在容災系統〔或者異地備份來防范,占總故障率的44%。〔2允許的RTO和RPO指標從技術上看,衡量容災系統有兩個主要指標：RPO〔RecoveryPointObject和RTO〔RecoveryTimeObject,其中RPO代表了當災難發生時允許丟失的數據量；而RTO則代表了系統恢復的時間。一般而言：容災系統能夠提供較好的RTO和RPO指標。〔3系統投資總的說來,建設備份系統的投資遠比建設標準意義的容災系統的投資小得多：備份系統的投資規模一般在幾百萬；而最節省的一套容災系統投資都將上千萬；因為建設備份系統所需的資源在以下幾個方面的投資都遠遠小于容災系統：備份系統容災系統傳輸鏈路TCP/IP網絡帶寬一般<1GBSAN網絡獨占光纖資源帶寬要求10GB盤陣需求容量小只需要中檔陣列容量大必需高端陣列系統維護成本幾乎無需維護需建一個團隊維護6．常用的災備組合方式基于以上原因,業界在災備系統的建設上一般按照以下幾種方式：建設機房內的本地備份系統建設異地的備份系統該方式可以備份系統的價格滿足備份和異地容災功能,能夠避免主生產中心由于地震、火災或其他災害造成的數據丟失備份系統＋異地容災系統這是一個較為理想化的災備一體化解決方案,能夠在很大程度上避免各種可能的錯誤。容災項目需要多大的投資？其實這個問題也可以被反問為：你希望容災系統能達到什么效果？要想闡述清楚此問題,首先要明白兩個指標：RTO和RPO。RTO,RecoverTimeObject,恢復時間指標〔業務接管時間,是指當災難發生后,生產系統需要多長時間能夠恢復生產,它是衡量企業在災難發生后多長時間能重新開始運轉的指標。RPO,RecoverPointObject,恢復點指標〔數據丟失量,是指災難發生后,容災系統能把數據恢復到災難發生前的哪一個時間點的數據,它是衡量企業在災難發生后會丟失多少生產數據的指標。理想狀態下,我們希望RTO=0,RPO=0,即災難發生對企業生產毫無影響,既不會導致生產停頓,也不會導致生產數據丟失。從當前計算機技術水平來說,我們可以為用戶建設這種類型的容災系統,其中最著名的例子當屬VISA和Master的結算系統,由于這兩個銀行結算組織占據了全球銀行結算業務的重要地位,他們的結算系統不允許發生任何停頓和數據丟失的情況,即使在"911"這種極端情況下。但實現這樣的容災系統的投資巨大,它結合了存儲數據復制技術、服務器操作系統鏡像技術、集群技術、數據庫高可用性設計、應用系統高可用性設計、同步容災技術、異步容災技術、同城容災方案、異地容災方案,以及相應的管理流程和意外事件反映處理流程等詳細的規章制度,和人員配備、行政保障手段〔通信、交通等,綜合在一起完成一個完整的容災方案〔實際是雙生產中心或多生產中心方案,并沒有單純的容災中心。但是這種方案的投資過于巨大,目前中國可能除了中國銀聯等這種特殊性質的企業外,不會有太多的企業會去實現這個系統。目前,在電信等企業的關鍵業務系統容災項目建設中,投資規模為多少是合理的？如果業務部門能確認RTO/RPO指標,那技術部門選擇了合適的容災技術以及配套的管理流程就可以確定投資規模了。例如,如果業務部門確認,災難發生后,3個小時內營業廳恢復生產就可以滿足用戶需求,且營業系統數據不能丟失,那RTO＝3小時,RPO＝0,那就必須選擇基于存儲平臺數據復制技術的同步容災方案；如果業務部門確認,災難發生后,3天能恢復經營分析系統工作,且以前的數據丟失可以忽略不計,那RTO=3天,RPO無,那選擇ATA磁盤實現異地備份,就能滿足要求。容災項目如何解決投資回收問題從系統安全性角度考慮,我們必須為關鍵的業務支撐系統建設最有效的災難恢復解決方案。但是在大部分情況下,當未出現災難時,我們的容災端系統總是處于空閑狀態,花費大量投資買來的系統根本無法有效利用。這個問題一直困擾著用戶。為了百年不遇的災難投入巨資建設一個容災中心,容災中心的設備在災難發生前不能給企業帶來效益,這是企業決策者很難接受的,因此如何合理分配投資,將容災中心建設成為第二生產中心,與生產中心成為企業支持企業正常運行的雙中心,并實現互為容災,是降低總體擁有成本〔TCO,TotalCostofOwnership,提高投資回報率〔ROI,ReturnOfInvestment的一個重要措施,應該得到企業的高度重視。因此,我們建議在容災系統建設中,需要考慮的第一個問題是如何保證容災端的系統可以得到充分利用,使容災端系統的數據實現共享,能夠利用容災系統提供的高性能主機資源、存儲資源為企業帶來更大的處理能力。目前建設容災方案的原則都是"平戰結合",容災數據在平時能夠方便的利用〔查詢統計報表等業務分擔、實驗系統數據來源、數據倉庫中數據抽取,突出容災數據的價值,保證容災系統建設的合理性。目前能支持容災數據實時再利用的解決方案不是很多,如DSG的RealSync產品,目標系統的數據庫一直處于打開狀態,甚至在復制過程中。因此,RealSync技術除用于容災外,還可以將不同的業務模塊分布在源系統和容災系統上,實現負載分擔。因為RealSync的目標數據庫在被實時更新時可以被訪問,還可以被用于決策支持類應用。為決策分析和報表系統提供快速的數據抽取功能提供準實時脫機查詢,提高查詢效率為試驗系統提供真實的生產數據將以上本來需要在主系統上運行的業務與生產系統完全隔離,充分利用容災系統的資源,實現企業應用負載分擔,減少對生產系統的影響,提高服務系統響應效率；從而將容災系統這個成本中心轉化為利潤中心。容災項目對生產系統性能的影響容災系統的本質是將生產系統的數據以及這些數據的變化,完整地復制到容災系統中,并通過相關技術手段,確保容災系統中數據的完整性和一致性。容災系統對生產數據和生產數據的變化的復制操作,必然需要與完成這些操作相對應的CPU資源〔存儲的CPU、或服務器的CPU、內存資源〔存儲的Cache、或服務器的RAM、網絡資源〔TCP/IP、FC或FICON,如果這些資源不能獨立分配給容災系統〔實際上不可能獨立,則必然會影響生產系統的性能。因此更準確的問題是,如何確保容災系統上線后,在可以實現既定的RTO/RPO指標的同時,不會影響生產系統的正常運行？答案是可以通過技術手段實現的。要想實現,則必須對現有生產系統進行詳細的性能分析,包括系統I/O特性〔IOPS,RespondTime,讀寫比,I/O塊大小,I/O峰值、均值,時間特性等等、系統內各子系統業務特點、存儲空間分配、服務器CPU和RAM資源的使用狀況、SAN網絡情況〔端口使用狀況、Zoning劃分狀況、端口IOPS等、能夠使用的數據復制鏈路〔FC、TCP/IP、ATM、E1/E3以及鏈路的QoS保障等。獲得這些數據后,通過對容災系統I/O分布的詳細設計,將I/O均勻分布到更多的設備上,從而確保生產系統實現容災后,不會造成性能下降影響正常生產的情況出現。選擇什么容災技術能保證項目實施成功？容災項目實施成功,與技術關系不大。能舉出成功案例的容災技術,則必有它的可行性。但作為一個工程師,除了考慮項目的可行性外,還要考慮項目的不可行性。任何技術的實現,都有它的制約條件。在自己的生產環境中,能否避免這些制約條件的出現？或者出現后,是否有資源可以解決它？比如ORACLE在中國實施了一個基于DataGuard的容災方案,但在實施過程中出現了大量意想不到的問題和BUG,作為對該特殊客戶的重視,ORACLE甚至從國外派遣R&D人員到現場編制PATCH以保證項目能實施,但這種資源,是否每個客戶都能向ORACLE索取？因此,選擇一個簡單的容災方案,并選擇一個曾經成功實施過該方案的工程團隊,才是確保容災項目實施成功的關鍵。容災項目的建設原則"平戰結合"變成本中心為利潤中心容災與其他任何保險策略一樣,當沒有災難出現時,我們根本無法意識到容災系統所起到的作用,無法回收容災系統建設所需的大量投資。但從系統安全性角度考慮,我們又必須為關鍵的業務支撐系統建設最有效的災難恢復解決方案。但是在大部分情況下,當未出現災難時,我們的容災端系統總是處于空閑狀態,花費大量投資買來的系統根本無法有效利用。這個問題一直困擾著用戶。因此,我們建議在容災系統建設中,需要考慮的第一個問題是如何保證容災端的系統可以得到充分利用,使容災端系統的數據實現共享,能夠利用容災系統提供的高性能主機資源、存儲資源為企業帶來更大的處理能力。因為對于容災系統而言還有一套整體的規劃,未來的統一容災系統對于數據的異地保護將起到非常關鍵的作用,將來的容災系統無論在數據的實時性上,還是安全可靠性性上都會非常完善,只不過在業務的接管方面無法滿足業務需求。因次本次建設容災系統目的是提供一個能夠快速接管的系統,能夠充分利用投資的方案。為此我們強烈建議采用雙active的結構,讓容災系統的數據庫也處于OPEN狀態,這樣實際上關鍵系統就擁有了第二數據中心,而不僅僅是一個災難備份系統,通過第二數據中心可以實現如下功能：核心業務的災備平臺通過數據同步建立的第二數據中心可以實現對業務關鍵數據的容災及保護,在不影響生產數據庫性能的同時為生產數據庫在本地或異地建立一份準實時鏡像,以保證在生產數據庫發生災難時可使用容災數據庫進行業務接管和數據恢復。業務負載分擔這里要求第二數據中心的數據必需處于實時可讀取狀態,數據庫必需處于OPEN狀態,實現系統業務模塊的重新部署。通過第二數據中心實現對核心系統的業務模塊進行負載分擔,將那些只對數據進行讀取操作的模塊都遷移到第二數據中心上來,主要包括：提供帳務和話單實時查詢；提供統計報表運行；提供經營分析數據抽取；提供其他系統的數據訪問接口；這樣作將達到兩個好處：提高數據訪問的效率,提高外圍系統部署的靈活性；提高核心系統的運行效率,提高核心系統運行的穩定和可靠性；容災技術的推薦"DSGRealSync"我們建議采用DSGRealSync軟件作為關鍵系統的數據備份方案。這個方案能夠很好的解決災備的難點：第一：網絡帶寬要求低：交易級復制軟件需要在網絡上傳輸的量為oracleredolog的1/3。一方面比oracleDG的帶寬要求低,當然更遠遠低于磁盤陣列復制所需要的帶寬。第二：可支持不同硬件環境之間的異構環境容災,使得關鍵系統的集中容災方案不僅能夠滿足多個IT系統的需求,同時更能滿足用戶IT系統的五花八門的硬件環境的需求。第三：容災數據庫更可靠：因為容災數據庫是OPEN狀態的,所以不會存在容災數據庫無法啟動的風險。同時這種方式可避免生產庫上出現壞塊等物理錯誤。第四：容災數據庫處于OPEN狀態,可在容災數據庫上進行查詢、統計報表等功能,實現業務負載分擔。DSG從2002年在中國成立以來,在RealSync這個數據庫復制產品的項目實施方面也經過了很長的一段路。DSG始終以"客戶需求為導向"的原則發展自己的產品,到目前為止,DSGRealSync產品已經在電信、政府、政券和企業采用,主要包括〔詳見方案后案例：DSG-RealSync數據同步復制容災產品應用案例電信行業廣西移動BOSS容災及查詢平臺建設系統；北京移動告警數據同步、備份及容災系統廣西電信數據災備中心應用XX電信BOSS數據復制應用XX電信計費系統數據復制應用XX網通支撐系統復制/查詢統計平臺項目XX聯通大客戶系統數據復制項目XX聯通業務支撐系統數據復制應用XX聯通計費系統容災項目XX聯通綜合營帳數據復制XX聯通BOSS系統數據復制/查詢平臺應用XX聯通數據復制/查詢平臺應用XX電信Oracle數據異構復制遷移項目XX電信支撐系統容災及備份應用XX電信支撐系統容災及備份應用XX電信支撐系統容災及備份應用……其他行業XX省地稅數據集中及容災系統；上海松江財政異地容災XX財政異地容災備份項目XX省交通廳征稽局征費系統"數據同步復制軟件"容災項目中國金融期貨交易所異地容災濟鋼Oracle-ERP數據同步復制項目XX神州通集團數據復制異地容災應用長江證券數據集中的容災應用華泰證券數據集中的容災應用國聯證券數據集中的容災應用民族證券數據集中的容災應用西南證券數據集中的容災應用XX證券數據集中的容災應用金通證券數據集中的容災應用中原證券數據集中的容災應用西南證券數據集中的容災應用XX證券異地容災項目銀河證券數據容災備份綜合管理應用西部證券數據容災備份一體化綜合管理應用…………DSG-SnapAssure高速備份產品應用案例電信行業中國電信總部結算中心備份系統中國聯通總部CRM備份系統中國電信全國九省結算中心備份系統〔XX、XX、廣西、XX、XX、新疆、XX、XX、XX北方電信九省結算系統備份〔XX、XX、XX、XX、XX、XX、XX、天津、XX信息產業部全國十省互連互通和網間結算備份系統〔含XX、XX、XX、XX、XX、XX、XX、XX、XX和XX信產廳XX移動BOSS系統異地備份系統XX移動BOSS系統集中備份XX移動BOSS災備系統新疆移動結算系統災備項目天津聯通固網計費備份系統XX聯通綜合結算備份系統；XX聯通全省數據庫集中備份XX聯通業務支撐系統集中備份XX聯通數據備份系統升級應用XX聯通業務支撐系統的集中備份XX聯通業務支撐系統的集中備份XX、XX、XX聯通支撐系統的集中備份新疆電信BSS/OSS系統備份項目XX電信數據集中備份系統XX電信業務支撐系統集中備份XX通信、XX通信計費系統備份項目……其他行業銀河證券全國數據中心集中備份系統XX社保數據備份項目廣西公安備份系統XX公安備份及查詢應用項目XX公安戶籍系統備份應用新疆電力數據備份系統XX電力數據備份系統江漢油田數據備份系統……DSGRealSync數據庫復制產品的特點DSGRealSync產品通過在邏輯級,通過傳輸和運行數據庫事務〔Transaction,來提供實時數據復制功能,支持對生產系統數據庫生成多個副本,用以作為災難備份、和信息系統優化部署應用。RealSync對ORACLE的日志進行監控,發現改變的塊及時對目標數據庫進行更新,當應用系統向數據庫中進行任何操作時時,這些信息都將在在線日志中存儲,RealSync通過對實時獲取的數據庫在線日志進行分析,獲得本次操作的交易指令和交易數據,然后將這些交易指令和交易數據經過格式轉化并實時壓縮后通過網絡傳送到目標系統。目標系統的RealSync代理接收數據庫包,經過校驗碼檢查,確認正確的數據庫包后,將包解壓進行格式轉化后按照交易的先后順序在容災系統中重新執行該交易。〔1Transaction-Based的復制機制：該產品的實現不是通過數據庫底層存儲復制、也不是將生產系統的Log復制到目標系統上重新應用的模式。而是在源系統上通過Log分析出系統的交易指令〔Transaction,然后將交易指令在目標端裝載的原理實現的。因此,目標端的數據庫必須處于Open狀態,并且兩端的操作系統、數據庫平臺等都可以屬于不同版本。〔2快速的TransactionLoad技術：基于主機的復制軟件最大的問題在于性能是否滿足大容量業務需求,如果復制軟件在采用標準的SQL語句進行復制的話,勢必要求目標系統與源系統具有相同的處理性能,從而導致投資成本大幅度上升。DSGRealSync獨創DXF〔DSGExtendFormat數據表達格式,通過應用該格式實現數據的傳輸和裝載能夠達到數據庫裝載速度的極限,滿足大容量應用系統的性能需求。該產品在支持作為災難備份時具有如下特點：異構的系統平臺,開放的硬件選擇：RealSync技術在邏輯級的數據復制技術,因此對于生產系統和容災系統來說,其硬件平臺可以屬于不同的廠商、不同的型號,可采用不同的操作系統等。零時間數據庫切換的熱容災：系統恢復時間是指當主系統出現故障不能在短期內恢復,而需要啟動容災端系統時,容災端系統啟動的時間。該時間不僅僅是指容災端的硬件系統啟動,更主要的、也是更耗費時間的是容災端數據庫系統的啟動、業務系統的啟動和外部接口的切換等。其中又以數據庫的啟動最為耗費時間,因為容災端數據庫不屬于正常下線,因此重起時需要作許多檢查和恢復,花費的時間非常長。RealSync維護的容災數據庫系統在數據復制過程中也始終處于打開狀態,保證數據復制在邏輯上的完整性,RealSync技術為源系統提供了永遠可用的后備數據庫系統。在源系統出現故障時,應用系統可實現實時訪問備用數據庫系統。達到數據庫系統的零切換目的。可靠的數據復制技術：RealSync維護的容災數據庫系統始終處于打開狀態,保證數據復制在邏輯上的完整性和可靠性,保證容災站點數據庫系統可用的系統。投資回報分析〔ROI：容災系統始終處于打開狀態,可提供數據抽取、報表系統、試驗系統等實現數據共享,為信息系統提供更多的可利用資源。支持從高到中低端應用需求：由于RealSync在建設容災系統時,對服務器、存儲陣列和傳輸帶寬要求都無特殊要求,而不同于傳統容災技術要求高端磁盤陣列、高端服務器、數GB的傳輸帶寬,所以該系統適應于高端的電信、金融客戶、也適合中端的政府機構、大型企業、同時也適合于運行PC平臺的中小型企業應用。該產品在支持作為系統優化部署應用時具有如下特點：按需復制查詢和統計系統往往不需要所有的原始數據,因此完全可以按需要復制數據。RealSync系統支持對指定信息的按需復制,如指定需要復制的表、字段和條件等,減少存儲和網絡帶寬的成本。實時數據更新實時更新保證副本系統快速反映源系統的變化,提供賬單查詢、話單查詢等的及時性。經過大量的測試,實時數據復制技術使源系統和目的系統的數據延遲<10秒。對生產系統的低干擾性DSG實時數據復制技術不需要通過任何數據庫的引擎來獲取變更數據,而是通過數據庫自身的信息獲取源系統上的改變并傳送給目的系統,不會對生產系統造成性能影響。系統異構,可提供更多的優化空間源數據庫系統和目的數據庫系統的可異構,主要包括索引規則和存儲參數〔如數據塊大小、回滾段等。因此可以在目標數據庫上根據業務特點進行調整和優化,完全不受源系統的限制。容災技術對比和分析容災產品概述在選擇容災系統的構造時,首先要考慮的就是選擇采用合理的異地數據復制技術。數據的遠程復制技術是容災系統的核心技術,它對于數據系統的一致性和可靠性以及系統的應變能力具有舉足輕重的作用,通過有效的數據復制,遠程的業務數據中心與本地的業務數據實現同步,確保一旦本地系統故障,遠程的容災中心迅速進行完整的接管。一般說,在容災系統方案的數據復制技術上存在兩種主流模式：第一種方式是基于智能存儲的數據鏡像技術。該技術是將數據復制通過磁盤陣列控制器在進行寫入操作的同時通過高速網絡向容災系統的陣列上發送相同的I/O指令來實現,因此該方案對主機的資源占用很小；穩定性好；同步性強。該技術主要由各存儲設備生產廠家所推薦,如EMC,IBM,HP等都提供了相應的解決方案。第二種方式是基于主機系統的數據復制,該方式是把數據定期、在線地復制到目的地的機器上去。這種方案大部分由存儲管理軟件廠家提供,尤其是VERITAS推出了一系列基于該方案的存儲管理軟件解決方案。實現這些功能的業界常用解決方案主要包括以下幾類：磁盤陣列復制技術：主要由一些磁盤陣列廠商提供,如EMCSRDF、IBMPPRC、HPBusinessCopy、HDSTrueCopy等；存儲卷復制技術：由一些卷管理軟件廠商提供,如VERITASVVR；數據庫復制技術：由數據庫廠商以及一些第三方廠商提供,如DSGRealSync/SmartE等；應用層復制技術：由各系統的應用廠商自己提供；DSGRealSync屬于數據庫復制技術。因此下面就該技術與其他幾類復制技術的優缺點作一個歸納：基于異地備份技術實現容災的分析基于數據備份方式,通過磁帶數據傳輸是最早使用的容災方式,盡管現在有很多新技術出現,該容災方式仍在使用。備份類廠商VeritasNetbackupLegatoNetworkerIBMTSMDSGSnapassure基于數據備份技術的容災使用此方式的優點是：成本較低,簡單可行容災端可以異構存儲如是文件系統應用,容災端可以異構主機平臺此方式的缺點是：實時性差,發生問題,數據丟失量大磁帶不可靠磁帶恢復慢,RTO長數據庫應用通常不能跨平臺。基于應用層容災技術的分析應用層復制技術DSGRealSync/SmartE適合對象：只適合那些在應用中提供了該技術的應用,而非常少。優點：與應用集成緊密,可按照應用的需求作調整。從理論上講能夠解決所有的應用需求缺點：非標準化：不同應用軟件的復制方式不同；開發和維護工作量大,任何應用的變動都可能導致復制技術的變動；應用不成熟、不普遍。無法實現大量應用案例之間的知識共享。適合對象：適合于構建在ORACLE系統上的所有應用系統和應用類型優點：無需二次開發；標準的工業化軟件,成熟度遠遠高于應用復制；專業廠商支持和維護；應用案例遠多于應用層復制技術；缺點：與應用的關系比較松散,無法完全按照應用需求定制基于磁盤陣列復制容災技術的分析采用基于存儲的容災方案的技術核心是利用存儲陣列自身的盤陣對盤陣的數據塊復制技術實現對生產數據的遠程拷貝,從而實現生產數據的災難保護。在主數據中心發生災難時,可以利用災備中心的數據在災備中心建立運營支撐環境,為業務繼續運營提供IT支持。同時,也可以利用災備中心的數據恢復主數據中心的業務系統,從而能夠讓企業的業務運營快速回復到災難發生前的正常運營狀態。采用基于存儲的數據復制技術建設容災系統是目前金融、電信采用較多的容災方案,有較多的應用案例。采用基于存儲數據復制技術建設容災方案的必要前提是：缺點通常必須采用同一廠家的存儲平臺,通常也必須是同一系列的存儲產品,給用戶的存儲平臺選擇帶來一定的限制。容災中心的主機平臺也需要和生產中心為相同類型。采用同步方式可能對生產系統性能產生影響,而且對通信鏈路要求較高,有距離限制,通常在近距離范圍內實現〔同城容災或園區容災方案采用異步方式與其他種類的異步容災方案一樣,存在數據丟失的風險,通常在遠距離通信鏈路帶寬有限的情況下實施。如果容災數據需要使用,可以為"目標數據"建立一個BCV卷,需要多投入一倍的存儲空間,即整個架構需要生產系統的4倍存儲容量才可支撐,且獲得的數據不是實時的,一般都是隔天。磁盤陣列復制技術DSGRealSync適合對象：主要適用于數據中心級的海量數據復制。用戶必需采用支持該功能的磁盤陣列型號,而這些陣列大都為高端陣列,投資昂貴。優點：支持陣列上的所有數據類型復制。可支持同步方式復制不占用主機CPU資源缺點：目標端數據不可用：目標端數據庫在復制過程中不能被打開,造成大量投資浪費；必需同構：源和目標必需要求相同的磁盤陣列、相同的操作系統、相同的數據庫版本；只能全庫復制：復制的對象是整個數據庫不能實現數據整合和數據分發；帶寬高：要求獨占的光纖網絡,動輒需要上GB的帶寬。適合對象：適合從工作組級、企業級到數據中心級的復制需求。無論系統采用什么樣的服務器平臺、什么樣的存儲平臺,只要是ORACLE系統之間的復制即可適用。優點：目標端數據可用：目標端數據庫在復制過程中出于可用狀態,可用作數據查詢、報表、數據抽取等任務分擔；異構系統復制：源端系統和目標端系統可以采用異構的操作系統平臺、存儲平臺；支持選擇性復制：支持只復制指定的user、指定的Table、指定的行和列。節省存儲空間,提高應用靈活性；支持1對多,多對1的復制結構：能夠將多個數據庫中的數據復制到一個數據庫中；能夠將一個數據庫中的不同數據分發到不同的數據庫中。節約帶寬和網絡資源：所需帶寬一般在幾Mbps,幾十Mbps。缺點：只支持ORACLE數據庫系統。只支持異步復制,不支持同步方式。只支持ORACLE系統中的DML復制和常用的DDL復制,對存儲的變化不復制。占用主機的CPU資源；基于存儲卷復制容災技術的分析采用基于主機系統的容災方式的核心是利用主、備中心主機系統通過IP網絡建立數據傳輸通道,通過主機數據管理軟件實現數據的遠程復制,當主數據中心的數據遭到破壞時,可以隨時從備份中心恢復應用或從備份中心恢復數據,從而給企業提供了應用系統容災的能力。實現遠程數據復制的數據管理軟件有很多產品,主機廠商和一些第三方軟件公司<如Veritas>提供基于主機的數據復制方案,如Sun公司的AvailabilitySuite軟件和VeritasVolumeReplicator<VVR>等軟件可實現基于主機的遠程數據復制,從而構建基于主機的容災系統。采用基于主機的數據復制技術建設容災方案有以下優點：基于主機的方案最主要的優點是只對服務器平臺和主機軟件有要求,完全不依賴于底層存儲平臺,生產數據中心和后備數據中心可以采用不同的存儲平臺；既有針對數據庫的容災保護方案,也有針對文件系統的容災保護方案。有很多不同的基于主機的方案,可以滿足用戶的不同數據保護要求,提供多種不同數據保護模式；基于IP網絡,沒有距離限制同時,采用主機的數據復制技術建設容災方案有以下缺點：基于主機的方案通常需要同種主機平臺；基于主機的數據復制方案由于生產主機既要處理生產請求,又要處理遠程數據復制,必須消耗生產主機的計算資源,因而對生產主機性能產生較大的影響,甚至是產生嚴重影響；災備中心的數據一般不可用,如果用戶需要在遠程數據中心使用生產數據給開發測試、DW/BI應用使用將非常困難；利用主機數據復制軟件的方案比較復雜,尤其是和數據庫應用結合的時候需要很復雜的機制或多種軟件的結合,從而對生產系統的穩定性、可靠性、性能帶來顯著影響；如果有多個系統、多種應用需要災難保護,采用基于主機的方案將無法有統一的技術方案來實現。管理復雜,需要大量的人工干預過程,容易發生錯誤。目前,企業采用基于主機的數據復制技術建設容災方案相對比較少,通常適合單一應用或系統在I/O規模不大的情況下局部使用。在應用I/O負載比較大,需要災難保護的應用及應用類型比較多的時候,基于主機方案將不適用。VeritasvvrDSGRealSync/SmartE適合對象：主要適用于工作組級的數據復制。因為對CPU資源占用高優點：支持存儲卷上的所有數據類型復制。可支持同步方式復制缺點：目標端數據不可用：目標端數據庫在復制過程中不能被打開,造成大量投資浪費；操作系統必需同構：源和目標必需要求相同的操作系統和相同的數據庫版本,但不要求相同的存儲設備只能全庫復制：復制的對象是整個數據庫不能實現數據整合和數據分發；帶寬高：傳輸數據量比DSGRealSync/SmartE高5倍以上。適合對象：適合從工作組級、企業級到數據中心級的復制需求。無論系統采用什么樣的服務器平臺、什么樣的存儲平臺,只要是ORACLE系統之間的復制即可適用。優點：目標端數據可用：目標端數據庫在復制過程中出于可用狀態,可用作數據查詢、報表、數據抽取等任務分擔；異構系統復制：源端系統和目標端系統可以采用異構的操作系統平臺、存儲平臺；支持選擇性復制：支持只復制指定的user、指定的Table、指定的行和列。節省存儲空間,提高應用靈活性；支持1對多,多對1的復制結構：能夠將多個數據庫中的數據復制到一個數據庫中；能夠將一個數據庫中的不同數據分發到不同的數據庫中。節約帶寬和網絡資源：所需帶寬一般在幾Mbps,幾十Mbps。缺點：只支持ORACLE數據庫系統。只支持異步復制,不支持同步方式。只支持ORACLE系統中的DML復制和常用的DDL復制,對存儲的變化不復制。占用主機的CPU資源；基于虛擬化存儲技術的分析存儲虛擬化的技術方法,是將系統中各種異構的存儲設備映射為一個單一的存儲資源,對用戶完全透明,達到屏蔽存儲設備的異構和主機的異構的目的。通過虛擬化技術,用戶可以利用已有的硬件資源,把SAN內部的各種異構的存儲資源統一成對用戶來說是單一視圖的存儲資源〔StoragePool,而且采用Striping、LUNMasking、Zoning等技術,用戶可以根據自己的需求對這個大的存儲池進行方便的分割、分配,保護了用戶的已有投資,減少了總體擁有成本〔TCO。另外也可以根據業務的需要,實現存儲池對服務器的動態而透明的增長與縮減。通過存儲虛擬化技術可實現數據的遠程復制,以確保容災中心與主站點的數據保持同步以實現數據容災。目前各存儲廠商分別有不同的存儲虛擬化技術<如EMCStorageRouter和RecoverPoint,IBMSanVolumeController,HDSTagmaStor存儲平臺提供的UniversalReplicator,SVM技術都是虛擬化技術>,利用各廠家的存儲虛擬化技術能夠實現異構存儲平臺之間的數據復制〔同步或異步方式。存儲虛擬化技術可以在不同層面實現,如在智能交換機層面、存儲層面或增加第三方設備來實現。采用虛擬存儲技術進行數據復制同樣也可以有同步復制方案和異步復制方案,需要根據具體的需求選擇合適的產品。采用虛擬存儲化技術建設容災方案有以下優點：主生產中心和容災中心的存儲陣列可以是不同廠家的產品,存儲平臺選擇不受現有存儲平臺廠商的廠商限制〔但主機必須是同種平臺。對不同廠家的存儲陣列提供統一的管理界面。在虛擬存儲環境下,無論后端物理存儲是什么設備,服務器及其應用系統看到的都是其熟悉的存儲設備的邏輯鏡像。即便物理存儲發生變化,這種邏輯鏡像也永遠不變,系統管理員不必再關心后端存儲,只需專注于管理存儲空間,所有的存儲管理操作,如系統升級、建立和分配虛擬磁盤、改變RAID級別、擴充存儲空間等比從前的任何產品都容易,存儲管理變得輕松簡單。采用虛擬存儲化技術建設容災方案需要考慮以下缺點：虛擬存儲技術比較新,雖然為異構環境設計,但在異構環境種保證兼容性和數據的完整性依然可能存在風險；采用虛擬存儲技術,尤其是增加第三方硬件的方式將需要評估對整個系統的高可用性和性能的影響。需要驗證選擇的產品和技術的成熟性以及和現有設備、未來設備的兼容性能力,尤其是需要在復雜環境、大規模容災要求重的實際適用情況。在當前階段,建議暫不在關鍵業務系統的容災上選擇虛擬化存儲技術,該技術還有待時間和實際應用的驗證,尚無法勝任核心、關鍵業務系統的容災保護。基于OracleDataGuard容災技術的分析OracleDataGuard技術是Oracle數據庫系統特有的災難備份和恢復技術,利用了Oracle數據庫系統的日志備份和恢復機制。DataGuard的基本原理是在與主系統完全一致的硬件和操作系統平臺上建立后備數據庫系統,同時對主數據庫的數據庫日志<Log>和控制文件等關鍵文件進行備份。在主系統正常工作的同時將主系統產生歸檔日志文件<ArchivedLog>不斷的傳送到后備數據庫系統,并且利用這些日志文件在后備數據庫系統上連續進行恢復<Recover>操作,以保持后備系統與運行系統的一致。當主系統發生故障時,使用備份的數據庫日志文件在后備數據庫上恢復主數據庫內的數據。圖表13采用OracleDataGuard的容災方案OracleDataGuard提供了三種模式：最大保護模式最大可用模式最大性能模式OracleDataGuard最大保護模式提供了對于主數據庫最高級別的數據可用度,是一種保證零數據丟失的容災解決方案。當運行最大保護模式時,Redo紀錄以同步的方式從主數據庫發送到后備數據庫,而且,在主數據庫方的事務,一定要等到至少有一個后備數據庫確認接收到事務數據,該事務才被提交。在這種模式下,一般配置至少兩個后備數據庫,以提供雙重容錯保護。如果后備數據庫不可用,則主數據庫方會自動掛起處理進程。最大可用性模式提供了對于主數據庫次高級別的數據可用度,保證零數據丟失,并對單個組件的失敗提供保護。與最大保護模式一樣,redo數據被同步地從主數據庫發送到后備數據庫。在主數據庫方的事務,一定要等到后備數據庫確認接收事務數據,該事務才被提交。然而,如果后備數據庫因為諸如網絡連接之類的問題而不可用時,主數據庫方的處理會繼續執行。這樣,會出現后備數據庫暫時與主數據庫不一致的情況,但是一旦后備數據庫恢復可用,數據庫會自動同步,不會有數據丟失。最大性能模式是缺省的保護模式。與最大可用性模式相比,它對于主數據庫提供稍弱一點的保護,但是性能更高。在這種模式下,當主數據庫對事務進行處理時,日志數據被以異步的方式傳送到后備數據庫。在主數據庫方,提交操作在完成寫的動作前、無需等待后備數據庫的接收確認。在任何時候,如果后備方不可用,主數據庫方的處理繼續執行,這樣對性能不會有什么影響。采用OracleDataGuard技術進行災難備份需要滿足以下前提條件：后備系統與主系統的硬件平臺、操作系統、操作系統版本等保持一致；后備系統與主系統上Oracle用戶的權限一致；后備系統與主系統的Oracle數據庫版本一致；后備系統與主系統的Oracle數據庫配置文件一致。采用OracleDataGuard建設容災方案有以下優點：完全通過Oracle數據庫機制來實現,完全不依賴于其它軟件和底層存儲平臺；可以滿足用戶的不同性能、數據保護要求,提供多種不同數據保護模式；可以實現一對多的數據復制,提供多重保護；后備數據庫可以在很短的時間內提升到生產狀態〔因為數據庫已經在運行基于IP網絡,沒有距離限制同時,采用OracleDataGuard建設容災方案有以下缺點：OracleDataGuard的三種模式都將對生產數據庫系統的性能產生影響,因而需要更多的處理資源；后備數據庫不可用,如果用戶需要在遠程數據中心使用生產數據給開發測試、DW/BI應用使用將非常困難。只能對Oracle數據庫數據提供保護,不能對其它應用數據—如文件應用等提供災難保護。管理復雜,需要大量的人工干預過程,容易發生錯誤。只能保護Oracle數據庫,無法保護其他應用數據。業界其它基于應用的容災方案的優點和局限性與OracleDataGuard模式基本相同。ORACLEDGDSGRealSync適合對象：主要適用于幾十GB的小型數據庫的容災使用。優點：Free可實現同步復制模式。缺點：目標端數據不可用：目標端數據庫在復制過程中處于RECOVER狀態,不能被用來使用；操作系統必需同構：源和目標必需要求相同的操作系統和相同的數據庫版本；只能全庫復制：復制的對象是整個數據庫不能實現數據整合和數據分發；性能低下,目前的應用案例多在幾十GB的小型數據庫上使用。重新同步一次非常復雜,需要通過備份恢復的方式來進行首次初始化,并且最好很死停止業務。logicalstandby模式的性能低下logicalstandby方式支持的數據類型有限,例如對longraw,rowid等數據類型不支持。適合對象：適合從工作組級、企業級到數據中心級的復制需求。無論系統采用什么樣的服務器平臺、什么樣的存儲平臺,只要是ORACLE系統之間的復制即可適用。優點：目標端數據可用：目標端數據庫在復制過程中出于可用狀態,可用作數據查詢、報表、數據抽取等任務分擔；異構系統復制：源端系統和目標端系統可以采用異構的操作系統平臺、存儲平臺；支持選擇性復制：支持只復制指定的user、指定的Table、指定的行和列。節省存儲空間,提高應用靈活性；支持1對多,多對1的復制結構：能夠將多個數據庫中的數據復制到一個數據庫中；能夠將一個數據庫中的不同數據分發到不同的數據庫中。節約帶寬和網絡資源：所需帶寬一般在幾Mbps,幾十Mbps。性能高于ORACLEDG,DSGRealSync軟件已經應用于廣西移動的營帳系統的環境,數據容量達到2TB,每天產生的日志量最大能夠處理到600GB/天缺點：需要單獨購買只支持異步復制,不支持同步方式。DSGRealsync容災技術的分析DSG是全球領先的數據與存儲管理軟件提供商,提供優秀的數據管理軟件和數據備份、災難恢復、數據抽取共享、數據歸檔檢索和一體化管理平臺在內的解決方案。DSG公司擁有對Oracle數據庫復制的核心技術掌握,其推出的復制產品家族RealSync是通過對OracleLog日志進行分析獲取跟蹤源系統的交易指令。該軟件成功應用在長江證券、華泰證券、國聯證券、金通證券、民族證券、銀河證券、XX地稅、XX電信、XX聯通、XX聯通、XX聯通、XX聯通、XX聯通、XX聯通、廣西移動、XX網通、上海松江財政、XX鋼鐵集團公司…等單位的關鍵業務系統上該軟件在生產系統上的每個oracle系統和dc系統上安裝一個agent,該agent通過對oraclelog的分析抽取實時增量數據,并將這些增量數據傳送到災備中心上。災備中心的每個服務器上也需要安裝agent,用于接收從生產中心傳輸來的交易指令,并將這些交易指令裝載到災備中心的數據庫上復制系統包括兩個部分組成：－DS:DataSource端,即源系統端；－DT：DataTarget端,即目標系統端。〔1源端和目標端各安裝一套DSG的realsync軟件,只要進行一些簡單的配置就可以完成從首次初始化到實時增量同步的整個過程,并且實現無需停掉生產系統業務而完成整個實時數據復制容災功能。〔2DSGReal實時分析oracle的OnlineRedoLog生成壓縮的xf1文件自動發送到目標端等待裝載。〔3通過的定制filter功能,來根據用戶需要不復制一些危險的DDL操作比如droptabletruncatetable。〔4目標系統收到xf1指令后保存到目標系統的緩存隊列,由于RealSync只分析onlineredolog中的有用信息,所以一般需要傳輸的xf1文件只是oracleredolog的1/5,這樣大大降低了網絡的負載,從而更好的減少了數據延遲。〔5目標系統的loader進程從本地隊列中讀取數據裝載到目標端oracle系統上,裝載過程中通過DSG獨有Rowmapping技術進行數據一致性的檢測,從而部分保證生產端和容災端數據的一致性。〔6整個延遲在OracleRAC模式下正常情況下為3－5秒中,最長延遲不超過10秒,即RPO<10。〔7目標端數據庫處于實時打開狀態,如果源端出現災難,整個RTO時間只是應用準備的時間。而且在沒有接管生產系統業務的情況下容災端數據庫不僅可以用來容災還可以用來將OLTP應用、報表和查詢應用分離；提高每個系統效率,降低資源爭用和消耗,從而更有效的利用現有設備。〔8整個分析、傳輸、裝載過程全程監控,如果出現錯誤及時提示用戶,方便用戶及時發現問題解決問題。正因為該技術原因,DSGRealsync在滿足容災系統的過程中具有如下幾個優勢：異構環境支持RealSync技術是邏輯級的數據復制技術,因此對于生產系統和容災系統來說,其硬件平臺可以屬于不同的廠商、不同的型號,可采用不同的操作系統等。它的優點在于：一方面為用戶提供容災系統建設時,硬件平臺的可靈活選擇空間；同時提供了在同一容災解決方案架構下,實現企業不同平臺上的多個信息系統的統一容災支持。容災數據庫處于OPEN狀態,提供及時、可靠的容災切換RealSync維護的容災數據庫在數據復制過程中始終處于打開狀態,為保證災難切換的時效性和可靠性：打開的備份數據庫保證數據復制在邏輯上的完整性,為源系統提供了永遠可用的后備數據庫系統,確保容災系統的可靠性。當源系統出現故障時,應用系統可實現實時訪問備用數據庫系統,無需重新啟動備用數據庫,達到數據庫的秒級切換目的。容災數據庫可提供實時數據共享,支持企業應用負載分擔和投資回收采用RealSync容災技術,容災數據庫始終處于打開狀態,不同于其他模式下容災數據庫系統不可用的狀態。因此,可以通過RealSync維護的容災系統,提供數據共享服務：為決策分析和報表系統提供快速的數據抽取功能提供準實時脫機查詢,提高查詢效率為試驗系統提供真實的生產數據將以上本來需要在主系統上運行的業務與生產系統完全隔離,充分利用容災系統的資源,實現企業應用負載分擔,減少對生產系統的影響,提高服務系統響應效率；從而將容災系統這個成本中心轉化為利潤中心。靈活的組網結構和低帶寬資源需求RealSync采用交易〔Transaction傳輸方式,極大的減少了復制過程中需要傳輸的數據量。使得在網絡上傳輸的數據量大大減少,要求更低的網絡帶寬。Realsync支持標準的TCP/IP網絡傳輸,用戶可靈活布建容災網絡架構。系統可支持1:1、N:1、1:N和雙向容災結構支持,提高企業容災結構的靈活性。整體方案設計方案設計<案例：西部證券>需求分析西北某證券集中交易系統在2005年實現交易集中并升級到Unix+Oracle平臺,系統穩定運行。2006年以來,隨著中國股市轉牛,交易活躍,系統所承受的壓力越來越大。一旦集中交易系統出現故障,將導致嚴重的后果。因此,西北某證券考慮升級以往的應用級容災系統,采用專業的災備軟件對集中交易系統進行完善的保護,包括:實現災、備一體化的數據保護對集中交易系統實現災、備一體化保護,即在出現地震、火災、存儲故障、大面積電力中斷、網絡中斷等情況下使用容災系統實現業務快速接管；在出現諸如表數據丟失、數據邏輯錯誤、軟件BUG等情況下可以通過備份系統快速在線修復系統。同時整合兩種災備模式,做到全方位保護。實現本、異地結合,查詢、容災結合的數據同步在中心機房和異地機房之間各保留一份同步數據。中心機房的同步數據用于歷史查詢、數據分析等,作為"溫備"數據。異地同步數據用于容災切換,作為"災備"數據。強調應急處理及演習體制的建設,實現災備制度保證在關鍵時刻容災切換是否能夠成功,不但取決于災備軟件,而且和平時的災備演練、系統維護以及應急體制息息相關。因此,西北某證券要求災備系統的建設同時應建設應急處理制度、演習制度并形成規范文檔和應急指導手冊,切實提高容災系統的應用效果。DSG災備一體化產品線DSG公司針對業界的數據保護需求,推出了兩類數據保護產品：實時備份<realsync>和定時備份<snapAssure>。實時備份產品<realsync>：該產品是通過交易實時同步的方式實現數據備份。其目的是保護證券系統的業務連續性,當生產系統出現因為硬件故障、數據庫故障、以及環境故障等而不能正常提供服務時,可在備份系統上快速接管。確保業務的連續性。定時備份產品<snapassure>：該產品是每天進行一次數據備份〔日常作歸檔日志的備份。其目的是保護證券系統的數據安全性。當生產系統出現因為人為誤操作,應用程序錯誤、或者其他故障導致數據丟失時,可從備份系統上找回這些數據。而且可以找回一段時間以前的數據。Snapassure與Realsync的關系snapassure與realsync都是將生產系統的數據備份到備份系統上來,表面上看二者都是實現數據的備份和恢復,但在實質上二者有著本質的差別,主要差別在于：realsync目的在于保證系統的可用性：當生產系統發生故障時,可在短時間內〔分鐘級通過備份系統對外提供業務服務,以使交易不致停頓。snapassure的目的在于對數據的保護：當生產系統發生數據損壞時,可以通過備份系統上的數據進行恢復。備份數系統上保存了多個備份時間點的多個版本,當生產系統的數據被破壞時,可通過備份系統的數據將系統回溯到錯誤發生之前的時刻。該技術能夠應付交易數據庫中的邏輯錯誤〔比如誤刪除表,表記錄改錯了等。所以,雖然我們可以采用realsync軟件來達到實時備份的目的,當生產系統不能對外提供業務的時候,能夠在備份系統上快速的接管業務。但是snapassure仍然是不可替代的：realsync無法解決生產系統的帶病運行情況：例如realsync無法避免truncatetable,droptable以及錯誤導入數據等邏輯錯誤,realsync無法識別這些錯誤是正常操作還是錯誤操作,當生產系統的數據被破壞后,備份系統上的數據也是被破壞的。snapassure卻能夠避免這些數據的錯誤,保護數據不被破壞。當生產數據被破壞時,我們可以通過snapassure系統的多個時間點的備份數據來將系統回溯到發生錯誤之前的狀態。因此,業界都將realsync和snapassure兩種技術配合使用,以達到系統保護和數據保護的雙重目的。在證券集中交易系統中,已經有幾個證券公司采用snapassure和realsync并存的方式來達到最佳的保護效果。因此我們建議在條件允許的情況下,盡量能采用兩種技術相結合的數據保護方式。容災技術的推薦我們建議采用DSGRealSync軟件作為關鍵系統的數據備份方案。這個方案能夠很好的解決災備的難點：第一：網絡帶寬要求低：交易級復制軟件需要在網絡上傳輸的量為oracleredolog的1/3。一方面比oracleDG的帶寬要求低,當然更遠遠低于磁盤陣列復制所需要的帶寬。第二：可支持不同硬件環境之間的異構環境容災,使得關鍵系統的集中容災方案不僅能夠滿足多個IT系統的需求,同時更能滿足用戶IT系統的五花八門的硬件環境的需求。第三：容災數據庫更可靠：因為容災數據庫是OPEN狀態的,所以不會存在容災數據庫無法啟動的風險。同時這種方式可避免生產庫上出現壞塊等物理錯誤。第四：容災數據庫處于OPEN狀態,可在容災數據庫上進行查詢、統計報表等功能,實現業務負載分擔。系統結構目前集中交易系統由兩臺UNIX服務器組成OracleRAC結構。數據量為200GB左右,每天產生的ArchiveLog量約在30G左右。DSG公司針對證券業界的數據保護需求,推出了兩類數據保護產品：容災產品<RealSync>和備份產品<SnapAssure>。容災產品<RealSync>：該產品是通過交易實時同步的方式實現數據備份,其目的是保護證券系統的業務連續性。當生產系統出現硬件故障、數據庫故障、以及環境故障等而不能正常提供服務時,可在備份系統上快速接管,以確保業務的連續性。備份產品<SnapAssure>：該產品是每天進行一次數據備份〔日常作歸檔日志的備份,其目的是保護證券系統的數據安全性。當生產系統出現因人為誤操作、應用程序錯誤、或者其他故障導致數據丟失時,可從備份系統上找回這些數據,而且可以找回一段時間以前的數據。在西部證券公司,實現了SnapAssure+RealSync的一體化系統保護架構：實時復制軟件realsync配置為了實現該本地和異地的實時備份架構,我們采用DSGRealSync用于數據復制軟件。該軟件在集中交易的一個服務器上安裝兩個realsyncagent:一個realsyncagent用于用于同步到本地的服務器上；另一個realsyncagent同步到遠程的備份服務器上。在本地實時備份服務器上安裝一個realsyncagent；同時在異地備份服務器上安裝一個realsyncagent。定時備份軟件snapassure配置為了實現該本地定時備份功能,我們采用DSGsnapassure用于數據復制軟件。該軟件在集中交易的一個服務器上安裝snapassureagent。在本地的pc服務器上安裝snapassureserver；snapassureagent每天將備份的數據傳給給server,經過壓縮后保存到本地備份磁盤陣列上。功能實現采用DSGSnapAssure＋RealSync災備一體化的模式,系統建設了本地備份系統、本地容災查詢平臺系統和異地容災系統三個部分。本地容災查詢平臺系統采用DSGRealSync實時復制技術將交易系統的數據實時同步到本地容災系統上。本地服務器上的數據延遲一般可控制在3秒左右。本地容災系統用于集中交易系統因為硬件的問題,例如：服務器無法啟動、磁盤陣列無法啟動、數據庫的性能問題、或者數據庫無法啟動時,快速接管集中交易業務。同時由于本地容災系統的數據庫處于OPEN狀態,所以證券公司也將歷史數據的查詢遷移到本地容災系統上來做。本地備份系統：本地備份系統采用DSGSnapAssure產品將集中交易的數據備份過來,形成2周的備份版本。通過這些備份版本,可以將數據恢復到14天內的任意一個時間點。該系統主要用于防范人為誤操作造成的數據破壞,比如TruncateTable、DropTable等造成的數據破壞,尤其是歷史數據的破壞,這時需要利用本地備份系統來恢復丟失的數據。異地容災系統采用DSGRealSync實時復制技術將交易系統的數據實時同步到異地容災系統上。網絡帶寬為2Mbps。異地容災系統用于本地發生電力故障、網絡故障、火災、地震以及其他環境故障時,業務可以在短期內快速接管至異地的容災系統上,以確保業務不間斷。性能和資源需求估算在關鍵業務系統中的應用,性能和壓力是復制軟件的核心,是每天每時每刻都用到的,尤其是在業務高峰期情況下,能否跟得上日志的產生速度、能否不大量的占用系統資源、能否保證復制的及時性是整個數據庫復制軟件產品最為核心的內容。根據我們在各種國內的幾十家應用情況顯示來看DSGRealSync在實時復制方面的性能是同類產品中領先的。主要體現在：網絡需求RealSync對數據傳輸采用TCP/IP網絡傳輸。RealSync復制操作只是讀取操作系統的日志文件,同時通過TCP/IP方式而不是采用中間件方式傳輸只發生改變的數據也使網絡負載降至最低。RealSync只將日志的三分之一的內容通過網絡進行傳輸。實際每小時傳輸的數據量=每小時日志文件切換的數量*日志文件的大小*1/3.日志分析速度我們采取了積壓日志分析的方式進行測試,利用rac環境下的兩臺服務器同時產生10GB的日志數據,然后啟動realsync測試其在多長時間內能夠分析完這些數據。測試結果表名,在rac模式下,由兩個數據庫節點同時工作,在5分鐘內產生的10GB歸檔日志,共計800萬條記錄,realsync只需要2分鐘40秒即能分析完累積的日志,約9分鐘裝載完成。日志分析的速度遠遠高于產生日志的速度。完全能夠滿足用戶IT系統的業務需求,即使是在業務高峰期,也不會造成日志累積。每秒鐘復制的操作數在測試過程中,我們采用PL/SQL方式在源端產生1萬,10萬,100萬條記錄,以及進行1萬,10萬,100萬的update,delete操作等。按照統計結果,DSGRealSync達到平均18000條/s的復制速度。完全能夠滿足單系統上用戶IT系統的業務要求。復制數據延遲RealSync是一種異步準實時的復制技術,其數據延遲非常小。數據延遲的周期可以設置,在生產系統中,數據延遲和源系統復制事物的多少,事物的處理方式有關,以及跟設置的log數據輪詢周期有關。在復制數據量正常的OLTP系統中,數據延遲一般在幾秒鐘。如果每天產生30GB的日志量,在155Mb帶寬的情況下,可確保數據的延遲在5秒鐘左右。CPU資源占用DSGRealSync通過Oracle日志獲得數據的變化信息,它獨特的技術優勢使得它對源系統的資源占用很小。在生產系統中,實際對源系統的影響和源系統復制事物的多少,事物的處理方式有關。在復制數據量正常的OLTP系統中,正常狀態下對CPU資源的占用為<5%的CPU資源占用。根據我們在XX地稅的使用情況來看,在XX地市征管高峰期每2分鐘產生100MB的日志量,而REALSYNC的日志分析資源占用僅為2%〔4cpu,8Gram。源端的緩存空間當容災中心暫停或傳輸異常中斷導致復制停止時,RealSync會將數據庫的變化內容存儲在源系統或目標系統的隊列中,當系統恢復后,RealSync會自動識別復制環境,自動從斷點處開始復制工作。在上述過程中,主中心的業務不受任何影響。數據的一致性不會破壞。當復制環境停止的情況下,需要在源系統和目標系統上存儲的空間和業務系統每天峰值的日志數有關。根據每天平均產生25GB的日志計算,我們建議在源端給REALSYNC預留的緩存空間能夠滿足一天的緩存量：按照1/3的比例計算并增加一定的富裕量,需予留10GB的緩存存儲空間。業務切換RealSync是通過對OracleLog日志進行分析獲取跟蹤源系統的交易指令實時的將指令傳輸到目標端進行加載,且目標端數據庫始終在OPEN狀態,可實時在目標端進行查詢和統計,所以當災難發生時或在主機源端發生故障以后,可直接將生產端數據庫切換到容災端,目標端數據庫不需要重新啟動,確保目標端數據的可用性,并大大提高了RTO、RPO指標。RTO,RPO指標規劃采用交易級數據實時