Installation manual

Adding a Managed Volume
Storing Volume Metadata on a Dedicated Share
CLI Storage-Management Guide 9-5
Designating the Metadata Share as Critical (optional)
If the current switch has a redundant peer, you have the option to designate the
volume’s metadata share as critical. Skip to the next section if this switch is not
configured for redundancy.
If the volume software loses contact with its metadata share, the ARX initiates a
failover. The failover is accepted by the redundant peer as long as the peer has full
access to all critical shares, critical routes, critical metadata shares, and the quorum
disk. If the peer is unable to access any of these critical resources, no failover occurs.
(For instructions on configuring critical routes, refer to “Identifying a Critical Route”
on page 6-15 of the CLI Network-Management Guide.)
If the switch has a redundant peer, we recommend that you use this option for all
managed volumes. Without metadata, the managed volume cannot function.
From gbl-ns-vol mode, use the
metadata critical command to designate the current
volume’s metadata share as a critical resource:
metadata critical
For example, this command sequence designates the metadata share as a critical
resource for the “nemed~/acctShdw” volume:
prtlndA1k(gbl)# namespace nemed
prtlndA1k(gbl-ns[nemed])# volume /acctShdw
prtlndA1k(gbl-ns-vol[nemed~/acctShdw])# metadata critical
prtlndA1k(gbl-ns-vol[nemed~/acctShdw])# ...
Removing Critical-Resource Status
By default, metadata shares are not critical. If the managed volume loses contact with
its metadata share in this case, the volume fails and the switch does not initiate a
failover. This is not recommended for redundant switches. For non-redundant
switches, it is the only option.
From gbl-ns-vol mode, use the
no metadata critical command to make the metadata
share non-critical for the current volume:
no metadata critical
For example: