thin provisioning « Cinetica

Articoli con tag ‘thin provisioning’
CINETICABLOG

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.

Fabio Rapposelli

This post originally appeared on my blog: http://p2v.it

Tag:Cinetica, Compellent, Data Progression, Fast Track, SAN, Storage, thin provisioning, wide striping
Pubblicato il 2 aprile 2010 nella categoria Cinetica, Compellent, Storage | 1 Commento »

The best space guarantee program

After NetApp and Pillar, 3Par and HDS have now their “space guarantee” programs, but not EMC!

In the last days I saw a lot of chattering about this argument from many sources (you can find some links here, here, here and one from EMC here).

Space guarantee programs are only marketing campaigns to lure customers with fireworks and not with real substance.

Some of these programs have a lot of fine prints and clauses that look like this: “…The 50 percent guarantee is for the raw storage capacity for migrating from third party RAID-1 source environments to dynamically provisioned RAID-5 target environments. For any third party RAID-5 environment, Hitachi Data Systems will guarantee a 20 percent storage capacity reduction. …” (here the complete press-release from HDS).

So if you migrate your DB LUNs from RAID1 to RAID5 thin provisioned you can save space but no guarantees about performance! it seems more a well packaged and legalized fraud than a real opportunity for the customers!

Now I would like to show how my space (and performance) guarantee program works, a recent success case with Compellent.

My Space (and performance) guarantee program:

Compellent Storage Center with its Automated tiered storage (Data Progression), Thin provisioning (Dynamic capacity), space and performance efficient snapshot (instant replays) features may save you a lot of space, grant IOPS and big savings without any more or less hidden clause.

One of our Compellent’s customers (SCM Group) acquired their first Compellent Storage Center more than one year ago and they migrated some of their data to it, one year after (it took quite a bit to test the whole solution in production about support, real different workload, management, etc.) they then decided to move all their contents from an old HDS AMS 500 to Compellent!

The HDS was configured with a total of 1 controllers tray + 8 disk trays as follow:

2 trays 300GB/10K : 6.6TB allocable capacity;
4 trays 146GB/10K : 6.5TB allocable capacity;
3 trays 146GB/15K : 4.9TB allocable capcity;

All the disks were configured in RAID5 (6D+1P, 1 spare per tray).

TOTALS

RAW disks capacity (excluding spares) is about 21TB;
Theoretical allocable capacity was 18TBs;
Really allocated for usage was 14TBs, due to shadow images (LUN clones);
Really used was 12,5TB!!! (near an half of raw);

We did a complete analysis of their needs and summarized the findings in these two following graphs (click on pictures for a full size view):

iops

spazio

You can easily draw two important conclusions:

The space used is high: nearly 80% of usable space;
The real iops deliverd are not a lot (99th percentile is 4059): no wide striping.

Well, with these information and forecasted growth in our mind we designed the best solution for the customer (not on the basis of a unrealistic marketing program):

The results are the following:

135 FC disks were replaced by only 38 300GB/15K FC DISKS: less than one third!
To achieve new space requirements (present + 30% forecast growth) we added 16 1TB/SATA disks!
+ 7000 measured IOPS from the Compellent upgraded (thanks to fast track and data progression), + 72% than HDS!
22.7TB of allocable space, much more usable than what was allocated on HDS, thank to Instant Replays!
The Array is SSD ready (added more backend loops and some slots are free to accomodate some SSD disks in near future)!
Space usage down to 12 Rack Units from 27!
Huge energy savings (4 trays compared to 8 trays + 1 controller), something like 6KW (including cooling)!

And last, but not least: if we break up the cost the customer had to face for the whole operation into what covered the same space/performance they already had and what covered the increase in space/performance, well, the first part was the very same needed to just sustain the old storage (maintenance + power/cooling dissavings), all in all what they payed more for was only what they got more!

This is the best NON Marketing space (and IOPS) guarantee program I know, what do you think about it?

HANDS-ON TECHNOLOGY DAY (18 febbraio 2010): http://www.cinetica.it/hands-on/

Tag:Cinetica, Compellent, Data Progression, EMC, Fast Track, HDS, NetApp, Pillar, SSD, Storage, thin provisioning, wide striping
Pubblicato il 4 febbraio 2010 nella categoria Cinetica, Compellent, Storage | 1 Commento »

Implementation affects TCO

I saw a tweet this morning from Stephen Foskett (@sfoskett): “Looks like 3PAR, BlueArc, Compellent, Dell, EMC, HDS, HP, IBM, NetApp, and Pillar all claim to offer thin provisioning of some sort” .

My answer on twitter was: “it’s time to take a better look to implementations!”

All vendors are working to offer new features on their storages and this is a never ending race that brings users new functionalities and lower prices for their storage! That’s good because innovation rules technology and technology is one of the base factors to do better with less resources, save money and improve efficiency!

There are lots of aspects to evaluate when you chose a new storage, from my personal point of view one of the most important is TCO (total cost of ownership), but, at the same time, TCO is one of the most difficult to calculate. You need a deep dive in every feature to understand how it will impact in your environment to calculate your piece of storage TCO. Indeed it is very difficult without a true benchmarking activity because each vendor tries to show you only the good things while hiding the bad ones!

Thin provisioning (just like all other features) may help you to save money cutting your TCO but the difference between a good and a bad implementation can drastically change the final result and the money spent versus saved ratio!

And, last but not least, a feature cannot live just its own life alone, it has, more or less, to be integrated with every other features: the implementation itself is important but if its use limits other features it may turn out to be a real pain: limitations and constraints cut down your operations while TCO soars up again!

Hands-on technology day, 18 febbraio 2010

Tag:Storage, TCO, thin provisioning
Pubblicato il 21 gennaio 2010 nella categoria Compellent, Storage, Virtualization | 1 Commento »

How Compellent Storage Center works – Part 1

Related Posts:

The best space guarantee program

Related Posts:

Implementation affects TCO

Related Posts:

Ricerca

Subscription Options:

Twitter

Post recenti

Archivio

Links

Related Posts: