#What performance impact in using HDD aggr for FabricPool?

1 messages · Page 1 of 1 (latest)

sour cradle
#

We are planning on using "all" FabricPool policy on volumes for storing backups with HDD aggs (preferred) or SSD aggrs. Such workloads could be large and in daily basis. SSD should be okay.

I know FabricPool supports HDD Aggregates type (on FAS8200). But anybody has experiences on really using it? In "all" FP policy, data from multiple volumes on the same HDD aggr could be constantly tiered to the capacity tier (StorageGrid here), and meanwhile the aggr also has to response write requests, is there performance concern on the HDD aggregate level?

gray swift
#

Oof.

#

Yes.

#

Yes it works, but don't expect it to be great. How much is perf a concern?

sour cradle
#

I figured it works but there could be an issue with the performance, and don't know how much. That's why I post the message asking anybody who may have real experiences at work.

dawn night
#

I'll add my 2 cents here - I was one of the annoying customers pushing to get NetApp to support HDD aggregates for FabricPool. I wanted a HDD/FabricPool/StorageGRID setup for my SnapVault destinations and didn't want to pay for all-flash to get FP support.

Lessons learned:
0) Yes, it was a lot cheaper to go HDD/StorageGRID than to buy enough spinning disks to hold the target data copies.

  1. FabricPool does a LOT of scanning of disk blocks to decide what to tier. I mean a LOT. You can easily become spindle-bound. We started with a FAS2720 pair with 48 8TB SATA spindles. Major saturation. The data was coming in faster than we could tier. We were also CPU-bound. This cluster was also used for Commvault backups and we had to take the Commvault data off and write to StorageGRID directly (which is more efficient anyway) to reduce the load. It helped, but not really enough. I spent a bunch of time simply doing vol moves from head to head to force the data to tier.

  2. SnapVault with an all tiering policy sucks and we needed to set it to 3 days. Too much churn otherwise.

  3. We eventually switched to a FAS8300 pair with 192 1.8TB SAS drives. This is mostly keeping up. I bought this at the end of 2022. For less money today, I can buy a C400 with the same capacity but with QLC flash instead of SAS drives and in a much smaller footprint. It's a no-brainer if I was buying today.

sour cradle
#

Information provided here are very helpful.
While I am still trying to chewing information, one quick follow-up:

What steps should I go through, in order to have Linux clients can directly write to StorageGRID without going through "volumes-FP-SG" path? Any detailed document?

Thank you!

chrome eagle
#

StorageGrid is object only so you would have to have your Linux Clients write S3. I am assuming you are wanting to just have a NFS mount point and write to that though correct?

dawn night
#

The s3cmd packages will let you manipulate s3 storage from Linux clients. https://s3tools.org/s3cmd
I have tested s3cmd with StorageGRID and it works fine but I don't use it much though. Typically if I'm writing to S3 directly, the application already has support for that. For example, our Commvault backups can write to S3 directly and it's much more efficient than CIFS/FabricPool/StorageGRID.

Amazon S3 Tools: Command Line S3 Client and S3 Backup for Windows, ...

S3Cmd, S3Express: Fully-Featured S3 Command Line Tools and S3 Backup Software for Windows, Linux and Mac. More than 60 command line options, including multipart uploads, encryption, incremental backup, s3 sync, ACL and Metadata management, S3 bucket size, bucket policies, and more. List and query S3 objects using conditional filters, manage meta...

pulsar hatch
#

Any channel specific to storage efficiency

nimble yacht
gilded oak
sharp wind
#
  1. FabricPool does a LOT of scanning of disk blocks to decide what to tier. I mean a LOT. You can easily become spindle-bound. We started with a FAS2720 pair with 48 8TB SATA spindles. Major saturation. The data was coming in faster than we could tier.

A similar question about using "all" tiering policy for backup volumes on SSD aggregates@A400 AFF nodes.

I understand this shouldn't be a problem for SSD aggrs. However, since there are a lot of volumes involved with heavy writes(20+ volumes,10+ on each aggr), used as destinations for RMAN backups, and each volume can have a number of Linux clients. If they are all using "all" policy, FabricPool will do a lot of scanning, could this kind of workload cause performance degration to the SSD aggregates?

nimble yacht
#

We investigated it ourselves for cameras, and decided it wasn't worth it and just told the requestors that FAS is not an S3 proxy

sharp wind
#

From what ONTAP/WAFL should do in tiering, what it does differently in these two different policies: "all" or "auto(ex, 3d+)"? Will "all" policy do a LOT more scanning of disk blocks than "auto"? How frquently will it do in these two respctive policies?

wet glade
#

you could get some advantages from deduplication if you let the data sit on the primary disks long enough... the auto is still going to scan every volume once a day... no clue about "all"

#

or at least try to scan every day... scans on large volumes can take a very long time

sharp wind
#

  1. With "auto" policy, the tiering scanner should be run every 24 hours. I couldn't find any information on "all" policy.
    If it is also every 24 hours, then the data has to be staying in the performance tier first not directly to the capacity tier, that's contrictory for how "all" works.

  2. How can we determine if tiering scanner for "all" policy could slow down the performance?

wet glade
#

it's going to be a background/lower priority task... so primary protocol operations shouldn't be affected, but the scanning may not complete within the time you require and you'll fill your primary storage .

#

there's only so much disks can do

dawn night
#

In diag mode, you want to be running something like ' vol show-footprint -aggregate !aggr0* -field aggregate,volume-blocks-footprint-bin0 -sort-by volume-blocks-footprint-bin0 ' to see if your volumes are tiering as they should. If you have an all policy and your bin0 (performance tier) is large, then it's not tiering and you need to figure out why.

The most common things I've seen to prevent tiering is spindle saturation followed by head resource consumption. Don't expect a small filer to do much. Don't expect SATA drives to be your friends.
With the right amount of resources, FabricPool is absolutely awesome. With insufficient resources, it's an exercise in frustration.

gray swift
#

Tiering scanner doesn't respect HDD performance.

#

Honestly FabricPool on non-SSD systems is just a problem waiting to happen.

wet glade
#

i've used it for years with with SATA drives with few problems, but it's basically all archiving

gray swift
#

That's the best way to use FabricPool...