Unsolved
This post is more than 5 years old
522 Posts
0
2256
LUN Mapping Limitation
Why does XtremIO randomly limit the number of volumes that can be mapped in a single operation? And why does this number seem to decrement over time as more volumes are added - is there an intrinsic limit based on the metadata consumption?
If I have 300 volumes to be mapped, it will limit me to 190 and throw and error. The if I map another 300 a week later, it will limit me to 182 volumes - seems like an odd limit and just trying to understand it better since I can't find it documented anywhere yet....but I have yet to go through all 15 of the documentation sources within EMC
Thanks!
-Keith
dunnel1
5 Posts
0
November 9th, 2016 13:00
Keith,
I am not aware of any limitation for "amount of mappings in a single operation" (but would imagine a soft limit must exist somewhere along the line). Are you adding the initiators on a cluster which is already processing I/O i.e. a system which is possibly busy from a workload point of view?
echolaughmk
522 Posts
0
November 10th, 2016 06:00
Hi,
Yeah - the cluster is already under regular workload and had a bunch of LUNs mapped to initiators. When we go to add more new LUNs to the same initiator groups, there is an error thrown in the gui about a limit it can map. So the example I had was trying to map 303 new LUNs to a cluster - the error said it could only map 190, so I had to do them in 2 chunks. 2 weeks later, I needed to add another 200 LUNs and I got an error that I could only map 182 - so there definitely seems to be a scale limitation either limited by the metadata of the cluster (in use or configured) or something else. This is what I am trying to understand to explain. I can reproduce this almost at will so it looks like it should be a known limitation or something from what I can tell....I just can't find any info on it.
Thanks!
-Keith
mabela
33 Posts
0
November 10th, 2016 09:00
You can find information regarding scalability numbers in the XIOS release notes. The latest can be found at: https://support.emc.com/docu79428_XtremIO-Storage-Array-Software-4.0.15-15-Release-Notes.pdf?language=en_US
Please keep in mind that the second is at the XMS level, not at the cluster level.
Swapnil_Pandey
86 Posts
0
November 10th, 2016 10:00
Hi,
Have you tried using XMCLI to map volumes, have never tested it and never heard of it. It will be interesting to know however if anyone else have noticed the same?
Regards,
Swapnil
echolaughmk
522 Posts
0
November 10th, 2016 10:00
Thanks Avi 4.10 code and 4.2 on the XMS. It's not really an issue, just seems like an arbitrary limit at this point still (since I haven't eclipsed the array limits)
thanks.
Kumar_A
727 Posts
0
November 10th, 2016 10:00
Hi Keith,
We are looking into it. Which code version are you running on the array and the XMS?
echolaughmk
522 Posts
0
November 10th, 2016 10:00
No - that is not what I am asking about or seeing. This is an event being logged in the process of performing the mapping to initiators. array limits have not been reached - it simply cannot process X number of items at a time and that number changes as the array gets busier - this seems 100% like a scale issue on the array and its code unless there is some other reason for it.
echolaughmk
522 Posts
0
November 10th, 2016 11:00
Nope...haven't tried the CLI to map them - it is much easier to shift-click a range in the GUI to be honest. It's not a major deal as I can do it in chunks - rather just annoying at times.