Storagezilla

New Blogger: Mich Fisher. The Storage Seeker.

There are some very smart people at EMC but two of the guys I never get to spend enough time with are Steve Todd and Mich Fisher.

Though the last time all of us were together Mich and I started talking about the changes in Dungeons & Dragons Online only for sports jock Steve to get this distant glazed over look in his eye.

Now, Mich’s last product idea won the EMC Innovation Award and shipped as Iomega v.Clone. Before that he was at Revivio where I think they possibly invented CDP (I’m not willing to start a war on who was there first as he’ll say they were) amd has been knocking around the industry since before I was in nappies.

The first time I spoke with him he had done some insane file system work that unfortunately never saw the light of day as who knows what hell it would have unleashed. But that ability to look at something at an angle just a bit skewed from everyone else is a benefit not a drawback.

A a frequent buyer of consumer storage an a gaming nut myself I look forward to reading his blog posts.

FAST Cache for EMC Unified Storage

In a nutshell FAST Cache provides an immediate performance benefit to the busiest workloads across an entire CX4 or EMC Unified Storage System by holding a large percentage of the most frequently used data in high performance FLASH drives.

When we look at Unified Storage today you have DRAM, located close to the CPU providing nanosecond response times, acting as a lightning fast buffer in front of much slower responding disk drives. Gigabytes of DRAM can be cost prohibitive. FLASH Drives on the other hand providing millisecond response times are significantly less expensive meaning that Terrabyte FAST Cache capacities are easily achievable and while located further away from the CPU FLASH drives are large enough to cache a huge amount of hot data from many different workloads running on the system.

