I don’t blame anyone for being confused about the server hosting options that are out there. It makes picking a mobile phone billing plan or reading a constitutional amendment look easy. I thought I’d take a few minutes to explain what some of the options are in the market and compare them with the C Infinity private cloud.
A critical factor in setting up an outsourced implementation or a Software-as-a-Service (SaaS) solution is fault tolerance. Your customers, be they internal or external, expect the service that your provide, usually with a service level agreement (SLA), to be available when they need to use it. That means outages are not tolerable. Spend a few minutes using your favourite search engine and you’ll soon find out how customers and service providers react when there’s an outage. It isn’t pretty and that’s quite understandable. If I’m a subscriber to a service and I rely on it to generate revenue then I need it to be there and perform well when an opportunity arises. I don’t care about disk or network card failures; I care about the service working when I need it to.
If you go and implement a single server running your application then the industry metrics reckon that the best uptime you should expect is 98%. It doesn’t matter what SLA’s your hoster offers. A standalone server will have failures that require maintenance, even with dual power, dual networking and RAID storage. That’s why you see mission critical applications running on more complex solutions.
You’ve probably heard the term VPS. That’s no better! This uses machine virtualisation to squeeze as many virtual machines (individual computers that run in the memory of a physical computer) onto a host as possible. Compromises are made to accomplish this including those that affect performance. When you see the word “burstable” beside your allocation of RAM that will be your tip off that the VPS service doesn’t guarantee you the RAM you are paying for. They might have 32GB of RAM on the server but they’re trying to sell more than that by not supplying a virtual machine with its RAM until it requires it. The VPS virtual machines suffer from the same uptimes as a standalone server. That’s because they are running on a standalone server. So when you see an SLA of more than 98% on VPS you should start to ask questions. Industry metrics say it just isn’t possible no matter where that standalone server is hosted or how it is configured.
The traditional approach to achieving higher uptimes with physical servers was to build a cluster. “Statefull” servers such as database servers use failover clusters.
Click for full size image
These types of cluster consist of N+1 servers. What does that mean? It means that if you run a service, e.g. a database engine, on one server then you have 1 equally specified machine sitting idle, waiting for a situation when the first server fails. You then need to deploy shared disk. That’s required because both servers need to be able to access the database and log files of the database engine. That’s where the “statefull” comes in; there is some form of data that needs to be consistent. This storage can’t be just any old server disk. It must be a storage area network (SAN) with either fibre channel or iSCSI connections. There are multiple connections between servers and multiple paths between the servers, switches, controllers and storage trays. You can almost hear the Euros melting away from your bank account! Your application needs to be suitable for running on a cluster. Your service will then be presented to the rest of the network as a “virtual” server with its own computer name and IP address. A resource group containing the disk, service(s), name and IP address are configured in the cluster. This resource group from one server to another when there is a failure or when some maintenance needs to be done. In a failure, the redundant server detects a response failure on the private network and initiates that move. When there is scheduled maintenance an administrator will initiate the move. No matter what the circumstance, there will be a brief outage as services are pause, disks have their owner changed from one server to another and the services are started up again.
That sounds expensive and it is. The last time I looked at a basic cluster kit with 2 low spec servers and a small amount of storage it came in at a purchase price of €13,000 plus VAT. Since then server hardware has gone up in price. When you add in the cost of racking that, powering it up and running the enterprise editions of your operating system on both servers then you can see the costs going up and up. Then comes the inevitable upgrade of the operating system. You can’t just do an in-place upgrade. There’s a complicated process of destroying the cluster and building a new one. With this process there is a window (small if carefully planned and executed) where there is no fault tolerance. Could you or your customers risk that?
“Stateless” applications such as web servers don’t need a failover cluster. Instead you will use load balanced servers. Sure, the costs are lower but you’re still looking at running two servers and 2 operating systems to get N+1 fault tolerance should there be a hardware issue. You also need to consider how you will synchronise the data changes for your web content between the servers to ensure a consistent experience for your customers.
Can you do any of this clustering with VPS machines? Sure you can. But here’s the rub: What use is it to implement 2 load balanced web servers and a failover cluster with iSCSI storage if all four machines are running on the same physical host? The reason we have used clustering is to avoid outages caused by hardware faults. If that single physical machine has a fault then it affects all four VPS machines equally. No amount of clustering or expensive operating system editions will save your business then.
Related posts:
