How do you calculate IOPS for a CX4 array which has FAST?

Are you asking about forensic analysis (after the fact? If so....You can get IOPS rates for the LUNs from Navi Analyzer.

RE FAST Cache: IOPS are counted to a LUN whether the IO hit FAST Cache or not. FAST Cache 'hit' stats are given similarly to DRAM cache statistics.

RE FAST: Are you asking how to determine at which tier the IOPS were serviced? That's a tougher thing to do as Analyzer won't tell you that. There used to be a LUN IO DIsk Detail that shoed each LUN's contribution to the underlying disks' activity, but that is not provided for Pool LUN. For pool LUNs you can see the stats drives in the pool, but that's aggregate stats, for all the LUNs' activity on those drives. But, at least you can tell which drives are busy and thus gauge your tiering effectiveness.

Are you asking for a priori analysis, in the design phase? For that you need to know the IOPS-derived skew of % IOPS over %capacity. There are tools available to USPEED personnel which can tell you, for an existing CLARiiON system, the Skew at a sublun (1 GB slice) level, which is the level used by FAST VP to track and adjust to activity.

Hi David,

Thanks for your response.  I am asking in regards to the design phase.  If there was some sort of formula to use it would be great.  I guess what I would need to know is if I need LUNs to service so many average IOPS, in terms of a Storage Pool, what is required?

On traditional RG you would have just worked this out as IOPS per disk with RAID overhead and dividing that into the total IOPS would give you a good idea.  I guess its the same calculation only you need to know down to a 1GB slice level where all the data would exist.

How could you know where it would exist though, if it is an existing workload you could collect info on it and work it out from there but if its a new workload, for example VDI POC for 2000 users and you've never run a workload like this for the customer then you are shooting in the dark.

To really oversimplify I guess if you add up the IOPS from each tier this would give you the total IOPS and you know if this is higher than what you need it should be enough to service your IO.  In that case you may hope the top tier has enough storage to promote all the hottest slices to it.

Regards

Steven

RE: "I guess if you add up the IOPS from each tier this would give you the total IOPS..." Yes that's the approach. And to get that far you need to have some guess for the skew - distribution of IO across capacity -- to know how many IOPS to assign to each tier. Our Unified SPEED (USPEED) gurus have a tool -- UBLA -- that can do that calculation, given an existing CLARiiON system. That requires gettin a trace file from the array while under load. There are also tools that try to do this with NAR information but NAR is not sublun, so NAR analysis is not as accurate.

The last part of the design is to calculate "tier miss" -- the number of IOPS that might miss the top tier due to a new app starting up, doing reports on older data etc. Make sure your lower tiers have enough capability to absorb some fraction of the workload allocated to the tier above. I use 10% as a minimum there.