Power BIのオンプレミスデータゲートウェイを高可用性クラスターにする

最初に決めるのは「何を止めたくないか」

オンプレミスデータゲートウェイが1台だけで動いていると、そのマシンが停止した間、クラウドサービスからオンプレミスデータへ接続できなくなることがあります。高可用性が必要なら、Microsoftの標準モード（standard mode）gatewayを2台以上、同じgateway clusterへ登録します。個人モード（personal mode）はPower BI専用かつ一人用で、標準モードのような共有cluster構成に使えません。

ただし、gatewayを増やすだけでデータソースまで必ず使えるわけではありません。障害時の切替には、cluster内の別memberがオンラインで、同じconnectionや権限、ネットワーク条件を満たす必要があります。この記事では実環境の設定を確認していません。読む人が構成前に必要条件を洗い出し、追加memberの登録と切替確認へ進める手順をまとめます。

表は横にスクロールできます

条件	1台構成	Standard mode cluster
障害時に別gatewayへ切替	できない	別memberが利用可能なら切替
複数gateway管理	1台	cluster単位で管理
Personal mode	対象外	cluster構成に使わない
主に向く用途	小規模・停止許容	停止リスク低減・負荷分散

Microsoft Learnによると、clusterは最大10 memberをサポートし、cloud serviceは通常primary gatewayを使い、primaryが利用できないとき次の利用可能なmemberへ切り替えます。負荷分散設定を有効にした場合は、cluster内へ要求を分配できます。したがって「いつも均等に分散される」「一台落ちても瞬時に必ず全処理が成功する」とは説明できません。必要な可用性は、実際のrefreshや接続を使って確認します。

1. 現在のgateway modeと管理者を確認する

Power BI ServiceのManage connections and gatewaysで、対象gatewayが個人モードか標準モードか、誰が管理者かを確認します。共有データソースや複数利用者の接続なら、personal modeの前提と合わない可能性があります。個人モードを標準モードclusterへそのまま追加するのではなく、standard modeを使う構成かどうかを決めてください。

次に、gatewayを実行しているWindowsマシン、接続先のデータソース、現在のconnection名、認証方式、必要なネットワーク経路を書き出します。Windows認証を使う環境では、gateway machineと接続先domainの関係など、データソース側の要件も確認します。ここは組織固有の設定なので、一般的な手順だけで認証成功を保証できません。

clusterの追加や設定はgateway administratorが行います。管理者が分からない、recovery keyを保管していない、接続用credentialの責任者が不明なら、そのままインストール作業に入らず担当を決めます。recovery keyは新しいmemberの追加や移行・復旧に使う重要情報です。Microsoftはこのkeyを取得できないと説明しているため、管理組織の安全な保管先とアクセス責任者を先に確認してください。

2. 高可用性化の前提を一覧にする

追加前に、次の表を埋めると「gatewayは登録されたがconnectionが使えない」という状態を見つけやすくなります。

表は横にスクロールできます

確認項目	記録する内容	未確認のまま追加した場合の問題
既存mode	Personal / Standard	Personalをclusterに追加しようとする
Cluster管理者	担当者・連絡先	member追加や障害対応が止まる
Primary member	machine名・状態・version	追加先clusterを誤る
Recovery key	保管場所と利用権限	追加・復旧できない
Data source	接続名・サーバー・DB・認証方式	他memberから接続できない
Network	DNS・port・proxy等の組織要件	Onlineでもsourceへ届かない
Failover要件	許容停止時間・対象処理	テストの合格条件が曖昧
運用担当	alert・更新・offline対応	障害memberが放置される

「同じversionで動かす」ことも運用要件として確認します。Microsoftはcluster membersを同じgateway versionにするよう案内し、version差が予期しない失敗につながる可能性を指摘しています。更新では全台を一度に止めず、組織のメンテナンス手順に沿って順番と状態を記録します。

3. Standard modeのmemberを同じclusterへ追加する

現行のMicrosoft install手順に従い、追加するWindows machineでstandard mode gatewayをインストールし、管理者アカウントでサインインします。新規gatewayとして別のclusterを作る選択ではなく、既存clusterへ追加する操作を選び、対象のprimary gateway clusterとrecovery keyを確認して登録します。

操作前に、選択画面で既存cluster名が想定どおりか、keyの管理者が承認した対象かを確認してください。誤ったclusterへ追加すると、意図しない共有環境へ接続される可能性があります。画面表示や設定権限はtenant・gatewayの状態によって異なるため、手順どおりのボタン名が見えない場合は別clusterを作って進めず、管理者へ構成を確認します。

