计算机系统性能容量规划-实施办法-原创

主机性能容量规划实施办法作者：TonyShiEmail：tony26600882@欢迎通过邮件交流2容量规划能够解决的问题IT资源配置是否满足目前的业务需求？

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

未来6个月IT资源是否能够满足业务增长需要？

增加多少IT硬件资源，才能满足2年内的业务处理？

业务系统合并和拆分，如何配置硬件资源？

业务以每月5％增长时，什么时候需要IT扩容？IT基础设施监控体系为了能准确反映业务量和性能之间的函数关系，应为不同类型的业务系统规划相应的监控指标，这是生成容量基准模型的必要条件。通过有效监控可以提供准确的性能数据。业务量估算模型分析IT系统主要的资源包括CPU、内存、磁盘/磁盘控制器三大类。因此，由于资源数量、单个资源不同体系架构的影响，需要将影响性能的资源的数学关系公式和经验值有效结合在模型中，才能进行有效的性能趋势和假设性分析。不同的应用系统的业务量估算有不同方法和流程。容量规划的主要工作克服TPC-C、SPEC等国际标准主要体现主机/存储、系统平台性能的局限性，将业务量、服务等级、IT系统性能统一规划和管理，建立三者之间的关系模型。容量规划有助于企业有效控制IT基础设施的投入成本；并帮助企业(特别是电信运营商、银联系统)的IT系统的服务输出能力。增强对短、中期投资的可预见性。IT投资成本IT服务提高投资回报率实施容量规划意义何在？5容量规划的价值体现隐式价值显式价值CapacityPlanning降低采购成本：对在建项目预先进行容量规划，确定最优化的硬件资源配置并指导投资预算；找出未充分利用的资源和容量，以便指导业务系统合并或者将其它业务系统加入进来。节约维护成本：在约5年的硬件资源有效期内，系统维护、配置、升级等方面的费用要高于硬件的购买投资，容量规划帮助成比例的降低了这些附加成本。减少人力资源成本：容量规划帮助合理分配IT硬件资源，从而也会帮助组建合理的IT团队，以降低人力成本。增强IT系统可靠性：减少资源或容量的过度冗余，会减少风险节点，从而降低风险转变成灾难的概率；准确预测资源或容量的过度负载时间点，降低宕机概率。提高IT系统可用性：通过短期、不间断的容量规划，及时监控服务质量要求和响应时间的差距，提前采取措施，避免因服务质量降低导致的客户不满。降低IT投资成本&提高IT的QoS系统迁移。通过在测试环境下的有效性能监控，建立业务量、服务等级、IT硬件资源三者之间的容量基准模型，通过what-if分析业务量变化时的资源需求和性能表现，有效控制IT系统运营环境下的软硬件资源成本。系统的扩容改造。通过在运维期内的有效性能监控，收集系统在运营期的性能数据，建立业务量、服务等级、IT资源三者之间的容量模型，分析未来不同时间（例如6个月内、1年内等）的资源需求和性能表现，为IT系统的扩容提供依据，并对IT系统的性能进行有效的监控和预警。

系统迁移系统扩容改造何时？何处？实施容量规划7容量规划时机需求开发上线运维系统架构确定开发环境代码测试功能测试性能测试系统测试系统调优系统监控

需求(扩容)容量规划容量规划上线容量规划扩容容量规划8容量规划的前提条件上线容量规划扩容容量规划对测试环境的要求性能调优后收集容量规划的基础数据：即确保应用每个组件（Web、DB等）的瓶颈都在于硬件平台，即每个组件都可能因为压力的增加而使CPU或内存的利用率接近100；测试环境中DB的数据量要基本和现网一致，否则结果会有偏差；在测试中如果发现各组件间系统资源占用情况差别过大（如DBCPU100％时WebCPU10％），应调整测试环境；尽量保证测试环境和上线环境的硬件平台有相同的技术架构。对应用系统运行环境的要求确认网络不是造成响应时间过长的原因假设应用系统处在最优状态（如果瓶颈在应用系统，容量规划的结果会有较大的误差）；准确统计目前的业务量，作为容量规划建模的输入数据，业务量偏差大会导致不能和实际的性能表现相匹配；性能监控代理。客户端软件，安装在每台主机上，收集并存储主机的性能数据；根据容量规划的要求，对性能数据进行统计分析。提供性能数据导出工具；用户可以通过web页面展现系统的性能变化曲线。容量监控/管理工具。服务器端软件，汇总各代理收集的性能数据，建立业务系统的动态性能模型，对主机的性能、硬件资源进行动态的监控和管理，可以设置阈值在设定的条件下实现预警。

