内容


使用 target.xml 文件识别、理解并解决 WebSphere Virtual Enterprise On Demand Router 中的路由问题

Comments

简介

当 WebSphere Virtual Enterprise On Demand Router (ODR) 返回一个 HTTP 1.1 404 File Not FoundHTTP 1.1 503 Service is not Available 响应时,可能表明有一个配置问题,或者有一个场景可能需要高级协助。理解如何生成和分析 ODR target.xml 文件可能有助于在进行初始问题识别时节约宝贵的故障诊断和排除时间。

对于本文中的所有示例,使用的 ODR 名称为 ODR01,单元名称为 C01,ODR 中运行的节点名称为 ODR_C01_WVE61_Node,<WebSphere_Install_Root> 为 C:\Program Files\IBM\WebSphere\ND61_XD61。所有示例均在一个 WebSphere Virtual Enterprise 6.1.1.x 单元上执行。

什么是 target.xml 文件?

WebSphere Virtual Enterprise 在内存中包含进行路由决策所需要的数据,这与 web 服务器不同,后者使用一个静态文件。这允许 WebSphere Virtual Enterprise 动态感知单元状态。因此,只要单元状态发生了变化, ODR 用于进行路由决策的数据就会动态修改。

target.xml 文件是单元状态的快照,包括服务器状态、应用程序状态和路由信息。如果单元状态在 target.xml 文件生成之后更改,那么必须生成一个新的 target.xml 文件。

生成 target.xml 文件

可以使用几种方法来生成 target.xml 文件,我们将在下面分别介绍。

启用跟踪

如果在 ODR 上设置 “com.ibm.ws.odc.nd.ODCTreeImpl$Save=all” 跟踪规范,则在跟踪进程首次启动时会生成一个 target.xml 文件,在单元中进行的任何后续配置更改也会生成一个 target.xml 文件。要启用这个跟踪规范,从 WebSphere 管理控制台,转到 Trouble Shooting -> Logs and Trace -> (ODR_Name) -> Change Log Detail Levels。这个文件将在以下目录中生成:

<WebSphere_Install_Root>/profiles/<profileName>/installedFilters/wlm/<process>/

使用 dumpODRState.jacl 脚本

dumpODRState.jacl 脚本输出当前路由信息(target.xml 文件),并标明请求是否正在通过 Autonomic Request Flow Manager (ARFM) 排队。

用法:

wsadmin -f "<WebSphere_Install_Root>\bin\dumpODRState.jacl" odr_name

示例:

wsadmin -f "C:\ IBM\WebSphere\ND61_WVE61\bin\dumpXdState.py" ODR01

这个脚本位于 <WebSphere_Install_Root>\bin 目录中。

使用 ODRDebug.py 脚本

ODRDebug.py 脚本可用于在 503 或 404 错误出现时生成 target.xml 文件。这个 target.xml 文件将被记录到 ODR 的 Systemout.log 中。这允许您在问题出现时捕获单元状态。

使用这种方法自动生成 target.xml 文件将导致 SystemOut.log 文件中记录的数据量大幅增加。要防止包装引起的数据损失,应增加日志大小和历史日志的数量,方法是转到 Troubleshooting -> Logs and Trace -> (ODR_Name) -> JVM Logs。如果触发 target.xml 文件生成的情况频繁出现,则这种方法可能会严重降低性能。

用法:

wsadmin -f <WebSphere_Install_Root>\bin\odrDebug.py" setHttpDebug  
                            ODR_Node_Name ODR_Name HTTP_Response true Log_Level

可以指定以下日志级别:

  1. 禁用
  2. 显示一行故障原因
  3. 1 + 一个 ODCTreeView(如果单元状态在上一个 ODCTreeView 之后更改)
  4. 1 + 一个完整 target.xml 树(如果单元状态在上一个 target.xml 之后更改)
..DMGR\.wsadmin -f "C:\Program Files\IBM\WebSphere\ND61_XD61\bin\odrDebug.py" 
          setHttpDebug  ODR01_C01_WVE61_Node  ODR01 503 true 3

WASX7209I: Connected to process "dmgr" on node D_C01_WVE61_Node using SOAP connector;  
    The type of process is: DeploymentManager
WASX7303I: The following options are passed to the scripting environment and are
    available as arguments that are stored in the argv variable: 
    "[setHttpDebug, ODR01_C01_WVE61_Node, ODR01, 503, true, 3]"
