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

Discussion in 'Clustering' started by RonC, Jul 24, 2007.

  1. RonC

    RonC Guest


    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?
    RonC, Jul 24, 2007
    1. Advertisements

  2. RonC

    Ryan Hanisco Guest

    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
    Ryan Hanisco, Jul 25, 2007
    1. Advertisements

  3. RonC

    Chuck [MSFT] Guest

    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.
    Chuck [MSFT], Jul 25, 2007
  4. RonC

    RonC Guest

    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.
    RonC, Jul 25, 2007
  5. RonC

    Chuck [MSFT] Guest

    We still do not failover 'state' information.
    Chuck [MSFT], Jul 26, 2007
  6. 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
    Edwin vMierlo [MVP], Jul 26, 2007
  7. RonC

    RonC Guest

    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.
    RonC, Jul 26, 2007
  8. 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
    Edwin vMierlo [MVP], Jul 26, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.