容量建模工具。根据采集的性能数据建立系统性能容量模型，使用系统容量模型进行假设性问题试验,事先了解应用系统环境的变化对应用系统部署、服务器的整合、业务扩展或增加工作负荷所产生的影响，从而对系统容量规划作出正确的决策。容量建模工具容量监控/管理工具IBMHost性能监控代理SunHost性能监控代理HPHost性能监控代理windows性能监控代理容量规划架构10容量规划的基本过程理解业务最大的应用/负载业务量的增长幅度2.划分主机负载a.定义workload b.workload的服务方式3.分析当前系统容量

a.测量所有的应用资源

b.使用workload测量应用资源

c.确定硬件系统各部分的反应时间4.系统中/远期预测

a.确定未来系统的资源配置需求

b.结合业务发展，规划远期系统配置5．编制详细性能报告11

Step1：理解业务第一步工作负载workload是计算机系统上所有工作的逻辑分类，如果将计算机的工作想象成一块大饼，那么每一个workload就是大饼的一块扇区。可以按照以下逻辑对workload进行分类：

who：谁在工作？例如特定的用户或组织

what：什么类型的工作？例如订单处理，财务报表

how：如何做这些工作？在线查询，批量数据备份

每个workload应具备业务敏感度，也就是说业务量的增加或减少和workload的性能表现有较明显的相关性；不管以何种逻辑划分workload，都应找出每个workload的相关业务指标，并用业务语言描述和定义该指标。第二步工作单元第三步服务等级将工作单元和workload联系起来，与完成某项工作而消耗的系统资源的数量类似，工作单元是一类可量化的变量，只不过需要用业务语言来描述。工作单元可以看成为workload而设定的几个可量化的参数，其数值的变化代表了workload对资源消耗的变化。例如：1、应用的交易事务数量2、连接数据库的用户数3、呼叫中心处理的呼叫次数4、帐务中心的订单处理数量都可以作为工作单元。服务等级协议由服务提供者和服务消费者双方制定，定义一个在服务消费者接受范围内的服务，一般通过响应时间和吞吐量来描述服务等级。签订服务等级协议时最好按照workload，理由是workload类似与性能和业务量之间的纽带，有很大的相关性；而且workload中工作单元的数值大小对业务量变化具备相当的敏感度。比如对一个预约应用系统，我们可以这样定义其服务等级：1、一小时内能够处理的电话预约数量不少于200个；2、每一个预约需在30秒内完成；3、每一个预约请求在队列中的等待时间不能超过60秒。

12Step1：理解业务系统(System)工作负载(Workload)工作单元(Unitofwork)资源(Resource)SAP主机财务模块活动用户数每个工作单元对多个资源都有消耗CPU业务处理数I/OTuxedo服务器查询模块事务数Memory取款模块事务数Networkconnection……店面(System)部门(Workload)业务指标(Unitofwork)资源(Resource)快餐店厨房食物重量每个业务指标对多个资源都有消耗鸡蛋每天生产三明治数量生肉大厅就餐的顾客数量泡菜切片……面粉asopposedto对比13Step2：划分workload类型解释Batch用于mainframe结构的主机容量规划，该环境下没有用户，workload根据预先定义的schedule启动/停止/休眠，即有处理任务就启动，没有就休眠直到有新的处理任务。Process用于opensystem结构的主机，即适用于小型机和pc机。Interactive有用户参与，并且一般用户通过终端连接，执行一些交互性的工作。例如用户对oracle数据库发出请求。Transaction多个进程一起执行事务，transaction不是由某一个用户发起或者执行，这是和interactive差异的地方。14Step3：收集数据上线容量规划扩容容量规划通过性能测试收集业务数据和性能数据业务数据：通过性能测试阶段指定的加压方式和测试策略，收集业务数据性能数据：收集不同负载测试时的性能数据，作为容量规划的原始数据。通过业务统计和系统监控收集数据业务数据:通过业务量统计或其它监控方法，收集业务数据。性能数据：通过实时监控收集性能数据15Step4：模型分析模型基础数据：根据当前的性能数据，建立性能benchmark，作为模型分析的基础。趋势分析不同的业务增长量What-if分析MVAP模型Simulation模型按照计算模型的差异，可以建立的模型包括：单机模型改变硬件配置Multi-tier模型改变各层的硬件配置；改变各层的主机数量按照应用系统的类型，可以建立的模型包括：模型分析时能够定义的资源：CPUDiskDiskcontroller模型分析时可以改变的参数：业务增长量Workload类型Disk间的I/O平衡……16Step5：结果报告结果报告：容量规划最终将为硬件采购提供必要的依据，在预先制定的业务目标前提下，给出最佳的硬件配置方案。一般情况下，对平均负载的模型分析以及对峰值负载的模型分析，都需要实施。

