分布式系统的容量规划

正是在资源中心化统一管理的基础上进行的。基于分布式架构的业务系统自底向上的架构层次为计算、存储、网络设施,操作系统,中间件,运行时环境,数据,应用程序。一方面,纵向的统一管理允许系统的管理员将不同层次之间的资源进行动态的组合,例如可在不同的服务器中动态的部署中间件,将不同的中间件实例组合成为运行时环境,以及在不同的运行时环境中部署多个应用程序的运行实例。另一方面,横向的中心化资源管理可利用全局的资源并行处理业务应用的负载。在此基础上,容量规划能够灵活、高效的对系统的资源和负载进行匹配,从而生成动态资源调度和伸缩的规则,为用户合理的计划资源的使用和扩展。


TeamQuest公司提供了整套实施容量规划的软件平台,其建模工具 TQ model能够帮助容量规划人员从进程、批量处理、事务、交互处理等多种方式区分工作负载的不同行为。其产品容量规划的基本过程如表1 所示

容量规划基本过程任务 操作
整理系统负载信息,并文档化 系统管理员交付有关服务器上应用/负载的详细数据;
每个应用/负载启动的进程列表;
过去5周系统/负载的相关日志记录;
将没有指定给应用/负载的一些较小进程,一步步经鉴定后指定给新的或者已经存在的应用/负载;
建立多个容量规划模型,检查并手工校正后,正确定义磁盘、磁盘控制器、CPU的类型。如果需要,提高模型的精确度。
确定应用对系统负载的贡献 系统管理员描述应用/负载峰值应用的时间变化模式,其中有些有规律性,有些无规律性;
确定每台服务器上的主要峰值负载贡献者(主要应用/负载),不要太多,通常为1至3个主要贡献者。
确定业务驱动 仅对主要应用/负载做深入分析,管理员列出应用的业务驱动因素;管理员仅需要考虑主要应用/负载的业务驱动因素;
规划人员收集关于业务驱动的有效信息,需要在“小时”粒度上评估其和CPU负载之间的相关系数。某些案例中该系数有效,某些案例中该系数需要计算,某些案例中该系数通过聚合模式收集。
CPU负载和业务驱动之间的依赖关系 选取多个CPU负载并在TQ模型中解释它们,每个CPU负载的Visit count由模型计算得出(表里中visit count的值),本例中的业务驱动为DB Sessions,图2右边是两者之间的依赖关系(点集)。我们发现在很多案例中,CPU负载和主要的业务驱动都成比例关系,但对低CPU负载时却不一定正确。
计算依赖关系公式 通过Excel的相关分析,生成CPU负载和业务驱动之间的关系公式:
Visit Count = 1.6409 * sessions - 18.425
其它依赖关系公式 如果还有其它的主要负载贡献者(业务驱动,例如多于本例的3个),我们也要按照刚才的两步计算出它们和CPU负载之间的关系公式。
预测系统负载 在业务驱动预测和计算依赖关系的基础上,规划人员计算visit count(这是model唯一需要改变的输入)的变化比例,然后输入模型并分析结果。

目前,容量规划技术主要被用于Web应用程序的部署中。首先,应用程序服务的提供者将Web应用程序进行模块化拆分,通常按照MVC框架拆分成为不同层次,然后将每个层次中的不同逻辑单元分布的部署在不同的站点中。之后,通过容量规划方法制定资源分配的规则,按照规则在全局资源中动态部署Web应用程序模块的实例,以实现Web应用的并行化。容量规划通常基于系统的监控结果,根据监控信息发现资源使用的规律,如业务的高峰期,以及应用程序负载的周期性变化等。因此,容量规划的本质实际上是对监控信息的分析。在现有研究成果中,容量规划使用的方法有时间序列、基于分类的方法,也有一些研究采用了比较复杂的算法,如聚类分析、人工神经网络、支持向量机等方法。