Comments on: Virtual Eggs and Baskets

By: Scott Alan Miller

Scott Alan Miller — Wed, 28 Nov 2012 16:53:25 +0000

Then in that case you simply extrapolate the discussion appropriately. In the example we collapsed ten single points of failure into one single point of failure. In your example (two sites with clustered resources) let’s assume we still have ten systems, five at each site, with each being a cluster (most SMBs do not have an infrastructure like this but it is entirely possible – this could also be same-site clustering) then you are not looking at ten single points of failure but five clustered points of failure. We would then collapse those five into a single clustered point of failure. Of course this requires two pieces of resultant hardware rather than one, but the consolidation providing improved reliability remains. Collapsing multiple points of fragility into a single point of equal or lesser fragility results in lower cost and lower overall risk.

By: concernedcitizen

concernedcitizen — Wed, 28 Nov 2012 14:18:13 +0000

Is the discussion framed to be only about hardware failures on the server(s) themselves? What happens when you have infrastructure or network failures? Let’s say ABC Corp has 2 geographic locations, each location has domain controllers and file servers with DFSR.

If there’s a major network outage in Site A, Site B is still running because they have their own on-premise servers. And if there’s a natural disaster in Site B (flood, hurricane, etc) then Site A doesn’t suffer because again, they had their own servers.

By: Scott Alan Miller

Scott Alan Miller — Wed, 28 Nov 2012 05:59:37 +0000

Yes, that is exactly what I mean. Taking ten single points of failure and reducing to one single point of failure. Assuming that the ten boxes are not clustered but individual systems. Nearly all SMBs have traditionally run this way with each system being a single point of failure.

Given that situation, reducing all ten to one is a no brainer. Saves a fortune in cost and makes the overall system far less risky. Having tens systems, any one of which is just as likely to fail as the others, is incredibly risky compared to having just one for a normal spread of workloads.

It depends on how the systems are used, but any amount of system interdependence means that integration and consolidation is hugely beneficial. If you are going to have outages of systems, you want them to overlap as much as possible rather than being spread out. It’s about reducing the impact of the outage.

Some businesses can run well with, for example, email down. But more often than not, having email, AD or ERP systems offline means that the overall impact is far greater than the loss of 10% of the computing infrastructure would suggest.

By: concernedcitizen

concernedcitizen — Wed, 28 Nov 2012 02:43:05 +0000

I’ve read through this post a few times, and I am wondering if I’m missing an important part of your “10 servers to 1” scenario. In this example, are you assuming that these are the *only* 10 physical servers that exist, and then consolidating them down so there’s just 1 for the whole organization? Surely that can’t be the case.