The storage system is a shared point of failure. Proxmox VE HA protects tenant VMs from a host failure, but not from a failure of the storage system that hosts their disks. One storage outage affects every tenant on that system.

No way to sell higher availability. Without synchronous replication and automatic storage failover, a provider can't offer a premium availability tier with zero data loss and stronger uptime commitments.

Tenant isolation during recovery. Recovery, maintenance, and disaster recovery tests must affect only the tenants involved, not the whole platform.

The QDevice still needs a third location. ONTAP Cloud Mediator removes the mediator host, not the corosync QDevice host. The QDevice needs a small Linux host that all Proxmox VE nodes can reach on TCP port 5403, and it doesn't have the low-latency requirement of corosync.

Both clusters need access to the NetApp Console. If the clusters use a proxy, install the proxy's root CA certificate on both clusters. NetApp recommends a different proxy server for each cluster.

Plan for the same failure behavior with either option. When the mediator is unavailable, replication continues without data loss, but automatic and planned failovers aren't possible until the mediator is available again. With ONTAP Cloud Mediator, this includes a loss of connectivity from the clusters to the NetApp Console.

VM availability beyond host HA. Tenant VMs keep running when the storage system that hosts their disks fails. ONTAP fails over to the second AFF cluster, and the VMs resume I/O on the same shared storage without a restart.

A premium availability tier. You can offer a zero RPO, storage-resilient VM service as an add-on, alongside standard tiers on unprotected storage in the same clusters.

Per-tenant protection and failover. With separate protected storage for each tenant or service tier, you protect, fail over, and test disaster recovery for each tenant independently, without affecting other tenants.

Better use of both sites. You can make some workloads primary at site A and others primary at site B, so both data centers serve active workloads.

Zero data loss for business-critical VMs during a storage or site failure.

Automated recovery without scripts, storage remounts, or changes to /etc/pve/storage.cfg.

Built into ONTAP, with no extra software layer on the Proxmox VE nodes.

Day-to-day operations from one interface. Storage Manager for Proxmox provisions the protected shared storage and backs up, restores, and clones VMs with ONTAP snapshots and FlexClone technology.

Choose MetroCluster when all, or nearly all, workloads on the storage need zero RPO, for example when an enterprise runs only mission-critical VMs on the cluster, or a service provider offers the same availability tier to every tenant. You get one protection domain without per-workload configuration.

Choose SnapMirror active sync when only a subset of workloads needs zero RPO, for example a premium tier for some tenants, or when you need to fail over or test disaster recovery for one tenant or application at a time.

SnapMirror active sync for NAS isn't supported on a MetroCluster configuration. Use one solution for each pair of clusters.

The corosync, QDevice, and HA guidance in this solution applies to both. With MetroCluster, align the QDevice tie breaker with the site that keeps serving data when the inter-site link fails, and use HA node affinity rules to keep VMs at the same site as their active SVM.

MetroCluster IP also supports VIP LIFs with BGP for layer 3 networks between sites.

SnapMirror active sync requires an inter-cluster round-trip time (RTT) under 10 ms. Proxmox recommends a corosync latency under 5 ms between all nodes, so the corosync requirement sets the distance limit for the solution.

Corosync needs low, consistent latency rather than high bandwidth. Use a dedicated network for corosync, separate from storage and live migration traffic, so that storage bursts don't cause corosync timeouts.

Configure at least two corosync links (for example, link 0 and link 1) on separate physical paths between the sites. Corosync uses Kronosnet to switch links automatically if one path fails.

Proxmox VE HA typically detects a failed node and recovers its VMs in about two minutes, including a 60-second watchdog fencing timeout. During a site failure, the SnapMirror active sync failover and the Proxmox VE HA recovery run in parallel.

Use HA node affinity rules with node priorities to place VMs on the nodes at the same site as their primary storage, and to let them fail over to the other site.

After a site failover, set the HA failback property to 0 for affected VMs until you fail the storage back. Otherwise, HA migrates VMs back to site A nodes as soon as they return, while the active storage is still at site B.

Make sure the guest operating system disk timeouts are longer than the expected failover time, so that guests don't report I/O errors during a storage failover.

