總部 ERP 開發(fā)和測試服務器性能指標需求：

– SAP 開發(fā)服務器：SAPS>=6000 ，硬盤>=235GB

– SAP 測試服務器：SAPS>=6000 ，硬盤 >= 335GB

第2章 技術方案建議

2.1 SAP 系統(tǒng)架構

SAP 系統(tǒng)是三層架構，分為前端客戶、中間層應用及后端數(shù)據庫，中間層應用及后端數(shù)據庫是通過預先定義的 SAP API 及 DBMS SQL。從服務器來看，有些用戶將中間應用層及后端數(shù)據庫層放在同一個物理服務器平臺上;但大多數(shù)用戶還是選擇將數(shù)據庫和 SAP 應用運行在不同的物理服務器上，這樣 SAP 系統(tǒng)運行的效率更高，而且可靠性更好。

SAP 系統(tǒng)架構如下圖：

該系統(tǒng)設計通過將 SAP 應用及數(shù)據庫運行在不同的物理服務器上，為 SAP 實施提供了卓越的性能及良好的可擴展性。SAP 應用可以運行在多臺 IBM p 系列小型機服務器上，理論上可以為 SAP 應用系統(tǒng)在縱向(即交易量)及橫向(及交易種類)提供無限制的擴展。數(shù)據庫服務器運行在 IBM p 系列小型機服務器上可以獲得對數(shù)據操作的很好的性能。這兩臺服務器處于同一個局域網網段內，并且組成雙機集群進行相互備份。前端運行在用戶桌面的 SAP 應用僅能看見運行在中間層的 SAP 應用服務器，而不能看見后端的數(shù)據庫服務器，這樣可以避免客戶端直接訪問數(shù)據庫。

這種設計的主要特點體現(xiàn)在：

系統(tǒng)的高性能

平臺的高可靠性(IBM的硬件平臺和操作系統(tǒng))

低成本高效率(SAP應用和數(shù)據庫運行在不同的物理服務器上,相互之間進行熱備份)

開放平臺

UNIX 是流行的操作系統(tǒng)之一，掌握的人相對較多，而且易于學習。目前實施的 ERP 系統(tǒng)，建議選用 IBM p 系列服務器作為核心的數(shù)據庫和應用平臺，即可以利用 IT 開發(fā)和維護人員對 UNIX 操作系統(tǒng)的技能，同時又可以滿足對于系統(tǒng)高性能、高可用性及高擴展性的要求，支持大規(guī)模用戶和工作負載的要求，消除今后發(fā)展的瓶頸。

系統(tǒng)容量的估算 — SAP 系統(tǒng) Sizing 的原理

Sizing 指對 SAP 系統(tǒng)硬件設備配置的預估(主要包括內存 Memory、處理器 CPU 和存儲器Disk)。SAP 與其合作伙伴共同開發(fā)了在線的評估工具”Quick Sizer”來幫助用戶完成配置預估工作。在相應的 Internet 站點上，SAP 向客戶詢問一系列相關信息(包括人員信息及業(yè)務信息)，”Quick Sizer”根據這些信息通過一定的算法，估算出所需的配置。”Quick Sizer”所用的算法是根據 SAP 公司及其合作伙伴的標準測試以及客戶使用反饋的經驗數(shù)據共同制定的。”Quick Sizer”的結果并非精確數(shù)值，它只是建議一系列系統(tǒng)負荷的相對參數(shù)作參考，根據這些負荷參數(shù)可以對某確定硬件型號的配置進行規(guī)劃。”Quick Sizer”不對硬件供應廠商或平臺作評價，具體的選擇由用戶和硬件供應商共同決定。SAP 系統(tǒng)硬件設備配置的確定最終還是要根據實施顧問的經驗，參考業(yè)界已有的成功實例并與專業(yè)硬件工程師共同來完成。

“Quick Sizer”定義了兩類評估模型：基于用戶的預估、基于業(yè)務量的預估。

