Is there a best practise to implement a warm standby-solution

Hello:

I am planning to integrate an existing application with MSCS. However, in a
failover scenario a full application startup will take too long. Therefore I
am planning to implement a warm standby instance of the application. I would
like that status of the warm standby instance to be a consideration in a
failover decision.

Do you have any suggestions on how I might accomplish this with MSCS as
opposed to building a custom cluster aware component?

 

Hi RonC,

This will really depend on the application. In most cluster-aware apps, all
nodes stay running with the app ready to go. On failure, the other takes
over with only the time for the failure detect and session reconnect.

If the app is not built for this, your options may be far fewer.
--
Ryan Hanisco
MCSE, MCTS: SQL 2005, Project+
Chicago, IL

Remember: Marking helpful answers helps everyone find the info they need
quickly.

 

Microsoft Clustering services cannot provide what you need. We provide
'high' availability, not '100%' availability. Failing over application
'state' is not possible. We disconnect clients during a failover and the
clients must be able to reconnect. If your applications use Distributed
Transactions, then the ACID process should help deal with that.

 

Hi Chuck. Thanks, but I realize there will be a disruption to the clients
during failover.

All I want to do is reduce the failover time. I can achieve this with a
second instance of the application running in a warm state. The application
is complex with multiple services. If a service fails in the active instance,
I want to know I am failing to an instance of the application that is in good
health (having a better service level than the failed from side). Failing to
the warm instance would only involve a failover of an I P address.

Thanks again for your response.

Hi Chuck. Thanks, but I realize there will be a disruption to the clients
during failover.

 

We still do not failover 'state' information.

 

sounds to me you want some sort of NLB, but then also failing over "state"
or "session" info.
Your application need to take care of that, custering will not do that for
you.

 

Thanks all, I do appreciate your attention:

I suspected that some of what I need is not provided by MSCS. My concern is
"am I trying to do something that is beyond support". I'll try to articulate
the solution in a way that focuses on my areas of concern:

1) In a two node cluster I am planning to run an instance of the same
application (ApplicationX) on each node. ApplicationX is cluster aware. Each
instance will be managed by a separate resource group. These resource groups
will be configured to not failover (i.e. only run on one node). Is this type
of configuration supported?

2) In the same two node cluster, I am planning to run one instance of an
application (ApplicationY, different from the above). ApplicationY will be
cluster aware. Using the eventing mechanism in MSCS, ApplicationY and will
listen to cluster events initiated from the resource groups managing
ApplicationX instances. ApplicationY will be managed by a third resource
group. This resource group will failover, between the two nodes. The failover
criteria will be based on the online/offline status of ApplicationX instances
collect through MSCS events. Is this type of implementation supported?

My plan is to have ApplicationY tell the local instance of ApplicationX to
be the active one. Note even though both instances of X are online, only one
can be "active".

ApplicationX is not stateless so NLB won't fly.

I need both instances of ApplicationX past initialization to reduce the
failover time.

I don't want to fail to an instance of ApplicationX if it's not healthy.

 

I don't think that MSCS is the right platform for this.
Doing all this on a failover cluster is just adding complexity.

you are talking about some sort of "Application Failover" from within an
Application, monitored and decision making by a third app (your app Y)... I
fail to see why you cannot run this on standalone hosts.

Also, the below does not take care of "state", you need to code that into
your appX