某集团LIMS服务器访问ERP系统故障分析、解决方案_百度文库

1、某集团LIMS 服务器访问ERP 系统故障分析1.1. 故障描述1. 故障现象LIMS 从2008.11.1正式接入网络，开始对ERP 系统进行访问。同时，集团内部还有很多用户对ERP 系统进行访问。从2009.1.5日开始，ERP 系统时常出现访问速度慢、业务瘫痪、甚至ERP 系统宕机的情况。集团网络管理人员分析后，发现当LIMS 系统断开与ERP 系统的链路时，ERP 系统一切正常。 继续分析后发现，在LIMS 系统与ERP 链路相连的时候，如果LIMS 系统使用手动模式时，ERP 工作正常；但使用自动模式（每5分钟一次查询），即会出现故障导致ERP 系统不能正常工作。备注：LIMS 的工

2、作模式有自动和手动两种。LIMS 系统开发商表示，自动和手动工作模式，在工作时没有任何区别。对LIMS 系统进行了彻底的安全检查、病毒木马查杀，但未发现任何异常。对ERP 系统进行了彻底的检查，但一切正常。2. 网络拓扑LIMS 访问ERP 系统的拓扑如图1所示。从图中可知，LIMS 访问ERP 的链路非常简单，具体是LIMS -> 接入交换机 -> 核心C6509E -> 数据中心C6509E -> ERP系统。 （图1 某集团LIMS 访问ERP 原始简易拓扑图）1.2. 具体分析1. 捕获数据包通过上述分析，明确了该故障属于应用故障，而不是网络故障。由于已对该应用

3、的两端（LIMS 和ERP ）进行过彻底检查，故在此情况下，我们捕获并分析了该应用的原始数据包。捕获数据包的位置是在LIMS 服务器和接入交换机之间，串接了一个HUB ，然后将捕获数据包的笔记本接入到HUB 上，如图2所示。 （图2 捕获LIMS 访问ERP 系统的原始数据包拓扑图）从捕获的数据包可知，不管是手动模式还是自动模式，LIMS 对ERP 进行1次访问，均会创建3个连接，其中2个是LIMS 从ERP 下载数据，第3个是LIMS 上传数据到ERP ，第3个与第2个连接之间相隔约105s （此时间应该是LIMS 检查本地是否存在更新）。 自动模式下首先进行的是LIMS 从ERP 下载数据

4、，然后是LIMS 上传数据到ERP 。 手动模式下可自由选择顺序（测试时两种顺序都进行了测试，下面的分析选择和自动模式一样的顺序，即先从ERP 下载，再上传到ERP ）。2. LIMS 访问ERP 的RFC 函数及模块通过科来的TCP 数据流重组，可以知道自动和手动两种模式下，LIMS 调用SAP 的RFC 函数只有极少数存在差异，具体如下。 自动模式LIMS 从ERP 下载数据，此过程包括2个连接。第1个连接调用SAP 函数及模块的顺序如下。RFCPINGRFC_SYSTEM_INFORFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_GET_UNICO

5、DE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTUREIRF_SEND_INSP_REQUIRMENTS（注：连续调用此函数若干次）第2个连接调用SAP 函数及模块的顺序如下。RFCPINGRFC_SYSTEM_INFORFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_GET_UNICODE_ST

6、RUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTUREQIRF_SEND_REQUIRMENTS_GET_D

7、ATALIMS 上传数据到ERP ，调用SAP 函数及模块的顺序如下：RFCPINGRFC_SYSTEM_INFORFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFOR

8、FC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTUREQIRF_GET_ALL_DATA_VALUE手动模式LIMS 从ERP 下载数据和自动模式一样，此过程也包括2个连接。第1个连接调用SAP 函数及模块的顺序如下：RFCPINGRFC_SYSTEM_INFORFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_GET_UNICODE_STRUCTURERFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURER

9、FC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTUREQIRF_SEND_INSP_REQUIRMENTSRFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTUREQIRF_SEND_INSP_REQUIRMENTS（注：连续调用此函数若干次）第2个连接调用SAP 函数及模块的顺序如下RFCPINGRFC_SYSTEM_INFORFC_SYSTEM_INFORFC_GE

