Manual Chapter :
ARX Disaster Recovery
Applies To:
Show Versions
ARX
- 6.3.0
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
Validate Wrapping Password: an0ther$ecretpw
For detailed information about using this command, refer to the show master-key description in the ARX CLI Reference.
| 1. | Use the copy running-config command to copy the entire running configuration (network-level parameters, not storage parameters) into a file on the chassis. |
| 2. | 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. |
| 4. | 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. |
| 6. | 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.
Where name is the cluster you are defining, and switch-name is the name of an individual ARX that will belong to the cluster.
To change an existing cluster name, you must remove the cluster name from the global configuration first. Use the remove cluster-config command in privileged exec mode to do this.
remove cluster-config clustername
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.
In order for all client data to be accessed reliably and transparently by the ARXes at both sites, the filers at the backup clusters site must be included in the active clusters configuration. (This is part of the global configuration that is in turn replicated from the active site to the backup site.) For complete instructions for doing this, refer to the ARX® CLI Storage-Management Guide, Appendix 6, Adding an External Filer.
For example, the following commands show the addition to the Providence configuration of two filers at the Newport site, named nwpt and npt2. The name and IP address of each is specified, along with a brief description, the management protocol to be used, and the proxy user ID for each. In addition, snapshot support is configured for each. The exit command at the end of each command sequence quits gbl-filer mode.
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:
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:
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.
For each managed volume share configuration, you need to define per site configuration. For each ARX share, a filer and share can be configured per cluster. Assign the shares to a filer and cluster using the filer command. The command syntax is:
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.
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:
Where name is the replication task you are creating and clustername is the ARX cluster from which the global-config originates.
For example, the following command sequence specifies an ARX administrative user named admin with a password of acopia; the target filename is provSvcs.rcfg, and it is replicated according to the schedule named oncePerDay to the target cluster newport. Additional commands name the prefix of the replication report and define a textual description of the replication object. The enable command puts the replication task into effect.
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.
| 1. | Disable the replication of the ARX global configuration by executing the no enable command in gbl-cfg-repl mode. |
| 2. | Halt the active ARX clusters front-end services if the active cluster is still viable. Do this by executing no enable for each CIFS/NFS service and for the global server. |
| 5. |
| 7. |
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.
If there are conflicting objects in the global configuration, the objects that exist already in the switch will take precedence. Conflict resolution is described in detail in Conflict Resolution For Replicated Configurations.
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.
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.
Note: Executing this command by specifying a filename without any additional arguments will enable all shares, volumes, and global-servers by default. In order to activate policies, the policies option must be specified explicitly.
