• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 8848 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Standby VM Sync Time

Corrigun
over 7 years ago

It appears that if one export for a standby VM fails then the entire export process begins again. This would be understandable if there was a mandated time or number of data changes for export VM's to remain in "sync" but there isn't.

For instance if the queue is backed up RR does not seem to care if the window is missed, it simply does it later. Also, I can set my backup schedule on any given machine for once an hour or once a day and they still stay in "sync" regardless of changes or data moved.

Given these things why does RR barf and start over if the hypervisor happens to be off or the network is down for one snapshot?

Also in regards to standby VM's. Is it possible for these to "sync" while running or paused? I dare not try it knowing one problem will force me to start over. A process that can take days for large servers.

  • 0 over 7 years ago

    What you are describing is correct, if the export job fails, the core will queue up a full export upon the next pass. The intent here is that the core will not leave your virtual clone's stability up to chance. This is by design as another layer of protection for you so that the day that you go to power on the VM it is there, ready to go, and you have a lesser risk of a configuration issue or BSOD boot cycle. This is an extension of why the first step in each VS pass is that we revert the existing snapshot in VMware or HV so that any booting/changes/modifications that you make to the clone are removed so they are still indeed a clone of the production machine, we're trying our best to make sure that the day you need it, it is there and ready for you.

    For your other questions, the virtual standby jobs are set to run after a backup (or a replication on the target core) are complete, if you wanted to automate them, you'd have to pause them from the GUI and then configure a PS script or something of that nature to kick them off at a certain desired time. Or, if it works for you environment you could switch to doing daily backups and then the virtual standby would kick off right after the backup at said desired time.

    For the 'queue' you are correct, once the scheduler releases a job into the queue, then the logic is such that that job will run. The scheduler is only set to release the jobs, not to monitor how long they take or govern when they should stop or start. This goes back to the data protection concept, whether the job takes 1 hour or 8 we will continue as one day we expect you will want to restore from that, so we want it intact.

    I'll honestly have to test the scenario of the hypervisor being off, as I can't definitively say if this forces a full export or not off-hand. That I'd be happy to test, however I was/am unaware of that result at this point in time, however I'd be happy to test that scenario.

    This point, forgive me, I am not sure what you mean?
    "Also in regards to standby VM's. Is it possible for these to "sync" while running or paused?"

    Are you trying to run an export while the clone VM is powered on? I'm sorry I'm not sure what you mean there.

  • 0 over 7 years ago

    Hi Phuffers,

    I really only had two questions.

    1) Why does one missed for any reason update/export/sync of a standby VM trigger a full "one time" type export of the VM?

    If the answer is in the name of integrity then so be it I guess. I'm not sure why it's not tied to data changes or a total amount of time or whatever.

    A missed snaphot does not trigger a new base image so why would a missed export trigger a whole new VM is my logic I guess.


    2) Can a running VM be exported to/synced/updated?

    Exactly like it sounds. Can a running or paused standby VM be updated or does it have to be off?

    The logic behind this is it takes a significant amount of time to boot a new VM and install services, attach to a network, etc. If it was up and running or paused at that state it this would dramatically cut down time in a failover situation.

    No idea about the automation thing you referenced. Not a question of mine anyway.

    Thanks.

  • +1 over 7 years ago

    The missed job triggering a full export, like I mentioned I'll be happy to check, that is news to me. The failed export though, yup, that will most certainly get you a full export.

    For the virtual standby itself, that MUST be powered off. Having it powered on, or if you are going in can configuring then you actually are manually creating a situation that we would expect to you to have future issues. As mentioned before that is why the first things we do at the start of the 'next' pass is revert your snapshot that we left open so that it is back to being where we left it when the last job finished. If you are going in and booting them up, editing something customizing we would expect the clone VM to BSOD on you the day you need to use it, as that is essentially 2 hands in the cookie jar editing the VM without the other knowing about it. To answer your question the VM must be off to update it, which is common in the DP industry (or at least to the DP solutions that I have seen/used over the years).

    Forgive me, I mentioned the scheduling off your mandated time comment, perhaps I misunderstood. 

  • 0 over 7 years ago
    What happens if I need the VM and it's in the middle of one of these large base image moves (or any export for that matter)?

    Is the previous VM going to be available? If not this is a pretty major concern.
  • 0 over 7 years ago
    During the export the VM is not available no. Also if you cancel an export job while it is going, or at least during a base image, it will orphan the VM, so you would be left with an inoperable VM at that point. You would be at the mercy of letting it finish similar to a restore.
  • 0 over 7 years ago
    If the host is powered off the VS doesn't even run - the core logs this in the journal:

    Failed to enqueue continuous export of 'xxxxxxxxxxxx'. Reason: Unable to connect to the remote server details

    Then the next export pass is another incremental just to catch up.
  • 0 over 7 years ago
    So only if the network connection fails or the export is cancelled should trigger a base move?

    It's too bad you can't stagger exports between hypervisors. If you are syncing frequently there is a good chance it will be running when you may need it.

    I thought about backing up the VM itself locally between exports but it takes too long.
  • 0 over 7 years ago

    With the addition of the backup actually doing a base image, that pretty much sums it up.

    The only way you can really stagger them would be to stagger the backups themselves, since the VS follow the backups. Once you're in sync the VS are usually in/out in a matter of minutes (depending on your change rate). In normal production by the time a server were to actually 'go down' and you notice and respond to it, chances are high that there was not a backup just done a moment ago, so the VS job shouldn't be running as nothing was sent to it. Now, yes, if you had just done a base or something, that is a different story.

    Once setup/in production (and local) this does come up when the core has to do a full export and the question of why gets asked, however I can't say that I see the situation much (if at all) where customers are in the middle of a VS and need to use the VM, but it is indeed a gamble.