Recommended Scaling Practices
From 1 to 2 Virtual Servers:
Round-Robin DNS, Database Replication, and Dynamic Asset Storage
With one VPS you typically have your software load balancer, application server(s), and database server on the same filesystem sharing the same resources (see diagram on the right, highlighted yellow boxes). In this scenario, uploaded assets like photos are stored in one directory and because all application servers read from this one directory there is no problem. But, if the VPS fails for some reason your entire application is down.
Therefore, in order to prevent the failure of one VPS from taking down your entire operation and to share (balance) resource loads, it is possible to move from one VPS to two via Round-Robin DNS, Database Replication, and centralized dynamic asset storage.
1) Database Replication - MySQL Master/Slave Setup
After your second VPS is up and running with essentially the same software/files/etc.. on it you'll want to setup a MySQL Master/Slave scenario where the slave will read the byte-level log of the master and replicate the data securely across the private network within miliseconds.
On the Master create a file called /etc/my.cnf and in it put the following:
[mysqld]
log-bin=master-bin
binlog-ignore-db=mysql
binlog-ignore-db=test
sync_binlog=1
server-id=1
and on Slave create a file called /etc/my.cnf and in it put the following:
[mysqld]
server-id=2
log-bin=master-bin
On Master jump into a MySQL shell session and:
mysql> grant replication slave on *.* to 'replication'@'' identified by 'some_password';
and on Master do a
mysql> SHOW MASTER STATUS;
should be something like
+-------------------+----------+--------------+-----------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+-----------------------+
| master-bin.000001 | 98 | | mysql,test,mysql,test |
+-------------------+----------+--------------+-----------------------+
1 row in set (0.00 sec)
With this info jump on to Slave and:
mysql>
CHANGE MASTER TO
MASTER_HOST='
Make sure that the MASTER_LOG_POS matches what was in the output on Master for the SHOW MASTER STATUS command.
After restarting MySQL on both Master and Slave, enter the following on Slave:
mysql> start slave;
mysql> show slave status \G;
From here the slave status should show no errors and indicate it is waiting for the Master to send it some data.
IF THE SLAVE GETS STUCK!! you'll want to enter (and possibly repeat multiple times) on Slave:
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
start slave sql_thread;
show slave status \G;
Make sure to modify your application for reads/writes accordingly!!
Most frameworks have plugins available to ensure that all write requests go only to
the Master. Make sure you include this in your application's code and test it
to ensure it works correctly.
2) Round-Robin DNS
Round-Robin DNS is a relatively simple technique of providing multiple A records for your domain so that load will be distributed at the DNS level as routers around the Net match domains to IP addresses. This will send traffic to both of your VPS servers but should not be relied upon for fail-over. In the event one VPS goes down you can have your live VPS catch both IPs until the broken one is back up. Contact support for more details.
3) Dynamic Asset Storage
With multiple application servers, if dynamic assets (photos, documents, etc...) are uploaded directly to the filesystem they will not be accessible by other application servers. While the poor-man's hack to to solve this problem is to run regular rsync crons, the more acceptable practice is to use an internally mounted Storage Area Network (SAN) or a third-party storage system like Amazon S3. At Framework Cloud, we highly recommend using S3, as most application frameworks have easy drop-in plugin configuration so that uploaded files go directly to S3 and are served from there accordingly.
Scaling Beyond 2 Virtual Servers:
Software Load Balancing & Further Database Replication
Typically scaling beyond two Virtual Servers involves separating application and database servers, adding more MySQL slaves, using Memcached, and putting a few software Load Balancers in place with Round-Robin DNS and at least one Balancer ready to go as a fail-over option should one of the others go down. We recommend Nginx as the load balancer of choice, which is very lightweight, stable, and easily configurable.
With dynamic asset storage already in place, scaling out application servers is relatively simple, and the key is to measure peak throughput (max traffic) levels of both transactions per second and the average duration per transaction to determine break points so you know when to scale. These values are application specific and need to be tested and re-tested to ensure high-availability is maintained.
Example scaling diagram of a web hosting cloud