wide striping « Cinetica

Articoli con tag ‘wide striping’
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 »

Virtualizzazione dello Storage: la federazione dei sistemi

Nel 2009 si è parlato molto di virtualizzazione dello storage e si sono viste diverse implementazioni di alcune tecnologie di base come ad esempio thin provisioning, wide striping e deduplication.

La strada è stata tracciata e alcuni vendor si sono già spinti oltre con l’automated tiered storage. Quindi si è creata sempre più una differenziazione fra storage vendor che offrono tecnologie legacy contro storage vendor di nuova generazione che offrono soluzioni più integrate e innovative.

In ogni caso tutte le nuove tecnologie che si stanno affacciando sul mercato hanno come obiettivi comuni quello di migliorare l’uso dello spazio, ottimizzare le performance e semplificare la gestione. Le aziende sono alla ricerca di soluzioni per reagire in maniera brillante alle crescenti (in certi casi esplosive) esigenze di spazio e performance. La risposta sta nella semplicità di gestione e nella scalabilità dei sistemi (un problema molto sentito è il numero di TB gestiti per sysadmin!).

Virtualizzare lo storage ha lo stesso vantaggio che virtualizzare i server e, per avere una infrastruttura totalmente virtualizzata, è necessario avere uno storage adeguato!

Oggi siamo ad una fase di virtualizzazione dello storage che possiamo definire 1.0 con l’adozione delle tecnologie di base, pochi vendor stanno già lavorando alla versione 2.0 (automated tiered storage) ma la vera rivoluzione si otterrà quando avremo la terza generazione di storage virtualizzato cioè storage modulari che si possono federare fra di loro per distribuire il carico di lavoro e aumentare l’uptime.

Non siamo lontani da questo risultato, acumi sistemi NAS hanno già funzionalità del genere e alcune SAN iniziano a farci intravedere che la strada sarà quella.

Quello che è successo per i server, cioè il passaggio da grossi server SMP a server x86 economici con hypervisor, succederà presto anche per lo storage: non si scalerà più verticalmente ma orizzontalmente. Infatti, oggi, la grande differenza fra un sistema modulare e uno monolitico (o “enterprise”) di vecchia generazione è la scalabilità e, in alcuni casi, la maggior disponibilità. Ma se in futuro avrò tanti sistemi modulari che potranno concorrere a formare un sistema complesso il vantaggio dei sistemi definiti “enterprise” si annullerà e il costo sensibilmente superiore non sarà più giustificato!

Alcuni vendor stanno lavorando già e permetteranno presto di movimentare a caldo LUN fra più sistemi e quindi bilanciare, automaticamente o manualmente, il carico di lavoro e facilitare operazioni di manutenzione. Semplificando si potrebbe paragonare queste funzionalità al vMotion e al DRS di VMware: oggi fondamentali negli ambienti virtualizzati!

Come oggi avviene per i server sarà tutto molto più facile anche per lo storage:

si potranno acquistare storage modulari relativamente economici e affiancarne diversi per ottenere una infrastruttura importante;
si potrà acquistare la miglior tecnologia del momento ad un prezzo sempre allineato con il mercato;
la scalabilità sarà praticamente illimitata e la spesa crescerà linearmente con le esigenze;

Sono convinto che nel 2010 verranno rilasciate le prime implementazioni di questo tipo e che nel giro di un paio d’anni tutti i principali vendor prenderanno questa strada. Certo, le prime versioni di queste nuove architetture non saranno esenti da difetti e vincoli ma sicuramente lo sviluppo sarà rapido… lo abbiamo già visto con la virtualizzazione dei server!

Tag:Compellent, Data Progression, deduplication, Storage, thin provisioning, Virtualizzazione, wide striping
Pubblicato il 8 gennaio 2010 nella categoria Compellent, Senza categoria, Storage, Virtualization, Virtualizzazione | 1 Commento »

How Compellent Storage Center works – Part 1

Related Posts:

The best space guarantee program

Related Posts:

Virtualizzazione dello Storage: la federazione dei sistemi

Related Posts:

Ricerca

Subscription Options:

Twitter

Post recenti

Archivio

Links

Related Posts: