[转帖]WebLogic Server 组播问题疑难答解_Tomcat, WebLogic及J2EE讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛

总帖数

每页帖数

1/1页

返回列表

发起投票

查看: 4642 | 回复: 0

主题： [转帖]WebLogic Server 组播问题疑难答解

root

注册用户

等级：中尉
经验：470
发帖：31
精华：1
注册：2013-2-22
状态：离线
发送短消息息给root

加好友发送短消息息给root

发消息

发表于：

2013-2-26 9:40:37 | [全部帖] [楼主帖]

楼主

当在您的配置中存在组播问题时，如果需要调试编译应用程序，您的问题通常要么是在BEA WebLogic Server 中组播配置错误，要么是网络问题（例如在所指有问题的机器中组播本身并没有建立）。请使用该校验清单来检查配置、其他可能的问题以及组播的

常见问题

。

导致集群群集不能启动或服务器加入集群群集失败的最常见原因之一是组播地址问题。每个群集都需要组播地址。组播地址可以是介于224.0.0.0 到 239.255.255.255之间的一个IP地址，或者IP地址在该范围之内的一个主机名。您可以使用WebLogic Server Console 来检查集群群集的组播地址和端口。

对于针对排版错误或拼写错误，请检查config.xml��件中或控制台上的组播信息。特别要查看组播的地址和端口。如果组播地址有问题，那么您最有可能看到的错误信息是：

·         "Unable to create a multicast socket for clustering" （不能为集群群集创建组播套接字）
·         "Multicast socket send error" （组播套接字发送错误）
·         "Multicast socket receive error" （组播套接字接收错误）

对于集群群集中的Version 6.x，组播端口号是从每台个服务器的监听端口设置拷贝而来的。由于集群群集中的所有成员必须使用相同的组播地址和端口号，所以拷贝来的端口号要求集群群集中的所有服务器使用相同的监听端口。对于集群群集中的Version 7.x 和更高的版本，集群群集的组播配置不再依赖于单独单个服务器的网络配置。相反，配置的组播端口号与和集群群

集成

员所使用的端口号是相互独立的。您也可以识别指定每台个集群群集服务器在��进行组播通信时应该使用哪个网络接口卡（NIC）。

验证不存在任何诸如网络连接不存在的物理问题以及没有其他的应用程序正在使用该集群群集组播地址。检查检验方法之一是使用特定的操作系统命令来查看该地址/端口是否正在使用中，该命令是netstat。然后检查检验以确保赋分配给多台个机器的IP地址没有重复。

如果您得到一条信息显示为 “Unable to send service announcement（不能发送服务声明），”消息，这可能指出意味着一个常见的网络问题或者DNS配置错误。集群群集服务器之间通过组播进行通信并且必须共享相同的（独占的）组播地址。

运行 utils.MulticastTest 实用程序

工具

来验证组播正在工作，或者如果已经查看到它正在工作，用该

工具

来验证不同的集群群集正在互相对话，这是不希望的。例如：

在Run this on MachA上运行："java utils.MulticastTest -N ginger -A 237.0.0.1 -P 7126"
在Run this on MachB上运行："java utils.MulticastTest -N fred -A 237.0.0.1 -P 7126"
在Run this on MachC上运行："java utils.MulticastTest -N smith -A 237.1.1.60 -P 7126"
在Run this on MachD上运行："java utils.MulticastTest -N jones -A 237.1.1.60 -P 7126"

您在第一组合中应该看到只有fred和ginger交换了消息交换。相反您在第二组合中应该看到只有smith和jones交换了消息交换。如果您看到在这两个组合之间有消息交换，或者根本看不到来自其他进程的消息，说明有网络出现了问题。

如果组播测试失败，请要检查是否使用了主地址（WebLogic Server需要使用主地址）。检查DNS的是否正确设置和使用是否正确了DNS。您也可以获取/usr/sbin/ifconfig -a 信息（它必须作为根来运行以获取MAC地址），并检查多重初始地址宿主环境中的每台机器的MAC地址。如果所有MAC地址都相同，那么这可能就是问题的症结所在。您将不得不必须要确保这些MAC地址的惟一性，尤其是在Solaris环境下。一种规避方法是用一个接口卡将所有的有多重初始宿主地址的Solaris机器集中到一起。另一种规避方法是再添加另一块接口卡。这是Solaris的一个已知的问题。

一种情况是仅针对Solaris的，并且不能应用于其他平台。在Solaris和SunOS系统上，以太网设备通常被称为le0 或 ie0。要查找以太网设备的MAC地址，首先使用su命令变成根，通过使用su。然后键入ifconfig -a 并查看有关信息。例如：

# ifconfig -a
le0: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING>
inet 131.225.220.144 netmask ffffff00 broadcast 131.225.255.255
ether 8:0:20:f:c2:f8

