Stretching your vBulletin Servers with OpenVZ

December 13, 2006 by · 3 Comments 

Most of the people reading this blog are familiar with the LAMP software bundle (Linux, Apache httpd, MySQL, and one of PHP/Perl/Python). The LAMP stack on a single server is common-place on the internet today because the components are all free and work well together to provide a stable, dynamic web platform (although, interestingly enough, they were not designed to do so). Who says that it's the best way to do things though? When working with complex applications such as vBulletin, there are definite benefits to keeping things separate.

For the past 6 months or so I've been consolidating my servers (both in the office and at remote data centers) using a virtualization package called OpenVZ (the open-source branch of SWSoft's Virtuozzo). Unlike virtualization packages such as VMWare (a system emulator) or Xen (a paravirtualization system), OpenVZ does not allow you to run multiple, different operating systems. OpenVZ will allow you to run Linux on Linux and nothing more. Moreover, it is heavily biased towards RPM-based distributions, so don't plan on getting wild. That said, if you can get past those limitations, OpenVZ might just help you get more out of your existing server because unlike the alternatives, OpenVZ's operating system-level virtualization technique has almost zero performance penalty.

Installing OpenVZ is pretty straight-forward. If you don't have a server up and running yet then have it deployed with a "minimal" install of RHEL or CentOS 4. If you are already up and running, once you're done, you'll probably want to remove all of the unneeded services (httpd, mysql, etc.) from the system as they'll all end up running in VEs. At this point you'll want to read through the official OpenVZ install guide so you can get started on migrating your existing services to virtual environments (VEs).

The general consensus on the vBulletin forums is that when you outgrow a dedicated server in the $300-400/month range that you should switch to a dual-server (one web, one db) or triple-server (one web & two db) setup. Unfortunately, most people who do this end up with performance problems because they can't afford to lease two $300-400/month servers and they certainly can't afford three of them. They end up with more web server than they need and a LOT less DB server than they need. On top of that, if you can't get a gigabit ethernet connection between the two servers (which many hosts don't offer), you really aren't getting all that you can out of your servers anyway.

Before I decided to make the switch to OpenVZ I had 2 independent servers at The Planet hosting about a dozen vBulletin sites between them, plus a couple content-based sites. The problem I was running onto was that if there was a problem with one site, or if I wanted to make a configuration change, every site on the server was interrupted. On top of that, performance issues (such as running out of httpd connections due to a DB table lock) from one site would break the rest, and httpd was sucking even more memory than usual due to the convoluted config files generated by Plesk.

My solution was to setup a server using OpenVZ and to stick each needed service into a separate VE. DNS runs in its own environment. Email runs by itself (even separated from the webmail). Both instances of MySQL run on their own (more on this later). I even went to the level of separating each web site into it's own VE so that virtual hosting would not be needed. While that does add a bit of overhead in the total number of running processes, there really aren't any more active processes at any given time and this separation of services allowed me greatly reduce the running complexity of the server. I never have to worry about a change to my mail VE affecting my DNS and I never have to worry about a change to my slave MySQL VE affecting one of my web VEs as each VE only deals with one thing.

With regards to MySQL, the real point of this post is that this is a wonderful opportunity for those of you with boards that have more than 2 or 3 million posts. As you have probably already noticed, if you have the full-text boolean search enabled, your server grinds to a halt when a few people search at the same time. The site becomes all but useless. By creating two MySQL VEs and configuring replication, you can use the built-in master/slave database configuration in vBulletin to send your searches and other read-only queries to the slave server. The searches don't get any faster, but the site keeps acting as if nothing is going on at all.

For those of you that have two servers already and are finding that it's not enough, try installing OpenVZ on your DB server and installing a second instance to use as a replication slave. I guarantee it will help the load.

That said, OpenVZ isn't a miracle worker. It's not going to allow you to run a board with 1000 online users on a $200/month box. However, it will help you get every bit of power out of the system that you have and for those of you with big boards, it can really save the day.

Digg this story


3 Responses to “Stretching your vBulletin Servers with OpenVZ”
  1. Jason says:

    I forgot to mention, but all of the PHP, httpd, and mysql tutorials I've written were built and tested in development VEs I've setup on my server. They have saved the day more than once when building a package has required removing the old one first or when the resulting package didn't work quite right the first time out...

    Even if you don't run vBulletin, it might be worth it for you to install OpenVZ just as a test environment.

  2. Kir Kolyshkin says:

    I'd like to point out that people are running OpenVZ on non-RPM distributions as well -- notably Gentoo and Debian. Those systems can also be used as a guests (i.e. inside a VE).

    The only thing that is "biased towards RPM" is vzpkg tools -- they can't currently manage debs, for example.

  3. Jason says:

    That's true, thanks for the clarification. In any case, from my experience, it is certainly easiest to get everything up and running with an RPM-based distro.

This site is no longer updated. If you have a need for RHEL/CentOS LAMP Stack updates outside the normal channels, I recommend ART.