Appendix A Environment File Variables for Serviceguard Integration with Continuous Access XP

(Default=1)

This parameter applies only when the fence level is set to DATA, which will cause the application to fail if the CA link fails or if the remote site fails.

Values:

0—Do NOT startup the package at the primary site. Require user intervention to either fix the hardware problem or to force the package to start on this node by creating the FORCEFLAG file. Use this value to ensure that the SVOL data is always current with the trade-off of long application downtime while the CA link and/or the remote site are being repaired.

1—(DEFAULT) Startup the package at the primary site. Request the local disk array to automatically split itself from the remote array. This will ensure that the application will be able to startup at the primary site without having to fix the hardware problems immediately. Note that the new data written on the PVOL will not be remotely protected and the data on SVOL will be non-current. When the CA link and/or the remote site is repaired, you must manually use the command “pairresync” to re-join the PVOL and SVOL. Until that command successfully completes, the PVOL will NOT be remotely protected and the SVOL data will not be current. Use this value to minimize the down time of the application with the trade-off of having to manually resynchronize the pairs while the application is running at the primary site.

(Default=0)

This parameter applies when the package is starting up with possible non-current data under certain CA pair states. During failover, this parameter will apply when the SVOL is in the PAIR or PFUL state and the PVOL side is in the PSUE, EX_ENORMT, EX_CMDIOE or PAIR (for CA Journal) state. During failback, this parameter will apply when the PVOL is in the PSUS state and the SVOL is in the EX_ENORMT or EX_CMDIOE state. When starting the package in any of the above states, you run the risk of losing data.

Values:

0—(DEFAULT) Do NOT startup the application on non-current data. If Metrocluster/CA cannot determine the data is current, it will not allow the package to start up. (Note: for fence level DATA and NEVER, the data is current when both PVOL and SVOL are in PAIR state.)

1—Startup the application even when the data may not be current.

Note on using the AUTO_NONCURDATA variable:

When a device group state is SVOL_PAIR on the local site and EX_ENORMT (Raid Manager or node failure) or EX_CMDIOE (disk I/O failure) on the remote site (this means it is impossible for Metrocluster/CA to determine if the data on the SVOL site is current), Metrocluster/CA conservatively assumes that the data on the SVOL site may by non-current and uses the value of AUTO_NONCURDATA to determine whether the package is allowed to automatically start up. If the value is 1, Metrocluster/CA allows the package to startup; otherwise, the package will not be started.

Use the two scenarios below to help you determine the correct environment settings for AUTO_NONCURDATA and AUTO_FENCEDATA_SPLIT for your Metrocluster/CA packages.

Scenario 1: With the package device group fence level DATA, if setting AUTO_FENCEDATA_SPLIT=0, it is guaranteed that the remote data site will never contain non-current data (this assumes that the FORCEFLAG has not been used to allow the package to start up if the CA links or SVOL site are down). In this environment, you can set AUTO_NONCURDATA=1 to make the package automatically startup on the SVOL site when the PVOL site fails, and it is guaranteed the package data is current. (If setting AUTO_NONCURDATA=0, the package will not automatically startup on the SVOL site.)

Scenario 2:When the package device group fence level is set to NEVER or ASYNC, you are not guaranteed that the remote (SVOL) data site still contains current data (The application can continue to write data to the device group on the PVOL site if the CA links or SVOL site are down, and it is impossible for Metrocluster/CA to determine whether the data on the SVOL site is current.) In this environment, it is required to set AUTO_NONCURDATA=0 if the intention is to ensure the package application is running on current data. (If setting AUTO_NONCURDATA=1, the package will be started up on SVOL site whether the data is current or not.)

(Default=0)

In asynchronous mode, when the primary site fails, either due to CA link failure, or some other hardware failure, and we fail over to the secondary site, the PVOL will become PSUE and the SVOL will become PSUS(SSWS). During this transition, horctakeover will attempt to flush any data in the side file on the MCU to the RCU. Data that does not make it to the RCU will be stored on the bit map of the MCU. When failing back to the primary site any data that was in the MCU side file that is now stored on the bit map will be lost during resynchronization.

In synchronous mode with fence level NEVER, when the CA link fails, the application continues running and writing data to the PVOL. At this point the SVOL contains non-current data. If there is another failure that causes the package to fail over and start on the secondary site, the PVOL will become PSUE and the SVOL will become PSUS(SSWS). When failing back to the primary site, any differential data that was on the PVOL prior to failover will be lost during resynchronization.

	NOTE: This variable is also used for the combination of PVOL_PFUS and SVOL_PSUS. When either the side file or journal volumes have reached threshold timeout, the PVOL will become PFUS. If there is a CA link, or some other hardware failure, and we fail over the secondary site, the SVOL will become PSUS(SSWS) but the PVOL will remain PFUS. Once the hardware failure has been fixed, any data that is on the MCU bit map will be lost during resynchronization. This variable will allow package startup if changed from default value of 0 to 1.

