Users Guide

iv. Do not delete fabrics from the old lead chassis as deleting the fabrics can lead to network loss once the old lead is
added back to the network.
v. On the old lead, run a force “reset configuration” using the following REST API payload:
URI: /api/ApplicationService/Actions/ApplicationService.ResetApplication
Method: POST
Payload: {"ResetType": "RESET_ALL", "ForceReset": true}
d. Relocate the working components of the old lead to other chassis in the group:
i. Relocate network switches from the old lead to the new lead or member chassis in the group to restore the health of
the fabrics.
ii. Relocate computes from the old lead to the new lead or member chassis in the group. New templates or identities
must be deployed on the computes before resuming workloads, which they were running on the old lead chassis.
Retiring lead chassis
The "retire" option enables a backup chassis to takeover as the lead of a chassis group when the lead chassis is running for a
long time and must be removed from the production environment temporarily or permanently. The lead chassis can gracefully
detach from the group. The "retire" option also facilitates the lead to retire from the lead role but remain a member of the
group.
1. Run "retire" task from the lead chassis:
a. A job is created when the "retire" task starts. The job may be completed in 10-45 minutes based on the number of
chassis in the group and amount of configuration to restored.
b. If the lead chassis is configured to forward alerts to external destinations (email, trap, system log), any alerts that the
components in the group generate are only available locally in their respective hardware or alert logs when the retire task
and the backup taking over the lead chassis is in progress. After the "retire" task is complete and before the backup is
promoted, there is an outage in group management. The outage includes forwarding of alerts to configured external
destinations.
2. Expected behavior of backup on completion of the "retire" task:
a. The backup chassis becomes the new lead and all the member chassis are accessible as they were on the retired lead
chassis. The new lead chassis rediscovers all the members in the group and if any member chassis is inaccessible then,
the members are still listed on the Home page of the lead chassis with broken connection and available repair options.
Use the repair option to readd or remove the member chassis from the group.
b. All firmware baselines or catalogs, alert policies, templates or identity-pools, and fabrics settings are restored, as they
were on the retired lead chassis.
3. Expected behavior of old lead chassis on completion of the "retire" task:
a. If the old lead is chosen to retire as a stand-alone chassis, it continues to carry the templates/identity-pools
configuration. Perform the following steps to clear configuration to avoid conflicts with the new lead.
i. Unstack the earlier lead from the group.
ii. Reclaim any identity-pool IO identities that are deployed to computes on the old lead.
iii. Do not delete fabrics from the old lead chassis as deleting the fabrics can lead to network loss once the old lead is
added back to the network.
iv. Run a force “reset configuration” using the following REST API payload:
URI: /api/ApplicationService/Actions/ApplicationService.ResetApplication
Method: POST
Payload: {"ResetType": "RESET_ALL", "ForceReset": true}
b. If the old lead is retired as a member of the current group, it no longer carries the identity-pools configuration. However,
it contains the templates configuration. To avoid conflicts with the new lead, clear the templates configuration using
Configuration > Deploy > Delete.
110
Use case scenarios