Author Topic: Transparent RAID Performance Thread - Part 4/4 (Storage Accelerators - SSD Cache  (Read 21093 times)

Offline Brahim

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8,547
  • Karma: +204/-16
    • View Profile
Storage Accelerators

Overview
We are now tackling the final performance enhancement features for Transparent RAID.
These performance boosting features were the most obvious features to implement. However, we chose to implement them last and for good reason.

It was really important to us to design the core Transparent RAID engine to be as optimal as possible without resolving to external enhancements. No matter what type of storage acceleration one puts in front of a RAID array, the data needs to eventually tickle down to the array. Essentially, a good cache layer is nothing if the medium it has to flush to is too slow. So, rather than masking the challenges Transparent RAID faced, we were pretty open about them, which gave us the opportunity to address those challenges rather than sweeping them under the rug.

Additionally, we want and expect storage acceleration to be optional. Transparent RAID should be fully usable without any external enhancement for the typical user.

Our achievement
Well, we have succeeded in our design goals. :)
Check out the charts posted in the Performance mode thread.

The average system in Energy mode using S.W.O performs far better than all other comparable NAS solutions on the market.
However, this was not enough for us. We boosted performance further with TCQ and OS Caching. OS Caching improves the user's experience in normal usage.
Finally, for those users with high latency disks, we introduced a Performance mode that minimizes latency and boosts performance to a height theoretically not possible. In theory, Transparent RAID should not be able to achieve more than 1/3rd of the speed of a single disk. In practice, properly equipped systems are hitting close to 80% of the speed of a single disk.

It is important to understand that Transparent RAID does not stripe data and should not be compared to striped RAID implementations.
This stems from a critical design choice, which provides certain benefits but at the cost speed. Even then, Transparent RAID is actually faster than some striped RAID implementations.  :P

External enhancements
Although the average user will be plenty satisfied with the performance out of Transparent RAID as designed, there is always a group of select few that always demand more, and they cannot be ignored.
We have pushed the design of the core Transparent RAID engine as far as we could from a performance perspective. Any significant performance boost would have to be external.

External accelerators are not a bad thing. Accelerators are great for transactional operations while large cheap storage arrays are great for warehousing.
If one's daily activities can execute on a fast/hot storage while the inactive data remains on the slow/cold storage, we can achieve an ideal from many fronts.

Landing Disk
The first solution we have is a landing disk.
A landing disk purely accelerates write operations for new data. Eventually, that data will get moved to the main array through a background process.
The landing disk can be a mirror set so that it is protected or it can be a single unprotected disk. Using an unprotected disk as landing disk should not be a big of a deal for deployments where it is merely viewed as a buffer. Those that require protection of that buffer can mirror the landing disk so that it is protected.

In Transparent RAID, a landing disk can be a folder on your OS disk or any other disk in your system that is not part of a Transparent RAID array. This means that, for most users, there will not be an additional hardware purchase. Of course, you can fully take advantage of the landing disk feature by using a dedicated SSD for such purpose.

If you have multiple Transparent RAID arrays, they can all share the same disk as landing disk (this will make sense when you see how landing disks are configured in tRAID).
Also included is a configuration for including and excluding what goes into the landing disk. We can foresee scenarios where a user might want certain data to just go to the array skipping the landing disk.

For configuration please refer to the wiki guide on Storage Acceleration in Transparent RAID:
http://wiki.flexraid.com/2013/06/27/storage-acceleration/


SSD Caching
To be discussed later (we will focus first on Landing Disk).
« Last Edit: October 30, 2014, 11:26:00 pm by Brahim »

Offline Brahim

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8,547
  • Karma: +204/-16
    • View Profile
Okay ladies and gents, the Landing Disk feature is out! :)

See the beta release thread for early access: http://forum.flexraid.com/index.php/topic,3528.msg23609.html

Offline knewknow

  • Newbie
  • *
  • Posts: 23
  • Karma: +0/-0
    • View Profile
The landing disk is also used when copying to the array over network?

Offline robinp

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +1/-0
    • View Profile
The landing zone is used both when accessing the pool locally and when accessing pool shares over the network.

Offline eeze

  • Newbie
  • *
  • Posts: 44
  • Karma: +0/-0
    • View Profile
I have 3 questions related to this

1) If I am copying to one of my drives directly (storage pool stopped) and the drive managed by Flexraid.  Will the files be copied to the Storage temp folder first then to the destination of my choice? Or is it random
2) Since I run in a VM environement, could I use any folder on the C drive (assuming enough space exists)
3) I'm very concerned about this quote from the Storage Accelerator page
"In theory, Transparent RAID should not be able to achieve more than 1/3rd of the speed of a single disk. In practice, properly equipped systems are hitting close to 80% of the speed of a single disk."
--- The reason is i'm seeing only 36MB/s even with a new PPU (Seagate) drive.  Without Flexraid, I am able to get a sustained 140MB/s with WD Red drives.  This is with 100GB files.


Offline Brahim

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8,547
  • Karma: +204/-16
    • View Profile
