-
- Enthusiast
- Posts: 65
- Liked: 45 times
- Joined: Feb 14, 2018 1:47 pm
- Full Name: Chris Garlington
- Contact:
Creative solutions for shared VVOLs
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!
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!
-
- Product Manager
- Posts: 14844
- Liked: 3086 times
- Joined: Sep 01, 2014 11:46 am
- Full Name: Hannes Kasparick
- Location: Austria
- Contact:
Re: Creative solutions for shared VVOLs
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
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
-
- Enthusiast
- Posts: 65
- Liked: 45 times
- Joined: Feb 14, 2018 1:47 pm
- Full Name: Chris Garlington
- Contact:
Re: Creative solutions for shared VVOLs
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
-
- Service Provider
- Posts: 129
- Liked: 27 times
- Joined: Apr 01, 2016 5:36 pm
- Full Name: Olivier
- Contact:
Re: Creative solutions for shared VVOLs
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
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
-
- Enthusiast
- Posts: 32
- Liked: 12 times
- Joined: Nov 18, 2020 3:59 pm
- Full Name: Juan Machado
- Contact:
Re: Creative solutions for shared VVOLs
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:
So, can you backup/restore vVols from veeam using the Nimble SAN snapshots?
Thanks
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:
So, can you backup/restore vVols from veeam using the Nimble SAN snapshots?
Thanks
-
- Product Manager
- Posts: 14844
- Liked: 3086 times
- Joined: Sep 01, 2014 11:46 am
- Full Name: Hannes Kasparick
- Location: Austria
- Contact:
Re: Creative solutions for shared VVOLs
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
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
Who is online
Users browsing this forum: No registered users and 36 guests