2. Is it true that each controller requires three disks for it's own use and, therefore, in an active-active configuration with dual controllers, six out of the total 12 disks will not be available for storage ? If so, what is the reason for this ?
I have stumbled over your post this afternoon, and wanted to post a brief reply with my contact details on as I work for a NetApp partner in the UK and I would be keen on discussing things with you in greater detail.
In the first instance our company website is www.cetus-solutions.com and our head office number is 0161 848 4315. I will drop you a private message with my email address and mobile number so you can contact me directly when you have an opportunity to do so.
Wow. I'll do my best to answer these. NetApp does things a bit differently so these questions are quite common and usually handled by a Systems Engineer. Since you've had a tough time getting a reseller, I'll help with your questions as I'm an SE in the US.
1. The difference between those models is the A model is an HA pair in the same chassis. This is a very typical configuration for production environments because high availability isn't really an option anymore.
2. It's not exactly true. What's true is that each controller must have a root volume. However, that root volume can live in a aggregate that is shared with other data volumes.
3. Hopefully #2 answered this. Keep in mind that on a per GB basis, you typically have small or cheap. The cheaper disks tend to be SATA which are large while the more expensive disks tend to be FC/SAS which are smaller (but faster).
4. Yes according to #2. As to whether it makes sense to get 2 non-HA systems and mirror them, I'm not sure you will end up ahead. I suppose it depends on what problem you are trying to solve. A normal HA solution will require 1 aggregate per head but so would 2 non-HA controllers. Plus the later would require 2x the storage in order to replicate as well as a license for the replication software. So if cost and efficiency are the goals, a standard HA config wins hands down as the later requires more storage and software plus your storage utilisation (before any thin provisioning and dedup) starts at 50% and goes down from there from data replication. You'll get some, perhaps much, of that back with thin provisioning and dedup, but you'd get those savings on the HA solution as well so it's fair to take them out when comparing. Also with the HA pair, failover is built-in and automatic. With the 2nd config I expect there to be some manual intervention to get the failover.
5. Hot spares are global across the appliance, even expansion shelves assuming the same speed disks. e.g. You don't have a 7200 rpm SATA fill in for a 15K rpm FC disk. However, expect to have one spare per controller.
6. Yes this true. Supporting any disk out there would be a support nightmare. Trust me on this.
7. We have no word as yet on when the 2020 will go EOL. New drives for EOL hw is usually dependent on suppliers of those drives and we strive to offer them as long as we can. Replacement disks under your support contract will continue for 5 years after the EOA announcement.
8. Yes. Snapshot blocks are not physically moved from the volume. This is a good thing because it is a big reason why NTAP snapshots do not adversely affect performance. Moving blocks around takes lots of extra iops. ONTAP supports up to 255 snapshots per volume and you can use all of them as long as you have the space without hurting your performance. This is not the case for many storage systems out there.
9. Yes, that is a good outline of the provisioning process. The dedup limit goes up you go up in models (and sometimes in OS rev).
10. Upgrades are included in the SW support contract. So along with access to tech support, knowledge bases, etc. You get a software subscription that entitles you to download new versions as well as patches to existing releases.
Hope this helps. If you aren't getting much help from the resellers directly, that you try a local NetApp sales office as they should be able to refer you.
-- Adam Fox
Thank you very much for that very helpful reply, much appreciated. It clears a lot up. I'd agree that the A variant is probably the one to go for since HA is a requirement for us, especially since we're doing a lot of consolidation. I also like your thinking about using HA rather than mirroring two arrays. Having two arrays does allow us to place them both in different sites. We might yet consider that as a future upgrade.
I assume when you say each controller has to have a root volume, it is not possible (or best) to put both root volumes on the same aggregate ? Your answer to #4 implies that an aggregate must be assigned to each controller, so there would have to be a minimum of two aggregates. That's fine by me, slightly less flexible than I'd like but not insurmountable.
My questions about disk allocation to controllers come from a number of postings over on the XenServer forums that I found while googling on this subject. Specifically, this one :
Quote : "Also we were fitted with dual controllers with 6 assigned to each controller. 3 drives went to the OS for controller A, 3 more drives went to the OS for conroller B, and out of the remaining 6 we had 2 set aside for hot spares. Out of 12TB of drives we ended up with something crazy like 1TB of acutal usable data."
I'm sure the guy (who repeats this on several different threads) does not intend to be malicious, but it sounds like he is badly misinformed.
One of the dealers on the internet is quoting a good price for a refurbished expansion shelf with 12x 500GB drives installed. So, let's say I go for a FAS2020A and a shelf giving a total of 24 500GB SATA disks. What would be the optimal configuration with a good degree of reliability ? I hope you're going to say I should have two spares and two 11-spindle RAID-DP aggregates If so, assuming two parity disks per aggregate, that would give me 18 spindles worth of storage = 9TB.
There is certainly no problem in getting a 2nd location later. One of the nice parts of the NetApp unified architecture is that you can replicate between any models. So you could buy a bigger unit later and redeploy your older unit elsewhere.
Each controller must have at least one aggregate but that aggregate can contain both a root and various non-root volumes. It is not necessary to dedicate an aggregate for root volumes. So you may have a single aggr on each controller of a few TBs. Then you can set aside a few GBs for a root volume, then create as many data volumes as you like.
You are close on your allocations. I would recommend 1 spare per controller. 2 parity per controller and the rest is data. Now your usable space will be less than 1TB per pair of data drives due to things like formatting and other overheads. An SE can help you with those calculations. Of course you'll get much of that back in other efficiencies.
As for the guy in the Cirtrix forum's config. I can only speak to it specifically however it would appear from that sound bite that it could have been done with a much higher yield.
-- Adam Fox
Much appreciated once again, thank you.
Understood on the storage allocation. I was trying to get an idea of the raw storage (before formatting but after RAID/spares/etc overheads) to compare it with the pair of arrays we've already got whenever I'm making my case. Those arrays are configured as pairs of mirrored disks used as JBOD (it doesn't do stacked RAID in hardware!), so the yield is somewhat lower; 4.5TB per array (before formatting). So what I'm figuring is that a setup with 24 500GB disks will give me roughly the same amount of storage as our current 28-disk setup has, with better performance due to using RAID-DP across lots of spindles . And that's before the benefits associated with dedupe and over-allocation kick in.
I will try to get in touch with the local NetApp office here to see if I can get a reseller to talk to me.