Installing Rhino
Interactive Rhino install
The following parameters need to have values entered when installing Rhino interactively. See the Rhino Getting Started Guide’s page on unpacking and gathering information for more information.
| Parameter | Expected Value |
|---|---|
Clustering mode |
|
Cassandra contact points |
Comma-separated list of contact points (as host:port pairs) for your Cassandra database cluster. |
Cassandra datacentre |
The name of the local datacentre present at the specified contact points. |
In addition to above parameters, it is recommended to review the defaults for the following parameters:
| Parameter | Default Value | Guidance |
|---|---|---|
Database keyspace name for the pool maintenance subsystem |
|
Ensure that this keyspace is not used by anything else in the deployment. |
Rhino interconnect listen address |
|
It is highly recommended to select a specific network interface in production environments. For ease of use in replicating pool cluster nodes, the bind address can be specified as an address range, expressed in CIDR notation, where the relevant network interface can be found. This allows each node to determine the correct IP address to bind without any further manual configuration requirement. |
Rhino interconnect listen port range start |
|
The listen port range typically does not need to be changed unless a smaller range is desired for security reasons, or more than ten nodes are expected to be running on the same host. |
Rhino interconnect listen port range end |
|
Unattended Rhino install
The answer file used in an unattended installation of Rhino (using rhino-install.sh) should have values of the following config variables as specified.
See the Rhino Getting Started Guide’s page on installing unattended for more information.
| Config Variable | Expected Value |
|---|---|
|
|
|
Comma-separated list of contact points (as host:port pairs) for your Cassandra database cluster. |
|
The name of the local datacentre present at the specified contact points. |
|
|
|
The interfaces the node interconnect server should bind to. It is highly recommended to select a specific network interface in production environments. For ease of use in replicating pool cluster nodes, the bind address can be specified as an address range, expressed in CIDR notation, where the relevant network interface can be found. This allows each node to determine the correct IP address to bind without any further manual configuration requirement. |
|
The low end of the range of ports that the Rhino interconnect server will try to bind to. |
|
The high end of the range of ports that the Rhino interconnect server will try to bind to. |
Creating pool nodes
After installation, a pool node can be created by following the instructions in the create new nodes page.
Configuration of Cassandra for Rhino pools
After a pool node is created, Rhino’s Cassandra configuration and the Cassandra deployment have to be verified and provisioned respectively before pool mode can start working.
Verify Rhino’s Cassandra driver configuration
There are additional Cassandra configuration options that should be checked and updated if necessary.
These settings are configured in two separate configuration files: config/rhino-config.xml and config/persistence.xml.
|
The |
In rhino-config.xml, check the settings for the pool maintenance subsystem in the <pool-maintenance> element.
If the key/value store (<key-value-store> element) or session ownership store (<session-ownership-store> element) has also been enabled, these should also be checked as well.
The key/value store and session ownership store define the keyspace name with the keyspaceNamePrefix property.
The additional Cassandra configuration options depend on how Cassandra’s deployment topology is set up. See the page on requirements for databases in Rhino pools for more information on these options.
| Property | Reason to check |
|---|---|
|
By default, the property refers to the |
|
This specifies how keyspaces are replicated across the Cassandra cluster. Ensure that the replication strategy class and replication factors match with the Cassandra deployment’s topology. The Requirements for Databases page gives further information on this. |
|
These properties specify the maximum number of milliseconds that reads and writes to the database are expected to complete in. Smaller values may result in more frequent sporadic read/write failures, while larger values may result in longer application pauses when the database is under heavy load or otherwise unable to respond. |
In persistence.xml check the configuration parameters for the cassandra persistence instance.
These parameters configure the driver that Rhino uses to communicate with Cassandra.
Refer to the DataStax Java Driver reference configuration for more detail on the driver configuration options.
Setting up keyspaces and tables in Cassandra
A node in a Rhino pool stores the data that is required to maintain the pool in a Cassandra database. Administrators must manually create the necessary keyspaces and tables in the Cassandra database before the pool can function. Follow the instructions in the Initialise the Cassandra Database page to create the required keyspaces and tables from a Rhino node.
Generally, a Rhino cluster using the pool clustering mode will also make use of the key/value store and session ownership store for the replication and management of application state between cluster nodes. Support for these additional subsystems can be enabled during the installation process. Each of these subsystems require additional Cassandra-related configuration, such as a database keyspace name prefix used to determine the keyspaces that the subsystems will use for their own tables.
|
Ensure that any database keyspace names or prefixes specified for the Rhino install are available for exclusive use by the cluster. Unexpected problems can occur if different Rhino clusters access the same database keyspaces. |
Duplicating pool nodes
Duplicating pool nodes involves transferring an installation to another host and then updating some configuration.
Follow the instructions in the Transfer Installations page to transfer a pool installation to another host.
After transfer, the following variables in node-xxx/config/config_variables file should be updated to reflect the new host and node id.
| Variable | Reason to change |
|---|---|
|
New node may be installed in a different directory to where it was in the original node. |
|
JDK may be installed in a different directory to where it was in the original node. |
|
Every node in the pool needs to have a separate management database. |
|
Every node in the pool must have a unique node id. |
Deleting pool nodes
To delete all nodes of the pool, follow instructions in the Uninstallation page for each node in the pool.
To delete only a single node in the pool, follow all the instructions in the Rhino Uninstallation page except for the section titled Removing Cassandra database keyspaces. The Cassandra database is shared by all nodes in the pool and deleting keyspaces in it will make other nodes non-functional.
Viewing pool cluster state
The state of a Rhino pool can be monitored with the rhino-console command getpoolstate.