done

ODRDebug.py 脚本位于 <WebSphere_Install_Root>\bin 目录中。

ODR 如何处理请求

理解 ODR 如何处理请求有助于理解如何分析 target.xml 文件,以便解决路由问题。

ODR 首先检查所有以 ODR 为中心的路由规则。如果匹配,则 ODR 尝试定位请求应该被路由到的 web 模块。予以考虑的 web 模块是与匹配规则关联的 web 模块。这些 web 模块根据 routingLocations 选项的值、按照以下方式与一个规则关联:

  • 一个集群规范包含所有部署到该集群的 web 模块。
  • 一个服务器规范包含所有部署到该服务器的 web 模块。
  • 一个模块规范包含匹配的 web 模块。

以 ODR 为中心的路由规则不应与在应用程序工作类上设置的路由规则混淆。

如果没有任何 ODR 路由规则匹配,默认行为是考虑所有匹配请求的 URI 的 web 模块来处理该请求。

当某个请求被映射到一个特定应用程序之后,该应用程序的应用程序路由规则将被处理。这些规则与应用程序的 Routing policy 选项卡下的工作类关联。它们是 HTTP 和 SOAP 工作类。如果一个 HTTP 请求同时也是一个 SOAP 请求(HTTP 上的 SOAP),则使用 SOAP 工作类;否则,使用 HTTP 工作类。

定位应用程序的适当版本之后,将处理该应用程序版本的服务策略规则。这些规则与应用程序的 Routing policy 选项卡下的工作类关联。

如果没有为请求发现任何 web 模块,则通过用服务器集群(Generic Server Cluster,GSC)路由策略规则将被评估。GSC 路由策略的默认工作类的默认行为是使用一个 404 (Not Found) 错误拒绝请求。

验证应用程序服务器没有问题

要确定问题,第一步是验证托管应用程序的应用程序服务器正在正确响应。验证方法是直接发送一个请求到应用程序服务器,而不是通过 ODR 或通过 ODR 前端的 web 服务器。

ODR 中如何记录请求

ODR 处理的所有请求都被记录在下列文件之一:local.log 或 proxy.log。local.log 中记录的所有请求表明故障出现在 ODR 中,而 proxy.log 文件中记录的失败请求可能表明问题出在应用程序服务器上。

如何阅读 target.xml 文件

下面部分将使用两个失败请求的示例来说明:

Request 1
http://localhost/snoot
127.0.0.1 - - [18/Jul/2010:19:25:11 -0400] "GET /snoot HTTP/1.1" 404 70
Request 2
http://localhost:12080/snoop
127.0.0.1 - - [18/Jul/2010:19:21:12 -0400] "GET /snoop HTTP/1.1" 404 70

步骤 1:确认 target.xml 文件的生成时间

检查 target.xml 文件上的时间戳。记住 ODR 上的 target.xml 文件是 ODR 状态的快照,其目的是捕获拒绝发生时起作用的 ODR 的状态。

步骤 2:确认请求应该路由到的应用程序

要确定哪个应用程序应该服务请求,首先应确认是否有 ODR 路由规则匹配入站请求。如果没有匹配的 ODR 路由规则,则默认行为是考虑单元中所有拥有匹配请求的 URI 模式的应用程序。需要牢记,一般规则是 ODR 试图匹配最具体的模式。这样,“http://snoop/xyz.html” 在匹配 “/snoop/*” 或 "/*" 之前优先匹配 “/snoop/*.html”。

以下 wsadmin 脚本可用于列示指定 ODR 的 ODR 路由规则。这个脚本必须针对其中记录了 404 或 503 响应的 ODR 运行。例如:

AdminTask.listRoutingRules('-odrname ODR01 -nodename ODR01_C01_WVE61_Node -protocol HTTP')
WASX7209I: Connected to process "dmgr" on node D_C01_WVE61_Node using SOAP connector;  
The type of process is: DeploymentManager
0 uri likein ('/snoot/*') 
          permit:WLOR:module=C01/DefaultApplication//DefaultWebApplication.war

根据这个规则,带有一个 snoot URI 地 请求(比如 Request 1)应该被路由到 web 模块 DefaultWebApplication.war。

如果没有匹配请求的 ODR 路由规则,比如 Request 2 这种情况,默认行为是考虑单元中的所有模块。要确定哪个应用程序应该服务 Request 2,最快的方法是在 target.xml 文件中搜索 URI snoop

