NATS Multiple Server Setup
This article explains how to setup NATS across multiple servers. The are a number of solutions you can implement to use multiple servers/databases to improve performance and distribute the work load.
Database Server(s)
NATS supports the ability of querying a secondary "slave" database when running any non-essential reports. A slave database is essentially an exact copy of your actual NATS database that is typically used by NATS for larger, time-intensive queries. You can have as many slave databases attached to your master NATS database as you want at no extra charge. Using a slave database will greatly improve performance on both your join pages and on your reporting pages, as they will not be fighting for the same database resources when they are both running at the same time.
To use a slave database in NATS, your host must first create the slave database in MySQL and set up replication between the two. Replication is how the master and slave databases keep data up-to-date between each other. MySQL's official documentation on replication can be found here.
Note: NATS Technical Support cannot and will not create slave databases or setup replication as this is something that is set up outside of the NATS system
Once replication is set up by your host, the next step is to tell NATS how to connect to the primary slave database. Before you start this next step, you need to get the following information from your host:
- The hostname/address of the slave database
- The username for the slave database
- The password for the slave database
- The name of the slave database
Then in your includes/config.php file, add the following lines:
$config['DB_STATS_SERVER'] = 'localhost'; //replace localhost with address/hostname of where slave database lives $config['DB_STATS_USER'] = 'access'; //replace access with the username for slave database $config['DB_STATS_PASSWORD'] = 'my_password'; //replace my_password with the password for slave database $config['DB_STATS_DB'] = 'db_name'; //replace db_name with the name of the slave database
THE FOLLOWING STEP ONLY APPLIES TO USERS OF NATS V4
THE FOLLOWING STEP IS OPTIONAL
If you have multiple slave databases replicating from your master NATS database, you can have NATS automatically choose one of your slave databases at random when a user hits a page/script that uses the slave database(s). You can add an array of slave databases to your includes/config.php file in the following manner:
$config['DB_REPORTING_SERVERS'] = Array( "0" => Array( 'SERVER' => 'localhost', //replace localhost with address of where first slave database lives 'USER' => 'access1', //replace access1 with the username for the first slave database 'PASSWORD' => 'password1', //replace password1 with the password for first slave database 'DB' => 'slave_name1' //replace slave_name1 with the name of the first slave database ), "1" => Array( 'SERVER' => 'localhost', //replace localhost with address of where second slave database lives 'USER' => 'access2', //replace access2 with the username for the second slave database 'PASSWORD' => 'password2', //replace password2 with the password for second slave database 'DB' => 'slave_name2' //replace slave_name2 with the name of the second slave database ) //continue in this manner for as many slave databases you wish to configure );
Load Balancing Web Files
It is possible to run your NATS install across multiple servers, however, you will need to purchase an extra license for each additional server.
There are many possible ways to set this up, here is an example:
SERVER1 Main install of NATS. SERVER2 Replicated version of NATS.
- The nats/templates_c and nats/logs directory should not be replicated from SERVER1 to SERVER2. Everything else in the nats/ directory should be replicated from SERVER1 to SERVER2.
- If possible, have nats/logs on SERVER2 replicated to some location on SERVER1 (like nats/logs2). This makes it easier for us to debug any issues that may arise, without needing you to copy files for us every time. In this example, 'logs2' would be another directory that shouldn't be replicated back over to SERVER2.
- NATS has a feature called 'db_session' which can be enabled in the NATS configuration admin which will have NATS store session information in the database. This way we can identify the surfer even if they switch servers for some reason. It is also possible that your load balancing appliance can manage sessions across servers.
- NATS now also offers the PHP function Memcached, which has NATS store session information in the server's memory (RAM), as opposed to the database. This provides a faster way to retrieve a surfer's session information, even if they switch servers. For more information, please see our Using Memcached For Caching article.
Note: You must be on NATS version 4.0.77.1 or higher to enable this feature.
- In this setup, both installs of NATS are connecting to the same MySql database. The slave database(a replication of the master database) is used by NATS to handle some reporting and otherwise intensive lookups that may put some strain on the database, leaving the master free to handle inserts.
- It is important that there is some way to force the main server, so the admins can always get the master (and not the replicated server) to perform adminstrative functions. Usually a special domain is set aside for just admins.
- It is important that the NAts cron is set up on the master server, and only the master server.
- When we are requesting access, we will need access to the master and not one of the replicated servers.
This method can be expanded by adding SERVER3, SERVER 4 etc, and setting them up just like SERVER2.
Additional Notes
The following notes can help your load balanced setup to run as smoothly as possible:
- Make sure there is a sync in place to automatically push changes from the master to all other servers.
- Exclude the logs and templates_c directories from the sync.
- Make sure there is a way to manually trigger the sync, for when you need to make changes.
- Make sure there is one non-load balanced subdomain (for example, admin.sitename.com) that you can use.
- Have subdirectories in the logs folder on the master for each other server you have set up, and have the logs from those servers copied over automatically.
After moving your servers to a load balanced setup, you may need to update your config.php file to allow your new IP in order to correctly receive the traffic directed from your load balanced servers.
Note: You must be on NATS version 4.0.74.1 or higher to enable this feature.
To do so, add the following code to the nats/config.php file on all of the servers you are using for your load balancing setup:
$config['USE_LB_HEADER'] = 'HTTP_X_CLUSTER_CLIENT_IP'; // The key in the PHP $_SERVER array whose value is the requesting IP
$config['LB_ALLOWED_IPS'] = Array(
"0" => "123.123.123.12"
);
Replace "123.123.123.12" in the above example with the IP for your new server. HTTP_X_CLUSTER_CLIENT_IP is the value that is being sent from your load balancer. If your load balancer configuration changes for any reason, you must update this value so that NATS will know what to look for.
For AWS Load Balancing, we recommend upgrading to NATS version 4.1.19.1 or above. These version support specifying a CIDR address (ex. 10.0.2.0/24) in the LB_ALLOWED_IPS setting. When using AWS load balancers, the ip address of the load balancer can fluctuate between any ip address in your VPC range. So you will need to set LB_ALLOWED_IPS to the CIDR address range of your vpc or specify every individual address.
