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

主機(jī)性能容量規(guī)劃實(shí)施辦法,作者：Tony Shi Email：tony26600882 歡迎通過(guò)郵件交流,2,容量規(guī)劃能夠解決的問(wèn)題,為了能準(zhǔn)確反映業(yè)務(wù)量和性能之間的函數(shù)關(guān)系，應(yīng)為不同類型的業(yè)務(wù)系統(tǒng)規(guī)劃相應(yīng)的監(jiān)控指標(biāo)，這是生成容量基準(zhǔn)模型的必要條件。 通過(guò)有效監(jiān)控可以提供準(zhǔn)確的性能數(shù)據(jù)。,IT系統(tǒng)主要的資源包括CPU、內(nèi)存、磁盤/磁盤控制器三大類。因此，由于資源數(shù)量、單個(gè)資源不同體系架構(gòu)的影響，需要將影響性能的資源的數(shù)學(xué)關(guān)系公式和經(jīng)驗(yàn)值有效結(jié)合在模型中，才能進(jìn)行有效的性能趨勢(shì)和假設(shè)性分析。,不同的應(yīng)用系統(tǒng)的業(yè)務(wù)量估算有不同方法和流程。,容量規(guī)劃的主要工作,克服TPC-C、SPEC等國(guó)際標(biāo)準(zhǔn)主要體現(xiàn)主機(jī)/存儲(chǔ)、系統(tǒng)平臺(tái)性能的局限性，將業(yè)務(wù)量、服務(wù)等級(jí)、IT系統(tǒng)性能統(tǒng)一規(guī)劃和管理，建立三者之間的關(guān)系模型。容量規(guī)劃有助于企業(yè)有效控制IT基礎(chǔ)設(shè)施的投入成本；并幫助企業(yè)(特別是電信運(yùn)營(yíng)商、銀聯(lián)系統(tǒng))的IT系統(tǒng)的服務(wù)輸出能力。,增強(qiáng)對(duì)短、中期投資的可預(yù)見(jiàn)性。,實(shí)施容量規(guī)劃意義何在？,5,容量規(guī)劃的價(jià)值體現(xiàn),隱式價(jià)值,顯式價(jià)值,Capacity Planning,降低采購(gòu)成本： 對(duì)在建項(xiàng)目預(yù)先進(jìn)行容量規(guī)劃，確定最優(yōu)化的硬件資源配置并指導(dǎo)投資預(yù)算； 找出未充分利用的資源和容量，以便指導(dǎo)業(yè)務(wù)系統(tǒng)合并或者將其它業(yè)務(wù)系統(tǒng)加入進(jìn)來(lái) 。 節(jié)約維護(hù)成本： 在約5年的硬件資源有效期內(nèi)，系統(tǒng)維護(hù)、配置、升級(jí)等方面的費(fèi)用要高于硬件的購(gòu)買投資，容量規(guī)劃幫助成比例的降低了這些附加成本。 減少人力資源成本 ： 容量規(guī)劃幫助合理分配IT硬件資源，從而也會(huì)幫助組建合理的IT團(tuán)隊(duì)，以降低人力成本。,增強(qiáng)IT系統(tǒng)可靠性： 減少資源或容量的過(guò)度冗余，會(huì)減少風(fēng)險(xiǎn)節(jié)點(diǎn)，從而降低風(fēng)險(xiǎn)轉(zhuǎn)變成災(zāi)難的概率； 準(zhǔn)確預(yù)測(cè)資源或容量的過(guò)度負(fù)載時(shí)間點(diǎn)，降低宕機(jī)概率。 提高IT系統(tǒng)可用性： 通過(guò)短期、不間斷的容量規(guī)劃，及時(shí)監(jiān)控服務(wù)質(zhì)量要求和響應(yīng)時(shí)間的差距，提前采取措施，避免因服務(wù)質(zhì)量降低導(dǎo)致的客戶不滿。,系統(tǒng)遷移。通過(guò)在測(cè)試環(huán)境下的有效性能監(jiān)控，建立業(yè)務(wù)量、服務(wù)等級(jí)、IT硬件資源三者之間的容量基準(zhǔn)模型，通過(guò)what-if分析業(yè)務(wù)量變化時(shí)的資源需求和性能表現(xiàn)，有效控制IT系統(tǒng)運(yùn)營(yíng)環(huán)境下的軟硬件資源成本。 系統(tǒng)的擴(kuò)容改造。通過(guò)在運(yùn)維期內(nèi)的有效性能監(jiān)控，收集系統(tǒng)在運(yùn)營(yíng)期的性能數(shù)據(jù)，建立業(yè)務(wù)量、服務(wù)等級(jí)、IT資源三者之間的容量模型，分析未來(lái)不同時(shí)間（例如6個(gè)月內(nèi)、1年內(nèi)等）的資源需求和性能表現(xiàn)，為IT系統(tǒng)的擴(kuò)容提供依據(jù)，并對(duì)IT系統(tǒng)的性能進(jìn)行有效的監(jiān)控和預(yù)警。,系統(tǒng)遷移,系統(tǒng)擴(kuò)容改造,何時(shí)？何處？實(shí)施容量規(guī)劃,7,容量規(guī)劃時(shí)機(jī),需求,開(kāi)發(fā),上線,運(yùn)維,系統(tǒng)架構(gòu) 確定開(kāi)發(fā)環(huán)境,代碼測(cè)試 功能測(cè)試 性能測(cè)試,系統(tǒng)測(cè)試 系統(tǒng)調(diào)優(yōu),系統(tǒng)監(jiān)控,需求(擴(kuò)容),容量規(guī)劃,容量規(guī)劃,上線容量規(guī)劃 擴(kuò)容容量規(guī)劃,8,容量規(guī)劃的前提條件,性能監(jiān)控代理?？蛻舳塑浖?，安裝在每臺(tái)主機(jī)上，收集并存儲(chǔ)主機(jī)的性能數(shù)據(jù)；根據(jù)容量規(guī)劃的要求，對(duì)性能數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析。提供性能數(shù)據(jù)導(dǎo)出工具；用戶可以通過(guò)web頁(yè)面展現(xiàn)系統(tǒng)的性能變化曲線。 容量監(jiān)控/管理工具。服務(wù)器端軟件，匯總各代理收集的性能數(shù)據(jù)，建立業(yè)務(wù)系統(tǒng)的動(dòng)態(tài)性能模型，對(duì)主機(jī)的性能、硬件資源進(jìn)行動(dòng)態(tài)的監(jiān)控和管理，可以設(shè)置閾值在設(shè)定的條件下實(shí)現(xiàn)預(yù)警。 容量建模工具。根據(jù)采集的性能數(shù)據(jù)建立系統(tǒng)性能容量模型，使用系統(tǒng)容量模型進(jìn)行假設(shè)性問(wèn)題試驗(yàn),事先了解應(yīng)用系統(tǒng)環(huán)境的變化對(duì)應(yīng)用系統(tǒng)部署、服務(wù)器的整合、業(yè)務(wù)擴(kuò)展或增加工作負(fù)荷所產(chǎn)生的影響，從而對(duì)系統(tǒng)容量規(guī)劃作出正確的決策。,容量建模工具,容量監(jiān)控/管理工具,IBM Host 性能監(jiān)控代理,Sun Host 性能監(jiān)控代理,HP Host 性能監(jiān)控代理,windows 性能監(jiān)控代理,容量規(guī)劃架構(gòu),10,容量規(guī)劃的基本過(guò)程,理解業(yè)務(wù) 最大的應(yīng)用/負(fù)載 業(yè)務(wù)量的增長(zhǎng)幅度 2. 劃分主機(jī)負(fù)載 a. 定義workload b. workload的服務(wù)方式 3. 分析當(dāng)前系統(tǒng)容量 a. 測(cè)量所有的應(yīng)用資源 b. 使用workload 測(cè)量應(yīng)用資源 c. 確定硬件系統(tǒng)各部分的反應(yīng)時(shí)間 4. 系統(tǒng)中/遠(yuǎn)期預(yù)測(cè) a. 確定未來(lái)系統(tǒng)的資源配置需求 b. 結(jié)合業(yè)務(wù)發(fā)展，規(guī)劃遠(yuǎn)期系統(tǒng)配置 5編制詳細(xì)性能報(bào)告,11,Step1：理解業(yè)務(wù),workload是計(jì)算機(jī)系統(tǒng)上所有工作的邏輯分類，如果將計(jì)算機(jī)的工作想象成一塊大餅，那么每一個(gè)workload就是大餅的一塊扇區(qū)。 可以按照以下邏輯對(duì)workload進(jìn)行分類： who：誰(shuí)在工作？例如特定的用戶或組織 what：什么類型的工作？例如訂單處理，財(cái)務(wù)報(bào)表 how：如何做這些工作？ 在線查詢，批量數(shù)據(jù)備份 每個(gè)workload應(yīng)具備業(yè)務(wù)敏感度，也就是說(shuō)業(yè)務(wù)量的增加或減少和workload的性能表現(xiàn)有較明顯的相關(guān)性； 不管以何種邏輯劃分workload，都應(yīng)找出每個(gè)workload的相關(guān)業(yè)務(wù)指標(biāo)，并用業(yè)務(wù)語(yǔ)言描述和定義該指標(biāo)。,將工作單元和workload聯(lián)系起來(lái)，與完成某項(xiàng)工作而消耗的系統(tǒng)資源的數(shù)量類似，工作單元是一類可量化的變量，只不過(guò)需要用業(yè)務(wù)語(yǔ)言來(lái)描述。 工作單元可以看成為workload而設(shè)定的幾個(gè)可量化的參數(shù)，其數(shù)值的變化代表了workload對(duì)資源消耗的變化。 例如： 1、應(yīng)用的交易事務(wù)數(shù)量 2、連接數(shù)據(jù)庫(kù)的用戶數(shù) 3、呼叫中心處理的呼叫次數(shù) 4、帳務(wù)中心的訂單處理數(shù)量 都可以作為工作單元。,服務(wù)等級(jí)協(xié)議由服務(wù)提供者和服務(wù)消費(fèi)者雙方制定，定義一個(gè)在服務(wù)消費(fèi)者接受范圍內(nèi)的服務(wù)，一般通過(guò)響應(yīng)時(shí)間和吞吐量來(lái)描述服務(wù)等級(jí)。簽訂服務(wù)等級(jí)協(xié)議時(shí)最好按照workload，理由是workload類似與性能和業(yè)務(wù)量之間的紐帶，有很大的相關(guān)性；而且workload中工作單元的數(shù)值大小對(duì)業(yè)務(wù)量變化具備相當(dāng)?shù)拿舾卸取?比如對(duì)一個(gè)預(yù)約應(yīng)用系統(tǒng)，我們可以這樣定義其服務(wù)等級(jí)： 1、一小時(shí)內(nèi)能夠處理的電話預(yù)約數(shù)量不少于200個(gè)； 2、每一個(gè)預(yù)約需在30秒內(nèi)完成； 3、每一個(gè)預(yù)約請(qǐng)求在隊(duì)列中的等待時(shí)間不能超過(guò)60秒。,12,Step1：理解業(yè)務(wù),as opposed to 對(duì)比,13,Step2：劃分workload,14,Step3：收集數(shù)據(jù),15,Step4：模型分析,模型基礎(chǔ)數(shù)據(jù)：根據(jù)當(dāng)前的性能數(shù)據(jù)，建立性能benchmark，作為模型分析的基礎(chǔ)。,模型分析時(shí)能夠定義的資源： CPU Disk Disk controller 模型分析時(shí)可以改變的參數(shù)： 業(yè)務(wù)增長(zhǎng)量 Workload類型 Disk間的I/O平衡 ,16,Step5：結(jié)果報(bào)告,結(jié)果報(bào)告： 容量規(guī)劃最終將為硬件采購(gòu)提供必要的依據(jù)，在預(yù)先制定的業(yè)務(wù)目標(biāo)前提下，給出最佳的硬件配置方案。 一般情況下，對(duì)平均負(fù)載的模型分析以及對(duì)峰值負(fù)載的模型分析，都需要實(shí)施。,17,謝謝！ (后附容量規(guī)劃案例),結(jié) 束,18,案例SAP系統(tǒng)容量規(guī)劃,通過(guò)容量規(guī)劃預(yù)測(cè)兩年內(nèi)的性能表現(xiàn)，回答以下幾個(gè)問(wèn)題： 為了滿足平均負(fù)載，系統(tǒng)需要在什么時(shí)候擴(kuò)容？擴(kuò)多少資源？ 為了滿足峰值負(fù)載，系統(tǒng)需要在什么時(shí)候擴(kuò)容？擴(kuò)多少資源？,過(guò)程： 理解業(yè)務(wù)：估算業(yè)務(wù)量 劃分負(fù)載(workload)：從業(yè)務(wù)上對(duì)引起應(yīng)用/負(fù)載的活動(dòng)進(jìn)行分類 采集數(shù)據(jù)：平均負(fù)載下的性能數(shù)據(jù)；峰值負(fù)載下的性能數(shù)據(jù) 建模分析:趨勢(shì)分析,What-if分析 建議:回答假設(shè)性問(wèn)題,19,5 結(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ù)角度來(lái)描述，業(yè)務(wù)量受到兩個(gè)主要因素的影響：活動(dòng)用戶數(shù)； 用戶的平均業(yè)務(wù)處理量,用戶數(shù)和業(yè)務(wù)處理量的增加，必然帶動(dòng)業(yè)務(wù)量的增長(zhǎng)。反映到SAP應(yīng)用系統(tǒng)，必然需要更多的硬件資源用于業(yè)務(wù)處理，通過(guò)對(duì)兩個(gè)自變量在IT系統(tǒng)的功能映射分析，我們可以確定： 用戶數(shù)增加需要SAP應(yīng)用系統(tǒng)和Oracle數(shù)據(jù)庫(kù)相應(yīng)啟動(dòng)更多的進(jìn)程，以增加業(yè)務(wù)處理能力，TeamQuest容量規(guī)劃中的Population就代表了某一時(shí)刻SAP用戶和oracle用戶啟動(dòng)的進(jìn)程數(shù)量，因此進(jìn)程數(shù)的增長(zhǎng)趨勢(shì)可以較好的模擬用戶數(shù)引起業(yè)務(wù)量增長(zhǎng)的趨勢(shì)。 用戶操作數(shù)的增加需要計(jì)算機(jī)處理更多的用戶請(qǐng)求，表現(xiàn)在硬件層面上即計(jì)算機(jī)的CPU、Memory、DISK需要處理更多的機(jī)器指令，TeamQuest 容量規(guī)劃中的visits at active resource的值就代表了一個(gè)用戶的業(yè)務(wù)操作數(shù)，因此visits值的增長(zhǎng)趨勢(shì)可以較好的模擬用戶操作數(shù)引起的業(yè)務(wù)量增長(zhǎng)趨勢(shì)。,案例SAP系統(tǒng)容量規(guī)劃,20,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,由于業(yè)務(wù)每月增長(zhǎng)量暫時(shí)缺乏精確的統(tǒng)計(jì)數(shù)據(jù)，本次案例暫時(shí)通過(guò)假設(shè)設(shè)定一個(gè)增長(zhǎng)比例：,本次預(yù)測(cè)“2年”內(nèi)的業(yè)務(wù)滿足程度，設(shè)計(jì)24步（step），每step代表一個(gè)月，上表為假設(shè)的業(yè)務(wù)量每月的變化。,案例SAP系統(tǒng)容量規(guī)劃,21,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,根據(jù)業(yè)務(wù)類型劃分工作負(fù)載,案例SAP系統(tǒng)容量規(guī)劃,22,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,Sap系統(tǒng)在每月25下月5日業(yè)務(wù)比較繁忙，本次建模就在該時(shí)間段內(nèi)收集數(shù)據(jù)，由于該時(shí)間段的性能表現(xiàn)有一定的代表性，所以對(duì)系統(tǒng)擴(kuò)容有一定的參考意義。 經(jīng)過(guò)篩選，確定選取2006-5-26 8:2017:20之間共9個(gè)小時(shí)的數(shù)據(jù)段：,對(duì)平均負(fù)載性能數(shù)據(jù)，以10分鐘作為數(shù)據(jù)聚合尺度；(保證計(jì)算出精確的平均值)； 對(duì)峰值負(fù)載性能數(shù)據(jù)，以1小時(shí)作為數(shù)據(jù)聚合尺度。（真正反映業(yè)務(wù)峰值，而不是瞬時(shí)性能峰值）。,案例SAP系統(tǒng)容量規(guī)劃,23,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapApp1,峰值負(fù)載,平均負(fù)載,案例SAP系統(tǒng)容量規(guī)劃,24,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapApp2,峰值負(fù)載,平均負(fù)載,案例SAP系統(tǒng)容量規(guī)劃,25,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,峰值負(fù)載,平均負(fù)載,案例SAP系統(tǒng)容量規(guī)劃,26,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,在建模階段，需要IT人員提供的數(shù)據(jù)包括： 主機(jī)/存儲(chǔ)的CPU、disk controller、disk的類型或者性能參數(shù)；,對(duì)每臺(tái)主機(jī)平均負(fù)載、峰值負(fù)載單獨(dú)建立并校驗(yàn)model，模型分析的思路： 首先正確匹配硬件資源類型，保存為baseline模型； 平均負(fù)載按照每月10業(yè)務(wù)量增長(zhǎng)，峰值負(fù)載按照每月5業(yè)務(wù)量增長(zhǎng)，分別進(jìn)行趨勢(shì)分析； 如果在某些硬件資源處形成瓶頸，增加該資源，進(jìn)行what-if分析。,案例SAP系統(tǒng)容量規(guī)劃,27,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,平均負(fù)載_趨勢(shì)分析,在step16step18之間，即平均CPU利用率在80.3% 85.8%之間時(shí)，為了滿足平均業(yè)務(wù)量需求，應(yīng)考慮對(duì)系統(tǒng)進(jìn)行擴(kuò)容。,案例SAP系統(tǒng)容量規(guī)劃,28,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,峰值負(fù)載_趨勢(shì)分析,分析結(jié)果：,在step1step3之間，為了滿足峰值業(yè)務(wù)處理，應(yīng)考慮對(duì)系統(tǒng)進(jìn)行擴(kuò)容； 在第24 step之前，必須考慮對(duì)CPU進(jìn)行擴(kuò)容，以防系統(tǒng)崩潰不再提供服務(wù)，或者CPU過(guò)于繁忙導(dǎo)致不能正常返回響應(yīng)。,案例SAP系統(tǒng)容量規(guī)劃,29,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,峰值負(fù)載_what-if分析,分析結(jié)果：,增加4個(gè)CPU后，在未來(lái)24個(gè)月內(nèi)，硬件資源可以較好的滿足業(yè)務(wù)需要。,案例SAP系統(tǒng)容量規(guī)劃,30,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,平均負(fù)載_趨勢(shì)分析,分析結(jié)果：,未來(lái)24個(gè)月內(nèi)，硬件資源可以較好的滿足均值業(yè)務(wù)需要。,案例SAP系統(tǒng)容量規(guī)劃,31,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,峰值負(fù)載_趨勢(shì)分析,分析結(jié)果：,未來(lái)24個(gè)月內(nèi)，硬件資源可以較好的滿足峰值業(yè)務(wù)需要。,案例SAP系統(tǒng)容量規(guī)劃,32,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,平均負(fù)載_趨勢(shì)分析,分析結(jié)果：,在step10step11之間，即平均CPU利用率在84%88%之間時(shí)，為了滿足Oracle用戶的業(yè)務(wù)處理需求，應(yīng)考慮對(duì)系統(tǒng)進(jìn)行擴(kuò)容。 在step20時(shí)，數(shù)據(jù)庫(kù)對(duì)用戶的請(qǐng)求將不能正常返回響應(yīng)，即在第step20之前，必須考慮對(duì)系統(tǒng)進(jìn)行升級(jí)。,案例SAP系統(tǒng)容量規(guī)劃,33,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,平均負(fù)載_what-if分析,分析結(jié)果：,CPU不再是性能瓶頸，在24個(gè)月內(nèi)，硬件資源基本上可以較好的滿足業(yè)務(wù)需求； 磁盤I/O在后期會(huì)越來(lái)越繁忙，指令在磁盤處的排隊(duì)有逐漸增多的趨勢(shì)，在24個(gè)月后應(yīng)考慮優(yōu)化磁盤結(jié)構(gòu) 或者 更換更快的磁盤。,案例SAP系統(tǒng)容量規(guī)劃,34,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,峰值負(fù)載_趨勢(shì)分析,分析結(jié)果：,在step1step2之間，即平均CPU利用率在82%86%之間時(shí)，為滿足峰值業(yè)務(wù)處理需求，應(yīng)考慮對(duì)系統(tǒng)進(jìn)行擴(kuò)容。 在step17時(shí)(Stretch Factor值超過(guò)12)，數(shù)據(jù)庫(kù)對(duì)用戶的請(qǐng)求將不能正常返回響應(yīng)，即在第step17之前，必須考慮對(duì)系統(tǒng)進(jìn)行升級(jí)。,案例SAP系統(tǒng)容量規(guī)劃,35,5 結(jié)果,4 模型分析,3 采集數(shù)據(jù),2 劃分負(fù)載,1 估算業(yè)務(wù)量,SapDB,SapApp2,SapApp1,峰值負(fù)載_what-if分析,分析結(jié)果：,在step21step23之間，即平均CPU利用率在90% 93%之間時(shí)，為了滿足Oracle用戶的業(yè)務(wù)處理需求，應(yīng)考慮