Network Deployment (Distributed operating systems), v8.0 > Establishing high availability > Configure core groups > Configure a core group transport
Core group transports
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.
We can use one of the following types of transports to set up communications between core group members. However, if possible, use a channel framework transport, because support for unicast transports is deprecated.
- Channel framework transport, which is the default transport
- Unicast transport
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 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 a 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 facilitates future customization.
If you use a channel framework transport, two different mechanisms are available to secure the core group network connections:
- A lightweight third-party authentication (LTPA) token is used to authenticate all incoming connection requests if administrative security is enabled for the product.
- SSL is used to encrypt all communications if the SSL version of a transport chain is selected.
We can use these mechanisms separately or combine them for the highest level of security possible.
Unicast transport
Deprecated feature: Support for unicast transports is deprecated. You should use the channel framework transport as your transport type whenever it is possible to do so.depfeat
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 transport. 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 administrative security is enabled for the product, 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 application server environment, the unicast transport provides optimal 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.
Core groups (high availability domains)
Core group discovery and failure detection protocols
Configure a core group transport