Xen Orchestra and Continuous Replication
-
@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?
-
@FATeknollogee said in Xen Orchestra and Continuous Replication:
@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?
Hundred's of TB's is the impression I was under.
-
Hundreds of GBs starts to be harder/less flexible to play with in general. Anyway, the limit is 2TB due to VHD format.
I would prefer to use a filer and NFS/SMB to it from VMs. This way you separate your VM issues to your data/file issues.
-
@olivier You prefer not to use local storage?
-
@olivier yeah that sounds as if you prefer iSCSI data storage on the VM.
This way your VM is a meager 350GB c drive, and the data just hooks in from the back end.
-
@FATeknollogee SR type doesn't matter in this case. I said to NOT attach large disks to VMs but to prefer, inside the VM, to mount a remote data store from a NAS/SAN/whatever.
This way your VM keeps a system disks (let's say 20 or 50GB) and that's all to backup/restore.
-
@olivier said in Xen Orchestra and Continuous Replication:
@FATeknollogee SR type doesn't matter in this case. I said to NOT attach large disks to VMs but to prefer, inside the VM, to mount a remote data store from a NAS/SAN/whatever.
This way your VM keeps a system disks (let's say 20 or 50GB) and that's all to backup/restore.
That is how I read it, but it seems backwards to do so generally. Since local will always have a performance boost.
-
@DustinB3403 You have to put this into context. A fast local SSD disk for a database or webserver is not a bad idea. But that won't need hundreds of GBs.
For a "datastore", there isn't any perf problem to serve larger files on a remote location (when latency isn't an issue)
-
@olivier said in Xen Orchestra and Continuous Replication:
@DustinB3403 You have to put this into context. A fast local SSD disk for a database or webserver is not a bad idea. But that won't need hundreds of GBs.
For a "datastore", there isn't any perf problem to serve larger files on a remote location (when latency isn't an issue)
combating latency is the issue though.
