Karl Erik Filip Modén
ongoing

Enterprise Storage for an Apartment: Home Assistant on Two-Node vSAN ESA

I run IKEA lights through Home Assistant on a two-node vSAN ESA cluster, with a witness in my main lab, redundant 10GbE point-to-point links, and a frankly unreasonable amount of availability for an apartment.

  • ESXi 8
  • vSAN ESA
  • Home Assistant
  • vSAN Witness
  • 10GbE
  • Supermicro E200-12A-4C

The brief, which got out of hand

The original problem was simple: run Home Assistant reliably enough that the IKEA lights still work when I am too tired to troubleshoot a small computer hiding in a cupboard.

The eventual answer was two Supermicro SuperServer E200-12A-4C hosts, vSAN Express Storage Architecture (ESA), two redundant point-to-point 10GbE links between them, and a vSAN Witness Appliance hosted in my main lab. It is a very elaborate way to turn the kitchen lights on. That is also why it is a useful homelab: the workload is tiny, but the design makes real availability, quorum, networking, and storage-policy behaviour visible without pretending it is a production platform.

The Home Assistant VM runs the lights, automations, dashboards, and integrations. The cluster runs the lesson plan.

The design

Each Supermicro node has one NVMe SSD assigned to vSAN ESA. The hosts are connected directly to each other with two 10GbE links, so the data path does not depend on a switch and a failed cable or port does not immediately partition the storage network. Management traffic uses the regular LAN; vSAN traffic uses the dedicated point-to-point links. The witness lives in the main lab, separate from the two apartment data nodes, so it can cast the deciding vote if one of them disappears.

                  Home network
                        |
              management / Home Assistant
                        |
        +---------------+---------------+
        |                               |
  +-----+------+   2x redundant 10GbE  +------+-----+
  | E200 node A |======================| E200 node B |
  |  NVMe / ESA |                      |  NVMe / ESA |
  +-----+------+                       +------+-----+
        \                                      /
         \        main lab network path       /
          +------------- LAN -----------------+
                         |
                 +-------+--------+
                 | vSAN Witness   |
                 | Main lab       |
                 +----------------+

With a typical Failures To Tolerate = 1 policy, the Home Assistant VM’s data has one data component on each Supermicro node. The witness contributes quorum metadata rather than a third copy of the VM’s data. Lose either data node and the surviving node plus witness can retain quorum; vSphere HA has somewhere to restart the VM. This is the useful part of the design, even if the protected workload mostly controls lamps.

Why ESA for such a small workload?

Because this lab is not trying to be sensible. ESA makes the storage model easy to inspect: the NVMe devices are the storage tier, policies describe the protection goal, and vSAN places the objects across the two hosts. Home Assistant itself barely notices the difference; its database and configuration files are very small. I notice it when a host is restarted and the cluster behaves like a cluster instead of a single fragile appliance.

The upside is wonderfully boring day-to-day behaviour:

  • A host reboot does not automatically mean a dark apartment.
  • The two data nodes have a clean, dedicated replication path.
  • A node failure is a real quorum and HA exercise, not a simulated one.
  • The same vSAN health, policy compliance, and object-placement ideas used at work are right there behind a Home Assistant VM.

The cost is capacity. A mirrored FTT=1 VM consumes space on both data nodes, so two single NVMe drives do not turn into the sum of their capacities for protected workloads. In practice, the cluster behaves much closer to the capacity of one drive, with room still needed for vSAN overhead and normal operational headroom. For Home Assistant this is wildly ample; for a growing VM estate it becomes the first hard limit.

The limits are part of the project

This is a deliberately opinionated homelab, not a hardware recommendation.

One NVMe SSD per node keeps the design compact, not resilient inside a host. If the SSD in one E200 fails, that host has lost its vSAN capacity device. The other host’s replica can keep the Home Assistant data available with the witness online, but there is no local spare drive and no room for a clever rebuild. Replacement and resync are the recovery plan.

The two 10GbE links remove a switch, but not the need for network discipline. A failed cable or port has a second path to fall back to, but an MTU mismatch, incorrect teaming, or a mistake shared by both paths can still isolate the nodes. The most important check in this setup is not a benchmark; it is proving that each host can reach the other data node and the witness over the intended VMkernel path, including after one link is disconnected.

The witness is in the main lab, not a remote site. vSAN two-node configurations use a witness appliance, and the appliance needs to match the cluster architecture and be kept compatible with the data nodes. This placement is more predictable than a free cloud service, but it is not protection from a whole-home power or network outage. It is a quorum design for the two data nodes, not a substitute for a second physical location.

What failure actually looks like

The interesting scenario is losing one E200 host while the main-lab witness remains reachable:

Before failure:       Node A data + Node B data + Witness vote

Node A offline:       Node B data + Witness vote = quorum retained
                       Home Assistant can run on Node B

Witness also offline: Node B has the data, but the cluster has lost its tie-breaker.
                       Treat this as degraded, not as high availability.

This is why the witness is more than a box to make the wizard happy. It changes the decision the cluster can safely make during a partition. The data stays in the apartment; the witness helps the cluster agree on which side is allowed to keep serving it.

What I have learned from using it

  1. Small workloads make excellent availability labs. Home Assistant has very little tolerance for being forgotten, but its resource footprint is small enough that a failed host is a lesson rather than a crisis.
  2. The network deserves the same respect as the disks. The redundant local 10GbE links feel almost boring, which is exactly the compliment storage networking should earn.
  3. Overkill is occasionally useful. The lights do not need ESA. I do need a reason to understand why a two-node design survives one kind of failure and becomes cautious around another.

Reference notes

  • Broadcom documents that two-node and stretched configurations require a witness appliance, and that the ESA or OSA appliance must match the cluster architecture: Deploying a vSAN 8.0 Witness Appliance.
  • A dedicated direct connection between the two data hosts is supported for the vSAN traffic in a two-node deployment: Two-Node vSAN Direct Connect.