計算機(jī)系統(tǒng)性能容量規(guī)劃-實(shí)施辦法-原創(chuàng)課件

主機(jī)性能容量規(guī)劃實(shí)施辦法作者：TonyShiEmail：tony26600882@歡迎通過郵件交流主機(jī)性能容量規(guī)劃實(shí)施辦法作者：TonyShi2容量規(guī)劃能夠解決的問題IT資源配置是否滿足目前的業(yè)務(wù)需求？

是否存在未充分利用的IT資源和容量？

未來6個月IT資源是否能夠滿足業(yè)務(wù)增長需要？

增加多少IT硬件資源，才能滿足2年內(nèi)的業(yè)務(wù)處理？

業(yè)務(wù)系統(tǒng)合并和拆分，如何配置硬件資源？

業(yè)務(wù)以每月5％增長時，什么時候需要IT擴(kuò)容？IT基礎(chǔ)設(shè)施2容量規(guī)劃能夠解決的問題IT資源配置是否滿足目前的業(yè)務(wù)監(jiān)控體系為了能準(zhǔn)確反映業(yè)務(wù)量和性能之間的函數(shù)關(guān)系，應(yīng)為不同類型的業(yè)務(wù)系統(tǒng)規(guī)劃相應(yīng)的監(jiān)控指標(biāo)，這是生成容量基準(zhǔn)模型的必要條件。通過有效監(jiān)控可以提供準(zhǔn)確的性能數(shù)據(jù)。業(yè)務(wù)量估算模型分析IT系統(tǒng)主要的資源包括CPU、內(nèi)存、磁盤/磁盤控制器三大類。因此，由于資源數(shù)量、單個資源不同體系架構(gòu)的影響，需要將影響性能的資源的數(shù)學(xué)關(guān)系公式和經(jīng)驗值有效結(jié)合在模型中，才能進(jìn)行有效的性能趨勢和假設(shè)性分析。不同的應(yīng)用系統(tǒng)的業(yè)務(wù)量估算有不同方法和流程。容量規(guī)劃的主要工作監(jiān)控體系為了能準(zhǔn)確反映業(yè)務(wù)量和性能之間的函數(shù)關(guān)系，應(yīng)克服TPC-C、SPEC等國際標(biāo)準(zhǔn)主要體現(xiàn)主機(jī)/存儲、系統(tǒng)平臺性能的局限性，將業(yè)務(wù)量、服務(wù)等級、IT系統(tǒng)性能統(tǒng)一規(guī)劃和管理，建立三者之間的關(guān)系模型。容量規(guī)劃有助于企業(yè)有效控制IT基礎(chǔ)設(shè)施的投入成本；并幫助企業(yè)(特別是電信運(yùn)營商、銀聯(lián)系統(tǒng))的IT系統(tǒng)的服務(wù)輸出能力。增強(qiáng)對短、中期投資的可預(yù)見性。IT投資成本IT服務(wù)提高投資回報率實(shí)施容量規(guī)劃意義何在？克服TPC-C、SPEC等國際標(biāo)準(zhǔn)主要體現(xiàn)主機(jī)/存儲5容量規(guī)劃的價值體現(xiàn)隱式價值顯式價值CapacityPlanning降低采購成本：對在建項目預(yù)先進(jìn)行容量規(guī)劃，確定最優(yōu)化的硬件資源配置并指導(dǎo)投資預(yù)算；找出未充分利用的資源和容量，以便指導(dǎo)業(yè)務(wù)系統(tǒng)合并或者將其它業(yè)務(wù)系統(tǒng)加入進(jìn)來。節(jié)約維護(hù)成本：在約5年的硬件資源有效期內(nèi)，系統(tǒng)維護(hù)、配置、升級等方面的費(fèi)用要高于硬件的購買投資，容量規(guī)劃幫助成比例的降低了這些附加成本。減少人力資源成本：容量規(guī)劃幫助合理分配IT硬件資源，從而也會幫助組建合理的IT團(tuán)隊，以降低人力成本。

增強(qiáng)IT系統(tǒng)可靠性：減少資源或容量的過度冗余，會減少風(fēng)險節(jié)點(diǎn)，從而降低風(fēng)險轉(zhuǎn)變成災(zāi)難的概率；

準(zhǔn)確預(yù)測資源或容量的過度負(fù)載時間點(diǎn)，降低宕機(jī)概率。提高IT系統(tǒng)可用性：通過短期、不間斷的容量規(guī)劃，及時監(jiān)控服務(wù)質(zhì)量要求和響應(yīng)時間的差距，提前采取措施，避免因服務(wù)質(zhì)量降低導(dǎo)致的客戶不滿。

降低IT投資成本&提高IT的QoS5容量規(guī)劃的價值體現(xiàn)隱式價值顯式價值CapacityPla系統(tǒng)遷移。通過在測試環(huán)境下的有效性能監(jiān)控，建立業(yè)務(wù)量、服務(wù)等級、IT硬件資源三者之間的容量基準(zhǔn)模型，通過what-if分析業(yè)務(wù)量變化時的資源需求和性能表現(xiàn)，有效控制IT系統(tǒng)運(yùn)營環(huán)境下的軟硬件資源成本。系統(tǒng)的擴(kuò)容改造。通過在運(yùn)維期內(nèi)的有效性能監(jiān)控，收集系統(tǒng)在運(yùn)營期的性能數(shù)據(jù)，建立業(yè)務(wù)量、服務(wù)等級、IT資源三者之間的容量模型，分析未來不同時間（例如6個月內(nèi)、1年內(nèi)等）的資源需求和性能表現(xiàn)，為IT系統(tǒng)的擴(kuò)容提供依據(jù)，并對IT系統(tǒng)的性能進(jìn)行有效的監(jiān)控和預(yù)警。

系統(tǒng)遷移系統(tǒng)擴(kuò)容改造何時？何處？實(shí)施容量規(guī)劃系統(tǒng)遷移。通過在測試環(huán)境下的有效性能監(jiān)控，建立業(yè)務(wù)量、服務(wù)等7容量規(guī)劃時機(jī)需求開發(fā)上線運(yùn)維系統(tǒng)架構(gòu)確定開發(fā)環(huán)境代碼測試功能測試性能測試系統(tǒng)測試系統(tǒng)調(diào)優(yōu)系統(tǒng)監(jiān)控

