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

    Server 2012 Hyper V Cluster

    IT Discussion
    7
    27
    913
    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.
    • scottalanmillerS
      scottalanmiller
      last edited by

      To compare in a different way, think of having a single server with two hard drives. You are require to protect the data on the drives.

      You could do one of two things:

      1. Use RAID 1, all data is instantly protected on write. Two copies made of every thing that goes to disk, every time. Failover is transparent and instantaneous. Recovery is also transparent.
      2. Create an identical filesystem on the second drive and use a tool like Robocopy to copy all of the stuff from the first disk to the second every twenty minutes and hope that it gets everything. And recovery is difficult.

      There is a reason why approach 1 is the industry standard and a foregone conclusion and approach 2 would be considered crazy.

      Taking this to the two node space, something like DRBD or Starwind is literally using RAID 1 over the network, and the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

      ObsolesceO 1 Reply Last reply Reply Quote 0
      • ObsolesceO
        Obsolesce @scottalanmiller
        last edited by

        @scottalanmiller said in Server 2012 Hyper V Cluster:

        the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

        It uses Hyper-V VSS

        scottalanmillerS 1 Reply Last reply Reply Quote 0
        • scottalanmillerS
          scottalanmiller @Obsolesce
          last edited by

          @Obsolesce said in Server 2012 Hyper V Cluster:

          @scottalanmiller said in Server 2012 Hyper V Cluster:

          the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

          It uses Hyper-V VSS

          I know, but that's only one piece of it. VSS grabs the snap, something transfers it, and that part might actually be Robocopy. VSS isn't the part that does the work we are talking about.

          JaredBuschJ 1 Reply Last reply Reply Quote 0
          • JaredBuschJ
            JaredBusch @scottalanmiller
            last edited by

            @scottalanmiller said in Server 2012 Hyper V Cluster:

            @Obsolesce said in Server 2012 Hyper V Cluster:

            @scottalanmiller said in Server 2012 Hyper V Cluster:

            the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

            It uses Hyper-V VSS

            I know, but that's only one piece of it. VSS grabs the snap, something transfers it, and that part might actually be Robocopy. VSS isn't the part that does the work we are talking about.

            The transfer can have zero to do with the Veeam instance. You tell the backup job during creation if it will use the Veeam server or go direct from hypervisor to storage repository.

            DashrenderD ObsolesceO scottalanmillerS 3 Replies Last reply Reply Quote 0
            • DashrenderD
              Dashrender @JaredBusch
              last edited by

              @JaredBusch said in Server 2012 Hyper V Cluster:

              @scottalanmiller said in Server 2012 Hyper V Cluster:

              @Obsolesce said in Server 2012 Hyper V Cluster:

              @scottalanmiller said in Server 2012 Hyper V Cluster:

              the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

              It uses Hyper-V VSS

              I know, but that's only one piece of it. VSS grabs the snap, something transfers it, and that part might actually be Robocopy. VSS isn't the part that does the work we are talking about.

              The transfer can have zero to do with the Veeam instance. You tell the backup job during creation if it will use the Veeam server or go direct from hypervisor to storage repository.

              hmmm... this means I have something look at!

              JaredBuschJ 1 Reply Last reply Reply Quote 0
              • ObsolesceO
                Obsolesce @JaredBusch
                last edited by

                @JaredBusch said in Server 2012 Hyper V Cluster:

                @scottalanmiller said in Server 2012 Hyper V Cluster:

                @Obsolesce said in Server 2012 Hyper V Cluster:

                @scottalanmiller said in Server 2012 Hyper V Cluster:

                the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

                It uses Hyper-V VSS

                I know, but that's only one piece of it. VSS grabs the snap, something transfers it, and that part might actually be Robocopy. VSS isn't the part that does the work we are talking about.

                The transfer can have zero to do with the Veeam instance. You tell the backup job during creation if it will use the Veeam server or go direct from hypervisor to storage repository.

                This is true. I have a backup repo (das) attached to a Hyper-V Server, and the Veeam backup server is separate. The data never leaves the Hyper-V Server. Same with the tape backups.

                1 Reply Last reply Reply Quote 0
                • scottalanmillerS
                  scottalanmiller @JaredBusch
                  last edited by scottalanmiller

                  @JaredBusch said in Server 2012 Hyper V Cluster:

                  @scottalanmiller said in Server 2012 Hyper V Cluster:

                  @Obsolesce said in Server 2012 Hyper V Cluster:

                  @scottalanmiller said in Server 2012 Hyper V Cluster:

                  the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

                  It uses Hyper-V VSS

                  I know, but that's only one piece of it. VSS grabs the snap, something transfers it, and that part might actually be Robocopy. VSS isn't the part that does the work we are talking about.

                  The transfer can have zero to do with the Veeam instance. You tell the backup job during creation if it will use the Veeam server or go direct from hypervisor to storage repository.

                  VSS is Volume Shadow Copy. The question was really... after VSS takes a snap, what MS tool is being used to move the data over to the other node.

                  JaredBuschJ DashrenderD 2 Replies Last reply Reply Quote 0
                  • JaredBuschJ
                    JaredBusch @scottalanmiller
                    last edited by

                    @scottalanmiller said in Server 2012 Hyper V Cluster:

                    @JaredBusch said in Server 2012 Hyper V Cluster:

                    @scottalanmiller said in Server 2012 Hyper V Cluster:

                    @Obsolesce said in Server 2012 Hyper V Cluster:

                    @scottalanmiller said in Server 2012 Hyper V Cluster:

                    the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

                    It uses Hyper-V VSS

                    I know, but that's only one piece of it. VSS grabs the snap, something transfers it, and that part might actually be Robocopy. VSS isn't the part that does the work we are talking about.

                    The transfer can have zero to do with the Veeam instance. You tell the backup job during creation if it will use the Veeam server or go direct from hypervisor to storage repository.

                    VSS is Volume Shadow Copy. The question was really... after VSS takes a snap, what MS tool is being used to move the data over to the other node.

                    No idea. I just know the Veeam tools that are put onto the hypervisor and storage repository control things (if told to do so).

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

                      @scottalanmiller said in Server 2012 Hyper V Cluster:

                      @JaredBusch said in Server 2012 Hyper V Cluster:

                      @scottalanmiller said in Server 2012 Hyper V Cluster:

                      @Obsolesce said in Server 2012 Hyper V Cluster:

                      @scottalanmiller said in Server 2012 Hyper V Cluster:

                      the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

                      It uses Hyper-V VSS

                      I know, but that's only one piece of it. VSS grabs the snap, something transfers it, and that part might actually be Robocopy. VSS isn't the part that does the work we are talking about.

                      The transfer can have zero to do with the Veeam instance. You tell the backup job during creation if it will use the Veeam server or go direct from hypervisor to storage repository.

                      VSS is Volume Shadow Copy. The question was really... after VSS takes a snap, what MS tool is being used to move the data over to the other node.

                      Sounds almost like a remote powershell command.

                      1 Reply Last reply Reply Quote 0
                      • JaredBuschJ
                        JaredBusch @Dashrender
                        last edited by

                        @Dashrender said in Server 2012 Hyper V Cluster:

                        @JaredBusch said in Server 2012 Hyper V Cluster:

                        @scottalanmiller said in Server 2012 Hyper V Cluster:

                        @Obsolesce said in Server 2012 Hyper V Cluster:

                        @scottalanmiller said in Server 2012 Hyper V Cluster:

                        the approach you are looking at is a form of the second, just not using Robocopy specifically. It's almost an identical scenario.

                        It uses Hyper-V VSS

                        I know, but that's only one piece of it. VSS grabs the snap, something transfers it, and that part might actually be Robocopy. VSS isn't the part that does the work we are talking about.

                        The transfer can have zero to do with the Veeam instance. You tell the backup job during creation if it will use the Veeam server or go direct from hypervisor to storage repository.

                        hmmm... this means I have something look at!

                        This setting for on host. Depends on the hypervisor workload if you want to use it or not. Off-host is the default setting.

                        ff967f92-9c8b-4c5b-8fcc-9b76e569804e-image.png

                        If you want to make proxies to do this, you need more Windows server instances.

                        This is the vSphere guide to setting up proxies, but hypervisor doens't matter to the principle https://helpcenter.veeam.com/docs/backup/vsphere/backup_proxy.html?ver=95u4

                        1 Reply Last reply Reply Quote 0
                        • mroth911M
                          mroth911
                          last edited by

                          Is there anyway to set this up without shared storage. Have stripped storage across the clusters. and not need another device,

                          scottalanmillerS 2 Replies Last reply Reply Quote 0
                          • scottalanmillerS
                            scottalanmiller @mroth911
                            last edited by

                            @mroth911 said in Server 2012 Hyper V Cluster:

                            Is there anyway to set this up without shared storage. Have stripped storage across the clusters. and not need another device,

                            Of course, but there is no REASON to do this. You are associating "shared storage" with "external storage" and there is no such association. Under no conditions should you be pursing this idea. Shared storage is the only logical approach here.

                            1 Reply Last reply Reply Quote 1
                            • scottalanmillerS
                              scottalanmiller @mroth911
                              last edited by

                              @mroth911 said in Server 2012 Hyper V Cluster:

                              and not need another device,

                              What does this have to do with shared storage?

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

                                @scottalanmiller based on @mroth911's most recent topic he is looking to setup a Hyperconverged system and appears to be testing Hyper-V and oVirt.

                                But based on the other topic, it doesn't sound as though HC is really required, just Near-HA to protect from any host going offline.

                                scottalanmillerS 1 Reply Last reply Reply Quote 0
                                • scottalanmillerS
                                  scottalanmiller @DustinB3403
                                  last edited by

                                  @DustinB3403 said in Server 2012 Hyper V Cluster:

                                  @scottalanmiller based on @mroth911's most recent topic he is looking to setup a Hyperconverged system and appears to be testing Hyper-V and oVirt.

                                  can't do hyperconverged without shared storage. Shared Storage is the foundation of hyperconvergence.

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