在IBM Integration Bus中配置WebSphere Service Registry and Repository缓存

日期:2014/8/1 11:55:00 来源:本网整理 阅读:51

本系列文章将介绍如何集成这两款产品,并提供解决一些重要业务问题的示例。第 7 部分将介绍 Endpoint Lookup 和 Registry Lookup 节点所使用的缓存的配置和行为,包括该缓存如何支持高效地查找以前检索的 WSRR 工件,以及如何将此数据提供给生产系统。本文将介绍 WSRR 集成查找节点所引用的代理托管的缓存的行为,这些节点可以包含在 IIB 消息流中。然后,我们还将介绍如何配置这个由代理托管的缓存(以下简称 WSRR 缓存)来集成 WSRR 和 IIB,以及如何验证它的正确操作。本文最后将介绍如何管理 WSRR 缓存,分离这两款产品来创建一个服务窗口,以便在升级 WSRR 时无需关闭 IIB 或它的运行时流,而且无需在生产环境中引入任何宕机时间。此过程具有重大的业务价值,因为 IIB 运行时环境需要尽可能少的宕机时间。

特征

WSRR 集成节点:Endpoint Lookup 和 Registry Lookup 被设计为能够与 WSRR 进行交互,支持通过对这个注册表系统发出查询来提取收集的数据。因此,这些节点允许从注册表查找信息,并将这些信息注入到传出它们的消息树中,以便在它们所嵌入的任何流中执行后续下游处理。

代理实现了一种本地缓存,在启用该缓存之后,该缓存可以存储这些对所关注的查询语句的调用的结果。启用缓存后(默认设置),只要以前执行过一次完全匹配的查询,WSRR 集成节点就可以直接从本地缓存检索数据。访问本地缓存的查询结果集,而不是重新发出相同的查询语句,有助于改善消息吞吐量,进而改善与 WSRR 集成的流的性能。

备注:作为一条规则,如果消息处理吞吐量是主要的问题,那么建议您启用缓存。但是,如果您的关键目标是对每条针对 WSRR 中存储的最新的易变内容的消息进行处理,则应禁用缓存。

每个查询在第一次执行时,始终会通过已建立的基于 HTTP 的 Web 服务连接发送到 WSRR。默认情况下,此活动会在 WSRR 节点首次发出一个特定查询时发生,但它可能在代理启动时预先填充缓存。

WSRR 节点在没有缓存时也可以操作。如果缓存被禁用,则会将该节点发出的每个查询发送到 WSRR,以确保查询的结果始终反映了注册表的最新内容。此选项对性能会产生影响。

WSRR 缓存是以执行小组为基础来提供的,因此是一种跨给定执行小组中的消息流而共享的资源。在查询(读取)或更新(写入)缓存时,缓存会被锁定,无论是被消息流查询还是执行动态更新。

WSRR 缓存操作

IIB Execution Groups 中的消息流调用了 WSRR Endpoint Lookup 或 Registry Lookup 集成节点。来自这些节点的查询会转发到 WSRR 代理,这个 IIB 组件连接到缓存中保存的以前查询的结果。
在IBM Integration Bus中配置WebSphere Service Registry and Reposi

如果缓存中存在针对一个查询的现有条目,则会将相应的数据直接返回给消息流,而不会对 WSRR 进行查询。如果没有此条目,则会同时对 WSRR 进行查询,该查询的结果存储在缓存中,然后返回到消息流。

在配置的超时间隔之后,所有缓存条目都会过期并从缓存中删除。这意味着,如果一个查询请求一个过期的缓存条目所持有的数据,则需要对 WSRR 执行一次全新的查找。

备注:在一个消息流中的消息进入 WSRR 节点中时,会在整个执行小组中锁定缓存,以便在该节点访问缓存时保留缓存状态。如果在缓存锁定期间收到更新通知,则会在消息流放弃缓存上的锁后来处理更新。因此,在一条消息和一条通知同时到达时,消息中填入的来自缓存的数据可能不再反映服务器上的数据。

因此,通知更新可能影响 WSRR 缓存内容;这些内容随后可能在给定消息实例的流中被下游 WSRR 节点访问,在该实例中进行处理。因此,对于缓存通知,我们无法保证缓存的内容在给定流实例处理某个特定消息的整个时段内保持不变。

事实上,由于缓存条目超时(参阅下文),代理无法保证缓存内容在给定流和消息实例的各个 WSRR 节点上是一致性的,无论是否启用了缓存通知。因此一种可能的场景是,由于缓存条目会在流的上游释放锁后被刷新,所以流中的其他 WSRR 节点(处理同一个消息实例)可能处理不同的值。

尽管每个代理执行小组流程会维护自己的 WSRR 缓存的副本,但所有这些缓存的特征在给定代理实例上是相同的。WSRR 缓存配置参数值与 ServiceRegistries 可配置服务相关联;所以您将需要回收代理,然后才能激活对此服务执行的任何更改。

但是,要丢弃(使失效)某个特定的 WSRR 缓存,只需回收与之有关联的执行小组即可。因此,您应该将任何特定于 WSRR 节点的流分离到它们自己的一个或多个执行小组中。在一组给定流的 WSRR 缓存失效时,采用此方法会强制执行分离,控制这些流并允许其他流保持活动。

除了让整个缓存失效,还可以在缓存中的各个条目上应用超时。向 WSRR 发出查询并收到响应后,会向查询语句以及与之有关联的结果集附加一个时间戳。这意味着每个条目会单独从缓存中超时。

缓存过期超时值可以通过设置与 ServiceRegistries 可配置服务有关联的 timeout 参数来调整。每个缓存条目(缓存的一个查询的结果)会在指定的时间(以毫秒为单位)过后被丢弃。默认缓存过期超时值为 100,000,000 毫秒或大约 27.8 小时。

当一个节点对超时的查询进行下一次引用,会强制将该查询重新发送给 WSRR;相应的结果会替代缓存中过时的条目,并与一个新时间戳相关联。

缓存中可用的结果集条目数量不受限制,也就是说,没有强制规定最大缓存大小。

WSRR 缓存的上述功能得到了两个额外功的进一步增强,这两个功能相结合,提升了注册表查询过程的性能,简化了为一个可预测的时间段配置一个服务窗口的过程。下面介绍了相关的功能。

缓存预加载

在默认情况下,缓存中没有预加载任何内容,每个查询在第一次执行时都会被发送到 WSRR。可以指定在代理启动时或首次部署一条包含 WSRR 流的消息流时执行的预定义查询。这些查询会填充缓存,以供后续 WSRR 节点使用。通过指定预定义的查询,在启动时性能可能受到影响,而在运行时第一次执行查询时性能不会受影响。

缓存通知

与过期超时相比,缓存通知是一种更灵活的刷新缓存数据的方法。它允许在 WSRR 中修改各个 WSRR 条目时让它们在缓存中失效,确保缓存绝不会在其存储的条目中包含过时的数据。

要启用缓存通知,还必须启用缓存本身。启用缓存通知后,缓存会订阅在 WSRR 中发生的事件,并在 WSRR 中的一个对象被更新或删除时获得通知。在这个场景中,根据超时过期机制,缓存中的条目可能会直接失效,或者通过事件订阅间接地失效。

订阅通过一个基于 JMS 的缓存通知连接来实现,该连接不同于 Web 服务连接。如上所述,缓存通知机制用于确保缓存的内容是最新的,并与 WSRR 服务器的内容一致。

WSRR 缓存更新通知

假设 IIB WSRR 缓存中已加载了数据,并且一个治理 WSRR 系统的用户执行了一项与 WSRR 缓存中的一部分数据相关的更改。WSRR 会向 IIB Cache Update Listener 组件发布一条消息,以告知此更改。

Cache Update Listener 收到此消息后,对缓存中声称被更改的数据执行操作。执行的操作取决于在 WSRR 服务器中执行的更改类型。如果删除了某一项,那么只会从缓存中删除该项。其他任何操作都将导致缓存过期,以确保缓存保持一致的状态。默认情况下,这意味着下一次执行一个消息流查询来请求此数据时,该请求会转发回 WSRR。请注意,配置了缓存更新通知后,超时机制会继续起作用。
在IBM Integration Bus中配置WebSphere Service Registry and Reposi

配置缓存预加载

缓存预加载旨在增强代理中的流性能(消息吞吐量)。正常情况下,缓存会按需填充,第一次执行某个流中的 WSRR 节点发出的查询语句时,性能影响是可以接受的。因此对于一个节点处理的第一条消息(在启动时或一次超时过后),预计会产生与直接从 WSRR 收集(而不是从本地代理缓存收集)查询结果相关的成本。

要改善这种情况,可以在运行时消除这种初始开销。这可以通过提前声明代理可能发出的已知查询表达式列表来实现;在代理最初启动时,会在执行定义的查询时在缓存中预先加载查询结果,然后再由运行时消息对任何消息执行处理。

预定义的 WSRR XPath 查询表达式列表通过 ServiceRegistries 可配置服务的 predefinedCacheQueries 参数向代理公开。表达式列表(由分号分隔)(每个表达式有一个可选的深度规范)可以直接通过此参数定义。

也可以通过将这些表达式放在一个通过参数指向的文件中,间接地访问它们。可以通过打开用户轨迹并针对关注的流执行运行时,收集代理系统发出的表达式集合。对用户轨迹的检查可以显示所有已部署的 WSRR 集成节点生成的 WSRR XPath 查询表达式。

构建服务查询文件

