This section describes best practices for the following subjects:
This page is a list of Best Practices for when setting up and installing ClustrixDB. See ClustrixDB Installation Guide Bare OS Instructions 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.
For example:
Currently, to achieve this, you have to add nodes one at a time to the cluster using either ALTER CLUSTER Syntax - Flex Up or the Flex Up page on the ClustrixGUI. 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:
These network ports are required for communication between ClustrixDB nodes. They must each be accessible by other nodes within the cluster.
Protocol | Port | Use | Reason |
---|---|---|---|
TCP | 22 | SSH | Administration and upgrade |
TCP, UDP | 2048 | Control Port | ClustrixDB specialized administrative tool |
TCP, UDP | 2424 | Nanny Port | nanny - ClustrixDB process manager |
TCP | 3306 | SQL | Database communication |
TCP | 7888 | clxdbi | Database interface for ClustrixGUI |
TCP, UDP | 24378 - 24410 | Multiport | ClustrixDB internode communication |
These network ports are used to access ClustrixDB externally from your applications and for cluster administration.
Protocol | Port | Use | Reason |
---|---|---|---|
TCP | 22 | SSH | Remote management and cluster access |
TCP | 8080* | HTTP | ClustrixGUI |
TCP | 3306 | SQL | Database access |
TCP | 3581 | Health Check | Heartbeat monitor for cluster |
*For root installation, ClustrixGUI uses port 80.
In a typical secure configuration, you will limit access to TCP Ports 80, 8080, 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. Please see Load Balancing ClustrixDB with HAProxy for details.
NTP should be running so that the nodes' clocks do not get out of sync; otherwise, you may get inconsistent timestamps when using now() , and this also makes log analysis much more difficult. See Verify NTP is running on ClustrixDB.
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 an ext3 device file will take longer than with other volume formats.
You can see which format your filesystem is with the following:
shell> # df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/md1 ext3 14446128 2253276 11459028 17% /
tmpfs tmpfs 16440012 131076 16308936 1% /dev/shm
/dev/md0 ext3 253807 27521 213182 12% /boot
/dev/md3 ext4 1060589952 993662712 13052376 99% /data/clustrix
/dev/sdh1 ext3 484535504 9458888 450657416 3% /data/clustrix/log |
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 go to swap, even on SSD, will degrade performance.