Web体系结构发展规划
blueski推荐 [2006-4-11]
出处:IBM DevelopWorks
作者:不详
本文介绍了 IT 专家用于确定其网站能否满足未来需求以及评估网站工作负荷与基础结构变化的方法。同时也介绍了基于对不同组件如何组合才能最好地满足特定工作负荷模式性能目标的分析来配置网站的概念,利用这一概念就可能削减原型设计和强度测试的成本。 本文包括特定的数据和和图形范例,以及您可用来分析用户在在线购物、银行业务和贸易站点上的行为的方案脚本范例。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
电子商务的增长使得以下一点变得至关重要,那就是必须确保支持网站的 IT 基础结构能够为公司的信息、产品和服务提供可用、可伸缩、快捷以及高效的访问。CIO 及其小组面临着前所未有的挑战,那就是必须将停机时间和网络瓶颈降至最低程度,并最充分地利用构成其电子商务基础结构的软硬件。 支持最大容量网站 (HVWS) 的 IT 基础结构一般包括多层机器,常常称为层 (tier),如图 1 所示。每层包含多台机器(从两台到数百台)来提供该层上所运行功能的容量和可用性。每层提供一组特定的功能,例如提供内容(Web 表示服务器)、提供集成业务逻辑(Web 应用程序服务器)或处理数据库事务(事务和数据库服务器)。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
图 1. 电子商务的多层基础结构 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
虽然复杂性越来越高,但仍可以分析典型的 IT 基础结构并开发相关的模式,以协助对如何满足未来需求作出预测和规划。 容量规划方法 我们的容量规划方法基于对多家大型网站(包括 IBM 的网站)的分析,以及我们与那些寻求改进网站性能、精确地规划工作负荷、进行基础结构更改以满足未来需求的的大型客户的不断接洽。该方法包括以下四个步骤:
无论您是在考虑更改当前站点还是规划新网站,这些步骤都同样有效。 本文将集中介绍容量规划技术。实施这些技术将影响您的 IT 组织、流程和人员;本文并不涉及这些相关的含义。 我们小组的容量规划技术是对 IBM 的电子商务模式的补充(请参阅参考资料),因为您可以将我们描述的每种工作负荷模式对应到站点设计的一种电子商务模式。无论您使用哪些方法设计您的站点,这种容量规划方法都可作为那一工作的补充,并为管理您的容量需求打下基础。 步骤 1. 确定您的工作负荷模式 请参考以下的工作负荷模式说明(或参阅工作负荷模式概览以了解其本质,并将其汇总到表格中)来确定您的工作负荷模式:
步骤 2. 评测当前站点的性能
您在规划未来时必须了解现在。您需要以下站点指数:容量(点击数、网页流量、交易、搜索)、抵达率、分类响应时间、用户会话时间、并行用户数量以及处理器和磁盘的利用率。如果您正在规划新站点,则可利用您编写站点概要的相关经验进行评估,或者基于资深顾问(如我们的 HVWS 小组)的站点概要进行评估。 我们对多种工作负荷模式下电子商务基础结构性能的分析说明了以下这一点:工作负荷模式的复杂性(例如突增抵达模式)可极大地影响资源需求、吞吐量和用户请 求的延迟时间,具体表现在更高的平均响应时间和更大的响应时间差异。如果没有最佳的适应性资源管理和控制,基于响应时间的服务级协议 (SLA) 就无法实现。站点的容量要求不断提高,而其提供可接受的性能和可用性的能力却在降低。 在分析您的当前站点时,要记住将网页的设计考虑在内。IBM 的研究表明您可以遵照许多惯例来减少您的网页的下载时间。网页都具有相同的组件和指数,如页面大小和项目数,因此,您可以而且应该着眼于将其下载时间降至 最低程度。做“正确”的事并不是总能成功,而且有些组件或指数是网页设计员无法控制的。另外,对站点性能感兴趣的人员都应该了解这些因素以及其相关的负面 影响。表 1 汇总了 15 个不同网站的页面设计。设计各不相同,但都强有力地表明网页设计是一个重要的性能成分;如果管理得当,则它们可以提高网站的容量。在这个彩色的表中,良好 或优秀的设计标为绿色;稍差的设计标为琥珀色,而很差的设计标为红色。有关优化您的网页以便加快下载的详细信息,请参阅我们小组的前一篇论文," Design pages for performance"。 表 1. 网页设计范例。绿色表示良好;红色表示很差;琥珀色表示勉强。
合理确定您的工作负荷模式,为评测和了解站点复杂性做好准备。每一种工作负荷模式都有一类相关的用户需求。图 2 显示了与在线购物工作负荷模式相关的用户需求类别范例。 每个类别是按照请求抵达网站的方式以及满足请求所需的资源来划分的。影响抵达的主要因素包括标准(临界)分布、相关性结构和季节性。总之,IBM 的分析表明,复杂行为包括短尾和长尾分布、短距离和长距离的相关性、强季节性和周期性以及地理效应。在这些条件下,站点请求的独立指数输入时间间隔这一典型假定不成立,所以必须采用非传统假定来解决问题,这需要复杂的数学算法。IBM 对这些指数的数学研究使人们能够开发更好的模型,以便了解并预测这些关系和行为的影响。 图 2. 每种工作负荷模式都有相关的一类用户请求 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
分布和相关性 突增和变化极大的点击率是影响站点性能和可用性的最显而易见的工作负荷模式复杂性之一。在传统模型中,各个请求相互独立,流量突增幅度的变化相对较小。这些分布属于短尾分布类。HVWS 的流量突增引起了长尾分布和强相关性结构。1998 年长野奥运会的流量模式恰好说明了这一点,如图 3 所示。这种请求突增是由某些特殊事件引发的,例如,在这次奥运会上,日本获得了跳高滑雪项目的金牌。请比较亚洲的长尾分布和当日欧洲的短尾分布之间的差异。另外,请注意每天、一天中以及不同地点间的独立性结构。 图3. 1998 年长野奥运会流量模式 IBM 的 Wimbledon 2000 网站也在最忙碌的一天,2000 年 7 月 7 日,显示出极度突增现象。 图 4. 破记录那天 IBM 的 Wimbledon 网站 非传统请求流量对 Web 服务器造成压力。长尾分布的流量突增所产生的性能下降要比短尾分布所产生的性能下降大几个数量级。与短尾模型相比,长尾分布发生极端流量突增的情况更频 繁。另外,相关性结构可导致在邻近的地方发生流量突增现象。对于这种输入流量特性,性能评测结果,尤其是响应时间,与输入流量具有相似的指数。这有助于解 释为什么一些体育和电子商务网站比相对简单的网站(例如只提供静态内容的大学网站)更难维护。 就 SLA 而论,长尾分布的同级服务比独立的短尾请求流量要求具备更为强大的一组服务器。为了确保获得优良的性能,您必须注重流量的高峰期,因为请求的巨增是导致性能降低的首要元凶。这有些繁忙站点需要更多的峰值储备空间(空闲容量)来处理这些容量,例如大容量在线贸易站点用 3:1 的比例来保留空闲容量。 季节性 图 6 显示长野奥运会网站季节性流量范例。该图绘制了从 2 月 9 日到 16 日间每 5 分钟内所有服务器接收的请求数。尽管每天的周期变化很大,但请注意每天包含三个峰值,总体流量密度在每个工作日开始增加,然后在周末减少。这些模式每周反复,说明了与周周期对应的季节性变化。 图 5. 用长野奥运会一周的流量来说明的季节性范例 季节性请求会降低 Web 服务器的性能,因为在高峰期内,同一时间内将会出现大量的请求。关键问题在于这个峰值有多“高”,以及高峰期会持续多长时间。这两个问题的答案对 Web 服务器的功能应有多强才能有效处理特定的 SLA 有极大的影响。为了圆满处理请求流量,Web 服务器的容量应该与峰值请求时的容量接近,并且还要留出一定的峰值贮备空间,以防意外的增长。 确定工作负荷模式的其他因素包括页面浏览量和交易量、搜索的容量和类型、交易复杂性、数据变更率以及安全性考虑。 本节后面的内容将介绍可用来获取完成容量规划所需的评测结果的方法。 获取站点评测结果 表 2. 一个在线购物站点的基准评测方法范例
通过分析典型的用户访问,就能够创建未来用户访问的概率。例如,在线购物者通常都是在浏览,也可能查询,偶尔会购买。您可以开发各种脚本来描述用户的访问。脚本 1、2 和 3 包含所有适用于您的情况的在线购物、在线银行和在线交易方案的脚本范例。 脚本 1. 在线购物方案的脚本范例
脚本 2. 在线银行方案的脚本范例
脚本 3. 在线贸易方案的脚本范例
借助方案脚本和评测结果中的数据,您就可以创建一种转换矩阵。图 6 是在线购物访问的转换矩阵范例。通过查看与脚本范例相关的转换矩阵,可以很容易看出浏览和搜索请求;当用户决定 添加(到购物袋)并付款时,就产生买卖请求。 图 6. 在线购物访问的转换矩阵范例 步骤 3. 分析趋势并设定性能目标 表 3. 一个在线购物站点当前和规划中的评测结果
准确预测请求模式的能力是容量规划的重要要求。我们的预测技术部分基于构建一套数学方法和模型,这些方法和模型用来分离并确定网站请求模式中的趋势、相关性、季节效应、随机性以及其他关键行为(请参见参考资料中的 4、6、7 和 8)。例如,这包括与长尾分布组合在一起的分段自回归移动平均 (ARIMA) 的使用。图 7 是准备用于我们的模型的请求模式范例;该图显示了长野奥运会网站 1 小时内每秒接收到的请求数。从这些结果中拟合出的曲线显示在数据点中间。 由于每个关键流量指数都可以在很大的范围内变动,我们使用一套数学方法评估未来请求模式中每种指数的强度,并将其调整到预计的强度(请参阅参考资料中的 4、7 和 8)。然后,我们将这些调整后的数学模型结合在一起,以确定并预测请求模式。通过使用我们的数学方法隔离、确定并预测请求模式中的趋势、相关性、季节效应、随机性和其他关键行为,我们研究出一种一般的方法,这种方法能够比当前采用的其他方法更准确、更有效地预测请求模式。 图 7. 长野奥运会期间一小时内每秒的请求数 我们的方法已被实践证明极为有效,已被用于预测短期和长期的实际站点请求模式。我们特意采用该方法对最近 IBM 主持的体育赛事站点的峰值小时请求容量进行了预测。在过去三年中,我们一直基于网站的请求模式以及 95% 的置信区间来作出评估。在其他方法中,我们采用了一阶变化率方法评估每年的流量密度伸缩因数。我们通过对 1997、1998 和 1999 年的比较得出了指数式增长的趋势。我们还使用 2000 年的预测伸缩因素,并结合我们调整 1999 年峰值小时流量模型的方法,预测出了 2000 年的峰值小时流量模型。结果与我们的预测相符:我们的预测与站点的实际峰值容量非常接近。另外,这些方法在预测将来季节性事件(如圣诞节在线购物高峰)的 请求模式方面也获得了同样的成功。我们还用此方法预测了短期(数天、数周)的请求模式;同样,预测与站点的实际请求模式相当一致。 步骤 4. 确定基础结构替代模型 IBM 正在为 HVWS 容量规划开发的技术依赖于图 8 中描绘的三种模型。 图 8. HVWS 容量规划模型 业务模型或业务使用模型定义了电子商务模式和工作负荷模式。每种工作负荷模式都有一个用户行为模型。每种工作负荷模式包含几类用户请求。每一类的抵达模式和路由(转换矩阵)站点访问者都包含用户行为模型。满足每类用户请求的软硬件资源和数量包含 基础结构模型。 基础结构模型处理浏览、搜索和购买交易。该模型假定:
图 9. 多层网站(不包括防火墙层) 我们设计了一个排队网络的类,用以确定多层体系结构的模型,以便分析不同级别的性能。我们还进一步得出了这些模型在不同输入流量模式和不同时间范围内的多 种解决方案。这一系列数学模型和解决方案非常通用,足以抽象当前软硬件的详细信息,但它同时又非常详细,足以生成有意义的性能结果。我们考虑一下排队系 统,其中每层的资源由多服务器队列模拟,这些多服务器队列之间存在特定的关系。这些关系通过评测或评估的工作负荷指数确定。我们然后根据一组用户需求解决 性能/容量问题,例如并发用户数、响应时间或吞吐率。我们还制定了一个独特的公式,使我们能够评估系统处于以下状态时的行为:峰值需求明显高于平均需求, 而且不可忽略用户访问大量数据的概率。 我们的方法具有极大的灵活性,可根据用户的需求和工作负荷指数确定水平和垂直方向的伸缩,或二者的组合。例如,我们可以通过添加另一台服务器,或者在指定服务器上添加另一个处理器来增加 Web 服务器的数量。有了适当的网站和工作负荷数据,我们就能够根据我们的性能模型和分析得到性能评估。 我们已为多家 IBM 托管的网站制定了容量规划。图 10 就说明了这样一个网站,并反映了采用当前的网站数据,然后根据当前的数据、趋势和目标制定规划来校正我们的模型的过程。在图 10 中,前三个响应时间曲线反映了用于按步骤 2 中的方法校正模型的当前数据。通过分析当前的设计和组件信息,我们就可以对第四条曲线进行规划。 参考图 10,结果显示当请求流量较小时,一台前端服务器已足以处理负载。随着流量的增加,响应时间曲线保持平直,直至该前端 CPU 的利用率达到 90%(每小时 280 万次点击)为止。这时,负载的少量增加就会导致系统很快死机,前端服务器以越来越低的速度尝试处理越来越多的文件,这样几乎没有人能感受到令人满意的响应时间。这意味着前端服务器已成为瓶颈。因此,我们需要添加前端服务器,添加以后前端服务器的 CPU 利用率就会按我们的预期下降。响应曲线变成平直状态,直至前端服务器的 CPU 利用率重新达到 90%(每小时 510 万次点击),这时我们需要考虑添加另一台前端服务器。只有当大约 15 台前端服务器每小时处理约 2800 万次点击时,后端服务器才会成为瓶颈。 图 10. WebSphere 商务网站的伸缩 图 11 中的图形是我们在分析特定软硬件组件的性能目标时得到的范例。 图 11. 显示性能指数的图形范例。 小结 当然,容量规划的课题还需继续研究。越来越多的有价值的信息可供您使用(请参阅参考资料中的 10),令人振奋的新工具正在不断出现,而且按需求提供容量的选择也将极大地增强对流量增长作出反应的能力。IBM 的 HVWS 着眼于发现并总结现代的设计方法,以提供更大的容量和可伸缩性。该小组将继续改进它的方法,开发包含该方法的工具,调整数学方法,并致力于诸如网络高速缓存和快速增长的企业对企业工作负荷这类领域所提出的更多挑战。在满足未来需求的同时有效规划并降低成本的前景十分广阔。 参考资料(序号与正文的引用对应)
|