<application name="DefaultApplication">
    <webModule name="DefaultWebApplication.war"> 
          …….
          ……..
           <uri name="/snoop/*"/>

这个来自 target.xml 文件的信息显示这两个请求都应该被路由到同一个应用程序。

步骤 3:验证应用程序的可用性和配置

接下来,检查应用程序的状态、版本和路由规则。要确定应用程序是否已启动,搜索 target.xml 文件中的下列信息:

 <serverApplication name="DefaultApplication">
      <property name="state" priority="1" value="STARTED"/>
 </serverApplication>

这个信息显示应用程序已启动。如果应用程序被停止,那么对有效的请求将返回一个 503 响应,而不是 404 响应。

我们已验证应用程序已启动,现在需要确认:

  1. 是否正在使用 WebSphere Virtual Enterprise 的 Application Edition 特性?
  2. 被请求的 URI 有效吗?
  3. 有一些应用程序路由规则吗?

target.xml 文件的以下部分包含解决这些问题需要的所有信息。

<application name="DefaultApplication">
  ....
  <property name="edition" priority="0" value=""/>
  <property name="state" priority="0" value="ACTIVE"/>
  ....
  .... 
  <!-- webModule section -->
   <webModule name="DefaultWebApplication.war">
     ....
     <property name="contextRoot" priority="0" value=""/>
     ....
     <!-- uri section -->
     <uri name="/*.jsp"/>
       <uri name="/*.jsv"/>
       <uri name="/*.jsw"/>
       <uri name="/servlet/*"/>
       <uri name="/snoop/*"/>
       <uri name="/hello"/>
       <uri name="/hitcount"/>
        ….
       </webModule>
  ....
  ....
  <!-- webRouteWorkClass section -->
  <webRouteWorkClass name="Default_HTTP_WC">
    <!-- uri section -->
    <uri name="/*"/>
    <!-- rule section -->
      <rule name="default">
        <property name="action" priority="2" value="permit:DefaultApplication"/>
      </rule>
      ....
      ....
</application>

前两个属性 stateedition 显示 Application Edition 特性是否正被使用。如果部署了多个版本,则有一个与 edition 属性关联的值,其中一个版本的状态要么为 INACTIVE,要么为 VALIDATE,而主版本的状态为 ACTIVE。

要能够接收请求,应用程序的状态必须为 ACTIVEVALIDATE。如果状态为 VALIDATE,则应用程序的另一个版本必须处于 ACTIVEINACTIVE 状态,还应该有已配置的 ODR 或应用程序路由规则。在本例中,应用程序状态为 ACTIVE,因此应用程序应该能够处理请求。

需要检查的下一个区域是 URI 组。Request 1 指定了一个 URI snoot,但 snoot 不是 URI 组的一部分。现在我们需要验证 GSC 配置。在 target.xml 文件中搜索 genericApplication,我们发现:

<application name="ODR01_C01_WVE61_Node/ODR01/GenericApplication">
    ……
    <!-- webModule section -->
         <webModule name="Default_default_host_HTTP_WC">
          <property name="contextRoot" priority="0" value=""/>
        <!-- uri section -->
            <uri name="/*"/>
       …..
       …..
 <webRouteWorkClass name="Default_default_host_HTTP_WC">
    <!-- uri section -->
          <uri name="/*"/>
              <!-- rule section -->
                <rule name="default">
                    <property name="action" priority="0" value="reject:404"/>
                </rule>
	…..
	……
</application>

GSC 被配置为接受所有带有 URI “\*” 的请求,其中有一个路由规则配置为用一个 404 响应拒绝所有匹配这个 URI 的请求。这解释了 Request 1 以一个 404 响应失败的原因。

Request 2 指定 URI snoop,这是 URI 组的一部分,因此这个应用程序应该能够处理这个请求。下一步是确定是否有一些应用程序路由规则可能会导致这个请求失败。

