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 信息（也就是计数器值）的最高次数。

本文转自xudayu 51CTO博客，原文链接：http://blog.51cto.com/xudayu/70402，如需转载请自行联系原作者