17谢谢！(后附容量规划案例)结束18

案例—SAP系统容量规划通过容量规划预测两年内的性能表现，回答以下几个问题：为了满足平均负载，系统需要在什么时候扩容？扩多少资源？为了满足峰值负载，系统需要在什么时候扩容？扩多少资源？过程：理解业务：估算业务量划分负载(workload)：从业务上对引起应用/负载的活动进行分类采集数据：平均负载下的性能数据；峰值负载下的性能数据建模分析:趋势分析,What-if分析建议:回答假设性问题195

结果4

模型分析3

采集数据2

划分负载1

估算业务量应用/负载代表了sap系统的业务量，根据和sap系统和业务人员的讨论，并从业务角度来描述，业务量受到两个主要因素的影响：活动用户数；用户的平均业务处理量

用户数和业务处理量的增加，必然带动业务量的增长。反映到SAP应用系统，必然需要更多的硬件资源用于业务处理，通过对两个自变量在IT系统的功能映射分析，我们可以确定：用户数增加需要SAP应用系统和Oracle数据库相应启动更多的进程，以增加业务处理能力，TeamQuest容量规划中的Population就代表了某一时刻SAP用户和oracle用户启动的进程数量，因此进程数的增长趋势可以较好的模拟用户数引起业务量增长的趋势。用户操作数的增加需要计算机处理更多的用户请求，表现在硬件层面上即计算机的CPU、Memory、DISK需要处理更多的机器指令，TeamQuest容量规划中的visitsatactiveresource的值就代表了一个用户的业务操作数，因此visits值的增长趋势可以较好的模拟用户操作数引起的业务量增长趋势。

ID业务量因子(工作单元)模型中对应的变量1活动用户数Population2平均业务处理量Visitsatactiveresource

案例—SAP系统容量规划205

结果4

模型分析3

采集数据2

划分负载1

估算业务量由于业务每月增长量暂时缺乏精确的统计数据，本次案例暂时通过假设设定一个增长比例：负载类型Population(活动用户数)Visitsatactiveresource(处理请求数)平均负载SAP系统10%10%Oracle数据库10%10%峰值负载SAP系统5%5%Oracle数据库5%5%本次预测“2年”内的业务满足程度，设计24步（step），每step代表一个月，上表为假设的业务量每月的变化。

案例—SAP系统容量规划21机器Workloads备注Sapapp1r3padmuserhpOpenViewrootexceptOpenViewusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenViewSapapp2r3padmuserhpOpenViewrootexceptOpenViewusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenViewSapDBSapDBorar3pr3padmuserhpOpenViewrootexceptOpenViewusedbyorar3pusedbyr3padmusedbyOpenViewagentusedbyrootexceptOpenView5

结果4

模型分析3

采集数据2

划分负载1

估算业务量根据业务类型划分工作负载

案例—SAP系统容量规划225

结果4

模型分析3

采集数据2

划分负载1

估算业务量Sap系统在每月25～下月5日业务比较繁忙，本次建模就在该时间段内收集数据，由于该时间段的性能表现有一定的代表性，所以对系统扩容有一定的参考意义。经过筛选，确定选取2006-5-268:20~17:20之间共9个小时的数据段：对平均负载性能数据，以10分钟作为数据聚合尺度；(保证计算出精确的平均值)；对峰值负载性能数据，以1小时作为数据聚合尺度。（真正反映业务峰值，而不是瞬时性能峰值）。

确定采集段数据聚合尺度生成abr文件

案例—SAP系统容量规划235

结果4

模型分析3

采集数据2

划分负载1

估算业务量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峰值负载平均负载

案例—SAP系统容量规划245

