This section describes best practices for the following subjects:
This page is a list of Best Practices for when setting up and installing the ClustrixDB software. See Getting Started on ClustrixDB Software to complete the initial installation and general configuration instructions.
When setting up a new cluster it is best to maintain consistent ordering and numbering with IP address, hostnames, and node numbers.
Currently to achieve this, you have to add nodes one at a time to the cluster using the Cluster Management page on the Clustrix Insight webui, otherwise the node number is random as the numbers are assigned in the order that the nodes respond to the addition request.
This is only relevant for on-premises installations, as you don't typically have that much control over IP address allocation in cloud/hosted environments.
While ClustrixDB runs fine on nodes with a single network connection, the recommended network topology is a setup with at least two ethernet connections; the front-end and back-end. The front-end ethernet is for external traffic to communicate with the cluster while the back-end ethernet should be used for internode communication only.
For more information on setting up the network please see Network Security with ClustrixDB.
When adding nodes to a cluster in a cloud environment such as AWS or Rackspace it is important to use the internal IP address as using the external address can cause cluster creation to fail.
The 3 main approaches to security are as follows:
There are 9 ports that are used for communication between ClustrixDB nodes and must be open to allow proper cluster operation. With the exception of 22 and 80, these ports should be restricted so they are only accessible by the other nodes in the cluster.
There are 4 TCP network ports that are used to access your ClustrixDB from your database application and for day-to-day administration:
In a typical secure configuration, you will limit access to TCP Ports 80 and 22 to the network CIDR range that maps to the public IPs for your administrative clients (typically exposed through your firewall), and you will limit access to TCP Port 3306 to your administrative client CIDR range and also to the range of IPs used by your application servers (if they are outside your firewall).
For complete details on how to set up security please see Network Security with ClustrixDB.
ClustrixDB has been designed to take full advantage of a front-end load balancer. We recommend HAProxy if you are using ClustrixDB software and the Amazon Elastic Load Balancer if you are running in AWS. For more detailed information on setting up HAProxy or the AWS ELB please see the following links:
NTP should be running so that the nodes' clocks don't get out of sync; otherwise, you may get inconsistent timestamps when using now() , and this also makes log analysis much more difficult. See Setting Up NTP for ClustrixDB on CentOS.
There are three methods of internode SSH access, listed here in order of administrative simplicity:
If you use password-based authentication then the CLX Command Line Tool will require a password for most commands.
For ease of use, we suggest having the same password for each node.
Databases are not typically network-bound (as compared to a file server), however, a clustered database system does rely upon low latency links between nodes.
To learn more about how network latency can affect nodes in a cluster please see Recognizing Platform Limits.
Below are some general best practices on RAID configuration for ClustrixDB:
For more information about the various RAID level please see Wikipedia: RAID.
For optimal performance use the ext4 format for your filesystem.
ClustrixDB will work when using an ext3 formatted volume, but it will generate warnings during startup and space allocation. Growing the device file will also take longer than with other volume formats. However, the performance hit from this should be minimal as ClustrixDB proactively grows the device file.
You can see which format your filesystem is with the following:
In the above example, we have most of the partitions running ext3 and the main /data partition running ext4.
Below are the general operating system best practices and concerns for running the ClustrixDB software.
Do not configure swap. Having the database process going to swap, even on SSD, will degrade performance.