Lost Information during Multi-Cluster Management

Hi Keith,

What you see is correct – some of the objects (like tags) are defined at the XMS level instead of being defined at the array level. So when you move a cluster from one XMS to the other, you don’t carry over those objects (and the performance data) along with the array to the new XMS.

We should clearly document that in our user guides though. I will follow up on that.

Thanks for the feedback Avi. Here are my follow-up thoughts:

1. Definitely need to call that out in the docs, without that information known, its leading customers in the wrong direction so that to me needs to be updated ASAP.

2. Please tell me there is an enhancement for this coming asap - this seems like a terrible implementation of multi-cluster management given all the info you lose by moving these around or recovering from a possible loss or future pXMS/vXMS refresh. Is there any supported way to capture this information and transfer it as a workaround?

Thanks.

-Keith

1. Done. I have submitted a request to get this information added to the documentation.

2. Whilst this is a known issue, I am finding out about our plans to fix it as part of the roadmap.

Thank you.....feel free to hit me offline (I think you have my email) if you can share the second part when you have it.

Thanks,

-Keith

was the problem if managing multiple clusters resolved ..the one where with two clusters you can only create 4k volumes per cluster versus 8k per cluster when using stand alone xms per cluster?

Thanks Keith.  I just installed my second cluster (FAST.X behind VMAX3) so got excited thinking i could put both into one xms ..sounds like we are not there yet.  And yes, I would be really upset if i lost all my tags.

nah...that still exists and has to be an improvement in the XMS architecture to be fixed in the future. Its a limitation of the XMS and the fact that the limits are global on an XMS level, so if you have 2 clusters in one XMS, you have 8192 volumes total across BOTH clusters, not 8192 per each cluster like you would have with a 1:1 XMS-to-Array setup.

Basically I don't bother with anything multi-cluster related anymore....between the issues with limits and the lost information and impact to migrating clusters, its just cleaner to leave it all 1:1...albeit more cumbersome from a management perspctive if you have many clusters.

yeah.....depending on how you will scale the 2 clusters, I would be weary of putting them both under 1 XMS. You can do it, but if you look far out and think you will scale in a big way and then have to deal with migrating the XMS at a later date, I don't know if they will have enhanced the importing of it and if they didn't you will lose all your performance data and have to recreate tags, smtp, event filtering, LDAP, users, etc.....so I have just chosen the path that future proofs me the best for my customers

I was fortunate enough to be able to merge my cluster to XMS before I had created many tags, so they got recreated.

I can't imagine myself exceeding the combined cluster volume limits at any point soon, but you never know

Good to know. Only using RP with VNX at this stage, future though, who knows..

Well said Chris!

Just a small clarification: the number of replicated consistency groups is limited at 128, but you can have a maximum of 256 volumes per consistency group.

Agreed. This is a limitation of the XMS in regards to RP especially if you have many volumes being replicated and the default snapshots to keep per CG is left at 128. I had this concern for a customer who migrated from a VMAX as-is to the XtremIO. VMAX design practices were usually focused around many, smaller LUNs to drive performance. On the XtremIO, you can consolidate those many, smaller LUNs into fewer, larger volumes. This helped us to stay under the 8192 volumes/snapshots limit managed by the XMS while leaving the default of 128 snapshots on each CG within RP. I was told this 8192 XMS limit would be increasing in a future release of XtremIO so be sure to check the release notes and the scalability numbers chart.

Thanks,

Chris Mahon, VCP, EMCCE, EMCIE

EMC2 Delivery Specialist II

Here's the deal with LUN consolidation. XtremIO's appeal is that you get consistent performance regardless of the LUN size. So while I agree it is a perfect opportunity to consolidate LUNs for easier management, LUN consolidation doesn't fix the 8192 LUN limit and here is why. With RP involved, each RP PiT is really a snapshot volume on any XtremIO that is a target of RP (assume XtremIO-to-XtremIO replication with SBR). So given you can have a max of 500 snapshots per CG copy with RP, if you have consolidated to 100 LUNs in your environment and you want to get that max of 500 snapshots per CG copy, that is 100 LUNs x 500 snapshots per LUN on the target array, which is well over 8192. So the LUN limit effectively limits the amount of protection you can provide with RP per CG and it becomes a math exercise to ensure you are below the limits and have the growth you need. So it becomes a decision of protection versus limits IMO and this is where the LUN limit and the global scalability limits of a single XMS become a problem.

-Keith

Thanks, I know you guys understand the issue and how it impacts the protection window, I just wanted to provide the explanation versus always hearing LUN consolidation is the answer. Agree on the release notes point.

Thanks Avi.