Server 2012 Hyper V Cluster
-
There are two types of replication... async replication (a la Veeam or Hyper-V built in) which syncs a copy "every so often" whether minutes or hours apart. It is a copy that isn't live or shared.
The other type is sync replication (a la Starwind, DRBD, Gluster) which keeps a copy on both nodes and keeps them fully in sync allowing it to be "shared."
The advantage to async is that it can work well on disparate systems or over a WAN link to a remote site. In the past we used it because common products were free where sync was not, but that has changed.
The advantage to sync is that you can use less overhead, keep data fully protected, failover automatically, etc. Basically if you can sync, you do sync. Async is only useful when sync isn't an option.
-
Two Node Free Replication Comparison
Sync / Shared Async / Unshared Cost Free Free Overhead of Sync Low Sporadic Overhead of Writes Some None Risk of Data Loss None Up to Time Between Syncs Handles Memory Replication Sometimes No Protects In Fight Workloads Sometimes No Allows for Automatic Failover / High Availability Yes No Fully Utilizes Available Gear Yes No -
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:
- 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.
- 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.
-
@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
-
@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.
-
@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.
-
@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!
-
@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.
-
@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.
-
@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).
-
@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.
-
@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.
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
-
Is there anyway to set this up without shared storage. Have stripped storage across the clusters. and not need another device,
-
@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.
-
@mroth911 said in Server 2012 Hyper V Cluster:
and not need another device,
What does this have to do with shared storage?
-
@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.
-
@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.