要实现与 WSRR 的代理隔离,必须在代理内配置缓存预加载。这使得代理能够在执行小组启动后,从 WSRR 拉取所有已知的服务工件。每次启动代理内的一个执行小组时,或者首次部署一个包含 WSRR 集成节点的消息流时,都会进行缓存预加载。

缓存实现使用对 WSRR 执行的服务查询作为进入缓存的钥匙。这些服务查询是惟一的,而且在配置缓存预加载时,它们需要在运行时以 Endpoint Lookup 节点或 Registry Lookup 节点使用的完全相同的格式来指定。如果这些查询未知,确定它们的惟一方式是在代理内启用用户轨迹,并执行相关的流。然后,查询可以从代理轨迹文件读取数据。可以通过两种方式启动用户轨迹:

  • 第一种方式是在代理自身内启用用户轨迹。轨迹类型分为正常或调试。对于此练习,需要将轨迹类型设置为调试。这通过运行以下命令来完成: mqsichangetrace <broker_name> -u –e <execution_group> -l debug
  • 第二种方式是从 MQ Explorer 内启用用户轨迹。这通过切换到 WebSphere MQ Explorer 来完成。在 Navigator View 中,展开 Integration Nodes 树元素,并右键单击要启用用户轨迹的执行小组。单击 User Trace All Flows,然后选择轨迹级别。在本例中为 Debug。下图显示了该视图:
  • 在IBM Integration Bus中配置WebSphere Service Registry and Reposi

启用用户轨迹后,必须执行可能会执行 WSRR 查询的所有流。执行这些流期间,每次 Endpoint Lookup 节点或 Registry Lookup 节点对 WSRR 执行查询时,该查询都会捕获在轨迹中。

它将属于用于创建 Query 文件的查询。所有相关的查询都运行后,开始在轨迹文件中扫描短语 ‘BIP3676I’。这是 Endpoint lookup 节点的消息 ID。它在轨迹文件中类似于以下代码:

代理记录的 EndpointLookup 查询字符串用户轨迹

2013-12-06 17:01:56.414672    14395   UserTrace   BIP3676I: The query 
string from node ''EndpointLookup'' that will be used to query the 
WebSphere Service Registry and Repository (WSRR) is: 

