VM replication vs vSAN on two hosts?
-
@Pete-S said in VM replication vs vSAN on two hosts?:
Two hosts with replication between them are however still two completely independent hosts. I imagine it would be almost impossible to have a failure on one host that would make the other one inoperable.
But maybe that's incorrect and vSAN on one host would still have all the data and work regardless of what happened to the second host?VSAN is still replication. All approaches here are replication. One is just faster and allows for automated recovery, and one does not. You can do VSAN and not have automated recovery, or even nodal awareness to replicate (see what I did there) the autonomy of the Veeam Async approach.
The different is in how quickly replication happens and if you wait for replication to happen before moving on with other tasks or not.
There is an inbetween solution from vendors like DRBD where they do "real time async", so it acts like Veeam in that it does not wait for the second node to ack changes before moving on, but it sends the changes to it in real time like a VSAN so in theory the two nodes are always identical, no "delay" between when one node gets something and when the second one does.
Really, this is all one technology, just different ways to configure it. In the case of DRBD, it's literally one tech with just a knob being tuned.
-
@Pete-S said in VM replication vs vSAN on two hosts?:
HCI is smoother than replication from a usage point but I fear that there can be failure modes that would render both hosts inoperable.
That's theoretically true. But it's also theoretically true with the Veeam approach. It's the automated recovery, not the VSAN, that causes any additional risks. You can use VSAN in generally without that risk.
-
@Pete-S said in VM replication vs vSAN on two hosts?:
But maybe that's incorrect and vSAN on one host would still have all the data and work regardless of what happened to the second host?
From a VSAN perspective, yes, that's the whole idea of the technology (at least in this kind of implementation.) Pooling VMware into a single cluster is where there is more risks.
-
@scottalanmiller said in VM replication vs vSAN on two hosts?:
@Pete-S said in VM replication vs vSAN on two hosts?:
But maybe that's incorrect and vSAN on one host would still have all the data and work regardless of what happened to the second host?
From a VSAN perspective, yes, that's the whole idea of the technology (at least in this kind of implementation.) Pooling VMware into a single cluster is where there is more risks.
OK, so if I understand correctly, vSAN, the real time synchronous replicated storage isn't the problem.
But having VMs failover and automatically recover is what could potentially cause problems?
So it would be an option to use vSAN as shared storage but without having the HA features in play?
And in that case basically end up having the same functionality as Veeam replication but faster? -
@Pete-S said in VM replication vs vSAN on two hosts?:
But having VMs failover and automatically recover is what could potentially cause problems?
Correct. Just replicating, whether async or sync, carries extremely little risk. But this stuff, automating VM management, is when things can go haywire.
-
@Pete-S said in VM replication vs vSAN on two hosts?:
So it would be an option to use vSAN as shared storage but without having the HA features in play?
And in that case basically end up having the same functionality as Veeam replication but faster?DOn't know if VMware VSAN gives you that option. VSAN in general does. This moves from a conceptual question to an implementation question. @NetworkNerd is the right person for that question.
-
@Pete-S said in VM replication vs vSAN on two hosts?:
So it would be an option to use vSAN as shared storage but without having the HA features in play?
This is a stupid idea. If you have vSphere HA available, enable it. It doesn't cause problems.
-
@scottalanmiller said in VM replication vs vSAN on two hosts?:
DOn't know if VMware VSAN gives you that option
It does, but you will get a health alarm, as there isn't a real reason to disable it....
-
@scottalanmiller said in VM replication vs vSAN on two hosts?:
Correct. Just replicating, whether async or sync, carries extremely little risk. But this stuff, automating VM management, is when things can go haywire.
Automatic HA with ASYNCHRONOUS replication is a terrible idea at a block or VM level. This is why Veeam doesn't support it (You would have to build your own scripts, and Gostev would likely say "this is a stupid idea"), as you are potentially automating dataloss.
Note Veeam Replication (TODAY) uses VADP. This requires snapshots and carries performance overhead. Alternatively, in the future they will support VAIO replication (which gets you down from a 15 minute RPO to a 15 second PRO). VAIO bassed replication is a resource heavy (as is any async near-realtime write split journal system).
-
@DustinB3403 said in VM replication vs vSAN on two hosts?:
@scottalanmiller said in VM replication vs vSAN on two hosts?:
@DustinB3403 said in VM replication vs vSAN on two hosts?:
Replication may occur as often as every minute, but you could still lose files or changes within that time span that were never copied to the target.
I think Veeam limits to every 15 minutes?
I don't know as we don't use Veeam replication. I know other solutions can go as often as every minute. But that is outside of this scope.
Some every 30 seconds.
-
@Obsolesce said in VM replication vs vSAN on two hosts?:
@DustinB3403 said in VM replication vs vSAN on two hosts?:
@scottalanmiller said in VM replication vs vSAN on two hosts?:
@DustinB3403 said in VM replication vs vSAN on two hosts?:
Replication may occur as often as every minute, but you could still lose files or changes within that time span that were never copied to the target.
I think Veeam limits to every 15 minutes?
I don't know as we don't use Veeam replication. I know other solutions can go as often as every minute. But that is outside of this scope.
Some every 30 seconds.
DRBD does it in milliseconds, as fast as the platform can do it.
