It’s that time of your company or personal project where you find yourself staring at your slow website and thinking “why didn’t I do something to prevent this?”. If you paid attention, you’ve probably scaled your virtual server vertically and gained a few extra connections to your site. But even that might not be enough in the long run.
We need another way to ensure we can continue to grow without incurring into heavy costs or idle processing power.
If this is you, then this post might be enlightening. If you are not currently in this pickle, well, read on since this is a must-have know-how.
Back to the drawing board
With vertical scaling, you increase server capacity in order to support more users or processing at the same time. With City Cloud, as with any IaaS platform, this is straight-forward. The drawback of vertical scaling is that costs increase greatly and sometimes your performance might not be as sustained to justify spending more money.
Horizontal on the other hand, is the process of adding more servers and distributing the load between them. Naturally this also comes with increased costs but the main difference is that resources are more efficiently handled in the long term. Also, the upper limit on horizontal scaling is usually larger than vertical scaling. In the real world, we tend to use a combination of vertically increasing processing power and then adding more servers when we are being hit hard in terms of traffic; and then shrinking back to a nominal state.
The key here is cloud computing. Having to exchange hardware parts to increase capacity or adding servers to a rack is certainly possible and still a practice for many companies, but with cloud computing we enable that ability to smaller players that otherwise couldn’t afford more hardware. However, nowadays both small and large enterprises use this approach.
Let’s cut to the chase.
In order to show you the benefits of this approach, we’ll try to keep it simple. We will take a single server with a WordPress installation, separate the database server into another one (Part 1), implement a simple load balancing scheme (Part 2) and then simulate traffic and problems (Part 3).
In this first part, we’ll have a database server, webserver and a WordPress installation all setup into one virtual machine and then we’ll create a new server, move the database and connect everything together through an internal network.
WordPress is a great guinea pig since it’s widely used, involves several processes that we find in many websites and at the same time is easy to setup and test.
Let’s start, shall we?
Great then. We are assuming you have an account with us, no? Go here first then. The rest of you, follow me.
Log into City Cloud control panel and create a new virtual machine using the the image named “Debian 6.0.2 64-bit – WordPress (Nginx)” in our App Center (make sure you select “Small” for the server profile, since we are doing a simple test, we don’t need more processing power than that). Give it a few minutes until the server is ready and then finish the installation. Using a dummy domain (or a real one, your choice), this should be the end result in your browser:
Now, let’s go back and create a new server. This time, based on the image named “Debian 126.96.36.199 64-bit” which contains only the operating system. Get into the box and install MySQL server with:
# Let's make sure we have the listing up-to-date apt-get update # Now we use apt to install the MySQL server apt-get -y install mysql-server
After a few seconds you will have a barebones MySQL server installation, don’t forget to select a strong root password. Now let’s connect both servers internally. If you already know what to do, you are probably contacting us already, otherwise you should read this handy guide.
Once you have added a second virtual network card to both servers, you should go ahead and setup an internal IP address space (like 192.168.x.x). Make sure both servers can ping each other before proceeding. Troubleshooting in this situation generally involves ensuring both NICs are up and both of them have the correct IP address.
Divide and conquer
Now, we have to get into the first server and dump the database to a file. You can use SSH or VNC, the choice is up to you. Once inside, we need to stop the webserver to avoid any further accesses (not really necessary but it would be the right thing to do).
# Switch to root first /etc/init.d/nginx stop
Later we proceed to export the database. With the following command (check your database name and replace when necessary):
mysqldump -u root -p databasename > databasename_dump.sql Password: [insert your root mysql password here]
This should be fairly quick, once you get the file, copy it to the other server:
scp databasename_dump.sql adminuser@[internal_ip_of_the_new_db_server]:/home/adminuser
Once inside the other server, we can create a new database and import it:
# First, connect to MySQL mysql -u root -p # Then, we create the database mysql> create database wordpress; # Afterwards, we assign a user to it mysql> grant all privileges on wordpress.* to 'username_here'@'192.168.1.1' identified by 'password_here'; # Let's make sure privileges are reloaded mysql> flush privileges; # We switch to the database and import the dump into it mysql> use wordpress; mysql> . databasename_dump.sql
Last but not least, we have to give access to the webserver. Since we added an internal network, this will gives us some basic security. Edit the MySQL server config file (usually /etc/my.cnf on Debian) and change the following line:
bind-address = 127.0.0.1
bind-address = [your_internal_database_server_ip]
Hang in there, we are almost done. Now we just need to tell WordPress where the new server is located. Get back to the webserver and edit the following file: [wordpress config file path], with the correct host (internal ip of the new database server), user, password and database name.
Turn the webserver back on with:
# Again, as root. /etc/init.d/nginx start
And that should be all. If you go to your browser and load the address, you should see WordPress as it was before. To confirm the server is using this new distributed setup, you can go and remove the MySQL database from the webserver, everything should still be running as usual.
Other forms of horizontal scaling
What we have covered here aims mostly at sites that have saturated webservers. This is just the tip of the iceberg, depending on your site, the bottleneck could be on other locations. For instance, you could have a fast webserver but the database is getting the entire system stuck. In that case, there are also horizontal scaling schemes for that but the complexity increases since you have to take into account other issues, such as replication, fail-over and other challenges.
Or you could have a custom made system, where it doesn’t matter how many servers you throw at it, if the code doesn’t take advantage of the situation it won’t make a difference. And we can make it really overwhelming if we wanted to, what if you want geography redundancy and need to scale beyond a single datacenter?
Either case, scaling in practical terms goes beyond what we have exposed here, so as a rule of thumb, never underestimate the time and investment needed to have a proper redundant system.
The immediate benefit of this are performance. You no longer have a webserver fighting with the database for precious resources. The other instant benefit is security, your database is now isolated into a separated server that can have increased restrictions (in that case, don’t forget to turn off the default network card that has a public IP address associated with it). Of course this is not the ideal case but a step in the right direction.
We hope this guide has given you some ideas to experiment with. Are you not satisfied? Don’t you worry, in our next part we will show you how to setup a simple load balancing scheme furthering expanding your operating capacity.