With FAST Cache you insert FLASH Drives into standard Disk Array Enclosure drive slots (if you don't have them installed already) and from Unisphere you mark the devices as being FAST Cache.

That's as involved as the configuration gets.

Once enabled FAST Cache monitors incoming I/O for access frequency and if the addressed data meets the criteria for promotion into FAST Cache it is copied from the back end drives into FAST Cache. While promoted the data continues to serve host reads and writes and if written to while promoted data is asynchronously copied to the back end drives. Should the promoted data need to be discarded to make room for new data a least recently used algorithm identifies what data is available to be discarded.

FAST Cache isn't dependent on the Pool storage provisioning model, non-Pool LUNs, replication operations and other functions using cache benefiting from the availability FAST Cache and since FAST Cache is available only to highly used data it's a highly efficient way of adding FLASH to a system.

You can still dedicated LUNs on a FLASH Raid Group or include FLASH as a Tier in a Pool LUN but from FLARE 30 onwards with FAST Cache I think the hottest data will occupy the cache while warm and cold data move up and down between FC and SATA tiers in FAST pools.

You have been reading FAST Cache for EMC Unified Storage by Storagezilla.

You may also wish to read The Clariion Storage Pool and Storage Services For Clariion Pool LUNs.

Storage Services for Clariion Storage Pool LUNs

The pool based provisioning model will be the prevalent storage model for Clariion going forward.

But what are Clariion Storage Pools?

Clariion Storage Pools

Clariion Storage Pools can be created from any type of Clariion Disk and can incorporate multiple tiers (FLASH,FC,SATA) in the same pool. LUN creation from a pool is a case of providing three basic inputs such as the name of the pool, the host you’re making the LUN available to and the amount of storage capacity the host should see. These LUNs can be expanded or shrunk and come with additional inputs for the use of storage services such as FAST or Compression.

Let's talk about the latest additions to the storage pool model.

Thick LUNS

As I stated previously a Thin LUN is constructed of 8KB extents allocated in 1GB slices upon demand from a pool by the CBFS Mapping Service. Well a Thick LUN is a construct of the same type except all the storage is reserved up front but only allocated upon demand in 1GB slices distributed throughput the pool to maximize spindle usage.

The choice going forward isn’t one of FLARE LUNs, MetaLUNs or designing HyperGroups but simply of Thick or Thin? For the most part I think it’s going to be Thin as Thin LUNs enable great levels of capacity utilization but you can non-disruptively migrate the data between them so the choice is yours.

Now that we‘ve discussed pools and pool LUNs we can introduce the new storage services for pool LUNs starting with one of the big ticket releases.

Fully Automated Storage Tiering (FAST)

Even with Clariion FAST LUN Migrator (An analysis tool which highlights LUNs which could benefit from being migrated to Flash Drives) being available for a while now manual tiering can be time consuming and it requires someone to sit down, examine what’s going inside the system and then make a decision as to migrate a LUN or not.

In FLARE 30 FAST introduces four new Automated Storage Tiering Policies for sub-LUN tiering.

The four policies are Auto-Tier (The default), which moves hot data up tiers and cold data down. Highest Available Tier which places as much data on the highest available tier as is possible ranking from hot to cold. Lowest Available Tier which places as much data as possible on the lowest available tier ranking from cold to hot and No Data Movement which prevents movement operations entirely regardless of how hot, warm or cold the data is.

Periodically the system examines the I/O statistics, applies weights depending on the tiering policy and calculates how much data needs to be moved up and how much data needs to be moved down. Data relocation being scheduled to occur every day/only on specified days/only during specified hours or manually with the click of a button.

Any non-pool LUNs non-disruptively migrated into a pool are automatically included in relocation calculations the moment the migration has completed. Meaning non-pool LUNs can be migrated into a pool to leverage FAST, their LUNs unbound after the migration and their storage space added to the pool when the disks in the RAID Group no longer have any data on them.

Having examined FAST operating across tiers of devices, placing the data on the correct tier of storage at the proper time lets drive out even more storage efficiency.

Compression.

When we examine efficiency through optimization we find that LUN migration to Thin LUNs can maximize overall storage utilization by eliminating any stranded storage which might occur on LUNs which have a significant amount of provisioned but unused storage. That’s one storage efficiency technique.

The use of compression is another. 

As of FLARE 30 LUNs can be compressed. If the LUNs aren't already pool LUNs they will automatically migrated to a Thin LUN and compressed using the same compression algorithms found in RecoverPoint as the migration occurs. It's as easy as ticking a checkbox in Unisphere.

What happens if you no longer want the LUN to be compressed? You uncheck the checkbox and the LUN decompresses back to it's original size.

And that’s a high level look of the new storage services available in FLARE 30.

Next time: FAST Cache & Unisphere.

You have been reading Storage Services for Clariion Storage Pool LUNs by Storagezilla.

You may also wish to read The Clariion Storage Pool and FAST Cache for EMC Unified Storage

EMC Unified Storage is 20% more efficient to begin with. Guaranteed.

The ‘guarantee’ is that you’ll get 20% savings with both SAN and NAS. Apparently if I LIE to my configuration and say ‘Eh, I don’t care about that’ I still get OMG devastatingly positive results of capacity utilization.

via www.pkguild.com

You look at the comments and it's a case of "There they go again."

Yet again the opposition can't put up nor can they shut up.

I knew the most virulent reaction to the guarantee would be from NetApp, their history of awful capacity utilization going back to the dawn of WAFL in the 90's (Nearly as old as FAT32 and unlike Wine file systems don't age very well) It was the same reaction when I pointed to the fact that with Celerra there is no degradation of NAS performance regardless of the protocol (CIFS or NFS) used.

At that time NetApp had to charge out and attack the benchmarks, highlight the fact that they've never submitted a CIFS benchmark and then used every excuse under the sun from their dog ate it to just wait and see what we'll do with PAM when the cards are created from 9th Dimensional Matter when asked why they've never submitted a CIFS benchmark.

In this case amongst all their hand waving the fact of the matter here is that EMC guarantees that for customer needs EMC Unified Storage requires 20% less raw capacity or it will match the shortfall.

That's it.

No pages of fine print. No RAID 10 on a Sunday before Mass. No need to bring your lawyer or promise not to covet your neighbors disk drives, sacrifice your first born to Cthulhu or any of the the other bloated arse covering legalese nonsense found in less efficient guarantees from less efficient vendors.

Another brick in a "Wall of Yellow...?"

Symantec is lining up here appears to be a strong push for application security, which makes a lot of sense given where some disruptive technologies are heading and that Symantec needs (in my opinion) to make up for missing a lot of what is happening with cloud and virtualization.

via www.rsa.com

I'd agree with Sam on this and not just because he's razor sharp on these things.

Virtualization and Cloud Computing were things which were inflicted upon Symantec so now they're trying to jump on that train a few stops further down the track.