需求(擴(kuò)容)容量規(guī)劃容量規(guī)劃上線容量規(guī)劃擴(kuò)容容量規(guī)劃7容量規(guī)劃時機(jī)需求開發(fā)上線運(yùn)維系統(tǒng)架構(gòu)代碼測試系統(tǒng)測試系統(tǒng)監(jiān)8容量規(guī)劃的前提條件上線容量規(guī)劃擴(kuò)容容量規(guī)劃對測試環(huán)境的要求性能調(diào)優(yōu)后收集容量規(guī)劃的基礎(chǔ)數(shù)據(jù)：即確保應(yīng)用每個組件（Web、DB等）的瓶頸都在于硬件平臺，即每個組件都可能因為壓力的增加而使CPU或內(nèi)存的利用率接近100；測試環(huán)境中DB的數(shù)據(jù)量要基本和現(xiàn)網(wǎng)一致，否則結(jié)果會有偏差；在測試中如果發(fā)現(xiàn)各組件間系統(tǒng)資源占用情況差別過大（如DBCPU100％時WebCPU10％），應(yīng)調(diào)整測試環(huán)境；盡量保證測試環(huán)境和上線環(huán)境的硬件平臺有相同的技術(shù)架構(gòu)。對應(yīng)用系統(tǒng)運(yùn)行環(huán)境的要求確認(rèn)網(wǎng)絡(luò)不是造成響應(yīng)時間過長的原因假設(shè)應(yīng)用系統(tǒng)處在最優(yōu)狀態(tài)（如果瓶頸在應(yīng)用系統(tǒng)，容量規(guī)劃的結(jié)果會有較大的誤差）；準(zhǔn)確統(tǒng)計目前的業(yè)務(wù)量，作為容量規(guī)劃建模的輸入數(shù)據(jù)，業(yè)務(wù)量偏差大會導(dǎo)致不能和實(shí)際的性能表現(xiàn)相匹配；8容量規(guī)劃的前提條件上線容量規(guī)劃擴(kuò)容容量規(guī)劃對測試環(huán)境的要求性能監(jiān)控代理?？蛻舳塑浖惭b在每臺主機(jī)上，收集并存儲主機(jī)的性能數(shù)據(jù)；根據(jù)容量規(guī)劃的要求，對性能數(shù)據(jù)進(jìn)行統(tǒng)計分析。提供性能數(shù)據(jù)導(dǎo)出工具；用戶可以通過web頁面展現(xiàn)系統(tǒng)的性能變化曲線。容量監(jiān)控/管理工具。服務(wù)器端軟件，匯總各代理收集的性能數(shù)據(jù)，建立業(yè)務(wù)系統(tǒng)的動態(tài)性能模型，對主機(jī)的性能、硬件資源進(jìn)行動態(tài)的監(jiān)控和管理，可以設(shè)置閾值在設(shè)定的條件下實(shí)現(xiàn)預(yù)警。

容量建模工具。根據(jù)采集的性能數(shù)據(jù)建立系統(tǒng)性能容量模型，使用系統(tǒng)容量模型進(jìn)行假設(shè)性問題試驗,事先了解應(yīng)用系統(tǒng)環(huán)境的變化對應(yīng)用系統(tǒng)部署、服務(wù)器的整合、業(yè)務(wù)擴(kuò)展或增加工作負(fù)荷所產(chǎn)生的影響，從而對系統(tǒng)容量規(guī)劃作出正確的決策。容量建模工具容量監(jiān)控/管理工具IBMHost性能監(jiān)控代理SunHost性能監(jiān)控代理HPHost性能監(jiān)控代理windows性能監(jiān)控代理容量規(guī)劃架構(gòu)性能監(jiān)控代理?？蛻舳塑浖?，安裝在每臺主機(jī)上，收集并存儲主機(jī)的10容量規(guī)劃的基本過程理解業(yè)務(wù)最大的應(yīng)用/負(fù)載業(yè)務(wù)量的增長幅度2.劃分主機(jī)負(fù)載a.定義workload b.workload的服務(wù)方式3.分析當(dāng)前系統(tǒng)容量

a.測量所有的應(yīng)用資源

b.使用workload測量應(yīng)用資源

c.確定硬件系統(tǒng)各部分的反應(yīng)時間4.系統(tǒng)中/遠(yuǎn)期預(yù)測

a.確定未來系統(tǒng)的資源配置需求

b.結(jié)合業(yè)務(wù)發(fā)展，規(guī)劃遠(yuǎn)期系統(tǒng)配置5．編制詳細(xì)性能報告10容量規(guī)劃的基本過程理解業(yè)務(wù)11

Step1：理解業(yè)務(wù)第一步工作負(fù)載workload是計算機(jī)系統(tǒng)上所有工作的邏輯分類，如果將計算機(jī)的工作想象成一塊大餅，那么每一個workload就是大餅的一塊扇區(qū)?？梢园凑找韵逻壿媽orkload進(jìn)行分類：

who：誰在工作？例如特定的用戶或組織

what：什么類型的工作？例如訂單處理，財務(wù)報表

how：如何做這些工作？在線查詢，批量數(shù)據(jù)備份

每個workload應(yīng)具備業(yè)務(wù)敏感度，也就是說業(yè)務(wù)量的增加或減少和workload的性能表現(xiàn)有較明顯的相關(guān)性；不管以何種邏輯劃分workload，都應(yīng)找出每個workload的相關(guān)業(yè)務(wù)指標(biāo)，并用業(yè)務(wù)語言描述和定義該指標(biāo)。第二步工作單元第三步服務(wù)等級將工作單元和workload聯(lián)系起來，與完成某項工作而消耗的系統(tǒng)資源的數(shù)量類似，工作單元是一類可量化的變量，只不過需要用業(yè)務(wù)語言來描述。工作單元可以看成為workload而設(shè)定的幾個可量化的參數(shù)，其數(shù)值的變化代表了workload對資源消耗的變化。例如：1、應(yīng)用的交易事務(wù)數(shù)量2、連接數(shù)據(jù)庫的用戶數(shù)3、呼叫中心處理的呼叫次數(shù)4、帳務(wù)中心的訂單處理數(shù)量都可以作為工作單元。服務(wù)等級協(xié)議由服務(wù)提供者和服務(wù)消費(fèi)者雙方制定，定義一個在服務(wù)消費(fèi)者接受范圍內(nèi)的服務(wù)，一般通過響應(yīng)時間和吞吐量來描述服務(wù)等級。簽訂服務(wù)等級協(xié)議時最好按照workload，理由是workload類似與性能和業(yè)務(wù)量之間的紐帶，有很大的相關(guān)性；而且workload中工作單元的數(shù)值大小對業(yè)務(wù)量變化具備相當(dāng)?shù)拿舾卸?。比如對一個預(yù)約應(yīng)用系統(tǒng)，我們可以這樣定義其服務(wù)等級：1、一小時內(nèi)能夠處理的電話預(yù)約數(shù)量不少于200個；2、每一個預(yù)約需在30秒內(nèi)完成；3、每一個預(yù)約請求在隊列中的等待時間不能超過60秒。

