If you know you're storage bound, then benchmarks on your server won't definitively tell you how much you need. They can only tell how fast you can go while subject to the limited storage. In order to properly get the answer you're looking for, you need to, if possible, isolate the different ways you can be storage throttled and test them independently.
IOPS is of course the easy limit that everyone talks about, because disks are bad at seeking and databases like to seek. These days with cache and SSD, small block IO random seek reads are a lot easier than they used to be. A small tier of SSD and a large cache will probably ensure that if it really is IOPS (for small block "seek" type IO) that's your bottleneck, you won't be subject to it any more. Be careful about these benchmarks, though- you'll read all kinds of unrealistic numbers as people measure the number of IOs they can do straight to unmirrored cache. That's not going to help your linux server.
Another type of storage limit is bandwidth, or throughput. This one is hard to isolate, but if you know how much data you're trying to read or write and you know how long it takes you now, pick a new time target, and that'll be your new number. For example: if you observe your application spending 4 hours to do a large backup or something, and at the end of it, it's moved 9 TB, that tells you your current throughput limit: about 650 MB/s. If you want to move 18 TB in that time, you need 1300 MB/s. For the most part, ethernet, fibre, and SAS can all be configured to go faster than storage hardware. The storage's ability to keep that transfer layer full is usually the real bottleneck. You want to look at the number of front end ports, and the benchmark numbers with cache mirroring turned on (to ensure there's no bottleneck between controllers mirroring cached writes).
Lastly, you can be limited by bad storage configuration in terms of SCSI queues. This is not ridiculously common, but is defined by being unable to push your storage hardware as fast as it should go. If you are seeing 500ms latency on writes from the host, but your storage reports 3ms 100% cache hits, that can be an issue with insufficient SCSI queues on the target. Basically the SCSI initiator is waiting up to 500ms to free up a slot in its queue it can use to take requests. You want to ask your storage vendor for the best practices on host queue depth settings and fan-out ratio for this.
I hope this helps, I know it's not as simple an answer as you were hoping for.