基于用戶的預估通過了解每個業(yè)務模塊的并發(fā)用戶數(shù)量來估計系統(tǒng)的負荷。所需的輸入信息為實際生產系統(tǒng)中各業(yè)務模塊將同時登錄的用戶數(shù)量。內存(MEMORY)大小的預估只能通過這種方法進行。由于并非所有用戶都同等頻度地使用系統(tǒng)，基于用戶的預估把用戶分成三種：低、中、高，一般每小時在系統(tǒng)上處理的會話數(shù)(一次屏幕的切換為一個會話)在 10 個以內的為”低”用戶，在 120 左右的為”中”用戶，在 360 左右的為 “高”用戶。

基于業(yè)務量的預估基于系統(tǒng)所處理的各種對象的實際數(shù)量作評估。這種方法用來預估處理器(CPU)及存儲空間(DISK)。存儲空間的大小可以通過估計 SAP 數(shù)據庫表將如何因各種業(yè)務對象的創(chuàng)建而增長，處理器(CPU)的需求通過估計業(yè)務對象創(chuàng)建過程中會話事務或批處理事務執(zhí)行所需的時間而實現(xiàn)。內存(MEMORY)的預估不能通過這種方法實現(xiàn)。這種方法所需的輸入信息為每年系統(tǒng)各業(yè)務模塊中將處理的業(yè)務對象及子對象總量等。具體包括：每年創(chuàng)建的對象數(shù)量(如各種憑證、單據等)、各對象所含的子對象數(shù)量(如一張憑證的細目條數(shù)等)、對象在系統(tǒng)中需保存的月份數(shù)量、業(yè)務高峰時節(jié)及其間對象創(chuàng)建的頻率，等等。

在全球已實施的眾多 SAP 項目中，”三系統(tǒng)藍圖結構”使用最為廣泛，業(yè)已成為默認的標準。這樣的整體架構中必須至少包含三套 SAP 系統(tǒng)：生產系統(tǒng)、開發(fā)系統(tǒng)、測試系統(tǒng)。它們的作用分別如下：

生產系統(tǒng)(Production System)– 企業(yè)日常運轉實際使用的系統(tǒng)，其中存有企業(yè)的完整業(yè)務數(shù)據，生產系統(tǒng)中不允許直接做客戶化或開發(fā);

開發(fā)系統(tǒng) (Development System)– SAP 項目的實施系統(tǒng)，各種業(yè)務模塊的客戶化工作、相關的應用開發(fā)等在該系統(tǒng)中進行;

測試系統(tǒng)(Testing System)–為各種客戶化和開發(fā)工作提供完整測試的系統(tǒng)，其中存有企業(yè)實際業(yè)務數(shù)據，用以驗證客戶化和開發(fā)的正確性。

實施企業(yè)小型機和磁盤陣列的選型

根據實施企業(yè)的技術需求，以及 IBM p 系列小型機服務器的 SAPS 值，我們可以確定滿足某石化公司 2003 年 ERP 實施企業(yè)的技術需求的 IBM p 系列小型機服務器的型號和主要配置。

2.1.1 生產系統(tǒng)

考慮到技術需求中有關生產系統(tǒng)可靠性的要求，即組成集群系統(tǒng)的節(jié)點沒有單點故障，并保證生產系統(tǒng) 7×24 的有效性，在工作時間系統(tǒng)運行正常率應達到 99%，全年總體運行正常率應達到 99.5%，我們建議將數(shù)據庫和 SAP 應用運行在不同的物理服務器上，這樣 SAP 系統(tǒng)運行的效率更高，而且可靠性更好，全年總體系統(tǒng)運行正常率可達 99.99%。

邏輯連接圖示如下：

根據上圖，我們可以將服務器的選型方案及其擴展性能列表所示(考慮到集群中的數(shù)據庫服務器和應用服務器相互備份的切換因素，我們建議應用服務器應與數(shù)據庫服務器配置相同)：

