Wednesday, July 6, 2016

New PowerShell function to setup a iSCSI target on a NETAPP and mount it on Windows

I don't often use my NETAPP controllers as iSCSI targets. Most of the time I just export NFS (especially to host VMWare datastores) or CIFS and that suffices my needs. Sometimes however I am asked to mount on Windows Servers disks from the NETAPP directly on startup and not just as simple shares mounted with logon scripts or whatever.
So I decided to write a pretty do-it-all PowerShell function that does all the work of configuring the NETAPP and mounting the disk via iSCSI on my server.
If I had to do this via the OnCommand GUI, I should first setup an aggregate, then a volume, then a LUN, configure the iGroup and only then move to my Windows server and manually bind the initiator with the target.
Fortunately back in 2010 NETAPP released a module (inside the NetApp PowerShell Toolkit) to do all this stuff and more. Today you need to grab at least version 1.5 to get all the cmdlets I used in my function. Personally I have the last version (which is 4.2) which can bo downloaded here.


Concerning the requirements, the script must run on the Windows Server that acts as initiator. On that server you have to be running at least version 3.0 of Windows PowerShell and to have the DataONTAP module installed.
The Windows Server that acts as initiator will run my function that
  • configures the storage controller
  • setup the target
  • setup the initiator
  • do the mapping with the LUN in a iGroup.
Once the function has finished configuring the iSCSI disk, you just have to initialize it in Disk Management, format it and assign a letter. I already showed you how to do this in PowerShell, just search my blog.

Enough said: here's the function Mount-NAiSCSIDisk.

Just one last quick note: I am going to work on this function to improve it, so please, post suggestions or ideas in the comments below! And, for sure, share!

#Requires -Version 3.0 -Modules DataONTAP

