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

主机性能容量规划实施办法,作者：Tony Shi Email：tony26600882 欢迎通过邮件交流,2,容量规划能够解决的问题,为了能准确反映业务量和性能之间的函数关系，应为不同类型的业务系统规划相应的监控指标，这是生成容量基准模型的必要条件。 通过有效监控可以提供准确的性能数据。,IT系统主要的资源包括CPU、内存、磁盘/磁盘控制器三大类。因此，由于资源数量、单个资源不同体系架构的影响，需要将影响性能的资源的数学关系公式和经验值有效结合在模型中，才能进行有效的性能趋势和假设性分析。,不同的应用系统的业务量估算有不同方法和流程。,容量规划的主要工作,克服TPC-C、SPEC等国际标准主要体现主机/存储、系统平台性能的局限性，将业务量、服务等级、IT系统性能统一规划和管理，建立三者之间的关系模型。容量规划有助于企业有效控制IT基础设施的投入成本；并帮助企业(特别是电信运营商、银联系统)的IT系统的服务输出能力。,增强对短、中期投资的可预见性。,实施容量规划意义何在？,5,容量规划的价值体现,隐式价值,显式价值,Capacity Planning,降低采购成本： 对在建项目预先进行容量规划，确定最优化的硬件资源配置并指导投资预算； 找出未充分利用的资源和容量，以便指导业务系统合并或者将其它业务系统加入进来 。 节约维护成本： 在约5年的硬件资源有效期内，系统维护、配置、升级等方面的费用要高于硬件的购买投资，容量规划帮助成比例的降低了这些附加成本。 减少人力资源成本 ： 容量规划帮助合理分配IT硬件资源，从而也会帮助组建合理的IT团队，以降低人力成本。,增强IT系统可靠性： 减少资源或容量的过度冗余，会减少风险节点，从而降低风险转变成灾难的概率； 准确预测资源或容量的过度负载时间点，降低宕机概率。 提高IT系统可用性： 通过短期、不间断的容量规划，及时监控服务质量要求和响应时间的差距，提前采取措施，避免因服务质量降低导致的客户不满。,系统迁移。通过在测试环境下的有效性能监控，建立业务量、服务等级、IT硬件资源三者之间的容量基准模型，通过what-if分析业务量变化时的资源需求和性能表现，有效控制IT系统运营环境下的软硬件资源成本。 系统的扩容改造。通过在运维期内的有效性能监控，收集系统在运营期的性能数据，建立业务量、服务等级、IT资源三者之间的容量模型，分析未来不同时间（例如6个月内、1年内等）的资源需求和性能表现，为IT系统的扩容提供依据，并对IT系统的性能进行有效的监控和预警。,系统迁移,系统扩容改造,何时？何处？实施容量规划,7,容量规划时机,需求,开发,上线,运维,系统架构 确定开发环境,代码测试 功能测试 性能测试,系统测试 系统调优,系统监控,需求(扩容),容量规划,容量规划,上线容量规划 扩容容量规划,8,容量规划的前提条件,性能监控代理。客户端软件，安装在每台主机上，收集并存储主机的性能数据；根据容量规划的要求，对性能数据进行统计分析。提供性能数据导出工具；用户可以通过web页面展现系统的性能变化曲线。 容量监控/管理工具。服务器端软件，汇总各代理收集的性能数据，建立业务系统的动态性能模型，对主机的性能、硬件资源进行动态的监控和管理，可以设置阈值在设定的条件下实现预警。 容量建模工具。根据采集的性能数据建立系统性能容量模型，使用系统容量模型进行假设性问题试验,事先了解应用系统环境的变化对应用系统部署、服务器的整合、业务扩展或增加工作负荷所产生的影响，从而对系统容量规划作出正确的决策。,容量建模工具,容量监控/管理工具,IBM Host 性能监控代理,Sun Host 性能监控代理,HP Host 性能监控代理,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秒。,12,Step1：理解业务,as opposed to 对比,13,Step2：划分workload,14,Step3：收集数据,15,Step4：模型分析,模型基础数据：根据当前的性能数据，建立性能benchmark，作为模型分析的基础。,模型分析时能够定义的资源： CPU Disk Disk controller 模型分析时可以改变的参数： 业务增长量 Workload类型 Disk间的I/O平衡 ,16,Step5：结果报告,结果报告： 容量规划最终将为硬件采购提供必要的依据，在预先制定的业务目标前提下，给出最佳的硬件配置方案。 一般情况下，对平均负载的模型分析以及对峰值负载的模型分析，都需要实施。,17,谢谢！ (后附容量规划案例),结 束,18,案例SAP系统容量规划,通过容量规划预测两年内的性能表现，回答以下几个问题： 为了满足平均负载，系统需要在什么时候扩容？扩多少资源？ 为了满足峰值负载，系统需要在什么时候扩容？扩多少资源？,过程： 理解业务：估算业务量 划分负载(workload)：从业务上对引起应用/负载的活动进行分类 采集数据：平均负载下的性能数据；峰值负载下的性能数据 建模分析:趋势分析,What-if分析 建议:回答假设性问题,19,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,应用/负载代表了sap系统的业务量，根据和sap系统和业务人员的讨论，并从业务角度来描述，业务量受到两个主要因素的影响：活动用户数； 用户的平均业务处理量,用户数和业务处理量的增加，必然带动业务量的增长。反映到SAP应用系统，必然需要更多的硬件资源用于业务处理，通过对两个自变量在IT系统的功能映射分析，我们可以确定： 用户数增加需要SAP应用系统和Oracle数据库相应启动更多的进程，以增加业务处理能力，TeamQuest容量规划中的Population就代表了某一时刻SAP用户和oracle用户启动的进程数量，因此进程数的增长趋势可以较好的模拟用户数引起业务量增长的趋势。 用户操作数的增加需要计算机处理更多的用户请求，表现在硬件层面上即计算机的CPU、Memory、DISK需要处理更多的机器指令，TeamQuest 容量规划中的visits at active resource的值就代表了一个用户的业务操作数，因此visits值的增长趋势可以较好的模拟用户操作数引起的业务量增长趋势。,案例SAP系统容量规划,20,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,由于业务每月增长量暂时缺乏精确的统计数据，本次案例暂时通过假设设定一个增长比例：,本次预测“2年”内的业务满足程度，设计24步（step），每step代表一个月，上表为假设的业务量每月的变化。,案例SAP系统容量规划,21,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,根据业务类型划分工作负载,案例SAP系统容量规划,22,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,Sap系统在每月25下月5日业务比较繁忙，本次建模就在该时间段内收集数据，由于该时间段的性能表现有一定的代表性，所以对系统扩容有一定的参考意义。 经过筛选，确定选取2006-5-26 8:2017:20之间共9个小时的数据段：,对平均负载性能数据，以10分钟作为数据聚合尺度；(保证计算出精确的平均值)； 对峰值负载性能数据，以1小时作为数据聚合尺度。（真正反映业务峰值，而不是瞬时性能峰值）。,案例SAP系统容量规划,23,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapApp1,峰值负载,平均负载,案例SAP系统容量规划,24,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapApp2,峰值负载,平均负载,案例SAP系统容量规划,25,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,峰值负载,平均负载,案例SAP系统容量规划,26,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,在建模阶段，需要IT人员提供的数据包括： 主机/存储的CPU、disk controller、disk的类型或者性能参数；,对每台主机平均负载、峰值负载单独建立并校验model，模型分析的思路： 首先正确匹配硬件资源类型，保存为baseline模型； 平均负载按照每月10业务量增长，峰值负载按照每月5业务量增长，分别进行趋势分析； 如果在某些硬件资源处形成瓶颈，增加该资源，进行what-if分析。,案例SAP系统容量规划,27,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,平均负载_趋势分析,在step16step18之间，即平均CPU利用率在80.3% 85.8%之间时，为了满足平均业务量需求，应考虑对系统进行扩容。,案例SAP系统容量规划,28,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,峰值负载_趋势分析,分析结果：,在step1step3之间，为了满足峰值业务处理，应考虑对系统进行扩容； 在第24 step之前，必须考虑对CPU进行扩容，以防系统崩溃不再提供服务，或者CPU过于繁忙导致不能正常返回响应。,案例SAP系统容量规划,29,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,峰值负载_what-if分析,分析结果：,增加4个CPU后，在未来24个月内，硬件资源可以较好的满足业务需要。,案例SAP系统容量规划,30,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,平均负载_趋势分析,分析结果：,未来24个月内，硬件资源可以较好的满足均值业务需要。,案例SAP系统容量规划,31,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,峰值负载_趋势分析,分析结果：,未来24个月内，硬件资源可以较好的满足峰值业务需要。,案例SAP系统容量规划,32,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,平均负载_趋势分析,分析结果：,在step10step11之间，即平均CPU利用率在84%88%之间时，为了满足Oracle用户的业务处理需求，应考虑对系统进行扩容。 在step20时，数据库对用户的请求将不能正常返回响应，即在第step20之前，必须考虑对系统进行升级。,案例SAP系统容量规划,33,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,平均负载_what-if分析,分析结果：,CPU不再是性能瓶颈，在24个月内，硬件资源基本上可以较好的满足业务需求； 磁盘I/O在后期会越来越繁忙，指令在磁盘处的排队有逐渐增多的趋势，在24个月后应考虑优化磁盘结构 或者 更换更快的磁盘。,案例SAP系统容量规划,34,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,峰值负载_趋势分析,分析结果：,在step1step2之间，即平均CPU利用率在82%86%之间时，为满足峰值业务处理需求，应考虑对系统进行扩容。 在step17时(Stretch Factor值超过12)，数据库对用户的请求将不能正常返回响应，即在第step17之前，必须考虑对系统进行升级。,案例SAP系统容量规划,35,5 结果,4 模型分析,3 采集数据,2 划分负载,1 估算业务量,SapDB,SapApp2,SapApp1,峰值负载_what-if分析,分析结果：,在step21step23之间，即平均CPU利用率在90% 93%之间时，为了满足Oracle用户的业务处理需求，应考虑