Overview - Operational Behavior of Neverfail ClusterProtector

Follow

Summary

This Knowledgebase article describes the operation behavior of the Neverfail ClusterProtector solution which differs from a standard Neverfail implementation.


More Information

The behavior described in this document is valid for correctly deployed solutions that have been deployed according to Neverfail ClusterProtector documentation and appropriate plug-ins and describes the following scenarios:

  • What happens when there is a switch between Cluster nodes (Resource Group Move)?
  • What happens when there is a failover between Cluster nodes (Cluster Node Failover)?
  • What happens when there is a switchover within Heartbeat (Neverfail Switch)?
  • What happens where there is a failover within Heartbeat (Cluster Failure)?

The following description overview assumes a two-node cluster protected by Neverfail ClusterProtector.

  • Cluster nodes Node1 and Node2
    • Protected by Neverfail Primary
  • To a standalone Disaster Recovery Server running Neverfail Secondary
  • Or, in the case of Exchange a single node cluster protected by Neverfail Secondary.
  1. Resource Group Move

    A switch occurs between Cluster nodes Node1 (active) to Node2 (active). This is initiated by the Move Group function selected from the Cluster Administrator console (cluster.mmc).
    1. The resources in the group are taken offline on Node1.
    2. Neverfail Heartbeat is shut down on Node1.
    3. Resources are then brought online on Node2.
    4. Neverfail Heartbeat is then started on Node2.
    5. A registry check and a full system check will take place between Node2-Neverfail Secondary.
  2. Cluster Node Failover

    Node1 fails and there is a failover to Node2. This can happen when the cluster service stops or the resources are no longer available on that node.
    1. Neverfail Heartbeat is shut down on Node1.
    2. Neverfail Heartbeat starts on Node2.
    3. A registry check and a full system check will take place between Node2-Neverfail Secondary.
  3. Neverfail Switch

    When a switchover is triggered by the Administrator or an auto-switchover is triggered by a monitoring rule, Neverfail ClusterProtector will perform the following actions:
    1. Switching from Primary Site to DR Secondary Site.
      1. The stopPrimary.bat script is executed on the Neverfail Primary server protecting Active Node1.
      2. The protected application IP resource is taken offline on Node1.
      3. All resources dependent on this resource will go offline including the application resources.
      4. The startSecondary.bat script will execute on the Neverfail Secondary server.
      5. Application services will start on the secondary server.

        Additional Step for Exchange 2007 Only :

      6. For PowerShell cmdlets to return the correct information, the Clustered Mailbox Server ownership must be moved to the DR Cluster node with the following PowerShell command:

        Set-MailboxServer -Identity:<CMSName> -RedundantMachines:{<DRNodeName>}

    2. Switching from DR Secondary Site to Primary Site
      1. The stopSecondary.bat script is executed on the Neverfail Secondary server.
      2. The application services stop on Neverfail Secondary.
      3. The startPrimary.bat script is executed on Node1: active (Neverfail Primary) server, which brings the resources including the application group online.

        Additional Step for Exchange 2007 Only :

      4. For PowerShell cmdlets to return the correct information, the Clustered Mailbox Server ownership must be moved to the Production Cluster nodes with the following PowerShell command:

        Set-MailboxServer -Identity:<CCMSServerName> -RedundantMachines:{< ProductionActiveNodeName>,<ProductionPassiveNodeName>}

  4. Cluster Failure

    When the Cluster fails:
    1. The Neverfail Secondary server will start counting missed heartbeats.
    2. When the max number of missed heartbeats is reached, the Neverfail Secondary server will become the active server. Neverfail strongly recommends configuring manual failover to avoid split brain if the communication channel fails between Primary and Secondary servers. Administrators can then control failover by manually making the Secondary/DR server active.
    3. The startSecondary.bat script is executed on the server, which will start the application’s services.

      Additional Step for Exchange 2007 Only :

    4. For PowerShell cmdlets to return the correct information, the Clustered Mailbox Server ownership must be moved to the DR Cluster node with the following PowerShell command:

      Set-MailboxServer -Identity:< CMSName > -RedundantMachines:{< DRNodeName >}


Applies To

Neverfail Cluster Protector with Neverfail v5.5.1
Neverfail Cluster Protector with Neverfail v6.3.1
Neverfail Cluster Protector with Neverfail v6.6.0
Neverfail Cluster Protector with Neverfail v6.7.0


Related Information

None

KBID-1456

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.