This section describes what a Rhino pool requires for the Cassandra external database and the management database.
Cassandra external database
The Cassandra external database stores the status and network contact points for each node in the pool. The database must be reliable as the Rhino pool maintenance subsystem depends on it. Rhino is configured to require a Cassandra cluster to have a minimum number of Cassandra nodes. This requirement is influenced by several configurable attributes of a Cassandra deployment:
-
the replication strategy and replication factor; and
-
the data consistency level.
Replication
The replication parameters of the pool maintenance database keyspace are set in the keyspaceReplication parameter of the pool-maintenance configuration in node-xxx/config/rhino-config.xml.
The default settings use the SimpleStrategy with a replication factor of 3.
This strategy uses only one Cassandra datacentre and one rack, and replicates stored data across three database nodes.
For production deployments, the NetworkTopologyStrategy may be more appropriate.
This strategy allows Cassandra clusters to be deployed across multiple datacentres and allows for easier expansion.
Further information about how these replication parameters are used by Cassandra is provided by the Data Replication section of the Cassandra documentation.
Consistency level
Each Rhino node in the pool requires that the database can read or write data at a configured consistency level. This level is the minimum number of Cassandra nodes that must acknowledge a read or write operation before the operation is considered successful.
The consistency level is specified in the basic.request.consistency configuration property for Cassandra persistence instances in the node-xxx/config/persistence.xml.
The default consistency level is LOCAL_QUORUM.
Further information about consistency levels can be found in the How is the consistency level configured? section of the Cassandra documentation.
Management database
As each node in the pool is independently managed, each node requires its own management database. In a typical deployment, with one Rhino node per host, each host will run a management database server alongside the Rhino node. In an alternative arrangement, a single management database server cluster may provide separate database instances for each pool cluster member over the network.
By default, Rhino is configured to use PostgreSQL for the management database server.
