1 術語和定義
1.1 資訊系統
資訊系統（Information system），是由計算機硬體、網路和通訊裝置、計算機軟體、資訊資源、資訊使用者和規章制度組成的以處理資訊流為目的的人機一體化系統。主要有五個基本功能，即對資訊的輸入、儲存、處理、輸出和控制。資訊系統經歷了簡單的資料處理資訊系統、孤立的業務管理資訊系統、整合的智慧資訊系統三個發展階段。
1.2 軟硬體平臺
指資訊系統執行的環境，主要包括：硬體（伺服器、儲存）和軟體（作業系統、資料庫和中介軟體）部分。
1.3 非安全區
即Internet，此區域允許外網使用者隨意訪問。
1.4 安全區
內網，此區域通常不對外提供服務。
1.5 DMZ區（Demilitarized Zone）
又稱非軍事區，介於非安全區與安全區之間，此區域按需對外網使用者提供部分服務。
1.6 FC SAN（Fiber ChannelStorage Area Network）
指採用光纖通道的儲存區域網路，是一種將儲存裝置、連線裝置和伺服器整合在一個高速網路中的技術，SAN作為儲存網路，與LAN網路隔離，主要承擔資料儲存任務。
1.7 FC Switch（Fibre Channel Switch）
指光纖通道交換機，是一種高速的網路傳輸中繼裝置，以光纖作為傳輸介質，是組成FC SAN光纖儲存網路的光纖交換機。
1.8 HBA（Host Bus Adapter）
指主機匯流排介面卡，是一個使計算機和儲存裝置間提供輸入/輸出處理和物理連線的電路板和/或積體電路介面卡。
1.9 磁碟陣列（Redundant Arrays of Inexpensive Disks，簡稱Raid）
由多個容量較小、速度較慢的磁碟組合成一個磁碟組，以提升整體效能和儲存空間。
1.10 虛擬機器
指使用系統虛擬化技術，執行在一個隔離環境中、具有完整硬體功能的邏輯計算機系統。
1.11 負載均衡
分為硬體和軟體負載均衡，軟體負載均衡指透過將負載均衡軟體安裝在一臺或多臺伺服器相應的作業系統上來實現負載均衡，硬體負載均衡是直接將負載均衡裝置部署在伺服器和外部網路之間，專門完成負載均衡任務。
1.12 關鍵應用系統
指對業務開展起核心的支撐作用的，對可靠性（Reliability）、可用性（Availability）和可服務性(Serviceability)等具有非常高要求的應用系統，如資產管理系統、營銷管理系統、財務管理系統、人力資源系統、協同辦公系統和綜合管理系統。
1.13 非關鍵應用系統
指除關鍵應用系統外的應用系統。
1.14 TPC-C測試
指模擬一個批發商的訂單管理系統進行資料庫事務處理測試，主要衡量伺服器及資料庫軟體處理線上查詢交易處理（OLTP）的效能表現，正規 TPC-C 測試結果釋出必須提供 tpmC值，即每分鐘完成多少筆 TPC-C (TPC-C Transaction Per Minute)資料庫交易。
1.15 SPEC Web2005
SPEC Web2005延續了SPEC傳統測試的原理，透過多臺客戶機向伺服器發出Http Get請求，請求呼叫Web伺服器上的網頁檔案，這些檔案從數千位元組到數兆位元組不等。在相同的時間裡，伺服器回答的請求越多，就表明伺服器對客戶端的處理能力越強，系統的Web效能就越好。
1.16 業務交易
在TPC-C估演算法中，業務交易指的是使用者的業務請求，使用者每次查詢、修改和刪除操作均各算一次業務交易。
1.17 資料分級儲存
資料分級儲存是指將資料存放在不同級別的儲存裝置（磁碟、磁碟陣列、光碟庫、磁帶庫）中，透過資料分級儲存管理軟體實現資料在儲存裝置之間的自動遷移。
2 基本原則
- 架構一致性原則。
- 安全性原則。
- 可靠性原則。
- 可擴充套件性原則。
- 綠色低碳原則。
3 軟硬體平臺架構
網路從安全形度：
-
- 一般分為DMZ區和安全區（內網），根據應用的用途、架構、功能，選擇適合的網路環境。
- DMZ區和安全區（內網）內各資訊系統應按照相關資訊保安等級保護的要求，依據分割槽、分級、分域的的原則，進行安全域的劃分，實現各安全域差異化的資訊保安防護。
軟體架構方面：
-
- 對維護簡單、不需要更新客戶端的應用系統，建議採用Browser/Server（B/S）架構；
- 對響應時間要求快、客戶端操作介面複雜和有較多個性化要求的應用系統，可採用Client/Server（C/S）架構。
- 對效能要求不高的B/S架構應用系統，可採用Web客戶端/應用伺服器/資料庫伺服器三層架構；
- 對效能要求高的B/S架構應用系統，應採用Web客戶端/Web伺服器/應用伺服器/資料庫伺服器四層架構，Web伺服器用於專門處理HTTP請求(request)，應用伺服器透過多種協議為應用系統提供處理商業邏輯(business logic)。
4 儲存裝置
儲存裝置包括本地物理伺服器（或者虛擬機器）的儲存裝置和共享儲存裝置。對於共享儲存裝置，結構化資料建議採用支援FC SAN 或高頻寬、低延遲的InfiniBand 網路的磁碟陣列，非結構化資料可以採用高價效比的NAS 作為儲存裝置。
儲存網路交換機可選擇FC SAN 交換機或InfiniBand 交換機，交換機應實現2N方式的冗餘；儲存網路交換機應支援Trunk級聯，以便實現多套儲存裝置的共享。
儲存裝置的選擇主要考慮效能、管理複雜程度與可擴充套件性，應支援儲存虛擬化技術，以提高儲存資源的利用率，降低管理複雜度和成本，支援開放結構，可方便的被其他廠商的系統管理軟體使用，支援動態可擴充套件，無須終止應用程式即可擴充套件儲存空間。
建議在DMZ區和安全區（內網）各配置一套共享儲存裝置，以滿足不同資訊系統對儲存裝置的需求。
對可用性要求高、資料讀取速度快、儲存空間需求大、線上可擴充套件等應用系統，原則上應使用共享儲存裝置；資料庫伺服器及虛擬化的物理伺服器應透過儲存網路和共享儲存裝置相連。
對於關鍵應用系統，建議採用資料分級儲存，根據資料的訪問頻率、保留時間、容量、效能要求等因素設定資料遷移規則，將訪問頻率較低的資料儲存在磁帶庫等成本較低、速度較慢的儲存裝置中，將訪問頻率較高的資料儲存在磁碟或者磁碟陣列等成本較高、速度較快的儲存裝置中。
5 資料庫伺服器
（1）傳統方式
關鍵應用系統的Oracle資料庫叢集建議採用多臺小型機，可透過合理密度的虛擬化分割槽技術將一臺小型機分為不同分割槽，建議將不同關鍵應用系統叢集資料庫的節點應安裝在物理伺服器的不同分割槽上，同一應用系統叢集資料庫的不同節點應安裝在不同物理伺服器分割槽上，節點的分佈要結合系統的特點進行錯峰安排。
Oracle資料庫叢集建議採用Real Application Cluster（RAC）的方式構建，可以充分利用RAC提供的負載均衡和實時災難恢復的功能。RAC方式搭建Oracle資料庫叢集對應用系統架構有一定要求，應當注意：
1）透過程式控制各個RAC節點承擔系統中相對獨立的業務邏輯的後臺資料處理，應儘量避免在多個不同節點上存放相同表的資料，以減少各個節點間記憶體資料通訊。
2）應用程式訪問後臺資料來源的連結配置設定為Service方式，將多個資料來源指向的資料庫節點配置為不同的優先順序，例如：3臺資料庫伺服器機器為A、B、C，配置3個資料來源，其中資料來源1指向的資料庫優先順序為ABC，資料來源2指向的資料庫優先順序為BCA，資料來源3指向的資料庫優先順序為CAB。
為滿足某些高負載、大使用者量、資料庫讀寫訪問非常頻繁的應用系統需求，可以考慮透過主從複製、垂直分割槽、水平分割槽等技術將資料庫進行結構分解。
1）主從複製：進行讀寫分離，寫操作作用在主資料庫節點上，透過資料庫複製軟體，結合業務資料更新週期利用業務低谷期進行資料同步。
2）垂直分割槽：將不同型別的資料儲存在不同的資料庫節點中，方便上層業務模組在部署上的分離。
3）水平分割槽：將同一個表的資料透過某種演算法分佈到不同的資料庫節點上。
（2）超融合一體機
建議採用超融合一體機的方式，視情況使用K8S或虛擬機器的方式部署，實現部署落地，可實現以下效果：
滿足高可靠性支援7*24小時持續服務，架構可擴充套件性強
資料庫和應用支援高可用和負載均衡，
支援業務資料和時序資料的分離
6 應用伺服器/Web伺服器
建議採用微機伺服器或刀鋒伺服器作為應用伺服器/Web伺服器的物理伺服器，透過伺服器虛擬化技術，在物理伺服器 上建立虛擬機器，將不同應用系統的應用伺服器/Web伺服器安裝在同一臺物理伺服器的不同虛擬機器上；在部署多節點應用系統時，不同節點應儘量均衡分佈在不同物理伺服器上，以保證應用的高可用性。
針對伺服器硬體配置要求較低、無特殊硬體（影像顯示卡、音訊卡、加密卡等）要求和I/O需求不高（IO吞吐率不超過50MB/s）的資訊系統建議執行在虛擬機器上，以提高資源利用率。
-
- 執行虛擬機器的伺服器應提供主要配件（如電源、硬碟、風扇、記憶體、網路卡）的熱插拔技術。
- 虛擬機器資料應存放在共享儲存裝置上，以提高整體系統的可用性和效能。
關鍵應用系統的應用伺服器/Web伺服器前端應部署硬體負載均衡裝置，根據預設的負載均衡策略，將使用者訪問導向負載壓力較小的虛擬機器/物理伺服器。
使用Weblogic應用伺服器組建叢集時，應用系統軟體設計中不能包含檔案共享的檔案服務和時間服務，可以在叢集中的單個節點使用此類服務，但是不能提供平衡負載或故障轉移功能。
針對Java應用伺服器軟體，應當根據應用系統實際情況和硬體伺服器配置，調整Java的執行引數，最大程度最佳化系統的效能，如Java虛擬機器堆的大小預設是256M，建議根據虛擬機器/物理伺服器的記憶體大小將Java虛擬機器堆進行調整，範圍從512M（當記憶體大於2GB時）至1024M（記憶體大於4GB時）之間。
Java應用伺服器 Weblogic和Websphere 叢集必須滿足以下條件：
-
- 叢集中的主機必須使用永久的靜態IP地址，動態IP地址不能用於叢集環境；
- 叢集中的所有伺服器必須位於同一個區域網，並且必須是IP廣播可到達的；
- 叢集中的所有伺服器必須使用相同的版本，其中Websphere要求所有伺服器都採用WSA ND版本；
- 對於使用了JDBC連線的EJB，所有部署了某EJB的伺服器必須具有相同的部署與持久化配置，即所有伺服器均應有相同的JDBC配置；
- 所有部署了servlet的主機必須維護一組具有相同ACL的servlet。
對於使用Weblogic的應用伺服器系統，應避免將管理伺服器(admin server)設定在叢集的伺服器中。
對web伺服器，可採用各種快取技術提升效能：將訪問頻率高的頁面放到快取伺服器中進行快取。
7 負載均衡
負載均衡裝置主要應用於應用伺服器和WEB伺服器，關鍵應用系統因對效能要求較高，建議以共享的方式使用硬體負載均衡裝置。
使用硬體負載均衡有兩種部署方式：直聯和旁路方式，建議採用旁路方式，將多臺負載均衡裝置分別連線到多臺核心交換機，多臺負載均衡裝置間互為備份，不同應用系統的應用伺服器/Web伺服器叢集共用多臺負載均衡裝置。
判斷負載均衡是否採用主要和物理伺服器/虛擬機器的效能、應用系統所執行事務的複雜性等有關。Weblogic建議每個伺服器併發執行緒數為（25-50）*CPU核數最優，如果應用系統所需最多的併發數超過（25-50）*CPU核數，建議配置多個伺服器組成叢集，使用負載均衡技術，將負載分佈在不同的伺服器上。
建議將Weblogic或者Websphere的server部署在不同的物理伺服器的虛擬機器上，組成叢集，以提高系統的可用性、穩定性。
8 資源分配方法
對儲存資源採用分解法估計，對資料庫伺服器資源採用TPC-C值估演算法，對Web伺服器資源採用SPECweb2005估演算法，對應用伺服器採用SPECjbb2005估演算法。
資源分配的基本方法是首先了解資訊系統的非功能性需求，初步估計各型別伺服器（資料庫伺服器、應用伺服器、Web伺服器、介面伺服器和其他伺服器）總體資源需求，再根據需求冗餘、安全等方面要求，確定各型別伺服器所需物理伺服器數量，基本原則如下：
1）單臺伺服器能提供足夠處理能力的不再分解為多臺物理伺服器。
2）資料庫伺服器採用雙節點冗餘（如Oracle RAC）時，處理容量一般按增長50%計算。
3）應用伺服器採用多個邏輯(物理)節點組成叢集時，4個節點以下（含4個）的叢集，總體處理能力一般按各節點處理能力總和的60%計算，4個節點以上的叢集，總體處理能力一般按各節點處理能力總和的50%計算。
4）web伺服器採用多個邏輯(物理)節點組成叢集時， 4個節點以下（含4個）的叢集，總體處理能力一般按各節點處理能力總和的70%計算，4個節點以上的叢集，總體處理能力一般按各節點處理能力總和的60%計算。
本指導意見的資源主要介紹儲存裝置、資料庫伺服器、應用伺服器、Web伺服器的資源估算方法，其他型別伺服器的資源可參考進行估算。
在進行實際分配資源時，可根據資源需求的估算進行一定程度上的調整。
9 伺服器資源估算方法
9.1 方法一：資料庫伺服器TPC-C估演算法
適用範圍：適用於對資料庫伺服器（應用伺服器、Web伺服器可參考）所需伺服器的CPU能力進行估算。根據估算出的TPC-C值選擇合適的伺服器和伺服器配置。
原理介紹：該估演算法是透過計算應用系統峰值每分鐘需要處理的業務交易數，再綜合考慮業務交易的複雜程度、未來業務交易數量的增長和CPU處理餘量等因素，透過公式計算得出一個估算值，以此來評估需要伺服器必須達到的TPC-C值。
計算公式：TPC-C值 = ((TASK x 80%) /T) x S x F/C
引數解釋：
TASK：典型工作日平均業務交易總量，指的是應用系統需要處理的使用者業務請求的總和。
TASK x 80%：假設典型工作日80%的業務交易集中在高峰時段。
TASK x 80% / T： 即應用系統峰值每分鐘處理的業務交易數。
T：應用系統典型工作日業務交易峰值（完成80%交易）持續時間，以分鐘為單位。
S：實際業務交易操作相對於標準TPC-C測試基準環境交易的複雜程度比例。
F：系統未來的業務交易量發展冗餘預留，需要根據應用系統情況估算。
C：伺服器CPU利用率估算值。實際應用經驗表明，伺服器的CPU利用率高於80%則表明CPU的利用率過高會產生系統瓶頸，而利用率處於75%時，是處於利用率最佳狀態。此值一般設定為C=75%。
計算步驟：
步驟一：估計應用系統平均典型工作日處理的業務交易總量
可以透過以下方法估算：
1、估算典型工作日平均登入系統的使用者數。
2、估算平均典型工作日每個使用者執行的業務交易數。例如，如果平均每個使用者執行五次查詢、五次修改和五次儲存操作，那麼平均每個使用者執行的事務數為15次。
3、根據1和2估算出應用系統平均每典型工作日處理的業務交易總量。
步驟二：估算應用系統每日峰值持續時間（單位為分鐘）
估算應用系統典型工作日峰值持續的時間，指的是應用系統典型工作日每天繁忙的時間。例如，股票交易系統每天的繁忙時間為上午9：30至 11:30和下午13:00至15:00，那麼它的峰值持續時間為3+2 = 5 小時=300分鐘。
步驟三：估算應用系統峰值每分鐘需要處理業務交易數
計算應用系統峰值每分鐘需要處理業務交易數時，需要估算典型工作日高峰時間處理的業務交易數佔每天平均處理的業務交易總數的比例。通常按照20-80的原則進行估算，即80%的業務交易在高峰時間進行，20%的在非高峰時間進行。
根據上述步驟，可以算出應用系統峰值每分鐘需要處理業務交易數。
步驟四：估算應用系統事務複雜度
由於實際業務交易的複雜程度與TPC-C標準測試中的業務交易存在較大的差異，應設定一個合理的對應值，根據經驗，簡單事務的S值為2-5，一般複雜事務為6-12，較複雜事務為13-16，高度複雜事務為17-20。針對資料庫伺服器，S值建議設定為15。
步驟五：估算應用系統未來一段時間後預留量。
如果預計未來使用者數翻番，預留量即為200%。
步驟六：將以上各引數值代入公式，計算出TPC-C值。
步驟七：根據計算出TPC-C值，選擇等於或者大於TPC-C值的目標伺服器。
9.2 方法二：未公佈伺服器TPC-C值估演算法
適用範圍：本方法適用於透過廠商已公佈型號伺服器的TPC-C值估算未公佈伺服器的TPC-C值。
原理介紹：廠家通常會在www.tpc.org上公佈滿配置的某一型號伺服器的TPC-C值，對於非滿配置的伺服器需要進行估算，而TPC-C效能指標反映的是伺服器的整體效能指標，包括：系統結構、處理器、快取、記憶體、I/O等，因此不能簡單從TPC-C值推算出CPU、記憶體的數值，需要綜合考察裝置的整體效能。為了簡化計算，假設伺服器的TPC-C值和CPU數和頻率呈線性關係，因此可以根據滿配置的伺服器大概估算出非滿配置的相同型號或同檔次伺服器的TPC-C值。
計算公式：
目標配置伺服器的TPC-C值 ≈（同型號伺服器滿配置的伺服器的TPC-C值÷CPU個數÷CPU主頻頻率）* 估算伺服器的CPU個數*CPU主頻頻率
計算步驟：
步驟一：獲取滿配置同型別伺服器的TPC-C值，可以在www.tpc.org查到最新的某些型別的伺服器TPC-C值或者透過廠商獲取該值。
步驟二：將滿配置伺服器型號的CPU個數和主頻、目標配置的伺服器的CPU個數和主頻等代入公式。
步驟三：透過公式計算目標配置的伺服器的TPC-C值。
9.3 方法三：Web伺服器SPECweb2005估演算法
適用範圍：適用於為支援滿足特定吞吐量和客戶請求響應速率要求的WEB伺服器的效能進行估算。
原理介紹：Web伺服器通常需要衡量它可以支援滿足特定吞吐量和客戶請求響應速率要求的WEB伺服器的最大併發連線數量，而SPECweb2005是由標準效能評估組織（SPEC）專門開發的的Web伺服器基準測試。伺服器廠商通常會提供每種型號伺服器的SPECweb2005值。使用本方法估算不考慮網路因素，假設客戶端和伺服器位於同一區域網中，網路傳輸時間可以忽略。
計算公式：SPEC Web2005值= (總使用者數 * 線上率 * 線上使用者平均發起http請求數)/ (1 — 冗餘率)
引數解釋：
總使用者數：應用系統總的使用者數。
線上率：應用系統使用高峰時使用者的線上率。
線上使用者平均發起http請求數：平均每個線上使用者發起的http請求數量。
冗餘率：需要預留的冗餘率。
計算步驟：
步驟一：估算系統總的使用者數。
步驟二：估算應用系統使用高峰時使用者的線上率。
步驟三：估算平均每個使用者發起的http請求數量。
步驟四：設定預留的冗餘率。
步驟五：將步驟一、二、三、四的估算值代入公式，計算出SPECweb2005值。
步驟六：根據計算出SPECweb2005值，選擇等於或者大於SPECweb2005值的目標伺服器。
9.4 方法四：應用伺服器SPECjbb2005估演算法
使用範圍：適用於估算Java類應用伺服器所需達到的伺服器效能。
原理解釋：SPECjbb2005是評估伺服器端Java效能的SPEC測試工具。SPECjbb2005透過模擬三層C/S系統(主要是中間層)來評估伺服器端Java的效能。該測試軟體執行JVM(Java虛擬機器)、JIT (Just-In-Time)編譯器、碎片收集、執行緒以及作業系統的其他任務，它同時也測量CPU、Cache、記憶體和 SMP的效能。
伺服器上執行基於J2EE的中間應用軟體平臺，可以將其應用處理能力量化為Java處理能力效能值SPECjbb2005，同時充分考慮系統的冗餘處理能力以及系統資源分配情況，即可估算出伺服器的處理能力效能值。
公式：SPECjbb2005 =A×B/（1-C-D）
引數解釋：
A：每秒最多需要同時處理的業務交易量。
B：每筆業務交易需消耗的SPECjbb2005峰值，根據經驗，每筆業務交易消耗一般為200個bops，或根據該筆業務交易的java語句數量進行計算，B=該筆業務交易的java語句數/5。
C：系統的冗餘處理能力。
D：非Java應用所佔用的系統資源百分比。
例如某系統業務交易峰值為1000筆/秒，系統冗餘處理能力預留30% ，非Java應用所佔用的系統資源百分比為20%，根據計算公式，伺服器SPECjbb2005效能值為：1000*200/(1-30%-20%)=400,000。
9.5 方法五：資料庫伺服器記憶體估演算法
適用範圍：適用於估算資料庫伺服器（應用伺服器、Web伺服器可參考）所需的記憶體。
原理介紹：資料庫伺服器相對其他伺服器來說，因為涉及大量的資料處理，需要把資料載入記憶體，以加快處理速度，所以需要更多的記憶體。對於記憶體的估算一般有下述兩種方法，建議採用下述兩種方法分別估算出所需的記憶體，取其中最大的數值。
計算方法：
方法一：
根據標準化設計，將資料庫記憶體容量（單位為G）和CPU的核心的數量的比例按照4:1配置，一個CPU的核心對應4G記憶體。例如伺服器配置兩個4核CPU則建議配置32G記憶體。
方法二：
原理介紹：資料庫伺服器的記憶體主要包括：作業系統佔用記憶體、資料庫系統佔用記憶體、資料庫併發網路連線佔用記憶體等。按照經驗，Windows平臺記憶體佔用率不超過55%、Unix（或Linux）平臺記憶體佔用率不超過80%時，不會影響系統的效能。
計算公式：
資料庫伺服器（Windows平臺）記憶體 = （作業系統佔用記憶體+資料庫佔用記憶體+資料庫併發網路連線佔用記憶體+其他軟體佔用記憶體）/ 55%
資料庫伺服器（Unix或Linux平臺）記憶體 = （作業系統佔用記憶體+資料庫佔用記憶體+資料庫併發網路連線佔用記憶體+其他軟體佔用記憶體）/ 60%（前置條件：作業系統佔用記憶體+資料庫佔用記憶體+資料庫併發網路連線佔用記憶體+其他軟體佔用記憶體≤4G）
資料庫伺服器（Unix或Linux平臺）記憶體 = （作業系統佔用記憶體+資料庫佔用記憶體+資料庫併發網路連線佔用記憶體+其他軟體佔用記憶體）/ 80%（前置條件：作業系統佔用記憶體+資料庫佔用記憶體+資料庫併發網路連線佔用記憶體+其他軟體佔用記憶體>4G）
引數解釋：
作業系統佔用記憶體：作業系統執行需要佔用的記憶體。
資料庫佔用記憶體：資料庫伺服器執行需要佔用的記憶體。
資料庫併發網路連線佔用記憶體：資料庫客戶端和資料庫伺服器之間連線時，資料庫伺服器需要花費的記憶體。
其他軟體佔用記憶體：資料庫伺服器中其他軟體執行需要佔用的記憶體。
計算步驟：
步驟一：估算作業系統所佔用記憶體
作業系統所佔用記憶體具體和作業系統型別和版本相關，一般為600M記憶體。
步驟二：估算資料庫系統佔用記憶體
資料庫系統佔用記憶體主要包括：資料庫伺服器軟體佔用的記憶體和資料庫快取。其中資料庫快取和資料庫大小相關，根據經驗，資料庫伺服器在快取容量達到資料庫經常訪問資料總量（注：資料庫總量不包括系統資料）的5%時效能較好。資料庫總量可以根據5.2 節中資料庫資料估算的方法計算。因此，資料庫系統快取=資料庫經常訪問資料總量*5%。
資料庫伺服器軟體佔用記憶體和所用的資料庫管理軟體及版本相關，按照經驗，一般為200M記憶體。
步驟三：估算資料庫併發網路連線佔用記憶體
資料庫併發網路連線數每個佔用5M。假設有200個連線，即併發連線佔用記憶體為200 * 5M = 1000M。
步驟四：估算其他軟體佔用記憶體
先估算需要安裝的軟體，再估算每種軟體佔用記憶體的總和。為了簡化計算，可以先估計每種軟體佔用記憶體大小Mi，再估計安裝的軟體數Ni，即其他軟體佔用記憶體= 。
步驟五：估算所需記憶體
根據上述公式，估算所需記憶體。
10 儲存資源估算方法
申請儲存資源時應根據下述方法估算所需儲存資源的需求，儲存需求主要包括資料庫儲存需求、普通檔案儲存需求和系統執行儲存需求三類。
專案 資料庫儲存估算 普通檔案儲存估算系統執行儲存估算
所需引數
1、系統需儲存的實體表資料清單（用E表示）
2、實體資料的索引表資料清單（用I表示）
3、評估每個實體表每條記錄儲存資料容量需求（用S表示）
1、日誌檔案（用L表示）
2、其他檔案（用E表示）
1、作業系統（用OS表示）
2、應用軟體（如Weblogic）（用App表示）
3、其他軟體需求（超過100M以上）（用E表示）
初始估算
1、應用系統實體表資料容量估算：
E 1：實體E1本期記錄M1個，每個容量S1 MB，該檢視表的索引每個容量I1MB。
2、其他類推。
1、日誌檔案大小估算L
2、其他檔案大小估算
E 1、作業系統大小估算OS
2、應用軟體大小估算 App
3、其他軟體大小估算 E
初始容量需求彙總
容量= (S1+I1) * M1 +…+(Si+Ii) * Mi 容量=L + E 容量= OS + App +E
容量冗餘比率
（建議按照未來2年的儲存需求估算） 容量* （1+容量冗餘比率）
=((S1+I1) * M1 +…+(Si+Ii) * Mi
）*（1+冗餘比率） 容量*（1+容量冗餘比率）=（L + E）*（1+冗餘比率） 容量*（1+容量冗餘比率）=（OS + App +E）*（1+冗餘比率）
磁碟Raid冗餘比率
（Raid1：增加100%
Raid10：增加100%
Raid5：增加50%） 容量*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率)
=((S1+I1) * M1 +…+(Si+Ii) * Mi
）*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率) 容量*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率)=
（L + E）*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率) 容量*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率)=
（OS + App +E）*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率)
彙總 （(S1+I1) * M1 +…+(Si+Ii) * Mi
）*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率) （L + E）*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率) （OS + App +E）*（1+容量冗餘比率）*(1+磁碟Raid冗餘比率)
1、TPC-C估演算法例項
1）情景描述：
a. 某應用系統平均每天20，000個使用者次登入系統；
b. 平均每個使用者執行五個查詢事務和五個更新事務；
c. 每天最忙時間從上午9：15到上午10：15時間段；
d. 未來一年，使用者數估計要增加一倍。
2）計算步驟：
步驟一：估算應用系統峰值每分鐘需要處理事務數
高峰時間段每分鐘需要處理事務數 = 20，000 x （5+5）x 80% / 60 = 2666.67
步驟二：估算應用系統事務複雜度：本例項事務複雜度為15。
步驟三：估算應用系統未來一段時間後預留量：預留量為200%。
步驟四：將以上各引數值代入公式，計算出TPC-C值。
TPC-C值=2666.67* 15 * 200% / 75% = 106,666
2、未公佈伺服器TPC-C估演算法例項
1）情景描述：
TPC組織的網站上釋出了最新的IBM的p5-595的TPC-C值測試結果，如下表所示：
型號 處理器型別 處理器主頻 處理器數量 TPC-C值
p5-595 POWER5+處理器 2.3GHz 64路 4,033,378 tpmC
假設需要估算32路CPU的TPC-C值。
2）計算步驟：
步驟一：獲取滿配置的同型別伺服器的TPC-C值：4，033，378。
步驟二：將滿配置伺服器型號的CPU個數和主頻、目標配置的伺服器的CPU個數和主頻等代入公式。
步驟三：透過公式計算目標配置的伺服器的TPC-C值。
估算伺服器的TPC-C值=（4033378 ÷2.3÷64）*2.3 * 32 = 2，016，689。
3、Web伺服器SPECweb2005估演算法例項
1）情景描述：
a. 某個應用系統的總使用者數：100,000。
b. 使用者在典型工作日的線上率為：25%。
c. 線上使用者平均發起http請求數為：4。
d. 系統的預留冗餘率為：20%。
2）計算步驟：
SPECweb2005值=（100，000 * 25% * 4 ）/（1 - 20%）= 125，000。
4、儲存資源估算例項
1）資料庫儲存
情景假設：
a. 某個應用系統，主要包括客戶、產品、訂購關係等三個實體表，建立了3個索引；
b. 預計一年內客戶數為10000個，每個客戶資料3MB；
c. 產品數為200個，每個產品資料5MB；
d. 訂購關係數為50000個，每個資料1MB；
e. 三種索引，每個索引的大小為1MB；
f. 假設考慮30%的容量冗餘比率；
g. 磁碟採用Raid10冗餘。
計算步驟：
a. 分別估算每個實體表的數量和大小
客戶資料大小： 10000 * 3MB
產品資料大小： 200 * 5MB
訂購關係資料大小： 50000 * 1MB
索引資料大小： 10000 * 1MB + 200 * 1MB + 50000 * 1MB
b. 初步容量需求彙總
初步容量需求彙總= 10000 * (3MB + 1MB) + 200 * (5MB + 1MB) + 50000 * (1MB + 1MB)
= 40000MB + 1200MB + 100000MB = 141,200MB
c. 考慮容量冗餘的容量需求
考慮容量冗餘的容量需求= 141，200MB ÷ (1-30%) = 141,200MB ÷0.7 = 201,714MB
d. 考慮磁碟raid冗餘的容量需求
考慮磁碟raid冗餘的容量需求=201，714MB * 200% = 403,428MB
2）普通檔案儲存
情景假設：
a. 某個應用系統存在三種容量較大的檔案：日誌檔案、交易資料記錄、收費檔案；
b. 預計一定時期內，日誌檔案的大小可能達到3G, 交易資料記錄檔案的大小可能達到2.5G，收費檔案的大小可能達到2G；
c. 假設考慮30%的容量冗餘比率；
d. 磁碟採用Raid10冗餘。
計算步驟：
a. 初步容量需求彙總
初步容量需求彙總= 3G + 2.5G + 2G = 7.5G
e. 考慮容量冗餘的容量需求
考慮容量冗餘的容量需求 = 7.5G ÷ (1- 30%) = 10.7G
b. 考慮磁碟raid冗餘的容量需求
考慮磁碟raid冗餘的容量需求= 10.7G * 200% = 21.4G
3）系統執行儲存
情景假設：
a. 伺服器上安裝windows 2003server作業系統、WebLogic8.0中介軟體和防病毒軟體。
b. 假設考慮30%的容量冗餘比率；
c. 磁碟採用Raid10冗餘。
估算步驟：
d. 估算作業系統需要的儲存容量大小
Windows 2003 server作業系統需佔用4.5G空間。
e. 估算應用軟體需要的儲存容量大小
WebLogic 8.0軟體需佔用1.5G空間。
f. 估算其他軟體需要的儲存容量大小
安裝一套防病毒軟體需佔用1G空間。
g. 初步容量需求彙總
初步容量需求彙總 = 4.5G + 1.5G + 1G = 7G
h. 考慮容量冗餘的容量需求：
考慮容量冗餘的容量需求= 7G÷ (1 –30%) = 10G
i. 考慮磁碟raid冗餘的容量需求：