Knowledge

• Identify FC SAN hardware components
  When you decide to use a SAN with you VMware environment first make sure that this particular SAN is on the Hardware Compatibility List (HCL). A SAN is build up out of several components:
  • SAN Controller
    This is the controller that controls disk, creates LUN and presents these LUNs to your ESX hosts. The controller is managed from a web based console or by using a software suite. This of course depends on you SAN vendor.
  • SAN Switches
    The SAN controller and the ESX hosts are connected by means of SAN switches. You can think of SAN switches like Ethernet switches, but they cannot be mixed, SAN switches only switch the FC protocol. Usually zoning is in place a SAN switch. Zoning creates separate segments (like VLANs when compared to Ethernet switches) the separate the devices in the fabric (a fabric is a collection of a SAN controller, SAN Switch and HBA on a single path. When using a redundant setup you usually have two fabrics, read more here.
  • Host Bus Adaptor
    Within the ESX host a Host Bus Adaptor (HBA) is used to connect to the SAN switch. Again, also the HBA has to be supported by VMware and be listed on the HCL. Configuration of SAN LUNS is done from the Virtual Center or from the command line of the ESX host.
• Identify how ESX Server connections are made to FC SAN storage
  When you have a SAN connection over two fabric and you SAN controller has two active controllers you have four paths to your storage. To combine those four to one usable path you need Multi Pathing (standard installed on ESX). This is default behaviour of many SANs including most HP EVA storage arrays. In vSphere enterprise plus you can use storage plugins from you vendor that will optimize multipathing for you. In the other editions you can do this manually. Using multipathing can improve you SAN bandwidth with factor 4 (or more / less depending on the number of path to a storage array you have).
• Describe ESX Server FC SAN storage addressing
  Storage on a FC SAN is presented to a ESX host as a LUN (Logical Unit Number). A storage array usually can present up to 256 LUNs per storage controller. When a LUN is presented to an ESX host it will be given a unique identifier existing of 4 digits separated by :. Example; 1:0:0:2. In order these digits represent: Adapter,  Channel, Target, LUN.
  To find this
  • GUI
    • Select a ESX host
    • Select the tab “Configuration”
    • Select “Storage Adaptors”
    • Select you HBA
      
      
    • Look at the “Runtime Name”
  • CLI
    • Open a Command line to you ESX server
    • Type:
      

       esxcfg-mpath –l

    • A large list of LUN details appear. Look at:
      

       Adapter: vmhba1 Channel: 0 Target: 0 LUN: 2

• Describe the concepts of zoning and LUN masking
  To hide certain LUNs from the ESX hypervisor you can use two techniques; zoning and LUN Masking
  • Zoning
    Zoning is a technique typically implemented on your SAN switches. Zoning makes segments on SAN switch that separate traffic and allows only hosts configured in that zone to see each other. Zoning is quite straight forward and allows a host based segmentation. When a host can see a storage controller it can see all LUNs presented on that storage controller to the host. No LUN based granularity is possible.
  • LUN Masking
    LUN Masking u typically implemented on the ESX server. This technique allows LUNs to be hided fromthe ESX host.
    
• Configure LUN masking
  LUN Masking is used to hide certain LUNs for the ESX hypervisor. All LUNs presented to the OS are under normal circumstances visible (assuming the LUNs are presented on the storage array). When installing ESX on a LUN you want to be sure you only see the partition you want to install ESX on, otherwise you risk overwriting valuable VMFS partition with VM’s. Hiding LUNs during installation is typically done on you storage array. To hide LUNs on ESX (not applicable during install):
  
  LUN masking has been changed since the ESX 3.x version. A new command is used: “esxcli corestorage claimrules convert”. This new command allows you to (un)hide luns and the convert the previous LUN maksing used in pre ESX 4 servers to the new format. To add a new LUN masking to need to hide the LUN on every available path to the storage controller! This means that the underlaying command line needs to be executed for every path. The command to add a LUN is:
  

   esxcli corestorage claimrule add -r <claimrule_ID> -t <type> <required_option> -P <MASK_PATH> 

  This and more examples can be found here.
  
  More information on how to migrate you existing pre ESX 4 LUN masking configuration to the new format can be found here on page 94.

• Scan for new LUNs
  When new LUNs are presented from the storage controller to ESX hosts the ESX host needs to scan for LUNs before they are visible on the system. Do to so we use the GUI:
  • Select a ESX host
  • Select the tab “Configuration”
  • Select “Storage Adaptors”
  • Select the HBA to where the new LUNs are presented
  • Click “Rescan” in the upper right corner
    
    
  • Optionally adjust where to scan for
  • Click OK to start scanning. This process van take a few minutes depending on you configuration.
    
    On ESXi, it is not possible to rescan a single storage adapter. If you rescan a single adapter, all adapters are rescanned.

• Determine and configure the appropriate multi-pathing policy
  Multipathing is a technique to optimize the usage of all paths to a storage controller. To manage storage multipathing, ESX uses a special VMkernel layer, Pluggable Storage Architecture (PSA). The PSA is an open modular framework that coordinates the simultaneous operation of multiple multipathing plugins (MPPs). You can choose to use the default build in Native Multipathing Plugin, or use a vendor procides policy.  The native pathing policies that can be used with ESX 4 are:
  • Most Recently Used (MRU)
    Selects the first working path discovered at system boot time. If this path becomes unavailable, the ESX host switches to an alternative path and continues to use the new path while it is available. This is the default policy for LUNs presented from an Active/Passive array.
  • Fixed (Fixed)
    Uses the designated preferred path, if it has been configured. Otherwise, it uses the first working path discovered at system boot time. If the ESX host cannot use the preferred path, it selects a random alternative available path. The ESX host automatically reverts back to the preferred path as soon as the path becomes available. This is the default policy for LUNs presented from an Active/Active array.
  • Round Robin (RR)
    Uses an automatic path selection rotating through all available paths and enabling the distribution of the load across the paths. For Active/Passive arrays, only the paths to the active controller will used in the round robin. For Active/Active arrays, all paths will used in the round robin. This policy is not currently supported for LUNs that are part of a Microsoft Cluster Service (MSCS) virtual machine.
    
    These only apply to VMware's Native Multipathing (NMP) Path Selection Plugins (PSP). Third party PSPs have their own restrictions.
    
    VMware does not recommend changing the LUN policy from Fixed to MRU as this policy is based on the array that has been detected by the NMP PSP.
    
    Switching to Round Robin is safe and supported for all arrays.
    

• Differentiate between NMP and third-party MPP
  The VMkernel multipathing plugin that ESX provides by default is the VMware Native Multipathing Plugin (NMP). The NMP is an extensible module that manages subplugins. There are two types of NMP subplugins
  • Storage Array Type Plugins (SATPs)
  • Selection Plugins (PSPs).
• SATPs and PSPs can be built-in and provided by VMware, or can be provided by a third party.
  If more multipathing functionality is required, a third party can also provide an Mulitple Multipathing Plugin (MPP) to run in addition to, or as a replacement for, the default NMP. A MPP is provided especially for one type of storage array by you vendor and can contain specific multipathing configurations the further improve performance.
  The multipathing modules perform the following operations:
  • Manage physical path claiming and unclaiming.
  • Manage creation, registration, and deregistration of logical devices.
  • Associate physical paths with logical devices.
  • Process I/O requests to logical devices:
  • Select an optimal physical path for the request.
  • Depending on a storage device, perform specific actions necessary to handle path failures and I/O command retries.
  • Support management tasks, such as abort or reset of logical devices.

Tools

• FC SAN Configuration Guide
• Product Documentation
• VMware vSphere Client