Overview of the switchover process
The MetroCluster switchover operation enables immediate resumption of services following a disaster by moving storage and client access from the source cluster to the remote site. You must be aware of what changes to expect and which actions you need to perform if a switchover occurs.
During a switchover operation, the system takes the following actions:
Ownership of the disks that belong to the disaster site is changed to the disaster recovery (DR) partner.
This is similar to the case of a local failover in a high-availability (HA) pair, in which ownership of the disks belonging to the partner that is down is changed to the healthy partner.
The surviving plexes that are located on the surviving site but belong to the nodes in the disaster cluster are brought online on the cluster at the surviving site.
The sync-source storage virtual machine (SVM) that belongs to the disaster site is brought down only during a negotiated switchover.
NoteThis is applicable only to a negotiated switchover.The sync-destination SVM belonging to the disaster site is brought up.
While being switched over, the root aggregates of the DR partner are not brought online.
The metrocluster switchover command switches over the nodes in all DR groups in the MetroCluster configuration. For example, in an eight-node MetroCluster configuration, it switches over the nodes in both DR groups.
If you are switching over only services to the remote site, you should perform a negotiated switchover without fencing the site. If storage or equipment is unreliable, you should fence the disaster site, and then perform an unplanned switchover. Fencing prevents RAID reconstructions when the disks power up in a staggered manner.
Availability of commands during switchover
The following table shows the availability of commands during switchover:
| Command | Availability |
|---|---|
| storage aggregate create | You can create an aggregate:
You cannot create an aggregate:
|
| storage aggregate delete | You can delete a data aggregate. |
| storage aggregate mirror | You can create a plex for a non-mirrored aggregate. |
| storage aggregate plex delete | You can delete a plex for a mirrored aggregate. |
| vserver create | You can create an SVM:
You cannot create an SVM:
|
| vserver delete | You can delete both sync-source and sync-destination SVMs. |
| network interface create -lif | You can create a data SVM LIF for both sync-source and sync-destination SVMs. |
| network interface delete -lif | You can delete a data SVM LIF for both sync-source and sync-destination SVMs. |
| lif create | You can create LIFs. |
| lif delete | You can delete LIFs. |
| volume create | You can create a volume for both sync-source and sync-destination SVMs.
|
| volume delete | You can delete a volume for both sync-source and sync-destination SVMs. |
| volume move | You can move a volume for both sync-source and sync-destination SVMs.
|
| snapmirror break | You can break a SnapMirror relationship between a source and destination endpoint of a data protection mirror. |
Differences in switchover between MetroCluster FC and IP configurations
In MetroCluster IP configurations, because the remote disks are accessed through the remote DR partner nodes acting as iSCSI targets, the remote disks are not accessible when the remote nodes are taken down in a switchover operation. This results in differences with MetroCluster FC configurations:
Mirrored aggregates that are owned by the local cluster become degraded.
Mirrored aggregates that were switched over from the remote cluster become degraded.