追加後は、Serviceの管理画面でclusterとmemberの状態、各memberのversionを確認します。個々のgateway instanceではなくclusterとして表示・管理される箇所があります。Microsoftは、clusterに登録されたdata sourceや接続の管理操作がcluster全体に適用されると説明しています。そのため、接続を追加・変更するときは対象clusterに対する操作かを確認してください。

4. 切替と負荷分散は別の確認をする

高可用性clusterでは、primaryが利用できない場合に別の利用可能なmemberが使われる仕組みがあります。負荷分散を使うかどうかは別の設定です。負荷分散を有効にすると、複数のmemberへ要求を分配できます。設定によって選択方法も異なるため、全ての要求が均等に回ることを前提にしないでください。

本番停止を避けるために故障テストをする場合は、影響を受けるrefreshや利用者、停止時間、戻し方をあらかじめ決め、管理者が承認した保守枠で実施します。実験的にprimary機器を電源断するのではなく、Serviceでmemberを無効化するなど、組織の運用手順とMicrosoftの管理機能に沿った方法を選びます。接続管理の読み取りテストだけでは、refreshやlive queryの切替確認にならないことがあります。

表は横にスクロールできます

テスト	合格の確認例
Member状態	想定memberがonlineで、version差がない
Data source	各connectionが正しいclusterへ登録されている
Primary停止時	承認済みテスト処理が別memberで実行される
負荷分散	設定した場合のみ、実要求の分配と失敗を確認
Recovery	戻し方、key保管担当、障害時の連絡先を記録

一台がofflineなのにcluster一覧に残った状態は放置しないようにします。Microsoftはoffline memberを無効化または削除することを推奨しています。無効化されていないoffline memberへqueryが送られると、次のmemberへ進む前に性能へ悪影響を与える可能性があるためです。状態の監視担当と、復旧・無効化・削除の判断基準を運用記録に残します。

5. 導入・切替チェックリスト

• 対象がstandard modeであり、既存clusterとprimaryを特定した。

• Gateway administratorと追加作業の実施者が確定している。

• recovery keyの保管場所、利用権限、保管責任者を確認した。

• 追加memberのOS、gateway version、network要件を確認した。

• 既存clusterへ追加する操作を選び、別clusterを誤作成していない。

• cluster / member状態とversionを確認した。

• 必要なdata source connectionとcredentialが対象clusterに登録されている。

• 管理されたテスト枠で、primaryが使えない場合の接続・refresh動作を確かめた。

• Load balancingを有効にした場合は、意図した分散設定を読み戻した。

• offline memberの通知・無効化・復旧担当を決めた。

• 作業前後の状態、試した処理、失敗・成功時刻、戻し方を記録した。

問題が出たら、gatewayの「online」表示だけで完了としないでください。接続credential、対象data source、Service側のrefresh history、各memberのversion、network reachabilityを照合します。切替に失敗したときは、どのmemberへ要求が渡り、どのconnectionで止まったかを管理ログから確認できる範囲で記録します。原因が権限や組織ネットワークにある場合、本文の一般手順では変更できないため、管理者へ必要情報を渡します。

どの構成を選ぶか

表は横にスクロールできます

状況	判断
一人だけがPower BIで使い、停止を許容できる	Personal modeなど現行構成を維持する選択肢を検討
複数利用者または複数serviceの接続を運用する	Standard modeの利用要件と共有管理を確認
一台の停止が業務refreshを止める	Standard mode clusterを候補にし、2台以上で切替テストを計画
接続要件・recovery key・管理者が不明	追加作業を止め、管理者と前提を確定
高負荷や負荷分散が必要	memberの容量・実測・管理設定を見て個別設計

clusterは単一障害点を減らす手段ですが、データソースやネットワーク、認証、Power BI Service、refresh policy全体の可用性を保証するものではありません。停止許容時間、対象dataset、障害時の担当者を決めた上で、実際の障害テストを通過した構成だけを運用上の高可用性として扱います。

公式情報と確認範囲

Microsoft Learnを2026-10-15に確認しました。install資料はStandard modeとPersonal modeの用途、clusterへの追加、recovery keyの必要性を説明しています。High-availability clusters資料はprimary利用とfallback、member上限、同一version、負荷分散設定、offline memberの取扱いを記載しています。FAQはclusterの最大member数とrecovery keyの使い方を確認する補助情報です。組織固有のgateway、connections、data source、permissions、network、failover動作は未確認です。

・Install an on-premises data gateway：https://learn.microsoft.com/en-us/data-integration/gateway/service-gateway-install（新しいタブで開く）

・Manage on-premises data gateway high-availability clusters and load balancing：https://learn.microsoft.com/en-us/data-integration/gateway/service-gateway-high-availability-clusters（新しいタブで開く）

・On-premises data gateway FAQ：https://learn.microsoft.com/en-us/data-integration/gateway/service-gateway-onprem-faq（新しいタブで開く）