In the context of external storage on the Hitachi Enterprise array, one of the problems I've encountered in the past is trying to match an arbitrary LDEV size (down to the block count) between my internal and external storage. Traditional modular arrays, including the previous generation Hitachi AMS would not allow you to create LDEVs with an arbitrary block size. They were generally bound at 1GB limits. This has led to many debates on our team to determine the best way to present external storage to the USP or USPV; maintaining the benefit of simplified storage management while engineering against performance issues.
The issue? Creating large LUNs on the external (virtualized) array allows you to easily carve up, or CVS (custom volume size) LDEVs on the USP/USPV. This provides an easier to manage external storage environment but at the expense of granularity. Large external LUNs means a fewer number of LDEVs on the external array, or a high ratio of "internally" created LDEVs to each external LUN. This may help depict the issue:
A 2000 GB volume is virtualized to the USP/USPV, and carved into 20 100GB LUNs. Now, you map those 20 LUNs to various hosts and start pushing I/O. To the hosts, these are typical LUNs, each with their own queue depth (32 in the case of USPV). The host does not understand that on the back end these LUNs all exist on a single LDEV which has a finite queue depth (typically less than 32). I guess you could call it "thin provisioning your queues" but don't, that just gets you in trouble.Some recent work I have been doing involves the AMS2000 Modular storage virtualized to a USPV. During some basic testing I was able to create LDEVs on the AMS that matched the block size of the USPV LDEVs. Specifically what I'll be doing is taking advantage of the AMS2500s Dynamic Provisioning Software to provide several hundred correctly sized LDEVs to the USPV which will be used as ShadowImage (clone) S-VOLs for internal P-VOLs (DP-VOLs in this case). This is not possible with all externally attached arrays as their block sizes most likely will not match the USP or USP-V block sizes like the AMS2000 array does.
This solution saves my customer money by licensing Hitachi Dynamic Provisioning on their enterprise array for only the storage required by the production volumes. I have simplified management of the external array by leveraging the frame based HDP license included on the AMS product. In addition, I can leverage this infrastructure in the future to provide storage tiering for other applications to further control storage costs. All in all, not a bad day's work!
ok so how did you do it on the AMS? my thought though is that on the USP-V the frame license for HDP in the big scope of a large scalable array isn't all that much though is it? very cool though. one neat thing i did for the first time today was completely manage some new external LUNs all from HDvM. never had to login to SNM2 or the USP-V SN.
ReplyDeleteHey Steve!
ReplyDeleteIn this case, the customer did not have a frame license for HDP on the Enterprise array. If fact they didn't have HDP on it at all (yet). I created a pool on the AMS2500, created my DP-VOLs by specifying the block sizes, and virtualized the 300 or so LDEVs to the Enterprise array. If I had an Enterprise HDP frame license, I would manage everything at that level. If however I had a limited HDP license, I'd save it and leverage the AMS2000 for sure!
I like what you're doing with HDvM! I'm pretty excited about some improvements that are on the horizon for that product stack! I'll let you know more when I can.