Server 2012 Hyper V Cluster
-
@JaredBusch said in Server 2012 Hyper V Cluster:
To build an actual cluster, you need SCCM.
Definitely not a requirement in any way, nor is SCVMM.
A Hyper-V failover cluster can be set up, configured, and managed using FCM.
-
@mroth911 said in Server 2012 Hyper V Cluster:
I am trying to build A hyper V cluster using failover cluster, I do not what shared storage. I want to use the hard rives in the machines and replicate data across. Is this possible. ?
Regards
Yes, but you will need Starwind with VSAN for that to happen.
-
@mroth911 said in Server 2012 Hyper V Cluster:
I am trying to build A hyper V cluster using failover cluster, I do not what shared storage. I want to use the hard rives in the machines and replicate data across. Is this possible. ?
Regards
Possible but doesnt make sense. No advantage over shared storage across the nodes, its the same hardware, its just more overhead and more risk and more effort your way.
Whats making you "want" this?
-
@Obsolesce said in Server 2012 Hyper V Cluster:
@mroth911 said in Server 2012 Hyper V Cluster:
I am trying to build A hyper V cluster using failover cluster, I do not what shared storage. I want to use the hard rives in the machines and replicate data across. Is this possible. ?
Regards
If you don't want the features of a failover cluster, it sounds like plain old Hyper-V Replication will do what you need, without all those extra requirements.
But to answer your question, yeah, you do not have to use shared storage.
Dont have to, but you have to provide all the same storage physically so why skip the benefits?
-
I basically want to use the storage in the servers to replicate to each node. So if one goes off I still have two other servers.
I was thinking about Maxtra software, or using Ovirt.
-
@mroth911 said in Server 2012 Hyper V Cluster:
I basically want to use the storage in the servers to replicate to each node. So if one goes off I still have two other servers.
Right, and the best way to do that is shared storage. RLS.
-
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.
