ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Xen Orchestra and Continuous Replication

    IT Discussion
    xen orchestra continuous replication
    7
    52
    6.7k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • olivierO
      olivier @Dashrender
      last edited by

      @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.
      FATeknollogeeF 1 Reply Last reply Reply Quote 0
      • olivierO
        olivier
        last edited by

        To take your example, your 700GB backup should take 4 or 5 hours max, and then delta would be almost done instantly.

        DustinB3403D 1 Reply Last reply Reply Quote 0
        • DustinB3403D
          DustinB3403 @olivier
          last edited by

          @olivier So a question for you is with CR, would you also take forever delta's?

          olivierO 1 Reply Last reply Reply Quote 0
          • olivierO
            olivier @DustinB3403
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • FATeknollogeeF
              FATeknollogee @olivier
              last edited by

              @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?

              DustinB3403D olivierO 2 Replies Last reply Reply Quote 0
              • DustinB3403D
                DustinB3403 @FATeknollogee
                last edited by

                @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.

                1 Reply Last reply Reply Quote 0
                • olivierO
                  olivier @FATeknollogee
                  last edited by

                  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.

                  FATeknollogeeF DustinB3403D 2 Replies Last reply Reply Quote 0
                  • FATeknollogeeF
                    FATeknollogee @olivier
                    last edited by

                    @olivier You prefer not to use local storage?

                    olivierO 1 Reply Last reply Reply Quote 0
                    • DustinB3403D
                      DustinB3403 @olivier
                      last edited by

                      @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.

                      1 Reply Last reply Reply Quote 0
                      • olivierO
                        olivier @FATeknollogee
                        last edited by

                        @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.

                        DustinB3403D 1 Reply Last reply Reply Quote 1
                        • DustinB3403D
                          DustinB3403 @olivier
                          last edited by

                          @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.

                          olivierO 1 Reply Last reply Reply Quote 0
                          • olivierO
                            olivier @DustinB3403
                            last edited by

                            @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)

                            DustinB3403D 1 Reply Last reply Reply Quote 0
                            • DustinB3403D
                              DustinB3403 @olivier
                              last edited by

                              @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.

                              😄

                              olivierO 1 Reply Last reply Reply Quote 0
                              • olivierO
                                olivier @DustinB3403
                                last edited by

                                @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)

                                1 Reply Last reply Reply Quote 0
                                • FATeknollogeeF
                                  FATeknollogee
                                  last edited by

                                  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?

                                  olivierO 1 Reply Last reply Reply Quote 0
                                  • DustinB3403D
                                    DustinB3403
                                    last edited by

                                    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?

                                    olivierO 1 Reply Last reply Reply Quote 0
                                    • olivierO
                                      olivier @FATeknollogee
                                      last edited by olivier

                                      @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

                                      1 Reply Last reply Reply Quote 0
                                      • olivierO
                                        olivier @DustinB3403
                                        last edited by olivier

                                        @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.

                                        1 Reply Last reply Reply Quote 0
                                        • DustinB3403D
                                          DustinB3403
                                          last edited by

                                          Considering that my new file server resides on a single host, yeah I'm gonna need to pre-seed the target.

                                          olivierO 1 Reply Last reply Reply Quote 0
                                          • olivierO
                                            olivier @DustinB3403
                                            last edited by

                                            @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?

                                            DustinB3403D 1 Reply Last reply Reply Quote 0
                                            • 1
                                            • 2
                                            • 3
                                            • 2 / 3
                                            • First post
                                              Last post