Ryan,
So several others have weighed in with options, I personally have a different view
and so far the deployments i've been involved in have all required multiple filesystems per cluster, with different capacity and performance requirements per filesystem.
Because of this I prefer to use a configuration that uses 5% of the RG disk size per Vdisk, and build 20 Vdisks per RG
This gives me the flexibility to add and remove more manageable capacity increments, and or split unused Vdisks up and move them around between file systems as required.
If I was building for a single Filesystem then yes I would use 1 or 2 Vdisks per RG, and potentially an RG per Expansion Shelf to cater for future expand-ability, however on average i've found that most of my scale clusters have at least 2 filesystems some have between 6 & 8 filesystems and in these scenarios having the flexibility to move capacity around was a priority.
By using at least 5% of the RG size I am still able to get all of the performance of all of the drives in the RG if its not being used elsewhere, this also allows me to calculate what percentage of a Building block's performance I am allocating to a filesystem based on the number of vdisks per building block i've added to that filesystem and provide a Min performance / Max performance number for a filesystem.
Regards,
Andrew Beattie
File and Object Storage Technical Specialist - A/NZ
IBM Systems - Storage
Phone: 614-2133-7927
E-mail: [email protected]
----- Original message -----
From: Ryan Novosielski <[email protected]>
Sent by: [email protected]
To: gpfsug main discussion list <[email protected]>
Cc:
Subject: [EXTERNAL] Re: [gpfsug-discuss] Any guidelines for choosing vdisk size?
Date: Mon, Jul 1, 2019 4:01 PM
Sure; thanks, I meant to add those details:
In our case, all GSS/DSS-G with GNR.
The context here is general information, but specifically designing new filesystems/setting up one of these systems from scratch in what I’d figure to be the traditional way: don’t allocate the entire storage if you’re not totally sure the way the growth will go, but don’t leave behind unusable space or space that forces you to later change vdisk sizes. Essentially allocate something today that makes sense, but leaves room open for sensible growth with both the existing hardware and new, if expanded. If I’m thinking about this generally the wrong way, let me know.
The systems we currently own are GSS26 (6 TB drives, fully populated — I forget how many drives, 350 or so?) , and a few DSS-G 220 w/10 TB drives (also fully populated with 168 drives).
> On Jul 1, 2019, at 1:54 AM, Andrew Beattie <[email protected]> wrote:
>
> Hi Ryan,
>
> Can I ask a couple of clarifying questions?
>
> Is this in an ESS / GSS environment with Scale native raid ?
> Is this in classic San attached storage environment / or Direct Attached Disk without Scale Native Raid?
>
> What are you trying to achieve?
> Are you presenting the Vdisk into an existing filesystem ?
> Are you creating an new filesystem?
>
>
> Regards,
>
> Andrew Beattie
> File and Object Storage Technical Specialist - A/NZ
> IBM Systems - Storage
> Phone: 614-2133-7927
> E-mail: [email protected]
>
>
> ----- Original message -----
> From: Ryan Novosielski <[email protected]>
> Sent by: [email protected]
> To: gpfsug main discussion list <[email protected]>
> Cc:
> Subject: [EXTERNAL] [gpfsug-discuss] Any guidelines for choosing vdisk size?
> Date: Mon, Jul 1, 2019 3:43 PM
>
> Good morning,
>
> Was wondering if anyone could point me to any tips or provide some regarding choosing vdisk size? My understanding is that too small is a waste of resources in the form of overhead, and that there is an upper limit. but that generally within a pool, you want them to be the same size, so that if you aren’t allocating the entire storage space on the system straight off, you’ll need to choose a reasonable size or be left with unusable space (eg. you will waste space if you went with, say, 200 GB vdisk sizes on a 500 GB array).
>
> Anyone have any tips? Do people just generally allocate the whole thing and have one 2 vdisks (redundancy)? Seems you have some more flexibility if you don’t do that and have to, say, create a storage pool or filesystem from scratch to take advantage of features in a newer FS version or what have you.
>
> Thanks for the help — spent a lot of time looking for this previously, but never asked on the list.
>
> --
> ____
> || \\UTGERS, |---------------------------*O*---------------------------
> ||_// the State | Ryan Novosielski - [email protected]
> || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
> || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark
> `'
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