11Step1：理解業(yè)務(wù)第一步工作負(fù)載wo12Step1：理解業(yè)務(wù)系統(tǒng)(System)工作負(fù)載(Workload)工作單元(Unitofwork)資源(Resource)SAP主機(jī)財務(wù)模塊活動用戶數(shù)每個工作單元對多個資源都有消耗CPU業(yè)務(wù)處理數(shù)I/OTuxedo服務(wù)器查詢模塊事務(wù)數(shù)Memory取款模塊事務(wù)數(shù)Networkconnection……店面(System)部門(Workload)業(yè)務(wù)指標(biāo)(Unitofwork)資源(Resource)快餐店廚房食物重量每個業(yè)務(wù)指標(biāo)對多個資源都有消耗雞蛋每天生產(chǎn)三明治數(shù)量生肉大廳就餐的顧客數(shù)量泡菜切片……面粉asopposedto對比12Step1：理解業(yè)務(wù)系統(tǒng)工作負(fù)載工作單元資源SAP主機(jī)活13Step2：劃分workload類型解釋Batch用于mainframe結(jié)構(gòu)的主機(jī)容量規(guī)劃，該環(huán)境下沒有用戶，workload根據(jù)預(yù)先定義的schedule啟動/停止/休眠，即有處理任務(wù)就啟動，沒有就休眠直到有新的處理任務(wù)。Process用于opensystem結(jié)構(gòu)的主機(jī)，即適用于小型機(jī)和pc機(jī)。Interactive有用戶參與，并且一般用戶通過終端連接，執(zhí)行一些交互性的工作。例如用戶對oracle數(shù)據(jù)庫發(fā)出請求。Transaction多個進(jìn)程一起執(zhí)行事務(wù)，transaction不是由某一個用戶發(fā)起或者執(zhí)行，這是和interactive差異的地方。13Step2：劃分workload類型解釋Batch用于m14Step3：收集數(shù)據(jù)上線容量規(guī)劃擴(kuò)容容量規(guī)劃通過性能測試收集業(yè)務(wù)數(shù)據(jù)和性能數(shù)據(jù)業(yè)務(wù)數(shù)據(jù)：通過性能測試階段指定的加壓方式和測試策略，收集業(yè)務(wù)數(shù)據(jù)性能數(shù)據(jù)：收集不同負(fù)載測試時的性能數(shù)據(jù)，作為容量規(guī)劃的原始數(shù)據(jù)。通過業(yè)務(wù)統(tǒng)計和系統(tǒng)監(jiān)控收集數(shù)據(jù)業(yè)務(wù)數(shù)據(jù):通過業(yè)務(wù)量統(tǒng)計或其它監(jiān)控方法，收集業(yè)務(wù)數(shù)據(jù)。性能數(shù)據(jù)：通過實(shí)時監(jiān)控收集性能數(shù)據(jù)14Step3：收集數(shù)據(jù)上線容量規(guī)劃擴(kuò)容容量規(guī)劃通過性能測試15Step4：模型分析模型基礎(chǔ)數(shù)據(jù)：根據(jù)當(dāng)前的性能數(shù)據(jù)，建立性能benchmark，作為模型分析的基礎(chǔ)。趨勢分析不同的業(yè)務(wù)增長量What-if分析MVAP模型Simulation模型按照計算模型的差異，可以建立的模型包括：單機(jī)模型改變硬件配置Multi-tier模型改變各層的硬件配置；改變各層的主機(jī)數(shù)量按照應(yīng)用系統(tǒng)的類型，可以建立的模型包括：模型分析時能夠定義的資源：CPUDiskDiskcontroller模型分析時可以改變的參數(shù)：業(yè)務(wù)增長量Workload類型Disk間的I/O平衡……15Step4：模型分析模型基礎(chǔ)數(shù)據(jù)：根據(jù)當(dāng)前的性能數(shù)據(jù)，建16Step5：結(jié)果報告結(jié)果報告：容量規(guī)劃最終將為硬件采購提供必要的依據(jù)，在預(yù)先制定的業(yè)務(wù)目標(biāo)前提下，給出最佳的硬件配置方案。一般情況下，對平均負(fù)載的模型分析以及對峰值負(fù)載的模型分析，都需要實(shí)施。

16Step5：結(jié)果報告結(jié)果報告：17謝謝！(后附容量規(guī)劃案例)結(jié)束17謝謝！結(jié)束18

案例—SAP系統(tǒng)容量規(guī)劃通過容量規(guī)劃預(yù)測兩年內(nèi)的性能表現(xiàn)，回答以下幾個問題：為了滿足平均負(fù)載，系統(tǒng)需要在什么時候擴(kuò)容？擴(kuò)多少資源？為了滿足峰值負(fù)載，系統(tǒng)需要在什么時候擴(kuò)容？擴(kuò)多少資源？過程：理解業(yè)務(wù)：估算業(yè)務(wù)量劃分負(fù)載(workload)：從業(yè)務(wù)上對引起應(yīng)用/負(fù)載的活動進(jìn)行分類采集數(shù)據(jù)：平均負(fù)載下的性能數(shù)據(jù)；峰值負(fù)載下的性能數(shù)據(jù)建模分析:趨勢分析,What-if分析建議:回答假設(shè)性問題18案例—SAP系統(tǒng)容量規(guī)劃過程：195

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量應(yīng)用/負(fù)載代表了sap系統(tǒng)的業(yè)務(wù)量，根據(jù)和sap系統(tǒng)和業(yè)務(wù)人員的討論，并從業(yè)務(wù)角度來描述，業(yè)務(wù)量受到兩個主要因素的影響：活動用戶數(shù)；用戶的平均業(yè)務(wù)處理量

用戶數(shù)和業(yè)務(wù)處理量的增加，必然帶動業(yè)務(wù)量的增長。反映到SAP應(yīng)用系統(tǒng)，必然需要更多的硬件資源用于業(yè)務(wù)處理，通過對兩個自變量在IT系統(tǒng)的功能映射分析，我們可以確定：用戶數(shù)增加需要SAP應(yīng)用系統(tǒng)和Oracle數(shù)據(jù)庫相應(yīng)啟動更多的進(jìn)程，以增加業(yè)務(wù)處理能力，TeamQuest容量規(guī)劃中的Population就代表了某一時刻SAP用戶和oracle用戶啟動的進(jìn)程數(shù)量，因此進(jìn)程數(shù)的增長趨勢可以較好的模擬用戶數(shù)引起業(yè)務(wù)量增長的趨勢。用戶操作數(shù)的增加需要計算機(jī)處理更多的用戶請求，表現(xiàn)在硬件層面上即計算機(jī)的CPU、Memory、DISK需要處理更多的機(jī)器指令，TeamQuest容量規(guī)劃中的visitsatactiveresource的值就代表了一個用戶的業(yè)務(wù)操作數(shù)，因此visits值的增長趨勢可以較好的模擬用戶操作數(shù)引起的業(yè)務(wù)量增長趨勢。

ID業(yè)務(wù)量因子(工作單元)模型中對應(yīng)的變量1活動用戶數(shù)Population2平均業(yè)務(wù)處理量Visitsatactiveresource

案例—SAP系統(tǒng)容量規(guī)劃195結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)205

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量由于業(yè)務(wù)每月增長量暫時缺乏精確的統(tǒng)計數(shù)據(jù)，本次案例暫時通過假設(shè)設(shè)定一個增長比例：負(fù)載類型Population(活動用戶數(shù))Visitsatactiveresource(處理請求數(shù))平均負(fù)載SAP系統(tǒng)10%10%Oracle數(shù)據(jù)庫10%10%峰值負(fù)載SAP系統(tǒng)5%5%Oracle數(shù)據(jù)庫5%5%本次預(yù)測“2年”內(nèi)的業(yè)務(wù)滿足程度，設(shè)計24步（step），每step代表一個月，上表為假設(shè)的業(yè)務(wù)量每月的變化。

案例—SAP系統(tǒng)容量規(guī)劃205結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)21機(jī)器Workloads備注Sapapp1r3padmuserhpOpenViewrootexceptOpenViewusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenViewSapapp2r3padmuserhpOpenViewrootexceptOpenViewusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenViewSapDBSapDBorar3pr3padmuserhpOpenViewrootexceptOpenViewusedbyorar3pusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenView5

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量根據(jù)業(yè)務(wù)類型劃分工作負(fù)載

案例—SAP系統(tǒng)容量規(guī)劃21機(jī)器Workloads備注Sapapp1r3padmu225

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量Sap系統(tǒng)在每月25～下月5日業(yè)務(wù)比較繁忙，本次建模就在該時間段內(nèi)收集數(shù)據(jù)，由于該時間段的性能表現(xiàn)有一定的代表性，所以對系統(tǒng)擴(kuò)容有一定的參考意義。經(jīng)過篩選，確定選取2006-5-268:20~17:20之間共9個小時的數(shù)據(jù)段：對平均負(fù)載性能數(shù)據(jù)，以10分鐘作為數(shù)據(jù)聚合尺度；(保證計算出精確的平均值)；對峰值負(fù)載性能數(shù)據(jù)，以1小時作為數(shù)據(jù)聚合尺度。（真正反映業(yè)務(wù)峰值，而不是瞬時性能峰值）。

確定采集段數(shù)據(jù)聚合尺度生成abr文件

