核心组伸缩注意事项

高可用性管理器消耗的系统资源(例如,CPU 和内存)量并不是随着核心组大小的增大而按线性增加。例如,高可用性管理器使用的“视图同步协议”需要大量的系统资源以保持与核心组成员紧密耦合。因此,一个大型核心组消耗的资源量可能会变得非常大。

大小相同的不同核心组所需要的“视图同步协议”资源会存在非常大的差别。“视图同步协议”用于核心组的资源量由下列因素确定:
  • 正在运行的应用程序数。
  • 正在运行的应用程序类型。
  • 使用的高可用性管理器服务。

在设置核心组可伸缩性时必须确保:

即使系统在正常运行,也要考虑实现下面的一项或多项可伸缩性技术,用来对大型单元中的高可用性管理器进行伸缩处理。下面是两种最基本的技术:

调整核心组大小

核心组大小会直接影响高可用性管理器处理的以下三个方面,这三个方面又会影响资源使用量:
  • 第一个方面同时也是最重要的方面是,对一组活动的核心组成员建立“视图同步协议”。此活动通称为视图更改
  • 第二个方面是,高可用性管理器在后台定期运行的发现和故障检测任务。
  • 第三个方面是,其他产品组件在使用高可用性管理器提供的服务时所使用的资源量。
视图更改

每当“视图同步协议”检测到活动的核心组成员发生更改时,它就会创建一个新的视图。通常,每当核心组成员启动或停止时就会发生视图更改。当核心组成员启动时,它就会打开与所有其他正在运行的核心组成员之间的连接。当某一核心组成员停止时,其他核心组成员就会检测到它们与已停止成员之间的连接已关闭。在任何一种情况下,“视图同步协议”都需要反映此更改。对于新启动的成员,“视图同步协议”必须建立一个包含新成员的视图。对于已停止的成员,“视图同步协议”必须为继续存在的核心组成员(已停止的成员除外)建立新的视图。

建立新视图是一项重要活动,但是它会使用许多系统资源,对于大型核心组更是如此。
  • 正在运行的每个核心组成员必须将它的当前状态(包括关于它在当前视图中已发送或接收的消息的信息)告知其他核心组成员。
  • 必须在所有接收方都接收到在给定视图中发送的所有消息并作出应答之后,才能安装新视图。在正常运行情况下,这些消息的接收方将缓慢地作出应答。要及时完成视图更改范围内的消息,需要主动应答并重新传输。
  • 所有核心组成员都必须传输与它们的当前状态有关的数据,例如,可以与它们频繁进行通信的其他核心组成员集。

随着活动成员数增加,安装新视图时将要求临时非线性地增加高可用性管理器的 CPU 使用量。当存在 50 个其他的核心组成员时添加或除去单个成员所需要的成本,比只存在 20 个其他的核心组成员时添加或除去一个成员所需要的成本明显高得多。

安装新视图时,还会在使用高可用性管理器的产品组件中触发状态更改。例如,可能需要更新路由表以反映已启动或已停止的成员,或者可能需要对新成员重新启动单一服务。

安装新视图的最终结果是导致 CPU 使用量瞬间显著增大。如果核心组大小变得太大,那么在视图更改期间会使网络在时间选择方面恶化。这些情况通常会导致在尝试安装新视图期间发生故障。要消除这种故障也需要消耗大量 CPU 资源。当没有足够的 CPU 资源可用或者发生页面调度时,故障数量会快速增加。

后台任务

高可用性管理器会定期运行许多后台任务,例如,检查它正在管理的高可用性单一服务的运行状况。大多数这样的后台任务将消耗很少的 CPU 资源。但是,定期调度的“发现协议”和“故障检测协议”是例外。

“发现协议”将尝试在当前未连接的核心组成员(包括未运行的进程)之间建立通信。对于包含 N 个核心组成员的给定核心组(其中有 M 个核心组成员当前正在运行),在每个发现周期内大约会产生 M x (N – M) 条发现消息。因此,创建大量从不启动的进程会对“发现协议”CPU 使用情况产生不利影响。

同样,当“故障检测协议”运行时,每个核心组成员都会对它与其他核心组成员之间建立的所有连接发送脉动信号。对于 M 个活动成员,将发送 M x (M-1) 条脉动信号消息。如果需要主动进行故障检测,那么核心组 大小对于核心组成员之间发送脉动信号所消耗的 CPU 使用情况产生不利影响。