同時，隨著業(yè)務的發(fā)展和用戶數(shù)的增加，現(xiàn)有配置的系統(tǒng)還將面臨升級和擴容的要求，以滿足對系統(tǒng)處理能力的要求。在目前為石化 SAP 系統(tǒng)所配置的服務器中，均留有一定的擴展余地(滿配后 SAPS 值大于現(xiàn)有 SAPS 值的 150%)。

2.1.2 存儲系統(tǒng)

對于雙機集群系統(tǒng)，外置磁盤陣列是必須的，這里我們建議使用 IBM 的機架式安裝的磁盤陣列產品——IBM FAStT 系列，同時配備 2 臺 SAN 光纖交換機，它與服務器之間通過 SAN 光纖方式連接，傳輸速率高達 400MB/s?；?SAN 構架，不但可以提高雙機系統(tǒng)的安全性，還可以十分方便的完成對存儲空間與主機連接的擴展，實現(xiàn)未來集中的存儲平臺的構建。

說明：1 個磁盤陣列(IBM FAStT600)目前配置了 8 到 14 個 146GB 磁盤，一個磁盤柜最多支持 14 個磁盤，一個 IBM FAStT600 最多可管理兩個擴展磁盤柜，則最大可擴展磁盤數(shù)為 42個。如果 1 套 IBM FAStT600 配滿了，可以通過升級控制器的方式增加擴展能力，當升級到IBM FAStT700 或 900 時，最多支持 224 個磁盤，還可以通過 SAN 光纖交換機進一步增加 IBM FAStT 系列存儲設備達到擴展存儲空間的目的，用戶可以根據需要很靈活地進行擴展。

2.1.3 總部開發(fā)和測試系統(tǒng)

對于開發(fā)和測試系統(tǒng)，比較生產系統(tǒng)而言，其可靠性的要求相對較低。所以，我們建議在1 臺 IBM p670 服務器上建立 2 個邏輯分區(qū)，相當于 2 臺獨立的機器，分別作為開發(fā)和測試服務器，而每一個邏輯分區(qū)的性能完全滿足某石化公司對于開發(fā)和測試系統(tǒng)的技術需求。

針對這樣的方案，我們可以充分利用 IBM 的動態(tài)邏輯分區(qū)(DLPAR)的功能，隨著 SAP開發(fā)和測試工作的負載的變化，在開發(fā)及測試服務器之間隨意地、動態(tài)地調整系統(tǒng)的資源;而系統(tǒng)資源調整的最小顆粒度可分別達到 CPU=1，內存=256MB，I/O 槽位=1。這種動態(tài)調整系統(tǒng)資源的方式，以及精細的調整顆粒讀非常適合于開發(fā)及測試系統(tǒng)。

另外，我們認為，沒有必要采用雙機備份來提高開發(fā)和測試系統(tǒng)的可靠性，因此，測試和開發(fā)系統(tǒng)的數(shù)據庫服務器和 SAP 應用服務器運行在同一個邏輯分區(qū)上，采用 SAP 兩層結構。

各實施企業(yè)的生產系統(tǒng)都配置了外置光纖磁盤陣列(IBM 的磁盤陣列產品 — IBM FAStT600);由于測試和開發(fā)系統(tǒng)是單機系統(tǒng)，因此我們建議測試和開發(fā)系統(tǒng)的服務器使用IBM FAStT600 提供的存儲空間，同時，配置一臺 IBM 的 3583-L18 磁帶庫，同時利用數(shù)據庫服務器，作為 TSM 數(shù)據備份管理服務器，用于備份開發(fā)和測試服務器的數(shù)據。

2.1.4 系統(tǒng)配置

根據以上分析，我們對 SAP 系統(tǒng)服務器的配置描述如下：

從以上明細配置中可以看出，生產系統(tǒng)都按照集群系統(tǒng)要求配備了相關選件，包括硬件和軟件(HACMP)，而且集群系統(tǒng)中的服務器的 SAPS 值完全滿足某石化的 SAP 技術需求。