@eeze
1. The landing disk feature is implemented as part of the storage pool. No storage pool, no landing disk.

2. The wiki is rather clear on that - but, yes.

3. Your sequential speed standalone and your speed in RAID mode are two different things. If your disks do poorly in random operations, you will need to switch to performance mode.

Offline ninja6o4

  • Full Member
  • ***
  • Posts: 107
  • Karma: +0/-0
    • View Profile
    • My tRAID config
@Brahim
In your wiki, you have a note at the bottom:
Quote
Note: the available space on the landing disk must be larger than the reserve space set on the storage pool.
If the available space on the landing disk is smaller than the storage pool reserve space, the landing disk will not be used and will be ignored.

Is this the "Space Management Reserve (in GB)" field in the RAID Options dialog? I am just clarifying - the wiki should refer to the option identically as in the options so there is no confusion.

Thanks
My tRAID config: http://i.imgur.com/6UL9GF4.png
Case: Supermicro SC846 24 Bay 4U
MB: Asus Q87E/CSM
CPU: Intel i7-4771
RAM: 4x 8GB
HBA: Dell H310, IT fw
HDD: 8x+2x 3TB WD Reds (tRAID), 2x Samsung 256 Pro SSD (Boot), 2x 1TB WD Blacks, 1x 640GB WD Black
PSU: Corsair HX750w
OS: Server 2008 R2 w/ HyperV

Offline NLS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1,018
  • Karma: +29/-4
  • Look ma, no hands!
    • View Profile
    • iLogic
Yes this is the field.
---
NLS
Production system: SBS2011 fully patched, intel Core2 Quad, 8GB, 12 disks (1 system IDE, 1 backup IDE, 10 for array and parity most SATA3), parity is 3TB, largest data disk is 3TB, millions of smaller files, common browser Chrome latest.

Offline pbrauman

  • Full Member
  • ***
  • Posts: 108
  • Karma: +1/-0
    • View Profile
Question:

What happens if the amount of data being written to the array (via the Landing disk) exceeds the Landing disk size.

eg: If I move 100Gb to the array but my landing disk is a 64Gb SSD?

Pete

Offline Brahim

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8,547
  • Karma: +204/-16
    • View Profile
The data will overflow to the array.

Offline natecook

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Any word on SSD caching? I just built my system with eleven 4 TB drives (9 data, 2 parity) and an old 3 TB as a landing disk, and I kept my old 256 GB SSD to use for caching. I'd like to know when I can start firing it up  ;D
Transparent RAID 36 TB

Offline hhb97b

  • Newbie
  • *
  • Posts: 26
  • Karma: +1/-0
    • View Profile
Hi

I know we are not supposed to discuss ssd cache yet, but I'm in the planning for a new machine and I have two simple questions for ssd cache.
Will the ssd cache help with write performance and will it require a separate drive or volume or will a folder also work?

Offline Brahim

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8,547
  • Karma: +204/-16
    • View Profile
SSD cache will mostly improve small random read/writes.
The landing disk is better for sequential writes. So, use an SSD or a fast sequential disk for that purpose.

An entire SSD or part of it could be used for the purpose of SSD caching.
SSD caching will have little value for the average user here. Its real purpose is to help those users that need hot data (data that is read and/or edited often) and those that need improvements in random I/O.

Offline pclausen

  • Jr. Member
  • **
  • Posts: 96
  • Karma: +0/-0
    • View Profile
Question on the overflowing from landing disk to array.  I'm currently in the process of copy about 4TB of smaller files (music collection of a little over 400,000 tracks).  I started the copy process Friday afternoon, so I'm now about 80 hours in, and still have more than 24 hours to go.  Average copy speed is about 3 MB/sec, which is very slow.  I do have a 64GB SSD landing disk, that was exhausted within minutes of starting the copy operation.

Here's a view of the copy session itself:



And a view from resource monitor showing various copy tasks taken place, most of which are being piped through the poor landing disks.



Even when only the music copy task is running, the speed does not budge much past 3 MB/sec.

So my question is, if I know I got a large data transfer tasks planned, should I disable the landing disk feature before I begin?
« Last Edit: August 25, 2014, 05:22:19 pm by pclausen »

Offline Brahim

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8,547
  • Karma: +204/-16
    • View Profile
The biggest improvement you should make is to queue the files to be copied rather than doing many parallel operations.

But yeah, when copying large amount of data, do skip the Landing Disk.
Copying 4TB to a lowly 64GB SSD will ware it out like nothing and slow it down to a crawl as its garbage collection tries to keep up.

The simplest thing to do is to have an exclusion folder for the landing disk. When copying large amount of data, copy that to the excluded folder first and then rename/move the data outside of that folder.

FYI, you are hitting a double effect:
1. The I/O priority on the Landing Disk is likely set to IDLE, which causes it to throttle the copy.
2. The SSD naturally slows down due to garbage collection
« Last Edit: August 25, 2014, 06:12:04 pm by Brahim »