The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter contains the following topics:
At some time during normal operations of your Crosswork Network Controller cluster, you may find that you need to recover the entire system. This can be the result of one or more malfunctioning nodes, one or more malfunctioning services or applications, or a disaster that destroys the hosts for the entire cluster.
This section explains the steps needed to perform to recover your geo redundant clusters.
This topic explains the recovery steps that must be executed when the active cluster is destroyed.
|
Step 1 |
Switch the standby cluster to become the new active cluster. If using manual arbitration, perform the switchover manually. If using automatic arbitration, the standby cluster becomes the new active cluster automatically. For more information, see Geo Redundancy Switchover. |
|
Step 2 |
Re-deploy the destroyed cluster (the old active cluster, which will now become the standby cluster) with the same IP and Virtual IP (VIP) addresses. |
|
Step 3 |
Install the same version of applications as the new active cluster. |
|
Step 4 |
Enable pairing mode in the new active cluster. For more information, see Enable Geo Redundancy. |
|
Step 5 |
Edit the Cross Cluster inventory file (.yaml) to reflect the current state of the Cross Cluster after the switchover in step 1. |
|
Step 6 |
On the Geo Redundancy window of the old active cluster (now standby), click Browse and upload the edited inventory file (.yaml file). |
|
Step 7 |
Enable geo redundancy on the old active cluster (now standby). For more information, see Enable Geo Redundancy. |
|
Step 8 |
Enter the Cross Cluster settings on the old active cluster (now standby) as per the settings on the new active cluster. Alternatively, you can enable the Apply the same configuration to peer cluster checkbox for the Cross Cluster settings on the new active cluster, and save the settings. |
|
Step 9 |
On the Cross Cluster window, synchronize data to ensure the old active cluster (now standby) pulls data from the new active cluster. |
|
Step 10 |
(Optional) Switch the standby cluster to become the new active cluster if needed. |
This topic explains the recovery steps that must be executed when the standby cluster is destroyed.
|
Step 1 |
Deploy the new standby cluster (to replace the destroyed standby cluster) with the same IP and Virtual IP (VIP) addresses. |
|
Step 2 |
Install the same version of applications as the active cluster. |
|
Step 3 |
Enable pairing mode in the active cluster. For more information, see Enable Geo Redundancy. |
|
Step 4 |
Enable geo redundancy on the new standby cluster. For more information, see Enable Geo Redundancy. |
|
Step 5 |
Enter the Cross Cluster settings on the new standby cluster as per the settings on the active cluster. Alternatively, you can enable the Apply the same configuration to peer cluster checkbox for the Cross Cluster settings on the active cluster, and save the settings. |
|
Step 6 |
On the Cross Cluster window, synchronize data to ensure the new standby cluster pulls data from the active cluster. |
Feedback