How Compellent Storage Center works – Part 1

Posted: April 1st, 2010 | Author: | Filed under: Storage | Tags: , , , | 2 Comments »

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.

Newer Entries »