10、T_FUNCTION_INTERFACERFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACEQIRF_SEND_REQUIRMENTS_GET_DATARFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTUR

11、ERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTUREQIRF_SEND_REQUIRMENTS_GET_DATALIMS 上传数据到ERP ，调用SAP 函数及模块的顺序如下。RFCPINGRFC_SYSTEM_INFORFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACERFC_SYSTEM_INFORFC_GET_UNICO

12、DE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURERFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTUREQIRF_GET_ALL_DATA_VALUES3. 疑问及故障原因多余的连接不管是自动模式和手动模式，不论是否存在更新，LIMS 都会和ERP 发起3个连接。这3个连接中，前2个检查ERP 端是否有更新及下载，是必须的。第3个连接是用于上传LIMS 端的更新到ERP 。如果LIMS 端在没有更新的时候，则不应该发起这个连接。但现在的

13、情况时，不论LIMS 端是否存在更新，都会和ERP 发起这个连接。这个连接会白白耗费网络和服务器资源，可向LIMS 开发人员了解相关的情况。同时，在第3个连接中，LIMS 端存在1次响应非常慢的情况，如图3，图4。 （图3 手动模式下，第3个连接响应时间太慢） （图4 自动模式下，第3个连接中时间太慢）在手动模式下，第3个连接中LIMS 端有个数据包的响应时间为1分4秒（图3）。在自动模式下，响应时间为57秒（图4）。从而使得LIMS 访问ERP 的速度较慢，ERP 系统资源将被长久占用，影响ERP 对其它客户端访问的响应。TCP 急迫位置1不论是自动还是手动模式，都从数据包中发现一个严重的问

14、题，应用层对LIMS 和ERP 的整个访问都进行了控制。LIMS 端发出的数据包，除TCP 握手、关闭及纯粹的ACK 应答数据包外，均将TCP 急迫位置1，如下图。（图 5 LIMS 到 ERP 的访问均将 TCP 急迫位置 1） TCP 急迫标志位置 1 的数据包，拥有比常规数据包更高的优先级。接收端收到 TCP 急迫标志位置 1 的数据包时，直接将其发送到应用层进行处理，而不用等待。 举例如下： 假设 ERP 目前负载较大，TCP 缓存里有 500K 的数据正在排队等待发送到应用层。 如果这时 ERP 再收到一个 500 字节的常规数据包，那么这个数据包将在 TCP 缓存里面排队，待前面

15、的 500K 传输完毕后，再发送到应用层处理。 如果这时 ERP 接收到一个 TCP 急迫位置 1 的 500 字节的数据包。这时，ERP 会立即将这个 500 字 节的数据包，连同缓存中的 500K 数据一起送到应用层处理。由于 ERP 负载已经非常大，在这种特殊情况 下，ERP 系统将不能承受，由此导致服务器出现响应慢，甚至宕机。 所以，当其它用户正在对 ERP 进行访问时，LIMS 发起了和 ERP 的通讯，由于 LIMS 发起的绝大部分 数据包都将 TCP 急迫位置 1，因而 LIMS 发向 ERP 的数据将被直接送到应用层让 ERP 对其进行响应，从 而打破了正常的通讯秩序。 那为什么此故障不是一直出现，而是有时出现呢，且手动模式不出现此问题呢？ 当 ERP 系统空闲的时候，ERP 有足够的资源响应 LIMS，及其它相对较少的应用，所以在这个时候， ERP 系统工作正常。 可是当 ERP 系统繁忙的时候，一旦 LIMS 和 ERP 进行通讯，这时由于 LIMS 抢占了 ERP 的资源，打 破了正常的传输秩序，使得 ERP 响应过慢，甚至使 ERP 系统内部出现混乱，导致宕机。 手动模式的情况 下，只有用户发起连接，才会进行上述的操作。其实很可能问题也存在，但由于频率 不高，故障未被注意。 从上面两点可以知道，其实从 2008 年 11 月 1 日