JBoss企业级应用服务平台群集指南(十)

2.1.2      Discovery协议

    群集系统需要一直维护当前成员节点的列表，这样负载平衡系统（ load balancer ）和客户端拦截器（ client interceptor ）就知道怎样去指引它们的请求。发现协议（ discovery protocols ）用来在群集系统里探索活动节点。当群集系统启动时将检测到所有的初始节点。之后如果有新的节点加入，它只有在组成员协议（ group membership protocol ）（ GMS ，参见章节 1.5.1, “组成员资格”）批准后才能被探索（ discovered ）到。

    既然发现协议（ discovery protocols ）处于传输协议之上，你可以根据你的传输协议选择不同的发现协议。发现协议在 JGroups MBean Config 元素里也被配置成子元素（ sub-elements ）。

2.1.2.1        PING

    PING 发现协议（ discovery protocol ）通常在 UDP 传输协议之上。每个节点用一个单播的 UDP 数据报文（ datagram ）来应答发送者。下面是 JGroups Config 元素下 PING 配置的例子。

< PING timeout ="2000" num_initial_members ="2" />

 

下列是 PING 元素里的可用属性。

•   timeout 指定等待应答的最长时间（毫秒数）。

•   num_initial_members 指定等待的最大的应答数量。

•   gossip_host 指定 GossipRouter 在哪个主机上运行。

•   gossip_port 指定 GossipRouter 所侦听的端口。

•   gossip_refresh 指定 GossipRouter 的租约（ lease ）的时间间隔（毫秒数）。

•   initial_hosts 是一个用逗号隔开的地址列表（如： host1[12345],host2[23456] ），群集系统会 ping 这个列表来进行探索（ discovery ）。

    如果 gossip_host 和 gossip_port 都被定义了，群集系统会使用 GossipRouter 作初始探索（ initial discovery ）。如果指定了 initial_hosts ，群集系统会 ping 这个静态地址列表来进行探索。否则，群集系统用 IP 多点传送来进行探索。

注意
   当已经过了 timeout 毫秒后或者已经接收到 num_initial_members 应答后，探索阶段就会返回。

2.1.2.2        TCPGOSSIP

    TCPGOSSIP 协议只用于 GossipRouter 。它和 PING 协议配置基本上一样，有着有效的 gossip_host 和 gossip_port 属性。它处于 UDP 和 TCP 协议的上面。下面是一个例子。

< PING timeout ="2000"
initial_hosts ="192.168.5.1[12000],192.168.0.2[12000]"
num_initial_members ="3" />

下列是 TCPGOSSIP 元素里的可用属性。

•   timeout specifies the maximum number of milliseconds to wait for any responses.

•   num_initial_members specifies the maximum number of responses to wait for.

• initial_hosts 是一个 GossipRouters 用来注册的用逗号隔开的地址列表（如： host1[12345],host2[23456] ）。

2.1.2.3        TCPPING

    TCPPING 协议使用一套知名成员并 ping 它们来进行探索。它基本上是一个静态的配置。它工作于 TCP 协议的上面。这里是一个 JGroups Config 元素里的 TCPPING 配置元素的例子。

< TCPPING timeout ="2000"
initial_hosts ="192.168.5.1[7800],192.168.0.2[7800]"
port_range ="2" num_initial_members ="3" />

下列是 TCPPING 元素的可用属性。

•   timeout specifies the maximum number of milliseconds to wait for any responses.

•   num_initial_members specifies the maximum number of responses to wait for.

• initial_hosts 是一个用来 pinging 的用逗号隔开的地址列表（如： host1[12345],host2[23456] ）。

•   port_range specifies the range of ports to ping on each host in the initial_hosts list. That

is because multiple nodes can run on the same host. In the above example, the cluster would ping ports 7800, 7801, and 7802 on both hosts.

2.1.2.4        MPING

    MPING 协议是 TCP 上的多点传送 ping 协议。它和 PING 在 UDP 上工作的方式一样。它不要求外部的进程（ GossipRouter ）或静态配置（初始主机列表）。这里是一个 JGroups Config 元素的 MPING 配置元素的例子。

