KNOWLEDGE

• Describe methods to secure access to virtual disks and related storage devices
  • Distributed Lock Handling
    Each ESX server uniquely owns a VM when it is running. VMFS provides the distributed lock management that arbitrates access, allowing each VM and ESX server to share the clustered pool of storage. This principle facilitates VMotion, HA and DRS. Each VM on a pool of storage can run on different ESX servers.
• Identify tools and steps necessary to manage replicated VMFS volumes
  Replication creates full copies of LUNs. Replicas are usually made to separate storage systems, possibly to separate sites to protect against major outages that incapacitate or destroy an entire storage system or site. This functionality is usually offered by the storage solution. Replication can be done in realtime (synchronous or asynchronous write to a second storage array)or via a copy of a LUN based point in time snapshot.
  • Resignaturing
    VMFS-3 volumes uses a unique identifier (a UUID) in the Logical Volume Manager (LVM) that "signs" the volume. It's a long 16 character hexadecimal value that we can look up in the directory /vmfs/volumes with a ls -al. When another ESX Server scans the SAN and finds a LUN with a VMFS-3 filesystem, it compares the data from the SCSI disk ID information returned from the LUN/storage array with the data currently stored in the LVM header Metadata. When these values are different the LUN will be treated as a snapshot by the VM kernel. To make the LUN usable for the second ESX hosts that thinks the LUN is a snapshot the LUN must be resigned. This process is disabled by default. To enable resignaturing of LUNs the value for LVM.EnableResignature must be changed to on. This can be done via the GUI or the CLI.
    
    From the ESX San guide:
    Understanding Resignaturing Options
    This section discusses how the EnableResignature and DisallowSnapshotLUN options interact and explains the three states that result from changing these options:
    • State 1: EnableResignature=0, DisallowSnapshotLUN=1 (the ESX Server 3.xdefault)
    • State 2: EnableResignature=1 (DisallowSnapshotLUN is not relevant)
    • State 3: EnableResignature=0, DisallowSnapshotLUN=0 (ESX Server 2.x behavior)
  • State 1: EnableResignature=0, DisallowSnapshotLUN=1 (default)
    In this state:
    You cannot bring snapshots or replicas of VMFS volumes made by the storage system into the ESX Server host regardless of whether the ESX Server has access to the original LUN.
    LUNs formatted with VMFS must have the same ID for each ESX Server host.
    State 1 is the safest state but:
    If you use Clariion AX100i or AX150i with Navisphere Express, you cannot configure the same LUN ID across storage groups. You must instead use a version of Navisphere software that has more comprehensive management capabilities.
    For IBM TotalStorage 8000, if you have LUNs that are not configured to present the same LUN ID to all servers, you need to either use the settings in state 3 or recreate the LUNs from scratch.
  • State 2: EnableResignature=1, (DisallowSnapshotLUN is not relevant)
    In this state:
    You can safely bring snapshots or replicas of VMFS volumes into the same servers as the original and they are automatically resignatured.
    VMFS volumes containing LUNs from AX100i or AX150i that are not presented with the same LUN numbers to all servers effectively lose the ability to use the virtual machines stored on that VMFS volume. Avoid this situation.
  • State 3: EnableResignature=0, DisallowSnapshotLUN=0
    This is similar to ESX Server 2.x behavior. In this state the ESX Server assumes that it sees only one replica or snapshot of a given LUN and never tries to resignature. This is ideal in a DR scenario where you are bringing a replica of a LUN to a new cluster of ESX Servers, possibly on another site that does not have access to the source LUN. In such a case, the ESX Server uses the replica as if it is the original. If you have an AX100i or AX150i that cannot be configured to present the same LUN numbers to all servers for some reason, you need this setting to allow all ESX Server systems to use the same LUNs for features like VMotion, VMware DRS, and VMware HA. Do not use this setting if you are bringing snapshots or replicas of a LUN into a server with access to the original LUN. This can have destructive results including:
    
    • If you create snapshots of a VMFS volume one or more times and dynamically bring one or more of those snapshots into an ESX Server, only the first copy is usable. The usable copy is most likely the primary copy. After reboot, it is impossible to determine which volume (the source or one of the snapshots) is usable. This nondeterministic behavior should be avoided.
    • If you create a snapshot of a spanned VMFS volume, an ESX Server host might reassemble the volume from fragments that belong to different snapshots. This can corrupt your file system.
  • Snapshot LUNs
    Allows snapshot VMFS-3 Volumes to be seen by a different ESX host. This can be usefull when storage data is replicated from the primary site to a secondary site that is used for disaster recovery.
    You can present a snapshot VMFS-3 volumes to a different ESX Server host using 2 options
    
    - EnableResignature
    - DisallowSnapshotLUN
    
    To allow snapshot LUNs, set LVM.EnableResignature to 0 & LVM.DisallowSnapshotLUN to 0
    Do not use DisallowSnapshotLUN to present snapshots back to same ESX server as the original LUN.
    Unpredictable results can occur since you will have 2 LUNs with the same UUID so LVM.EnableResignature will have to be used to make the volume located on a replicated LUN visible to the same ESX server. Last but no least, LVM.EnableResignature overrides LVM.DisallowSnapshotLUN.
