ioSafe 1513+ Review: A Disaster-Resistant Synology DS1513+
by Ganesh T S on August 13, 2014 7:30 AM EST- Posted in
- NAS
- Storage
- Synology
- Enterprise
- ioSafe
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+.
Facebook
Twitter
RSS
43 Comments
View All Comments
ddriver - Saturday, August 16, 2014 - link
Thanks for the input. BTW, where I come from, "cellar" does not imply "basement" - our cellars are usually on floor levels, tiny room, around 1 m^2 for general storage purposes, no water mains no nothing. Closer to what you may call "pantry" in the US. Cultural differences... me'h. Nothing to burn and nothing to flood in there. Plus noise in the cellar bothers nobody.Never failed a demo - which exactly proves the point I make earlier about being careful with controlled fires. That would create the illusion your products are flawless and someone's gonna buy one expecting it to survive his fancy wooden and lacquer soaked cottage burning to the ground which I am willing to bet it will not. You should really draw the line between "office fire accidents" and "fire disasters" just for the sake of being more realistic and not deceiving consumers, deliberately or not. People are impressed by big numbers, and could easily be impressed by the 1700 F number, absent the realization most flammable materials burn at significantly higher temperatures. Every engineer knows - there is no such thing as a flawless product, the fact you never had a failed demo only goes to show you never really pushed your products. With those zero failed demos you will very easily give consumers the wrong idea and unrealistic expectations, especially ones who are not educated on the subject. You SHOULD fail a few demos, because it will be beneficial for people to know what your products CAN'T HANDLE. A few failures in extreme cases will not degrade consumer trust as your PR folks might be prone to believing, it will actually make you look more honest and therefore more trustworthy.
ddriver - Saturday, August 16, 2014 - link
I mean better you cross that line with a test unit than some outraged consumer going viral over the internet how your product failed and he lost his life work ;)robb.moore - Monday, August 18, 2014 - link
Hi ddriver-As mentioned, our fireproof tech relies on proven methods that are over 100 years old. Appreciate the heated skepticism though. As an engineer myself, I agree that no product is flawless and everything (including our own products) have their limits. I take back the "never failed a demo" comment. We did some gun demos with shotguns (passed) - got a bunch of flack for ONLY using shotguns so we redid the demo with fully auto AR-15's - blew holes completely through the product and of course failed...sometimes. Fun demo though.
-Robb
Phil Stephen - Monday, August 18, 2014 - link
ddriver: I'm a firefighter and can confirm that, based on the specs, these units would indeed withstand a typical structure fire.zlobster - Sunday, August 17, 2014 - link
Dear Mr. Moore,I'm really glad that you actually follow up with the public opinion.
I'll try to use the opportunity and use it to ask you whether you are planning to build a unit with non-Intel CPU, rather with AMD/ARM/Marvell/etc.? A unit that can handle the latest industry standards for on-the-fly encryption without sacrificing the performance even a bit?
Also, besides the physical integrity and resiliency tests that you are conducting, do you do similar penetration-testing for data integrity? I mean, with well-known independent hacker/pen-testing communities? With all the fuzz around govt. agencies putting backdoors virtually everywhere, it's of extreme importance for the piece of mind of extreme paranoics (like me), to know how hack-proof your devices are.
Regards,
Zlob
robb.moore - Monday, August 18, 2014 - link
Hi Zlop-We're constantly working on new products. The 1513+ does use an Intel chip but our other NAS (2 bay), ioSafe 214 uses a Marvell chip. We realize that encryption can be important in many situations and we're always interested in balancing features, cost and speed for our products. Can't make direct comments though on what we have in the pipeline except stay tuned! :)
In regards to "hack-proof", the most "hack-proof" systems (aka CIA, etc.) don't exist on the internet at all. They're fully contained offline in secured facilities. In fact, ioSafe systems are used in situations like this where offsite backup (online or physical relocation) is not allowed or impractical but the end user still wants a disaster plan.
Obviously, there's a balance between security, accessibility, cost and speed. If you put an ioSafe system online, no firewall, never update OS/firmware, all ports open with standard admin passwords - expect mayhem. If you put an ioSafe system in a bank vault, offline and turned off it's obviously pretty secure but inaccessible - not very useful. Security can be complicated. Striking the right balance is different for every situation. Our NAS systems are based on the Synology platform which in turn is a custom Linux kernel so it's as safe as you make it generally (like all connected systems) and is susceptible to hackers if setup incorrectly. We're very happy to help you with configuring your device if you have any questions at all about the tradeoffs.
Ultimately though its under your control. You're in charge of opening or closing doors.
Robb Moore, CEO
ioSafe Inc.
PEJUman - Saturday, August 16, 2014 - link
I second that, for this price... I really want to know it it would last the rated time under fire. Should try it under propane {bbq tank 2300+ C} and and Nat. Gas/wood based flame {1900+ C} To simulate household/industry gas line.bsd228 - Thursday, August 14, 2014 - link
Well for the $1000 extra, one could buy a 30"x72" inch gun safe that can also be used to store the regular Synology (or a DIY NAS) plus guns, camera gear, and any other valuables. Harder to steal as well- they weight 500-1000lbs.DanNeely - Thursday, August 14, 2014 - link
Maybe; but good luck using the NAS with the door shut...smorebuds - Thursday, August 14, 2014 - link
l0l