Thin provisioning in the recent years became a great tool for Storage Admins and Systems Engineers to help provision storage on demand and then go on to purchase what is required. It greatly helps in capacity management as you do not have to procure upfront storage. Not all provisioning can be thin - it depends on what type of data and the application usage. If it is user data and if files are being added to the full capacity then no thin provisioning technology can save you space. But if it is database data, where they need the file upfront, but only writes zero blocks in them, or user shares where 'xx' amount of capacity need to be provisioned upfront but they will be using it over a period of time this is really a great tool to use.
All vendors have implemented TP over a period of time since it is now prime-time. If a storage array cannot support it, then you should think over making that purchase. Why would a vendor want to support TP when they can sell more disks to you? Well, they really didn't want to. But it is the storage community that pushed every vendor to implement it so now it is something that every vendor has in their products. Some give it away for free, some license it.
Let us look at how Thin Provisioning was implemented in HDS high end arrays. The term used by HDS for this is Dynamic Provisioning. Data allocation is done in 42MB blocks which is referred to as 'page'. This is the most granular level at which 'free pages' can be reclaimed. Now, 42MB seem to be a very large number - especially when other storage vendors can reclaim blocks from 4k to 256k (depending on the vendor). How can 42MB be more efficient in un-used storage space reclamation and the bigger question is, will this really work with all kinds of Operating systems and applications?
Right off the bat, there are some Operating systems that are excluded due to the nature they generate metadata while creating file systems. Solaris UFS file system writes metadata for every 52MB blocks which means, all of the pages allocated for a UFS file system will be consumed and none can be reclaimed even though the file system is empty. This certainly does not sound like "thin" provisioning. Linux EXT2 and EXT3 file systems generate metadata for every 128MB block, and maybe you can see some benefit over here. The most-hds-thin-provisioning friendly file systems seem to be VxFS / JFS (HPUX) / JFS2 (AIX) as these write metadata on the top/initial block of the partition. The same benefits applies to NTFS as well.
Also, in order to "efficiently" use HDP, it is suggested to create partition for the right-sized requirement. Why would you want to allocate a 2TB "thin" LUN for a 200G requirement, and then keep monitoring the usage and when the usage hits a threshold, increase the partition size "dynamically" to the next increment of size? And with 42MB blocks, how much of space do you expect to be reclaimed?
Apart from the page size itself, the other challenges today are (maybe not be there with future updates) to have a minimum of 4-parity groups per pool, and you can ONLY increase the pool size by adding the same amount of parity groups that are currently in the pool (i.e 4 more). This sounds ridiculous where other storage vendors can create a thin provisioned block device with just about any amount of storage available and can increase its size as long as there is enough capacity to commit those blocks.
Also, best practices say it is best not to assign independent LDEVs from any other parity groups that you might have, rather create a single-ldev out of a parity group and assign it as a whole to the pool.
The way I see it, HDP is just Hitachi's wide striping rather than thin provisioning. All these years while other storage vendors were able to stripe data across 10s of disks, the largest Hitachi array could only do it across 7 (rather 7 data and 1 parity) which seemed to create lots of hot spots for customers requiring high transaction processing and forcing customers to micro-manage their storage (ldevs) and move them to unused parity groups for better performance.
All vendors have implemented TP over a period of time since it is now prime-time. If a storage array cannot support it, then you should think over making that purchase. Why would a vendor want to support TP when they can sell more disks to you? Well, they really didn't want to. But it is the storage community that pushed every vendor to implement it so now it is something that every vendor has in their products. Some give it away for free, some license it.
Let us look at how Thin Provisioning was implemented in HDS high end arrays. The term used by HDS for this is Dynamic Provisioning. Data allocation is done in 42MB blocks which is referred to as 'page'. This is the most granular level at which 'free pages' can be reclaimed. Now, 42MB seem to be a very large number - especially when other storage vendors can reclaim blocks from 4k to 256k (depending on the vendor). How can 42MB be more efficient in un-used storage space reclamation and the bigger question is, will this really work with all kinds of Operating systems and applications?
Right off the bat, there are some Operating systems that are excluded due to the nature they generate metadata while creating file systems. Solaris UFS file system writes metadata for every 52MB blocks which means, all of the pages allocated for a UFS file system will be consumed and none can be reclaimed even though the file system is empty. This certainly does not sound like "thin" provisioning. Linux EXT2 and EXT3 file systems generate metadata for every 128MB block, and maybe you can see some benefit over here. The most-hds-thin-provisioning friendly file systems seem to be VxFS / JFS (HPUX) / JFS2 (AIX) as these write metadata on the top/initial block of the partition. The same benefits applies to NTFS as well.
Also, in order to "efficiently" use HDP, it is suggested to create partition for the right-sized requirement. Why would you want to allocate a 2TB "thin" LUN for a 200G requirement, and then keep monitoring the usage and when the usage hits a threshold, increase the partition size "dynamically" to the next increment of size? And with 42MB blocks, how much of space do you expect to be reclaimed?
Apart from the page size itself, the other challenges today are (maybe not be there with future updates) to have a minimum of 4-parity groups per pool, and you can ONLY increase the pool size by adding the same amount of parity groups that are currently in the pool (i.e 4 more). This sounds ridiculous where other storage vendors can create a thin provisioned block device with just about any amount of storage available and can increase its size as long as there is enough capacity to commit those blocks.
Also, best practices say it is best not to assign independent LDEVs from any other parity groups that you might have, rather create a single-ldev out of a parity group and assign it as a whole to the pool.
The way I see it, HDP is just Hitachi's wide striping rather than thin provisioning. All these years while other storage vendors were able to stripe data across 10s of disks, the largest Hitachi array could only do it across 7 (rather 7 data and 1 parity) which seemed to create lots of hot spots for customers requiring high transaction processing and forcing customers to micro-manage their storage (ldevs) and move them to unused parity groups for better performance.
Oh Yeah! did I forget to mention that any parity groups that are in a HDP pool cannot be released independently unless you destroy the whole pool?
No comments:
Post a Comment