InfoScale™ 9.0 Cluster Server Agent for Hitachi TrueCopy/HP-XP Continuous Access Configuration Guide - Windows

Last Published:
Product(s): InfoScale & Storage Foundation (9.0)
Platform: Windows
  1. Introducing the agent for Hitachi TrueCopy/Hewlett-Packard XP Continuous Access
    1.  
      About the agent for Hitachi TrueCopy/HP-XP Continuous Access
    2.  
      Supported software
    3.  
      Supported hardware
    4.  
      Typical Hitachi TrueCopy/Hewlett-Packard XP Continuous Access setup in a VCS cluster
    5. Hitachi TrueCopy/Hewlett-Packard XP Continuous Access agent functions
      1.  
        About the Hitachi TrueCopy/Hewlett-Packard XP Continuous Access agent's online function
  2. Configuring the agent for Hitachi TrueCopy/Hewlett-Packard XP Continuous Access
    1. Configuration concepts for the Hitachi TrueCopy/Hewlett-Packard XP Continuous Access agent
      1.  
        Resource type definition for the Hitachi TrueCopy agent
      2. Attribute definitions for the TrueCopy/HP-XP-CA agent
        1. About the SplitTakeover attribute for the Hitachi TrueCopy agent
          1.  
            SplitTakeover attribute = 0
          2.  
            SplitTakeover attribute = 1
        2. About the FreezeSecondaryOnSplit attribute for the Hitachi TrueCopy agent
          1.  
            FreezeSecondaryOnSplit attribute = 0
        3.  
          About the HTC configuration parameters
        4.  
          Special consideration for fence level NEVER
        5.  
          Considerations for calculating the AllowAutoFailoverInterval attribute value
      3.  
        Sample configuration for the TrueCopy/HP-XP-CA agent
    2. Before you configure the agent for Hitachi TrueCopy/Hewlett-Packard XP Continuous Access
      1.  
        About cluster heartbeats
      2.  
        About configuring system zones in replicated data clusters
      3.  
        About preventing split-brain
    3. Configuring the agent for Hitachi TrueCopy/Hewlett-Packard XP Continuous Access
      1.  
        Configuring the agent manually in a global cluster
      2.  
        Configuring the agent manually in a replicated data cluster
  3. Testing VCS disaster recovery support with Hitachi TrueCopy/Hewlett-Packard XP Continuous Access
    1. How VCS recovers from various disasters in an HA/DR setup with Hitachi TrueCopy/Hewlett-Packard XP Continuous Access
      1.  
        Failure scenarios in global clusters
      2.  
        Failure scenarios in replicated data clusters
      3.  
        Replication link / Application failure scenarios
    2.  
      Testing the global service group migration
    3.  
      Testing disaster recovery after host failure
    4.  
      Testing disaster recovery after site failure
    5.  
      Performing failback after a node failure or an application failure
    6.  
      Performing failback after a site failure
  4. Setting up fire drill
    1.  
      About fire drills
    2. About the HTCSnap agent
      1.  
        HTCSnap agent functions
      2.  
        Resource type definition for the HTCSnap agent
      3.  
        Attribute definitions for the HTCSnap agent
      4.  
        About the Snapshot attributes
      5.  
        Sample configuration for a fire drill service group
    3.  
      Additional considerations for running a fire drill
    4.  
      Before you configure the fire drill service group
    5. Configuring the fire drill service group
      1.  
        About the Fire Drill wizard
    6.  
      Verifying a successful fire drill

Special consideration for fence level NEVER

During each monitor cycle, the VCS agent for HTC records the P-VOL status with the timestamp and propagates this information to the secondary site. The secondary site uses this information to keep track of the last known PAIR time of P-VOL.

Consider the following failure scenario:

  • The primary site has failed.

  • The status of P-VOL cannot be determined, because the RAID manager for that site is not reachable.

  • The replication status of S-VOL is displayed as PAIR.

The agent provides the AllowAutoFailoverInternal attribute that lets you configure automatic failover in this scenario. The automatic failover allows for minimum downtime at the risk of data loss or corruption.

In this scenario, the agent allows a failover to happen only if AllowAutoFailoverInterval < (Event B - Event A), where:

  • Event A is the last known PAIR status of P-VOL, which is a timestamp.

  • Event B is the time at which the secondary site detects that the primary site has failed and the remote RAID manager is not reachable.

The AllowAutoFailoverInterval value is passed to the AdvancedOpts attribute.

Table: Failover scenarios for the various AllowAutoFailoverInterval values

Value

Conditions

Actions

0

  • The fence level is NEVER.

  • The remote RAID manager is not reachable.

The failover is triggered. The last known PAIR status of P-VOL is recorded but not used.

Greater than 0

  • The fence level is NEVER.

  • The remote RAID manager is not reachable.

  • The last known remote state within T seconds is PAIR, where T is the AllowAutofailoverInterval value.

The failover is triggered. The last known PAIR status of P-VOL is recorded and is used to determine the failover action.

Greater than 0

  • The fence level is NEVER.

  • The remote RAID manager is not reachable.

  • The last known remote state is PAIR and is greater than T seconds, where T is the AllowAutofailoverInterval value.

The failover is not triggered. The last known PAIR status of P-VOL is recorded and is used to determine the failover action.

Greater than 0

  • The fence level is NEVER.

  • The remote RAID manager is not reachable.

  • The last known remote state is not PAIR.

The failover is not triggered. The last known PAIR status of P-VOL is recorded and is used to determine the failover action.

undefined

or

The value is not passed to the AdvancedOpts attribute.

Any

The automatic failover is not enabled. The last known PAIR status of P-VOL is not recorded. Manual intervention is required to restore the operations in this scenario.

Consider the following before using the AllowAutoFailoverInterval attribute:

  • This attribute can allow for an automatic failover only when all the following conditions are met:

    • The fence level is NEVER.

    • The remote HORCM connection has failed.

    • The SplitTakeover attribute is set to 0 (zero).

  • The use of this attribute provides a tradeoff between minimum downtime and data consistency. You may achieve a smaller downtime at the cost of possible data loss or corruption. The tradeoff exists because, in the fence level NEVER, if the remote HORCM is down, there is no way to figure out whether the replication link is healthy and the latest data is available for failover.

  • In this scenario if takeover has failed, the service group goes into Freeze state.

  • If the SplitTakeover attribute is set to 1, the agent triggers a failover regardless of the AllowAutoFailoverInterval value.

See Considerations for calculating the AllowAutoFailoverInterval attribute value.