Understanding LUNs on a vFiler unit

What LUNs are

Logical Unit Numbers (LUNs) are portions of storage system storage that, when exported, look and act to the importing host like local disks. (They are sometimes referred to as "virtual disks.") Data on a LUN can be managed at the block level (for example, by a database manager) as well as at the file level. A LUN is the basic unit of storage in a Storage Area Network (SAN).

What is supported on a vFiler unit

Data ONTAP allows you to create and manage a separate set of iSCSI LUNs and initiator groups (igroups) on each vFiler unit. For detailed information about iSCSI LUNs, see the Block Access Management Guide.

What is not supported on a vFiler unit

Fibre Channel Protocol (FCP) LUNs are supported only on the hosting storage system, not on a vFiler unit. For detailed information about FCP LUNs, see the Block Access Management Guide. This means

You can create FCP igroups only on the hosting storage system.
FCP-connected hosts can access only those LUNs that are owned by the hosting storage system.
The fcp command does not recognize vFiler units.
You can create only iSCSI igroups on vFiler units; you cannot create FCP igroups on vFiler units.

iSCSI LUNs and igroups on a vFiler unit

From the point of view of a host importing LUNs, a vFiler unit looks and acts just like a storage system; administrators of those hosts normally do not even need to be aware that the LUN resides on a storage unit owned by a vFiler unit. But you, as the vFiler unit or hosting storage system administrator, need to be alert to some special considerations.

Be aware of the following points when you manage LUNs on a storage system on which a MultiStore license is enabled:

You must create and manage LUNs from the vFiler unit that owns the storage unit that contains the LUNs.
For instructions for switching the console to the context of a vFiler unit, see Executing commands and setting options for a vFiler unit.
A vFiler unit is aware only of those LUNs in the storage units it owns. When executed on a vFiler unit, the lun show command displays only that vFiler unit's LUNs.
Ownership of LUNs changes with the ownership of the storage unit that contains the LUNS.
LUNs must be unmapped before the storage unit containing them can be moved. This means you must unmap all affected LUNs before doing any of the following:
- Assigning storage that contains LUNs to a vFiler unit, either when you create the vFiler unit or later
- Destroying a vFiler unit that owns storage containing LUNs
- Moving storage that contains LUNs from one vFiler unit to another, or between a vFiler unit and the hosting storage system
If you try to move a storage unit without unmapping the LUNs it contains, the operation fails. See the appropriate Block Access Management Guide for instructions for unmapping LUNs.

Note
You do not need to unmap LUNs when you migrate a vFiler unit or replace it for disaster-recovery purposes. For more information, see Chapter 6, Disaster Recovery and Data Migration.
igroups are owned by the vFiler unit on which they are created.
As with LUNs, a vFiler unit is aware only of those igroups that it owns. When executed on a vFiler unit, the igroup show command displays only that vFiler unit's igroups.
LUNs must be mapped to igroups owned by the vFiler unit that owns the LUNs.
Each vFiler unit has its own name space for LUNs and igroups.
- igroups on different vFiler units can have the same initiator.
- LUNs on different vFiler units can have the same LUN ID.
When you migrate a vFiler unit or replicate it for disaster-recovery purposes, LUNs owned by the vFiler unit are also migrated or replicated, along with their maps, igroups, and iSCSI configuration (the node names and the state of the iSCSI service). However, iSCSI authentication is not migrated or replicated.
For more information, see Chapter 6, Disaster Recovery and Data Migration.

The iSCSI service on a vFiler unit

In general, the iSCSI service operates on individual vFiler units, treating them as though each were a physical storage system. But the iSCSI software adapter itself (iswt), and the commands that manage and report on it and the underlying network interface cards (NICs), operate on the hosting storage system. This is because an iSCSI adapter on a storage system has only one identity (there are no vFiler unit-specific adapter names) and so there is only one set of iSCSI sessions and statistics.

This section lists what is storage system-based and what is vFiler unit-based. For more information on the iSCSI service, see the Block Access Management Guide.

The following items are based on the hosting storage system:

The iswt command, which you use to manage the iSCSI service on the storage system's NICs, operates on the hosting storage system, not on individual vFiler units. The iswt driver allows the storage system to be accessed as an iSCSI target device over the storage system's standard network interfaces.
If iSCSI is licensed on the hosting storage system, the iSCSI service is started by default during vFiler unit setup.
Although most iSCSI subcommands operate specifically on each vFiler unit on which they are executed, the iscsi stats command displays statistics by hosting storage system and iSCSI adapter.

The following group is based on the individual vFiler unit:

The iSCSI protocol can be allowed and disallowed, and the iSCSI service can be started and stopped, for each vFiler unit.
The adapter is online or offline for each vFiler unit, depending on whether the iSCSI service is running or stopped on that vFiler unit.
Each vFiler unit has its own iSCSI node name, which includes the vFiler unit's UUID.
Portal groups are defined for each vFiler unit.
iSCSI subcommands operate specifically on each vFiler unit on which they are executed, except for the iscsi stats command.
You configure iSCSI security separately for each vFiler unit.
This includes setting the default authentication mode: none, deny, or Challenge Handshake Authentication Protocol (CHAP). For more information abut CHAP, see the Block Access Management Guide.
- In the case of CHAP, there is a separate list of initiators and passwords for each vFiler unit.
You can configure iSNS (iSCSI's naming service) separately for each vFiler unit.
Specifically, you can use iscsi isns subcommands on each vFiler unit to
- Configure which iSNS server to use
- Turn iSNS registration on or off
On creation, a vFiler unit's iSNS configuration is in the UNCONFIGURED state, no matter what the state is on the hosting storage system.

For more information, see the na_iscsi man page.