• Understand how to configure physical storage adapter properties
  TODO

SKILLS AND ABILITIES

• Configure storage network segmentation
  • FC Zoning
    Zoning is a SAN technique to separate hosts and storage devices into one or more logical segments. This can be used to isolate a ESX host or create separate zones for each ESX server and the storage device. Zoning works on a per device basis, not a per LUN basis. This means the once a ESX server and a storage device like an HP EVA are placed into one zone, all LUN presented to the WWN address of the ESX host are visible on this host. Zoning does not influence the number of LUNs presented to the host. How zoning is arranged depends on the SAN switches used to connect the servers and the storage devices together. There are many brands who build these SAN switches like Cisco and Broccade, mostly with their own operating system.
  • iSCSI/NFS VLAN
    A VLAN is a Virtual LAN. The essence of a virtual LAN is to act like a switch, but a virtual LAN can span many switches together with other VLANs. For storage over IP like iSCSI and NFS a separate VLAN can be created to separate host en guest traffic from the storage traffic. This creation must be done of the Network devices (end to end) and the VLANs must be configured on the ESX server. Gererally a 802.1q VLAN truck is configured on a Ethernet interface allowing VLANs to reach the ESX server. The ESX server creates a Virtual Switch per VLAN. For iSCSI and NFS a VMkernel port must be created within a Virtual Switch.
    
    This can be done in the GUI or on the CLI with the following commands:
    

    esxcfg-vswitch –a 				- to create the VSwitch
    esxcfg-vswitch -L vmnic1 			- to add a physical NIC
    esxcfg-vswitch -A "Service Console" 		– to add the service console 

• Configure LUN masking
  • Storage device
    The Disk.MaskLUNs parameter allows you to mask specific LUNs on specific HBAs. Masked LUNs are not touched or accessible by the VMkernel, even during initial scanning. Use this option to prevent the ESX Server system from accessing some iSCSI LUNs without the storage system's masking mechanisms. To Change via the GUI:
    - In the VI Client inventory panel, select the host, click the Configuration tab andclick Advanced Settings.
    - Select Disk.
    - Scroll down to Disk.MaskLUNs, change the existing value to the value of your choice, and click OK.
    CLI:
    

    esxcfg-advcfg –s :: /Disk/MaskLUNss

  • Host
    TODO
• Configure iSCSI/NFS security options
  TODO
• Use esxcfg-advcfg
  • Set Resignaturing and Snapshot LUN options
    CLI:
    

    esxcfg-advcfg -s /LVM/EnableResignature 
    esxcfg-advcfg -s /LVM/DisallowSnapshotLUN

  • Set ESX Server host-side disk options
    TODO
• Manage RDMs in a replicated environment
  RDM files contain metadata used to manage and redirect disk accesses to the physical device. Employing RDMs provides the advantages of direct access to a physical device while keeping some advantages of a virtual disk in the VMFS file system. In effect, the RDM merges VMFS manageability with raw device access. VMware VMotion, VMware DRS, and VMware HA are all supported in both RDM physical and virtual compatibility modes. With RDMs, there is no way to break up the LUN and address it as anything more than a single disk for a given VM. When LUNs, including RDMs, are replicated to another site the RDM must be recreated due to SCSI or LUN ID changes.
  
  This can be done via the CLI. To recreate the RDM use the command:
  

  vmkfstools -r /vmfs/devices/disks/vmhbaX:Y:Z:0 foo-rdm.vmdk 

  Default the RDM will be create in Vritual Compatibility mode. You can change this to Phisical Compatability mode by editing the vmdk file and change the "createType" value to
  

  createType="vmfsPassthroughRawDeviceMap"

  • Virtual compatibility mode
    Virtual compatibility mode allows a mapping to act exactly like a virtual disk file, including the use of storage array snapshots.
  • Physical compatibility mode
    Physical compatibility mode allows direct access of the SCSI device, for those applications needing lower level control.
• Use proc nodes to identify driver configuration and options
• Use esxcfg-module
  TODO
  • Modify storage adapter settings
  • Identify and load/unload modules
  • Get module status

TOOLS

• VI client
• CLI
  • esxcfg-advcfg
  • esxcfg-module