This is the first of several articles concerning our system architecture. It’s primarily aimed at technically minded ladies and dudes. But don’t feel left out if computers frighten you! It’s okay to learn, sometimes.
And today, we’re talking about servers!
First, a little back story: We were originally hosted on GoDaddy servers running Asp.Net. This was fine, there wasn’t anything wrong with it. Performance was fine and GoDaddy treated us okay. But I felt that the software solution wasn’t exactly what we needed: We needed better administration and templating features, and – more importantly – something that would let us scale. So I researched, found WordPress and ComicPress (and half a dozen other bits of software that I’ll discuss later) and moved us over to a Linux hosting environment at GoDaddy.
Performance with the Linux plan was abysmal. My suspicion is that there were simply too many sites hosted on our one tiny shared server. We had to move. But where?
Our servers are now running “in the cloud.” If you’re not familiar with the cloud, take a minute to Google it. It’s pretty neat. There are numerous companies providing cloud-like hosting, such as Amazon’s EC2 and Flexiscale. These guys generally bill on a per-CPU- or per-RAM-usage-per-instance-hour. This wasn’t exactly what we needed, so we took a sort of middle of the road approach and found a solution that let use bring up and tear down instances billed on a monthly basis. In our case, setup was painless and our first instance was available for use in less than five minutes. About a week later and working in my spare time, I had everything setup, switched our nameservers to point to our new cloud and crossed my fingers.
It mostly worked like a charm. A few kinks here and there and a few more Apache restarts than I’d like, but what can you do?
So now we’re in the cloud. Through a fancy-pants administration screen provided by our fabulous hosts over at Slicehost, we can now add, copy and delete instances of our servers to scale with demand. This scaling is furnished by the open source Xen virtualization backend.
As of this posting, we run two virtualized servers running Ubuntu 8.10 Intrepid Ibex: A web server (running Apache httpd 2.2.10 and PHP 5.2.6) and a database server (running MySql 5.0.67). Both servers are memcached servers allocated to 64 MB each. As of today, we use only 0.02% of that space!
Eventually, we plan on launching a third server to act as a slave to the web server using IP failover and heartbeat. When we scale beyond that, we’ll have two web servers running behind an nginx proxy, with two MySql servers running in a master/slave configuration.
And right now you’re probably wondering why our little site requires such a configuration: Here’s a secret, it doesn’t. We use almost none of the resources available to us because we’re so small. But we have plans in the works and we’re going to need a way to scale, so we wanted to be ready.
It’s quite sophisticated, really, for something that – strangely enough – amounts to nothing more than a hobby.
In the next article I’ll talk about our web server, how we cache and why I think pretzels are so awesome.
What do you think of our configuration? Do you use memcached? Did you see a movie this weekend? How was it?
Pings & Trackbacks ¬