案例—SAP系統(tǒng)容量規(guī)劃225結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)235

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.29%lessthan.011.01lessthan.01hpOpenViewlessthan.01%lessthan.012.00lessthan.01r3padmuser32.55%4.7945.24lessthan.01rootexceptOpenView0.31%5.13134.08lessthan.01WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.42%0.001.02lessthan.01hpOpenViewlessthan.01%lessthan.012.00lessthan.01r3padmuser81.44%4.7645.010.08rootexceptOpenView0.27%5.45135.030.22SapApp1峰值負(fù)載平均負(fù)載

案例—SAP系統(tǒng)容量規(guī)劃235結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)245

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.38%lessthan.011.02lessthan.01hpOpenView24.97%lessthan.012.00lessthan.01r3padmuser15.41%2.8240.00lessthan.01rootexceptOpenView0.13%4.99132.08lessthan.01WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.36%0.001.01lessthan.01hpOpenView24.98%lessthan.012.00lessthan.01r3padmuser25.49%2.4340.000.01rootexceptOpenView0.14%6.00133.010.04SapApp2峰值負(fù)載平均負(fù)載

案例—SAP系統(tǒng)容量規(guī)劃245結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)255

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.18%0.001.01lessthan.01hpOpenViewlessthan.01%lessthan.012.00lessthan.01r3padmuser0.02%0.013.00lessthan.01rootexceptOpenView0.34%5.07134.10lessthan.01sapdborar3p45.39%610.4978.99lessthan.01WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.40%0.001.02lessthan.01hpOpenViewlessthan.01%0.012.00lessthan.01r3padmuser0.02%0.023.00lessthan.01rootexceptOpenView0.37%6.33134.970.04sapdborar3p82.31%938.1678.980.02SapDB峰值負(fù)載平均負(fù)載

案例—SAP系統(tǒng)容量規(guī)劃255結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)265

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量在建模階段，需要IT人員提供的數(shù)據(jù)包括：主機(jī)/存儲的CPU、diskcontroller、disk的類型或者性能參數(shù)；對每臺主機(jī)平均負(fù)載、峰值負(fù)載單獨(dú)建立并校驗model，模型分析的思路：首先正確匹配硬件資源類型，保存為baseline模型；平均負(fù)載按照每月10％業(yè)務(wù)量增長，峰值負(fù)載按照每月5％業(yè)務(wù)量增長，分別進(jìn)行趨勢分析；如果在某些硬件資源處形成瓶頸，增加該資源，進(jìn)行what-if分析。

案例—SAP系統(tǒng)容量規(guī)劃265結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)275

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1平均負(fù)載_趨勢分析AVG(4CPU)Step:16Step:17Step:18Step:19Step:20StretchFactors1.501.641.842.142.55CPUUtilization80.2683.1385.8288.2590.34分析結(jié)果：

在step16～step18之間，即平均CPU利用率在80.3%~85.8%之間時，為了滿足平均業(yè)務(wù)量需求，應(yīng)考慮對系統(tǒng)進(jìn)行擴(kuò)容。

案例—SAP系統(tǒng)容量規(guī)劃275結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)285

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_趨勢分析分析結(jié)果：PEAK（4CPU）Step1Step2Step3Step4Step5StretchFactors1.511.671.892.172.51CPUUtilization81.4484.5287.1889.3491.05在step1～step3之間，為了滿足峰值業(yè)務(wù)處理，應(yīng)考慮對系統(tǒng)進(jìn)行擴(kuò)容；在第24step之前，必須考慮對CPU進(jìn)行擴(kuò)容，以防系統(tǒng)崩潰不再提供服務(wù)，或者CPU過于繁忙導(dǎo)致不能正常返回響應(yīng)。

案例—SAP系統(tǒng)容量規(guī)劃285結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)295

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_what-if分析分析結(jié)果：PEAK（8CPU）Step20Step21Step22Step23Step24StretchFactors1.271.331.411.511.64CPUUtilization86.3388.1389.7891.2592.49

增加4個CPU后，在未來24個月內(nèi)，硬件資源可以較好的滿足業(yè)務(wù)需要。

案例—SAP系統(tǒng)容量規(guī)劃295結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)305

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1平均負(fù)載_趨勢分析分析結(jié)果：AVG（4CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.171.191.201.221.241.27CPUUtilization43.0844.6146.1347.6649.1850.70

未來24個月內(nèi)，硬件資源可以較好的滿足均值業(yè)務(wù)需要。

案例—SAP系統(tǒng)容量規(guī)劃305結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)315

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_趨勢分析分析結(jié)果：PEAK（4CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.231.251.271.291.311.33CPUUtilization48.1449.3950.6351.8753.1154.34

未來24個月內(nèi)，硬件資源可以較好的滿足峰值業(yè)務(wù)需要。

案例—SAP系統(tǒng)容量規(guī)劃315結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)325

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1平均負(fù)載_趨勢分析分析結(jié)果：AVG（4CPU）Step8Step9Step10Step11Step12StretchFactors1.351.471.662.002.55CPUUtilization76.5880.7984.8088.4091.37在step10～step11之間，即平均CPU利用率在84%~88%之間時，為了滿足Oracle用戶的業(yè)務(wù)處理需求，應(yīng)考慮對系統(tǒng)進(jìn)行擴(kuò)容。在step20時，數(shù)據(jù)庫對用戶的請求將不能正常返回響應(yīng)，即在第step20之前，必須考慮對系統(tǒng)進(jìn)行升級。

案例—SAP系統(tǒng)容量規(guī)劃325結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)335

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1平均負(fù)載_what-if分析分析結(jié)果：Avg（8CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.161.181.211.241.271.32CPUUtilization70.2472.7075.1477.5879.9982.38CPU不再是性能瓶頸，在24個月內(nèi)，硬件資源基本上可以較好的滿足業(yè)務(wù)需求；磁盤I/O在后期會越來越繁忙，指令在磁盤處的排隊有逐漸增多的趨勢，在24個月后應(yīng)考慮優(yōu)化磁盤結(jié)構(gòu)或者更換更快的磁盤。

案例—SAP系統(tǒng)容量規(guī)劃335結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)345

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_趨勢分析分析結(jié)果：PEAK（4CPU）Step1Step2Step3Step4……Step17StretchFactors1.541.742.042.4512.02CPUUtilization82.3285.6088.4290.6898.15在step1～step2之間，即平均CPU利用率在82%~86%之間時，為滿足峰值業(yè)務(wù)處理需求，應(yīng)考慮對系統(tǒng)進(jìn)行擴(kuò)容。在step17時(StretchFactor值超過12)，數(shù)據(jù)庫對用戶的請求將不能正常返回響應(yīng)，即在第step17之前，必須考慮對系統(tǒng)進(jìn)行升級。

案例—SAP系統(tǒng)容量規(guī)劃345結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)355

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_what-if分析分析結(jié)果：PEAK（8CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.371.451.561.711.922.18CPUUtilization87.0788.9990.7592.2793.4994.44在step21～step23之間，即平均CPU利用率在90%~93%之間時，為了滿足Oracle用戶的業(yè)務(wù)處理需求，應(yīng)考慮對系統(tǒng)進(jìn)行擴(kuò)容。未來24個月內(nèi)，硬件資源基本上可以滿足峰值業(yè)務(wù)需求。

案例—SAP系統(tǒng)容量規(guī)劃355結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)365

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_what-if分析分析結(jié)果：PEAK（10CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.161.181.201.231.261.29CPUUtilization76.2178.1380.0381.9283.7785.59CPU不再是性能瓶頸，在24個月內(nèi)，硬件資源基本上可以較好的滿足業(yè)務(wù)需求；磁盤I/O在后期會越來越繁忙，指令在磁盤處的排隊有逐漸增多的趨勢，在24個月后應(yīng)考慮平衡磁盤的I/O或者優(yōu)化磁盤結(jié)構(gòu)。