在該配置的操作系統(tǒng)存儲中，系統(tǒng)盤均配置了 3 塊，可以實現(xiàn)操作系統(tǒng)鏡像;內置硬盤的交換(SWAP)區(qū)容量不小于 20G;另外，主機到外接存儲陣列采用 SAN 結構，使用光纖 I/O通道(2G FC，存儲傳輸速率為 200MB/s)，而且該光纖 I/O 通道是冗余的;再有，服務器的網卡滿足高可靠性集群的需求，其帶寬可達到 1000M，并具有 100M 的兼容能力。

在該系統(tǒng)方案下，如果考慮系統(tǒng)升級，服務器的 CPU 和內存增加的最小單位可以列表如下：

對于操作系統(tǒng)，以上所有服務器均使用統(tǒng)一的 AIX5L 的 5.2 版本，該版本支持動態(tài)邏輯分區(qū)功能，有很好的可靠性、安全性和 LINUX 的兼容性;同時，針對某石化公司 2003 年 ERP 實施系統(tǒng)來說，AIX 對以下軟件的支持已經通過了技術認證(SAP Note Number: 502513 Availability of AIX 5L 64-bit with Oracle database)：

ORACLE9i 9.2 (64bit)

SAP 64bit Kernel(R/3 4.6C SR2)

2.2 總部現(xiàn)有設備利用

總部現(xiàn)有可共用的存儲資源為 IBM ESS800，并安裝了 2 臺 SAN 交換機，ESS 安裝完畢的可用容量為 1.2TB(210GB*6)，已使用的 SAN 端口數(shù)為 13 個(合計 16 個端口)，以分配容量為 500GB，可用容量為 700GB。備份設備方面，總部現(xiàn)有 SUN L9 磁帶庫(LTO G1 單驅動器)，與 IBM LTO3583-L36 磁帶庫(LTO G1 雙驅動器)，目前為 10 個不同的應用數(shù)據庫進行備份。

由于 IBM ESS-M800 存儲設備上運行的核心應用數(shù)據已達 500GB，考慮到數(shù)據的安全性與可靠性因素(可能的誤操作)，建議總部開發(fā)預測式系統(tǒng)與核心數(shù)據分開，應用 IBM FAStT600 進行開發(fā)與測試應用。

對于分支機構數(shù)據，可利用已有 IBM ESS-M800 存儲設備提供磁盤空間(需擴容 2 組 FC盤包，有效容量可達700+432=1132GB，并增加存儲設備 2 路光纖連接通道與 2 個 8 口 SAN 光纖交換機)，SUN L9 磁帶機或 IBM LTO3583-L36 磁帶庫(已為 10 個不同的應用數(shù)據庫進行備份，備份窗口已滿，需增加 2 個驅動器，以滿足額外的備份需要)進行數(shù)據備份。

本方案優(yōu)勢：提高磁盤系統(tǒng)性能，充分利用現(xiàn)有資源，同時也可為未來數(shù)據集中工作做準備。

2.3 備份需求

為了保證 SAP 系統(tǒng)的穩(wěn)定運行，我們提供相應的磁帶庫備份方案：

– 在總部的開發(fā)、測試環(huán)境，配置一臺IBM的3583-L18磁帶庫，同時利用數(shù)據庫服務器，作為TSM數(shù)據備份管理服務器，用于備份開發(fā)和測試服務器的數(shù)據。

– 在各實施企業(yè)，配置一臺IBM的3583-L18磁帶庫，同時利用數(shù) 據庫服務器，作為TSM數(shù)據備份管理服務器，用于備份ERP數(shù)據庫服務器數(shù)據。

3583-L18 磁帶庫滿足以下需求：

生產系統(tǒng)通過磁帶庫每天進行高速的在線備份，速率保證在2小時內完成容量100-150GB的數(shù)據備份(IBM LTO3583-L18使用LTO Ultrium 2 FC光纖磁帶驅動器，最大未壓縮傳輸速度為35MB/s, 理論上2小時可完成： 2*3600*35MB=252GB的數(shù)據備份 );

支持自動備份功能;

