原文地址(英语):http://scn.sap.com/community/businessobjects-web-intelligence/blog/2014/12/18/revisit-the-sizing-for...
原作者: ted.ueda 现就职于SAP
2015好!希望您有一个满意的2014。这里,我想提醒您关注一下
重新规划部署BI4.x Web Intelligence Processing Servers
如果在过去的8个月您已经做完了以上的任务,那非常好。但是也请您在2015年日历上找一天重新做下这件事情。如果去年您没有做,我强烈推荐您在2015Q1练习一下。
我从BI4.0 Ramp-up阶段就开始支持Web Intelligence,到4.0在2011年9月16日正式发布,再到BI4.1发布。已经过去4年了,在这4年里,有3个非常重要的考量会影响到BI4.x WebI系统是否能平稳运行,(1)是sizing (2)是sizing (3)还是sizing。
如果您对BI系统构架做了不适当的sizing,那么您会遇到系统性能,稳定性,可用性的问题,如果现在没有相关问题,在您以后系统使用中也会发生。也许您会需要花很多时间在和技术支持部门的交流上,不过技术支持会首先询问您“上次什么时间做的sizing?”
如果回答是2014年2月以前,那么我们会推荐您文章Business Intelligence Sizing and Deployment,BI4 sizing guide,2014年2月更新版。在这个版本中,关于Web Intelligence的推荐配置有了更改。
规则1:参照最新的sizing guide做sizing
当您打开Sizing这篇网页时,我建议您选上"Follow"按钮,这样您就可以在网页有更新时随时得到最新消息。或者去https://service.sap.com/sizing页面,找到BI 4 Sizing Guide,点击"Subscribe"。
在最新更新中,对Web Intelligence services的推荐配置方面有更改,所以我强烈推荐您详读整篇文章,以确认您的BI4.1系统确实按照推荐的方式配置。
我和Platform Product Owner, Sada进行过讨论,他估计在BI4.2之前Sizing guide不会更改。但是上面说的可不算数,在您做sizing之前,一定要下载最新版本的Guide。
规则2:不能使用XI3.1的sizing guide或best practices来做BI4.1的sizing
曾经有一位客户抱怨他们的BI4.0系统构架的Sizing文档其中引用了XI3.1的文档。他们的系统使用了XI3.1同样的sizing构架。这当然不会好用,他们的系统发生了很多问题,但是在他们重新进行sizing之后,这些问题就消失了。
XI 3.1和BI 4.1是完全不同的东西,用XI3.1的构架来研究BI4.1就好比让马拉雪橇。不论这个东西有多么强大他们都不可能变成另一方。
这两个版本最主要的不同:
- BI 4.1 WebIPS是64位程序。XI3.1是32位程序,即使安装在64位机器上。
- .BI 4.1 WebIPS的query和chart生成的服务都分布在了不同的service。XI3.1是进程中处理。
因为以上不同,XI3.1的sizing best practices在BI4.1中是不合适的,甚至是有害的。我们来看下XI3.1的best practices以便与BI4.1做下对比:
XI3.1 - 一个CPU可以配置一个WebIPS
BI4.1 - 一个机器可以配置一个WebIPS
在XI3.1时代,CPU数量和WebIPS数量一致其实没什么必须的理由-因为WebIPS线程模式在多个CPU core中可以平行出来报表的请求。每个线程可以出来一个文档需求,但是不同的线程可以在不同的CPU Core中进行。WebIPS不会强制绑定CPU Core。
XI3.1是32位系统,所以一个能够使用的内存资源会限制一个WebIPS能够出来的job数量。所以那个时候,合理内存使用是XI3.1的sizing WebI的重要问题。随着使用的增加,会对系统处理能力增加提出更多要求。由于内存资源限制,最直接的方法就是增加WebIPS的数量。一个CPU可以配置一个WebIPS其实是增加机器数量的重要标准及规则。
但是BI4.1的WebIPS是64位程序,内存方面有很大提升。如果可以的话,我会推荐客户去更改BI 4.x WebIPS 的内存设置。
在Sizing Guide中,BI4.1的WebIPS是被IO限制的。你需要确保WebIPS能够得到的IO带宽,特别是虚拟机环境,只能是每台机器一个WebIPS。
曾经在BI4.0早期有过不同机器直接failover的问题(Document Recovery Service的相关问题)。当时我推荐书一台机器2个WebIPS(同一台机器两个WebIPS直接WebI session的failover不会使用Document Recovery Service)。但是那都是过去的事情了。
XI 3.1 – 启用内存分析
BI 4.1 - 不要启用内存分析
(2015-01-16更新)
我把这条加上因为这条建议不是经常被人们提起,但是我从一位WebI开发出得到消息,这条现在是推荐关注的。
BI 4.1 - 不要启用 Memory Analysis。现在默认状况下他是启用的(之后的版本可能会更改),但是他只是XI3.1时代的延续,对于现在来说不需要,甚至会因其发生问题。
在XI3.1时代,需要作出最大的努力就是珍惜使用32位内存空间。启用内存分析,在超过“内存上限阈值”时,会阻止WebIPS新进来的任何处理任务,而并不是存储报表。这个功能的最初目的是让用户在WebIPS内存枯竭的时候有个机会存储未保存的作业。并希望在达到“内存最大阈值”之前,能够阻止新的任务以使WebIPS能够在crash之前重新恢复功能。
BI 4.1 WebIPS是64位程序而且已经进行过改进,在内存不足之前就已经能够适当处理这种情况。“启用内存分析”就相当于无病吃药了。实际上,一直启用它有可能会造成系统不稳定-这里有客户曾经的事例。
在您下次计划停止BI Platform的时候,请登录CMC –>服务器–>服务器列表,取消所有WebIPS的“启用内存分析”。
XI 3.1 - “最大连接数”设为50,之后根据需要少量增加
BI 4.1 - “最大连接数”设为200,之后根据需要少量增加
“最大连接数”通常是由系统中活跃用户的数量决定的。如果您推算系统中会一直有200名活跃用户,可以将“最大连接数”设为200。但是会有的问题,以为WebIPS会将连接一直打开,知道Idle timeout。
所以即使您最多有200名活跃用户,还是有可能会出现200个以上open connections。所以会建议您根据需要少量增大这个参数。
对比旧的Sizing guide,经过多次测试,BI4.1中“最大连接数”设为200是最佳设置,BI4.1的WebIPS有更大的能够,足够可以处理50以上open connections。
如果您的系统有超过200名活跃用户,那么就需要增加一台机器,多部署一台WebIPS是明智选择。
XI 3.1 – 所有WebIPS的“Output Cache Directory”设置为同一个网络共享地址
BI 4.1 - WebIPS的“Output Cache Directory”设置为本地磁盘,而非网络共享地址
WebIPS初次打开某个WebI报表的时候,必须解压这个.wid文件,并内部生成相应的内容并解析。他会缓存这个生成的内容到磁盘上,在随后的应用中会使用他们。这些动作-打开/解压/解析需要经过很多处理。这样设计的好处就是下次再用这个WebI文档,过程就是先在缓存中查看是否已经有打开过的相应文档。如果有,就使用缓存的内容,不必在打开/解压/解析这个.wid。
现在,使用同一个Output Cache Directory的WebIPS可以共享其中存储的缓存内容。
这极大提高了打开WebI文档的速度,不同的WebIPS可以使用缓存中的数据来打开同一个报表,不论这个“打开”的要求是发给哪个WebIPS的。
在XI3.1,系统中经常会部署很多个WebIPS。一个CPU Core一个WebIPS,每50个活跃用户一个WebIPS。看到有16个WebIPS集群已经不是稀奇事。如果没有缓存共享,那么很有可能打开一个这个WebIPS没有打开过的WebI报表会极大影响性能。
但是在BI4.1里面,不需要那么多WebIPS,因为推荐的是一台机器一个WebIPS,每200个活跃用户一个WebIPS。所以XI3.1需要8个的时候,BI4.1只需要2个。缓存丢失的几率很小。另外,BI4.1的限制是在IO上,如果缓存是放在网络共享地址,那么系统性能将会被极大的限制。
因此,BI4.1建议WebIPS的“Output Cache Directory”设置为本地磁盘,而非网络共享地址。
不推荐使用网络共享地址来作为Cache Directory是有以下几点考量。
曾经有过网络共享地址来作为Cache Directory时,无法进行磁盘清理,而磁盘会因此被占满(SAP KBase 2050700)。网络连接问题会导致WebIPS停止响应(SAP KBase 1757824)。网络问题造成无法读取缓存造成WebIPS间断性shut down(SAP KBase 2057341) - 我将网络地址改为本地磁盘解决了问题。
总之,BI4.1建议WebIPS的“Output Cache Directory”设置为本地磁盘。
如果你有一个非常复杂并且庞大的,会让WebIPS处理很长时间来解析的WebI报表,你可以新建一个服务器组其中包含一个特定的WebIPS。指定那个WebI报表用这个专用的WebIPS来处理,这样就不会调用其他的WebIPS,而且缓存会保存。
规则3:经常重新进行sizing。并谨记sizing guide是起始点-是一份说明,不是规则
您对BI系统的使用不会是一成不变的-会创建新的文档,报表数据量会以倍数增长,查看报表的用户会增加等等。这是件好事,因为这说明您的BI系统是个不错的系统所以人们会不断增加对他的需求。但是这也就需要您不断的重新规划,确定执行的文档的个数与大小,监时与观察WebI Processing Server的负载。
至少每年做一次Resize。
BI 4 Sizing Guide是起始点。编写这个Guide的工程师有着非常丰富的测试经验并且能够做出合理的推荐。但是在他们的测试中,比如“活动的用户”的活跃程度,“大”的文档的大小程度都有别于您的实际的配置。只有您自己明白您的系统的情况,Sizing等同于tuning。您有可能一年只对您的系统做一次sizing,但是对于您的系统的健康度的观察却是要时时进行的。
规则4:分割并size Adaptive Processing Server
这是非常重要的一条规则,同样也是一个topic。下篇blog我会介绍。
这样说吧,BI4.1中初始安装的单独的Adaptive Processing Server是非常不适当的,还不如一个POC系统。如果没有进行合理分割并size (SAP KBase 1694041),您的系统会或多或少出问题。
总结
Sizing是保证SAP BusinessObjects BI Platform 4.1的Web Intelligence 稳定和高效运行的最重要的考量点。在本篇blog中,我简要介绍了Web Intelligence Processing Server的sizing。在下一篇中,我会介绍Adaptive Processing Server的sizing。