Every wonder what volumes make up a VNX Filesystem? Let’s consider our Friendly EMC definitions below, with commentary..the graphic is a picturesque view of all these volumes in motion, absent the disk volumes which underpin the storage pool…
On a VNX for file, a physical storage unit as exported from the storage system. All other volume
types are created from disk volumes. – the VNX recognizes all LUNs as disk volumes. They are denoted as “d” numbers, ie d12, d13, etc.
the is the basic unit of life on the VNX storage wise. Same size please…
Well not really a clear definition here. The best I can tell is when you add a disk volume to a storage pool it now becomes a member
Volume of that storage pool.
On VNX for file, a logical piece or specified area of a volume used to create smaller, more
manageable units of storage. –you want to slice your filesystems, otherwise you are wasting space. It’s a form of thin provisioning so use it.
Arrangement of volumes that appear as a single volume. Allows for stripe units that cut across
the volume and are addressed in an interlaced manner. Stripe volumes make load balancing
possible. – Striping is synonymous with good, something you want, increased performance. So for the love of cheese and beer, make all your disk volumes
the same size, across multiple RAID groups, across both SP’s, please?
On VNX for file, a concatenation of volumes, which can consist of disk, slice, or stripe volumes.
Also called a hypervolume or hyper. Every file system must be created on top of a unique
metavolume. –As you noticed in the graphic this is the end of the road, el finito. Your blessed file system lives here..
So here’s the basic flow of how the VNX takes a volume and at the end birth’s a Filesystem…
LUNs are added to data movers from VNX block. They are recognized as disk volumes. Volume profiles, as they are called, define how new storage is added to a system defined storage pool (AVM). AVM or Automatic Volume Management is a feature that creates, manages and organizes volumes into storage pools. The disk volume is then added to the appropriate storage pool based on its disk type (SAS, NL-SAS, EFD, FC, SATA, etc), its RAID type (R5, 6, and 10), count and size. At this point the disk volume becomes a member volume of that pool it’s been directed to. As volumes are added to that pool, AVM selects volumes based on certain algorithmic criteria. If that criteria is met multiple disk volumes are striped together to form stripe volumes. If it’s not met they are concatenated together. At this point shop is open. We have all heard of slices on the Unified Systems but do you know what it means? Slicing allows you to create smaller units of storage across stripped or concatenated volumes. If you did not set the slice option to yes then you are in affect guaranteeing that a file system will not share disk volumes with other file systems in that pool. Not the most efficient use of storage, eh? The final piece of this intricate puzzle is the metavolume. Every Filesystem is created on a Metavolume or Hyper as it’s called sometimes. This volume could consist and often is a conglomerate of concatenated slice, stripe or disk volumes. Consider this graphic. This is the logic road on how AVM selects disk volumes to add to a storage pool…
Know the mechanics and all designs are easy J More to come on obscure VNX knowledge me thinks….