2

Yesterday, Rackspace DFW data center went down for a few hours and made me think on taking the delayed action of improving my server structure there. So far, I've been using a single CentOS instance handling a basic LAMP setup for my PHP+MySQL application. So yesterday my application was down for more than three hours in an row and that was awful.

I thought on:

  • Having at least two instances handling the application split across at least two data centers (Rackspace or not).
  • Having at least two MySQL master/slave configured instances to host the data, splitted across at least two data centers.
  • Placing a load balancer in front of the application instances to avoid dealing with DNS propagation and being able to add or remove application instances painless at my will.

So my questions are:

  • How does the above three measures sound? What else can be done?
  • What's the best way of implementing them with no downtime?
  • How to handle code deployments
  • Any books/whitepapers/etc you can recommend to help me here?
  • Bonus: How to do it? :P
Improve this question
2
  • You are trying to boil the ocean. Each one of availability, performance and scalability requires separate, in-depth investigation and an intimate knowledge of your application/environment. You're kind of cavalier about having MySQL replicating across data centers in particular. That is a hard problem to solve and not inexpensive. There are solutions for it like Percona's XtraDB Cluster (Galera) and Continuent's Tungsten Cluster but each requires a substantial investment in time and money. There are solutions but be realistic, you're not going to change this overnight and it's going to cost $$.
    – HTTP500
    Dec 5, 2012 at 18:10
  • @HTTP500 Haha, yeah, I know I've posted a hundred questions in one and it's not that easy. The quick question is what is the better next step I can take to avoid downtime as much as possible. I'll actually edit it to focus it a bit.
    – Mauro
    Dec 5, 2012 at 18:16

1 Answer 1

Reset to default
4

Bottom line

@HTTP500 is right: Scalability is a non-trivial task. Even if everything is based on infrastructure tools like EC2 LoadBalancer & co, you still need a small team of experts to operate it.

High availability for LAMP web-hosting

Let's assume you want to make sure that your can scale X number of website impressions very quickly. However in order to help you, one does need more information about your application. I will still recommend to check out solutions as proposed by teams like Amazee, fortrabbit, etc.

To give you some ideas for "Getting started" here is a diagram (courtesy of Amazee):

LAMP HA scheme

Scheme nicely illustrates how HTTP request gets served (starting from load-balancer). Such solution would need a lot of good planning, that will help you to decide whether or not you actually still going to do it.

To achieve a primitive ping-pong and respawn - you will need a heart-beat failover. I would recommend to try http://www.keepalived.org/. For your LAMP you can have following classes of VM instances:

  • A load-balancer (just as on the diagramm - I recommend ngnix, writen by a russian smart-ass)
  • Apache (PHP application web-server)
  • Memcache or other type of cache servers (Here your application can be smarter if it is aware of memcache )
  • NFS-like file system but not NFS! GlusterFS is a good candidate.
  • Mysql slave-master DB cluster

As you see you will have to automate the monitoring, i.e. do something like a keepalive-based scripting that goes around and makes sure that everything is alive. That script can check a millisecond "availability score" for each instance.

PS

Continue with the slides http://www.slideshare.net/AmazeeAG/php-high-availability-high-performance Hopefully that will give you greater insight into how to implement what you are up to.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .