This post is more than 5 years old
522 Posts
0
2647
VPLEX with VIAS and XtremIO
Hello,
In anticipation of going to 5.5, I had a couple questions I was seeking clarification to with regards to ensuring best practices are met for XtremIO and VPLEX integration. From reading some of the guides and training manuals, the following questions don't seem to be called out so I wanted to validate:
1. The docs stats that each XtremIO is registered to the VPLEX cluster in a 1:1 fashion and that multiple XtremIO arrays have to be registered separately. This is OK, but what is the limitation around an XMS managing multiple XtremIO clusters today? Do I have to revert the XMS consolidation back to a legacy 1:1 mapping of XMS to XtremIO array if I want to have more than 1 XtremIO cluster registered with the VPLEX? It seems that way and this seems counter-productive to consolidating XMS's so I wanted to validate if there was a way to utilize a multi-cluster XMS with VIAS or if I had to go back to 1:1 and re-deploy XMS's to make them 1:1 again?
2. Is there a hard requirements to have ONLY a SINGLE IG created with all VPLEX BE ports on it registered in the XtremIO array or can VIAS operate when the VPLEX is registered using multiple IG's?
Thanks,
-Keith
MikeCram
15 Posts
0
December 16th, 2015 08:00
Hi Keith,
1. Yes, you have to register XtremIO on a 1:1 basis and this is a VIAS limitation today. If you weren't using VIAS then you could do XMS consolidation.
2. Due to system limitations exposed in large scale environments we have been reconsidering best practices. We have come to the decision to create two initiator groups for VPLEX. You would put the VPLEX backend ports FC00 and FC01 for each director into one initiator group and then put ports FC02 and FC03 in a second initiator group. This will allow you to double the total volumes provisioned to VPLEX to 4096. VIAS will work with this configuration by placing the newly provisioned volumes into the initiator group with the fewest number of volumes.
--Mike
echolaughmk
522 Posts
0
December 16th, 2015 04:00
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!
echolaughmk
522 Posts
0
December 17th, 2015 04:00
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
MikeCram
15 Posts
0
December 17th, 2015 10:00
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
echolaughmk
522 Posts
0
December 17th, 2015 11:00
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
gvaidman
20 Posts
0
July 22nd, 2016 17:00
FYI for those finding this post now: this issue was resolved in VPLEX 5.5.2:
"VIAS now supports registering an XMS as an AMP managing multiple XtremIO arrays.
No longer have to create one REST AMP per array as in VPLEX 5.5 and 5.5.1.
During the REST AMP registration, it is no longer required to select the array. VIAS will automatically discover all the arrays.
Under the covers, VIAS will either use the XtremIO REST API v1 or v2 based on the XMS version for provisioning."