I have an application that is almost arbitrarily divisible (but not auto-scaling).

For a fixed price, is there any benefit to going with a big linode instead of an equivalent amount of small linodes?

I think spreading out the impact of server failure on customers is a plus, but focusing on hardware; the ram, disk storage, cpu priority and transfer allowance all seem to scale equally. Would going with multiple small linodes give an advantage in disk IO priority?

Going multiple linodes does mean you incur the OS overhead multiple times though. You also get another IP address this way.

Any thoughts?

Multiple points of failures, never a good idea unless absolutely necessary.

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

As long as there isn't a single point of failure, it's a great idea.

_________________

/* TODO: need to add signature to posts */

That's not true.

With a single system - there's a x% chance of failure.

With a two systems - where both systems must be working in order for a success (i.e. a web server and a db server) - there's a 2 times x% chance of failure.

So unless you're talking about redundant systems (i.e. failover or clusters), having more then a single box increases your chance of downtime.

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

Then you have 2 single points of failure (SPOF), and so hoopycat's comment doesn't apply.


Not quite:

P(A or B) = P(A) + P(B) - P(A and B) = P(A)+P(B)-P(A)P(B) if A and B are independent events, so (2x-x^2)%

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

Unless you feel that you may in reality want to scale to have many application servers or DB servers in the future, one linode would be the simplest. However if you can see yourself increasing traffic over time, it can be good to split out servers and load balance between them.

_________________
Linode 512 @ cbr250.com

I'm quite lucky with my application: users don't interact, and have their own DNS records - so i can split up the application as much as i like with no servers depending on any other, and even minimal customer impact.

So with multiple servers, every customer would still experience the same chance of downtime - but if a server hiccups then it only affects a fraction of the customers.

RAM and disk IO are my limiting factors, so i might take the latest NextGen upgrade to double the ram of my linodes, then downgrade them to half size, then double the number of servers while staying in the same price envelope... ending up with basically the same specs, the same number of cpu core shares, and a more diversified chance of burst resource availability

But really, what would i have gained? The same hardware specs, and another server that might wake me up in the middle of the night. So i don't know if i should go with a few big linodes, or many small ones.

IMO one of the biggest appeals of virtualization is that you can split up your infra at cost; you no longer need to have one server that runs -everything-

It's definitely a lot easier to manage a bunch of servers that have specific jobs as opposed to a full stack on a single machine.

_________________
me | voltaireMC

You can scale more efficiently with a multiple server setup. It's easier to monitor where your choke points are (say, DB, App or Cache server) and then target your hardware budget accordingly. For me it's a commercial decision as much as a technical decision.

If RAM is your limiting factor you should go with fewer and bigger Linodes to avoid the (small) multiple OS overhead.

If Disk IO is your limiting factor you should go with a large number of small Linodes as disk IO capacity on the low end and high end servers is essentially the same.


The answer depends on what this application does and how it does it.

Of course, failover or clusters bring there own complexities.

I think a key factor is what you believe the future will hold. If scaling up a single instance has a high likelihood of meeting your availability, performance and growth needs for the foreseeable future then I'd stick with that.

Yes, splitting your customers between two independent servers means that a failure will only hit half of your customer base, but you'll still have a problem that needs attending to. Moreover, you'll have ~2x as many problems so your cumulative downtime measured in customer-hours will be the same over time in exchange for more admin work.

If you think that bumping up the instance size is going to be insufficient in the foreseeable future then going with two smaller instances would be a good step towards gaining practical experience with running your application on a resilient and scalable multi-instance architecture.