Pool vs Raid group: Bad experience
With flare 30, pool is the new feature.and mixed pool is something totally new. You can combine multiple disk type in a common raid configuration and put it inside the pool. Enable auto-tiering and you are promised for a good performance by moving data across different tiers, the catch (its not real time, unlike VMAX). If you have totally unpredicted I/O then by the time it is decided to move the data above or below the tiers the I/O profile gets completely changed.
In the next version of he flare, you can have disks in different raid type inside a single pool.
What goes inside the pool, how the data is striped or written is something internal to EMC. The very idea is to give customers a very comfortable way of handling the storage leaving the pain to EMC. However, things are always not green as it looks. This works well when you have predictable I/O, you know what is going inside and when.
What if the dynamics changes every now and then and you do not have control over the I/O profile or capacity? where capacity planning goes for a toss and management thinks storage just in terms of capacity not performance. Does pool fits in here, absolutely no unless you are willing to shell out couple of thousand dollars to EMC every 6-9 months for an array assessment.
There is some nagging problem with pools. You cannot find individual LUN performance details in fine granularity. You cannot enable/disable cache on individual luns, it has to be done on pools only. You don't know where exactly your data is inside the lun, in ssd or sas or nlsas in case of mixed pools. You can get disk performance details but will not be related to the lun as it might not be sitting out there if tiering is enabled.
I prefer the raid groups, very simple with fine control over performance. I know exactly what needs to be done. Its difficult to manage when the lun stripes over multiple raid groups but you sacrifice something for getting better SLA and future needs. You can prepare reports for management when you have the capacity but no performance headroom's,we can drill down to the individual file system on the host to that of storage and show where the bottleneck is.
In the next version of he flare, you can have disks in different raid type inside a single pool.
What goes inside the pool, how the data is striped or written is something internal to EMC. The very idea is to give customers a very comfortable way of handling the storage leaving the pain to EMC. However, things are always not green as it looks. This works well when you have predictable I/O, you know what is going inside and when.
What if the dynamics changes every now and then and you do not have control over the I/O profile or capacity? where capacity planning goes for a toss and management thinks storage just in terms of capacity not performance. Does pool fits in here, absolutely no unless you are willing to shell out couple of thousand dollars to EMC every 6-9 months for an array assessment.
There is some nagging problem with pools. You cannot find individual LUN performance details in fine granularity. You cannot enable/disable cache on individual luns, it has to be done on pools only. You don't know where exactly your data is inside the lun, in ssd or sas or nlsas in case of mixed pools. You can get disk performance details but will not be related to the lun as it might not be sitting out there if tiering is enabled.
I prefer the raid groups, very simple with fine control over performance. I know exactly what needs to be done. Its difficult to manage when the lun stripes over multiple raid groups but you sacrifice something for getting better SLA and future needs. You can prepare reports for management when you have the capacity but no performance headroom's,we can drill down to the individual file system on the host to that of storage and show where the bottleneck is.
Comments
Post a Comment