结果4

模型分析3

采集数据2

划分负载1

估算业务量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峰值负载平均负载

案例—SAP系统容量规划255

结果4

模型分析3

采集数据2

划分负载1

估算业务量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峰值负载平均负载

案例—SAP系统容量规划265

结果4

模型分析3

采集数据2

划分负载1

估算业务量在建模阶段，需要IT人员提供的数据包括：主机/存储的CPU、diskcontroller、disk的类型或者性能参数；对每台主机平均负载、峰值负载单独建立并校验model，模型分析的思路：首先正确匹配硬件资源类型，保存为baseline模型；平均负载按照每月10％业务量增长，峰值负载按照每月5％业务量增长，分别进行趋势分析；如果在某些硬件资源处形成瓶颈，增加该资源，进行what-if分析。

案例—SAP系统容量规划275

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1平均负载_趋势分析AVG(4CPU)Step:16Step:17Step:18Step:19Step:20StretchFactors1.501.641.842.142.55CPUUtilization80.2683.1385.8288.2590.34分析结果：

在step16～step18之间，即平均CPU利用率在80.3%~85.8%之间时，为了满足平均业务量需求，应考虑对系统进行扩容。

案例—SAP系统容量规划285

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1峰值负载_趋势分析分析结果：PEAK（4CPU）Step1Step2Step3Step4Step5StretchFactors1.511.671.892.172.51CPUUtilization81.4484.5287.1889.3491.05在step1～step3之间，为了满足峰值业务处理，应考虑对系统进行扩容；在第24step之前，必须考虑对CPU进行扩容，以防系统崩溃不再提供服务，或者CPU过于繁忙导致不能正常返回响应。

案例—SAP系统容量规划295

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1峰值负载_what-if分析分析结果：PEAK（8CPU）Step20Step21Step22Step23Step24StretchFactors1.271.331.411.511.64CPUUtilization86.3388.1389.7891.2592.49

增加4个CPU后，在未来24个月内，硬件资源可以较好的满足业务需要。

案例—SAP系统容量规划305

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1平均负载_趋势分析分析结果：AVG（4CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.171.191.201.221.241.27CPUUtilization43.0844.6146.1347.6649.1850.70

未来24个月内，硬件资源可以较好的满足均值业务需要。

案例—SAP系统容量规划315

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1峰值负载_趋势分析分析结果：PEAK（4CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.231.251.271.291.311.33CPUUtilization48.1449.3950.6351.8753.1154.34

未来24个月内，硬件资源可以较好的满足峰值业务需要。

案例—SAP系统容量规划325

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1平均负载_趋势分析分析结果：AVG（4CPU）Step8Step9Step10Step11Step12StretchFactors1.351.471.662.002.55CPUUtilization76.5880.7984.8088.4091.37在step10～step11之间，即平均CPU利用率在84%~88%之间时，为了满足Oracle用户的业务处理需求，应考虑对系统进行扩容。在step20时，数据库对用户的请求将不能正常返回响应，即在第step20之前，必须考虑对系统进行升级。

案例—SAP系统容量规划335

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1平均负载_what-if分析分析结果：Avg（8CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.161.181.211.241.271.32CPUUtilization70.2472.7075.1477.5879.9982.38CPU不再是性能瓶颈，在24个月内，硬件资源基本上可以较好的满足业务需求；磁盘I/O在后期会越来越繁忙，指令在磁盘处的排队有逐渐增多的趋势，在24个月后应考虑优化磁盘结构或者更换更快的磁盘。

案例—SAP系统容量规划345

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1峰值负载_趋势分析分析结果：PEAK（4CPU）Step1Step2Step3Step4……Step17StretchFactors1.541.742.042.4512.02CPUUtilization82.3285.6088.4290.6898.15在step1～step2之间，即平均CPU利用率在82%~86%之间时，为满足峰值业务处理需求，应考虑对系统进行扩容。在step17时(StretchFactor值超过12)，数据库对用户的请求将不能正常返回响应，即在第step17之前，必须考虑对系统进行升级。

案例—SAP系统容量规划355

结果4

模型分析3

采集数据2

划分负载1

估算业务量SapDBSapApp2SapApp1峰值负载_what-if分析分析结果：PEAK（8CPU）Step19Step20Step21Step22Step23Step24StretchFactors1.371.451.561.711.922.18CPUUtilization8