Values:

0—(DEFAULT) Do NOT failback to the PVOL side after an outage to the PVOL side has been fixed. This will protect any data that may have been in the MCU side file or differential data in the PVOL when the outage occurred.1—Allow the package to startup on the PVOL side. We failed over to the secondary (SVOL) side due to an error state on the primary (PVOL) side. Now we're ready to failback to the primary side. The delta data between the MCU and RCU will be resynchronized. This resynchronization will over write any data that was in the MCU prior to the primary (PVOL) side failure.

(Default=0)

This parameter applies when the PVOL is in the suspended state PSUS, and SVOL is in the failover state PSUS(SSWS). When the PVOL and SVOL are in these states, it is hard to tell which side has the good latest data. When starting the package in this state on the PVOL side, you run the risk of losing any changed data in the PVOL.

Values:

0—(Default) Do NOT startup the package at the primary site. Require user intervention to choose which side has the good data and resynchronizing the PVOL and SVOL or force the package to start by creating the FORCEFLAG file.1—Startup the package after resynchronize the data from the SVOL side to the PVOL side. The risk of using this option is that the SVOL data may not be a preferable one.

(Default=0)

This parameter applies when the PVOL and SVOL both have the state of suspended (PFUS) due to the side file reaching threshold while in Asynchronous mode only. When the PVOL and SVOL are in this state, the CA link is suspended, the data on the PVOL is not remotely protected, and the data on the SVOL will not be current. When starting the package in this state, you run the risk of losing any data that has been written to the PVOL side.

Values:

0—(Default) Do NOT startup the package at the secondary site and allowing restart on another node. Require user intervention to either fix the problem by resynchronizing the PVOL and SVOL or force the package to start on this node by creating the FORCEFLAG.

1—Startup the package after making the SVOL writable. The risk of using this option is that the SVOL data may actually be non-current and the data written to the PVOL side after the hardware failure may be loss.

(Default=0)

This parameter applies when the PVOL and SVOL both have the state of PSUE. This state combination will occur when there is an CA link, or other hardware failure, or when the SVOL side is in a PSUE state while we can not communicate with the PVOL side. This will only apply while in the Asynchronous mode.

The SVOL side will become PSUE after the CA link timeout value has been exceeded at which time the PVOL side will try and flush any outstanding data to the SVOL side. If this flush is unsuccessful, then the data on the SVOL side will not be current.

Values:

0—(Default) Do NOT startup the package at the secondary site and allow package to try another node. Require user intervention to either fix the problem by resynchronizing the PVOL and SVOL or force the package to start on this node by creating the FORCEFLAG file.

1—Startup the package on the SVOL side. The risk of using this option is that the SVOL data may actually be non-current and the data written to the PVOL side after the hardware failure may be loss.

(Default=0)

This parameter applies when the PVOL and SVOL both have the state of suspended (PSUS). The problem with this situation is we cannot determine the previous state: COPY or PAIR. If the previous state was PAIR, it is completely safe to startup the package at the remote site. If the previous state was COPY, the data at the SVOL site is likely to be inconsistent

Values:

0—(Default) Do NOT startup the package at the secondary site. Require user intervention to either fix the problem by resynchronizing the PVOL and SVOL or force the package to start on this node by creating the FORCEFLAG file.

1—Startup the package after making the SVOL writable. The risk of using this option is the SVOL data may be inconsistent and the application may fail. However, there is also a chance that the data is actually consistent, and it is okay to startup the application.

This parameter defines the clustering environment in which the script is used. Should be set to “metro” if this is a Metrocluster environment and “continental” if this is a Continentalclusters environment. A type of “metro” is supported only when the HP Metrocluster product is installed. A type of “continental” is supported only when the HP Continentalclusters product is installed.

Specifies the Raid Manager device group for this package.

Fence level. Possible values are NEVER, DATA, and ASYNC. Use ASYNC for improved performance over long distances.

If a Raid Manager device group contains multiple items where either the PVOL or SVOL devices reside on more than a single XP Series array, then the Fence level must be set to “data” in order to prevent the possibility of inconsistent data on the remote side if an CA link or an array goes down. The side effect of the “data” fence level is that if the package is running and a link goes down, an array goes down, or the remote data center goes down, then write(1) calls in the package application will fail, causing the package to fail.

	NOTE: The CA Journal is used for asynchronous data replication. Fence level ascyn is used for a journal group pair.

This is the instance of the Raid Manager that the control script will communicate with. This instance of Raid Manager must be started on all nodes before this package can be successfully started. (Note: If this variable is not exported, Raid Manager commands used in this script may fail).