But if you look at their record of acquisitions to date you'll see that some trains just never arrived at the stations they expected them to.

We'll see if they make a go of this or if it'll be another value destroying acquisition like Veritas was.

Miniman moves onwards

I can’t say I was happy when Stu told me he was leaving EMC but I do believe that a person’s progress through life is a great winding journey filled with different people and different places.

On the upside knowing where he’s going I’ll still have access to his insights, as will many other people as he’s not vanishing into a competitor.

Not that it really bothers me when I start working with a former competitor or watch someone leave for a current competitor. People are only trying to get on after all.

As they should.

And this is what this is, someone getting on.

Best of luck on your new adventure Stu!

The Clariion Storage Pool

One of the more interesting points to come out of EMC World for me was that all future storage services for Clariion (Such as Compression and FAST in FLARE 30 and the other stuff planned for FLARE.Next) will be implemented into Clariion Storage Pools.

But what is a Pool?

Into 101 mode for a sec so we can level set and then we’ll swing into Pools.

Consider that today there are three types of LUNs available on a Clariion.

-A FLARE LUN.

FLARE LUNs consist of a single RAID Group made up of anything up to 16 Disk Devices. A storage Atoll inside the array which can be aggregated with other FLARE LUNs by a host based volume manager for expansion. FLARE LUNs are the most tuneable logical storage constructs as you’re operating at a per LUN level with individual FLARE LUNs capable of being tuned in multiple different ways.

The advantage of FLARE LUNs being that you can control *everything*. If you know what you’re doing you can performance tune your workload to an insane level of detail.

The disadvantage of course is that you have to understand what you’re doing to get the true value out of it.

A FLARE LUN is a LUN created by an Expert.

-A MetaLUN.

A MetaLUN isn’t as tuneable as a FLARE LUN but offers in array expansion as you can stripe/concatenate additional LUNs directly inside the array without having to take on board the logic of a host based Logical Volume Manager.

You start with a Base LUN unto which you add Component LUNs and grow upwards to 16 Exabytes of addressable storage.

Can turn the storage contents of an entire Clariion into a single MetaLUN? Sure, probably not the best idea for whatever host is supposed to be using that storage though. Some file systems will address that, a lot of them won’t.

The advantage of MetaLUNs are due to their striped nature they offer very high bandwidth and large random IOPS while highly distributing the load and you can create large involved storage structures with multiple performance and fault domains. (HyperGroups)

The disadvantage is while MetaLUNs offer higher capacity in some cases they may not offer any higher performance than a FLARE LUN if the workload doesn’t benefit from load distribution, and some workloads just don’t, or someone loves their host based Logical Volume Manager more than they love your storage array. Why bother doing two times the work on volume expansion (On the host and on the array) when you could spend some time making the performance pitch perfect instead? They also have to be designed factoring in your expansion needs going forward. This is very much the case if you’ve decided to create your structural masterpiece as you need to do the visualisation yourself at a macro level to realise all the benefits.

MetaLUNs are LUNs created by an Architect.

-A Thin LUN.

Thin LUNs are LUNs provisioned on the AutoPilot to best practices. They’re simple to use and very space efficient as they allocate capacity from Thin Pools only upon demand.

The advantage of Thin LUNs being with some initial thought Thin Pools (Pools being analogous to RAID groups but supporting hundreds of devices instead of up to 16) are largely autonomic in their upkeep and mutable in their design.

The disadvantage being they’re not as tuneable as FLARE LUNs or MetaLUNs but they offer good random I/O and good bandwidth performance right out of the gate.

Lets focus somewhat on how Thin LUNs are allocated.

As I’ve stated all Thin LUNs are provisioned out of Thin Pools and unlike RAID Groups Thin Pools can contain hundreds of devices with the Common Block File System (CBFS) managing the underlying structural operations.

Thin LUNs are allocated out of Thin Pools in 1GB Slices of 8Kb file system extents by the Mapping Service. As that storage is used up additional 1GB slices of extents are allocated upon demand.

Thin LUNs not only support over subscription but also migration. Pre-allocated FLARE or MetaLUNs aren’t stranded but can be migrated into Thin Pools non-disruptively if or when required.

Thin LUNs are LUNs created by an Administrator.

FLARE 30 will introduce the concept of Thick LUNs, allowing you to carve out thick LUNs from a pool of devices. The Pool concept allowing for heterogeneity of device types be they EFD, FC, SATA or other while bringing low touch storage management to Thick LUNs.

Going forward all future data services will be developed for the Pool based architecture. So, the future of Clariion in FLARE 30 and onward is a Pool based future.

You’ll still have access to FLARE LUNs and MetaLUNs and will still have access to fine grained performance tuning but the dynamic attributes of the Storage Pool architecture and the ability to non-disruptively migrate non-pool LUNs to Pool LUNs (Thick/Thin) and vice versa will mean that it’s my belief that the use of Pools will quickly overtake the use of carving out FLARE LUNs or Concatenating/Striping with MetaLUNs.

FLARE LUNs and MetLUNs will remain the domain of the Expert or the Architect and Pool LUNs Thick and Thin, and as they are today, the domain of the Admin.

Now that we’ve covered the foundational stuff we’ll move on to the new Clariion Storage Services later.

You have been reading The Clariion Storage Pool by Storagezilla. You may also wish to read Storage Services For Clariion Storage Pool LUNs and FAST Cache For EMC Unified Storage.

SAP buys Sybase. Not for it’s database.

A quick thought or two on SAP’s acquisition of Sybase. Is this about kicking Oracle out of SAP accounts and reducing the $1B worth of Oracle SAP sells on to their customers annually?

Partly. But it’s not the sole motivation as SAP have had their own RDBMS (MaxDB) for years and the Oracle DBA who’s stakes their economic future on Oracle never rushed to swap out what they had for MaxDB. While I’m certain SAP consider reducing the amount of money they send to Redwood Shores, converting some SAP-Oracle customers and scooping up Sybase customers to be nothing but a good thing it’s not like the traditional RDBMS market is undergoing major growth.

You have a bunch of companies in there who use sky high maintenance costs and voodoo licensing techniques to pump ever increasing profits out of a static customer base. Who’s building Hyperscale apps on these mediocre performing but feature rich RDBMS databases?

Only the vendors who sell them and people who started building before they knew the world was going Hyperscale.

No one else is. They’re all too busy deploying thousands of nodes, running PB sized information stores and flaming each other over in NOSQL land.

The play here for SAP is where Sybase has been focusing the bulk of it’s attention and spending it’s development money. The mobile commerce and payment market.

Mobile apps are white hot and Sybase has a rapidly growing mobile commerce platform which has been growing faster than their RDBMS business. If it’s probable that the focus on mobile applications is going to sharpen due to the proliferation of mobile devices then having Sybase’s RDBMS business is only some Farmland surrounding the mobile platform Goldmine.

SAP is buying Sybase not for the RDBMS database it has built but for the mobile platform it is building.

It’ll be an interesting keynote at SAPPHIRE.

Notes on the team

Having met a lot of the Executive Team in the past two days who did I find the most impressive?

Michael Cappellas.

Admittedly it could have been because the bar was set so low as I hadn’t had any prior contact and I already knew how smart the rest of them were but I turned around to find a guy with a megawatt smile, a firm handshake and a ton of questions looking around the Bloggers Lounge.

Someone asked him about his strategy for VCE & Acadia and this explosion of plans, ideas and market observations came billowing forth.

He now has an organisation and an Executive Team (With Rich Talaber as his CTO) so we’ll see how strong Acadia’s moves are once his feet are under the table.

Notes on Convergence

Reading some of the speculation pre-EMC World I came to the conclusion I wouldn’t let some of the people involved design a Jam Sandwich due to how inaccurate their guesses were.

What I did find curious was the surprise that Clariion and Celerra were converging. Especially when you look back at the product announcements made to date.

In 2007 the Celerra started offering the same block storage functionality as the CX3.

In 2008 Clariion Virtual Provisioning, derived from Celerra Virtual Provisioning, was introduced.

In 2009 FAST V1 for block storage was available across both platforms and iSCSI support unified in the background.

In 2010 they’ll deliver Unified Management with Unisphere FAST-VP, FAST Cache and Compression across both platforms.

So while hindsight is 20/20, in this case it’s not like this should be a huge surprise.

And the year ain’t over yet.