Service guard Justification

[Basheer_2]

Good morning,

for a 7x24 oracle11i ERP, how do i justify service guard.
any links, info,docs, white/black papers please

Thanks

[Pete Randall]

Typically justifications are done by assigning a cost per hour figure to downtime. If you have hundreds of employees that cannot do any work when the system is down, there is a cost associated with that. If you can't sell any product, there is a cost associated with that.

The costs of the downtime are then weighed against the cost of setting up service guard. You may be able to find documents that can give you some guidance on assessing your downtime costs but I personally don't know of any.


Pete

[Jeff Schussele]

Well...IF this is a "grid" Oracle installation, then MC/SG is not necessary - the grid covers individual system failure.
If not, then it's worth it's weight in gold.
Downtime = lost $

My 2 cents,
Jeff

[Alzhy · Accepted solution]

Basheer,

It all boils down to how you interpret Highly Available (non-cluster but redundant server) and High Availability (SG Cluster) and what scenarios each implementation protects.

I've had clients that opt for the former (Highly Available configuration) for their critical systems instead of a cluster. What I do provide is a backup/failover (turnkey almost) scheme wherein recoverability and failoverability can be done within minutes -- basically close to what a cluster can do. A SAN environment makes this a lot easy since these days you can have everything (including your boot/swap disks) on the SAN. This also makes it cost effective since your failover environment can also be used for test, staging, development, etc. instead of just lying idle.

Of course if you've deep pockets - opt for a cluster.

[Steven E. Protter]

Shalom Basheer,

ServiceGuard provides higher availability and less points of failure than a single machine.

In a single machine setup if the power supply or boot disk or any critical component of the machine fails the application stops working and is not up.

With SG, the application fails over to another machine and work continues.

SEP

[Bill Hassell]

Technically, the requirement for 7x24 means your machine can't be down. If the requirement is rewritten to be Mon-Fri business hours only, then you'll have plenty of time for critical patches, replacing failed disks, RAM, etc and you won't need Service Guard. Often overlooked for 7x24 environments are the requirements to provide maintenance windows for patches (which are mandatory for production systems). MC/SG provides a method to patch the backup machine without affecting the production system, then switching machines to reverse the roles.

[A. Clay Stephenson]

Surprisingly, the best reason to use MC/SG is so that you won't need it. I have yet to have a single package failover (other than those I intentionally initiated for patching) in an ERP environment in well over 7 years -- and this includes many separate packages. You see, by the time you get your boxes robust enough for MC/SG, little things like LAN failures, network switch failures, disk-related failures, power failures, and perhaps most importantly your operating procedures -- are handled long before MC/SG itself comes into play.

[William DeJongh_1]

We justified it using accounting's own numbers. The CFO would throw a figure of $360K/day in our face if we had any extended downtime. So we used their estimate. Maybe you could do the same. Once you get MCSG in and eliminate one downtime, you'll love it and the users will love it.

[Alzhy]

A. Clay's response above precisely points out the same justification I made against a client wanting to splurge on a SG/Cluster solution. Never ever in my 10+ years IT career have I seen clustering solutions (like SG, Veritas Cluster or Sun Cluster) actually) ever ben called upon to failover applications. Most of the system faults are arrested way ahead of a failover need.

And this is what I meant by "highly available" -- making sure server critical components are redundant -- like storage, network , HBAs, etc. Coupled with a turnkey standby/failover system - you'll get close to a seamless failover without a cluster.

[A. Clay Stephenson]

You shouldn't read into my response that I am not a proponent of MC/SG; in fact, the opposite is quite true. There are still many scenarios that require MC/SG to fix the problem. Even on my systems which have never done a "real" package switch, I would never suggest that they will never do one. It could happen as I type this. My point is that MC/SG imposes a level of discipline on you and your systems so that by the time you get MC/SG correctly implemented, MC/SG itself seldom comes directly into play. Moreover, by the time you have spent the money on redundant HVAC systems, generators, UPS's, duplicate networks, disk arrays, and monitoring systems (not to mention the time), the cost of the MC/SG software is all but insignificant. Moreover, if you aren't willing to spend the money for those prerequisites the the money spent of MC/SG is all but wasted.

[Alzhy]

No A. Clay I am not assuming you are not a proponent of MC/SG. I am just saying your comments above mirror the same comments I made to a client wanting to have an SG solution in place but do not have deep pokets for redundant hardware etc.

These days, I advice clients to use a Cluster solution:

1. IF they have an absolute need for it
2. Have capable Admins() on their rolls
3. As a multi-site Failover solution along with mirrored storage.


(3) is particularly the primary justification in my book for cluster implementtion these days since single server failures are becoming pretty rare these days anyway. But even (3) can be implemented via a recipe I would call "Poor Man's Failover or CLustering"... with still acceptable downtime/lag in application availability for certain applications.