核心组越小,就会对这 两种协议消耗的 CPU 使用情况产生正面影响。例如,如果核心组包含 100 个活动成员,那么在每个故障检测周 期内将发送 9900 条脉动信号消息。如果将该核心组分成 5 个更小的核心组,每个核心组中只包含 20 个成 员,那么消息数将减少为 1900,可见消息数已大大降低。

外部使用
其他产品组件(如工作负载管理 (WLM))和随需应变配置使用高可用性管理器提供的服务(如实时服务器状态交换)来维护路由信息。这些组件消耗的 CPU 使用量跟核心组大小相关。例如,使用实时服务器状态交换来构建高可用性路由信息就与核心组大小相关。

在多个核心组之间分配进程

可以使用以下两种基本技术来将视图同步协议和相关协议消耗的资源量降低到最低程度:
  • 对于未使用高可用性管理器提供的服务的那些进程,可以禁用高可用性管理器。
  • 可以保持核心组大小很小。

限制高可用性管理器的 CPU 使用量的关键就是限制核心组大小。使用多个较小的核心组比只使用一个很大的核心组会更好。如果具有大型单元,那么应创建多个核心组。

在确定适合于您所在环境的核心组大小时,用来运行产品的硬件也是一个考虑因素。

应将较大的核心组分成多个较小的核心组。如果划分之后获得的核心组之间需要共享路由信息,那么可以使用核心组网桥将各个核心组连接在一起。

核心组大小

假设您最初执行以下调整活动的情况下,您可以合理地确定核心组大小:
  • 允许将 IBM_CS_WIRE_FORMAT_VERSION 核心组定制属性设置为值 6.1.0 时,您可以获得核心组内部协议改进。这些改进只在 V6.1 及更高版本中可用。
  • 允许将 IBM_CS_HAM_PROTOCOL_VERSION 核心组定制属性设置为值 6.0.2.31 时,可以在内存利用率和核心组网桥的故障转移特征方面获得显著改进。
  • 您可以调整传输内存设置。有两个内存或缓冲区大小设置与核心组传输相关联。 对于最多包含 50 个成员的小型核心组,这些设置的缺省值已足够。对于包含 50 个以上成员的核心组,这些设置的值必须大于缺省值。
    注: 增加这些传输内存设置的值不直接转换成由高可用性管理器使用的更多静态分配的内存,或长期内存用量。
如果 WebSphere Application Server Network Deployment 部署在相对现代化的硬件上,CPU 和内存不受限制,应用程序的行为良好,网络稳定且影响核心组稳定性的各个因素(例如网络和内存问题)已得到解决,那么可以考虑以下核心组大小。
  • 最多包含 100 个成员的核心组应该正常工作,而不会发生任何问题。
  • 包含 100 个以上成员的核心组在许多拓扑中应该正常工作,而不会发生任何问题。建议核心组的成员数不超过 200 个。

根据所使用的应用程序组合和服务来调整各个核心组

可能需要根据核心组成员使用的应用程序组合和高可用性服务来进一步调整各个核心组。

  • 如果“发现协议”和“故障检测协议”的运行频率的缺省设置不合适,请调整这些设置。
  • 将核心组协调程序配置为对特定进程或者一组进程运行。
  • 如果协调程序进程消耗的资源相当多,那么将协调程序分布在多个实例之间。
  • 配置“分发和一致性服务”(DCS) 和“可靠的多点广播消息传递”(RMM) 组件在检测到拥塞时可用于发送网络消息的内存量。在某些情况下,即使未使用从内存至内存的复制,也可能会发生拥塞。

调整临时端口范围

通常,一个核心组使用的套接字数目不是主要的考虑因素。每个核心组成员必须与该核心组中的其他每个成员建立连接。因此,连接数将呈指数级(n 次幂)增长,这是因为每个连接都需要两个套接字,即,连接的每一端都有一个套接字。因为通常都牵涉到多台机器,所以,您通常不必关心一个核心组使用的套接字数目。但是,如果在一台机器上运行的核心组成员数异常大,那么可能需要调整与临时端口范围相关的操作系统参数。对于临时端口范围,大多数操作系统具有不同的缺省行为。

最佳实践 最佳实践: 避免使用临时端口范围中的端口。 虽然这是个正确的配置,但如果定义了此范围内的端口,那么在核心组内进行成员至成员通信时,您可能会遇到不可预测的行为。bprac

指示主题类型的图标 概念主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_cgscale
文件名:crun_ha_cgscale.html