In Part 1 we went through some of the common terminology within the HP 3PAR array and now we will go into a bit more detail about one of them – the Chunklet! A Chunklet is a key player in how the 3PAR aims to utilize all of the disks within the array, and in turn maximize the performance and protection that they can get out of the array! With that said I mentioned that during the initialization of a physical disk it is divided up into 1GB Chunklets but what I didn’t mention is there are a few different types of Chunklets within the HP 3PAR – Now these may not be “official” HP names as I kind of named them myself during my reading. And for some reason I’m now craving gum 🙂
Normal Used Chunklets
These are the Chunklets that are utilized by Logical Disks. They are stringed together within different RAID sets across different physical disks in order to provide capacity to a CPG, which in turn passes it along to a Virtual Volume (this is essentially our datastore when it’s all said and done). These chunklets hold our production data
Normal Reserved Chunklets (Logging Chunklets)
I don’t know if these really exist but this is what I’m going to call them. They are pretty much the same as Normal Used Chunklets however they have been pre-configured in reserved Logical Disks which are created by the system. We normally see a reserved Logical Disk for Logging (used for disk failures/rebuilds), admin (used to store event logs and administration information) and srdata (used to store historical stats and information). We will often see these logical disks containing chunklets closer to the end of the spindles as well.
Normal Unused (Free) Chunklets
These Chunklets are exactly how they are described – they are Chunklets that are provisioned, and are NOT spares, but have not yet been claimed by any Logical Disk. It’s pretty safe to say that during installation all chunklets (except designated spares and reserved) are essentially free chunklets until you start provisioning LUNs.
Spare Chunklets
Some Chunklets will be designated as spares during the initialization of the 3PAR. Meaning, not all 1GB Chunklets are available to be used within a Logical Disk. Spare Chunklets are essentially a placeholder which is utilized when we have a physical disk failure and the Logical Disk RAID set needs to be rebuilt. An intelligent note here – the system automagically selects which Chunklets are to be assigned as spares, however it does it in a way that most of the spare chunklets are located as close to the end of the physical disks block space as possible, leaving the closer blocks for production.
Chunklet Relationships
Everything just seems silly with the word chunklet in front of it 🙂 Either way there are few terms that are used to describe the relationships between our Normal Used Chunklets and all other chunklets within the system.
- Local Spare Chunklets – This would be a chunklet designated as a spare, whose primary path is connected to the same node that owns the source logical disk containing the used chunklet.
- Local Free Chunklet – An Unused/Free chunklet whose primary path is connected to the same node that owns the source logical disk containing the used chunklet.
- Remote Spare Chunklet – A spare chunklet whose primary path is connected to a node different then the node owning the source logical disk containing the used chunklet.
- Remote Free Chunklet – A free/unused chunklet whose primary path is connected to a node different then the node owning the source logical disk containing the used chunklet.
So we have mentioned failing physical disks a couple of times so I think now would be a good time to discuss what exactly happens during a disk failure and how it affects our Chunklets…
- When a connection is lost or a failure of a physical disk occurs, the system immediately forwards all writes destined for failed chunklets that have been cached to chunklets contained in the reserved Logging Logical Disk. This occurs until the failed physical disk/chunklets comes back online, until the Logging LD becomes full, or until the rebuild process has been completed.
- The rebuild process occurs concurrently with the above step, where the system begins to reconstruct lost data utilizing the remaining chunklets and RAID levels provided.
- There is some logic that happens during this rebuild/relocation phase as well – the system first looks to select a local spare chunklet , if none are to be found it moves on to a local free chunklet , then a remote spare chunklet, and finally a remote free chunklet. All the while trying to maintain consistency in terms of the characteristics between the failed and target chunklets (Speed, Drive Type, etc).
- Once the rebuild has completed, the logging disks are replayed and data flushed back down to the newly constructed volume.
So in the end these little tiny 1GB chunks of contiguous space are a key player in the 3PAR array. To help understand them I tend to try to remove the fact that they are on individual drives, and think of them somewhat as really small, granular 1GB drives, some marked as spares, some in different logical drives with different raid sets, and some set aside to provide functionality for the array. All that said though they are not separate drives, different chunklets live on the same drive, leaving us with the ability to provide different RAID levels on the same drive, mix and match different sized drives without wasting capacity, and stripe our logical disks across multiple shelves, and in some cases, even provide shelf-level protection. Plus, they make for a nice little visualization of coloured blocks within the 3PAR Management Console 🙂
