Core group transports

 

+

Search Tips   |   Advanced Search

 

Core group members communicate with each other over a specialized and dedicated network transport. Multiple transport implementations are supported, each with its own set of advantages and disadvantages.

You can use one of the following types of transports to set up communications between core group members:

All of these transport options require TCP/IP connections for communication between core group members. The high availability discovery protocol ensures that these connections are opened, but the selected transport opens the connections. The discovery protocol also ensures, for each core group member, that connections are opened to all other members of that core group, thereby ensuring that all running core group members are fully connected through TCP/IP.

Each core group member has a configured endpoint known as the DCS_UNICAST_ADDRESS. This endpoint contains the host and port information that indicates where the core group member is listening for TCP/IP connections.

 

Channel framework transport

The channel framework transport is the most flexible and scalable of the transport options and is the best option for most topologies. The channel framework transport provides the most security options for core group connections. However, the advanced features of the channel framework transport come at the cost of slightly lower performance. This performance impact is a concern only in the most demanding topologies where replication throughput is a primary objective.

The channel framework transport is the default transport type for core group member connections. If you use a channel framework transport, all communication occurs directly over the core group TCP/IP connections. The work of opening connections and sending or receiving data is delegated to the channel framework transport and the associated channel implementations.

For example, to use a channel framework transport for distribution and consistency services (DCS) messages, configure either a DCS transport chain, which is the default, or a DCS_SECURE transport chain, in addition to the DCS_UNICAST_ADDRESS endpoint. A DCS transport chain uses a TCP channel for network communication. A DCS_SECURE transport chain includes both a TCP channel and an secure sockets layer (SSL) channel to add support for encrypted communication.

The channel framework function provides a common model for connection management, and contains support for implementing various channels that you can combine into a transport chain. The ability to combine various types of channels makes it possible to create custom transport chains. The channel framework function also supports port sharing, which provides additional flexibility and the potential for future customization. If you use a channel framework transport, two different mechanisms are available to secure the core group network connections:

  1. An LTPA token is used to authenticate all incoming connection requests if administrative security is enabled.

  2. SSL is used to encrypt all communications if the SSL version of a transport chain is selected.

You can use these mechanisms separately or combine them for the highest level of security possible.

 

Unicast transport

The communication mechanism of the unicast transport is similar to that of the channel framework transport. All communications occur over core group TCP/IP connections. The major difference is that a standard network connection, instead of a transport chain, is established and used to perform the communication between core group members.

Because a unicast transport does not go through the channel framework, this transport is somewhat faster than the channel framework transport. This performance improvement might be useful in topologies that make extensive use of memory-to-memory replication, and where the throughput that is obtained using a channel framework transport is not adequate.

Internal benchmarks show a gain in throughput using a unicast transport rather than a channel framework channel. However, this performance gain is achieved at the cost of using additional ephemeral ports.

A unicast transport has fewer security options than the channel framework transport. As with the channel framework transport, if WebSphere administrative security is enabled, an LTPA token is used to authenticate all incoming connection requests. However, no SSL encryption option is available for a unicast transport.

A unicast transport provides optimum performance with basic security. You trade the flexibility that a channel framework transport provides for improved performance. You are no longer able to do things like configure for SSL encrypted communication, or create a custom transport chain. However, in a typical appserver environment, the unicast transport provides the best performance for functions like memory-to-memory session replication.

Because a unicast transport uses more ephemeral ports than a channel framework transport, it might not scale as well as a channel framework transport does as the core group size increases.

 

Multicast transport

The multicast transport uses IP multicast and broadcasts information to all of the other processes in the core group. Although IP multicast uses a user datagram protocol (UDP), failure detection protocol still requires TCP/IP connections to be set up between core group members. The multicast transport requires the following additional configuration parameters:

A multicast transport also provides a high level of performance. However, because a multicast transport broadcasts information to all of the members of a core group, it is best suited for situations where many core group members need the same information. If you use a multicast transport when only a few members need the same information, you risk saturating the network with unnecessary data packets.

The multicast transport is the least secure of the available core group transport types because it broadcasts information out to all members of the networks. There are no restrictions as to who could potentially receive the data or try to send data to the connection. By default, the Time to Live (TTL) field in the IP header is 1. Therefore, multicast data is restricted to the subnet on which it is sent. If all of the systems are protected and located on the same subnet, then additional levels of security might not be required.

The multicast transport is optimum when many members in the core group need to have data replicated across them. The multicast transport typically requires that all members of the core group be located on a single subnet.

 

Related concepts


Core group Discovery Protocol
Core group Failure Detection Protocol
Core groups (high availability domains)

 

Related tasks


Configure a core group transport