VPLEX with VIAS and XtremIO

Hello,

Curious if anyone from EMC has some thoughts on this? I have seen a few posts about VIAS provisioning with video's so hoping someone can clarify the requirements above with XtremIO integration in 5.5.

thanks!

Thanks Mike for those answers! - I had one point of follow-up:

For #2, I just wanted to validate something. How you have it explained above is exactly how I have my VPLEX registered today, however I am allowing the customer to map the initial LUNs across both IG's on the XtremIO and the thought was that if they do hit the limits of LUNs mapped to IG's (don't think they will), that they would simply unmap all of the volumes in one of the IG's, rescan on the VPLEX to update the ITL's on the back-end, and then utilize that IG on the XtremIO for the new LUN mappings. This should still provide and meet the HA redundancy required on the VPLEX side and if this ever does need to happen I wouldn't unmap all 2048 volumes from those paths at once, I would do them in groups given some of the caveats out there. .

My thought process was that it is just easier to manage now and provide better performance to map across all and if they ever find themselves in a jam with the limits down the road, we have future-proofed their setup to accommodate the change  at that time.

Just curious if you see anything wrong with this approach from any of your testing?

thanks!

-Keith

Hi Keith,

The recommendation to the customer to share the same volumes to both initiator groups completely defeats the purpose.

You adding risk should you have to remove volumes when they reach the scale limits of 2048 volumes per initiator group.

To complicate matters further, VIAS will only place volumes in one initiator group so if you are using VIAS then you will have additional chance of user error should you have to remove volumes in the future.

There is also another mapping limit on the XtremIO that is probably irrelevant here but should also be mentioned as it may apply to others that may be reading this thread.  This mapping limit is the number of volume mappings per initiator group.  One volume mapped to one ig is one mapping.  Ten volumes mapped to ten ig's is one hundred mappings.  The total mapping limit is 16,384 and this is a cluster wide limit.  The more times you share the same volumes to multiple initiator groups, the faster you consume this mapping limit.

Also, please do not attempt to apply conventional thinking based on arrays with spinning disks to this all flash array.  The traditional array uses a cache front end and has algorithms that work to try and pre-fetch data to increase the chances of a "cache read hit".  The more random the data the less likely the algorithms will be successful.  The result is increasing latency causing delays in the port buffers.  The best practice is to spread the connectivity over more ports to prevent overrunning the buffers and receiving a queue full retry.  The latency is caused by the single controller at the disk level.  A spinning disk can only service one request at a time.  The more fragmented the data the longer it takes.

The flash drives used by XtremIO have multiple controllers that service multiple requests in parallel.  The added benefit of deduplication minimizes the actual writes sent to disk.  This translates into a different best practice.  The recommendation for XtremIO is to push the buffers hard keeping them busy.

--Mike

Thanks Mike,

So if I have my customer modify the setup now so that they round robin the volume mappings on the XtremIO to the 2 IG's registered to remove the risk in the future, will VIAS alternate it's placement of volumes to balance it out? Above you state it will go into the one with the fewest LUNs in it and then also state it will only place them in one initiator group, so I want to make sure that by going this route VIAS will not cause any bottlenecks due to to the way it provisions.

Also - what risks are there when removing volumes should it reach that limit? Are you talking about the documented issues with removing large numbers of volumes in a single operation within VPLEX? I'm just trying to understand if I am missing risks that I haven't seen documented because otherwise I would see it as simply just removing and re-scanning paths/ITLs to to the VPLEX, similar to a host using PowerPath in terms of pathing or just removing a volume no longer used by the VPLEX (assuming the other 2 paths are still online obviously).

Thanks!

-Keith