Host-based backup of VMware vSphere VMs.
Post Reply
ctg49
Enthusiast
Posts: 65
Liked: 45 times
Joined: Feb 14, 2018 1:47 pm
Full Name: Chris Garlington
Contact:

Creative solutions for shared VVOLs

Post by ctg49 »

All,

Looking for some creative solutions to a DR/BC scenario we have. At present, we're leveraging MSCS clusters for file servers and MSSQL servers in order to maintain HA across a few VM hosts. We can successfully back up clusters via VEEAM (which has worked wonderfully btw) and conceptually we understand how a full restoral would look, but we're currently spinning up a DR/BC project and we've hit a snag with them.

We have a VM environment backed by a SAN in our primary site, and the same model of SAN in our DR site which we intend to keep a full environment DR state asynchronously replicated there, but spun down (warm site). The SAN itself supports direct replication of non-VVOLs.

We shifted from pRDMs to VVOLs last year when vmware started supporting them (work great btw), so at present we have a VVOL datastore with about 2 dozen VVOLs within them tied to four different hosts (two clusters). All are backed up via VEEAM. Obviously VMware cannot snapshot these, which eliminates like 90% of the normal 'replicate/sync/failover' technologies leveraged out there, since they all leverage the same thing; vmware's snapshotting APIs. I understand many storage vendors support VVOL -> VVOL replication, independent of VM status, but ours does not. We're actively pressing on them to see if that's something they can get on the roadmap. Aside from that, I'm not quite sure what direction to go.

Options that I can see at present:
1) Convert all VVOL disks to pRDMs again, and create SAN-based replication of pRDMs, build new VMs with pRDMs backing the relevant disks, and let the SAN-level replication sync them until such time that we'd need to power up the VMs at the warm site. (Sloppy, lose benefits of VVOLs and gain headaches of pRDMs)
2) Create new VMs and VEEAM communication infrastructure (FW rules, permissions, etc) at warm site, leave offline. In the event of a DR scenario, spin those up, and get VEEAM to do an agent-based restore for the OS as well as all relevant disks. This would be necessary given that these are agent-based backups. (Ugly, slow restores)
3) Wait for vendor to support direct VVOL replication. (May never happen)
4) Wait for VEEAM to support some kind of failover cluster level replication or at least a rapid-deployment of VM OS + configuration + secondary disk restores. (Can that be a thing? This would be slow but at least elegant, and leveraging existing tools.)
5) Dump the MSCS clusters entirely, go back to boring servers. (lose HA, may not fly past leadership)
6) Creative solutions from the community/VEEAM.

Thanks!
HannesK
Product Manager
Posts: 14290
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Creative solutions for shared VVOLs

Post by HannesK »

Hello,
my favorite is 5, but from a technical perspective 1 is the only option I see.

Well, you could deploy a virtual storage as a VM and replicate that VM with Veeam replication. It's more a joke, I do that in my lab with virtual storage appliances to create MSCS. Nothing for production...

Best regards,
Hannes
ctg49
Enthusiast
Posts: 65
Liked: 45 times
Joined: Feb 14, 2018 1:47 pm
Full Name: Chris Garlington
Contact:

Re: Creative solutions for shared VVOLs

Post by ctg49 » 2 people like this post

Throwing an update into this, we had a conference call with our EMC rep and he stated that enabling VVOL replication is actually on the roadmap, and he's gathering some information regarding implementation timelines. The reasoning he gave for it not being enabled yet is due to 'low VVOL adoption rates', to which I reminded him that adoption rates are generally dictated by providers developing the technology, not by users using half-implemented technology. /rant
orb
Service Provider
Posts: 126
Liked: 27 times
Joined: Apr 01, 2016 5:36 pm
Full Name: Olivier
Contact:

Re: Creative solutions for shared VVOLs

Post by orb »

Hi,

So far, 3 storage vendors support VVOL replication 3PAR, Pure and Nimble. EMC, NetApp, IBM are still lacking the functionality. The replication function was introduced in 6.5. Here, the storage vendors are the one lagging on the technology because they don't have enough resources or maybe they have to rewrite some code.

VVOL, are basically RDM. You can attach them directly as a LUN since a VVOL datastore is a LUN with sub-LUNs. The downsides of VVOL with Veeam is you can't restore directly from a snapshot or backup from a storage Snapshot which I assume it disables the replication feature as well. I don't know if it is a technical limitation on the VDDK side or just it needs to be adapted for VVOLs concept in Veeam. I would not mind hearing a little more about that.

Oli
juanmachado
Enthusiast
Posts: 29
Liked: 8 times
Joined: Nov 18, 2020 3:59 pm
Full Name: Juan Machado
Contact:

Re: Creative solutions for shared VVOLs

Post by juanmachado »

Is this still the case.

I just added Nimble as a storage provider in Veeam. I can see all the data stores but not the vVols, meaning I can't backup/restore from the SAN snapshots.
But I found this paper from Veeam that says this:

Image
So, can you backup/restore vVols from veeam using the Nimble SAN snapshots?

Thanks
HannesK
Product Manager
Posts: 14290
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Creative solutions for shared VVOLs

Post by HannesK »

Hello,
VVOLS use per definition storage snapshots. There is no other way. It works out of the box with nothing to configure.

If you like the snapshot integration with browsing though the volumes / datastores, then you need classic datastores. Same if you want to back up via FC / iSCSI: classic datastores are needed.

Best regards,
Hannes
Post Reply

Who is online

Users browsing this forum: Baidu [Spider] and 71 guests