Reporting Services と Always On 可用性グループ (SQL Server)
適用対象: 
SQL Server
この記事では、SQL Server で Reporting Services を構成して、Always On 可用性グループ (AG) と組み合わせて利用する方法について説明します。 Reporting Services と Always On 可用性グループを使用するデータベースのシナリオとしては、レポート データ ソース、レポート サーバー データベース、レポート デザインの 3 つがあります。 3 つのシナリオでは、それぞれサポートされる機能と必要な構成が異なります。
Reporting Services のデータ ソースで Always On 可用性グループを使用する鍵とるなベネフィットは、セカンダリ レプリカにより、プライマリ データベースのフェールオーバーが提供されると同時に、その読み取り可能なセカンダリ レプリカをレポート データ ソースとしても使用できることです。
Always On 可用性グループの一般的な情報については、SQL Server 2012 の Always On に関するよくあるご質問 (../../../sql-server/index.yml) に関するページを参照してください。
Reporting Services と Always On 可用性グループを使用するための要件
SQL Server Reporting Services と Power BI Report Server では、.NET Framework 4.0 が使用され、データ ソースでの Always On 可用性グループの接続文字列プロパティの使用がサポートされます。
Always On 可用性グループを 2014 以前の Reporting Services で使用するには、.NET 3.5 SP1 の修正プログラムをダウンロードしてインストールする必要があります。 この修正プログラムを適用すると、AG 機能を使う SQL クライアントが新たにサポートされ、さらに、接続文字列プロパティとして ApplicationIntent および MultiSubnetFailoverがサポートされます。 レポート サーバーをホストする各コンピューターにこの修正プログラムがインストールされていない場合、ユーザーがレポートをプレビューしようとすると、以下のようなエラー メッセージが表示され、レポート サーバーのトレース ログに記録されます。
エラー メッセージ: "キーワードはサポートされていません:'applicationintent'"
このメッセージは、Reporting Services の接続文字列に Always On 可用性グループのプロパティが含まれているとき、そのプロパティがサーバー側で認識されない場合に生成されます。 レポート サーバーでリモート エラーが有効にされている場合、Reporting Services のユーザー インターフェイスで [接続テスト] ボタンを選択したときや、レポートをプレビューしたときにこのエラー メッセージが表示されます。
必要な修正プログラムの詳細については、「KB 2654347 - .NET Framework 3.5 SP1 に SQL Server 2012 の Always On 機能のサポートを導入する修正プログラム」を参照してください。
Always On 可用性グループのその他の要件については、「Always On 可用性グループの前提条件、制限事項、推奨事項 (SQL Server)」を参照してください。
注意
Always On 可用性グループの機能のサポート範囲には、RSreportserver.config などの Reporting Services の構成ファイルは含まれません。 いずれかのレポート サーバーの構成ファイルに手動で変更を加えた場合は、そのレプリカを手動で更新する必要があります。
レポート データ ソースと可用性グループ
Always On 可用性グループを使用した Reporting Services データ ソースの動作は、管理者による AG 環境の構成内容によって異なります。
レポート データ ソースに Always On 可用性グループを利用するには、可用性グループ "リスナーの DNS 名" を使用するようにレポート データ ソースの接続文字列を構成する必要があります。 サポートされているデータ ソースは次のとおりです。
SQL Native Client を使用した ODBC データ ソース。
SQL クライアント (レポート サーバーには .NET の修正プログラムを適用)。
接続文字列には、セカンダリ レプリカを使って読み取り専用レポートを生成するようにレポート クエリ要求を構成する、Always On の新しい接続プロパティを含めることもできます。 レポート要求にセカンダリ レプリカを使うことによって、読み取り/書き込み可能なプライマリ レプリカへの負荷を軽減することができます。 次の図は、3 つのレプリカから成る AG 構成の例です。Reporting Services データ ソースの接続文字列は ApplicationIntent=ReadOnly で構成されています。 この例では、レポート クエリ要求はセカンダリ レプリカに送信され、プライマリ レプリカには送信されません。
次に接続文字列の例を示します。[AvailabilityGroupListenerName] は、レプリカの作成時に構成された "リスナーの DNS 名" です。
Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2022; ApplicationIntent=ReadOnly
Reporting Services のユーザー インターフェイスにある [接続テスト] ボタンでは、接続が確立可能であるかどうかは検証されますが、AG の構成は検証されません。 たとえば、AG に属していないサーバーへの接続文字列に ApplicationIntent を含めても、このパラメーターは無視されます。 [接続テスト] ボタンによって検証されるのは、指定されたサーバーへの接続が確立可能であるかどうか、という点のみです。
接続文字列の編集方法は、レポートの作成方法とパブリッシュ方法によって異なります。
ネイティブ モード: 共有データ ソースと、既にネイティブ モードのレポート サーバーに発行されたレポートに、Web ポータルを使用します。
SharePoint モード: 既に SharePoint サーバーにパブリッシュされたレポートには、ドキュメント ライブラリ内の SharePoint 構成ページを使用します。
レポート デザイン: 新しいレポートを作成する場合、レポート ビルダーまたは SQL Server Data Tools (SSDT)。 詳細情報については、この記事のレポート デザインに関するセクションを参照してください。
その他のリソース:
使用できる接続文字列プロパティの詳細については、「 Using Connection String Keywords with SQL Server Native Client」をご覧ください。
可用性グループ リスナーの詳細については、可用性グループ リスナーの作成または構成 (SQL Server)に関するページを参照してください。
考慮事項: 通常、セカンダリ レプリカがプライマリ レプリカからデータの変更を受け取るまでには時間差が生じます。 プライマリ レプリカとセカンダリ レプリカ間に生じる更新の時間差は、次の要因によって変動します。
セカンダリ レプリカの数。 セカンダリ レプリカが 1 つ構成に追加されるごとに時間差は大きくなります。
プライマリ レプリカとセカンダリ レプリカの地理的な位置と両者の距離。 たとえば、セカンダリ レプリカとプライマリ レプリカが同じ建物内に存在した場合と比べ、異なるデータ センターに存在している方が通常は時間差が大きくなります。
各レプリカの可用性モードの構成。 プライマリ レプリカは、セカンダリ レプリカがディスクにトランザクションを書き込むまで、データベースに対するトランザクションをコミットせずに待機する場合があります。待機するかどうかを決めるのが可用性モードです。 詳細については、Always On 可用性グループの概要 (SQL Server)のページの「可用性モード」セクションを参照してください。
読み取り専用のセカンダリ レプリカを Reporting Services のデータ ソースとして使用する場合は、データ更新の待機時間をレポート ユーザーのニーズに対応させることが重要です。
レポート デザインと可用性グループ
レポート ビルダーまたは SQL Server Data Tools (SSDT) のレポート プロジェクトでレポートをデザインする際、ユーザーは、Always On 可用性グループの新しい接続プロパティを含めるようにレポート データ ソースの接続文字列を構成できます。 新しい接続プロパティのサポート状況は、ユーザーがどこでレポートをプレビューするかによって異なります。
ローカル プレビュー: レポート ビルダーと SQL Server Data Tools (SSDT) では、.NET framework 4.0 が使用され、Always On 可用性グループの接続文字列プロパティがサポートされます。
リモートまたはサーバー モード プレビュー:レポート サーバーにレポートを発行するか、レポート ビルダーのプレビューを使用した後、次のようなエラーが表示された場合、レポート サーバーに対してレポートをプレビューしており、そのレポート サーバーに Always On 可用性グループの .NET Framework 3.5 SP1 修正プログラムがインストールされていないことを示します。
エラー メッセージ: "キーワードはサポートされていません:'applicationintent'"
レポート サーバー データベースと可用性グループ
Reporting Services と Microsoft Power BI Report Server では、レポート サーバー データベースでの Always On 可用性グループの使用がサポートされますが、これには制限があります。 レポート サーバー データベースをレプリカの一部として AG 内に構成することはできますが、フェールオーバーが発生しても、Reporting Services では、レポート サーバー データベースに対して別のレプリカが自動的に使用されません。 MultiSubnetFailover とレポート サーバー データベースの使用はサポートされていません。
フェールオーバーと復旧を完了させるには、手動でのアクションまたはカスタム オートメーション スクリプトが必要です。 Always On 可用性グループのフェールオーバー後は、これらのアクションが完了するまで、レポート サーバーの一部の機能が正常に動作しない可能性があります。
Note
レポート サーバー データベースに対するフェールオーバーとディザスター リカバリーを検討している場合は、レポート サーバーの暗号化キーのコピーを必ずバックアップするようにお勧めします。
SharePoint モードとネイティブ モード間の違い
このセクションでは、Always On 可用性グループとの連携の観点から、SharePoint モードのレポート サーバーとネイティブ モードのレポート サーバーの違いについて説明します。
SharePoint レポート サーバーでは、作成した Reporting Services サービス アプリケーションごとに 3 つのデータベースが作成されます。 SharePoint モードのレポート サーバー データベースへの接続は、サービス アプリケーションを作成するときに、SharePoint サーバーの全体管理で構成します。 データベースの既定の名前には、サービス アプリケーションに関連付けられた GUID が含まれます。 SharePoint モードのレポート サーバーのデータベース名の例を次に示します。
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting
ネイティブ モードのレポート サーバーでは、 2 つのデータベースを使用します。 ネイティブ モードのレポート サーバーのデータベース名の例を次に示します。
ReportServer
ReportServerTempDB
Alerting データベースとそれに関連する機能は、ネイティブ モードではサポートされず、使用されません。 ネイティブ モードのレポート サーバーの構成は、Reporting Services Configuration Manager で行います。 SharePoint モードの場合、サービス アプリケーション データベースが、SharePoint 構成の過程で作成した "クライアント アクセス ポイント" の名前になるように構成します。 Always On 可用性グループを SharePoint に構成する方法の詳細については、「SharePoint Server 向け SQL Server 可用性グループの構成と管理 (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14))」を参照してください。
Note
SharePoint モードのレポート サーバーでは、Reporting Services サービス アプリケーション データベースと SharePoint コンテンツ データベースの間の同期処理が使用されます。 レポート サーバー データベースとコンテンツ データベースは一体で管理することが大切です。 1 つのまとまりとしてフェールオーバーと復元を行うことができるよう、同じ可用性グループで構成することを検討してください。 以下のシナリオについて考えてみます。
- コンテンツ データベースを復元またはフェールオーバーします。差し替わるコンテンツ データベースのコピーには、レポート サーバー データベースに対する直近の変更が反映されていません。
- Reporting Services の同期処理では、項目のリストについて、コンテンツ データベースとレポート サーバー データベースの間の相違が検出されます。
- 同期処理では、コンテンツ データベース内の項目が削除または更新されます。
可用性グループに使用するレポート サーバー データベースの準備
以下に、レポート サーバー データベースを準備して Always On 可用性グループに追加する基本的な手順を示します。
可用性グループを作成し、 リスナーの DNS 名を構成します。
プライマリ レプリカ: レポート サーバー データベースが 1 つの可用性グループの一部になるように構成し、すべてのレポート サーバー データベースを含んだプライマリ レプリカを作成します。
セカンダリ レプリカ: 1 つまたは複数のセカンダリ レプリカを作成します。 プライマリ レプリカからセカンダリ レプリカへとデータベースをコピーする際は、'RESTORE WITH NORECOVERY' を使って、セカンダリ レプリカごとにデータベースを復元するのが一般的です。 セカンダリ レプリカの作成およびデータの同期動作の検証の詳細については、「Always On セカンダリ データベース上のデータ移動の開始 (SQL Server) (SQL Server)」を参照してください。
レポート サーバーの資格情報: プライマリに対して作成したセカンダリ レプリカ上に、レポート サーバーの適切な資格情報を作成する必要があります。 実際の手順は、Reporting Services 環境で使用する認証の種類 (Window Reporting Services サービス アカウント、Windows ユーザー アカウント、または SQL Server 認証) によって異なります。 詳細については、レポート サーバー データベース接続の構成 (SSRS Configuration Manager) に関するページを参照してください
リスナーの DNS 名を使用するようにデータベース接続を更新します。 ネイティブ モードのレポート サーバーの場合、Reporting Services 構成マネージャーで [レポート サーバー データベース名] を変更します。 SharePoint モードの場合、Reporting Services サービス アプリケーションの [データベース サーバー名] を変更します。
レポート サーバー データベースのディザスター リカバリーの手順
次の手順は、セカンダリ レプリカへの Always On 可用性グループのフェールオーバー後に実施する必要があります。
Reporting Services のデータベースをホストするプライマリ データベース エンジンによって使用されていた SQL エージェント サービスのインスタンスを停止します。
新しいプライマリ レプリカとなるコンピューター上の SQL エージェント サービスを開始します。
レポート サーバー サービスを停止します。
レポート サーバーがネイティブ モードの場合、Reporting Services 構成マネージャーを使用して、レポート サーバーの Windows サーバーを停止します。
レポート サーバーが SharePoint モードに構成されている場合、SharePoint サーバーの全体管理で Reporting Services 共有サービスを停止します。
レポート サーバー サービスまたは Reporting Services SharePoint サービスを開始します。
新しいプライマリ レプリカに対してレポートを実行できることを確認します。
フェールオーバー時のレポート サーバーの動作
レポート サーバー データベースのフェールオーバーが発生した後は、新しいプライマリ レプリカを使用するようにレポート サーバー環境を更新することになりますが、このとき、フェールオーバーと復旧処理に起因する運用上の問題がいくつか生じます。 これらの問題の影響は、フェールオーバー時の Reporting Services の負荷に加え、Always On 可用性グループがセカンダリ レプリカへのフェールオーバーに要した時間、およびレポート サーバー管理者が新しいプライマリ レプリカを使うようにレポート環境を更新するのに要した時間によって異なります。
バックグラウンド処理が繰り返し実行される場合があります。これは、再試行ロジックが作動しても、フェールオーバー中は、スケジューリングされている作業をレポート サーバーが完了済みとしてマークできないためです。
SQL Server エージェントがレポート サーバー データベースにデータを書き込むことができず、そのデータが新しいプライマリ レプリカと同期されないために、通常ならフェールオーバー中にトリガーされるバックグラウンド処理が実行されません。
データベースのフェールオーバーが完了し、レポート サーバー サービスが再起動されると、その後、SQL Server エージェント ジョブが自動的に再作成されます。 SQL エージェント ジョブが再作成されるまで、SQL Server エージェント ジョブに関連するバックグラウンド処理は一切実行されません。 これには、Reporting Services サブスクリプション、スケジュール、スナップショットなどが含まれます。