Take 336 and subtract out your 4 disks, which leaves 332. See what numbers below 29 (since the raid group max size is 28) give you no remainder. Of course, 2, 4, 8 and 16 disk RAID groups divide evenly (just off the top of my head), but you didn't ask to maximize space. I'd have to believe that is a consideration. If you want to do that, use 28 disk RAID groups and you'll have 11 28 disk RAID groups, and 1 24 disk RAID group ( I think that's correct. too lazy to get a calculator out.) Of course, if you need all volumes the exact same size, that won't work. It's all a matter of understanding what you need out of the system. Keep in mind that if you make your RAID groups too small, you're going to pay more in parity and dparity disks than you would with spares. If you're like us, the # of volumes was just as important as any other factors ( I had a minimum that I needed from the system), as well as the net usable space.
Jason
On Jul 1, 2004, at 7:44 PM, Michael Christian wrote:
Why would DP cut your max raidsize in half? If anything, it should increase it, though I doubt Netapp allows it.
Here's a quiz for everyone:
Q: You have a fully loaded R200, 96TB, 24 shelves, 336 disks. You use a 2 disk root vol and want no more than 2 hot spares in the system. What raidsize do you use, so as not to end up with an inordinate number of spares?
-----Original Message----- From: Hill, Aaron [mailto:aaron.hill@cba.com.au] Sent: Wed Jun 30 17:41:38 2004 To: 'James Brigman'; toasters@mathworks.com Subject: RE: RAID Group Size Limits?
The absolute limit will depend on both your platform (FAS900 series, FAS250, R100, R150, R200 or F series) and ONTAP Version. Check the ONTAP release manual for your version. For example, 6.5 supports max of 28 for FAS900 & F series filers. I think this has been the same for quite a few releases.
RAID DP cuts that in half.
Seems you have two goals;
Consolidate exisiting volumes into fewer, larger volumesGet some performance increase by increasing spindlesYou can make your volumes & raid groups larger and thus get more spindles. However, there are two questions you need to answer first;
Are you sure that disk I/O is the bottleneck in your DBperformance? i.e. Run a statit analysis on your filer for some high and low usage periods over the next few days and examine the results.
How important is volume restore time? Remember, the larger thevolume, the longer it will take to restore if there is a double-disk failure. (Of course, you can always mitigate some of the risk here by upgrading to 6.5.1 and using RAID DP, however this limits you to max raid size of 14). I believe NetApp recommends to keep volumes under 0.5? TB for this very reason.
Now, if (1) is true and (2) is not so important, you still have one more thing to keep in mind;
Increasing spindles follows the law of diminishingreturns. I recall reading somewhere that the optimum raid size for performance was 10-14, anything larger than that and the performance return is exceedingly small.
At one place we ran Sybase DB's on 36G disks with RAIDsizes of 10 & 12 with good results. Although there are a lot of other factors that come into play with DB performance.
Ok, that should be enough information to help you make some preliminary judgements. Let me know how you go.
Aaron
From: James Brigman [mailto:jbrigman@nc.rr.com] Sent: Thursday, 1 July 2004 9:06 AM To: toasters@mathworks.com Subject: RAID Group Size Limits?
Does anyone on the list have experience with RAID group size limits?
I seek to convert my qty 5 small volumes for Oracle into qty 2 volumes (one big, one little) for oracle and use lots of spindles. In fact, I'd like to just do a big, giant volume on my filer and put everything in qtrees shared/exported.
Anyone out there done this yet? Hit any RAID size limits?
Thx;
JKB
************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: www.commbank.com.au