Network-Attached Storage

home_page-colorNAS image
Where many competitors have focused on creating an appliance offering, unRAID has taken a hardware-agnostic approach to network-attached storage.  The benefit is unRAID’s ability to boot on nearly any x86 64-bit capable system and manage an array of disks that vary in size, speed, brand, and protocol.  In addition, by eliminating the use of traditional RAID-based technologies, we can scale on-demand by adding more disks and without needing to rebalance data.

unRAID’s storage capabilities are broken down into three components:  the array, the cache, and the user share file system.

unRAID Array

The primary concept behind an unRAID array is its ability to manage an aggregate of disk devices (JBOD) that is protected by a dedicated parity device. A parity device provides a way for you to reconstruct data from a failed disk onto a new one.  While it seems mind boggling that one drive can possibly back up other drives that have way more storage capacity than the parity, it is able to reconstruct the missing data from a failed drive using binary logic called XOR (eXclusive-OR).  Since hard drives store data as zeroes and ones, when a drive fails the parity compares the binary data on all the surviving drives and can deduce the missing data to rebuild.

unRAID Array with Parity

unRAID Cache

The cache drive feature of unRAID provides faster data capture. Generally speaking, by using a cache alongside an array of 3 or more devices, you can achieve up to 3x write performance. When data is written to a user share that has been configured to use the cache device, all of that data is initially written directly to the dedicated cache device. Because this device is not a part of the array, the write speed is unimpeded by parity calculations. Subsequently an unRAID process called “the mover” copies the data from the cache to the array at time and frequency of your choosing. Once the data has been successfully copied, the space on the cache drive is once again freed up to front-end other write operations to cache-enabled user shares.

Cache Pool

With a single cache device, data captured there is at risk, as a parity device doesn’t protect it. However, you can configure a cache with multiple devices both to increase your cache capacity as well as to add protection for that data. The grouping of multiple devices in a cache is referred to as building a cache pool. The unRAID cache pool is created through a unique twist on traditional RAID 1. Here are just some of the benefits:

  • Improved Data Protection – With a single cache device, there’s a possibility that you can lose your data if the device fails before the data gets moved to the array. With a cache pool, however, all write operations are replicated across two separate disks to ensure that the loss of any one drive in the pool does not result in data loss.
  • Increased System Uptime – If a cache pool device fails, the system will continue to operate as normal. No need to drop everything to deal with a system outage. You can simply change the device when convenient.
  • Better Scalability – Add more devices of different sizes to your pool as you need to and grow on-demand.
  • Optimized for SSDs¹ – unRAID now has native support for TRIM, which can substantially reduce the number of write operations when used as a cache device. Benefits of SSDs vs. HDDs:
    • They don’t require time to ‘spin up’ or consume a lot of power to operate (they are fast and efficient);
    • They are also smaller, so you can fit more of them into a smaller space for highly compact, crazy fast storage.
    • When used for storing large quantities of smaller files (e.g., metadata), SSDs can provide a faster response time for these files to the application compared to spinning hard disks; and
    • SSDs are most ideal for supporting virtual machines.  VM performance benefits on an SSD are comparable to what a user would experience with them on a desktop PC vs. a spinning disk.
  • Optimized for Virtualization – Virtual machines and applications can have their data reside on the cache pool permanently for overall improved performance, while keeping mass-storage content on the array still accessible to those virtual instances using VirtFS (for KVM Virtual Machines) and Docker (for Containers). Given the desire for “fast-as-you” responsiveness in application and machine performance, using the cache pool for virtual machine/application storage is a no-brainer. Use of SSDs in a cache pool extends this benefit even further.

unRAID Cache Pool and Array

¹ SSDs are only supported as part of a cache pool, not in the unRAID array at this time.

unRAID Shares

Unlike most RAID systems, unRAID saves data to individual drives. To simplify manageability, users can create shares that allow files written to them to be spread across multiple drives. Each share can be thought of as a top-level folder on a drive. When browsing through a share, all data from all drives that participate in that share will be displayed together. Users do not need to know which disk a file is on in order to access it under a share. Shares can be tuned to include/exclude specific disks and to utilize various methods for determining how files are allocated across those disks. In addition to controlling how data is distributed across drives, users can also control what network protocols the share is visible through as well as define user-level security policy. When accessing your unRAID server over a network protocol, all shares exported through that protocol will be visible, but you can toggle protocols for both individual shares as well as at a global setting level. Should you have private data on your system that you wish to protect from anonymous access, user accounts can be created and policies defined to limit access to only trusted individuals.  In addition to this concept of user shares, entire individual disks can be shared individually as well for advanced management capabilities.  The simple concept with shares is that they enable you to organize your data any way you want.


user-shares-access-policies

Back to Top