[gpfsug-discuss] Any guidelines for choosing vdisk size?

Uwe Falke UWEFALKE at de.ibm.com
Mon Jul 1 09:29:49 BST 2019


gpfsug-discuss-bounces at spectrumscale.org wrote on 01/07/2019 09:25:23:

> From: Michael Hennecke <mhennecke at lenovo.com>
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
> Date: 01/07/2019 09:38
> Subject: [EXTERNAL] Re: [gpfsug-discuss] Any guidelines for choosing
> vdisk size?
> Sent by: gpfsug-discuss-bounces at spectrumscale.org
...
> Either way, it is a good idea (in environments with more than a 
> single building block) to put aside a small "test" vdisk per RG just
> for performance testing. So you can do performance validations on 
> each building block individually even if your main filesystem spans 
> all building block. Size of that "test" vdisk should be big enough 
> so you can run a few minutes of sequential IOR against it without 
> filling it up 100%.

However, be aware that GNR limits the number of ptracks per vdisk 
according to the vdisk size. That could limit the seen performance 
especially for writes. 
I've experienced that with vdisk sizes of 509GiB in DAs of 288TiB of ESS 
GL4 (can't recall exactly if ptracks are assigned by absolute or by 
relative vdisk size). 


 
Mit freundlichen Grüßen / Kind regards

 
Dr. Uwe Falke
 
IT Specialist
High Performance Computing Services / Integrated Technology Services / 
Data Center Services
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Rathausstr. 7
09111 Chemnitz
Phone: +49 371 6978 2165
Mobile: +49 175 575 2877
E-Mail: uwefalke at de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Business & Technology Services GmbH / Geschäftsführung: 
Thomas Wolter, Sven Schooß
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, 
HRB 17122 


gpfsug-discuss-bounces at spectrumscale.org wrote on 01/07/2019 09:25:23:

> From: Michael Hennecke <mhennecke at lenovo.com>
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
> Date: 01/07/2019 09:38
> Subject: [EXTERNAL] Re: [gpfsug-discuss] Any guidelines for choosing
> vdisk size?
> Sent by: gpfsug-discuss-bounces at spectrumscale.org
> 
> Ryan,
> 
> That is a question with many variables. Some of the factors 
> influencing the decision are:
> * Are you sharing data and metadata (the GNR default these days), or
> are you building separate data and metadata vdisks (the "older" 
> default, and still useful for some use cases)? If you have separate 
> metadata, you need to ensure you leave enough free space in the RGs 
> to account for metadata growth beyond your initial sizing.
> * Are you creating vdisks for multiple filesystems on the same 
> building block, or just for one filesystem? 
> * How likely is it that space needs to be (re-)allocated between 
> different filesystems?
> * How likely is it that new storage will be added to existing 
filesystems?
> * Is there a requirement to include building blocks of different 
> size (different #disks, or different capacity of disks) in the same 
> filesystem?
> 
> All of these influence the decision on the "best" vdisk quantity and
> capacities. If you have a specific configuration question, I'm happy
> to discuss that offline.
> 
> In general I advise customers to use at least two equally sized 
> vdisks per RG (4 per building block), so there is more flexibility 
> when capacity needs to be moved around. But many sites that have 
> homogeneous building blocks and don't expect changes in their 
> storage configuration just go with a single vdisk per RG (2 per 
> building block).
> 
> Either way, it is a good idea (in environments with more than a 
> single building block) to put aside a small "test" vdisk per RG just
> for performance testing. So you can do performance validations on 
> each building block individually even if your main filesystem spans 
> all building block. Size of that "test" vdisk should be big enough 
> so you can run a few minutes of sequential IOR against it without 
> filling it up 100%.
> 
> 
> Mit freundlichen Grüssen / Best regards,
> 
> Michael Hennecke
> HPC Chief Technologist - HPC and AI Business Unit 
> mailto:mhennecke at lenovo.com
> --
> Lenovo Global Technology (Germany) GmbH * Am Zehnthof 77 * D-45307 
> Essen * Germany 
> Geschäftsführung: Colm Gleeson, Christophe Laurent * Sitz der 
> Gesellschaft: Stuttgart * HRB-Nr.: 758298, AG Stuttgart
> 
> -----Original Message-----
> From: gpfsug-discuss-bounces at spectrumscale.org <gpfsug-discuss-
> bounces at spectrumscale.org> On Behalf Of Ryan Novosielski
> Sent: Monday, 1 July, 2019 07:43
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
> Subject: [External] [gpfsug-discuss] Any guidelines for choosing vdisk 
size?
> 
> 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 - novosirj at rutgers.edu
> || \\ 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
> https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-
> 
siA1ZOg&r=fTuVGtgq6A14KiNeaGfNZzOOgtHW5Lm4crZU6lJxtB8&m=XHrjWG2mnps3wxUISQHIZDR08HKkIKdcekRQibivZB4&s=wO1NamNaVBSnk_Kbe7Xl45aGtu7W6CBj0tHOlysTui4&e=
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-
> 
siA1ZOg&r=fTuVGtgq6A14KiNeaGfNZzOOgtHW5Lm4crZU6lJxtB8&m=XHrjWG2mnps3wxUISQHIZDR08HKkIKdcekRQibivZB4&s=wO1NamNaVBSnk_Kbe7Xl45aGtu7W6CBj0tHOlysTui4&e=
> 





More information about the gpfsug-discuss mailing list