Cognos 云最佳实践

调整架构提供性能和可伸缩性

支持在 IBM 云中大规模部署 Cognos 的最佳实践和建议

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Cognos 云最佳实践

敬请期待该系列的后续内容。

此内容是该系列的一部分:Cognos 云最佳实践

敬请期待该系列的后续内容。

Cognos 8 是一套精密的产品。调整架构可能是一项富有挑战的任务,需要预计系统整体工作负载方面的知识。因此,预计一些架构上的迭代来适当地定制它,满足您的需求。

在为您的云计算实例确定虚拟硬件规范时有几个因素需要考虑。这些因素的组合影响系统可以处理的负载的数量,这个数量每次都是不同的。

在一个典型的数据中心环境中,您必须根据最大负荷做计划,因此 IT 资源通常并未充分利用。然而由于云计算的动态性,最大负荷很容易适应需求,以至于新的计划标准是平均容量需求;资源在需要时可以自动添加,在负载减少时可以自动删除。

在本文中,我们提供了一些常见的指导方针和架构建议,来支持在 IBM Cloud 上的 Cognos 8 大规模部署。

要处理性能和可伸缩性实践,我们来看看:

  • 用户社区和用户的地理分布。
  • 应用程序复杂性(不同层次)。
  • 部署后注意事项。

关于在 IBM Cloud 中安装和配置 Cognos 的更多信息,阅读本系列其余的文章和 Cognos 网站(参考资料)。

用户社区和地理分布

根据本文背景,您的 Cognos 解决方案可以分为三个不同的用户组:

  • Named:所有注册到系统的用户。
  • Active:目前登录到系统的已命名用户,但不一定是处于提交一个请求或者等待一个请求完成的过程中(比如说一个用户正在阅读一个报告)。
  • Concurrent:在提交一个请求或者等待一个请求完成的过程中的 Active 用户。

根据 IBM 在大规模部署方面的经验,这些用户之间一个普遍的观察比分别是 100:10:1 (在任一时刻只有 1% 的 Concurrent 用户),这意味着每 100 个 Named 用户,10 个是 Active 用户,1 个用户处于提交或者执行请求的过程中。

注意,相同系统需要更高或者更低并发比率。然而大多数情况,即使在高峰,并发比率不会超过 5% 到 7%。在计算系统负载时,只有 Concurrent 用户需要被考虑。

另一个需要被考虑的重要因素是,用户社区的地理分布,这也影响着系统的平均负载和最大负载。您用户的时区中的变化可能会对您 Cognos 部署上负载的日模式产生深远的影响。如果您在适当位置有一个可比较的产品服务器,经过一段时间测量其实际负载模式可能对获取精确并发比率有很大的帮助,强烈推荐。

应用程序复杂性

除了考虑 Concurrent 用户平均数的需求外,您的应用程序的复杂性也会影响资源需求。例如,需要复杂数据库或高级格式化的报告需要更多处理报告的能力。这意味着在给定时间内服务的报告数量将被减少。在这些类型的应用程序中支持相同数量的 Concurrent 用户将需要更大的系统容量。

现在,让我们看看用于保持 web 服务器层、应用程序层和内容管理层的可伸缩性和性能的适当平衡的最佳实践。

Web 服务器层

为达成计划的目的,我建议一个环境的大小应该控制在每个现代 CPU 50 个 Concurrent 用户,不考虑用户角色。

然而,要在 web 层支持平均负载,也有两个因素将影响硬件需求的评估:

  • 首先,如果使用的是 Secure Sockets Layer 连通性,支持的 Concurrent 用户评估数量将会减少。
  • 更重要的是,也要考虑解决方案的故障恢复需求,并分配额外 CPU 资源来实现高可用性需求。

应用程序层

如果您正在寻找支持一个高可用性能的 Cognos 解决方案,作出报告和查询处理计划是最重要的考虑因素。报告和查询处理将受 Concurrent 用户数量和您应用程序复杂性的影响。

对于交互式报告,一个常用的指导方针是,首先假设每个 CPU 两个交互报告进程,每个进程 4 个报告执行线程。这就是说每个物理 CPU 有 8 个并发交互式报告请求。

  2 report processes/CPU
x 4 report execution threads
--------------------------------------
  8 concurrent reporting requests/CPU

由于大数据卷同批量报告处理 相关,一般指导方针是假设每个 CPU 两个批处理进程,每个进程有两个报告执行线程。这就是说每个物理 CPU 同时可以执行 4 个并发批处理报告请求。

  2 batch report processes/CPU
x 2 report execution threads
-------------------------------------------
  4 concurrent batch reporting requests/CPU

记住,这些是根据 IBM 经验总结的一般假设;对于不同的解决方案可能是不同的。在云中计算一个 Cognos 解决方案需要的资源时,使用这些一般假设和预计 Concurrent 用户日平均值来确定云计算的硬件需求。

记住,Cognos 8 是专为可伸缩性设计的。在高峰时期添加更多的 Cognos 应用程序服务器来处理更多的系统负载,这同将服务器新实例实例化到系统一样简单。最新添加的服务实例将自动共享系统负载,几乎是立即共享。当不再需要处理能力时,服务器很容易关闭和移除。

Content Manager 层

Content Manager 的性能本质上受一个包或文件夹中对象数量和对象关联的安全性的影响。例如,如果一个文件夹或者包中含有大量对象,当一个用户使用被限制的权限访问对象时,每个对象的用户许可必须被验证来确保安全规则的执行。如果在文件夹中只有少量对象,或者如果整个文件夹是不安全的,需要的资源将会更少。

IBM 在平均使用模式方面的经验建议每 4 个报告处理 CPU 应该分配一个 Content Manager CPU;然而,如果您的应用程序需要更多的 Content Manager 处理容量,那么加倍 Content Manager CPU 分配是合理的。

最后,因为 32 位 JVM 限制于 2GB 内存寻址空间,IBM 建议应该将 Cognos Content Manager 部署到 64 位操作系统上。强烈建议一个 64 位配置用于大规模部署。

部署后注意事项

这些建议只是根据我们在平均使用模式中的经验而来的一般指导方针。因为资源已被部署,系统监控是必不可少的,并且经常引起配置调整。根据故障恢复和负载平衡需求可能需要额外资源。

在 Cognos 网站和 developerWorks 上(参考资料)查看关于云计算中正在运行的 Cognos 的更多信息。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=576912
ArticleTitle=Cognos 云最佳实践: 调整架构提供性能和可伸缩性
publish-date=11082010