function Mount-NAiSCSIDisk
        <#
        .SYNOPSIS
            Setup and mounts a NetApp iSCSI LUN to a Windows Server
 
        .DESCRIPTION
            Setup an aggregate, a volume, a LUN, an iGroup then mounts it as a NetApp iSCSI target to a Windows Server
             
        .PARAMETER NaController
            Name of the NetApp controller

        .PARAMETER Aggregate
            Name of the aggregate

        .PARAMETER DiskCount
            Number of disks in the aggregate
            
        .PARAMETER Volume
            Name of the volume

        .PARAMETER VolumeSize
            Size of the volume

        .PARAMETER SnapshotReserveSize
            Size of the snapshot reserve

        .PARAMETER LUNPath
            Path of the LUN

        .PARAMETER LUNType
            Type of the LUN

        .PARAMETER LUNSize
            Size of the LUN

        .PARAMETER Igroup
            Nq;e of the Igroup

        .PARAMETER IgroupProtocol
            Protocl for the Igroup
            
        .PARAMETER IgroupType
            Type of the Igroup

        .EXAMPLE
            Mount-NAiSCSIDisk -NaController netapp1 -Igroup igroup1 -IgroupProtocol iscsi -IgroupType windows
            
        .EXAMPLE
            Mount-NAiSCSIDisk -NaController netapp1 -Aggregate aggr1 -DiskCount 32 -Volume vol1 -VolumeSize 10g -SnapshotReserveSize 0 -LUNPath /vol/NA1/iscsivol1 -LUNSize 1g -LUNType windows -Igroup igroup1 -IgroupProtocol iscsi -IgroupType windows

        .AUTHOR
            happysysadm.com - Carlo MANCINI

        #>
    {
    param(
        [Parameter(Mandatory)][string]$NaController,
        [string]$Aggregate,
        [string]$DiskCount,
        [string]$Volume,
        [string]$VolumeSize,
        [string]$SnapshotReserveSize,
        [Parameter(Mandatory)][string]$LUNPath,
        [string]$LUNSize,
        [string]$LunType,
        [Parameter(Mandatory)][string]$Igroup,
        [Parameter(Mandatory)][string]$IgroupProtocol,
        [Parameter(Mandatory)][string]$IgroupType
        )
    
    write-verbose 'Started'
    
    $Error = $False

    $info = @()

    $infolastonline = @()

    Write-Verbose 'Connect to NaController'

    try {
    
        Connect-NaController $NaController -ErrorAction Stop

        }

    catch {

        Write-Warning 'Unable to connect to the controller'

        }

    write-verbose 'Starting the configuration on the netapp controlller'
    
    if(Get-NaAggr $Aggregate) {

        Write-Verbose 'Creating the aggregate'
        
        New-NaAggr $Aggregate -Use64Bit -DiskCount $DiskCount

        }

    else {

        Write-Verbose 'Aggregate already existing'

        }

    if(Get-NaVol $Volume) {

        Write-Verbose 'Creating the volume'

        New-NaVol $Volume -Aggregate $Aggregate $VolumeSize

        Write-Verbose 'Setting the snapshot reserve'

        Set-NaSnapshotReserve $Volume $SnapshotReserveSize

        }

    else {

        Write-Verbose 'Volume already existing'

        }

    if(Get-NaLun $LUNPath) {
    
        Write-Verbose 'Creating the LUN'
    
        New-NaLun -Path $LUNPath -Size $LUNSize -Type $LunType

        }

    else {

        Write-Verbose 'LUN already existing'

        }
    
    Write-Verbose 'Starting the iSCSI configuration'
    
    Write-Verbose 'Adding the storage controller to the iSCSI Initiator target portals'

    Add-NaHostIscsiTargetPortal

    Write-Verbose 'Establishing a connection to the target discovered by the iSCSI Initiator'

    Get-NaHostIscsiTarget (Get-NaIscsiNodeName) | Connect-NaHostIscsiTarget

    Write-Verbose 'Creating a new initiator group'

    New-NaIgroup $Igroup $IgroupProtocol $IgroupType

    Write-Verbose 'Adding the initiator the the initiator group'
    
    Get-NaHostIscsiAdapter | Add-NaIgroupInitiator $Igroup

    Write-Verbose 'Mapping the LUN to the initiators in the initiator group'

    Add-NaLunMap $LUNPath $Igroup

    }

Monday, July 4, 2016

Measuring IOPS part 4: binding IOMETER results to DISKSPD results

In the previous post we have seen that Diskspd can provide us with a quick information on MB/s and I/O per second (IOPS), as well as the average latency.
For the moment we have no idea if the 39k IOPS measured in the first sequential read test or the 710 total IOPS measured in the last random read and write test are good or bad result compared to the workload I have generated. The only thing that we have found for sure is that latency decreases when we use small IOs instead of large IOs. But we still don’t know if a latency of 5 ms, such the one measured in the last run, is a fancy value or not.
We need to investigate further the other Diskspd options. But before we do that we have to build a dictionary of what is measured with IOMETER and see the corrisponding terms used by DISKSPD.
BINDING IOMETER RESULTS TO DISKSPD RESULTS

If I look in the Diskspd help, and I try to reproduce the variables of IOmeter, I can build the following table of matches:

  • IOMETER Transfer request size = DISKSPD -b parameter, described as ‘Size of the IO in KB
  • IOMETER Percent Read/Write Distribution = DISKSPD –w, described as ‘Percentage of writes
  • IOMETER Percent Random/Sequential Distribution = DISKSPD –r, which forces Random operations
  • IOMETER # of Outstanding I/Os = DISKSPD –o, described as ‘Outstanding IOs or queue depth (per thread)
At this moment we have no idea of what kind of workload we have to generate to get meaningful results that can help me assess storage performance, and Jose Barreto himself states that we have to experiment with the –t and the –o parameter until we find the combination that gives the best results.

Now guess which tool I am going to use to automate this task in the next post of this series: PowerShell! Stay tuned!

Related Posts Plugin for WordPress, Blogger...