<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >Ryan,</div>
<div dir="ltr" > </div>
<div dir="ltr" >So several others have weighed in with options, I personally have a different view</div>
<div dir="ltr" >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.</div>
<div dir="ltr" > </div>
<div dir="ltr" >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</div>
<div dir="ltr" > </div>
<div dir="ltr" >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.</div>
<div dir="ltr" > </div>
<div dir="ltr" >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.</div>
<div dir="ltr" > </div>
<div dir="ltr" >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.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Regards,</div>
<div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="margin-top: 20px;" ><div style="font-size: 12pt; font-weight: bold; font-family: sans-serif; color: #7C7C5F;" >Andrew Beattie</div>
<div style="font-size: 10pt; font-weight: bold; font-family: sans-serif;" >File and Object Storage Technical Specialist - A/NZ</div>
<div style="font-size: 10pt; font-weight: bold; font-family: sans-serif;" >IBM Systems - Storage</div>
<div style="font-size: 8pt; font-family: sans-serif; margin-top: 10px;" ><div><span style="font-weight: bold; color: #336699;" >Phone: </span>614-2133-7927</div>
<div><span style="font-weight: bold; color: #336699;" >E-mail: </span><a href="mailto:abeattie@au1.ibm.com" style="color: #555">abeattie@au1.ibm.com</a></div></div></div></div></div></div></div></div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Ryan Novosielski <novosirj@rutgers.edu><br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>Cc:<br>Subject: [EXTERNAL] Re: [gpfsug-discuss] Any guidelines for choosing vdisk size?<br>Date: Mon, Jul 1, 2019 4:01 PM<br>
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >Sure; thanks, I meant to add those details:<br><br>In our case, all GSS/DSS-G with GNR.<br><br>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.<br><br>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).<br><br>> On Jul 1, 2019, at 1:54 AM, Andrew Beattie <abeattie@au1.ibm.com> wrote:<br>><br>> Hi Ryan,<br>> <br>> Can I ask a couple of clarifying questions?<br>> <br>> Is this in an ESS / GSS environment with Scale native raid ?<br>> Is this in classic San attached storage environment / or Direct Attached Disk without Scale Native Raid?<br>> <br>> What are you trying to achieve?<br>> Are you presenting the Vdisk into an existing filesystem ?<br>> Are you creating an new filesystem?<br>> <br>> <br>> Regards,<br>> <br>> Andrew Beattie<br>> File and Object Storage Technical Specialist - A/NZ<br>> IBM Systems - Storage<br>> Phone: 614-2133-7927<br>> E-mail: abeattie@au1.ibm.com<br>> <br>> <br>> ----- Original message -----<br>> From: Ryan Novosielski <novosirj@rutgers.edu><br>> Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>> Cc:<br>> Subject: [EXTERNAL] [gpfsug-discuss] Any guidelines for choosing vdisk size?<br>> Date: Mon, Jul 1, 2019 3:43 PM<br>> <br>> Good morning,<br>><br>> 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).<br>><br>> 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.<br>><br>> Thanks for the help — spent a lot of time looking for this previously, but never asked on the list.<br>> <br>> --<br>> ____<br>> || \\UTGERS, |---------------------------*O*---------------------------<br>> ||_// the State | Ryan Novosielski - novosirj@rutgers.edu<br>> || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus<br>> || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark<br>> `'<br>><br>> _______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at spectrumscale.org<br>> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a> <br>> <br>> <br>><br>> _______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at spectrumscale.org<br>> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a> <br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a> </font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>