LUNs

A LUN (Logical Unit Number) is a logical representation of a disk
LUNs are specific to SAN protocols
The LUN is presented from the target to the initiator which gets block level 
access, the same as if it was a hard drive installed in its chassis
The LUN goes in either a volume or qtree
iSCSI Configuration Steps
1. Enable an SVM for iSCSI
2. Create aggregates, volumes and optionally qtrees to host the LUNs
3. Create iSCSI LIFs
4. Discover the target from the initiator 
5. Create sessions to the target from the initiator
6. Configure LUN masking with an Initiator Group (iGroup)
7. Create a LUN on the storage system
8. Map the LUN to the iGroup Client

9. Configure the LUN for use on the host NetApp Storage
iSCSI CHAP Authentication
For Fibre Channel, initiator access to the SAN is controlled through 
zoning on the switches.
Ethernet switches do not support zoning, so CHAP authentication 
between the initiator and target is recommended.
For one‐way CHAP, the target only authenticates the initiator. For 
mutual CHAP, the initiator also authenticates the target.
FC and FCoE
Fibre Channel and Fibre Channel over Ethernet both use FCP‐ the 
Fibre Channel Protocol
They both work exactly the same way, FCoE is Fibre Channel, just 
encapsulated in an Ethernet header to allow it to run over 
Ethernet networks
FC and FCoE
There is no separate configuration for FC and FCoE on NetApp Data 
ONTAP systems, they are both configured as Fibre Channel
They both use WWPNs for the addressing for initiators and targets
The WWPNs are assigned to FC LIFs
FC LIFs are homed on UTA2 ports configured as 2,4,8 or 16Gb native 
Fibre Channel, or 10Gb CNA
FC and FCoE Configuration Steps
1. Configure UTA2 adapters as type FC or CNA
2. Enable an SVM for FC
3. Create aggregates, volumes and optionally qtrees to host the LUNs
4. Create FC LIFs
5. Configure LUN masking with an Initiator Group (iGroup)
6. Create a LUN on the storage system
7. Map the LUN to the iGroup
Client
8. Configure the LUN for use on the host NetApp Storage
SVM SAN Identification
Each SVM appears as a separate storage system
When FC or iSCSI is enabled on an SVM, a WWNN or IQN is 
generated for it
Different SVMs will have different WWNNs or IQNs
SVM SAN Identification
The WWNN or IQN identifies the storage system as a whole, 
individual ports are identified by WWPN or IP address
WWPNs and IP addresses are not applied directly to physical ports, 
they are applied to LIF Logical Interfaces
Multiple LIFs can share the same underlying physical port
SAN LIFs
SAN Logical Interfaces:
Support either FC (and FCoE), or iSCSI
Do not support NAS 
FC and iSCSI LIFs can share underlying physical interfaces with NAS LIFs
FC LIFs have WWPNs, iSCSI LIFs have IP addresses
Are assigned a home node and port
Do not fail over
Can be moved to different ports or nodes within an SVM (LIF must be offline)
Can be grouped into port sets to control which clients can connect on which ports
SAN LIFs Best Practice
Use at least one LIF per node, per network, per SVM.

Host

Fabric A Fabric B

Node 1 Node 2 Node 3 Node 4

LUN Best Practice
LUNs can be created in Volumes or Qtrees.
Each LUN will typically be created in one of two ways:
‒ In its own dedicated volume
‒ Or multiple LUNs in dedicated Qtrees within the same volume.
Do not create LUNs in the Data SVM root volume.
For consistent Snapshot copies, NetApp recommends using SnapDrive or 
SnapManager. Turn off volume level snapshots in this case.