In a NetApp SAN environment, hosts are initiators and filers are targets that have storage target devices, which are referred to as LUNs (Logical Unit Numbers). With Data ONTAP, you configure the filer's storage by creating LUNs that can be accessed by initiators.
From the host (initiator), LUNs appear as local disks on the host that you can format and manage to store data.
From the filer (target), a LUN is a logical representation of a physical unit of storage. It is a collection of, or a part of, physical or virtual disks configured as a single disk. When you create a LUN, it is automatically striped across many physical disks.
Data ONTAP manages LUNs at the block level, so it cannot interpret the file system or the data in a LUN.
A LUN serial number is a unique 12-byte filer-generated ASCII string. Many multipathing software packages use this serial number to identify redundant paths to the same LUN. For example, VERATIS DMP expects the serial number of a drive to reside in bytes 36 through 47. You display the LUN serial number with the lun show -v command.
Before you can create LUNs, you must configure the filer's storage by using the vol create command to create volumes and, optionally, the qtree create command to create qtrees if you prefer to organize and manage LUNs at the qtree level. A LUN must be created at the root level of a qtree or a volume.
The following diagram shows four LUNs that were created by using the storage from Filer_A. LUNs 0 and 1 were created at the root of the volume /vol/vol1, and LUNs 2 and 3 were created at the root of the qtree /vol/vol1/qtree1. No LUNs were created on /vol/vol0 because that is the root volume Data ONTAP uses for system administration. To summarize, the four LUNs that were created on Filer_A are as follows:
T
A LUN must have a unique LUN identification number (LUN ID) that the host requires to have access to it. You can assign a LUN ID or accept a default, depending on the method of creating the LUN. Typically, the default ID begins with 0 and increments by 1 for each additional LUN as it is created, but valid LUN ID numbers are host-dependent. The host associates the LUN ID with the location and path name of the LUN. See the HBA installation and setup guide for your specific host for best practices or guidelines on the ranges of values to use when assigning LUN IDs.
An initiator group is a collection of the unique identifiers, either iSCSI node names or WWPNs of initiators (hosts). When you create an initiator group, you give it a name so that it is easy to manage, and you specify which initiators are in the initiator group by adding their unique identifiers to it.
You use the fcp show initiator command to see the FCP unique identifiers that are registered with the Fabric Name Server directory. You use the iscsi show initiator command to see the iSCSI unique identifiers that are attached to the filer.
To know which initiators are associated with the unique identifiers, see the appropriate HBA installation and setup guide for your host. These guides describe NetApp-supplied commands to run on the host that show the mapping between the host name and its unique identifier. For example, for Windows hosts, you use the lputilnt command, and for Solaris hosts, you use the sanlun command. See the appropriate HBA installation and setup guide for host specific commands.
To continue one of the previous examples, assume you are using FCP, you have a Solaris host whose name is Host1, and you installed the initiator HBA in that host. You obtained its WWPN by one of the following methods:
You can use the igroup create command or FilerView to create an initiator group called solaris-group0 and add the WWPN of the initiator, Host1, to it.
To make the LUNs accessible to hosts, you use the lun map command or FilerView to map LUNs to an initiator group. By mapping LUNs to the hosts listed in the initiator group, you allow access to the LUNs to the specified hosts. If you do not map a LUN, the LUN is not accessible to any hosts. This effectively masks access to the LUN.
Clustered filers in a NetApp SAN environment require that the following options are enabled to guarantee that takeover and giveback occur quickly enough to not interfere with host requests to the LUNs. These options are automatically enabled when the FCP or iSCSI service is turned on.
If you have a filer cluster, there are two dual-port target HBAs in each filer chassis. Port 1 on each HBA is the primary port and normally active. Port 2 on each HBA is the secondary port, and is on standby for the partner filer. When failover occurs, port 2 becomes active.
The filer does not have iSCSI target HBAs. The iSCSI service on the filer is implemented by the iSCSI software target (iswt) driver. This is a software driver that enables the filer to function as an iSCSI target device.
There are two logical iswt drivers: iswta and iswtb. The iswta adapter controls all iSCSI traffic for the filer. The iswtb adapter is dedicated to iSCSI traffic for the partner filer. If a failover occurs and the filer is operating in takeover mode, the iswtb driver becomes active.
For information about how to set up a NetApp SAN, see the NetApp SAN Setup Overview for FCP 1.1 or the NetApp SAN Setup Overview for iSCSI 1.0.
You can issue filer commands at the filer's console or you can open a Telnet or rsh session from a host, depending on what licenses are enabled on the filer and whether there is a TCP/IP connection between the filer and the host. A network interface card (NIC) is preinstalled in the filer. For information about filer administration, see the Data ONTAP 6.4 System Administration Storage Management Guide.
Copyright © 1994-2003, Network Appliance, Inc. All rights
reserved.
Part No. 210-00338
File: c1ov3.htm
Last updated: 01/17/03 17:40:27