Disaster Recovery and DR Preparedness : Configure startup dependencies
  
Configure startup dependencies
If an RN depends on one or more RNs, or server outside your HA’s control, (for example, your Exchange Server depends on a Domain Controller), configure these dependencies in advance by adding RNs to groups. You can start all your recovery nodes individually, if you desire, taking into account the necessary boot order, but onQ automates all this work for you.
onQ will start a given RN after the RNs on which it depends are up and running. Startup dependencies do not apply to RNs in test mode (or automatic testing); startup dependencies apply in production mode.
onQ uses startup dependencies when a group of RNs is started on the HA Appliance or a group, or all, RNs are started on the DR Appliance or DR Mirror.
To configure an RN’s startup dependencies:
There is no limit to the number of dependencies that you can create for each RN. All dependencies in the list are executed in parallel.
All dependencies are configured on the HA. After you save that configuration, onQ transfers that information to the DR Appliances and DR Mirrors.
1. Log on to the HA’s onQ Portal.
2. Create a group to contain each dependency. For example, create a Domain Controller & Mail Server group and assign both the Exchange Server and the Domain Controller to that group.
a. Click the PROTECTION CONFIG tab.
b. Select the node, then MODIFY button.
c. In the Group Name field type the name of the group, then SAVE.
3. Specify the startup dependencies for the RN:
a. Click the PROTECTION CONFIG tab.
b. Select the node, then MODIFY button > ADVANCED button.
c. In the Startup Dependencies field, click the NONE button. If this isn’t your first time setting up a dependency, the CUSTOM button appears instead.
d. Click the plus button (+). A default entry appears in the Startup Dependencies List.
e. Define the Dependent Server. In the Dependent Server field, select the RN from the drop‑down list or specify the IP address or hostname of the server that is not protected by (external to) this HA and on which the RN depends. If the dependent server is an external server, you must define it in the hosts file, unless you specify the IP address. Leave this field blank to specify a delay policy instead of a server dependency (see “Delay” in Step f).
f. Specify the following information:
Timeout – Indicate how long you want the onQ to wait for the Dependent Server to respond to a ping request. The default value is 5 minutes, but base the value on the typical boot time for your server. Ensure that the firewall allows ping requests. If you specify a Dependent Server, you must also specify a timeout value.
Timeout Action – Indicate what you want onQ to do with the RN if the Dependent Server does not respond to the ping command within the timeout period. onQ can start the RN (Start Anyway) without honoring the dependent server, or you can instruct onQ to refrain from starting the RN (Abort Start), regardless of whether all other dependencies are met, because the dependent server is critical to the RN’s availability.
Delay – Specify a delay policy along with or instead of a server dependency.
Delay policy in addition to a server dependency. Indicate how long you want onQ to delay the RN startup after onQ detects that the dependent server is up. The default value is 1 minute, but base the value that you specify on the typical time needed for your dependent server’s applications to respond to user requests.
Delay policy instead of a server dependency. If a dependent RN is not configured to respond to the ping command on which Timeout depends, or you know that a dependent server will take a long time to boot, do not specify a server dependency; instead, create a delay policy: leave the Dependent Server field blank and specify a Delay time that accounts for the typical time needed for your dependent server’s applications to respond to user requests. In this case, the delay option ignores values for Timeout Action and Timeout. You can only specify one such delay policy; if you try to specify two policies, the onQ Portal returns an error: Only one row may have a blank server entry for a delay only specification.
Example:
In the following example, all the internal dependent servers typically require 5 minutes to respond to ping requests, but this example provides an additional 5 minutes just in case. In most cases, the dependent server’s applications are available within 15 minutes; therefore, in this example, the applications will have more than enough time (10-min timeout plus a 15-min delay) to become available. All dependent servers are critical to the RN’s availability, with the exception of the “optional” Salesforce application. Alternatively, a simple 15-minute (or 20) delay policy can encompass all the dependencies in the list.
4. Click SAVE.
To revert to the last saved values, click REVERT.
To clear all data and start over, click CLEAR. Default values repopulate the fields provided.
As the RN starts and if that RN has dependencies configured, the onQ Portal displays messages as the dependencies are met.