This post is a part of the nine-part “What’s New in Windows Server & System Center 2012 R2” series that is featured on Brad Anderson’s In the Cloud blog. Today’s blog post covers iSCSI Target Server and how it applies to the larger topic of “Transform the Datacenter.” To read that post and see the other technologies discussed, read today’s post: “What’s New in 2012 R2: IaaS Innovations.”
iSCSI Target Server made its first in-box appearance in Windows Server 2012 as a feature, from being a separate downloadable in prior releases. Now in Windows Server 2012 R2, iSCSI Target Server ships with two sets of very cool feature enhancements (technically, note that this blog post applies specifically to Windows Server 2012 R2 Preview and is subject to change in future releases).
At the high-level, the two sets of enhancements are:
- Virtual Disk Enhancements: Larger, resilient, dynamically-growing SCSI Logical Units (LUs) on iSCSI Target Server
- Manageability Enhancements: Private and Hosted Cloud management using SCVMM and iSCSI Target Server-based storage
Let us go into more detail on each of these below. My objectives with this blog post are two: to help you become familiar with new functionality, and to make you comfortable to quickly using the new iSCSI Target Server hands-on.
Virtual Disk Enhancements
Overview
Let’s start with a quick recap of what a Windows Server iSCSI Target ‘Virtual Disk’ is. Most of you may already remember that the iSCSI Target Server implementation calls its inventory of storage units as “Virtual Disks” – when these Virtual Disks are provisioned and then assigned to an iSCSI Target, the disks become accessible to iSCSI initiators as ‘SCSI Logical Units’ (LUs). iSCSI Target Server administrator can of course control access to the iSCSI Target to allow only certain iSCSI initiators to access it. Application-consistent snapshots are easy to take with the VSS provider that installs on the initiator side. Finally, the administrator can also create multiple iSCSI Targets under the same iSCSI Target Server. Here then is a quick reference to all these steps:
- Provisioning a new iSCSI Virtual Disk: New-IscsiVirtualDisk
- Assigning an iSCSI Virtual Disk to an iSCSI Target: Add-IscsiVirtualDiskTargetMapping
- Configuring access controls on the iSCSI Target: Set-IscsiServerTarget
- Creating a new iSCSI Target under an existing iSCSI Target Server: New-IscsiServerTarget
- Taking a snapshot of an iSCSI Virtual Disk: Checkpoint-IscsiVirtualDisk
The good news is that this conceptual framework remains unchanged in Windows Server 2012 R2 although it packs a powerful set of infrastructure changes under the covers. Here is a pictorial that summarizes the Virtual Disk enhancements in the core stack.
So yes, the big news is that iSCSI Target Server switched to VHDX (VHD 2.0) format in Windows Server 2012 R2. Further, iSCSI Virtual Disks can now also be built off Dynamic VHDX virtual disks. iSCSI snapshots are also supported for Dynamic VHDX-based Virtual Disks.
In addition to these, our File and Storage Services UI team has done an excellent job in taking advantage of these new enhancements, such that you can simply use Server Manager to start playing with these new features right away. Here is a screen shot of the ‘New iSCSI Virtual Disk’ wizard that perhaps illustrates the enhancements the best:
We have also made a couple of other key enhancements:
- Unlike in Windows Server 2012 where iSCSI Target Server always sets FUA on back-end I/Os, iSCSI Target Server now enables Force Unit Access (FUA) on its back-end virtual disk I/O only if the front-end I/O that the iSCSI Target received from the initiator required such a direct medium access. This has the potential to improve performance, assuming of course you have FUA-capable back-end disks or JBODs behind the iSCSI Target Server.
- Local Mount functionality of iSCSI Virtual Disk snapshots – i.e. Mount-IscsiVirtualDiskSnapshot and Dismount-IscsiVirtualDiskSnapshot– are now deprecated in Windows Server 2012 R2. These cmdlets were typically used for locally mounting a snapshot for target-local usage, e.g. backup. Turns out there is actually a simpler approach to avoid the deprecated functionality – use Export-IscsiVirtualDiskSnapshot cmdlet to create an associated Virtual Disk, and access it through a target-local initiator which can then back up the disk. This simpler approach is feasible because iSCSI Target Server now supports “loopback initiator”, basically initiator and target can both be on the same computer.
- Maximum number of sessions/target is now increased to 544, and the maximum number of LUs/target has gone up to 276.
How to get started?
Good news is that existing “iSCSI Target Block Storage, How To” TechNet guidance for Windows Server 2012 remains unchanged for this release. Follow the same steps documented for setting up the iSCSI Target Server feature. No additional configuration is required for enabling the functionality to exercise this scenario. iSCSI Target Server is ready to use the VHDX format!
You can either use the Server Manager à File and Storage Services à iSCSI GUI (refer to the previous screen shot), or use the iSCSI Target PS cmdlets documented on TechNet for Windows Server 2012: iSCSI Target Cmdlets in Windows PowerShell
The most significant difference in Windows Server 2012 R2 is perhaps in New-iSCSIVirtualDisk cmdlet usage. Here is the syntax help for New-iSCSIVirtualDisk:
New-IscsiVirtualDisk [-Path] <string> [-SizeBytes] <uint64>
[-Description <string>] [-LogicalSectorSizeBytes <uint32>]
[-PhysicalSectorSizeBytes <uint32>] [-BlockSizeBytes <uint32>]
[-ComputerName <string>] [-Credential <pscredential>]
[<CommonParameters>]
New-IscsiVirtualDisk [-Path] <string> [[-SizeBytes] <uint64>]
-ParentPath <string> [-Description <string>]
[-PhysicalSectorSizeBytes <uint32>] [-BlockSizeBytes <uint32>]
[-ComputerName <string>] [-Credential <pscredential>]
[<CommonParameters>]
New-IscsiVirtualDisk [-Path] <string> [-SizeBytes] <uint64>
-UseFixed [-Description <string>] [-DoNotClearData]
[-LogicalSectorSizeBytes <uint32>]
[-PhysicalSectorSizeBytes <uint32>] [-BlockSizeBytes <uint32>]
[-ComputerName <string>] [-Credential <pscredential>]
[<CommonParameters>]
A handful of things worth noting here to start heading in the right direction:
- Be sure to use “.vhdx” file extension for the file name, “Path” parameter. VHDX is the only supported format for newly-created iSCSI Virtual Disks!
- Note that the default iSCSI Virtual Disk persistence format will be Dynamic VHDX. You will need to use the “UseFixed” parameter if you need the Fixed VHDX format.
- By default, fixed VHDX format zeroes out the virtual disk file on allocation. Recognizing that previous iSCSI Target Server version provided a non-zeroing fixed VHDX behavior, we have provided an option in this release to maintain functional parity through ‘DoNotClearData’ parameter. However, keep in mind that by using this parameter, you may accidentally expose non-zeroed data that you may not want to – so avoid using it if you can! That is the reason Microsoft is no longer making this the default behavior either in GUI or in cmdlets.
- You will quickly notice is that the new cmdlet now supports a number of new cmdlet parameters – e.g. PhysicalSectorSizeBytes – that are supported by New-VHD cmdlet, this is a direct benefit of the redesigned back-end persistence layer based on VHDX format.
You should be able to
- Create large iSCSI Virtual disks (up to 64 TB) using Windows PowerShell and/or GUI
- Run your desired workloads – including SQL, diskless boot, cluster shared storage – on iSCSI block storage
- Create dynamic virtual disks and assign them to an iSCSI target
Manageability Enhancements
Overview
Let me again start with a recap on the SMI-S provider, which is the most significant enhancement in this group. iSCSI Target Server had shipped a Windows Server 2012-compatible SMI-S provider with System Center Virtual Machine Manager (SCVMM) 2012 SP1. This required installation from SCVMM media onto an iSCSI Target Server computer, not to mention some additional configuration steps detailed on SCVMM storage configuration guidance on TechNet. Windows Server 2012 R2 now significantly improves the SMI-S provider, and brings it into in-box.
As shown in the diagram above, SMI-S provider ships and installs as part of the iSCSI Target Server. No separate configuration steps are necessary, SMI-S provider process is auto-instantiated on demand. SMI-S provider presents a different, standards-compliant management object model to SCVMM, but it transparently uses the same WMI provider that Windows PowerShell cmdlets use. SMI-S provider in Windows Server 2012 R2 is designed for dual active iSCSI target clusters whereas the previous version was limited to active-passive clusters. The new SMI-S provider also supports asynchronous job management for long-running Create/Expand/Restore jobs – so these are also cancelable from SCVMM. The following screen shot shows the storage manageability view from SCVMM for an iSCSI Target Server.
Additionally, iSCSI Target Server made a few other key manageability enhancements in Windows Server 2012 R2.
- Online resizing – grow or shrink – of an iSCSI Virtual Disk is now supported via the new Resize-iSCSIVirtualDisk cmdlet. Previously, only online expansion was supported via Expand-IscsiVirtualDisk cmdlet. Syntax of Resize remains the same as that of Expand. And the Expand cmdlet continues to work as well.
- Asynchronous long-running operations are supported via cmdlets:
- Long-running operations are automatically instantiated by the iSCSI Target Server for the following three cmdlets: New-IscsiVirtualDisk, Expand-IscsiVirtualDisk, Restore-IscsiVirtualDisk
- You can verify if a long-running operation is running on an iSCSI Virtual Disk by the familiar Get-IscsiVirtualDisk cmdlet
- Newly-introduced Stop-iSCSIVirtualDiskOperation cmdlet cancels a long-running operation on an iSCSI Virtual Disk.
- You can optionally disable remote management of an iSCSI Target Server using the newly-introduced ‘DisableRemoteManagement’ parameter on the Set-IscsiTargetServerSetting. This would be valuable in scenarios where you are embedding iSCSI Target Server in an appliance with a different management wrapper, and you do not want iSCSI manageability end point to be directly externally exposed.
- Two new cmdlets are now added to simplify migration experience to Windows Server 2012 R2 – Export-iSCSITargetServerConfiguration and Import-iSCSITargetServerConfiguration.
How to get started?
Good news is that existing “iSCSI Target Block Storage, How To” TechNet guidance for Windows Server 2012 remains unchanged for this release. Follow the same steps documented for setting up the iSCSI Target Server feature. No additional configuration is required for enabling the functionality to exercise this scenario. SMI-S provider for iSCSI Target Server is automatically installed and ready for usage. Use the existing TechNet documentation for configuring SCVMM 2012 SP1 or later versions to work with iSCSI Target Server, see Configuring an SMI-S Provider for iSCSI Target Server The only change from that page is that the SMI-S provider is no longer required to be installed from SCVMM media, it is included in-box in Windows Server 2012 R2. Note that the version of SCVMM Server used for SMI-S manageability must be SCVMM 2012 SP1 or SCVMM 2012 R2 – the management server itself could run either on a Windows Server 2012 R2 server or a Windows Server 2012 server.
Here is the syntax for Stop-IscsiVirtualDiskOperation cmdlet – you can reference the iSCSI Virtual Disk either via the Path parameter, or through the Virtual Disk object retrieved from a different cmdlet such as Get-IscsiVirtualDisk:
Stop-IscsiVirtualDiskOperation [-Path] <string> [-ComputerName <string>]
[-Credential <pscredential>] [<CommonParameters>]
Stop-IscsiVirtualDiskOperation -InputObject <IscsiVirtualDisk>
[-ComputerName <string>] [-Credential <pscredential>]
[<CommonParameters>]
You can use Export-iSCSITargetServerConfiguration with the following syntax. When you run the Export from Windows Server 2012 R2 to export configuration from a down-level OS version computer, be sure to use the ‘ComputerName’ parameter to point to the right down-level computer.
Export-IscsiTargetServerConfiguration [-Filename] <string>
[[-ComputerName] <string>] [[-Credential] <string>] [-Force]
[<CommonParameters>]
And here is the syntax for Import-iSCSITargetServerConfiguration:
Import-IscsiTargetServerConfiguration [-Filename] <string>
[[-ComputerName] <string>] [[-Credential] <string>] [-Force]
[<CommonParameters>]
Note that as with the previous PS script, Export/Import operations do not migrate CHAP settings for security reasons – because we do not want to export an encrypted password in clear. So you will need to note passwords through some other means, and re-configure them on the destination computer after finishing the Import operation. Expect a complete migration guide to be available on TechNet in the very near future that will go into a lot more detail on this topic.
You should be able to
- Discover iSCSI Target in-box SMI-S provider through SCVMM’s storage automation
- Carve out storage virtual disks on iSCSI Target, and provision them to a Hyper-V host
- Create long-running asynchronous jobs for large (>= ~5TB) virtual disk creation, and monitor the status
- Create multiple Continuously Available (CA) iSCSI target server instances in a single failover cluster using Failover Cluster Manager, and manage them all using a single instance of SCVMM
- Migrate your existing Windows Server 2008 R2 or Windows Server 2012-based iSCSI Target Server to Windows Server 2012 R2
Wrap-up
iSCSI Target Server ships with a lot of exciting new functionality in Windows Server 2012 R2. Here are a couple of other useful pointers:
What’s New for iSCSI Target Server in Windows Server 2012 R2
To conclude, hope this blog post gave you some insight and familiarity to start using the new iSCSI Target Server right away! Drop me an offline note using the blue “Contact” button on this page with your feedback on how it’s going.
To see all of the posts in this series, check out the What’s New in Windows Server & System Center 2012 R2 archive.