Validating Multicast Transport: Where Did My Instances Go?

For cluster health information and communication of high-availability state, GlassFish 3.1 depends on GMS. To dynamically discover the members of a cluster, GMS depends on UDP multicast. So if there's something about your network preventing multicast communication among hosts, instances will become isolated from each other.

As I wrote in my last blog on the 'asadmin get-health' command, it's a good idea after starting your cluster to make sure everything is working correctly. With the asadmin validate-multicast command, you can diagnose issues with intra-instance communication or plan your cluster deployment before creating the cluster instances.

This asadmin subcommand is used to send and receive UDP multicast information, and so acts to validate that various hosts can all communicate with each other. The usage is simple in concept: run the tool on each host at the same time, using the same multicast address and port, and verify from the tool's output that each host receives messages from the others. So if you're running on hosts 1, 2, and 3, then you should see this when running on host 1:

    Listening for data...
    Sending message with content "host1" every 2,000 milliseconds
    Received data from host1 (loopback)
    Received data from host2
    Received data from host3

Likewise, hosts 2 and 3 should see messages from all 3 machines. Make sure you're not running the DAS and instances at the same time, or else there will be interference with the UDP traffic. Here is a video showing some features of the tool:

Debugging, Step 1: Use Same Multicast Port/Address as Cluster

While this tool can be useful to check your network before deploying your cluster, it is most helpful when one instance is not communicating with the DAS/other instances. You may see this if you run the 'get-health' command described in the previous blog. If you know that an instance is up according to its server log, but it's showing up as "not started" in the get-health output, then it's likely that the DAS and the instance are not seeing each others' UDP multicast messages. In this case, you want to run asadmin validate-multicast with the following options:

  • --multicastport The value of gms-multicast-port for your cluster in domain.xml.
  • --multicastaddress The value of gms-multicast-address for your cluster in domain.xml.

Using those options will make the tool use the same values as the members of your cluster, in effect simulating the GMS traffic between the DAS and instances. To find the values for those options, you can read them from the attributes on the <cluster> element in domain.xml. For instance:

    <cluster name="mycluster"
        [etc.] >
      <server-ref ref="instance1"></server-ref>
      <!-- [etc.] -->

Debugging, Step 2: TTL

Unless specified on the command line, the validate-multicast tool and GMS use the default MulticastSocket time-to-live for your operating system or 4, whichever is greater. You can see this in the tool's output if you run with the --verbose flag. For example:

    McastSender: The default TTL for the socket is 1. Setting it to minimum 4 instead.

You can try increasing this value to see if it is the limiting factor that prevents packets from reaching the cluster members with your network configuration. To specify a different value, use the following option with the tool (in addition to --multicastport and --multicastaddress):

  • --timetolive Sets the time-to-live value of the multicast packets sent by the tool.

If you are now seeing all the instances you expect, you can change your cluster configuration so that GMS uses this TTL value. It is simple to pass this value into the asadmin create-cluster command. See the "To Create a Cluster" section of the High Availability Administration Guide for an example. If your cluster is already running, however, you can set this value with asadmin set. See the "To Change GMS Settings After Cluster Creation" section of the HA guide. The property to be set is GMS_MULTICAST_TIME_TO_LIVE, and it is listed in the "Dotted Names for GMS Settings" section.

Debugging, Step 3: Specifying the Network Adapter

On a multi-home machine machine (possessing two or more network interfaces), you may need to specify the local interface that should be used for UDP multicast traffic. You can use ifconfig, or the equivalent on your system, to list the network interfaces and obtain the local IP address of the interface you wish to use. This address can then be used with the following command line parameter (along with any you're already specifying):

  • --bindaddress Sets the local interface used to receive packets.

Note that this value will be different on each machine where you are running the tool. If you are now seeing all the instances you expect, you can set the GMS bind interface for each instance following the instructions in the "Traffic Separation Using Multi-Homing" section of the HA guide.

If one or more machines are still missing in the output, then it may be that they are located on different subnets from each other. Or it could be that UDP multicast is not enabled on the network. You may need to ask the network administrator to verify that the network is configured so that the UDP multicast transport is available.

For more information, see the validate-multicast man page. A copy of the help information is attached here as well. The validate-multicast tool is also covered in more depth in the HA guide referenced above.


Post a Comment:
Comments are closed for this entry.

Whatever part of GlassFish or the Java EE world that catches my attention. (Also, go Red Sox.)


« July 2016