Fabio

When looking at questions like the one you raise, I think you have to consider all the different considerations, not just one. People that use products like USP-V and the StorageWorks XP Disk Array use those products because they know once they turn the product on, they’ll never turn it off. Not all data needs this kind of availability. That said, I think we all know that the high-end enterprise storage market has flattened out. I’m sure in part that’s because mid-range arrays are getting more scalable and have more of the enterprise-class features.

But to your point on scale-out/scale-up, that’s exactly why our P4000 (formerly HP LeftHand) and X9000 (formerly IBRIX) are key to where HP storage is going. The P4000 is a unique clustered storage architecture that allows customers to scale performance and capacity together in an iSCSI-based SAN. The X9000 is similar but for unstructured data. Over the coming months, you’ll start to hear a lot more about how these kinds of architectures are central to customers converged infrastructure strategies. Ciao!

This post was mentioned on Twitter by esignoretti: RT @dikrek: New blog: Sizing best practices and does Compellent follow them? http://is.gd/a5nUz // my comment here: http://bit.ly/d5f3GV…

Dimitris,

I’m not sure you’re understanding correctly how Compellent works, let me explain how it works basic-style:

First thing first, the concepts:

Tiers are organized like that:

1st Tier – Fastest disks
2nd Tier – Medium disks
3rd Tier – Slowest disks

and they’re dynamically chosen based on the available drives in the storage, every tier is subdivided in different RAID Levels and different Tracks.

To clear things up, let’s imagine that we have a system configured with:

15 active drives FC 450GB 15K
15 active drives SATA 1TB 7.2K

With this kind of system we would have:

Tier 1 – 15K drives
- Raid 10 Fast Tracks
- Raid 5-9 Fast Tracks
- Raid 10 Standard Tracks
- Raid 5-9 Standard Tracks

Tier 3 – 7.2K drives
- Raid 10 Fast Tracks
- Raid 5-9 Fast Tracks
- Raid 10 Standard Tracks
- Raid 5-9 Standard Tracks

I’m using an “old” example since right now you can also have Raid 6 in the mix but let’s leave that alone for now, also Raid 5-9 means that it’s a Raid stripe made of 8 Data blocks and 1 Parity block (You can also have Raid 5-5 if you want)

So in this system my data can live on those 8 “tiers”, right now when I create a new Volume (LUN) I can choose where to put my active data and my snapshot data just selecting a “Storage Profile”, for example let’s use a best practice for that:

The “Recommended (All Tiers)” default profile is the most used and it’s configured like that:

Write data on Tier1:Raid 10 and Tier2:Raid 10
Snapshot data on Tier1:Raid 5-9, Tier2:Raid 5-9, Tier3:Raid 5-9

I usually create another custom storage Profile called “Archival Data (R5-9)” that’s configured like that:

Write data on Tier3:Raid 5-9
Snapshot Data on Tier3:Raid 5-9

To accomodate the need for low impact stuff.

Considering that let’s see how the data flow is for those two profiles:

—- Profile “Recommended (All Tiers)”

- Data flow from the server hbas to Compellent front-end ports
- the Data stage to write cache (512MB per controller) and it’s replicated to the other controller.
- The data is written to disk on the Tier1, Fast Tracks in Raid 10.

The data is now on stable storage.

—- Profile “Archival Data (R5-9)”

- Data flow from the server hbas to Compellent front-end ports
- the Data stage to write cache (512MB per controller) and it’s replicated to the other controller.
- The data is cached until a full stripe write is possible.
- The data is written to disk on the Tier3, Fast Tracks in Raid 5-9.

The data is now on stable storage.

And that’s for the write data flow, there’s no such thing as continuous destaging to Raid 5 from Raid 10.

After the data is on disk there are several ways to progress to the lower tiers, if you just leave the Volume (LUN) alone, the system will continue to keep statistic for every “chunk” of data (512k, 2MB or 4MB), and then progress it slowly (the algorithm is based on access treshold on a 14-day basis) to the lower tiers, that’s not a “quick & dirty” destage to Raid 5.

Instead, if you take snapshot, either using scheduled snapshot or manually, the data progress quicker, just for example, let’s imagine we have a 100GB volume (LUN):

it’s 12.00 pm

- We write 10GB of data (let’s call it Data Blob 1), it’s in Raid 10 on Tier 1, Fast Tracks, and it’s consuming 20GB of raw space (100% raid overhead due to Raid10)
- take a snapshot of the volume

It’s 3.00 pm

- We write another 5GB of data (call it Data Blob 2), that’s also in Raid 10 on Tier 1, Fast Tracks, 10GB of Raw Space (grand total of 30GB)

Usually at 7.00 pm (that’s the default but it’s configurable) the Data Progression Job kicks in, due to the fact that Compellent’s snapshot are pointer based (just like NetApp) what we’ve called “Data Blob 1″ becomes a Read-Only Blob of data and it progress immediately to Raid 5-9 to get some free space back.
So the next morning we find the system in this situation:

Blob Data 1 who’s now part of the Snapshot Data is written in Raid 5-9 on Tier 1, Fast Tracks, consuming almost 12 GB of Raw Disk Space
Blob Data 2 who’s part of the Active Data is still written in Raid 10 on Tier 1, Fast Tracks, still consuming 10 GB of Raw Disk Space

We just got 8GB of Raw Disk Space back, without sacrificing performances, because “Blob Data 1″ is considered “Read Only” thus we don’t have to write Raid 5 but just read from it, eliminating the raid penalty.
If we’re going to write data on that volume we’ll still write to “Blob Data 2″ who’s still active data, still in Raid 10.

Said that, I would not imply that the configuration that you found from Compellent was right for the kind of workload the customer had, as I stated many times previously, I trust only *MY* configurations, made from a known set of information that *I* analyze, but I still hope that you can more easily wrap around your head on how Compellent works in detail and why you simply cannot take off the optimizations from the drawing board.

HTH,
Fabio

Techmute, Dimitris,

You don’t know the technology involved and it is very difficult for me to speak about theory and compare it with a real world case when we (me and Fabio) don’t know the environment of the customer!
I invite you to share with us all the informations about this particular case, at least:
- a complete sampling (28800 samples in 24h, one every 3 seconds for all the server involved)
- a full picture of the SAN (servers, applications, data)
- customer requests

or stop to confuse who is reading!

BTW, for that customer did you propose something like 23 disks???
This is very far away from 15 and we may continue to discuss for years about the subsized 12HDs Compellent configuration or the oversized 23 HDs NetApp one!
My first question may be: Why you are proposing 23 HDs when 16 (15+1 spare) are more than enough?

Then, please, let me know if you want to talk about the theoretical 3000 IOPS or the real world solution comprising a 12 disks system and relative optimizations.

Anyway, I suggest you to spend some time on the Compellent site (http://www.compellent.com) to look for some documentation and videos and learn a little bit more about the architecture ( http://www.compellent.com/Products/Architecture.aspx ) of the product, probably you will find some interesting readings about how the system works, this will widen your horizons.

Well, back to the theory.
Fabio wrote about the 3000 IOPS with 15*15K disk for the IO pattern you suggested, without any specific optimization, and I add that Compellent may do more with data placement optimization features (Fast Track). He never spoke about a 12K block size because it’s not important, we obtain similar results with 4,8,16K blocks.

The main difference between Compellent and others is the fully virtualized concept of the LUN thanks to block’s metadata: each LUN is dispersed in every disk of the system (SSD,FC,SAS,SATA) and with different RAID levels.
There is no staging area (I apologize if my simplifications were pushed to the limit) and all data movements (RAID level and tier) are done when the system’s load allows to.
All of this makes sense only if the system is properly configured.

ciao,
Enrico

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