Use resource groups and backup policies to apply the same schedule and retention to the VMs of a tenant or an application.

Use file-consistent backups for VMs that run the QEMU guest agent, so the guest file systems are quiesced before ONTAP creates the snapshot.

SMP manages the storage that is active. After a SnapMirror active sync failover, run a discovery in SMP so that it maps the storage to cluster B before you run backup or restore operations.

For a third copy outside the two sites, or for longer retention, add a SnapMirror asynchronous fan-out relationship from the protected volumes, or use Proxmox Backup Server.

Tamperproof snapshots aren't supported with SnapMirror active sync, so don't enable snapshot locking in SMP for protected volumes.

Run the SMP VM as an HA resource on a SnapMirror active sync protected shared storage, so that SMP stays available after a storage or site failure.

Register the Proxmox VE cluster and both ONTAP clusters in SMP, so that SMP can reach the active storage at either site.

SnapMirror active sync for NAS protects an entire storage VM (SVM). You can protect all volumes in the SVM or exclude selected volumes. Only FlexVol volumes are supported, and the SVM can't contain LUNs.

The secondary SVM stays dormant, with its LIFs down, until a failover. ONTAP replicates the SVM configuration, including LIF IP addresses, export policies, and NFS settings, so the secondary SVM presents the same NFS endpoint after a failover.

Failover is non-disruptive for NFSv3 and later.

SnapMirror active sync for NAS is active/passive, so VMs on site B nodes read and write across the inter-site network to the primary SVM. For active workloads at both sites, use two SVMs with opposite replication directions, one primary at each site, and align each VM's node affinity rule with the site of its primary SVM.

SnapMirror active sync for NAS is supported on AFF A-Series and C-Series two-node clusters.

nConnect. Opens multiple TCP connections to a single NFS LIF address, for example nconnect=4. nConnect works with NFSv3 and NFSv4.1 and with a single VIP LIF address, so it's the recommended option for SnapMirror active sync for NAS, including layer 3 networks.

Session trunking. Groups multiple data LIFs into one NFSv4.1 session, for example vers=4.1,trunkdiscovery,max_connect=16. Session trunking requires NFSv4.1 or later. Use it only when the protected SVM has multiple data LIFs that clients can reach at both sites, such as in a stretched layer 2 network. For details, see NFS trunking.

Provision the volume in the primary SVM, and select the NFS LIF, or the VIP LIF in a layer 3 network, as the preferred LIF. The secondary SVM uses the same address after a failover, so the storage definition stays valid.

Mount the storage on all Proxmox VE nodes at both sites so that HA can restart VMs on any node.

Make sure the export policy allows the Proxmox VE nodes at both sites. ONTAP replicates the export policy to the secondary SVM.

After provisioning, verify that the volume is included in SnapMirror active sync protection.

BGP LIFs don't fail over. Redundancy comes from two BGP LIFs per node, each peering with a different router. If a node loses all its BGP sessions for an SVM, ONTAP moves the VIP LIF to another node that has an active BGP session for that SVM.

Use external BGP (eBGP) with a unique private autonomous system number (ASN) for each ONTAP node and each router.

Use a /31 subnet (netmask 255.255.255.254) for each BGP LIF and its router. Assign the odd-numbered address to the BGP LIF and the even-numbered address to the router.

ONTAP doesn't process routes from the routers. Configure the routers to accept /32 host routes from ONTAP and not to send route updates to the cluster.

Proxmox VE nodes must not share a subnet with the VIP address. A redundant layer 3 router, for example with VRRP or HSRP, must be in the path between the nodes and the storage.

Configure BGP peer groups with -use-peer-as-next-hop true so that each cluster learns its default route from its local routers. Routes that point to a site A gateway aren't valid at site B after a failover.

Enable multipath routing so that outgoing VIP traffic uses all available BGP LIF ports.

Lower the BGP hold time from the default of 180 seconds. TR-4949 recommends a hold time of 3 seconds. A router withdraws the route from a failed cluster only when the hold timer expires, and during a storage system failure the router at site A stays online.