Applies To:

Show Versions Show Versions

Manual Chapter: ARX Disaster Recovery
Manual Chapter
Table of Contents   |   << Previous Chapter

Execute the show master-key command on each ARX to display an encrypted version of its master key. If the backup switches have the wrong master key, reset them to their factory default configurations and change the master keys to the appropriate values.
An example of the output from the show master-key command follows; note that you must type the system password and the wrapping password for the chassis when prompted to do so:
provA(cfg)# show masterkey
System Password: %uper$ecretpw
Wrapping Password: an0ther$ecretpw
For detailed information about using this command, refer to the show master-key description in the ARX CLI Reference.
Use the copy running-config command to copy the entire running configuration (network-level parameters, not storage parameters) into a file on the chassis.
The ARX should not be running any storage services if it is designated as a backup; a backup is designed to take over services from the active switch or cluster after a failover. Use the remove service command to clear each service that is running currently, if any. This cleanly de-couples the ARX software from all back-end filers.
Use the delete startup-config and delete configs boot-config commands to delete the entire configuration, and then execute the reload command. This resets the ARX to its factory defaults, disables all management IP interfaces, and reruns the initial-boot script at the Console port.
Invoke the run command on the running-config file that you saved onto the chassis earlier. This re-establishes all of your network parameters.
The privileged-exec mode CLI command clear global-config removes the global-config.
All ARXes in both clusters must be configured with RON tunnels to all of the other ARXes, creating a full mesh. Use the ron tunnel CLI command to connect both ARXes at the active site to both ARXes at the backup site.
Use the cluster-name CLI command to specify a name for each cluster and the ARXes that belong to it. Each cluster must be named uniquely.
[no] cluster-name name {member switch-name member switch-name}
Where name is the cluster you are defining, and switch-name is the name of an individual ARX that will belong to the cluster.
where clustername is the name of the cluster for which you want to remove the name from the global configuration. If you specify localcluster as the cluster name, the name of the current cluster is removed from the global configuration.
If you are using CIFS local groups, you may want to assign a security account management (SAM) reference filer per site. Use the sam-reference command with its cluster argument to specify the cluster with which the external filer is associated. The command syntax is:
sam-reference filer cluster clustername
where clustername specifies the cluster with which filer is associated.
Note: Execute the sam reference command twice when configuring for disaster recovery: once to specify the SAM reference filer at the active cluster, and again to specify it at the backup cluster.
Refer to Selecting a SAM-Reference Filer in the ARX® CLI Storage-Management Guide for complete information about SAM-reference filers and the use of this command.
For each managed volume in the configuration, you need to define metadata shares for each site. Use the metadata share command to specify a metadata share for use with a particular cluster. The command syntax is:
metadata share filer {nfs3 | nfs3tcp | cifs} path [cluster cl-name]
where filer is the name of the external filer, path is the share path on the filer, and cl-name is cluster that will use filer.
Note: Execute the metadata share command twice per volume when configuring for disaster recovery: once to specify the metadata shares host at the active cluster, and again to specify the metadata host at the backup cluster. The two metadata shares need to use the same protocol.
Refer to Storing Volume Metadata on a Dedicated Share in the ARX® CLI Storage-Management Guide for complete information about metadata shares.
filer filer {nfs sharename | cifs sharename} [access-list listname] [cluster clustername]
where filer is the name of the filer that hosts the share in question, nfs sharename or cifs sharename is the share to be associated with the cluster, listname is the ACL associated with the share, and clustername is the cluster to which this configuration is relevant.
Note: Execute the filer command twice per share when configuring for disaster recovery: once to specify the shares filer at the active cluster, and again to specify the shares filer at the backup cluster.
virtual server switchname vip mask [vlan vlan-id] [cluster clustername]
Where switchname is the name of the network switch, vip is the IP address assigned to the virtual server, mask is the network subnet mask associated with that IP address, vlan-id is the VLAN on which virtual server is a node, and clustername is the cluster to which this configuration is relevant.
If you are running CIFS services with constrained delegation, some additional configuration of the domain controller will be necessary to support your CIFS clients. The back-end CIFS servers at the backup cluster must be on the delegate-to list for each front-end CIFS service. For each CIFS service, execute the probe delegate-to command to find any back-end servers that need to be added to the list, and add them at the domain controller. When complete, the CIFS services delegate-to list includes the back-end servers behind both clusters. This configuration is performed at the DC, and persists after the load-configs test.
Replication of the global configuration from the active cluster to a backup cluster is controlled by a user-configured replication task. Define the replication task using the global-config mode CLI command config-replication. This command creates a task that replicates the active ARXs global-config by a user-defined schedule to the target ARX cluster. The source ARX will use the cluster name to resolve the target ARXes from the configured target cluster. The best RON route will be used for reaching the switches in the target cluster.
Executing the config-replication command creates the config-replication object and enters gbl-cfg-repl mode. The command syntax is:
config-replication name cluster clustername
Where name is the replication task you are creating and clustername is the ARX cluster from which the global-config originates.
Use the show config-replication command to see the current status of one or more config-replication rules.
Use the show replicated-configs command to list the global configurations that have been replicated to the current ARX.
Refer to Appendix 12, Creating a Policy Schedule in the ARX® CLI Storage-Management Guide for complete information about defining and using schedules.
The privileged-exec mode CLI command load replicated-configs enables you to load all or part of a replicated global configuration. All objects are loaded in a non-enabled state, regardless of whether they were enabled in the source.
The load replicated-configs command always generates a report with all CLI output. The report name is generated automatically and includes a timestamp and the name of the replicated-config filename. The report type name is Load.
load replicated-configs filename [global-server gsname] [tentative]
Where filename is the name of the replicated configuration file and gsname is the name of the global server on which the replicated configuration will be loaded.
Note: The load command may be used to load a subset of a replicated configuration based on global-server. This is an advanced option; consult F5 technical support before attempting to use it.
After the global-config has been copied successfully to the backup cluster, you should test the use of the load configs tentative CLI command at that cluster from time to time. This performs a test load of the active clusters storage services onto the backup cluster.
The privileged-exec mode CLI command activate enables you to activate all or part of a loaded replicated global configuration. By default, the activation process enables all global servers, all of their associated CIFS and NFS services, all of their referenced volumes, and all of their referenced volume shares. By default, it does not enable volume policies; they must be enabled explicitly. The activation process activates the loaded configuration to maintain the original enable state of the loaded replicated global configuration.
The activate command provides options for enabling different portions of the loaded configuration. This enables administrators to test each portion of a loaded replicated configuration separately. In addition, the take ownership argument must be appended to the command in order to take ownership of volumes that are marked as being used by other ARXes.
The activate command always creates a report. The report includes output similar to that for the run script command. The report type name is Act.
activate replicated-configs filename [global-server gsname] [shares] [volumes] [global-servers] [take ownership] [policies] [tentative]
Where filename is the name of the replicated configuration file and gsname is the name of the global server on which the replicated configuration will be activated.
Table of Contents   |   << Previous Chapter

Was this resource helpful in solving your issue?

NOTE: Please do not provide personal information.

Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)