This message was deleted.

Two servers is not enough. You will only have HA with 3. When you install the 3rd server, Harvester will install all cluster administration containers and etcds automatically, before that, you will have a fragile hambient.

Thanks for confirming that @busy-photographer-15014. What would be the implications of adding a 3rd node with significantly less cpu, ram, and storage capacity/IOPS than the first 2 servers? Adding a comparable 3rd server would be very expensive for me, especially considering im using a direct SFP+ 25G link between the first 2 and do not have $ for 25G switch fabric. So in the near term to get HA I would be hacking together something with the minimum required cpu/ram/storage but it will be a lot slower than the first 2 servers, and my understanding is that Longhorn's replication and other operations will suffer greatly from this.

The documentation recommended 3rd servers :/

Point taken, @busy-photographer-15014. As [the docs say here](https://docs.harvesterhci.io/v1.0/host), the 3 node requirement is an etcd requirement, not a harvester or longhorn one. So, im pivoting my design to a 3 node ring topology, to prevent the need to buy a 25G switch. Each of the 3 servers' 2-port 25G NICs will be interconnected via DAC cables. The next question is about setting up networking on bare metal Harvester cluster nodes. Since these nodes will not be connected to a switch nor using DHCP, this design requires either static ip and routing rules, or some dynamic routing configuration such as [OSPF](https://en.m.wikipedia.org/wiki/Open_Shortest_Path_First), provided to each host via the [FRR package](https://docs.frrouting.org/en/latest/overview.html#). The [harvester networking deep dive](https://docs.harvesterhci.io/v1.1/networking/deep-dive) implies that only switched configurations are supported, using vlan tagging to separate MGMT from OOB traffic. So, essentially I'd like guidance on satisfying Harvester's network requirements in a 3 node cluster that talks amongst themselves via DAC SFP+ cables instead of a switch. This would be manually implemented at the host level with either static ips and routing. or dynamic routing using OSPF, similar to how this guy does same for a 3 node Proxmox cluster: I'll take any feedback here, but as this convo is diverging from the OP, perhaps Ill create a new post..

So, there are several ways of cluster network management. My cluster has 3 nodes, in different datacenters (they have LAN-TO-LAN) and they are configured with fixed IPs. At some point, using DHCP can also be an interesting approach, this is a strategy, and strategy is very personal. As for the requirements, I think you're on the right track!

The ring topology of a Harvester cluster deployment might theoretically work, but I wouldn’t recommend that. You need to configure them manually because we don’t support this type of deployment out of the box. And all three nodes have to be in the same network, so I don’t think tinkering with the routing table would work here. Also, you still need to reach the cluster from outside of it. That implies one of the nodes must have an uplink. This is a SPOF design. If the node with the uplink fails, the entire cluster goes off. 3-node HA seems meaningless under such circumstances. But as an experimental purpose, I think this is interesting and worth exploring 🙂

Thanks all. I ended up buying a 3rd identical server and a 25Gb switch. As fate would have it, I've decided that ceph compatibility is a deal-breaker and will be basing my homelab on bare-metal rke2 with kubevirt and ceph - basically same as Harvester, but with ceph and sans rancher integration/GUI.