Home / Data Platform / Fabric & Power BI

Data PlatformHow-toIntermediate

High availability for the on-premises data gateway: clusters, load balancing and updates

Build a gateway cluster for Power BI and Fabric so refreshes and DirectQuery survive a gateway machine failure, with load balancing, consistent drivers, recovery keys and a safe update routine.

Deepak Bhardwaj2 min read

Applies toOn-premises data gateway (standard mode) for Power BI, Fabric, Power Platform

Why a cluster

A single gateway machine is a single point of failure for every refresh and DirectQuery report that uses it. A gateway cluster has multiple members; if the primary is unavailable, requests go to another member.

1. Add a member

Install the gateway on a second server → Register a new gateway → Add to an existing gateway cluster → select the cluster and enter the recovery key of the first gateway.

Important

Store the recovery key in your password vault. Without it you can't add members, restore or migrate the gateway; you'd have to create a new gateway and remap every data source.

2. Load balancing

In the Power Platform admin center or Power BI Manage connections and gateways, enable Distribute requests across all active gateways in this cluster. Optionally set CPU/memory throttling so busy members get fewer requests.

3. Keep members identical

  • Same gateway version.
  • Same ODBC/OLE DB drivers, Oracle client, SAP connectors, and the same versions.
  • Same network access (firewall rules to all sources) and same proxy settings.
  • Same service account where Windows authentication or Kerberos SSO is used.

A query that works on member 1 and fails on member 2 produces "random" refresh failures that are painful to diagnose.

4. Placement

Different hosts, ideally different racks or data centres near the data sources. In Azure, VMs in different availability zones.

5. Updates

Microsoft releases gateway updates monthly and supports recent versions only:

  1. Update one member, check it's online and test a refresh.
  2. Update the remaining members.
  3. Keep members on the same version.

6. Monitoring

  • Gateway performance monitoring logs (query execution, system counters) to a file share, or Power BI gateway monitoring reports.
  • Alerts: member offline (Power BI admin notifications, or a scheduled check via the Power BI REST API GET /gateways / datasources/status), refresh failures.

7. DR

  • The cluster definition and data sources live in the Power BI service; members can be anywhere with network reach.
  • For a site failure, keep at least one cluster member in a second site (or a cold standby VM with the gateway installed but not registered, plus the recovery key).

Tip

Use the gateway logs' Additional logging only when troubleshooting; leave it on and the log volume grows quickly.

Related fixes