第五章系统容量规划.docx
《第五章系统容量规划.docx》由会员分享，可在线阅读，更多相关《第五章系统容量规划.docx（20页珍藏版）》请在冰点文库上搜索。
第五章系统容量规划
第五章系统容量规划
在本节中将详细地讨论在电子商务的环境下实现容量规划的一套方法。
这套方法有别于其它在网络服务器或者在客户服务器环境下使用的方法，因为它包含商务层次和客户行为层次。
首先会给岀容量规划的定义，接着再提岀一个容量规划场景的例子。
接下来，提岀这套容量规划方法并且使用这个例子来说明这个方法的各个步骤。
其中有些步骤将在本书的其它章节得到更为详细的介绍。
521容量规划和足够的容量
容量规划是预测未来负载水平何时会使系统饱和，以及确定一个尽可能延迟系统饱和的最经济方法的过程。
未来负载水平通常是三个因数组合的函数：
现有工作负载的发展，新的应用和服务的采用，以及客户行为的变化。
最后一个因素包括由于新情况（例如，爆炸性新闻，电视广告活动，或者一个新的产品的发布）而引发的通信量爆发，和由于新的商务功能的使用而导致的客户导航模式的变化。
预测是容量规划的核心，因为当负载水平和客户行为发生变化时或者建立了新的商务模型时，电子商务网站必须决定如何应对。
电子商务网站做岀决定时需要预测性模型，并且决不能是试验性的。
规划一个网站的容量的一个重要问题是，多少容量才足够支持一个网站的运作？
图5-5显示了定义足
够的容量所需的元素。
这幅图表明一个电子商务网站所需的足够的容量是以下三个元素的函数。
如:
响应时间<2秒”
图5-5足够容量的定义
服务水平满意度（SLAs）。
这是性能（例如，响应时间和吞吐量）和可用性度量标准的上下界限。
SLAs的例子包括服务方响应时间<2秒”，站点可用性>99.5%”和会话吞吐量>30,000个会话海天”SALs由电子商务网站管理方和一个来自客户的间接的输入（如图5.5中虚线所示）决定。
来自客户的输入是间
接的，这是因为他们并不说SLAs该怎么样，而是暗示他们所期望的特定的服务质量。
如果这些期望没有
得到满足，客户往往会不耐烦，并且如果他们大约要等8秒钟才能下载一页的话，他们就会转向别的地方。
在工业中这一常规被称为八秒钟”规则，它涉及端对端响应时间，包括服务端响应时间加上所有网络开销的时间。
实验表明在8秒极限上增长1秒将使点击退岀率从8%增长到30%。
差的性能可能只是使预期的购买者在一次访问中吓跑，也可能使他们再也不光临这个网站了。
特定的技术和标准。
在设计一个电子商务网站的时候可能会选择许多不同的技术和标准。
例如，管理方可能决定使用WIN2000服务器，使用Oracle来进行数据库管理，使用SSL和SET来支持认证和付款服务。
这些选择为如何提供足够的容量给岀了约束。
成本约束。
如果有充足的资金，那么建一个性能最好的电子商务网站就会非常容易。
然而，任何一个组织当它开始从事和运作一个站点时，它都是有预算和约束的。
这些约束决定了可能的容量。
因此对于我们来说，当在费用约束的范围内提供服务，并且服务级协议持续地满足特定的技术和特定的标准时，一个电子商务网站有着足够的容量。
进行容量规划的最终目标有三个，也可以说足够的容量可以带来三方面的好处：
降低停机时间和网络瓶颈现象。
客户总是希望访问页面的访问时间越短越好，而网站的所有者总是希望能尽可能的少停机以增加访问次数，这些都要容量规划来预测到底要多好才算足够。
可用、可扩展、快速且高效。
可用性是最低的要求，是一个电子商务网站能否生存的底线；可扩展性是进一步的要求，即使现在可能性能比较低但以后可以改进，这是长期发展的重要保证；快速、高效是最理想的结果，挖掘了现有的潜力并充分的展现岀来。
分层模型帮助分析。
分层是容量规划方法的主要过程，也是最后形成的解决方案的重要组成部分。
分层将大目标分成小目标，复杂问题分解成简单问题，有利于区分清楚各个参数的影响范围和影响力度，不至于在考虑细节的时候被不相关的因素所干扰。
522方法论
根据第一章介绍的电子商务参考模型，定义一个覆盖了商务层、客户层和资源层的容量规划方法。
图
5-6是这个方法的高级视图。
它表明电子商务的容量规划由3个主要的设计过程构成：
商务和功能设计、
客户行为设计和IT资源设计。
这些设计过程将在以下的各节中详细解释。
商务和功能设计过程受到商务发展规划和功能发展规划的影响。
如图5-6所示，客户行为的发展影响
客户行为规划过程，基础结构的发展规划也在影响IT资源规划过程。
规划过程的结果是关于商务模型、电子商务提供的功能、客户行为模型和IT基础结构的调整和站点发
展的一系列规划。
图5-6电子商务容量规划方法论的高级视图
1•商务层
商务和功能设计包括描绘商务的特征和分析电子商务站点提供的功能，如图5-7所示
图5-7
电子商务容量规划方法论的商务层面
1）商务描述商务描述阶段的目标是生成一个商务模型，如同第一章中描述的一样，由以下元素组成。
商务类型：
这个元素描述了网络上所经营的商务类型。
商务类型的一些例子包括B2C电子零售、B2C服务、C2C拍卖、B2C拍卖和B2B购买。
交付类型：
这个元素描述了多种交付类型，如果有的话，和商务模型联合在一起。
第三方服务的使用：
这个元素描述了用于支持电子商务的第三方服务有哪些，例如广告和付款网关。
商务定量描述符：
这些描述符的性质根据商务类型的不同而有着明显的变化。
这些描述符的目的是提供与商务相关的参数，这些参数对于容量规划很重要。
例如，和在线书店相关的定量描述符就有在线目录中的存书总量、站点的注册用户、购买模式、书价范围等等。
商务定量描述符有助于预测系统为了达到收入目标所必须处理的每种类型的交易数目。
市场组成成分：
这个元素描述了市场的组成成分。
例如，一家卖巴西和法国书籍的位于美国的在线书店，它的大部份订单肯定是来自于美国的讲葡萄牙语和法语的社区。
运作时间：
大多数电子商务是要每天运作24小时，每周运作7天的。
然而，一些电子商务，例如，在线交易站点的主要的活动时间就是市场开启的时候。
2）功能分析
功能分析步骤的目的是建立一个功能模型（见图5-7）。
这个模型描述了电子商务网站提供的功能。
功能分析可以通过调查站点和建立一个站点提供的功能的清单来实现。
功能模型的一个目标是支持容量规划，容量规划从本质上来说就是定量的。
从而，必须给每个功能的描述加上相关的定量以及性能相关的信息。
这种类型的信息包括以下部分：
交互模型。
这个描述了一个用户如何和电子商务站点交互来实现功能。
一个例子是，需要两个连续的
HTML表单来实现功能。
使用网络技术。
不同的技术被用来实现一个电子商务功能。
例如HTML表单、ASP、PHP、JSP和Java
Servlets。
使用认证。
信息描述是否使用诸如SSL的认证协议来实现电子商务功能。
这些信息结合功能模型描述的信息可以用来为每个电子商务功能建立CSIDs。
我们将使用我们的在线
汽车购买例子来说明功能分析步骤。
3）商务发展分析商务发展的规划可能会对运行电子商务所需的容量有着相当可观的影响。
我们要通过准确的分析来预
测这些规划会对容量有怎样的影响。
如果不能做到准确预测，譬如一个极具个性的销售广告可能极大的增加客户的兴趣也可能引起客户反感，这就要不遗漏的把每种可能后果都考虑进来。
4）功能发展分析这一步分析电子商务站点提供的功能是如何随着时间的前进而发展的。
结合商务发展分析的结论，对
应到容量规划上该做哪些改动，包括硬件的更新和系统的功能添加。
2．客户行为层次
在5.1节中详细地说明了客户行为模型的概念，并且描述了两种模型：
客户行为模型图（CBMG）和
客户访问模型（CVM）。
图5-8描绘了容量规划方法的客户行为层次。
这个层次的主要步骤是客户行为描述和客户行为发展规划。
前者生成一个CBMG或者CVM形式的客户行为模型，如果只有静态的客户行为模型也已足够。
后者为客户行为的发展提供规划。
这些规划由对站点布局规划的有计划的调整产生，布局规划的调整可能会改变可行的导航模式。
每一次客户行为的变化，都应该有一个修改过的客户行为模型与之对应。
图5-8电子商务的容量规划方法的客户行为层次
3•资源层
资源层正如在商务、功能和客户行为模型中所描述的一样，对电子商务提供的功能和客户行为方式有
着一个很好的了解。
容量规划方法中的下一个层次一一IT资源规划，处理用来支持电子商务的IT资源。
图
5-9表示了这一层的主要步骤：
IT环境描述、工作负载描述、工作负载预测、性能建模、校准和确认以及
假设性分析。
这个方法的资源层部分建立在三个模型和两个描述说明上，工作负载、性能和成本模型，IT
基础结构和工作负载描述说明。
图5-9电子商务容量规划方法的资源层
1）描述IT环境
这一步生成了IT基础结构和工作负载的描述说明。
IT基础结构的描述说明包括硬件类型（例如，服务
器、特大容量磁盘、路由器、负载均衡器、防火墙），服务器（例如，网络服务器、应用服务器、数据库服务器、域名服务器），软件（例如，操作系统、中间件、数据库管理系统），网络连接性，网络协议和付款服务。
2）工作负载描述
工作负载描述是以定性和定量的方式精确描述电子商务站点的全局工作负载的过程。
这过程首先以从
IT环境描述步骤中得到定性工作负载描述开始。
先为每个电子商务功能（由CBMG的状态来表示）建立客
户端/服务器端交互图表（CSIDs），并且为CSID中每一个非客户端节点赋予事务名称。
由此可以根据这个模型来分析相关事务在各个相关服务器和网络之间交换的消息的大小。
事务在这里由工作负载强度（例如事务到达率）和对每种资源的服务需求参数来描述。
每个参数或者可以通过使用性能监测和日志系统直接获得，或者也可以从其它可以直接测量得到的参数推导得到。
测量必须在负载高峰时刻进行，并且采用一个合适的监测间隔。
3）工作负载预测工作负载预测是预测系统工作负载在未来如何变化的过程。
通过这个过程可以回答重要的问题。
“访问站点的客户的数目在未来的6个月将如何变化？
”在“线书店购买计算机书籍的客户的数目在未来将如何变化？
”回答这些问题需要评估工作负载发展趋势，可以从历史数据中获得，也可以通过分析可能会实施的商务战略规划。
在实际应用中，我们可以采用多种手段对工作负载进行预测，比如对最近周期内的系统日志数据的曲线进行线性拟合或者指数拟合来进行预测。
4）性能建模容量规划的一个重要的方面包括预测系统是否会发送性能度量标准（例如，响应时间和吞吐量），这些性能度量标准满足想要的或者可接受的服务水平。
性能预测是根据一组指定的参数对一个计算机系统进行性能估测的过程。
典型的性能测量包括响应时间、吞吐量、资源利用率和资源队列长度。
5）校准和确认一个性能模型可以被认为是有效的，当根据模型计算得到的性能度量标准（例如，响应时间、资源利用率和吞吐量）和实际测量到的系统数据在一定的误差范围内是一致的。
一般来说，10%~30%的精确度在容量规划中是可以接受的。
如果计算值在可接受的程度上不匹配实测得到的值，那么这个模型必须被校准。
如果这两种值相匹配，这个模型就被认为是有效的，可以用来进行性能预测。
6）成本建模
基于发展IT基础结构模型的规划和现有的IT平台，必须建立成本模型，从而可以预测基础结构变化所需的花费。
前面曾提到了一个IT基础结构的费用模型的各种元素。
当不同的场景被评估时，需要预测对于每个场景还需要多少额外的磁盘存储器、处理器功能、内存和网络带宽以及这些元素现在和将来的价格。
当前的费用的计算是简单的，然而费用的预测却不是那么直接了当。
我们可使用一些拇指规则（ROT）来获得费用预测的初步估计。
下面是一些著名的ROT规则。
第一至第四条ROT假设性能提高的同时没有费用的增长。
1.内存的容量每三年增长四倍（Moore定律）。
2.处理器速度每三年增长四倍（Moore定律）。
3.二级存储器的容量每十年增长一百倍。
4.连接带宽每三年增长1/4（Gilder定律）。
5.一个系统所需的RAM容量（计量单位是MB）和该系统的MIPS的比率从1增长到4。
这个比率被称为a,这就是Amdahl存储器定律。
7）假设性分析
一旦建立和解答了性能模型，根据费用—性能的公平交易原则可以进行各种分析。
对于不同的配置，
性能模型和费用模型可以用来评价不同的场景和配置。
“我们应该镜像网络服务器从而平衡负载吗？
应该降低网络通信量并且提高性能吗？
”我“们应该换一个更快的服务器吗？
”我“们应该复制数据库并且把它分布到多个数据库服务器上吗？
”对于每一个场景，我们可以预测全局工作负载的每一个基本部件的性能并且算出它们的价值。
这些各种场景的比较给出了发展IT基础结构规划的输入，客户和站点进行交互的方法，商务模型和商务过程。
图5-10详细说明了这一反馈，它描绘了这一节描述的整个方法论。
523不同的Web站点分类及其对应策
不同的Web站点会对不同的资源有着不一样的要求。
如果把其它电子商务网站的设计方案直接搬到新
的网站上，很有可能会失败，因为两者之间的类型差别太大，侧重点完全不一样。
一般认为Web站点可以
分成五类，如下表所示：
表5-5五类不同的Web站点及其工作负载模式
站点类型
模式
发布/订阅
在线购物
客户自助服务
交易
业务对业务
分类/
示例
搜索引擎
媒体
事件
精确盘存
不精确盘存
家庭银行业务
包裹跟踪
旅行安排
在线股票交易
拍卖
电子购买
内容
页面布局的动
态变化，基于
内容或需要的
或是单调的（部分分类），或动态（变动频繁的
数据在旧应用程序中
多个数据来源，一致
性要求
对时间极其敏感高易变率多供应商，多消费
数据在旧应用程
序中
多个数据来源，一
变化许多页面作者及页面布局频繁地改变高容量，非用户专用访问相当静态的信息来源
项目，接近实时）
页面作者很少，
且页面布局变化
不太频繁
用户专用信息：
有数据挖掘的用户简档
者
事务复杂，且与后
端交互
致性要求
事务复杂
安全性
低
私密性、不可抵赖性、完整性、身份验证、规则
银行业务：
私密性、
不可抵赖性、完整性、
身份验证、规则
其它：
低
私密性、不可抵赖性、完整性、身份
验证、规则
私密性、不可抵赖性、完整性、身份
验证、规则
安全页
面百分
率
低
中等
中等
高
中等
跨会话
信息
无
高
有
有
有
搜索数
按类别构造完全动态低容量
按类别构造完全动态高容量
按类别构造
低容量
按类别构造
低容量
按类别构造
低到中等容量
独特项
高
低到中等
低
低到中等
中等
数据易
变性
低
低
低
高
中等
事务量
低
中等到高
中等到低
高到非常高（数量
上有大幅波动）
中等到低
旧式集成/复杂性
低
中等
高
高
高
页面阅
览数
高到非常高
中等到高
中等到低
中等到高
中等
同样，站点还要考虑现有的主要系统负载组件的情况，不能随意提岀现在的技术也无法实现的要求。
而且根据以往经验，电子商务网站的比较合理的组件应该有以下几个部分：
1.Web服务器
2.Web应用服务器
3.网络
4.目录和安全服务器
5.防火墙
6.现有的业务服务器
7.数据库服务器
在了解了环境、对工作负载进行了分类分析以及确定了该采用的组件之后，接下来的步骤就该选择应该应用的缩放技术。
缩放技术是为了未来的改动而考虑的，不一定现在就要实现但是要留下准备的余地。
一般来说其目标有三个：
增强组件处理能力或提高组件速度。
这是最直接也是最容易见效的方法，譬如更换成更快的处理器、
更大的主存空间，增加网络带宽。
提高组件/系统的效率。
效率的低下导致组件资源消耗在不该消耗的地方，不光浪费了宝贵的资源，
而且也增加了系统的不稳定性。
提高组件或系统的效率可以不需要增加硬件的开支，例如，将新闻网站的突发重大新闻或者是搜索引擎的常用搜索结果的优先级提高，使得它们被放在读取速度更快的储存空间内
转移或减少组件上的负载。
当一个网站的负载不均衡的时候，例如购物网站上本来期望是文字和图片的数据更重要，但是发现流媒体（包括视频流和音频流）的访问率比预计的多了很多，而投资上又不允许进行组件的更新，就可以考虑将某些流媒体的画质、音质降低以减少带宽占用，甚至取消媒体的功能。
虽然这样是迫不得已，但总好过继续让系统处在高风险低效率的状态。
1.对应的，伸缩技术也有如下几项：
2.使用更快的机器
3.创建机器群
4.使用特殊的机器
5.把工作负载分段
6.批处理请求
7.整合用户数据
8.管理连接
9.高速缓存
技术与目标是紧密关联的，有的技术能达到的目的，其他技术可能就不行。
通过下面的这个表来对症下药，这才能取得最好的效果。
表5-6伸缩技术同伸缩目标之间的联系
伸缩技术
提高能力/速度
提高效率
转移/减少负载
1
使用速度更快的机器
V
2
创建机器集群
V
3
使用特殊机器
V
V
4
对工作负载进行分段
V
V|
5
批处理请求
V
6
整合用户数据
V
7
管理连接
V
8
高速缓存数据和请求
V
V1
同时，还有一些限制，使得决策者不能随意的选择技术。
主要的限制有三种：
虽然这项技术有益，但目前无力负担在该技术上的投资
确定该技术提供的伸缩超岀了需要成本/收益分析表明该技术得不到合理的回报
1.接下来的步骤，就是把这些选定的技术应用到实际项目中。
这一切都完成之后，还有一点很重要,就是要在运行一段时间后重新评估这个方案的合适与否，不合适的地方在哪儿，并重复上述过程以改进。
1.下面是一些实践过的改进方法，经过证明这些方法确实能极大的改进组件性能：
2.增加了可以提高Web可并行处理请求数的Web服务器线程。
3.向数据库服务器添加索引减少了I/O瓶颈。
4.更改一些操作系统变量的缺省值使线程应用程序可以使用更多堆。
5.高速缓存显著的减少了到数据库服务器的请求数。
6.增加Web服务器的数目改进了负载平衡。
升级数据库服务器增加了吞吐量。
第五章系统容量规划
5.2.4一个容量规划案例的初步设计假设有一帮年轻人，决定要建立一家专门提供付费音乐下载的网站。
先且不论他们的成功概率，但至少可以帮他们做做容量规划的一个设计。
当然，设计肯定还是粗糙的，真正要实际投入的设计还得复杂得多。
电子商务模型
商务类型：
B2C服务，就直接面向消费者
发送类型：
只提供Internet上的实时数字交付。
客户在网上付款之后就能获得某个音乐的下载权和专有播放权。
使用第三方服务：
有广告链接，以及网上付款的功能。
定量描述符：
总歌曲数：
在线的所有音乐的数量。
音乐分类：
有若干类音乐风格，以及每个类下面还有若干子类风格。
每一首音乐都要有每周的销量统计和查询统计，当然也该扩展到每一类的音乐有销量和查询的统计。
注册的用户：
对每个已经注册的用户，该记住他的个人喜好和付款信息。
客户的喜好：
以听流行音乐居多。
购买音乐的趋势：
往往同一客户会相对固定其购买音乐的种类，甚至于固定于某个歌手的音乐。
用户的组成：
大部分是青年，小部分是专业人员（寻找音乐的材料），其他的较少。
运作时间：
每周7天，每天24小时。
功能模型这个音乐购买服务应该包括以下功能：
音乐搜索和选择功能：
根据给定的音乐分类、歌手名字、歌曲名称等等信息，找到符合条件的音乐。
这个交互模型应该包括两个HTML表单以及在HTML表单和CGI脚本中使用的网络技术。
这里不使用认证。
音乐预听功能：
可以预听某首歌曲的十秒钟（当然这是预先挑选出来的十秒钟）。
这个交互模型应该包括一个HTML表单以及在HTML表单使用音频流媒体的技术。
这里不使用认证。
个人资料填写：
在用户注册或者登录后需要修改自己的资料的时候，提供一个表单让用户填写。
这个交互模型应该包括一个HTML表单以及在HTML表单和CGI脚本中使用的网络技术。
这里通过SSL使用认证。
选择音乐的总览和确认：
将这次选择的所有歌曲都列在表单里，并且可以删除某些现在觉得不用购买的歌曲，并最后确认。
这个交互模型应该包括一个HTML表单以及在JavaApplet中用来即时显示选择歌曲信息和总金额统计的网络技术。
这里通过SSL使用认证。
付款：
用网上的信用卡帐号付款，或者采用本网站的专用付费卡付费。
这个交互模型应该包括一个
HTML表单以及在HTML表单和CGI脚本中使用的网络技术。
这里通过SSL使用认证。
下载音乐：
付费之后就可以获得下载对应音乐的权限，并给出下载的链接。
这个交互模型应该包括一
个HTML表单以及在HTML表单和CGI脚本中使用的网络技术。
这里通过SSL使用认证。
以往购买查询：
客户查看上次购买的歌曲列表。
这个交互模型应该包括一个HTML表单以及在HTML表单和CGI脚本中使用的网络技术。
这里不使用认证。
商务发展分析
广告宣传效应。
通过在平面媒体和其他网站上的广告宣传攻势，会有更多的客户来这个站点访问。
对应的，服务器的负担将明显加重，尤其在傍晚时的高峰期。
一开始将是查询功能的频繁使用，待到广告效应的影响逐渐稳定之后，购买功能和下载功能则会增长不少。
音乐总量的增加。
这包括两个方面：
一个是歌曲数量的增加，因为要不断添加最新的流行专辑和素材，以及过去遗漏的音乐的补充；另一方面是指选用音质更好的版本、保护更周全（譬如加入了防拷贝的功能）
的文件格式，这将导致音乐库容量的增加，对存储器及带宽的要求更高。
MTV的引入。
不少流行歌曲都会拍摄MTV以利用电视的影响力，可能是免费也可能是付费。
也可以
购买对应歌曲的MTV版本，这使得带宽的负担和存储器的负担急剧加重，并且文件格式会更加复杂。
用户论坛的建立。
用户可能希望在这个网站上跟其他用户交流，尤其是同一歌手的歌迷，他们的要求更加强烈；这么做也有助于网站的关注度增加。
这可能要另外的增加一台论坛服务器，甚至于另外的带宽。
为用户推荐音乐。
用户如果哪天厌烦了自己手动的选择歌曲，可以让网站自己推荐。
网站通过查看该
用户的购买记录（如果有的话）再结合现在的热门歌曲，智能的向用户推荐，然后用户就能轻松的选择。
这将加重多个服务器的CPU负荷，降低响应客户的时间。
功能发展分析
广告宣传。
功能模型没有变化。
音乐总量的增加。
功能模型没有变化。
MTV的引入。
可能预览时的流媒体格式要更加多样。
用户论坛的建立。
用户可以查看、搜索所有帐号的文章，以及发表、修改和删除自己的文章，还有跟其他用户的交流。
这个交互模型应该包括六个HTML表单以及在HTML表单和CGI脚本中使用的网络技
术。
这里不使用认证。
为用户推荐音乐。
推荐音乐实际上是一种特殊的搜索，可以在输入搜索的条件的页面上增加一个自动推荐的功能按钮，其他功能不需要改变。
客户行为描述和发展分析
图5-11是现有的客户行为模型图。
图5-11在线付费音乐下载的客户行为模型图
升级会员 