Sun Storage 7000 Unified Storage System: Configuration and tuning for iSCSI performance

Asset ID:	1-71-1175573.1
Update Date:	2011-05-19
Keywords:

Solution Type Technical Instruction Sure

Solution 1175573.1 : Sun Storage 7000 Unified Storage System: Configuration and tuning for iSCSI performance

Applies to:

Sun Storage 7210 Unified Storage System - Version: Not Applicable and later   [Release: N/A and later ]
Sun Storage 7110 Unified Storage System - Version: Not Applicable and later    [Release: N/A and later]
Sun Storage 7310 Unified Storage System - Version: Not Applicable and later    [Release: N/A and later]
Sun Storage 7410 Unified Storage System - Version: Not Applicable and later    [Release: N/A and later]
Information in this document applies to any platform.

Goal

To discuss this information further with Oracle experts and industry peers, we encourage you to review, join or start a discussion in the My Oracle Support Community - 7000 Series ZFS Appliances

To provide performance tuning considerations for Unified storage configured to use iSCSI

Solution

1. Misaligned partition blocks

The partition/slice starting block on the client host may or may not be alignment with the block allocated on by the zvol on the 7000 series storage. This misalignment causes the storage to under utilize the zvol blocks for each read or write originating from the host. Note that there is no target side defect, but instead it the tuning which is required from the client end at the time of creating the LUN partitions/slices on the client host. Depending on your client host type and lun label use the following method to determine if your system is affected by the misalignment.

Label type : EFI
Since an EFI label is sector addressable (and actually has no concept of cylinders or tracks), the following must be true for a given slice to be aligned:
(starting sector number * sector size) % block size == 0
With the "zpool create/add" default offset of 256 sectors, we are correctly aligned for any power of two zvol blocksize up to 128K.

Label type : SMI
When using cylinder addressing to create a partition, the following must be true for a given partition to be aligned:
(cylinder number * number of heads * sectors per track * sector size) % block size == 0

Win 2003:
Misaligned by default.

Windows Vista / 2008:
Correctly aligned by default.

Windows 2003 SP1 and later:
To determine the starting offset on windows use the following command
wmic partition get StartingOffset, Name, Index
Calculate the alignment using the formula
StartingOffset % block size == 0

To correct the partitions / slices which are misaligned:
Recreate the partition / slice starting from the sector/cylinder/offset which satisfies the above formula as applicable in your case.
For Windows 2003 SP1 and above use diskpart.exe utility and include align=X option, And specify X=128 to align for any block size up to 128KB.
You can create multiple slices if needed, as long as the starting sector of each meets the criteria above.

Following CRs are in place to take care of this issue in terms of identifying any misaligned
partition, these CRs are not yet fixed as of now at 2010.Q3.

<SUNBUG 6918051> 2009.Q3 COMSTAR iSCSI target - sequential read performance is much slower on Windows 2008R2 initiator
<SUNBUG 6919756> zfs exported luns need a way to cancel systematic unaligned offset after disk partitioning
<SUNBUG 6922617> exported lun geometry should have cylinders aligned on exported block device
<SUNBUG 6922630> need analytic dataset to identify initiator induced misaligned lun

2. Usage of Write cache and Log device

Write cache:
When write cache is enabled all the synchronous writes will go to the ARC on the node and later gets synced to the stable hard disk. In the event of node crash the un-synced data in the cache is lost. Unless the host application understand this semantics and can recover from this condition it is not advisable to enable this property.

Log Device (Also known as ZIL SSD, write optimized SSD):
Generally iSCSI IOs are random synchronous IO using one or more Log device will improve iSCSI write performance.

Configure Latency optimized:
Setting this parameter will immediately commit writes to the Log device, which reduces the write latency considerably. And by immediately committing writes to the SSD’s, writes are protected against failure. This setting makes heavily use of Log device and it is limited by Log device performance. More Log devices striped together provide better IOP’s and bandwidth performance.

Throughput optimized:
This means that writes bypass the Log device and commit directly to pool disks. This setting is usually very slow for a single transaction and only provides reasonable throughput when highly multi-threaded writes are hitting an iSCSI LUN. This setting should be avoided in most cases to achieve a decent performance as only few workloads could provide such highly parallel load.

Summary:
a. Enable write cache only if the host understands the write cache semantic
b. If write cache is not enabled, then it recommended to have Log device
c. Configure Latency optimization

3. RAID Type

The recommended disk layout for iSCSI environment is RAID 10 (mirrored sets in a striped set; ZFS stripes the data automatically between multiple sets). It is called 'Mirrored' by the 7000 series. While this disk layout uses 50% of the available disk capacity for redundancy it is faster than RAID 5 for intense small random read/writes which is the typical access characteristic for iSCSI.

Attachments

This solution has no attachment