Comprehensive data protection for all workloads
chris_lalala
Influencer
Posts: 10
Liked: 3 times
Joined: Jun 26, 2013 8:12 am
Full Name: Chris
Contact:

[MERGED] Stripe Size UCS S3260

Post by chris_lalala »

Hi together,

I'm a litte confused about the different Stripe Size recommendations.

https://www.veeam.com/wp-veeam-availabi ... guide.html
tells me to set 64k Stripe Size

https://bp.veeam.expert/repository_serv ... types#refs
tells me 256kb Stripe Size

https://bp.veeam.expert/repository_serv ... torage-das
tells me 256kb or greater

I bought a S3260 with 56 8 TB Disks

So my thoughts were:
1x Raid 60 as recommended in the Deployment Guide
ReFS Target with 64 kb
512kb Stripe Size

My Jobs uses mostly reverse increments.

The goal of the Stripe Size should be performance over space efficiency.
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Stripe Size UCS S3260

Post by Gostev »

Hello, we recommend 256KB RAID stripe size. Thanks!
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Stripe Size UCS S3260

Post by tsightler » 2 people like this post

I would say that 256KB is the general "best practice" size if you just want to go with something without testing. It generally works well across a wide variety of hardware and helps to minimize the overall IOPS are there are tons of deployments using this size with success.

Picking an exactly perfect stripe size for any given situation is quite difficult, but one of the primary benefits of a larger stripe size is to reduce the IOP burden on the individual disks during operations as, for spinning disks, IOPS are typically the most constrained resource.

Just for a super simplified example (liberties taken in details to make the example easy) imagine the average size of a block in Veeam is 512KB. If I have a RAID with 12 drives, and I read that 512KB block with a 64KB stripe size, I need to read data from 8 drives, witch effectively is 8 IOPS, a single IOP per drive, on the other hand, if I use 256KB stripe size I only need to read data from 2 drives for the same 512KB block, effectively reducing the load to 2 IOPS and allowing those other 6 drives freedom to perform IOPS for other blocks.

Now, this ignores some of the challenges of write overhead with RAID5/6, which can be significant with large stripes sizes in arrays with a large number of disks. It probably doesn't make sense to go much more than 256KB in any case (generally really large blocks are useful only for large sequential read/write), and, because the S3260 can have up to 56 drives, I can see why the alliances team might choose to align stripe size with ReFS block size as it generally has a good number of IOPS already.

On the other hand, when you have a small number of disks, larger stripe sizes are more critical because of the small number of overall IOPS available, that's why the standing recommendation is for 256KB, it just generally works fairly well across everything, for the small deployment with a handful of drives to large deployments with dozens of drives. However, if you have a lot of drives and a powerful RAID controller, there's probably not too much difference between 64KB and 256KB. Usually when I've seen performance issues with customer setups, it's when they are either really small (<=32KB) or really large (>1MB).

Personally I would not recommend 512KB or larger because a significant percentage of blocks will be smaller than the stripe size, which is generally less than ideal.
chris_lalala
Influencer
Posts: 10
Liked: 3 times
Joined: Jun 26, 2013 8:12 am
Full Name: Chris
Contact:

Re: Stripe Size UCS S3260

Post by chris_lalala » 1 person likes this post

Ok, thank you so much for explaining!

Can't wait to see the new Host performing ;-)
rschols
Novice
Posts: 8
Liked: 4 times
Joined: Sep 09, 2016 1:12 pm
Contact:

Re: Stripe Size UCS S3260

Post by rschols »

Dear tsightler,

Please clarify something for me.
tsightler wrote: Jun 03, 2019 4:53 pm Just for a super simplified example (liberties taken in details to make the example easy) imagine the average size of a block in Veeam is 512KB. If I have a RAID with 12 drives, and I read that 512KB block with a 64KB stripe size, I need to read data from 8 drives, witch effectively is 8 IOPS, a single IOP per drive, on the other hand, if I use 256KB stripe size I only need to read data from 2 drives for the same 512KB block, effectively reducing the load to 2 IOPS and allowing those other 6 drives freedom to perform IOPS for other blocks.
Is this describing strip size? Not stripe, with the extra E at the end?

I'm not trying to be clever here, I'm really just asking. Vendors seem to use various names for strip/chunk/element, but all vendors seem to agree that stripe is something that crosses all disks. As a result, I am confused about the Veeam documentation.

The way I understand: in your example scenario with a RAID with 12 drives, with a stripe size of 64kb, that means all disks need to be read to combine to 64kb in total. That means to read 512kb, I need to read 8 stripes, which means 8 x 12 = 96 IOPS.

My raid adapter (HPE SmartArray P-series) requires me to pick a strip size and the stripe size then depends on the total number of drives: stripe-size = strip-size * (data drives - parity drives)

Please clarify?

Kind regards,
Robert
TinchoB
Enthusiast
Posts: 29
Liked: 3 times
Joined: Nov 17, 2020 9:49 pm
Full Name: Martin B
Contact:

Re: Recommended best allocation unit size for repository volume?

Post by TinchoB »

Hello,
following this topic, has someone tried to set up as the DAS Storage repository a SAN Storage system (like a Dell ME4012 or MSA 2040/50) with an ADAPT RAID array (or DDP RAID array) with a 12 drive (12TB NL-SAS) ?
These RAID types (ADAPT or DDP) has a fixed Strip Size of 512k (chunk). Do you think it has an advantange from the performance side or its better to go with RAID6 with strip size 256k ? (10+2 HDD).

Thanks,

Tincho
Post Reply

Who is online

Users browsing this forum: Brian.Knoblauch, Google [Bot], Semrush [Bot] and 214 guests