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

主机性能容量规划实施办法 作者 TonyShiEmail tony26600882 欢迎通过邮件交流 2 容量规划能够解决的问题 为了能准确反映业务量和性能之间的函数关系 应为不同类型的业务系统规划相应的监控指标 这是生成容量基准模型的必要条件 通过有效监控可以提供准确的性能数据 IT系统主要的资源包括CPU 内存 磁盘 磁盘控制器三大类 因此 由于资源数量 单个资源不同体系架构的影响 需要将影响性能的资源的数学关系公式和经验值有效结合在模型中 才能进行有效的性能趋势和假设性分析 不同的应用系统的业务量估算有不同方法和流程 容量规划的主要工作 克服TPC C SPEC等国际标准主要体现主机 存储 系统平台性能的局限性 将业务量 服务等级 IT系统性能统一规划和管理 建立三者之间的关系模型 容量规划有助于企业有效控制IT基础设施的投入成本 并帮助企业 特别是电信运营商 银联系统 的IT系统的服务输出能力 增强对短 中期投资的可预见性 实施容量规划意义何在 5 容量规划的价值体现 隐式价值 显式价值 CapacityPlanning 降低采购成本 对在建项目预先进行容量规划 确定最优化的硬件资源配置并指导投资预算 找出未充分利用的资源和容量 以便指导业务系统合并或者将其它业务系统加入进来 节约维护成本 在约5年的硬件资源有效期内 系统维护 配置 升级等方面的费用要高于硬件的购买投资 容量规划帮助成比例的降低了这些附加成本 减少人力资源成本 容量规划帮助合理分配IT硬件资源 从而也会帮助组建合理的IT团队 以降低人力成本 增强IT系统可靠性 减少资源或容量的过度冗余 会减少风险节点 从而降低风险转变成灾难的概率 准确预测资源或容量的过度负载时间点 降低宕机概率 提高IT系统可用性 通过短期 不间断的容量规划 及时监控服务质量要求和响应时间的差距 提前采取措施 避免因服务质量降低导致的客户不满 系统迁移 通过在测试环境下的有效性能监控 建立业务量 服务等级 IT硬件资源三者之间的容量基准模型 通过what if分析业务量变化时的资源需求和性能表现 有效控制IT系统运营环境下的软硬件资源成本 系统的扩容改造 通过在运维期内的有效性能监控 收集系统在运营期的性能数据 建立业务量 服务等级 IT资源三者之间的容量模型 分析未来不同时间 例如6个月内 1年内等 的资源需求和性能表现 为IT系统的扩容提供依据 并对IT系统的性能进行有效的监控和预警 系统迁移 系统扩容改造 何时 何处 实施容量规划 7 容量规划时机 需求 开发 上线 运维 系统架构确定开发环境 代码测试功能测试性能测试 系统测试系统调优 系统监控 需求 扩容 容量规划 容量规划 上线容量规划扩容容量规划 8 容量规划的前提条件 性能监控代理 客户端软件 安装在每台主机上 收集并存储主机的性能数据 根据容量规划的要求 对性能数据进行统计分析 提供性能数据导出工具 用户可以通过web页面展现系统的性能变化曲线 容量监控 管理工具 服务器端软件 汇总各代理收集的性能数据 建立业务系统的动态性能模型 对主机的性能 硬件资源进行动态的监控和管理 可以设置阈值在设定的条件下实现预警 容量建模工具 根据采集的性能数据建立系统性能容量模型 使用系统容量模型进行假设性问题试验 事先了解应用系统环境的变化对应用系统部署 服务器的整合 业务扩展或增加工作负荷所产生的影响 从而对系统容量规划作出正确的决策 容量建模工具 容量监控 管理工具 IBMHost性能监控代理 SunHost性能监控代理 HPHost性能监控代理 windows性能监控代理 容量规划架构 10 容量规划的基本过程 理解业务最大的应用 负载业务量的增长幅度2 划分主机负载a 定义workloadb 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 理解业务 asopposedto对比 13 Step2 划分workload 14 Step3 收集数据 15 Step4 模型分析 模型基础数据 根据当前的性能数据 建立性能benchmark 作为模型分析的基础 模型分析时能够定义的资源 CPUDiskDiskcontroller模型分析时可以改变的参数 业务增长量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容量规划中的visitsatactiveresource的值就代表了一个用户的业务操作数 因此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 268 20 17 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 diskcontroller disk的类型或者性能参数 对每台主机平均负载 峰值负载单独建立并校验model 模型分析的思路 首先正确匹配硬件资源类型 保存为baseline模型 平均负载按照每月10 业务量增长 峰值负载按照每月5 业务量增长 分别进行趋势分析 如果在某些硬件资源处形成瓶颈 增加该资源 进行what if分析 案例 SAP系统容量规划 27 5结果 4模型分析 3采集数据 2划分负载 1估算业务量 SapDB SapApp2 SapApp1 平均负载 趋势分析 在step16 step18之间 即平均CPU利用率在80 3 85 8 之间时 为了满足平均业务量需求 应考虑对系统进行扩容 案例 SAP系统容量规划 28 5结果 4模型分析 3采集数据 2划分负载 1估算业务量 SapDB SapApp2 SapApp1 峰值负载 趋势分析 分析结果 在step1 step3之间 为了满足峰值业务处理 应考虑对系统进行扩容 在第24step之前 必须考虑对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 平均负载 趋势分析 分析结果 在step10 step11之间 即平均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 峰值负载 趋势分析 分析结果 在step1 step2之间 即平均CPU利用率在82 86 之间时 为满足峰值业务处理需求 应考虑对系统进行扩容 在step17时 StretchFactor值超过12 数据库对用户的请求将不能正常返回响应 即在第step17之前 必须考虑对系统进行升级 案例 SAP系统容量规划 35 5结果 4模型分析 3采集数据 2划分负载 1估算业务量 SapDB SapApp2 SapApp1 峰值负载 what if分析 分析结果 在step21 step23之间 即平均CPU利用率在90 93 之间时 为了满足Oracle用户的业务处