Xen Orchestra and Continuous Replication
-
@DustinB3403 said in Xen Orchestra and Continuous Replication:
My question is there a way to simple change the flag that they have set, I would hate to have to clone something that has already been cloned to an identical server to boot it up in an emergency..
Seems backwards, although I understand the concern.
I'm sure there is, but it would require some changes from the console.
-
I've actually been looking at the commercial version of XO for my primary backup system now that I'm almost 100% XenServer. It looks like decent value for the money.
-
@Kelly said in Xen Orchestra and Continuous Replication:
I've actually been looking at the commercial version of XO for my primary backup system now that I'm almost 100% XenServer. It looks like decent value for the money.
Are you using it for backups as well?
If so, how is the backup performance wise? the last time I tried it was pretty slow. 700 GB took 2+ days, that was before the last major update though, and XS v6.5 -
We prevent to start it for a very good reason: if you start it, you'll change blocks on the disk. You next backup will send the diff coming from the original VM, and apply it. But because blocks changed, this will corrupt the copy.
A fast clone won't cost you anything. Anyway, if you are SURE about what you are doing (eg original VM destroyed), you'll have to change the
blocked_operationsfield of the VM (we addedstartas a blocked operation). -
@Dashrender Speed of backup is not related to XO. Believe me, if we could done something about that, we would do it. But there is improvements on XS7 and a new patch coming will also double or triple perfs (at least).
-
@olivier said in Xen Orchestra and Continuous Replication:
We prevent to start it for a very good reason: if you start it, you'll change blocks on the disk. You next backup will send the diff coming from the original VM, and apply it. But because blocks changed, this will corrupt the copy.
A fast clone won't cost you anything. Anyway, if you are SURE about what you are doing (eg original VM destroyed), you'll have to change the
blocked_operationsfield of the VM (we addedstartas a blocked operation).So the operation is, CR to your other host, and if it comes to needing to run this CR-copy there is an Fast Clone function there.
Which goes and boots the VM?
-
@DustinB3403 Yes, because it's a clone, it left the initial copy untouched (and it still be used for the next backup). If you don't need the original and the copy because of the new clone, remove them. It won't affect the clone.
-
@olivier I wish I could see it in your lab just for testing, I just don't have enough hardware here / time to set it all up.
Going in blind.
-
@DustinB3403 Just create a test VM and start to use it. And play with it
-
@olivier said in Xen Orchestra and Continuous Replication:
@DustinB3403 Just create a test VM and start to use it. And play with it
you know... if I weren't tired I might have thought of that..
-
@olivier said in Xen Orchestra and Continuous Replication:
@Dashrender Speed of backup is not related to XO. Believe me, if we could done something about that, we would do it. But there is improvements on XS7 and a new patch coming will also double or triple perfs (at least).
A new patch from you (XO) or from Citrix/Xen?
-
@FATeknollogee Citrix. Backup speed is not XO dependent.
-
@Dashrender said in Xen Orchestra and Continuous Replication:
@Kelly said in Xen Orchestra and Continuous Replication:
I've actually been looking at the commercial version of XO for my primary backup system now that I'm almost 100% XenServer. It looks like decent value for the money.
Are you using it for backups as well?
If so, how is the backup performance wise? the last time I tried it was pretty slow. 700 GB took 2+ days, that was before the last major update though, and XS v6.5Haven't tried it yet. I'm just reaching the evaluation stage.
-
@FATeknollogee said in Xen Orchestra and Continuous Replication:
@olivier said in Xen Orchestra and Continuous Replication:
@Dashrender Speed of backup is not related to XO. Believe me, if we could done something about that, we would do it. But there is improvements on XS7 and a new patch coming will also double or triple perfs (at least).
A new patch from you (XO) or from Citrix/Xen?
There is a thread here on ML that describes the bug, and the patching process Citrix is working on. You can subscribe to it to follow along with what they are doing. @olivier is a major piece of that.
-
@olivier said in Xen Orchestra and Continuous Replication:
@Dashrender Speed of backup is not related to XO. Believe me, if we could done something about that, we would do it. But there is improvements on XS7 and a new patch coming will also double or triple perfs (at least).
Yeah - I know that it's not XO's fault. Considering how slow backups are on XS, I'm a bit amazed it's used. I say this slightly tongue in cheek.
I know there was talk of improvement - was the a placebo before in earlier versions of XS 7?
-
@Dashrender It's not slow for everyone: I'm maxing a GBit link without any problem and we have some users having larger connections used for backup. Otherwise, we won't have clients.
Also, everyone knows (in XS world at least) that having large VMs -in terms of disk space- is not a good idea*, so it's not a common practice (and that's good).
- : for a lot of reasons, time to backup, snapshot space, Xen storage motion time, restore time and a LOT of things.
-
To take your example, your 700GB backup should take 4 or 5 hours max, and then delta would be almost done instantly.
-
@olivier So a question for you is with CR, would you also take forever delta's?
-
@DustinB3403 This is kind of similar than delta backup, but the merge is done inside XenServer directly. After the first replication (full), it will only send the delta's.
-
@olivier said in Xen Orchestra and Continuous Replication:
@Dashrender It's not slow for everyone: I'm maxing a GBit link without any problem and we have some users having larger connections used for backup. Otherwise, we won't have clients.
Also, everyone knows (in XS world at least) that having large VMs -in terms of disk space- is not a good idea*, so it's not a common practice (and that's good).
- : for a lot of reasons, time to backup, snapshot space, Xen storage motion time, restore time and a LOT of things.
How large is too large?
