-
- Enthusiast
- Posts: 50
- Liked: never
- Joined: Jan 20, 2015 9:03 pm
- Full Name: Rasmus Andersen
- Contact:
Instant VM Recovery maximums
Hello
I am struggeling to find any sizing recommendations as to how many simulatenous Instant VM Recovery jobs you can run?
For this particular case it will be Hyper-V server 2016... but I guess the same recommendations would apply to VMware as well??
I am struggeling to find any sizing recommendations as to how many simulatenous Instant VM Recovery jobs you can run?
For this particular case it will be Hyper-V server 2016... but I guess the same recommendations would apply to VMware as well??
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Instant VM Recovery maximums
I blogged about this a while ago after some customer tested this and shared numbers... don't remember the exact details by now, but it was on VMware and over a couple of hundreds VMs. Of course, not something you'd want to do in real life due to backup repository IOPS constraints, but it will work reliably. And if you have multiple separate repositories, then you can scale it horizontally.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Instant VM Recovery maximums
Here, found it:
Here is an absolutely fascinating number from a POC with one of our prospects. They've been testing Instant VM Recovery scalability, and ended up running 281 VMs from the backup! Now, of course those instant restores were PowerShell scripted, otherwise there would be too much clicking involved... and I assume the instantly recovered VMs were light on the load too – because VM startup was taking less than 1 minute per VM up until the end. Still, this is an extremely impressive result – I don't believe we pushed IR engine this far internally, primarily because achieving anything like this has two critical dependencies. First, their backup storage is a beast designed according to my earlier recommendations (big fat Cisco S3260 with a few SSDs dedicated to vPower NFS cache). Second, getting there absolutely requires version 9.5, where our developers have put an incredible amount of effort optimizing and accelerating vPower NFS to improve its scalability by an order of magnitude. And I do know they did not have enough time to include some final touches – so there's even more improvement to look forward to in the future!
-
- Enthusiast
- Posts: 50
- Liked: never
- Joined: Jan 20, 2015 9:03 pm
- Full Name: Rasmus Andersen
- Contact:
Re: Instant VM Recovery maximums
Hi Gostev
Thanks for info.
However for Hyper-V, I understand Instant VM Recovery is a different than with VMware... My thoughts have been exactly on the Cisco S3260 server with a lot of NL-SAS disks, but does the sizing with SSD's for vPower NFS cache still apply in Hyper-V scenario?
Thanks for info.
However for Hyper-V, I understand Instant VM Recovery is a different than with VMware... My thoughts have been exactly on the Cisco S3260 server with a lot of NL-SAS disks, but does the sizing with SSD's for vPower NFS cache still apply in Hyper-V scenario?
-
- Enthusiast
- Posts: 96
- Liked: 24 times
- Joined: Oct 08, 2014 9:07 am
- Full Name: Jazz Oberoi
- Contact:
Re: Instant VM Recovery maximums
Does it ?rasmusan wrote:Hi Gostev
Thanks for info.
However for Hyper-V, I understand Instant VM Recovery is a different than with VMware... My thoughts have been exactly on the Cisco S3260 server with a lot of NL-SAS disks, but does the sizing with SSD's for vPower NFS cache still apply in Hyper-V scenario?
-
- Product Manager
- Posts: 8191
- Liked: 1322 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Instant VM Recovery maximums
No, it doesn't. Hyper-V indeed works differently. When you start instant VM recovery, a dummy VM with empty disks on the target host (which you select in the wizard) is created. VBR creates a protective snapshot for the dummy VM and then the VM is started. (This is necessary to make sure there is no data loss). Then we start a pair of data movers on the backup repository and on the target host to mount the VM disks from the backup file to the dummy VM.
However, with this type of recovery, IOPS remain an important part. As you can read above, there is some IO being performed .
However, with this type of recovery, IOPS remain an important part. As you can read above, there is some IO being performed .
Who is online
Users browsing this forum: No registered users and 72 guests