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
      last edited by

      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_operations field of the VM (we added start as a blocked operation).

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

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

        FATeknollogeeF DashrenderD 2 Replies Last reply Reply Quote 1
        • DustinB3403D
          DustinB3403 @olivier
          last edited by

          @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_operations field of the VM (we added start as 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?

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

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

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

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

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

                @DustinB3403 Just create a test VM and start to use it. And play with it 🙂

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

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

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

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

                    olivierO BRRABillB 2 Replies Last reply Reply Quote 0
                    • olivierO
                      olivier @FATeknollogee
                      last edited by

                      @FATeknollogee Citrix. Backup speed is not XO dependent.

                      1 Reply Last reply Reply Quote 0
                      • KellyK
                        Kelly @Dashrender
                        last edited by

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

                        Haven't tried it yet. I'm just reaching the evaluation stage.

                        1 Reply Last reply Reply Quote 0
                        • BRRABillB
                          BRRABill @FATeknollogee
                          last edited by BRRABill

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

                          1 Reply Last reply Reply Quote 1
                          • DashrenderD
                            Dashrender @olivier
                            last edited by

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

                            olivierO 1 Reply Last reply Reply Quote 0
                            • 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
                                            • 1
                                            • 2
                                            • 3
                                            • 2 / 3
                                            • First post
                                              Last post