He posted a comment some hours ago to your post.

BTW, I would like to add that Fabio hasn’t considered Fast Track in his comment, this data placement optimization feature can add a variable (some times slightly important) performance improvement to your disks.

ciao,
Enrico

Correct, 418GB is raw usable space when converted in base2. This system has 11 active disks so you have 11*418 = 4598 usable space before raid.
Compellent RAID protection is quite different from other vendors: you don’t need to define RAID groups but you go directly to create LUNs from the usable space!

In the LUN creation wizard you will associate a profile to the LUN: the profile defines the behavior of the LUN. There are standard (out of the box) and custom (user created) profiles. In the profile are defined all the RAID levels and tiers for the LUN. You can also modify profiles and LUNs properties on the fly.
i.e.: you may define a DB LUN to be positioned on RAID 10 Fast, RAID 10 standard, RAID5 standard and snapshots on RAID 5 standard.
So, you will write and access each new and hot block on “fast tracked” RAID 10 and, on the other hand, old and less used blocks are automatically migrated to RAID5 on less valuable tracks saving space and speed!!!
To say if the 11 disks can provide 3000 IOPS I need to know more about applications/servers and data involved but, I repeat, it is hard but not impossible.

Now, go back to the usable net space after RAID: we will have a variable net space (after RAID) ranging from half the raw space (4598/2=2299) to 4092GB for RAID 5 made with 9 disks stripes. The real space depends on how are organized the profiles and data activity… but if we can hypothesize something like 20% of RAID 10 and the rest of RAID5 you will obtain about 450GB net of RAID1 and 3270 net of RAID5. The Total net usable in this case is 450+3270=3720GBs.
This can be changed with a pair of clicks, the system will start immediately to work with the new profile freeing or allocating space as needed!

With this architecture you need to change drastically how to think about storage metrics and it is very important to analyze in deep the environment.
In a well sized and configured Compellent system you will write and read heavily accessed blocks on faster portion of disks (or on SSDs) and you will not pay for a write penalty due to RAID calculations getting awesome performance and space savings.

It’s not useful to answer how many spindles I use to write in RAID 5 because I don’t need to write in RAID 5 and pay a penalty. I will write in RAID 10 and then the systems move the blocks to RAID 5.

ciao,
Enrico

11 SAS disks * 177 IOPs/disk = 1947 IOPs * 20% boost for FastTrack = 2336.4 IOPs.

That still is 600+ IOPs way from the 3000 sustained number that you cited….what am I missing here? Even if cache is in play, there still has to be enough steady IOPs to keep the flushed during a sustained 3000 IOPs workload.

My thoughts were only on the ability of Compellent to offer less disks than other competitors because of features capable to get more optimized access to disks, as I wrote in my post, I don’t know enough details about the customer, the environment, prerequisites, etc. So I will continue only to show you the Compellent capabilities at my best.

Fast Track and Data Progression are tightly integrated and they achieve awesome results if coupled: I assumed an advantage in about 20% of performance improvements as an example but it can be slightly more in function of the environment (I personally saw 7000 sustained IOPS from an Oracle ERP server on 15*15K+15*10K disks !!! ).

BTW, I will try to clarify better my points:

Compellent uses 450GB SAS disks (418GB really).
In your case we will have 418*11=4598GB of usable space and, of course, 919GB of Fast Track. Each block on Compellent has its RAID level so the real net space varies from 919/2 for RAID1 to 817GB for RAID5-9, this space will reserved and freed dynamically. I don’t think that this customer has more than 800GB of active data in a system capable to deliver only 4TB!

To recap in a very coarse way: Each write is performed on FastTrack then blocks will be migrated to other RAID levels and/or portion of disks in background at a low priority (this operation doesn’t impact on front end performance). All managed by system policies and volume profiles.

Finally, it is hard but not impossible to achieve 3000 sustained IOPS on a well configured Compellent with 11 active disks,

ciao,
Enrico

D

Second, although I can see the benefit of using the outside of the disk how much data can you fit in that outer edge? If you get 20% boost on the first track that would have to reduce as you move in. Therefore, much like cache you would have to assume that the customers working set would fit into this “Fast Track” area. Is that correct?

As I said, it is a great explanation and I learned lots but it still seems to be cutting things dangerously close.

[Full disclosure - I am a NetApp Employee]

Keith

@esignoretti I have a post on boot from SAN, but its not in Italian. http://bit.ly/b0abSw

grazie Calvin.
ES

Thanks again for the opportunity to participate, we are proud to work with Cinetica.

Andy