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 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.