Installation manual

Adding a Managed Volume
Storing Volume Metadata on a Dedicated Share
9-2 CLI Storage-Management Guide
Metadata facilitates storage policies, but it requires some management. A direct
volume, described in the previous chapter, has no metadata and is therefore easier to
set up and tear down.
As explained in the namespace chapter, you use the gbl-ns
volume command to create
a volume (see “Adding a Volume” on page 7-21). This puts you into gbl-ns-vol mode,
where you configure import parameters, metadata storage, at least one share, and
several of the options discussed earlier for direct volumes.
For example, this command set creates a single volume (“/acct”) for the “wwmed”
namespace:
bstnA6k(gbl)# namespace wwmed
bstnA6k(gbl-ns[wwmed])# volume /acct
This will create a new volume.
Create volume '/acct'? [yes/no] yes
bstnA6k(gbl-ns-vol[wwmed~/acct])# ...
Storing Volume Metadata on a Dedicated Share
A managed volume stores its metadata on a reliable external share. This share, called
a metadata share, is devoted exclusively to Acopia metadata. Best practices dictate
that you use a dedicated metadata share for each managed volume. The namespace
can have a single metadata share (as described in the CLI Reference Guide) to be
divided amongst its managed volumes, but a dedicated share for each volume is
preferred.
An NFS metadata share works for either an NFS or CIFS volume. A CIFS metadata
share is not as flexible; an NFS-only volume cannot use a CIFS metadata share
because the volume does not have the required proxy-user credentials (see
“Configuring Windows Authentication (CIFS)” on page 7-14) to access a CIFS share.
It is vitally important that the external metadata share is fast, highly available, and has
multiple gigabytes of free space. A managed volume cannot function if it loses contact
with its metadata share.