Our open storage partner, Nexenta Systems Inc., hit a milestone this month by releasing NexentaStor 4.0.1 for general availability. This release is significant mainly because it is the first commercial release of NexentaStor based on the Open Source Illumos kernel and not Oracle’s OpenSolaris (now closed source). With this move, NexentaStor’s adhering to the company’s promise of “open source technology” that enables hardware independence and targeted flexibility.
Some highlights in 4.0.1:
- Faster Install times
- Better HA Cluster failover times and “easier” cluster manageability
- Support for large memory host configurations – up to 512GB of DRAM per head/controller
- Improved handling of intermittently faulty devices (disks with irregular I/O responses under load)
- New (read: “not backward compatible”) Auto-Sync replication (user configurable zfs+ssh still available for backward compatibility) with support for replication of HA to/from non-HA clusters
- Includes LZ4 compression (fast) option
- Better Control of “Force Flags” from NMV
- Better Control of Buffering and Connections
- L2ARC Compression now supported
- Potentially doubles the effective coverage of L2ARC (for compressible data sets)
- Supports LZ4 compression (fast)
- Automatically applied if dataset is likewise compressed
- Server Message Block v2.1 support for Windows (some caveats for IDMAP users)
- iSCSI support for Microsoft Server 2012 Cluster and Cluster Shared Volume (CSV)
- Guided storage pool configuration wizards – Performance, Balanced and Capacity modes
- Enhanced Support Data and Log Gathering
- High Availability Cluster plug-in (RSF-1) binaries are now part of the installation image
- VMware: Much better VMXNET3 support
- no more log spew
- MTU settings work from NMV
- VMware: Install to PVSCSI (boot disk) from ISO no longer requires tricks
- Upgrade from 3.x is currently “disruptive” – promised “non-disruptive” in next maintenance update
- Improved DTrace capabilities from NMC shell for
- general IO
- Snappier, more stable NMV/GUI
- Service port changes from 2000 to 8457
- Multi-NMS default
- Fast refresh for ZFS containers
- RSF-1 defaults in “Server” settings
- Improved iSCSI
See Nexenta’s 4.0.1 Release Notes for additional changes and details.
Note, the 18TB Community Edition EULA is still hampered by the “non-commercial” language, restricting it’s use to home, education and academic (ie. training, testing, lab, etc.) targets. However, the “total amount of Storage Space” license for Community is a deviation from the Enterprise licensing (typical “raw” storage entitlement)
2.2 If You have acquired a Community Edition license, the total amount of Storage Space is limited as specified on the Site and is subject to change without notice. The Community Edition may ONLY be used for educational, academic and other non-commercial purposes expressly excluding any commercial usage. The Trial Edition licenses may ONLY be used for the sole purposes of evaluating the suitability of the Product for licensing of the Enterprise Edition for a fee. If You have obtained the Product under discounted educational pricing, You are only permitted to use the Product for educational and academic purposes only and such license expressly excludes any commercial purposes.
- NexentaStor EULA, Version 4.0; Last updated: March 18, 2014
For those who operate under the Community license, this means your total physical storage is UNLIMITED, provided your space “IN USE” falls short of 18TB (18,432 GB) at all times. Where this is important is in constructing useful arrays with “currently available” disks (SATA, SAS, etc.) Let’s say you needed 16TB of AVAILABLE space using “modern” 3TB disks. The fact that your spinning disks are individually larger than 600GB indicates that array rebuild times might run afoul of failure PRIOR to the completion of the rebuild (encountering data loss) and mirror or raidz2/raidz3 would be your best bet for array configuration.
SOLORI Note: Richard Elling made this concept exceedingly clear back in 2010, and his “ZFS data protection comparison” of 2, 3 and 4-way mirrors to raidz, raidz2 and raidz3 is still a great reference on the topic.
Given 16TB in 3-way mirror or raidz2 (roughly equivalent MTTDL predictors), your 3TiB disk count would follow as:
3-way Mirror Disks := RoundUp( 16 * (1024 / 1000)^3 / 70% / ( 3 * (1000 / 1024)^3 ) ) * 3 = 27 disks, or
6-disk Raidz2 Disks := RoundUp( 16 * (1024 / 1000)^3 / 70% / ( 4 * 3 * (1000 / 1024)^3 ) ) * 6 = 18 disks
By “raw” licensing standards, the 3-way mirror would require a 76TB license while the raidz2 volume would require a 51TB license – a difference of 25TB in licensing (around $5,300 retail). However, under the Community License, the “cost” is exactly the same, allowing for a considerable amount of flexibility in array loadout and configuration.
Why do I need 54TiB in disk to make 16TB of “AVAILABLE” storage in Raidz2?
The RAID grouping we’ve chosen is 6-disk raidz2 – that’s akin to 4 data and 2 parity disks in RAID6 (without the fixed stripe requirement or the “write hole penalty.”) This means, on average, one third of the space consumed on-disk will be in the form of parity information. Therefore, right of the top, we’re losing 33% of the disk capacity. Likewise, disk manufacturers make TiB not TB disks, so we lose 7% of “capacity” in the conversion from TiB to TB. Additionally, we like to have a healthy amount of space reserved for new block allocation and recommend 30% unused space as a target. All combined, a 6-disk raidz array is, at best, 43% efficient in terms of capacity (by contrast, 3-way mirror is only 22% space efficient). For an array based on 3TiB disks, we therefore get only 1.3TB of usable storage – per disk – with 6-disk raidz (by contrast, 10-disk raidz nets only 160GB additional “usable” space per disk.)
SOLORI’s Take: If you’re running 3.x in production, 4.0.1 is not suitable for in-place upgrades (yet) so testing and waiting for the “non-disruptive” maintenance release is your best option. For new installations – especially inside a VM or hypervisor environment as a Virtual Storage Appliance (VSA) – version 4.0.1 presents a better option over it’s 3.x siblings. If you’re familiar with 3.x, there’s not much new on the NMV side outside better tunables and snappier response.