应用程序路由规则在应用程序的工作类中定义。在我们列示 DefaultApplication 的信息的示例中,您可以看到,所有带有 URI “/*” 的请求都可以通过这个应用程序处理。

此时,我们已经弄清 Request 1 为何失败,但需要继续深入 target.xml 文件才能明白 Request 2 为何也失败。

步骤 4:验证其中映射了应用程序的服务器的可用性

在 target.xml 文件中搜索名为 DefaultWebApplication.war 的 web 模块。文件显示该模块部署到集群 Default_Application_DC

<cluster name="Default_Application_DC">
   ……
<!-- server section -->
  <link name=
   "/cell/C01/node/A01_C01_WVE61_Node/server/Default_Application_DC_A01_C01_WVE61_Node"/>
  <link name=
"/cell/C01/node/A01_C01_WVE61_Node/server/Default_Application_DC_A01_C01_WVE61_Node_1"/>
<!-- webModule section -->
  <link name=
   "/cell/C01/application/DefaultApplication/webModule/DefaultWebApplication.war"/>
   ….
</cluster>

links 元素显示哪些服务器是集群的一部分,以及哪些模块已被映射到集群。在 target.xml 文件中搜索 link 元素中的服务器名,我们发现以下信息:

<node name="A01_C01_WVE61_Node">
  ……
  …..
  <server name="Default_Application_DC_A01_C01_WVE61_Node">
    ……
    <property name="state" priority="1" value="STARTED"/>
    <property name="reachable" priority="0" value="true"/>
    <property name="weight" priority="1" value="2"/>
    <property name="server.maintenancemode" value="false"/>
    …. 
  </server>
</node>
<!-- vHostGroup section -->
  <vHostGroup name="default_host">
  <!-- vHost section -->
    <vHost name="*:9090">
      <property name="port" priority="0" value="9090"/>
    </vHost>
  …..
</vHostGroup>

需要关注的属性是 statereachableweightmaintenanceMode。如果对于能够处理请求的所有服务器而言,以下任一条件为真,则将对有效请求返回一个 503 响应。

  1. state 属性设置为 STOPPED
  2. reachable 属性设置为 false。这意味着服务器已经启动,但由于某些网络问题,请求不能被路由到服务器。WebSphere Virtual Enterprise 不时尝试将请求路由到这个服务器,检查它是否已变为可达。
  3. weight 属性设置为 0。如果还有另一个服务器能够处理请求,则在将请求重新路由到新服务器时,相关性(affinity)被打破。
  4. maintenanceMode 属性设置为除 false 之外的其他任何值。如果是这样,ODR 不再将新请求路由到处于维护模式的服务器。但是,如果已创建一个 ODR 路由规则来覆盖这个行为,那么我们将会看到一个有效请求成功完成。

可以看出,这个服务器能够接收请求,因此我们必须检查虚拟主机部分,验证请求正在使用的端口有效。Request 2 使用端口 12080,该端口不在应用程序配置使用的虚拟主机组中。这才是 Request 2 失败的原因。要解决这个问题,要么使用虚拟主机组中的一个端口,要么将端口 12080 添加到虚拟主机组中。

现在,我们明白为何两个请求都失败了。

下一步操作

如果 target.xml 文件中的信息不能解释请求为何失败,执行以下操作:

  1. 检查是否有缺少一些修复程序。临时修复工具 能够确定您的环境缺少哪些修复程序,并提供一个机制来检索它们。应该应用的修复程序可以以 zip 文件形式 下载,这些文件还包含一些 readme 文件来提供所有修复程序的说明。
  2. 确定排队是否是请求失败的原因。如果检测到后端服务器可能不能处理其他请求,ARFM 可能会对请求排队。如果 ODR 上的队列已满,那么将返回 503 响应。要确认是否为这种情况,可以通过运行 wasadmin 脚本 <WebSphere_Install_Root>\bin\disableARFM.py 来禁用 ARFM 排队。一旦禁用,以下自定义属性将在单元范围内启用,且这一更改将被动态采用。
    arfmManageCpu=false

    这种更改仅当不利用 Service Policy 或 CPU 的超载保护时适用。

  3. 收集必要信息并联系支持部门。如果禁用 ARFM 能够解决问题,您需要收集 请求排队必要信息;否则,需要收集 ODR 请求路由问题必要信息

结束语

理解如何阅读 target.xml 文件有助于在 ODR 中出现路由故障时迅速找出原因并解决问题。要深入了解 WebSphere Virtual Enterprise,请参阅 “参考资料” 部分。

致谢

本文作者对 Adrian Vrouwenvelder 对本文的审阅和宝贵建议表示感谢!


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=608333
ArticleTitle=使用 target.xml 文件识别、理解并解决 WebSphere Virtual Enterprise On Demand Router 中的路由问题
publish-date=01172011