ioSafe 1513+ Review: A Disaster-Resistant Synology DS1513+

DSM 5.0: iSCSI Features

Synology's DSM is quite feature rich, and it is impossible to do it justice in a single review. Starting with the DS214play, we decided to use each review to focus on one particular aspect of the DSM / firmware ecosystem. The DS214play review dealt with the media aspects and associated apps and the DS414j review explored the backup and synchronization infrastructure. With its Atom-based platform, comparatively large amount of RAM and four network links, we decided that the ioSafe 1513+ was the perfect candidate to explore the iSCSI features of Synology DSM 5.0

Background

Readers dabbling in virtualization would be quite familiar with iSCSI and can conveniently skip this sub-section to move on to the discussion of Synology's iSCSI features further down. In layman's terms, iSCSI is a protocol which allows storage on a networked device to be presented as a physical device on another machine. Readers wanting to go into further detail on the various aspects of iSCSI can refer to Wikipedia.

iSCSI has been attracting a lot of interest from NAS vendors in the recent past due to the rising popularity of virtualized infrastructure. Since iSCSI devices appear as physical drives on the machines in which they are mapped, they are ideal for virtual machine hosts. The mapped iSCSI drives can be used as physical disks for the guest machines or simply as a store for the virtual hard disk files mapped to the guests.

In order to understand iSCSI implementations, it is important to be aware of two concepts, the LUN and the target. The LUN (Logical Unit Number) refers to a device that can be addressed via SCSI protocols and supports read/write operations. On the other hand, a target is an endpoint in the SCSI system to which an initiator (or master) connects. A target without a LUN is essentially useless, as there is nothing that be read or written. A target can have one or more LUNs associated with it.

Source: VMWare

In simple setups, each target is associated with a single LUN. If there are multiple LUNs associated with a target, each of them will appear as a separate physical disk for the initiator connecting to the target. In the rest of this coverage, we will be proceeding with the single LUN on single target configuration.

Synology's iSCSI Implementation

Synology has a step-by-step guide to get iSCSI services up and running on DSM. In this section, we share our experience and configurations steps with the ioSafe 1513+. After completing all the benchmarks in the previous section, we were left with a SHR volume (1-disk fault tolerance) having a few shared folders. Upon proceeding to create an iSCSI LUN, we were presented with three choices, two of which were grayed out. The only available option was to create a iSCSI LUN (Regular Files).

File-Based LUNs

Synology implements iSCSI LUN (Regular Files) as files under the path "/volume1/@iSCSITrg/". As seen from the above screenshot, Synology touts the dynamic capacity management using Thin Provisioning as the most advantageous aspect. Trying to create such a LUN rightly exposes an option for 'Thin Provisioning'. Enabling this allows for capacity expansion at a later stage.

The ioSafe 1513+ carries virtualization logos in its marketing collateral ("VMware READY", "CITRIX ready" and "Windows Server 2012 Certified"). Synology NAS units carrying these logos have an option for 'Advanced LUN Features' that can be turned on or off. If enabled, VMware VAAI - vStorage APIs for Array Integration - support is reported back to the initiator. This offloads storage tasks such as thin provisioning and cloning of virtual disks from the VM host to the NAS itself. On the Windows side, the advanced LUN features include ODX - Offloaded Data Transfers - for data transfer to not clog up the network bandwidth if possible (i.e, data movement from one part of the NAS volume to another) as well as LUN snapshotting and cloning.

Block-Level LUNs

Instead of file-based LUNs, users can also create block-based ones. Synology sums up the implementation difference succinctly in this graphic:

The trick to enable creation of block-based LUNs is to avoid the auto-creation of a SHR volume (or any other RAID volume) when the NAS gets initialized in the beginning. If such volumes exist, it is necessary to remove them. Once all volumes are removed, we can see the two previously-grayed out options getting enabled.

There are two ways to proceed with either of these two options. One is to follow the directions given in the LUN creation wizard and make it automatically create a Disk Group in a particular RAID configuration. The other is to create a disk group beforehand and use it while initializing the new LUN. Note that SHR is not available for such groups.

Choosing the Single LUN on RAID option utilizes the full capacity of all the disks in the Disk Group to a single target with one LUN. Such a LUN could potentially be mapped on a VM host and multiple virtual hard disk files could be create on it. Synology indicates that this configuration provides the best performance.

On the other hand, the Multiple LUNs on RAID option allows for specification of LUN size during creation. Synology claims this provides optimized performance. The advantage is that multiple LUNs can be created to map on as separate physical drives for multiple VMs. The left-over space can be used for the creation of a standard volume on which one can have the usual CIFS / NFS shares. An important aspect to note is that the VAAI and ODX capabilities are not available for block-level LUNs, but only for the regular file-based ones.

In the next section, we deal with our benchmarking methodology and performance numbers for various iSCSI configurations in the ioSafe 1513+.