Xen Orchestra and Continuous Replication
-
@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.
-
@DustinB3403 I mean latency of a NAS/SAN for serving files in a "normal" network isn't an issue in general (except for bad designed networks or undersized). For a DB or webserver, latency matters far more (with some order of magnitude)
-
I thought all the new cool kids are doing local storage/HCI etc..
Now @olivier is saying he prefers a remote mounted datastore!
@olivier I thought you were one of the cool kids? -
So @olivier just reading this here.
It says
1.Create a CR Job
2. Manually run the first job
3. When completed export the backup Why do we need to export the backup?
4. Import it to the destination
5. Remove the local copy.I'm planning on performing identical host to host replication. Is that wrong?
-
@FATeknollogee I'm not especially vulnerable to trends. I prefer solutions that works and in the same time which are not over complicated.
In this case, VMs with larger disks are always more complicated to handle in the end. That's my experience, in the XenServer world.
I don't say to never do this or that, that's just in general, you are less exposed by splitting problems into smaller pieces.
edit: that's also due to the storage architecture in XenServer. Maybe if it was far better/faster, my advice would be probably different. Having a lot of hope for SMAPIv3
-
@DustinB3403 said in Xen Orchestra and Continuous Replication:
So @olivier just reading this here.
It says
1.Create a CR Job
2. Manually run the first job
3. When completed export the backup Why do we need to export the backup?
4. Import it to the destination
5. Remove the local copy.I'm planning on performing identical host to host replication. Is that wrong?
This is the doc about seeding. Do you need to make an initial seed, really?
edit: read the doc carefully, seeding is only a specific case if you need it. I think you read too fast.
-
Considering that my new file server resides on a single host, yeah I'm gonna need to pre-seed the target.
-
@DustinB3403 I don't see the connection here. Can you explain further? You can't afford to do the initial replication over the network, so you need to export the VM on a disk that you can move over the destination?
-
@olivier said in Xen Orchestra and Continuous Replication:
@DustinB3403 I don't see the connection here. Can you explain further? You can't afford to do the initial replication over the network, so you need to export the VM on a disk that you can move over the destination?
My plan was to go from server to server over the network.
I could push it to my synology that is taking my backups now, and then offload it to the second server, this seems cumbersome though.
-
@DustinB3403 Manual seed is for people who can't afford to do the first replication over the network due to very low bandwidth. Otherwise, don't do it.
-
@olivier said in Xen Orchestra and Continuous Replication:
@DustinB3403 Manual seed is for people who can't afford to do the first replication over the network due to very low bandwidth. Otherwise, don't do it.
What is your definition of very low bandwidth?
-
@DustinB3403 Do you need or not, to transfer the VM content manually with a hard drive disk or by any mean that is not a network copy?
If not, don't even read the manual seed procedure.
-
I don't need to manually transfer the content, I just want to hit go, have it take the initial snapshot (I assume it's using snapshots for this) and then seed over.
I wonder how long the initial will take to complete....
-
@DustinB3403 said in Xen Orchestra and Continuous Replication:
I don't need to manually transfer the content, I just want to hit go, have it take the initial snapshot (I assume it's using snapshots for this) and then seed over.
I wonder how long the initial will take to complete....
It should take the same no matter what.
Copy to pre-seed location or copy over network to other server.
Both would be the same. -
@DustinB3403 Forget about manual seeding. Just don't read this paragraph and apply the "normal" procedure.
This is only relevant situation is for people having multiple datacenters with very bad interconnection, when copying VM on a disk and then take your car to the other datacenter has a better bandwidth (sneaker net).
-
@olivier said in Xen Orchestra and Continuous Replication:
@DustinB3403 Forget about manual seeding. Just don't read this paragraph and apply the "normal" procedure.
This is only relevant situation is for people having multiple datacenters with very bad interconnection, when copying VM on a disk and then take your car to the other datacenter has a better bandwidth (sneaker net).
Gotcha.
-
I'll improve the doc to be sure there no confusion possible
