ITIL把容量管理分为三个层次:业务层(Business Level)、服务层(Service Level)和组件层(Component Level)。
这三个层次的流程中有许多类似的活动,但是每个子流程有不同的侧重点。业务容量管理侧重于当前和未来的商务业务需求,服务容量管理侧重于支持业务的现有服务的交付,组件容量管理侧重于支撑服务供给的技术基础设施。
1、业务容量管理
业务容量管理把业务需求和规划转变为对服务和IT基础设施的需求,保证IT服务将来的业务需求得到及时的量化、设计、规划和实施。业务容量管理主要考虑将来的业务需求,这些需求来自新的业务或者是业务新的变化(Newly Changed Business)。例如:
- 新服务或者服务方向的改变所提出的需要。
- 已有服务需要改进以提供额外的功能。
- 旧的服务将会被淘汰,释放闲置容量。
这些改变都会影响对客户的SLA能力,容量管理的职责就是预测和管理这些变更带来的容量需求,并且管理这些需求。
2、服务容量管理
服务容量管理关注于端到端性能、现实状况的IT服务使用和工作负载的容量的管理、控制和预测。服务容量管理的主要目标是识别和理解IT服务、资源的使用、工作模式、高峰与低谷等,以保证服务达到SLA目标。
服务容量管理主要考虑目前的业务需求是否得到满足。主要的活动是监控、分析和相应的改进。
3、组件容量管理
组件容量管理是对单个IT技术组件的性能、使用和容量进行管理、控制和预测,保证拥有限定资源的IT基础设施内的所有组件得到监控和测量,并可以记录、分析和报告所收集的数据。组件容量管理的主要目标是识别和理解性能、容量及支撑IT服务技术的单个组件的使用,包括基础架构、环境、数据和应用程序,以保证当前硬件和软件资源得到最佳使用,从而达到和维持既定的服务等级。
容量管理相关的基础要素包含如下三方面。
- 容量阈值的管理和控制
每个应用服务或系统上的资源限制可以被用来建立容量阈值,这个阈值能够被监控活动用来产生警告和异常报告。在确定阈值时要特别小心,因为特定应用的限制是不同的。
服务与系统的阈值管理和控制是有效满足SLA中确定的服务水平的基础。这些阈值被连续和自动监测,并且每当监控阈值被超过或者接近时,将产生警告和异常报告,以促使人们采取合理的补救行动。
阈值监控不仅应该在超过阈值时报警,也应该能够监测变化的速率,并且预测何时将达到阈值,以达到提前预警的目的。例如,磁盘空间监测应监测增长速率,并以当前速率计算在未来几天内是否会引起磁盘空间用尽,以便及时警报。例如,500GB的磁盘已经使用了80%的空间,增长速率是每天20GB,那么5天内将会用尽。
- 新技术的出现
容量管理也应该充分了解新技术带来的优势,如使用虚拟化、公共云计算服务和按需计算(on-demand computing)这类技术和服务,以及如何使用这些技术来支持运营的容量改进。
此信息可以通过利用外部资源来收集,如供应商研讨会、技术博览会、行业或专业网站。在评估这些新技术时,核心是成本导向。在任何时候,容量管理的责任人都应该认识到,新技术的引进和使用必须在成本合理的前提下,并且新技术可以向业务提供实实在在的利益。技术运营需要的是技术带来的成本节约及可用性,而不只是技术的先进性。要充分理解容量管理的目的,不能为了技术而技术。
- 常规化
容量计划的制订和维护应该在规定的时间周期内。实际上,生产线的容量一定会涉及资金预算,因此,与业务或预算的计划周期一样,应该每年完成一次。每个季度的更新是必要的,目的是根据服务需求的变化做相应的调整,以保持容量预测的准确性。虽然需要额外的努力,但如果真的可以定期更新,容量规划则会更加准确,可以满足不断变化的业务需求。
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.e1idc.net