C-Drive 2010 – Get to the core of Fluid Data

Like every year, May is the chosen month for my trip to Minnesota, I’ll fly with Enrico to the 10.000 lakes state to attend C-Drive 2010, the Compellent yearly event where everyone involved with this wonderful storage product can get together, network and learn incredible stuff from the sessions presented.

I’ll try to tweet as much as I can during the event, you can follow me @fabiorapposelli.

How Compellent Storage Center works – Part 2

Here we are again with How Compellent works part 2, I’m writing this post just after a lucullian easter lunch with my whole family so please forgive some of my expressions

In the last post we talked about how data is written into PAGES and progressed using Storage Profiles and Data Progression, this time we’ll focus on how Replay works.

Replays are, in fact, snapshots of your volume data at a certain point in time, to apply this concept to the PAGES that Storage Center uses there’s another metadata on each, which identify the category of the PAGE, the categories are:

• Accessible Recently Accessed – These are the active pages the volume is using the most
• Accessible Non-recently accessed – Read-write pages that have not been recently used
• Historical Accessible – Read-only pages that may be read by a volume, applies to Snapshot Volumes only
• Historical Non-Accessible – Read-only data pages that are not being currently accessed by a volume, applies to Snapshot Volumes only, Snapshot maintains these pages for recovery purposes and they should be placed on the lowest cost storage possible

(the descriptions are copy/pasted from a Compellent document)

Let’s see with a simple graphic how it works, let’s see how a Volume is represented inside Storage Center when a Replay is taken, each blue block is a 2MB PAGE:

According to this diagram when the C1 PAGE has been written the old C Page change its state to Historical Non-Accessible, meanwhile C1 is an Accessible Recently Accessed PAGE, all the other PAGES that resides below the Replay separator are Historical Accessible PAGES.So in this case, the C PAGE will be automatically demoted during the first Data Progression Cycle to a lower cost storage.

In this graphic another Replay is taken, as you can see, even with multiple replays only the changed PAGES are allocated as new, in this scenario the C1 PAGE and E PAGE becomes Historical Non-Accessible PAGES.

Here is the Replay expiration, the expiration could be manually or scheduled, during the replay creation you can choose between a “never expire” Replay or a scheduled expiration, that can be eventually changed on the fly. The grey tinted PAGES are pushed toward the new oldest replay available, meanwhile the orange tinted PAGE is released back into the pool, to be immediately available for other purposes.

But what if we need to access data of a single Replay? maybe map it to another server to replicate the production environment?Here comes the VIEW.Now the graphic is getting complicated, in the following diagram we see the upper part which represent the VIEW created from a Replay which is in purple, and the lower part which represent the Volume with multiple snapshots like the examples above:

Here we have created this VIEW and mapped to another server (every VIEW is R/W) where we decided to create a new development environment based on production data that we snapshotted using a Replay, now every READ operation goes through the Replay like the arrows say, if there’s the need to write a new PAGE it will be written in the VIEW space, consuming in fact only the ∆ changes.Now the development environment has the need to be snapshotted itself, can we do it? OF COURSE we can , let’s see with the usual diagram how it works:

So you can clearly see how this technology is really powerful and space-savvy, it is also applicable recursively so you can create a view made from a replay of a view which is a view of a replay etc… etc…Next time I’ll take care of the replication with QOS and deduplication, as always feedback and comments are very welcomed!.

How Compellent Storage Center works – Part 1

I’ve been very busy this week, didn’t get enough time for social activities (online and offline), while I was cutting my way through some weird Solaris issues I had a chance to think about how Compellent technology is understood in the storage tech community.

And my conclusion was: not enough

So, recently I had a discussion over at RecoveryMonkey.net about how Compellent technology really works, and I tried to create a comprehensive post out of that discussion.

How Compellent Storage Center works

Dynamic Block Architecture

First of all, every chunk of data on a Storage Center system is stored in what’s called a PAGE, that’s referred in Compellent’s brochure as DBA (Dynamic Block Architecture).

The concept is pretty similar to virtual memory, basically you’re abstracting from the physical disk to an entity that can live on different medium, the single PAGE defaults to 2MB of size, but it’s tunable to 512k or 4MB, you can even have different PAGE sizes on the same Disk Folder (albeit not recommended).

Every PAGE comes with an attached Metadata, this metadata stores everything related to this PAGE like:

• When it was created
• When it was last accessed
• What kind of RAID protection currently has (R10, R5, R6…)
• What kind of tier it currently lives in (Tier 1, 2 or 3)
• What kind of disk tracks it lives in (FAST or Standard)

With this kind of data available for every PAGE in the system, Storage Center start to collect statistics on how the PAGEs are accessed, and adjust accordingly moving the PAGEs between different Disk Tracks, RAIDs and Tiers during its scheduled Data Progression.

Storage Profiles

To control HOW the Volumes are written/progressed through the system there’s a functionality called “Storage Profiles”, these Storage Profiles define what Tiers and RAID level a volume can use for Active data and Snapshot data, there are four default Storage Profiles and then the End User can create a custom one on its own (it’s a matter of a few clicks), let’s see more in deep how they works:

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 by 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 with:

• 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 with:

• Write data on Tier3:RAID 5-9
• Snapshot Data on Tier3:RAID 5-9

To accommodate the need for low impact stuff.

How data flows to Storage Center

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.

Data Progression

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 PAGE written, and then progress it slowly (the algorithm is based on access threshold on a 14-day basis) to the lower tiers.

Instead, if you take a Replay (the terminology used by Compellent for Snapshots), 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 Replay 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 snapshots are pointer based (more on that in another post) 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 which is 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 which is 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” that’s still active data, still in Raid 10.

Now, that’s all for today, in the next posts I will outline how pointer-based snapshots works on Storage Center, how Replication works and other nifty features.

What does a Block-Level Tiered Volume look like?

So, here we go, here’s my first english language post, please be nice and don’t throw me stuff for my bad english.

Last week I had a discussion with Dimitris Krekoukias on storage performance estimation and we ended up discussing Compellent technology in great detail. We talked a lot and I’ve been very verbose on the topic but I didn’t include a single image showing how actually a volume is represented in the Compellent Storage Center array so here we go, here’s a shot from a customer of mine who’s the first Italian Compellent customer (first deployed in 2008):

As you can see the statistics shows where the data for this Volume (or LUN) is located, the “Replay” space is the Snapshot space used, the “Active” space is the changed data since the last snapshot taken (this screenshot was taken a couple of minutes after the latest snapshot).

Feel free to comment and ask question about that!.

Fabio