備份的硬件和軟件支持/兼容SAP系統(tǒng)的系統(tǒng)備份接口。

備份解決方案可以支持其他UNIX平臺(HP、Sun等)服務器的備份。

實施企業(yè)備份及恢復系統(tǒng)解決方案

備份及恢復系統(tǒng)軟件配置如下：

1) 存儲備份軟件(TSM)

2) 對SAP進行實時在線備份的軟件(TSM for SAP)

Tivoli Storage Manager(TSM)是一個企業(yè)級的 Client/Server 結構跨平臺網絡備份、恢復及存儲管理軟件。TSM Client 主要功能是向 TSM Server 提供需要備份的數(shù)據，或向 TSM Server索取已備份數(shù)據及歸檔數(shù)據以便 Client 恢復數(shù)據。TSM Server 負責管理 TSM Client 的備份數(shù)據、備份策略，以及管理連接在 TSM Server 上的各類存儲產品。

對于操作系統(tǒng)的備份可以采用鏡像的方式，把整個操作系統(tǒng)備份到一個鏡像文件中，恢復時，直接從這個文件中恢復;對于 TSM 客戶端的文件系統(tǒng)，可以直接通過 TSM 來進行備份到和 TSM 服務器連接的磁帶庫中。

系統(tǒng)管理員可以通過 Web 瀏覽器登錄 Tivoli Storage Manager Server 進行管理。為不同的Tivoli Storage Manager Client 設置相應的備份策略，例如自動備份進行的時間，備份數(shù)據保留的長短等等。

系統(tǒng)管理人員還可通過 Web 界面幫助 TSM Client 做數(shù)據備份和恢復。所以 TSM 的管理員無論身在何處，使用何種機器，只要能夠訪問到 TSM 服務器，就可以使用 Web 瀏覽器管理和使用 TSM。配合 TSM 的企業(yè)級管理功能(Enterprise Management)，一名管理員可方便地管理企業(yè)內多臺 TSM 服務器。TSM 的 Web 訪問界面都支持 SSL 的加密方式，可以為某石化提供方便安全的管理方式。

TSM for SAP 是對 SAP 進行實時在線備份的軟件。SAP R/3 的系統(tǒng)是一個三層架構的Server-Client 的應用，如下圖所示：

SAP R/3 的三層結構

第一層是數(shù)據庫服務器(Database server)：R/3 應用的所有數(shù)據和 Log 都存放在此層，目前，R/3 系統(tǒng)支持的后臺外掛關系型數(shù)據庫有：Oracle、DB2、Informix、SQL 等，國內使用面最廣的是基于 Oracle 或 DB2 的 R/3 應用。

第二層是 SAP R/3 的應用服務器(SAP R/3 Application-server)，SAP R/3 的源程序和客戶開發(fā)的 R/3 應用集中在此層，R/3 系統(tǒng)通過一個內部的數(shù)據管理工具 SAPDBA 和數(shù)據庫服務器緊密的關聯(lián)在一起，執(zhí)行對數(shù)據庫服務器的系統(tǒng)管理、存儲管理等。

第三層是用戶的操作層(Presentation Client)，終端用戶通過此層進行系統(tǒng)的具體應用。

因此，從完整的系統(tǒng)存儲管理來說，對于 SAP R/3 的應用，在存儲管理方面，必須兼顧數(shù)據庫服務器和 SAP R/3 的應用服務器兩個層次，才能作到 SAP R/3 應用的在線備份。Tivoli 提供了 Tivoli Storage Manager For SAP R/3 On Oracle/DB2 模塊，結合 Tivoli Storage Manager，可以對 SAP R/3 的數(shù)據庫服務器(Oracle 或 DB2)進行在線的熱備份和恢復。在存儲區(qū)域網(SAN)的環(huán)境下，可以實現(xiàn)不依賴網絡帶寬(LAN-FREE)的數(shù)據備份和恢復。

