Clustering the hosts and clustering the guests provide similar benefits. If one physical machine fails, another will provide a platform for getting your workload running again.
The main differences come in how the clusters are managed, and in what, exactly, happens at the moment of failover.
- You can configure groups of hosts that can run any VM.
- Host failure results in the VM rebooting, hosted on a different physical machine.
- Shared storage is required
- The management of the cluster is at the host layer, and quite homogenous. All workloads are given high-availability properties.
- Intra-cluster communication happens very reliably. It can't be interrupted because a VM didn't get CPU time or access to I/O.
- Live migration depends on host clustering, so you probably are already on a path to enabling it.
- Each individual VM needs to be configured as part of a cluster.
- Each cluster is specific to the type of workload. If the workload doesn't support clustering, you can't cluster at this level.
- Shared storage is probably required, but might not be.
- Intra-cluster communication is harder to guarantee, so failovers sometimes happen unnecessarily, particularly during live migration. This might or might not matter to you.
- Failover, when it happens, might be somewhat faster, as the OS doesn't have to boot. For databases, though, this usually isn't the large part of the failover time.
I used to think that you should always cluster at the guest level, if you could. Then people walked me through the management effort involved in that and showed me that it often makes a lot of sense to cluster at the host level.