< MPING timeout ="2000"
bind_to_all_interfaces ="true" mcast_addr ="228.8.8.8" mcast_port ="7500" ip_ttl ="8" num_initial_members ="3" />

下列是 MPING 元素的可用属性。

•   timeout specifies the maximum number of milliseconds to wait for any responses.

•   num_initial_members specifies the maximum number of responses to wait for.

•   bind_addr 指定在哪个接口上发送和接收多点传送数据包。

•   bind_to_all_interfaces 覆盖了 bind_addr 并使用多宿主节点上的所有接口。

•   mcast_addr, mcast_port, ip_ttl 属性和 UDP 协议配置的相关属性相同。

2.1.3      故障检测协议

    故障检测协议（ failure detection protocols ）用来检测发生故障的节点。一旦检测到了一个发生故障的节点，群集系统会更新它的视图，使负载平衡系统（ load balancer ）和客户拦截器（ client interceptors ）避开死节点。故障检测协议被配置为 JGroups MBean Config 元素里的子元素。

2.1.3.1        FD

    FD 发现协议（ FD discovery protocol ）要求每个节点定期地发送 are-you-alive 信息给它的邻居节点。如果这个邻居没有应答，呼叫节点将给群集系统发送一个 SUSPECT 信息。当前的 group coordinator 会复核这个可能有问题的节点是否真的已经崩溃了，并更新群集系统的视图。这里是一个 FD 配置的例子。

< FD timeout ="2000" max_tries ="3" shun ="true" />

下列是 FD 元素的可用属性。

•   timeout 指定对 are-you-alive 信息的应答的最长等待时间（毫秒数）。

•   max_tries 指定在一个节点被怀疑为崩溃前，所丢失的 are-you-alive 信息的次数。

•   shun 指定崩溃的节点是否该被剔除（ shunned ）。一旦被剔除，这个节点将从群集里开除，即使之后它又恢复了。被剔除的节点可以通过探索过程（ discovery process ）重新加入到群集系统里来。

注意
   从某个节点的有规律的网络流量可以判定它是否正常工作。所以，are-you-alive 信息只是在节点有一段时间没有有规律的网络流量时才发送。

2.1.3.2        FD_SOCK

    当有很多节点时， FD 协议的 are-you-alive 信息会增加网络的负载。它也会产生误判。例如，如果网络太繁忙了而且超时时间（ timeout ）设置的很短，节点就有可能被误怀疑为崩溃了。此外，如果节点在调试器（ debugger ）或剖析工具（ profiler ）里被挂起时，它有可能被怀疑或剔除（ shunned ）。为了解决上述问题， FD_SOCK 协议依据只有有规律的与节点的 TCP 连接失败后才怀疑节点崩溃。然而，这种消极检测的问题是，挂起的节点只有被访问时或者 TCP 连接超时几分钟后才会被检测到。 FD_SOCK 在所有节点都被频繁访问的高负载的网络里表现最好。最简单的 FD_SOCK 配置不要设置任何属性。你可以只在 JGroups 的 Config 元素里声明一个空的 FD_SOCK 就可以了。

< FD_SOCK />

FD_SOCK 元素只有一个可选属性

•   srv_sock_bind_addr 指定服务器套接字应该绑定的接口。如果它被忽略，服务器启动时命令行里的 -D bind.address 属性将被使用。

2.1.3.3        FD_SIMPLE

    FD_SIMPLE 协议是一个基于 are-you-alive 信息的更加宽容（更少误判）的协议。每个节点定期地发送 are-you-alive 信息给随机选取的节点然后等待应答。如果在某一超时时间内还没有收到应答，和这个节点相关的计数器将增加。如果计数器超过了某一个值，这个节点就会被怀疑。当接收到对 are-you-alive 信息的应答时 , 这个计数器将清零。下面是 FD_SIMPLE 协议的一个配置例子。

< FD_SIMPLE timeout ="2000" max_missed_hbs ="10" />

下列是 FD_SIMPLE 元素的可用属性。

•   timeout 指定对 are-you-alive 信息应答的以毫秒为单位的超时时间。如果在这个时间内没有收到应答，目标节点的计数器将增加。

•   max_missed_hbs 指定节点被怀疑为崩溃前可以丢失的 are-you-alive 信息（也就是计数器值）的最高次数。