MetroCluster incident coordination checklist · use matching IP/FC and node-count runbook
MetroCluster has its own IP/FC topology and recovery procedures. This checklist is for assessment and coordination; use the matching NetApp procedure for the exact configuration.
About the command and output examples
Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.
01Identify configuration and failure
- Confirm MetroCluster IP or FC, node count, mediator/tiebreaker, local HA, intersite connectivity, storage health and the exact failed components.
- For planned maintenance, perform the supported simulation and prechecks. For a real disaster, establish whether the remote site can still write and follow the forced/negotiated switchover decision tree.
An approved site state and switchover type are recorded.
02Switchover and service validation
- Execute the platform-specific switchover procedure, monitoring each stage. Never run forced switchover merely because an alert appeared.
- Validate SVMs, LIF placement, SAN paths, client access, application startup order and data consistency at the surviving site.
Production is served by the expected site and no conflicting active copy exists.
03Heal and switch back
- Repair the failed site and follow the documented healing sequence. Run the supported readiness/simulation checks before switchback.
- Switch back in an approved window. Confirm both sites, aggregates, LIFs and application access return to expected states. Escalate if LIF placement or storage state is wrong.
MetroCluster is back to normal and all health checks pass.
04The topology determines the recovery procedure
This page is an assessment checklist, not a universal command sequence. Forced operations have different consequences from a planned negotiated switchover. Before a command, record the current site/failure state and select the exact supported procedure. If a previous operation failed partway, preserve the stage/error and use the recovery guidance for that state rather than restarting a generic sequence.
| Record first | Why it changes the plan |
|---|---|
| IP or FC MetroCluster and node count | Cabling, storage and supported recovery stages differ. |
| Local HA and site reachability | A node event and a site disaster are different failure scopes. |
| Mediator/tiebreaker state where used | Decision support is part of the configured architecture. |
| Which site can still write | Activation must not create competing service ownership. |
| Health and previous operation state | A partially completed recovery needs its supported continuation procedure. |
- Identify the exact deployment and collect local/remote state and client impact. Involve the network, application and vendor support owners when the failure scope is unclear.
- For a planned exercise, perform the supported readiness/simulation process and define the single active service location. Observe client transactions and SAN paths throughout the controlled change.
- For return to normal, follow the topology-specific healing and switchback requirements. Verify storage and service ownership, then test applications at both intended failure domains.
The record contains topology, approved operation type, actual stage results, measured application recovery and final normal-state evidence.
Use the section links to revisit a step, or follow a related guide below.
Official references and further reading
Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.