'/WSRR/WSDLService/ports[binding/portType[@name='MathServerPortType' 
and @namespace='http://math.pot.ibm.com' 
and @version='1.0']
and exactlyClassifiedByAllOf(., 'http://www.ibm.com/xmlns/prod/
serviceregistry/lifecycle/v6r3/LifecycleDefinition#Online')]' 

This is the query string that has been generated to query the WSRR. 
No user action required.

查询字符串可以是放在单引号内的任何内容。所以,在上述轨迹中,以下内容是 WSRR 查询:

/WSRR/WSDLService/ports[binding/portType[@name='MathServerPortType' 
and @namespace='http://math.pot.ibm.com' and @version='1.0']
and exactlyClassifiedByAllOf(., 'http://www.ibm.com/xmlns/prod/
serviceregistry/lifecycle/v6r3/LifecycleDefinition#Online')]

此查询字符串必须修改,才能转义任何单引号。每个单引号必须替换为 &apos;。新字符串查询类似于以下代码:

/WSRR/WSDLService/ports[binding/portType[@name=&apos;
MathServerPortType&apos; 
and @namespace=&apos;http://math.pot.ibm.com&apos; 
and @version=&apos;1.0&apos;]
and exactlyClassifiedByAllOf(., &apos;
http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
LifecycleDefinition#Online&apos;)]

同样地,轨迹文件将包含短语 ‘BIP3685I’。这是 Registry Lookup 节点的消息 ID。它在轨迹文件中类似于以下代码:

代理记录的 RegistryLookup 查询字符串用户轨迹

2013-12-06 17:05:14.519078    10849   UserTrace   BIP3685I: The 
following details will be used to query WebSphere Service Registry 
and Repository (WSRR) from node 'RegistryLookup': query string=
'//*[@name='MathService' and @namespace='http://math.pot.ibm.com' 
and @version='1.0']', depth='1'

控制检索的数据将如何显示的 Depth Policy 是 MatchPlusImmediate。指定的查询字符串和深度将被发送到 WSRR。根据 DepthPolicy 中指定的位置,从 WSRR 返回的信息添加到 LocalEnvironment。如果这些不是您想要的设置,请检查节点属性是否在 LocalEnvironment 中被覆盖,如果使用了 DepthPolicy 覆盖值,请仔细检查该值的拼写。

代理消息流对 WSRR 执行的查询集应存储在一个单独的文本文件中。该文件中的每个查询字符串必须由一个分号分隔,所有查询字符串必须显示在一行上,也就是说文本文件中的任何地方都不能出现新行或换行符。可以指定和预加载的 XPATH 查询的数量不受限制。以下是一个查询文件的示例:

/WSRR/WSDLService/ports[binding/portType[@name=&apos;
MathServerPortType&apos; 
and @namespace=&apos;http://math.pot.ibm.com&apos;
and @version=&apos;1.0&apos;]
and exactlyClassifiedByAllOf(., &apos;
http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
LifecycleDefinition#Online&apos;)]&apos; 
/WSRR/WSDLService/ports[binding/portType[@name=&apos;
MathServerPortType_V2&apos; 
and @namespace=&apos;http://math.pot.ibm.com/V2&apos;
and @version=&apos;2.0&apos;]
and exactlyClassifiedByAllOf(., &apos;
http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
LifecycleDefinition#Online&apos;)]&apos; 
//*[@name=&apos;MathService&apos; 
and @namespace=&apos;http://math.pot.ibm.com&apos; 
and @version=&apos;1.0&apos;]&apos;, 
depth=&apos;1&apos;

此文本文件需要保存在服务器上或保存在服务器可以访问的网络位置上。此刻,可以通过将轨迹级别设置回 None 来禁用用户轨迹。正如上面所讨论的,这可以从命令行或 MQ Explorer 完成。

启用缓存预加载

创建查询文件并将它放在服务器上后,是时候将代理配置为在执行小组启动时使用该文本文件了。可以使用更改属性命令来实现此目的,可通过运行以下命令来完成:

启用从文件预加载 WSRR 缓存的命令

mqsichangeproperties <broker_name> -c ServiceRegistries -p 
"<wsrr_query_text_file>" -o DefaultWSRR -n predefinedCacheQueries

将 <broker_name> 替换为使用的代理的名称。将 <wsrr_query_text_file> 替换为查询文件的绝对路径位置和名称。执行笑傲组应重新弄启动,对缓存配置的更改才会生效。重新运行所有测试流,以验证是否所有功能仍按预期运行。

此查询文本仅在启动时使用。缓存中的数据仍会基于缓存过期超时的值而失效。在执行代理内的相关流时,需要再次从 WSRR 抓取失效的条目。

出于这个原因,需要将缓存过期超时设置为一个合适的值才能创建所需的服务窗口。用于报告超时值的代理命令的一个示例如下:

报告对给定代理系统设置的 WSRR 相关属性的命令

mqsireportproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR -r

从结果中可以看到,超时值是在缓存中设置的查询结果将被视为最新(也即有效)的时长。显示的超时值以毫秒为单位。要更改此设置,需要发出以下命令:

修改对给定代理系统设置的 WSRR 缓存超时属性的命令

mqsichangeproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR –n timeout –v 10000000

正如上面所讨论的,指定的值的大小,使之足够创建一个能够容纳 WSRR、WebSphere Application Server 和 WSRR 数据库实例的升级的服务窗口。此超时值应由生产团队确定,基于它们通常对指定产品执行一次升级所花费的平均时间。

维护查询文件

查询文件首次建立时,应被视为一段源代码,因此放在生产团队的源代码管理系统中。随着新 Endpoint Lookup 或 Registry Lookup 节点添加到代理流中,它们的相关查询也需要附加到这个文本文件中。建立新的或修改的查询的过程保持不变,已在上面介绍查询文本文件的最初构造时介绍。因此,此文本文件的构造和修改应遵循团队采用的软件开发生命周期 (SDLC) 流程。

验证缓存

在某个时刻(生产前),生产团队将需要确认其代理管理的缓存的操作有效性;具体来讲他们希望测试其运行时代理能否与其目标 WSRR 环境隔离。

通过这么做,他们将验证借助已启用和预加载的缓存,WSRR 环境能够取消激活,而不影响代理运行时的操作。代理将继续运行,没有任何宕机时间。这在 WSRR 的升级过程中将变得非常有用。

在代理初始启动时所有预加载配置步骤都已完成,且缓存填满后,运行的 WSRR 所在的 WAS 实例应停止。这可以通过命令行或使用 WebSphere Administration Console 实现。

WSRR 服务器停止后,所有代理测试案例(WSRR 集成流)将需要生产团队重新执行,他们才能确认尽管没有一个正在运行的 WSRR 系统作为目标,但其代理仍能完全正常地运行。执行了代理测试案例并验证了它们的操作后,生产团队可以重新启动其 WSRR 服务器实例。

管理缓存和 JVM 堆大小

使用 WSRR 缓存时会立即想到的一个问题是,生产团队是否需要担忧突破 JVM 堆大小限制。也就是说,由于在执行小组中使用了 WSRR 缓存,他们是否需要提高代理中的默认 JVM 限制?此问题没有明确的答案。

在 IIB 中,您可以通过启用和使用代理发布的资源统计数据,监视 JVM 堆大小和垃圾收集速率。此功能然后将指示生产团队是否需要提高 JVM 限制。代理以各个执行小组为基础发布使用的资源的统计数据;因此要缩小 WSRR 缓存使用数据范围,生产团队应将其 WSRR 流隔离到一个或多个特定的执行小组中,以便监视。

配置缓存通知

启用缓存通知后,在启动包含一个或多个消息流的执行小组时(其中包含至少一个 Endpoint Lookup 或 Registry Lookup 节点),代理将订阅 WSRR JMS 发布主题:给定 WAS 消息引擎上的 jms/SuccessTopic。WAS(代表 WSRR)发布的针对此主题的任何消息,都会由代理收到并被分析。

如果该消息为以下事件类型:create、update、transition、make_governable 或 remove_governance,整个缓存将失效。如果消息为事件类型:delete,那么该消息所引用的对象(由一个惟一的 WSRR 统一资源标识符 (bsrURI) 来标识)会从缓存中删除。收到这些通知后,立即会对它们执行操作。

如果缓存通知连接(出于某种原因)失败,该连接将无限期地不断重试。频率降低时会产生一条报告连接失败的错误消息,该频率会在每次错误输出后增加一分钟。重新建立连接后,整个缓存会失效,以确保它不断刷新。

在缓存通知连接失败期间,缓存条目超时仍会继续发生。如之前所述,缓存超时以每个查询为基础,所以它的起始时间和过期时间都依赖于特定查询第一次发出的时间。

如果 JMS 连接由于缓存通知而丢失,整个查找流程会尝试重新建立一个订阅连接,也就是说会重新访问 JNDI 服务器。流中不会抛出任何异常,执行小组将无限期地重试连接。

启用缓存的 JMS 通知

WSRR 缓存启用时,如果受到查找节点的请求且代理的超时值已过,代理将仅更新一个缓存条目。因此,如果 WSRR 中的一个服务定义在这个配置的超时过期之前被修改,那么代理不会反映该更改,它将返回本地缓存中包含的一个过时的值。

代理中的缓存可以配置来从 WSRR 接收 JMS 通知;这些通知会在注册表系统中的内容更新后立即发出。

要启用缓存通知,第一步是运行下面的命令:

在给定代理系统上启用 WSRR 缓存,以开始处理 WSRR 所发布的更新通知

mqsichangeproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR –n enableCacheNotification –v true

接下来,使用下面的命令设置绑定属性 (IIOP URI) 的位置。

设置 WAS JMS 提供程序 JNDI 绑定所在的系统端点的命令

mqsichangeproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR –n locationJNDIBinding –v iiop://<WSRR_host>:<PORT>

将 –v 参数更改为您系统上的 JNDI 绑定的位置。该参数表示 WebSphere Application Server JMS 提供程序 JNDI 绑定的 URL,其中主机名 <WSRR_host> 是一个变量,表示可以在其上查找绑定定义的网络上的 JNDI 服务器。此设置是代理级别的,会由给定代理的所有执行小组采用。每个执行小组 JMS 连接会在启动过程中建立。

此外,Internet InterORB Protocol (IIOP) 是一个在 Internet 上使用的 General Inter-ORB Protocol (GIOP) 实现。它在 GIOP 消息与 TCP/IP 层之间提供了映射。

如果运行的 WSRR 所在的 WebSphere Application Server:

  • 启用了安全性或
  • 提供了一个高可用性环境(一个连接工厂可以管理多个引导服务器)。

然后,您需要运行以下命令:

设置 JMS 连接工厂名称的命令;用于查找消息引擎

mqsichangeproperties <broker_name> -n jms::DefaultWSRR@jms/SRConnectionFactory
 –u <userid> -p <password>

-n 令牌描述用于连接到 WSRR 服务集成总线的连接工厂。执行此命令后,代理实例需要运行以下命令来重新启动:

mqsistop <broker_name>
mqsistart <broker_name>

要确认缓存的 JMS 通知现在已启用并正确配置,需要在修改的代理环境中重新执行以前有效且能正常操作的测试案例。举例而言,这里有一个服务需要在 WSRR 系统中更新;无需重新启动代理或它部署的任何运行时工件,只需重新执行同一个测试即可完成更新。重新执行测试的目的是确认已经检测到注册表更改和代理缓存确实已刷新;进而反映了已经应用的更改。

缓存 JMS 通知和高可用性

截至编写本文时,IIB 有一个已知的限制,那就是它只能使用一个简单的(单主机名)IIOP URI 在 WebSphere Application Server (WAS) 命名空间中查找 WAS JMS 提供程序 JNDI 绑定。

代理不支持多个替代性端点,此设置可以在代理级别上进行应用。根据规定,这个单点故障用于获取 JMS 提供程序 JNDI 绑定,后者进而用于查找一个连接工厂;在高可用性环境中,该连接工厂可以管理多个用于选择消息引擎的引导服务器。

要让这个 JNDI 服务器端点更容易使用,可以部署各种不同的系统架构拓扑结构。

虚拟 IP

要在 WAS 集群中的成员之间实现自动高可用性,推荐使用网络设备解决方案。在这里,我们使用了一个虚拟 IP (VIP) 来监视 WSRR 中的端口,将请求路由到活动的应用服务器。

在 VIP 下,IP 地址由某个中间系统(通常是来自 F5 或 Cisco 等供应商的网络设备)来维护,该系统屏蔽了多个后端系统。这些设备提供了许多配置选项来实现跨多个隐藏在 VIP 背后的系统的负载平衡。一个常见的选项是支持系统之间的主动/被动模式,采用一些常规端口监视方法来留意后端系统(在本例中为一个 WAS 集群成员,充当着 JNDI 服务器)何时关闭。如果可用,此选项是为代理与高度可用的注册表系统之间的集成提供支持的最轻松的方式。

找到位于代理机器本地的 JNDI WAS 服务器

我们的目的是提供某个地方来放置 JNDI 对象,重要的是,这个地方在理论上应在代理可用时始终可用。

提供一个灾难恢复环境

为了支持此任务,可以将 IIOP URI 指向一个动态的主机名。动态主机名类似于 VIP,但通过域名系统 (DNS) 服务器提供,所以该解决方案不需要网络设备。但是,需要控制服务器的 DNS 记录。一种方法是在本地操作系统上创建一个简单的 hosts 文件,它可以通过任何脚本更新。在这里,DNS 在任何时刻都只包含一个条目,但某个系统会基于 WAS 端的监视情况来动态更新它。支持此方法的已知的监视技术包括:AIX PowerHA (HACMP)。

生产维护

非高可用性环境中的服务升级

这样一个 WSRR 环境中的第一个升级步骤是,确保在单一目标 WSRR 系统停止期间,代理管理的 WSRR 环境不会失效。因为无法确定某个托管缓存中的条目上次是何时失效的,所以推荐重新启动每个部署到生产运行时的执行小组,一次一个。再次声明,只包含一个或多个消息流的执行小组(其中至少包含一个 Endpoint Lookup 或 Registry Lookup 节点)需要回收。

通过按顺序重新启动每个执行小组,整个代理环境绝不会完全不可用。完成重新启动后,一个执行小组拥有的所有缓存都将立即填入来自 WSRR 的所有需要的数据(假设配置了预加载),而且在代理级缓存过期超时到达之前不会失效。

此超时值应由生产团队设置;它应该有一个足够大的时间窗口,以便容纳计划的服务升级活动。在非高可用性环境中,只有一个 WSRR 系统可供代理运行时访问。在服务升级期间,此系统将处于离线状态,所以代理建立的 Web 服务连接会丢失。在这样一个场景中,如果已经超过了某个特定条目上的超时值,那么代理管理的缓存将无法支持 WSRR 查找。这些条目已失效;导致它们的过时数据被销毁,尽管事实上没有活动的 Web 服务连接可供使用。

下一步是执行修复包或最新版本所提供的推荐的升级流程。

使用缓存通知进行提升

对于启用了缓存通知的 WSRR 下的同步提升,在成功完成事务之前,绑定到给定提升操作的事件不会提交到 SuccessTopic。因此,在成功地完成 WSRR 生命周期过渡后(这会触发一次提升),生产团队应提防生命周期过渡的成功事件被代理处理。

对此事件的处理的确认信息将会显示在代理服务轨迹中(如果已启用),其中此事件表示绑定到给定提升操作的最新事件;因此在这个时刻之后,与在 WSRR 中提交的具有事务控制的同一个提升操作有关联的未来事件不应让 WSRR 缓存重新失效。

此刻,生产团队可以安全地关闭服务轨迹,启动或重新启用其 WSRR 流,以便可以继续针对其完全更新的 WSRR 系统处理消息。对于大多数生产团队,将无法选择打开服务轨迹。最佳实践建议创建一个服务流,将它部署到每个受影响的执行小组中。这个流将包含一个连接到 TraceNode 的 JMSInput 节点。这样一个流可以在提升之前启动;启动它的目的是捕获 WSRR 发布的 JMS 成功主题事件并将它们写入文件中。

在 JMSInput 上设置的 Location JNDI 绑定 JMS 连接属性,并将它设置为对 ServiceRegistries 可配置服务的 locationJNDIBinding 属性设置的相同值。所以上述操作的前提是在提升过程中禁用消息流,确保没有针对 WSRR 系统或代理缓存处理任何消息;WSRR 系统或代理缓存可能处于过渡状态,因此它们的内容可能不一致。

但是,在与目标 WSRR 系统的集成仅限于 EndpointLookup 节点的情况下,不一致性表示存在问题,也就是说,您要么获得一个旧端点,要么获得一个新端点。在这种场景下,在提升活动期间无需停止工作流。

对于注册表查找,情况又有所不同。我们不希望缓存保存不一致的数据,即所有更新(除了删除)导致整个缓存失效,但删除仅会让受影响的特定条目失效。因此,在理论上,我们可以在一次提升之后处理过时数据和最新数据的混合体。

在一次提升之后提交整个事务之前,不会向成功主题发布任何事件。事件消息的顺序和它们的类型(将由代理拉取和处理)都是是未知的;所以缓存可能不会立即失效,因此会强制抓取所有后续的查询请求。

通过启用的缓存来提升

在这里,假设我们遵循了最佳实践指南,因此将所有特定于 WSRR 的流隔离到自己的执行小组中。在 WSRR 生产注册表通过提升来升级之前,生产团队应停止 WSRR 执行小组,以便停止对生产注册表处理更多消息并让整个缓存失效。

然后,他们应该将条目过渡到暂存系统中,以便提升它,并将同一个受控制的集合中的目标条目过渡到生产环境中。他们应该监视 WSRR 中的同步提升,确认过渡已成功完成。最后一个步骤是重新启动 WSRR 执行小组,继续对升级的生产注册表处理新消息。所有查询结果集最初都将通过直接调用生产系统来获取。应该将抓取的结果与它们的查询相结合,以便在缓存中填入一个新查询条目。后续调用可直接从缓存中抓取,这些条目的默认超时值应适当地进行延长,以适合团队的操作需求。

在与目标 WSRR 系统的集成仅限于 EndpointLookup 节点时,注册表的内容在工件提升期间不一致也不会导致问题。与上面一样,在这个场景中,在提升活动中无需停止工作流。

问题排除

从代理连接到 WSRR 时的错误

要诊断这种一般性错误,可以执行以下检查:

检查指向您的注册表服务器的端点地址值。从命令控制台,运行以下代理命令,将 <broker_name> 替换为您代理的名称,以显示与它有关联的 WSRR 属性:

mqsireportproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR -r

上述命令将生成一个类似输出的响应:

ReportableEntityName=''
ServiceRegistries
DefaultWSRR=''
connectionFactoryName='jms/SRConnectionFactory'
enableCacheNotification='false'
endpointAddress='http://<host>:<port><web service interface url>'
....

如果未连接到安全的 WSRR 服务器,那么您应该能够将报告的 endpointAddress URL 值复制到浏览器中,并获得有效的响应,也就是说,系统没有返回 404 Not Found 或 5xx server error 作为状态代码。例如,考虑下面这个无效的 URL 和返回的响应:

http://localhost:9080/WSRR_9/services/WSRRCoreSDOPort
Error 404: 
com.ibm.ws.webcontainer.servlet.exception.NoTargetForURIException: 
No target servlet configured for uri: /WSRR_9/services/WSRRCoreSDOPort

以下是有效的 URL 和在发送给 WSRR V8.0 系统时相应的响应的示例:

http://localhost:9080/WSRRCoreSDO/services/WSRRCoreSDOPort            
{http://www.ibm.com/xmlns/prod/serviceregistry/6/0/ws/sdo}WSRRCoreSDOPort
Hi there, this is a Web service!

http://localhost:9080/WSRR6_1/services/WSRRCoreSDOPort
{http://www.ibm.com/xmlns/prod/serviceregistry/6/1/ws/sdo}WSRRCoreSDOPort
Hi there, this is a Web service!

http://localhost:9080/WSRR7_5/services/WSRRCoreSDOPort
{http://www.ibm.com/xmlns/prod/serviceregistry/7/5/ws/sdo}WSRRCoreSDOPort
Hi there, this is a Web service!

http://localhost:9080/WSRR8_0/services/WSRRCoreSDOPort
{http://www.ibm.com/xmlns/prod/serviceregistry/8/0/ws/sdo}WSRRCoreSDOPort
Hi there, this is a Web service!

如果上述操作不起作用,则表明未正确指定 URL。通常 <host> 或 <port> 值存在问题。请确保提供的主机名是完全限定的。例如一个完全限定的主机名为:pic.dhe.ibm.com,而不是 pic.dhe。

对于不同的 WSRR 版本,支持使用不同的 URL 来访问公开的 Web 服务接口。更高的 WSRR 版本支持其自己的 URL,而且为了实现向后兼容性,它们还支持同一个 URL 的早期版本。

  • 例如,WSRR 6.0.2 版支持的核心 Web 服务接口 URL 为:/WSRRCoreSDO/services/WSRRCoreSDOPort,
  • 而同一个 URL 针对 V6.1 的版本为:/WSRR6_1/services/WSRRCoreSDOPort。

因此,请在报告的值中检查 <web service interface url>,确保它兼容您的目标注册表系统。例如,使用 V6.1、V6.2 或 V6.3 兼容性 URL 而不是 V6.0.2 兼容性 URL 时,V7.0.0.3 到 V7.0.0.6(以及 APAR IC84693)提供了 WSRR V8 支持。对于对 WSRR V7.5 的相同代理级别的访问,没有 V6.2 和 V6.3 兼容性 URL 可供使用。

请使用受您的代理和 WSRR 系统组合支持的最高的 Web 服务接口版本。例如,对于 V9,使用 V6.3 核心 Web 服务接口 URL:WSRR6_3/services/WSRRCoreSDOPort。

参见 参考资料 部分,获取有关哪些 Web 服务接口 URL 可用于某个特定 WSRR 版本的信息的链接。另一个链接显示了特定代理版本和平台的系统需求;更具体来讲,在产品协作部分中,列出了不同 WSRR 版本提供的功能。

使用 WAS V8.0 时,如果希望启用和使用 JMS 缓存通知支持,默认的 IIOP 安全设置必须被设置为支持 SSL。对于 WAS 的更高版本,默认的 JMS 安全性设置应从 supported 更改为 enforced。

从 MQ Explorer 启用并检查代理用户轨迹。指定的端点地址必须是正确的,但您仍有可能看到无效的响应。例如,考虑响应 GIOP。这个响应是一般性的响应,提示在与 WSRR 通信时某处出错了。这可能表示在绑定到 WAS 时出现了一个异常,在 WAS 中,在协商 General Inter-ORB Network Protocol 期间出现一个错误。

因此,在此实例中,下一步可能是生成一个代理服务轨迹。此轨迹可以捕获在产品尝试交互时生成的异常(如果有)。它可以突出显示代理中出现错误的地方,该错误是否从 WSRR 发回,或者代理是否未正确处理了某个错误。考虑下面这段与这类响应绑定在一起的示例服务轨迹片段:

...'WSRRMbLogHandler:FINEST' , 'BUFFER RELEASED: Calling Element: 
com.ibm.ws.http.channel.impl.HttpServiceContextImpl.clear 
(HttpServiceContextImpl.java:993) Main ID: 0'

...'WSRRMbLogHandler:FINEST' , 'BUFFER RELEASED: Calling Element: 
com.ibm.ws.genericbnf.impl.BNFHeadersImpl.clearBuffers
(BNFHeadersImpl.java:502) Main ID: 0'

...'WSRRMbLogHandler:FINER' , 'close(), 
com.ibm.ws.tcp.channel.impl.TCPConnLink@3d66c39 Entry'

...'WSRRMbLogHandler:FINEST' , 'Closing the connection: remote host 
name: wsrrhost.corp.xyz.com remote host address: x.x.x.x local host 
name: brokerhost local host address: x.x.x.x'

...'WSRRMbLogHandler:FINEST' , 'Connection closed with exception: 
Connection close: Read failed.  Possible end of stream encountered. '

...'WSRRMbLogHandler:FINER' , 'destroy(Exc) Connection close: Read 
failed. Possible end of stream encountered.  Entry'

...'WSRRMbLogHandler:FINEST' , 'Destroying the connection: remote host 
name: wsrrhost.corp.xyz.com remote host address: x.x.x.x local host 
name: brokerhost local host address: x.x.x.x'

...'WSRRMbLogHandler:FINER' , 'close Entry'

...'WSRRMbLogHandler:FINEST' , 'SocketChannel close starting, local: 
brokerhost/x.x.x.x:38775 remote: wsrrhost.corp.xyz.com/x.x.x.x:9080'

...'WSRRMbLogHandler:FINE' , 'SocketChannel close, local: 
brokerhost/x.x.x.x:38775 remote: wsrrhost.corp.xyz.com/x.x.x.x:9080'

查看服务轨迹可以看出,似乎抛出了一个 IOException (Connection close:Read failed)。瘦客户端成功地建立了连接并读取了一些数据,但随后,出于某种原因,连接被关闭了。

提示:为了筛查出这个 WSRR 瘦客户端的轨迹,来自 WSRR 的所有代理日志条目都将包含 WSRRMbLogHandler。在以这种方式进行过滤时,支持跳过所有类加载条目。

  • 本文相关:
  • IBM WSRR 使用 HTTP Request 节点执行 SLA 检查
  • IBM Rational Lifecycle Integration Adapters概览
  • BigSheets将数据转换为可用于未来查询和其他处理的可视化形式
  • IBM Cognos BI企业级商业智能产品日志简介
  • IBM医疗连接包一款基于Message Broker的新产品
  • WebSphere Message Broker和IBM Integration Bus中ESQL共享变量的使用
  • MongoDB保护新一代数据库的配置和策略
  • 使用IBM Rational Test Workbench进行移动终端应用测试
  • InfoSphere Streams如何帮助您将数据转换为洞察
  • 在WebSphere Application Server中部署资源适配器
  • 免责声明 - 关于我们 - 联系我们 - 广告联系 - 友情链接 - 帮助中心 - 频道导航
    Copyright © 2015 www.zgxue.com All Rights Reserved