This variable supports the security feature, RAID Manager Protection Facility on the Continuous Access devices. (Note: If the RAID Manager Protection Facility is disabled, set this variable to MGRNOINST. This is the default value).

(Default=360)

This variable is used only in asynchronous mode when the horctakeover command is issued; it is ignored in synchronous mode. The value is used as the timeout value in the horctakeover command, -t <timeout>. The value is the time to wait while horctakeover re-synchronizes the delta data from the PVOL to the SVOL. It is used for swap-takeover and SVOL takeover. If the timeout value is reached and a timeout occurs, horctakeover returns the value EX_EWSTOT. The unit is seconds.

In asynchronous mode, when there is an CA link failure, both the PVOL and SVOL sides change to a PSUE state. However, this change will not take place until the CA link timeout value, configured in the Service Processor (SVP), has been reached. If the horctakeover command is issued during this timeout period, the horctakeover command could fail if its timeout value is less than that of the CA link timeout. Therefore, it is important to set the HORCTIMEOUT variable to a value greater than the CA link timeout value. The default CA link timeout value is 5 minutes (300 seconds). A suggested value for HORCTIMEOUT is 360 seconds.

During package startup, the default startup timeout value of the package is set to NO_TIMEOUT in the package ASCII file. However, if there is a need to set a startup timeout value, then the package startup timeout value must be greater than the HORCTIMEOUT value, which is greater than the CA link timeout value:

Pkg Startup Timeout > HORCTIMEOUT > CA link timeout value

For CA Journal mode package, journal volumes in PVOL may contain a significant amount of journal data to be transferred to SVOL. Also, the package startup time may increase significantly when the package fails over and waits for all of the journal data to be flushed. The HORCTIMEOUT should be set long enough to accommodate the outstanding data transfer from PVOL to SVOL.

(Default=0)

This parameter must be set to 1 if a PVOL or an SVOL for this package resides on more than one XP frame. Currently, only a value of 0 is supported for this parameter.

	NOTE: Future releases may allow a value of 1.

Values:

0—(Default) Single frame.

1—Multiple frames. If this parameter is set to 1, then the device group must be created with the “data” fence level, and the FENCE parameter must be set to “data” in this script.

Contains the full path name of the package directory. This directory must be unique for each package to prevent the status file from being overwritten when there are multiple packages. The operator may create the FORCEFLAG file in this directory.

Seconds to wait for each “pairevtwait” interval. (Note: do not set this to less then 300 seconds because the disks have some long final processing when the copy state reaches 100%).

(Default=10 minutes)

This parameter defines the polling interval for the monitor service (if configured). If the parameter is not defined (commented out), the default value is 10 minutes. Otherwise, the value will be set to the desired polling interval in minutes.

(Default=0)

This parameter controls the frequency of notification messages sent when the state of the device group remains the same. If the value is set to 0, then the monitor will only send notifications when the device group state changes. If the value is set to n where n is greater than 0, the monitor will send a notification every nth polling interval or when the device group state has changed. If the parameter is not defined (commented out), the default value is 0.

(Default=empty string)

This parameter defines the email addresses that the monitor will use to send email notifications. The variable must use fully qualified email addresses. If multiple email addresses are defined, the comma must be used as a separator. If the parameter is not defined (commented out) or the default value is an empty string, this will indicate to the monitor that no email notifications will be sent.

(Default=0)

his parameter defines whether the monitor will send notifications to the syslog file. When the parameter is set to 0, the monitor will NOT send notifications to the syslog file. When the parameter is set to 1, the monitor will send notifications to the syslog file. If the parameter is not defined (commented out), the default value is 0.

(Default=0)

This parameter defines whether the monitor will send console notifications. When the parameter is set to 0, the monitor will NOT send console notifications. When the parameter is set to 1, the monitor will send console notifications. If the parameter is not defined (commented out), the default value is 0.

This parameter defines the pre-defined resynchronization actions that the monitor can perform when the package is on the PVOL side and the monitor detects the CA data replication link is down. If the variable is not defined or commented, the default value of 0 is used.

Values:

0— (Default) When the parameter is set to 0, the monitor will not perform any resynchronization actions.

1—When the parameter is set to 1 and the data replication link is down, the monitor will split the remote BC (if configured) and try to resynchronize the device. Until the resynchronization starts, the monitor will try to resynchronize every polling interval. Once the device group has been completely resynchronized, the monitor will resynchronize the remote BC.

2—When the parameter is set to 2 and the data replication link is down, the monitor will only try to perform resynchronization if a file named MON_RESYNC exists in the package directory (PKGDIR). The monitor will not perform any operations to the remote BC (that is, split and resynchronize the remote BC). Therefore, this setting is used when you want to manage the remote BC