案例—SAP系統(tǒng)容量規(guī)劃365結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)375

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量容量分析123456789101112131415161718192021222324SAPAPP1平均負(fù)載

SAPAPP1峰值負(fù)載

SAPAPP1+4CPU峰值負(fù)載

SAPAPP2平均負(fù)載

SAPAPP2峰值負(fù)載

SAPDB平均負(fù)載

SAPDB+4CPU平均負(fù)載SAPDB峰值負(fù)載

SAPDB+4CPU峰值負(fù)載SAPDB+6CPU峰值負(fù)載結(jié)果的判斷依據(jù)：StretchFactorperiod正常期考慮擴(kuò)容期響應(yīng)很慢期服務(wù)崩潰期StretchFactor<1.51.5~2.02.0~12>12

案例—SAP系統(tǒng)容量規(guī)劃375結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)385

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量三條建議：在未來2年內(nèi)，為保證SapApp1、SapApp2、SapDB三臺主機(jī)的硬件資源不會形成性能瓶頸，建議為三臺主機(jī)分別增加4個、0個、6個同類型CPU；相應(yīng)增加各主機(jī)的內(nèi)存數(shù)量。SapDB在2年內(nèi)磁盤的I/O不會形成瓶頸，但在后期disk的queue越來越長，預(yù)計2年后I/O會成為瓶頸，建議提前對I/O進(jìn)行優(yōu)化，例如在busydisk和idledisk之間進(jìn)行I/O平衡，優(yōu)化磁盤陣列的卷組管理等。容量規(guī)劃能夠回答的問題(回顧)：公司需要多少資源才能滿足對客戶的服務(wù)承諾？按照目前業(yè)務(wù)的增長速度，什么時候系統(tǒng)容量會超負(fù)荷？什么時候需要增加多少資源？

案例—SAP系統(tǒng)容量規(guī)劃385結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)主機(jī)性能容量規(guī)劃實(shí)施辦法作者：TonyShiEmail：tony26600882@歡迎通過郵件交流主機(jī)性能容量規(guī)劃實(shí)施辦法作者：TonyShi40容量規(guī)劃能夠解決的問題IT資源配置是否滿足目前的業(yè)務(wù)需求？

是否存在未充分利用的IT資源和容量？

未來6個月IT資源是否能夠滿足業(yè)務(wù)增長需要？

增加多少IT硬件資源，才能滿足2年內(nèi)的業(yè)務(wù)處理？

業(yè)務(wù)系統(tǒng)合并和拆分，如何配置硬件資源？

業(yè)務(wù)以每月5％增長時，什么時候需要IT擴(kuò)容？IT基礎(chǔ)設(shè)施2容量規(guī)劃能夠解決的問題IT資源配置是否滿足目前的業(yè)務(wù)監(jiān)控體系為了能準(zhǔn)確反映業(yè)務(wù)量和性能之間的函數(shù)關(guān)系，應(yīng)為不同類型的業(yè)務(wù)系統(tǒng)規(guī)劃相應(yīng)的監(jiān)控指標(biāo)，這是生成容量基準(zhǔn)模型的必要條件。通過有效監(jiān)控可以提供準(zhǔn)確的性能數(shù)據(jù)。業(yè)務(wù)量估算模型分析IT系統(tǒng)主要的資源包括CPU、內(nèi)存、磁盤/磁盤控制器三大類。因此，由于資源數(shù)量、單個資源不同體系架構(gòu)的影響，需要將影響性能的資源的數(shù)學(xué)關(guān)系公式和經(jīng)驗值有效結(jié)合在模型中，才能進(jìn)行有效的性能趨勢和假設(shè)性分析。不同的應(yīng)用系統(tǒng)的業(yè)務(wù)量估算有不同方法和流程。容量規(guī)劃的主要工作監(jiān)控體系為了能準(zhǔn)確反映業(yè)務(wù)量和性能之間的函數(shù)關(guān)系，應(yīng)克服TPC-C、SPEC等國際標(biāo)準(zhǔn)主要體現(xiàn)主機(jī)/存儲、系統(tǒng)平臺性能的局限性，將業(yè)務(wù)量、服務(wù)等級、IT系統(tǒng)性能統(tǒng)一規(guī)劃和管理，建立三者之間的關(guān)系模型。容量規(guī)劃有助于企業(yè)有效控制IT基礎(chǔ)設(shè)施的投入成本；并幫助企業(yè)(特別是電信運(yùn)營商、銀聯(lián)系統(tǒng))的IT系統(tǒng)的服務(wù)輸出能力。增強(qiáng)對短、中期投資的可預(yù)見性。IT投資成本IT服務(wù)提高投資回報率實(shí)施容量規(guī)劃意義何在？克服TPC-C、SPEC等國際標(biāo)準(zhǔn)主要體現(xiàn)主機(jī)/存儲43容量規(guī)劃的價值體現(xiàn)隱式價值顯式價值CapacityPlanning降低采購成本：對在建項目預(yù)先進(jìn)行容量規(guī)劃，確定最優(yōu)化的硬件資源配置并指導(dǎo)投資預(yù)算；找出未充分利用的資源和容量，以便指導(dǎo)業(yè)務(wù)系統(tǒng)合并或者將其它業(yè)務(wù)系統(tǒng)加入進(jìn)來。節(jié)約維護(hù)成本：在約5年的硬件資源有效期內(nèi)，系統(tǒng)維護(hù)、配置、升級等方面的費(fèi)用要高于硬件的購買投資，容量規(guī)劃幫助成比例的降低了這些附加成本。減少人力資源成本：容量規(guī)劃幫助合理分配IT硬件資源，從而也會幫助組建合理的IT團(tuán)隊，以降低人力成本。

增強(qiáng)IT系統(tǒng)可靠性：減少資源或容量的過度冗余，會減少風(fēng)險節(jié)點(diǎn)，從而降低風(fēng)險轉(zhuǎn)變成災(zāi)難的概率；

準(zhǔn)確預(yù)測資源或容量的過度負(fù)載時間點(diǎn)，降低宕機(jī)概率。提高IT系統(tǒng)可用性：通過短期、不間斷的容量規(guī)劃，及時監(jiān)控服務(wù)質(zhì)量要求和響應(yīng)時間的差距，提前采取措施，避免因服務(wù)質(zhì)量降低導(dǎo)致的客戶不滿。

降低IT投資成本&提高IT的QoS5容量規(guī)劃的價值體現(xiàn)隱式價值顯式價值CapacityPla系統(tǒng)遷移。通過在測試環(huán)境下的有效性能監(jiān)控，建立業(yè)務(wù)量、服務(wù)等級、IT硬件資源三者之間的容量基準(zhǔn)模型，通過what-if分析業(yè)務(wù)量變化時的資源需求和性能表現(xiàn)，有效控制IT系統(tǒng)運(yùn)營環(huán)境下的軟硬件資源成本。系統(tǒng)的擴(kuò)容改造。通過在運(yùn)維期內(nèi)的有效性能監(jiān)控，收集系統(tǒng)在運(yùn)營期的性能數(shù)據(jù)，建立業(yè)務(wù)量、服務(wù)等級、IT資源三者之間的容量模型，分析未來不同時間（例如6個月內(nèi)、1年內(nèi)等）的資源需求和性能表現(xiàn)，為IT系統(tǒng)的擴(kuò)容提供依據(jù)，并對IT系統(tǒng)的性能進(jìn)行有效的監(jiān)控和預(yù)警。

