but, how do I know what application requires how many IOS/GB,
The short answer for us:
"We don't worry _that_ much and use as few disks as possible and add disks or move if needed because we(with and without NetApp's assistance) have often failed at sizing" - Read below for longer answer.
-We have never been able to get this information reliably. It's also unreliable when someone gives you a number. So you may get some numbers your NetApp rep asks you to help you with your sizing, and you might be feeding your NetApp rep garbage numbers yourself. I'll give you a couple of observations:
1. When someone who's not a storage admin tells you that his/her application will do 5000 IOPs and is 500GB in size(thus 10 IOs/GB in your formula), it doesn't necessarily mean 5000 IOPs at the filer volume level, LUN, or aggregate. I have no idea if it is that the estimate provided is wrong, or if what is an op to an application(take a database for example) isn't
necessarily an op to a filer, but too many times I've heard that an application X will do Y number of ops and I find that it doesn't for storage.
2. That's not to say NetApp(I'm a NetApp customer, so YMMV with your account team) can't do sizing for you. They can, at the minimum, take your Oracle database's AWR and do its own sizing. They have also done sizing work for Exchange and SQL for us. I don't remember how SQL sizing went, but for Exchange it appeared that they take the number of your users (and probably mailbox size, but I'm not 100% sure) and a few other parameters and size that way. I'm operating from fairly old information and we don't do this often so YMMV.
3. So, none of this is probably particularly helpful in sizing. To be quite honest, for most applications, with the exception of probably Exchange, I have found sizing to be largely a guess-work with varying degrees of success. Sizing for one, or any small number of, database/application is not that helpful for us in a number of ways. One, we are a heavily shared infrastructure with a large number of apps, VMs and databases, and sizing an aggregate/controller for any one of those is not that productive because almost no one app/VM/DB has a controller(or controllers) to itself; We have dedicated aggregatest to specific applications/databases in the past and we have both oversized and undersized them in terms of perf. Two, we have enough controllers/aggregates of each type at this point and have had them long enough that a lot of the new applications are either incremental updates to what's already there(therefore we have historical performance data and that's more actionable data) OR we can ask the DBAs/app devs how they anticipate the new app to behave in comparison to existing apps. We certainly ask for hard IOP numbers anyway, but that is typically no more accurate than their estimate that it'd behave like an existing application named 'ABC'. Three, we keep enough HW on hand that if we undersize an aggr, we can add more disks. Or move it some place else. We do have a protocol in place to add a full raid group whenever we add anything, and at the max raid size. Historically, most any data we keep around grows in terms of space and/or I/O that nothing we create remains oversized from either perspective for very long. We do sometimes VolMove data in and out in both 7-mode/CDOT(or use a more traditional migration approach), but that's rarer than the data just growing organically where it sits. Four, we have a large number of apps/DBs AND add a large number of DBs over time that sizing for any one DB(or all) becomes old information fairly quickly. We actually tried to size them all once and that's what happened to us. So, yeah, size away, but be ready to adapt to the actual space and/or I/O growth.
how do I find out what is the requirement on response time?
-We ask the DBA/App dev, though this isn't always all that helpful. Not to throw people under the bus, but if you ask this question then the answer is often "the fastest you've got," and today that means some kind of storage with lots and lots of flash. A lot of DBs/apps do not take advantage of the excess resources for one reason or another. We have certainly had the opposite happen, but asking this question has, more often than not, led us to oversize at the aggregate level. We are going to a different approach where we will offer different tiers of storage at different price points in a more standardized manner.
