Clustering

Clusters help to improve the performance of the system through:

• Load balancing: see below for more information;

• Failover: see below for more information;

• Distributed caching: this is automatically done for you in the dvserver-standalone-cluster.xml configuration file;

• Event distribution: metadata and data modifications are distributed to all cluster members.

Load Balancing

JDBC

To enable load balancing in its simplest form, specify multiple hostname and port number combinations in the URL connection string. Here is an example:

jdbc:cdatavirtuality:<vdb-name>@mm://host1:31000,host1:31001,host2:31000;version=2

If you are using a data source to connect to the CData Virtuality Server, use the AlternateServers property/method to define the failover servers. The format is also a comma-separated list of host:port combinations.

The client will randomly pick one server from the list and establish a session with it. If this server cannot be contacted, a connection will be attempted to each of the remaining servers in random order. This allows for both connection time failover and random server selection load balancing.

HAProxy

Another way to enable load balancing and high availability is using HAProxy. For detailed information on HAProxy, see this article and Luigi Fugaro’s example.

The load balancer should use an algorithm that supports sticky connections as the CData Virtuality Server sessions as specific to the original host. For HAProxy, we recommend using leastconn or source.

Failover

Post connection failover will be used if the autoFailover connection property on JDBC URL is set to TRUE. Post connection failover works by sending a ping, at most every second, to test the connection prior to use. If the ping fails, a new instance will be selected before attempting the operation.

This is not a real "transparent application failover" as the client will not restart the transaction/query or recreate session-scoped temporary tables, so we recommend using this feature with caution.

Running the CData Virtuality Server in Cluster Mode

To run the CData Virtuality Server in cluster mode, follow the steps described below for your case.

Note that all nodes need to be connected to the same dvconfig database.

Single-server Clustering Sandbox Configuration

1. Make a second copy of dvserver and uncomment the last line in the dvserver-cluster script so that on the first dvserver, the dvserver-cluster looks like this:

• Windows (dvserver-cluster.bat):

cd /d "%~dp0%"
"%~dp0%\standalone.bat" --server-config=dvserver-standalone-cluster.xml -Djboss.node.name=dvserver1

• Linux (dvserver-cluster.sh):

./standalone.sh --server-config=dvserver-standalone-cluster.xml -b 0.0.0.0 -Djboss.node.name=dvserver1

and on the second dvserver, like this:

• Windows (dvserver-cluster.bat):

cd /d "%~dp0%"
"%~dp0%\standalone.bat" --server-config=dvserver-standalone-cluster.xml -Djboss.node.name=dvserver2 -Djboss.socket.binding.port-offset=100

• Linux (dvserver-cluster.sh):

./standalone.sh --server-config=dvserver-standalone-cluster.xml -b 0.0.0.0 -Djboss.node.name=dvserver2 -Djboss.socket.binding.port-offset=100

2. Run the first dvserver using the dvserver-cluster script.

3. The first dvserver will be configured as coordinator. Wait for the server to start completely: it will be connected to the cluster due to the coordinator process.

4. Run the second dvserver: it will be connected to the cluster due to the coordinator process on the first dvserver.

5. If the primary dvserver experiences a failure, the coordinator duties will be automatically handed off to the next available server in the system.

6. The JDBC host of the first dvserver will be as follows: localhost:31000, and for the second one, as follows: localhost:31100.

Multi-server Clustering Configuration

The high availability configuration has default multicast addresses set to 230.0.0.4. They can also be changed in the socket-binding section in the dvserver-standalone-cluster.xml file. Alternatively, you can add it as parameter like -u 230.0.1.2.

1. Make a second copy of dvserver and uncomment the last line in the dvserver-cluster script, so that on the first dvserver, the dvserver-cluster looks like this:

• Windows (dvserver-cluster.bat):

cd /d "%~dp0%"
"%~dp0%\standalone.bat" --server-config=dvserver-standalone-cluster.xml -b 172.16.0.1 -u 230.0.0.4 -Djboss.node.name=dvserver1

• Linux (dvserver-cluster.sh):

./standalone.sh --server-config=dvserver-standalone-cluster.xml -b 172.16.0.1 -u 230.0.0.4 -Djboss.node.name=dvserver1

and on the second dvserver, like this:

• Windows (dvserver-cluster.bat):

cd /d "%~dp0%"
"%~dp0%\standalone.bat" --server-config=dvserver-standalone-cluster.xml -b 172.16.0.2 -u 230.0.0.4 -Djboss.node.name=dvserver2 -Djboss.socket.binding.port-offset=100

• Linux (dvserver-cluster.sh):

./standalone.sh --server-config=dvserver-standalone-cluster.xml -b 172.16.0.2 -u 230.0.0.4 -Djboss.node.name=dvserver2 -Djboss.socket.binding.port-offset=100

In the examples above, -b 172.xx.xx.xx is the IP address of the computer the CData Virtuality Server is running on.

2. Run the first dvserver using the dvserver-cluster script.

3. The first dvserver will be configured as coordinator. Wait for the server to start completely: it will be connected to the cluster due to the coordinator process.

4. Run the second dvserver: it will be connected to the cluster due to the coordinator process on the first dvserver.

5. If the primary dvserver experiences a failure, the coordinator duties will be automatically handed off to the next available server in the system.

6. The JDBC host of the first dvserver will be as follows: 172.16.0.1:31000, and for the second one, as follows: 172.16.0.2:31100.

Limitations

When the SELECT INTO operation fails, the metadata is not automatically removed from all nodes. Consequently, a manual refresh is required for each individual node.

JDBC connection string changed in v4.10: both jdbc:datavirtuality and jdbc:cdatavirtuality are acceptable