系統(tǒng)遷移系統(tǒng)擴(kuò)容改造何時？何處？實(shí)施容量規(guī)劃系統(tǒng)遷移。通過在測試環(huán)境下的有效性能監(jiān)控，建立業(yè)務(wù)量、服務(wù)等45容量規(guī)劃時機(jī)需求開發(fā)上線運(yùn)維系統(tǒng)架構(gòu)確定開發(fā)環(huán)境代碼測試功能測試性能測試系統(tǒng)測試系統(tǒng)調(diào)優(yōu)系統(tǒng)監(jiān)控

需求(擴(kuò)容)容量規(guī)劃容量規(guī)劃上線容量規(guī)劃擴(kuò)容容量規(guī)劃7容量規(guī)劃時機(jī)需求開發(fā)上線運(yùn)維系統(tǒng)架構(gòu)代碼測試系統(tǒng)測試系統(tǒng)監(jiān)46容量規(guī)劃的前提條件上線容量規(guī)劃擴(kuò)容容量規(guī)劃對測試環(huán)境的要求性能調(diào)優(yōu)后收集容量規(guī)劃的基礎(chǔ)數(shù)據(jù)：即確保應(yīng)用每個組件（Web、DB等）的瓶頸都在于硬件平臺，即每個組件都可能因為壓力的增加而使CPU或內(nèi)存的利用率接近100；測試環(huán)境中DB的數(shù)據(jù)量要基本和現(xiàn)網(wǎng)一致，否則結(jié)果會有偏差；在測試中如果發(fā)現(xiàn)各組件間系統(tǒng)資源占用情況差別過大（如DBCPU100％時WebCPU10％），應(yīng)調(diào)整測試環(huán)境；盡量保證測試環(huán)境和上線環(huán)境的硬件平臺有相同的技術(shù)架構(gòu)。對應(yīng)用系統(tǒng)運(yùn)行環(huán)境的要求確認(rèn)網(wǎng)絡(luò)不是造成響應(yīng)時間過長的原因假設(shè)應(yīng)用系統(tǒng)處在最優(yōu)狀態(tài)（如果瓶頸在應(yīng)用系統(tǒng)，容量規(guī)劃的結(jié)果會有較大的誤差）；準(zhǔn)確統(tǒng)計目前的業(yè)務(wù)量，作為容量規(guī)劃建模的輸入數(shù)據(jù)，業(yè)務(wù)量偏差大會導(dǎo)致不能和實(shí)際的性能表現(xiàn)相匹配；8容量規(guī)劃的前提條件上線容量規(guī)劃擴(kuò)容容量規(guī)劃對測試環(huán)境的要求性能監(jiān)控代理。客戶端軟件，安裝在每臺主機(jī)上，收集并存儲主機(jī)的性能數(shù)據(jù)；根據(jù)容量規(guī)劃的要求，對性能數(shù)據(jù)進(jìn)行統(tǒng)計分析。提供性能數(shù)據(jù)導(dǎo)出工具；用戶可以通過web頁面展現(xiàn)系統(tǒng)的性能變化曲線。容量監(jiān)控/管理工具。服務(wù)器端軟件，匯總各代理收集的性能數(shù)據(jù)，建立業(yè)務(wù)系統(tǒng)的動態(tài)性能模型，對主機(jī)的性能、硬件資源進(jìn)行動態(tài)的監(jiān)控和管理，可以設(shè)置閾值在設(shè)定的條件下實(shí)現(xiàn)預(yù)警。

容量建模工具。根據(jù)采集的性能數(shù)據(jù)建立系統(tǒng)性能容量模型，使用系統(tǒng)容量模型進(jìn)行假設(shè)性問題試驗,事先了解應(yīng)用系統(tǒng)環(huán)境的變化對應(yīng)用系統(tǒng)部署、服務(wù)器的整合、業(yè)務(wù)擴(kuò)展或增加工作負(fù)荷所產(chǎn)生的影響，從而對系統(tǒng)容量規(guī)劃作出正確的決策。容量建模工具容量監(jiān)控/管理工具IBMHost性能監(jiān)控代理SunHost性能監(jiān)控代理HPHost性能監(jiān)控代理windows性能監(jiān)控代理容量規(guī)劃架構(gòu)性能監(jiān)控代理。客戶端軟件，安裝在每臺主機(jī)上，收集并存儲主機(jī)的48容量規(guī)劃的基本過程理解業(yè)務(wù)最大的應(yīng)用/負(fù)載業(yè)務(wù)量的增長幅度2.劃分主機(jī)負(fù)載a.定義workload b.workload的服務(wù)方式3.分析當(dāng)前系統(tǒng)容量

a.測量所有的應(yīng)用資源

b.使用workload測量應(yīng)用資源

c.確定硬件系統(tǒng)各部分的反應(yīng)時間4.系統(tǒng)中/遠(yuǎn)期預(yù)測

a.確定未來系統(tǒng)的資源配置需求

b.結(jié)合業(yè)務(wù)發(fā)展，規(guī)劃遠(yuǎn)期系統(tǒng)配置5．編制詳細(xì)性能報告10容量規(guī)劃的基本過程理解業(yè)務(wù)49

Step1：理解業(yè)務(wù)第一步工作負(fù)載workload是計算機(jī)系統(tǒng)上所有工作的邏輯分類，如果將計算機(jī)的工作想象成一塊大餅，那么每一個workload就是大餅的一塊扇區(qū)?？梢园凑找韵逻壿媽orkload進(jìn)行分類：

who：誰在工作？例如特定的用戶或組織

what：什么類型的工作？例如訂單處理，財務(wù)報表

how：如何做這些工作？在線查詢，批量數(shù)據(jù)備份

每個workload應(yīng)具備業(yè)務(wù)敏感度，也就是說業(yè)務(wù)量的增加或減少和workload的性能表現(xiàn)有較明顯的相關(guān)性；不管以何種邏輯劃分workload，都應(yīng)找出每個workload的相關(guān)業(yè)務(wù)指標(biāo)，并用業(yè)務(wù)語言描述和定義該指標(biāo)。第二步工作單元第三步服務(wù)等級將工作單元和workload聯(lián)系起來，與完成某項工作而消耗的系統(tǒng)資源的數(shù)量類似，工作單元是一類可量化的變量，只不過需要用業(yè)務(wù)語言來描述。工作單元可以看成為workload而設(shè)定的幾個可量化的參數(shù)，其數(shù)值的變化代表了workload對資源消耗的變化。例如：1、應(yīng)用的交易事務(wù)數(shù)量2、連接數(shù)據(jù)庫的用戶數(shù)3、呼叫中心處理的呼叫次數(shù)4、帳務(wù)中心的訂單處理數(shù)量都可以作為工作單元。服務(wù)等級協(xié)議由服務(wù)提供者和服務(wù)消費(fèi)者雙方制定，定義一個在服務(wù)消費(fèi)者接受范圍內(nèi)的服務(wù)，一般通過響應(yīng)時間和吞吐量來描述服務(wù)等級。簽訂服務(wù)等級協(xié)議時最好按照workload，理由是workload類似與性能和業(yè)務(wù)量之間的紐帶，有很大的相關(guān)性；而且workload中工作單元的數(shù)值大小對業(yè)務(wù)量變化具備相當(dāng)?shù)拿舾卸?。比如對一個預(yù)約應(yīng)用系統(tǒng)，我們可以這樣定義其服務(wù)等級：1、一小時內(nèi)能夠處理的電話預(yù)約數(shù)量不少于200個；2、每一個預(yù)約需在30秒內(nèi)完成；3、每一個預(yù)約請求在隊列中的等待時間不能超過60秒。

