Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Up until now, I've always set up my projects on a single (cloud or vps) instance. Always the same routine: Install LAMP, have it make mysql dumps for backups, secure the ssh, let it run for years without much maintenance.

These are all small projects, never had any issues.

The projects are now becomming bigger and I just now I had a hardware failure at Rackspace. 4 hours of downtime, client left waiting. etc.

So, here's my question: What do I need to learn about to get the next "level"?

Should I start splitting stuff up: a seperate DB server, a separate webserver etc. Should I be learning about quickly deploying a new cloud instance in case of downtime? Should I be ... something I haven't thought of yet... ?

share|improve this question

closed as too broad by Jenny D, ThatGraemeGuy, Nathan C, Falcon Momot, Dave M Jul 8 '13 at 13:55

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Best thing to do? Get yourself a trial account for $cloudplatform and have a play. – tombull89 Jul 8 '13 at 9:00
possible duplicate of Can you help me with my capacity planning? – Jenny D Jul 8 '13 at 10:14

It depends on how mission critical your application is. It's possible for you to set up a HA (high availability) configuration where you double the size of your cluster (double the price) and have automatic failover in the event of any issues.

As for splitting servers up, that could be a good idea. For instance, you could have two load-balanced front-end nodes serving your webpages. If you notice any issues with one of your servers, you can take the failed node out of the load balancer whilst you examine the problem. In the mean time, all traffic will continue to be served by the remaining node.

share|improve this answer

You should plan for High availability (HA) and disaster recovery (DR) strategies.

  1. Build for server failure

Instances in the cloud — just as in a typical data center — are ephemeral. You need to be prepared for server failure. Building for server failure begins with designing stateless applications that are resilient through a server or service reboot or relaunch.

Set up auto-scaling so that your application can respond to dynamic traffic patterns based on a set of performance metrics. Set up database mirroring, master/slave configurations, and/or priming to ensure data integrity and minimum downtime. Use dynamic DNS and static IPs so that components of your application's infrastructure always have the right context.

 2. Build for zone failure

Sometimes more than just single servers fail — there are power failures, network outages, and lightning strikes. You need to make sure that your applications are prepared for zone failures. Zones (Amazon Web Services refers to them as "availability zones") are distinct locations that are engineered to be insulated from failures in other zones.

Spread the servers in each of your application tiers across at least two zones. Replicate data across zones.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.