在系統(tǒng)中，對于生產系統(tǒng)的 ERP 服務器，需要使用 TSM for ERP 軟件，保證系統(tǒng)在正常運行時可以在線備份。由于備份工作由 ERP 的控制接口控制，建議備份的策略結合實際情況，采用全量備份的增量備份結合的方式進行。

2.4 網絡

目前所有服務器配置的網卡都是 10/100/1000M 自適應以太網卡，滿足總部開發(fā)測試環(huán)境和各實施企業(yè)局域網的具體需求。

由于雙機集群系統(tǒng)的要求，生產系統(tǒng)的服務器至少提供了 2 個以太網接口(10/100/1000M);測試和開發(fā)服務器只需要 1 個網絡接口就夠用了，但出于冗余的考慮，我們?yōu)殚_發(fā)和測試服務器也同樣配置了 2 個網絡接口(10/100/1000M)。

2.5 系統(tǒng) 安全性和穩(wěn)定性

生產系統(tǒng)要求具有 7×24 小時的有效性，在工作時間系統(tǒng)運行的正常率應達到 99%，全年總體運行正常率應達到 95%。而以上 IBM 提出的方案中，系統(tǒng)的總體運行正常率可達到99.99%。

生產系統(tǒng)的服務器均使用不同的物理服務器，能夠排除所有系統(tǒng)單點故障;而且每套生產系統(tǒng)都具有 HACMP 配置，系統(tǒng)能夠自動檢測和恢復系統(tǒng)故障，故障自動恢復時間小于 10 分鐘;同時，HACMP 結構可以與 SAP 系統(tǒng)緊密配合，確保對 SAP 的服務影響降到最低。這種可靠性設計已經被用于很多大型的 SAP 客戶。

集群軟件(HACMP)的安裝由賣方的技術人員負責，SAP 系統(tǒng)在集群環(huán)境中的調試和集成測試需要由賣方和 SAP 軟件的技術人員負責，并提供相應的測試技術報告，并由甲方技術人員簽字，當甲方的 SAP 系統(tǒng)升級時，賣方將負責提供相應的 Cluster 的技術支持和系統(tǒng)測試，并由甲方技術人員簽字。

當發(fā)生數(shù)據中心災難時，系統(tǒng)可以通過人工的方式盡快利用培訓系統(tǒng)搭建臨時的生產系統(tǒng)，恢復時間視具體情況而定，如：數(shù)據恢復的時間、是否需要重新安裝操作系統(tǒng)、數(shù)據庫、SAP 應用等因素。

對于電源模塊，所有服務器和存儲系統(tǒng)都配置了多路輸入(三相電至少有 2 路輸入，兩相電至少有三個電源模塊)，以及冗余風扇。

2.6 分支 機構業(yè)務連續(xù)與應急恢復方案

分支機構的 SAP 服務器在總部，這就需要充分考慮如何才能夠保證業(yè)務的連續(xù)運行，以及當“災害”發(fā)生時，如何能夠應急恢復系統(tǒng)的使用。

2.7 服務器系統(tǒng)的高可用性

目前，分支 5 將采用 2 臺 4 路 power4+處理器，8G 內存的 IBM p650 作為業(yè)務處理之用。在保證了足夠處理性能的同時，兩個 p650 之間進行雙機熱備份，保障了系統(tǒng)的可用性。

對于雙機集群系統(tǒng)，我們配備了 IBM FAStT 系列外置磁盤陣列，同時配備 2 臺 SAN 光纖交換機，它與服務器之間通過 SAN 光纖方式連接，提高了雙機系統(tǒng)的安全性。

2.8 網絡的高可用性

分支與總部之間除了要建立 512K 以上的電信專線連接以外，還應考慮建立備用的冗余傳輸線路。對于傳輸網絡的冗余考量，同時也要考慮到網絡帶寬的使用率，在保證用戶正常訪問的基礎上，盡量縮減帶寬成本。目前有以下三種情況，可依據不同的業(yè)務情況與費用分別考慮。

1. 租用新的電信專線作為傳輸線路

優(yōu)點：

傳輸線路穩(wěn)定

獨占方式

缺點：

費用高

長時間租用兩條線路，利用率低

2. 在總部建立 Modem 池，通過多條電話線路作為傳輸后備

優(yōu)點：

建設費用低

獨占方式，通常情況下可以將電話線路暫作其他用途，提高利用率

缺點：

傳輸線路狀態(tài)起伏大

速度依賴于線路質量，易受影響

3.

通過 Internet，以虛擬專網 VPN 方式建立連接后備

優(yōu)點：

建設費用中等，依賴客戶的網絡設備狀況而定

速度較快

缺點：

– 共享方式，通常情況下，通過Internet傳輸速度可以滿足要求，但無法作量化保證

– 安全因素須要進行特別考慮

2.9 應急恢復方案

當系統(tǒng)故障或災難實際發(fā)生時，只有數(shù)據還不夠，還要讓業(yè)務應用在最短的時間內在后援系統(tǒng)上運行起來。同時，業(yè)務人員和制度也應相應地準備就緒。

如上圖所示，目前業(yè)界普遍使用的災難備份方案有三個級別，采用災難備份的級別越高，

災難發(fā)生后恢復的時間就越短，但為了實現(xiàn)這一目標引起的投資成本則越高：

無數(shù)據丟失：專用備份中心實時異地備份。采用這種方式，用戶需要在異地建立一個數(shù)據中心，并且為備份中心購買與數(shù)據中心同樣多同樣配置的機器，使用特定的軟件進行異地實時備份并保證其能實時同步。當數(shù)據中心發(fā)生災難后，異地備份中心與數(shù)據中心應有的數(shù)據一致，最終用戶只要連接到備份中心的系統(tǒng)上即可繼續(xù)正常工作。

活動狀態(tài)的備援站點：這種方式與無數(shù)據丟失的方式有點類似，用戶也需要在異地建立一個備份中心，但由于技術原因備份中心的數(shù)據與數(shù)據中心的數(shù)據不可能實現(xiàn)完全一致，當數(shù)據中心發(fā)生災難后，最終用戶需要人工確認數(shù)據的一致性，并通過相關方式將備份中心沒能同步的數(shù)據補登到系統(tǒng)中。

卡車運動方式+熱站點備份：在這種方式下，用戶有明確的災難恢復中心及設備。在災難發(fā)生后，用戶需要將前一日的數(shù)據備份通過磁帶等介質恢復到災難恢復中心的系統(tǒng)上去，再通過相關的通訊設置使最終用戶能訪問到應用系統(tǒng)。這種方式與活動狀態(tài)的備援站點相比，恢復之后的系統(tǒng)會缺少災難發(fā)生當天所有的數(shù)據，需要最終用戶通過相關方式補錄。

2.10 BM共享型增值備援服務

這一方案相當于備援服務的第三級別，實施后可實現(xiàn)災難發(fā)生后用戶在 1 天左右的時間內恢復業(yè)務系統(tǒng)的運行。并且費用在三種方案中最為經濟。

在此方案中，IBM 設立災難備份中心，提供高水準的專業(yè)機房及相關配套設施，包括 IBM eServer pSeries 主機及相關的外設及通訊用網絡設備，由 IBM 專業(yè)工程師負責主機日常運行，基本操作及相關維護。

當災難發(fā)生時，用戶將前一天的數(shù)據備份用磁帶的方式恢復到 IBM 災難備份中心的eServer series 主機上后交由最終用戶使用。

在這種方案中，由于不同的用戶不可能同時發(fā)生災難，IBM 準備的機房和設備可以提供給多個用戶，所以對單一用戶來說可以用較低的代價實現(xiàn)業(yè)務連續(xù)性和災難恢復。另外，用戶還能享受一年兩次(每次兩天)的災難恢復模擬演練，以方便用戶對備份策略、恢復方案及應急措施進行檢驗，以確保用戶在真正災難發(fā)生后能及時恢復業(yè)務運行系統(tǒng)。

yangkun