In this quickstart, you'll learn the benefits of Azure Arc-enabled Kubernetes and how to connect an existing Kubernetes cluster to Azure Arc. For a conceptual look at connecting clusters to Azure Arc, see the Azure

Space bar clicker is the modified version of the spacebar counter in the space bar clicker we can use even our mouse to make the hit on the spacebar. You’ll enjoy much more fun by playing with the spacebar clicker counter

@DustinB3403
I don't doubt it.
There wasn't really any added complexity though. PVE was installed with all the defaults.

It definitely seems joined. I cannot even do anything form the IP of the second instance now.
c0a3fa85-5326-4648-a318-08221c193f5a-image.png

But it is all enabled from the primary.
e0e8003c-9e55-44b2-9914-93dd29ab656f-image.png

Generally, for most use cases, just having two servers and good backups is the best option. If you have a greenzone, turn your VMs off, do your updates, turn them back on.

Updates essentially never cause issues. Not on hypervisors (at least not on KVM/Xen.) Putting in a lot of complexity, cost, or risk to mitigate a shark attack isn't worth it. You will focus on a false risk.

All of the hypervisors are built for this. It's the storage and clustering that may or may not be built for this. As a rule, highest performance systems are not clustered at all, the can't be. Clustering takes a performance hit.

But in the extreme performance space products like VMware and Starwind are the top dogs. Both have multiple solutions, but they are using tech like memory sharing, localized data, NVMEoF, log structuring, and others to do things that Gluster just can't do. So much so that products like Gluster sometimes use these techs on top to accelerate them (example: Starwind makes a CEPH accelerator platform.)

@Vlinderbeest said in Infrastructure Needed for Hypervisor Cluster:

@scottalanmiller said in Infrastructure Needed for Hypervisor Cluster:

Clustering is done when the cost of clustering is low versus the risk of not clustering.

I would change that slightly to Clustering is done when the cost of clustering is low versus the cost of not clustering. A risk is always a cost, but some costs are not risks. For example taking down a hypervisor for maintenance vs moving guests to another node and taking down a free node for maintenance.

Sure, using risk cost vs investment cost as cost v cost is a perfect valid way to look at it. I use that all the time in the opposite way.

You can say that risk is a cost. Or conversely, you can look at the clustering cost up front as essentially a "financial event" similar to an outage.