原文地址(英语):http://scn.sap.com/community/businessobjects-web-intelligence/blog/2014/12/18/revisit-the-sizing-for-your-deployment-of-bi-4x-web-intelligence

原作者: Ted Ueda 现就职于SAP

2015好!希望您有一个满意的2014。这里,我想提醒您关注一下

    重新规划部署BI4.x Web Intelligence Processing Servers

如果在过去的8个月您已经做完了以上的任务,那非常好。但是也请您在2015年日历上找一天重新做下这件事情。如果去年您没有做,我强烈推荐您在2015Q1练习一下。

我从BI4.0 Ramp-up阶段就开始支持Web Intelligence,到4.02011916日正式发布,再到BI4.1发布。已经过去4年了,在这4年里,有3个非常重要的考量会影响到BI4.x WebI系统是否能平稳运行,(1)sizing (2)sizing (3)还是sizing

如果您对BI系统构架做了不适当的sizing,那么您会遇到系统性能,稳定性,可用性的问题,如果现在没有相关问题,在您以后系统使用中也会发生。也许您会需要花很多时间在和技术支持部门的交流上,不过技术支持会首先询问您上次什么时间做的sizing

如果回答是20142月以前,那么我们会推荐您文章Business Intelligence Sizing and DeploymentBI4 sizing guide20142月更新版。在这个版本中,关于Web Intelligence的推荐配置有了更改。

规则1:参照最新的sizing guidesizing

当您打开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.1sizing guidebest practices来做BI4.1sizing

曾经有一位客户抱怨他们的BI4.0系统构架的Sizing文档其中引用了XI3.1的文档。他们的系统使用了XI3.1同样的sizing构架。这当然不会好用,他们的系统发生了很多问题,但是在他们重新进行sizing之后,这些问题就消失了。

XI 3.1BI 4.1是完全不同的东西,用XI3.1的构架来研究BI4.1就好比让马拉雪橇。不论这个东西有多么强大他们都不可能变成另一方。

这两个版本最主要的不同:

  • BI 4.1 WebIPS64位程序。XI3.132位程序,即使安装在64位机器上。
  • .BI 4.1 WebIPSquerychart生成的服务都分布在了不同的serviceXI3.1是进程中处理。

因为以上不同,XI3.1sizing best practicesBI4.1中是不合适的,甚至是有害的。我们来看下XI3.1best practices以便与BI4.1做下对比:

XI3.1 – 一个CPU可以配置一个WebIPS

BI4.1 – 一个机器可以配置一个WebIPS

XI3.1时代,CPU数量和WebIPS数量一致其实没什么必须的理由因为WebIPS线程模式在多个CPU core中可以平行出来报表的请求。每个线程可以出来一个文档需求,但是不同的线程可以在不同的CPU Core中进行。WebIPS不会强制绑定CPU Core

XI3.132位系统,所以一个能够使用的内存资源会限制一个WebIPS能够出来的job数量。所以那个时候,合理内存使用是XI3.1sizing WebI的重要问题。随着使用的增加,会对系统处理能力增加提出更多要求。由于内存资源限制,最直接的方法就是增加WebIPS的数量。一个CPU可以配置一个WebIPS其实是增加机器数量的重要标准及规则。

但是BI4.1WebIPS64位程序,内存方面有很大提升。如果可以的话,我会推荐客户去更改BI 4.x WebIPS 的内存设置。

Sizing Guide中,BI4.1WebIPS是被IO限制的。你需要确保WebIPS能够得到的IO带宽,特别是虚拟机环境,只能是每台机器一个WebIPS

曾经在BI4.0早期有过不同机器直接failover的问题(Document Recovery Service的相关问题)。当时我推荐书一台机器2WebIPS(同一台机器两个WebIPS直接WebI sessionfailover不会使用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 WebIPS64位程序而且已经进行过改进,在内存不足之前就已经能够适当处理这种情况。“启用内存分析”就相当于无病吃药了。实际上,一直启用它有可能会造成系统不稳定这里有客户曾经的事例。

在您下次计划停止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.1WebIPS有更大的能够,足够可以处理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.1Web Intelligence 稳定和高效运行的最重要的考量点。在本篇blog中,我简要介绍了Web Intelligence Processing Serversizing。在下一篇中,我会介绍Adaptive Processing Serversizing

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

    1. Peter Han

      如果您使用BI41系统,文中建议使用本地文件系统而不是网络共享。Output Cache Directory默认值虽然是空,但其实是使用了本地文件系统<BO 安装目录>\SAP BusinessObjects Enterprise XI 4.0\Data这个目录,所以您不需要做特殊设置即可。如果您必须要使用网络共享目录,那请参考Input/Output File Server的设置方式

      (0) 

Leave a Reply