The other day, I was taking care of my end of year appointments, one of course was seeing my eye doctor.  I was overdue which is especially important since I am a diabetic and need my eyes checked each year.  Because my ophthalmologist is so busy, getting an appointment is nearly impossible. I had to miss my company holiday party because I had to book this appointment three months in advance. I did try to reschedule it but that would have had to be in February of next year.

Once at my appointment, I learned my ophthalmologist office is transitioning to EHR and they had my folder to check me in and do my exam. After they finished, they placed  a bright yellow paper on top of the papers in the file “ALERT, Patient is now in EHR system”.  So I sat there, missing my holiday party and thinking that if that system wasn’t available, could they still see me after they purge all the manila folders and my paper records?

Was there a backup, and would I be sitting here next year in the same predicament, but with a doctor unable to access my records if the server went down? And since the office is so busy, how much downtime would severely impact their schedule and patients? Would they have the time cushion to back fill the missed appointments, and if not, would I have to reschedule for February, miss my insurance claim for the year costing me more out of pocket, have to take additional time off from work, and of course – miss another holiday party?

Bah Humbug!

We’ve always had a bit of a problem describing “fault tolerant.” Even knowledgeable people in the availability industry struggle with a concept whose very name is misleading. “Fault tolerant” leads people to believe that a system works to manage or “tolerate” a failover, when that simply isn’t true. Since everything is duplicated and runs twice, nothing happens to the system when there is a problem. The application continues running on the working server and the performance stays the same while the faulty one calls home for pro-active service.

For an analogy, think of the Radio City Rockettes as our server, and the kicking action as our application. If, in the middle of the show, a Rockette falls off the stage, kicking still happens. However, in our model, the horror of watching the fall has probably disrupted the audience, and the show is no longer a success.

So let’s try another analogy. As it turns out, your body’s most important organs are fault tolerant (with two notable exceptions.) You have two lungs, two kidneys, two eyes, two legs, and women have two ovaries.  If we think of the functions of these organs (say, sight,) as the application and the organ (here, eyes) as the server, people with one working eye can still see. But, as Kevin Butler our web guy pointed out, one-eyes people can’t gauge distance, have limited range, and many other problems. So, your body isn’t quite as fault as we had hoped.

Another example we came up with were races. Imagine two identical runners in a race, each running for the same team. Here, the race is the application and the runners are the fault-tolerant servers. If the gun goes off, and one runner trips, a runner still makes it to the finish line for a medal for his team and if both runners had crossed the finish line, still only one medal would have been earned. It, too, doesn’t quite fit.

The duplicated, wasted energy is, in every other facet of life, eliminated or nonexistent. Fault tolerant servers literally do all of the work of each application twice, for just one result. Half of the work is completely superfluous unless its twin server has faulted in which case, it merely continues doing the same work alone until the faulted twin is back online.

Does anyone have a better analogy? How do you explain fault tolerance? Does this ever occur in nature?

There are many reasons clusters are difficult to manage: the number of servers, their connecting components, the application managing them such as Microsofts’ Cluster Administrator, and the inherent problem that clusters are designed to failover to each other. In essence, they are specifically designed to react to the problem after it happens.

There is also a requirement that your applications are “cluster-aware.” A cluster solution is not so much of a product as a tool set. To have the cluster work, your applications must be written with the tools so the application has knowledge of the cluster solution built into it.
Now, lots of commercial software such as SQL-server, for example, is cluster aware, however, the cluster-aware version of such software often carries a much higher license fee.

According to Microsoft’s website, applications are capable of being cluster-aware if they use TCP/IP as a network protocol, maintains data in a configurable location, and supports transaction processing. Essentially, in order to use a cluster solution, you must first choose applications that is “cluster aware.”

As an alternative, the virtualization-ready ftServer requires no specialties of application, requires no workarounds, and is a simple, plug-in-and-go solution.

Stratus® ftServer® systems are designed to use industry-standard hardware components and to support off-the-shelf operating systems so that they appear as standard x86 servers to third-party management tools. By adhering to industry-standard protocols, Stratus provides a suite of tools to manage ftServer systems both locally and remotely and to integrate them with a wide variety of third party management tools.

More importantly, this management capability is augmented by the fault-tolerant architecture of the ftServer system itself and the robust Service and Proactive Availability Management that back it up. This combination insures that ftServer systems seamlessly integrate within existing management frameworks and that they provide the highest levels of uptime and ease of management.

This session describes the tools available for monitoring and managing ftServer systems in a variety of scenarios ranging from local or remote configuration of a single server to integration with an enterprise management software suite controlling a large-scale heterogeneous server infrastructure.