We recently bought (or were given) 5 x Flash Drives (EFDs) to "try" in our VMAX.
Our configuration is this:
R1 is 1 x 69 GB MetaVolume made from 8 x 8.6 GB 2WM HyperVolumes. (We have 100s of them.)
BCV1 is 1 x 69 GB MetaVolume made from 8 x 8.6 GB R5(3+1) BCVs.
BCVB is the same.
R2 is 1 x 69 GB MetaVolume made from 8 x 8.6 GB 2WM HyperVolumes.
GBCV (Gold BCV) is 1 x 69 GB MetaVolume made from 8 x 8.6 GB R5(7+1) HyperVolumes.
QBCV is 1 x 69 GB MetaVolume made from 8 x 8.6 GB 2WM HyperVolumes.
So, our basic scheme is to use 69 GB MetaVolumes, made up from 8 x 8.6 GB HyperVolumes.
Because we only have 5 x EFDs, we are going to configure them as R5(3+1) + 1 x Hot Spare. So, we only will have 1 x EFG "RAID Group". So, there doesn't seem to be any value in making them 8.6 GB HyperVolumes and then makiing them into 69 GB MetaVolumes. I'd have meta-members on the same physical disk - that doesn't seem to make sense, does it? So, it would seem logical to make up 69 GB HyperVolumes on the EFD drives.
However, if I make 69 GB HyperVolumes on the EFD drives, then I CAN''T use "Virtual LUN Migration" to migrate my existing R1s to the my new Flash Volumes - apparently "Virtual LUN Migration" only works if the source and target are similiary constructed (MetaVolumes made up of the same size and number of components), but of different RAID Types.
Is this right? What should I do here?
Also, if I could use "Virtual LUN Migration", will it migrate data on-the-fly while continuosly and seamlessly "replicating" my R1s to BCV1, BCVB, R2 and GBCV, all concurrently?
Normally we tell folks never to put metas on the same raid group, but with EFDs it doesn't hurt since there are no "seeks". You will get better performance from a meta volume on the 4 EFDs than just a single volume.
I will get BETTER performance configuring MetaVolumes on the same disks than if I just configured 69 GB volumes on the disks? Odd!
Is my reading of the "Virtual LUN Migraiton" manual correct? I MUST configure both source and target as MetaVolumes of same number and size members, but of different RAID Types?
To answer the second part of your question
"Also, if I could use "Virtual LUN Migration", will it migrate data on-the-fly while continuosly and seamlessly "replicating" my R1s to BCV1, BCVB, R2 and GBCV, all concurrently?"
Yes It willmigrate data on-the-fly while continuosly and seamlessly "replicating" your BCVs and R2.
Checkout this image
each sym volume ( single or meta) is seen by the host server as one physical disk. So where is this better concurrency coming from?
The limitation described below is still valid; isn't it? The host O\S, device driver and HBA usually allocate a fixed set of resources for each volume, regardless of size of volume etc. This means that if there is a large metavolume (16 members or more), it may not have enough host resources or I\O bandwidth allocated by the host to satisfy the performance requirements. This is not a concern for single-threaded applications, applications with low I\O, and applications with a high cache hit rate, but other environments may see performance scaling non-linearly with increasing I\O due to these issues. The main issue described above is with host queues and "queue depth". Each volume recognised by a host gets an I\O queue with it's own queue depth. Consider a 90GB dataset, presented either as 10 x 9GB volumes or as a 1 x 9-member meta, with a queue depth of 8. In this way the maximum outstanding I\Os to a volume as seen from the host is: Max Outstanding I\Os (non-meta) = 10 x 8 = 80 Max Outstanding I\Os (metavol)) = 1 x 8 = 8 This can have 3 effects. Firstly a non-meta can have 8 I\Os driven in parallel, whereas the meta can have only 1 (no Powerpath). Secondly, the maximum outstanding I\Os is relatively limited in meta environments so the Symm cannot work so efficiently grouping I\Os for destage. Thirdly, each I\O waiting in the queue will have the response time of all the preceeding I\Os in the queue plus it's own, so with meta's there is a larger chance of higher response times. The queue depth is generally set at O\S, device driver and HBA levels, and is often a fixed value. A too high value of queue depth can stall applications and must be considered carefully by an expert. To a technical person this sounds like a bad move to use metavolumes, but this really only affects applications doing a lot of I\O to a large metavolume with a low cache hit rate, most applications on Symmetrix do not hit this bottleneck. The convenience and striping of metavolumes are big advantages and should also be considered. It is also possible to avoid the bottleneck with metavolumes by increasing the queue depth where possible and appropriate, and by using Powerpath which automatically gives each path has it's own queue.
If you are testing EFD drives be careful in your testing and expectations. Flash drives really shine for highly random read workloads. In my experience you are not going to see a big gain on other work loads because of the cache in the array and pre-fetch algorithms.
I had DBA's run tests and say they only gained 3% performance on flash. What were the tests? Full reads and full writes in comparison to the FC drives they were running into caching and pre-fetch. I explained why the tests were an invalid comparison.
I then turned the disks over to the system admin with instructions to run random read's via the DD utility on an AIX system with 12 HBA's and 20 active CPU's. He managed to hit 44,000 IOPS on one 200GB flash lun configured in a VP pool on raid-5 7+1 EFD's.