Solaris 和 SunOS 通常会将通常包含在MAC地址中的前导0去除。在本机的这种情况下，MAC地址是08:00:20:0f:c2:f8。参见：www.dimensional.com/findmac.html。

依赖于操作系统，文件描述符（FD）的数量可以是一个已知问题。例如，描述符用尽的问题可能发生在Solaris上，这是因为打开了太多的文件。Sun 指出这是由于一个fopen的限制。您可以做一些如lsof 的动作并查看在出现该问题时进程已经在磁盘上上打开文件的数量（不要担心套接字文件描述符）。如果描述符用尽确实成为了一个问题，请增加系统上FD的数量。这需要系统管理员来完成。

检查机器本机上的 /etc/nsswitch.conf 文件。您可能不得不将服务器上nsswitch.conf文件中的顺序改变为files、DNS、NIS以避免在随机时间出现的UnknownHostExceptions异常（甚至在服务器不是处在大于繁重负载的时候也可能出现）。这里是nsswitch.conf之手册页面的一部分：

注意：在使用nsswitch.conf 的每个进程中，整个文件只读取一次，如果该文件在后来有了改变，进程仍然将继续使用旧的配置。在Solaris环境中，使用NSS Service静态地链接��序是不可能的。在Linux环境中，这是没有问题的。

当发生NIC故障切换时会出现组播超时（像关闭网络）。这可导致像这样的消息： <Error> <Cluster> <Multicast socket receive error: java.io.InterruptedIOException: Receive timed out>

如果您遇到了这种消息：

·       尝试禁用关闭网络接口卡（NIC）的故障切换功能。

·       查看Internet分组管理协议(IGMP)。受网管交换机的一个设置称为IGMP侦听，它在默认情况下处于有效启用状态。该设置用来阻止在受网管交换机上出现组播泛洪泛滥（multicast flood）问题。通过关闭禁用受网管交换机上的IGMP侦听，WebLogic Server 组播测试无限期地成功了。

·       W2K 设置以确认：

· IGMPLevel
· Key: Tcpip\Parameters

·       取值类型： REG_DWORD - Number

·       有效范围： 0、1、2

·       默认值：2

·       描述: 此参数确定系统对IP组播和参与IGMP的支持程度。在第0级，系统不提供组播支持。在第1级，系统只发送IP组播报文数据包。在第2级，系统可以发送IP组播报文数据包并完全参与IGMP以接收组播报文数据包。尝试将其设置为2。

·                   您也可以尝试设置令MulticastTTL=32。参见：http://e-docs.bea.com/wls/docs70 ... fig_multicast.html.

如果您发现您正在经历组播风暴（multicast storm），您可能需要配置组播缓冲区的大小。TCP/IP的内核参数可以用UNIX ndd实用程序来配置。参数 udp_max_buf 控制着UDP套接字发送和接收缓冲区（以字节为单位）的大小。针对不同的部署，udp_max_buf 参数有不同的适合数值。如果您正在经历组播风暴，将udp_max_buf 的值增加32K并评估改变后的效果。不要武断地更改udp_max_buf 的值，除非您遇到了问题而且您的网络管理员认为有必要改变它的值。在对udp_max_buf 进行更改之前，请仔细阅读Solaris Tunable Parameters Reference Manual （参见 Resources）中“TCP/IP Tunable Parameters“一章“UDP Parameters with Additional Cautions“一节中的Sun的警告。如果您再次注意到组播风暴，您可以尝试将缓冲区增加32K，而同时也使用WebLogic的指数延迟参数。

如果已经设置了组播延迟（multicast delay）并且无法解决问题，那么您就需要查看两个操作系统参数了，这两个参数是接收和传输组播数据包的udp缓冲区大小。例如，如果udp 设置被设置为8K而组播数据包大小是32K（WebLogic所允许的最大值），那么就可能出现问题。如果udp_xmit_hiwat 和udp_recv_hiwat 被设置为64K，则问题迎刃而解。

如果所有这些选择都不能形成一个解决方案，那么您可以收集BEA客户支持的调试信息以备后用。随着启用这些调试参数，

日志

文件中将会有许多消息。组播的特定调试参数是：

·         DebugCluster
·         DebugClusterHeartbeats
·         DebugClusterFragments

这些参数可以在服务器启动时通过在命令行添加以下的命令来设置：

·         -Dweblogic.debug.DebugCluster=true
·         -Dweblogic.debug.DebugClusterHeartbeats=true
·         -Dweblogic.debug.DebugClusterFragments=true

也可以通过使用“weblogic.Admin”实用程序来动态设置这些参数。例如：

java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic SET -type ServerDebug -property DebugCluster true

您可以为其他参数重复该设置过程。您也可以关闭这些参数，只需运行相同的命令并将其设置为false。在您的配置中如果存在组播问题，这些解决方案中的一个应该会有所帮助。试一试看它们是否能起作用。