HPE Nimble & Veeam Storage Discovery Jobs causing vCenter storage disconnects

[thomas.biesmans]

To be fair Andreas, most updates come after someone asking for an update. So I'm kind of glad there's the occasional +1 asking for an update, seeing as we've got our own fair share of Nimble PP customers awaiting this feature. Perhaps a two-monthly pro-active update on your part may help lowering that need? But hey, that's a sensitive roadmap issue that has no perfect solution, so this'll do I guess? At least you're miles and miles ahead of something like Microsoft's feature request page, which is a horrible experience feedback-wise and which should burn in hell.

[Andreas Neufert]

Thanks, sure. Veeam Product Management monitors very closely the different topics and as well the likes. Likes will achieve the same as a +1 without making it hard to read through the topic.

[Coldfirex]

Is this still on track for v12 (or whatever the next version is)?

[foggy]

Hi Alan, if you're talking about Synchronous Replication support, then it still has chances for v12.

[mark49808]

I was brought to this thread by a support case after finding out after 2 years of successfully backing up synchronously replicated volumes from storage snapshots that its "not supported". I'd like to understand what specifically is not supported as it generally works great for us.

Per the prior comment in this thread: "The solution for us was to change the volume presentation on the Nimble systems from "Volume and Snapshots" to "Volume only". - Yes, we found this out the hard way too. The workaround is easy provided you remember to do this at volume creation.

We have a synchronously replicated setup that has been running for ~2 years without a problem being backed up with Veeam. Jobs work fine, as do restores. Nothing "wrong'" as far as I can tell.

We have another replicated setup (two different arrays at a different site) that works 95%, but will frequently leave behind online snapshots. They are easy enough to clean up, just annoying. Per my support case "There is an issue with Veeam indexing the arrays and often sends the offline request to the wrong array, causing the snapshot to be left online and undeleted"

So I guess my question is, I have Veeam and synchronously replicated volumes that I need to back up. Is there any 'danger' in continuing to run like this? Veeam can only access snapshots, and the esx hosts can only see Volume Only, so I would think not.

What else am I missing besides an occasional snapshot left open, which seems mostly harmless as long as they are cleaned up? I also don't understand why one array pair never has a problem while one does but I suppose i can file that under "not supported".

Last question, is this officially going to be in v12?

[Andreas Neufert]

Hi Mark,

thanks for the feedback and request.
For the "Volume only" setting needed for VMware (as outlined in the Nimble best practices guide for VMware): I would find it as well better if Nimble would switch the standard to "Volume only" when new volumes are created to follow their own best practices (has nothing to do with Veeam, we are just affected by the default setting not being the best practices for VMware).

For the Syncronous Replication.
Nimble Syncronous Replication serves the same volume (with same volume ID) from two different systems. Instead of having as well one storage management endpoint, Nimble has 2 management endpoint for this volume. Veeam is not aware of this situation (we do not correlate that this volume is served by 2 different storages). If you add both system to the same Veeam Backup Server, then it is "random" on what entry in our list we find first and create the snapshot on this management entity. As you said it worked 95% of the time for you. As we can not guarantee the outcome it is "unsupported" to add both storage management endpoints to the same Veeam server. If you can live with the mentioned side effects and that we can not guarantee on which storage we process snapshot and their deletes then there is no risk other than this.
Officially we support this scenario only in sitautions where each Nimble get an own B&R Server and you decide what is processed on what side. In v12 we will bring Nimble Peer Persistence support to address this officially. Basically it will bring the awareness for the volumes served from 2 controllers and we will process snapshots on both sides at the same time (it is anyway a syncronous volume situation).

[dasfliege]

+1 for immediate integration

[rennerstefan]

@dasfliege as Andreas answered above and I just did on your other post v12 is targeting the Peer Persistence support for Nimble.
Hope that helps.

Thanks