MultiStore is an optional software product that enables you to partition the storage and network resources of a single filer so that it appears as multiple filers on the network. Each "filer" created as a result of the partitioning is called a vFilerTM unit. A vFiler, using the resources assigned, delivers file services to its clients as a filer does.
The storage resource assigned to a vFiler can be one or more qtrees or volumes. The network resource assigned can be one or more base IP addresses or IP aliases associated with network interfaces. You can add or remove resources at any time.
Because MultiStore is an optional software product, you must enable the software license for it. The name of the license is "MultiStore."
MultiStore is typically used for the following reasons:
The following scenarios illustrate how you can use MultiStore to consolidate servers:
To consolidate the server, you can partition the filer into vFilers and then copy the data from the servers to the vFilers. If the vFilers are for CIFS users, you can set up the vFilers to use the same computer names as the servers. This enables CIFS clients to share resources without having to remap their drives or search for the new server in Network Neighborhood. If the vFilers are for NFS users, the NFS clients might need to remount the file systems, or they can use the automounter to automatically mount the file systems from the new locations.
Service providers, such as Internet service providers (ISPs) and storage service providers (SSPs), can partition the resources of a filer to create many vFilers for client companies. Similarly, the information technology (IT) department of an enterprise can create vFilers for various organizations, or customers, within the enterprise.
The administrator for each customer can manage and view files only on the assigned vFiler, not on other vFilers that reside on the same filer. In addition, there is no data flow between vFilers. A customer using a vFiler can be assured that no sensitive information is exposed to other customers that store data on the same filer.
For example, an SSP can create the following vFilers on a filer:
Although both CompanyA and CompanyB store data on the same filer, network traffic for each company is restricted to the specified interface. The administrator at CompanyA, which uses NFS to access data, cannot use the showmount command on a UNIX client to view directories on the filer that are outside the /vol/vol1 volume. Similarly, the administrator at CompanyB, which uses CIFS to access data, cannot browse the shares that are outside the /vol/vol2 volume.
See Chapter 3 for a more detailed discussion.
MultiStore enables you to migrate data from one filer to another without extensive reconfiguration on the destination filer.
If you did not have MultiStore, you could use SnapMirror to copy data from one filer to another, but you would then need to edit the files' access control lists (ACLs), local user group definitions, user mapping information, and so on, before users could access the data. If the data being copied is stored on a vFiler, however, all user, group, and ACL information is encapsulated in the vFiler. You re-create a vFiler on the destination filer with the encapsulated information, and data can be served from the destination filer without further reconfiguration.
The filer on which you create vFilers is called the hosting filer. The storage and network resources used by the vFilers exist on the hosting filer.
Licensing MultiStore automatically causes Data ONTAP to create a default vFiler on the hosting filer. The name of the default vFiler is vFiler0.
Initially, vFiler0 owns all the resources on the filer. After you create vFilers, vFiler0 owns the resources that are not owned by the vFilers you create.
The default vFiler exists as long as the vFiler license is enabled. On a filer with the vFiler license enabled, you cannot destroy vFiler0.
All information provided in this guide about vFilers is applicable to vFiler0, unless noted otherwise.
MultiStore has the following limitations:
A filer containing the maximum number of vFilers actually has 33 vFilers: vFiler0 plus the 32 vFilers that you, the system administrator, can create.
See Adjusting the vFiler limit for more information.
You, as the hosting filer administrator, do not have administrative, CIFS, or NFS access to the data owned by vFilers (other than the default vFiler, vFiler0). After you assign a qtree or volume to a vFiler, you lose access to the data in that qtree or volume.
Before you create a vFiler with the /vol/vol1 volume, you can configure the /etc/exports file so that you can mount the /vol/vol1 volume. After you create the vFiler, an attempt to mount the /vol/vol1 volume from the hosting filer results in the ".../vol/vol1 belongs to vFiler A, can't mount from vol0" error message.
To regain administrative control of storage owned by a vFiler, see Administering vFiler resources from the hosting filer.
A filer named toaster has the vFiler license enabled and is configured with three volumes, which are /vol/vol0, /vol/vol1, and /vol/vol2.
Because the vFiler license is enabled, a default vFiler, vFiler0, is created on toaster.
On toaster, you can create a vFiler named vFiler1. You can assign the IP address 123.123.123.1, the qtree /vol/vol0/qtree1, and the volume /vol/vol1 to vFiler1. Traffic destined for vFiler1 uses the IP address 123.123.123.1, and all data served by vFiler1 is stored in the assigned qtree and volume.
If /vol/vol0/qtree1 is the first path specified for vFiler1 on the vfiler create command line, this qtree becomes vFiler's primary storage, containing the vFiler's /etc directory.
Toaster is the hosting filer for vFiler1. vFiler0 uses all the IP addresses created on toaster except 123.123.123.1. It uses the following resources for storage:
From the point of view of CIFS clients, the root of the primary storage qtree (/vol/vol0/qtree1 in our example) is the root ("/")of vFiler1's file system. If "/" is shared, a CIFS client mapping to it can browse all of vFiler1's storage (all of /vol/vol0/qtree1and /vol/vol1 in this example) in a single tree. Network Appliance calls this mechanism the vFiler's "pseudo-root."
Note
Pseudo-root directories are not available to NFS clients. NFS clients must import discrete storage units as they are defined on the hosting filer. In this example, NFS clients needing access to all of vFiler1 storage must import /vol/vol0/qtree1 and /vol/vol1 separately, and will not see a tree connecting them. But administrators of NFS clients can see a list of all of the storage units owned by a vFiler in the vFiler's /etc/vfilerstorage file.
For more information, see How to specify path names for NFS exports or CIFS shares.
Copyright © 1994-2003, Network Appliance, Inc. All rights
reserved.
Part No. 210-00475
File: intro2.htm
Last updated: 11/24/03 16:11:41