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

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