Question... We are re-doing our current storage layout. When we first deployed our 3par, we were using adaptive optimization to move data between raid levels on the same tier. ( yeah, I know this was bad, but I got overruled)
Now we are re-doing our layout, and so we are moving half the data off to another device, and the rest, to new luns within the current 3par infrastructure ( using A/O the way it should be used). What I am wondering, is since we are going to be deleting the old luns, do I need re-migrate the blocks back using A/O or when I delete the lun, will it delete the corresponding blocks. ( ie. if I delete a lun that wrote to FC-R1 CPG, and A/O moved some of the blocks to the FC-R5 CPG)
Once the luns are no longer in use, I am planning on deleting the old CPG's altogether.
adaptive optimization and deleting luns
Re: adaptive optimization and deleting luns
That is not an issue, if you remove a vv, all the regions in all the tiers are removed as it should. it won't leave bits around.
The goal is to achieve the best results by following the clients wishes. If they want to have a house build upside down standing on its chimney, it's up to you to figure out how do it, while still making it usable.
Re: adaptive optimization and deleting luns
jcpetro wrote:Question... We are re-doing our current storage layout. When we first deployed our 3par, we were using adaptive optimization to move data between raid levels on the same tier. ( yeah, I know this was bad, but I got overruled)
Not sure why that is bad, we do it. We had 384 15K drives and had our top tier as RAID 1 on the 15K drives and then next tier was RAID 5 on the 15K drives, it worked great.
Re: adaptive optimization and deleting luns
Architect, thanks.. That is good to know. I was told that the process for deleting the VV's and CPG's was that I would have to have AO move the data back to it's original spot before I can remove the VV's and then ultimately the CPG.
kluken, we were told that moving data between say R1 and R5 on the FC tier, wasn't a good thing because it could cause contention, especially because the majority of our traffic is vmware data. We are re-architecting our layout, not so much because of that, but more because our overall environment requirements have changed. We have been going under the assumption that we would be charging customers back for their usage, but Sr. Mgmt has said that they don't want chargebacks, so we are re-doing our storage layout in such a way that we are taking advantage of all the 3par can give us resource wise. We are also going to be doign tiering on the backend with AO, instead of having vmware doing it, whcih is what we had originally planned
kluken, we were told that moving data between say R1 and R5 on the FC tier, wasn't a good thing because it could cause contention, especially because the majority of our traffic is vmware data. We are re-architecting our layout, not so much because of that, but more because our overall environment requirements have changed. We have been going under the assumption that we would be charging customers back for their usage, but Sr. Mgmt has said that they don't want chargebacks, so we are re-doing our storage layout in such a way that we are taking advantage of all the 3par can give us resource wise. We are also going to be doign tiering on the backend with AO, instead of having vmware doing it, whcih is what we had originally planned