11Step1：理解業(yè)務(wù)第一步工作負(fù)載wo50Step1：理解業(yè)務(wù)系統(tǒng)(System)工作負(fù)載(Workload)工作單元(Unitofwork)資源(Resource)SAP主機(jī)財務(wù)模塊活動用戶數(shù)每個工作單元對多個資源都有消耗CPU業(yè)務(wù)處理數(shù)I/OTuxedo服務(wù)器查詢模塊事務(wù)數(shù)Memory取款模塊事務(wù)數(shù)Networkconnection……店面(System)部門(Workload)業(yè)務(wù)指標(biāo)(Unitofwork)資源(Resource)快餐店廚房食物重量每個業(yè)務(wù)指標(biāo)對多個資源都有消耗雞蛋每天生產(chǎn)三明治數(shù)量生肉大廳就餐的顧客數(shù)量泡菜切片……面粉asopposedto對比12Step1：理解業(yè)務(wù)系統(tǒng)工作負(fù)載工作單元資源SAP主機(jī)活51Step2：劃分workload類型解釋Batch用于mainframe結(jié)構(gòu)的主機(jī)容量規(guī)劃，該環(huán)境下沒有用戶，workload根據(jù)預(yù)先定義的schedule啟動/停止/休眠，即有處理任務(wù)就啟動，沒有就休眠直到有新的處理任務(wù)。Process用于opensystem結(jié)構(gòu)的主機(jī)，即適用于小型機(jī)和pc機(jī)。Interactive有用戶參與，并且一般用戶通過終端連接，執(zhí)行一些交互性的工作。例如用戶對oracle數(shù)據(jù)庫發(fā)出請求。Transaction多個進(jìn)程一起執(zhí)行事務(wù)，transaction不是由某一個用戶發(fā)起或者執(zhí)行，這是和interactive差異的地方。13Step2：劃分workload類型解釋Batch用于m52Step3：收集數(shù)據(jù)上線容量規(guī)劃擴(kuò)容容量規(guī)劃通過性能測試收集業(yè)務(wù)數(shù)據(jù)和性能數(shù)據(jù)業(yè)務(wù)數(shù)據(jù)：通過性能測試階段指定的加壓方式和測試策略，收集業(yè)務(wù)數(shù)據(jù)性能數(shù)據(jù)：收集不同負(fù)載測試時的性能數(shù)據(jù)，作為容量規(guī)劃的原始數(shù)據(jù)。通過業(yè)務(wù)統(tǒng)計和系統(tǒng)監(jiān)控收集數(shù)據(jù)業(yè)務(wù)數(shù)據(jù):通過業(yè)務(wù)量統(tǒng)計或其它監(jiān)控方法，收集業(yè)務(wù)數(shù)據(jù)。性能數(shù)據(jù)：通過實(shí)時監(jiān)控收集性能數(shù)據(jù)14Step3：收集數(shù)據(jù)上線容量規(guī)劃擴(kuò)容容量規(guī)劃通過性能測試53Step4：模型分析模型基礎(chǔ)數(shù)據(jù)：根據(jù)當(dāng)前的性能數(shù)據(jù)，建立性能benchmark，作為模型分析的基礎(chǔ)。趨勢分析不同的業(yè)務(wù)增長量What-if分析MVAP模型Simulation模型按照計算模型的差異，可以建立的模型包括：單機(jī)模型改變硬件配置Multi-tier模型改變各層的硬件配置；改變各層的主機(jī)數(shù)量按照應(yīng)用系統(tǒng)的類型，可以建立的模型包括：模型分析時能夠定義的資源：CPUDiskDiskcontroller模型分析時可以改變的參數(shù)：業(yè)務(wù)增長量Workload類型Disk間的I/O平衡……15Step4：模型分析模型基礎(chǔ)數(shù)據(jù)：根據(jù)當(dāng)前的性能數(shù)據(jù)，建54Step5：結(jié)果報告結(jié)果報告：容量規(guī)劃最終將為硬件采購提供必要的依據(jù)，在預(yù)先制定的業(yè)務(wù)目標(biāo)前提下，給出最佳的硬件配置方案。一般情況下，對平均負(fù)載的模型分析以及對峰值負(fù)載的模型分析，都需要實(shí)施。

16Step5：結(jié)果報告結(jié)果報告：55謝謝！(后附容量規(guī)劃案例)結(jié)束17謝謝！結(jié)束56

案例—SAP系統(tǒng)容量規(guī)劃通過容量規(guī)劃預(yù)測兩年內(nèi)的性能表現(xiàn)，回答以下幾個問題：為了滿足平均負(fù)載，系統(tǒng)需要在什么時候擴(kuò)容？擴(kuò)多少資源？為了滿足峰值負(fù)載，系統(tǒng)需要在什么時候擴(kuò)容？擴(kuò)多少資源？過程：理解業(yè)務(wù)：估算業(yè)務(wù)量劃分負(fù)載(workload)：從業(yè)務(wù)上對引起應(yīng)用/負(fù)載的活動進(jìn)行分類采集數(shù)據(jù)：平均負(fù)載下的性能數(shù)據(jù)；峰值負(fù)載下的性能數(shù)據(jù)建模分析:趨勢分析,What-if分析建議:回答假設(shè)性問題18案例—SAP系統(tǒng)容量規(guī)劃過程：575

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量應(yīng)用/負(fù)載代表了sap系統(tǒng)的業(yè)務(wù)量，根據(jù)和sap系統(tǒng)和業(yè)務(wù)人員的討論，并從業(yè)務(wù)角度來描述，業(yè)務(wù)量受到兩個主要因素的影響：活動用戶數(shù)；用戶的平均業(yè)務(wù)處理量

用戶數(shù)和業(yè)務(wù)處理量的增加，必然帶動業(yè)務(wù)量的增長。反映到SAP應(yīng)用系統(tǒng)，必然需要更多的硬件資源用于業(yè)務(wù)處理，通過對兩個自變量在IT系統(tǒng)的功能映射分析，我們可以確定：用戶數(shù)增加需要SAP應(yīng)用系統(tǒng)和Oracle數(shù)據(jù)庫相應(yīng)啟動更多的進(jìn)程，以增加業(yè)務(wù)處理能力，TeamQuest容量規(guī)劃中的Population就代表了某一時刻SAP用戶和oracle用戶啟動的進(jìn)程數(shù)量，因此進(jìn)程數(shù)的增長趨勢可以較好的模擬用戶數(shù)引起業(yè)務(wù)量增長的趨勢。用戶操作數(shù)的增加需要計算機(jī)處理更多的用戶請求，表現(xiàn)在硬件層面上即計算機(jī)的CPU、Memory、DISK需要處理更多的機(jī)器指令，TeamQuest容量規(guī)劃中的visitsatactiveresource的值就代表了一個用戶的業(yè)務(wù)操作數(shù)，因此visits值的增長趨勢可以較好的模擬用戶操作數(shù)引起的業(yè)務(wù)量增長趨勢。

ID業(yè)務(wù)量因子(工作單元)模型中對應(yīng)的變量1活動用戶數(shù)Population2平均業(yè)務(wù)處理量Visitsatactiveresource

案例—SAP系統(tǒng)容量規(guī)劃195結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)585

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量由于業(yè)務(wù)每月增長量暫時缺乏精確的統(tǒng)計數(shù)據(jù)，本次案例暫時通過假設(shè)設(shè)定一個增長比例：負(fù)載類型Population(活動用戶數(shù))Visitsatactiveresource(處理請求數(shù))平均負(fù)載SAP系統(tǒng)10%10%Oracle數(shù)據(jù)庫10%10%峰值負(fù)載SAP系統(tǒng)5%5%Oracle數(shù)據(jù)庫5%5%本次預(yù)測“2年”內(nèi)的業(yè)務(wù)滿足程度，設(shè)計24步（step），每step代表一個月，上表為假設(shè)的業(yè)務(wù)量每月的變化。

案例—SAP系統(tǒng)容量規(guī)劃205結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)59機(jī)器Workloads備注Sapapp1r3padmuserhpOpenViewrootexceptOpenViewusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenViewSapapp2r3padmuserhpOpenViewrootexceptOpenViewusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenViewSapDBSapDBorar3pr3padmuserhpOpenViewrootexceptOpenViewusedbyorar3pusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenView5

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量根據(jù)業(yè)務(wù)類型劃分工作負(fù)載

案例—SAP系統(tǒng)容量規(guī)劃21機(jī)器Workloads備注Sapapp1r3padmu605

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量Sap系統(tǒng)在每月25～下月5日業(yè)務(wù)比較繁忙，本次建模就在該時間段內(nèi)收集數(shù)據(jù)，由于該時間段的性能表現(xiàn)有一定的代表性，所以對系統(tǒng)擴(kuò)容有一定的參考意義。經(jīng)過篩選，確定選取2006-5-268:20~17:20之間共9個小時的數(shù)據(jù)段：對平均負(fù)載性能數(shù)據(jù)，以10分鐘作為數(shù)據(jù)聚合尺度；(保證計算出精確的平均值)；對峰值負(fù)載性能數(shù)據(jù)，以1小時作為數(shù)據(jù)聚合尺度。（真正反映業(yè)務(wù)峰值，而不是瞬時性能峰值）。

確定采集段數(shù)據(jù)聚合尺度生成abr文件

案例—SAP系統(tǒng)容量規(guī)劃225結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)615

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.29%lessthan.011.01lessthan.01hpOpenViewlessthan.01%lessthan.012.00lessthan.01r3padmuser32.55%4.7945.24lessthan.01rootexceptOpenView0.31%5.13134.08lessthan.01WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.42%0.001.02lessthan.01hpOpenViewlessthan.01%lessthan.012.00lessthan.01r3padmuser81.44%4.7645.010.08rootexceptOpenView0.27%5.45135.030.22SapApp1峰值負(fù)載平均負(fù)載

案例—SAP系統(tǒng)容量規(guī)劃235結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)625

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.38%lessthan.011.02lessthan.01hpOpenView24.97%lessthan.012.00lessthan.01r3padmuser15.41%2.8240.00lessthan.01rootexceptOpenView0.13%4.99132.08lessthan.01WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.36%0.001.01lessthan.01hpOpenView24.98%lessthan.012.00lessthan.01r3padmuser25.49%2.4340.000.01rootexceptOpenView0.14%6.00133.010.04SapApp2峰值負(fù)載平均負(fù)載

案例—SAP系統(tǒng)容量規(guī)劃245結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)635

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.18%0.001.01lessthan.01hpOpenViewlessthan.01%lessthan.012.00lessthan.01r3padmuser0.02%0.013.00lessthan.01rootexceptOpenView0.34%5.07134.10lessthan.01sapdborar3p45.39%610.4978.99lessthan.01WorkloadNameCPUUtilizationI/OspersecondPopulationThroughputOTHER0.40%0.001.02lessthan.01hpOpenViewlessthan.01%0.012.00lessthan.01r3padmuser0.02%0.023.00lessthan.01rootexceptOpenView0.37%6.33134.970.04sapdborar3p82.31%938.1678.980.02SapDB峰值負(fù)載平均負(fù)載

案例—SAP系統(tǒng)容量規(guī)劃255結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)645

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量在建模階段，需要IT人員提供的數(shù)據(jù)包括：主機(jī)/存儲的CPU、diskcontroller、disk的類型或者性能參數(shù)；對每臺主機(jī)平均負(fù)載、峰值負(fù)載單獨(dú)建立并校驗model，模型分析的思路：首先正確匹配硬件資源類型，保存為baseline模型；平均負(fù)載按照每月10％業(yè)務(wù)量增長，峰值負(fù)載按照每月5％業(yè)務(wù)量增長，分別進(jìn)行趨勢分析；如果在某些硬件資源處形成瓶頸，增加該資源，進(jìn)行what-if分析。

案例—SAP系統(tǒng)容量規(guī)劃265結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)655

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1平均負(fù)載_趨勢分析AVG(4CPU)Step:16Step:17Step:18Step:19Step:20StretchFactors1.501.641.842.142.55CPUUtilization80.2683.1385.8288.2590.34分析結(jié)果：

在step16～step18之間，即平均CPU利用率在80.3%~85.8%之間時，為了滿足平均業(yè)務(wù)量需求，應(yīng)考慮對系統(tǒng)進(jìn)行擴(kuò)容。

案例—SAP系統(tǒng)容量規(guī)劃275結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)665

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_趨勢分析分析結(jié)果：PEAK（4CPU）Step1Step2Step3Step4Step5StretchFactors1.511.671.892.172.51CPUUtilization81.4484.5287.1889.3491.05在step1～step3之間，為了滿足峰值業(yè)務(wù)處理，應(yīng)考慮對系統(tǒng)進(jìn)行擴(kuò)容；在第24step之前，必須考慮對CPU進(jìn)行擴(kuò)容，以防系統(tǒng)崩潰不再提供服務(wù)，或者CPU過于繁忙導(dǎo)致不能正常返回響應(yīng)。

案例—SAP系統(tǒng)容量規(guī)劃285結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)675

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_what-if分析分析結(jié)果：PEAK（8CPU）Step20Step21Step22Step23Step24StretchFactors1.271.331.411.511.64CPUUtilization86.3388.1389.7891.2592.49

增加4個CPU后，在未來24個月內(nèi)，硬件資源可以較好的滿足業(yè)務(wù)需要。

案例—SAP系統(tǒng)容量規(guī)劃295結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)685

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1平均負(fù)載_趨勢分析分析結(jié)果：AVG（4CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.171.191.201.221.241.27CPUUtilization43.0844.6146.1347.6649.1850.70

未來24個月內(nèi)，硬件資源可以較好的滿足均值業(yè)務(wù)需要。

案例—SAP系統(tǒng)容量規(guī)劃305結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)695

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1峰值負(fù)載_趨勢分析分析結(jié)果：PEAK（4CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.231.251.271.291.311.33CPUUtilization48.1449.3950.6351.8753.1154.34

未來24個月內(nèi)，硬件資源可以較好的滿足峰值業(yè)務(wù)需要。

案例—SAP系統(tǒng)容量規(guī)劃315結(jié)果4模型分析3采集數(shù)據(jù)2劃分負(fù)載1估算業(yè)務(wù)705

結(jié)果4

模型分析3

采集數(shù)據(jù)2

劃分負(fù)載1

估算業(yè)務(wù)量SapDBSapApp2SapApp1平均負(fù)載_趨勢分析分析結(jié)果：AVG（4CPU）Step8Step9Step10Step11Step12StretchFactors1.351.471.662.002.55CPUUtilization76.5880.7984.8088.4091.37在step10～step11之間，即平均CPU利用率在84%~88%之間時，為了滿足Oracle用戶的業(yè)務(wù)處理需求，應(yīng)考慮對系統(tǒng)進(jìn)行擴(kuò)容。在step20時，數(shù)據(jù)庫對用戶的請求將不能正常返回響應(yīng)，即在第step20之前，必須考慮對系統(tǒng)進(jìn)行升級。

案例—SAP