Connecting Nodes

Every Remote Services cluster starts with a single node. The steps for starting Remote Services on a single node, either as a standard process or as a service, were covered in earlier sections.

Before adding nodes into your cluster, you first need to make sure that the cluster token (property CLUSTER_TOKEN in the configuration file) has the same value in each node. For better security, we recommend that you change the predefined value of the token by generating a new one and pasting the same value into each node configuration file. You can generate a new token with the following command:

> grb_rs token
GRBTK-6o4xujs59WJO5508nmaNwc1TtjZJAL1UcwN4vTD4qK4nata8oLr9GnubyXrLTkggc/aw2A==

Similarly, the passwords used for client, administrator and cluster administrator must be the same in all nodes. For better security, it is recommended to change the predefined value of the passwords by choosing a new password, generating a hash value for that password, and then pasting the result into each node configuration file. You can generate a hash of your chosen password (e.g., mynewpass) with the following command:

> grb_rs hash mynewpass
$$v0UBWkM_9kpY_v2RECV2LBGnlr8qzaGHzf0fMJvrMYwPnJap

Adding nodes to your cluster

Once you've started a single-node cluster, you can add nodes using the --join flag to grb_rs or the JOIN configuration property. For example, if you've already started a cluster on the default port of server1, you would run the following command on the new node (call it server2) to create a two-node cluster:

> grb_rs --join=server1

In the log output for server2, you should see the result of the handshake between the servers:

info  : Node server1, transition from JOINING to ALIVE

Similarly, the log output of server1 will include the line:

info  : Node server2, added to the cluster

If you are using a non-default port, you can specify the target node port as part of the node URL in the --join flag and you can specify the port of the current node using the --port flag. You could use different ports on the different machines, but it is a good practice to use the same one, for example 61000. The command would look like this instead:

> grb_rs --join=server1:61000 --port=61000

The JOIN property can also be set through the configuration file in the same way:

JOIN=server1:61000
PORT=61000
When starting grb_rs as a service, you won't have the opportunity to provide command-line options, so you'll need to provide this information through the configuration file.

Once you've created a multi-node cluster, you can add additional nodes to that cluster by doing a JOIN using the name of any member node. Furthermore, the --join flag or the JOIN property can take a comma-separated list of node names, so a node can still join a cluster even if one of the member nodes is unavailable. Note that when a list of nodes is specified, the joining node will try to join all the specified nodes at the same time. Joining nodes is an asynchronous process, if some target nodes are not reachable, the joining node will retry before giving up on joining. If all the nodes are reachable, they will all join and form a single cluster.

Checking the status of your cluster

Using grbcluster, you can check the status of the cluster:

> grbcluster --server=server1 --password=pass nodes --long
ADDRESS STATUS TYPE    LICENSE PROCESSING #Q #R JL IDLE     %MEM  %CPU  STARTED             RUNTIMES VERSION
server1 ALIVE  COMPUTE VALID   ACCEPTING  0  0  2  46h59m0s 9.79  0.50  2017-09-27 17:03:24 [8.0.0]  8.0.0
server2 ALIVE  COMPUTE VALID   ACCEPTING  0  0  2  46h46m0s 8.75  0.00  2017-09-27 17:16:11 [8.0.0]  8.0.0

The nodes of the cluster are constantly sharing information about their status. When using grbcluster, you can use any of the nodes in the --server flag for all global commands.

Each node can be in one of the following states:

ALIVE
The node is up and running.

DEGRADED
The node failed to respond to recent communications. The node could return to the ALIVE state if it can be reached again. The node will stay in this state until a timeout (controlled by the configuration property DEGRADED_TIMEOUT), at which point it is considered as FAILED

FAILED
The node has been in DEGRADED state for too long, and has been flagged as FAILED. A node will remaine in the FAILED state for a short time, and it will eventually be removed from the cluster. If the node comes back online, it will not re-join the cluster automatically.

JOINING
The node is in the process of joining the cluster.

LEAVING
The node left the cluster. It will stay in that state for short time period and then it will be removed from the cluster.

You can dynamically add or remove a node from a cluster using the grbcluster join or grbcluster leave commands. The join command can be useful when you want a node to rejoin the cluster after a network issue without having to restart the node. For example, if server2 left the cluster after a failure, it could rejoin using the following command:

> grbcluster --server=server2 --password=cluster join server1

Try Gurobi for Free

Choose the evaluation license that fits you best, and start working with our Expert Team for technical guidance and support.

Evaluation License
Get a free, full-featured license of the Gurobi Optimizer to experience the performance, support, benchmarking and tuning services we provide as part of our product offering.
Academic License
Gurobi supports the teaching and use of optimization within academic institutions. We offer free, full-featured copies of Gurobi for use in class, and for research.
Cloud Trial

Request free trial hours, so you can see how quickly and easily a model can be solved on the cloud.

Search