次の方法で共有

Reporting Services と AlwaysOn 可用性グループ (SQL Server)

  • [アーティクル]

このトピックでは、SQL Server 2014 でAlways On可用性グループ (AG) を操作するようにReporting Servicesを構成する方法について説明します。 Reporting ServicesとAlways On可用性グループを使用する 3 つのシナリオは、レポート データ ソース、レポート サーバー データベース、およびレポート設計用のデータベースです。 3 つのシナリオでは、それぞれサポートされる機能と必要な構成が異なります。

Reporting Services データ ソースでAlways On可用性グループを使用する主な利点は、読み取り可能なセカンダリ レプリカをレポート データ ソースとして活用すると同時に、セカンダリ レプリカがプライマリ データベースのフェールオーバーを提供することです。

Always On可用性グループの一般的な情報については、SQL Server 2012 の AlwaysOn FAQ (https://msdn.microsoft.com/sqlserver/gg508768)) を参照してください。

Reporting Services と AlwaysOn 可用性グループを使用するための要件

SQL Server 2014 Reporting ServicesでAlways On可用性グループを使用するには、.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 の AlwaysOn 機能のサポートを導入する修正プログラム」をご覧ください。

その他のAlways On可用性グループの要件については、「AlwaysOn 可用性グループの前提条件、制限事項、および推奨事項 (SQL Server)」を参照してください。

注意

RSreportserver.configなどのReporting Services構成ファイルは、Always On可用性グループ機能の一部としてサポートされていません。 いずれかのレポート サーバーの構成ファイルに手動で変更を加えた場合は、そのレプリカを手動で更新する必要があります。

レポート データ ソースと可用性グループ

Always On可用性グループに基づくReporting Services データ ソースの動作は、管理者が AG 環境をどのように構成したかによって異なる場合があります。

レポート データ ソースAlways On可用性グループを利用するには、可用性グループリスナー DNS 名を使用するようにレポート データ ソース接続文字列を構成する必要があります。 サポートされているデータ ソースは次のとおりです。

  • SQL Native Client を使用した ODBC データ ソース。

  • SQL クライアント (レポート サーバーには .Net の修正プログラムを適用)。

接続文字列には、セカンダリ レプリカを使って読み取り専用レポートを生成するようにレポート クエリ要求を構成する、AlwaysOn の新しい接続プロパティを含めることもできます。 レポート要求にセカンダリ レプリカを使うことによって、読み取り/書き込み可能なプライマリ レプリカへの負荷を軽減することができます。 次の図は、3 つのレプリカから成る AG 構成の例です。Reporting Services データ ソースの接続文字列は ApplicationIntent=ReadOnly で構成されています。 この例のレポート クエリ要求はセカンダリ レプリカに送信され、プライマリ レプリカには送信されません。

SSRS AG グループを使用したデータソース

次に接続文字列の例を示します。[AvailabilityGroupListenerName] は、レプリカの作成時に構成された "リスナーの DNS 名" です。

Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2008R2; ApplicationIntent=ReadOnly

Reporting Services のユーザー インターフェイスにある [接続テスト] ボタンでは、接続が確立可能であるかどうかは検証されますが、AG の構成は検証されません。 たとえば、AG に属していないサーバーへの接続文字列に ApplicationIntent を含めても、このパラメーターは無視されます。 [接続テスト] ボタンによって検証されるのは、指定されたサーバーへの接続が確立可能であるかどうか、という点のみです。

接続文字列の編集方法は、レポートの作成方法とパブリッシュ方法によって異なります。

  • ネイティブ モード: 既にネイティブ モードのレポート サーバーにパブリッシュされたレポートと共有データ ソースには、レポート マネージャーを使用します。

  • SharePoint モード: 既に SharePoint サーバーにパブリッシュされたレポートには、ドキュメント ライブラリ内の SharePoint 構成ページを使用します。

  • レポートデザイン: 新しいレポートを作成するときに、SQL Server 2012 またはSQL Server Data Tools (SSDT) のSQL Server Report Builder。 詳細については、このトピックのレポート デザインに関するセクションを参照してください。

その他のリソース:

考慮事項: 通常、セカンダリ レプリカがプライマリ レプリカからデータの変更を受け取るまでには時間差が生じます。 プライマリ レプリカとセカンダリ レプリカ間に生じる更新の時間差は、次の要因によって変動します。

  • セカンダリ レプリカの数。 セカンダリ レプリカが 1 つ構成に追加されるごとに時間差は大きくなります。

  • プライマリ レプリカとセカンダリ レプリカの地理的な位置と両者の距離。 たとえば、セカンダリ レプリカとプライマリ レプリカが同じ建物内に存在した場合と比べ、異なるデータ センターに存在している方が通常は時間差が大きくなります。

  • 各レプリカの可用性モードの構成。 プライマリ レプリカは、セカンダリ レプリカがディスクにトランザクションを書き込むまで、データベースに対するトランザクションをコミットせずに待機する場合があります。待機するかどうかを決めるのが可用性モードです。 詳細については、「AlwaysOn 可用性グループの概要 (SQL Server)」の「可用性モード」セクションを参照してください。

読み取り専用のセカンダリ レプリカを Reporting Services のデータ ソースとして使用する場合は、データ更新の待機時間をレポート ユーザーのニーズに対応させることが重要です。

レポート デザインと可用性グループ

SQL Server 2012 または SQL Server Data Tools (SSDT) のレポート プロジェクトのSQL Server Report Builderでレポートを設計する場合、ユーザーは、Always On可用性グループによって提供される新しい接続プロパティを含むレポート データ ソース接続文字列を構成できます。 新しい接続プロパティのサポート状況は、ユーザーがどこでレポートをプレビューするかによって異なります。

  • ローカル プレビュー: SQL Server 2012 およびSQL Server Data Tools (SSDT) のSQL Server Report Builderは.Net Framework 4.0 を使用し、可用性グループの接続文字列プロパティAlways Onサポートします。

  • リモート モードまたはサーバー モードのプレビュー:レポート サーバーにレポートを発行した後、または SQL Server 2012 のSQL Server Report Builderでプレビューを使用した後、次のようなエラーが表示される場合は、レポート サーバーと .Net Framework 3.5 SP1 修正プログラムに対してレポートをプレビューしていることを示Always On可用性グループがレポート サーバーにインストールされていません。

エラー メッセージ: "キーワードはサポートされていません:'applicationintent'"

レポート サーバー データベースと可用性グループ

Reporting Servicesでは、レポート サーバー データベースでAlways On可用性グループを使用するための制限付きサポートが提供されます。 レポート サーバー データベースをレプリカの一部として AG 内に構成することはできますが、フェールオーバーが発生しても、Reporting Services では、レポート サーバー データベースに対して別のレプリカが自動的に使用されません。

フェールオーバーと復旧を完了させるには、手動でのアクションまたはカスタム オートメーション スクリプトが必要です。 これらのアクションが完了するまで、Always On可用性グループのフェールオーバー後にレポート サーバーの一部の機能が正しく動作しない可能性があります。

Note

レポート サーバー データベースに対するフェールオーバーとディザスター リカバリーを検討している場合は、レポート サーバーの暗号化キーのコピーを必ずバックアップするようにお勧めします。

SharePoint モードとネイティブ モード間の違い

このセクションでは、SharePoint モードとネイティブ モードのレポート サーバーがAlways On可用性グループとやり取りする方法の違いについて説明します。

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可用性グループの構成と管理(https://go.microsoft.com/fwlink/?LinkId=245165))」を参照してください。

Note

SharePoint モードのレポート サーバーでは、Reporting Services サービス アプリケーション データベースと SharePoint コンテンツ データベースの間の同期処理が使用されます。 レポート サーバー データベースとコンテンツ データベースは一体で管理することが大切です。 1 つのまとまりとしてフェールオーバーと復元を行うことができるよう、同じ可用性グループで構成することを検討してください。 以下のシナリオについて考えてみます。

  • コンテンツ データベースを復元またはフェールオーバーします。差し替わるコンテンツ データベースのコピーには、レポート サーバー データベースに対する直近の変更が反映されていません。
  • Reporting Services の同期処理では、項目のリストについて、コンテンツ データベースとレポート サーバー データベースの間の相違が検出されます。
  • 同期処理では、コンテンツ データベース内の項目が削除または更新されます。

可用性グループに使用するレポート サーバー データベースの準備

レポート サーバー データベースを準備し、Always On可用性グループに追加する基本的な手順を次に示します。

  • 可用性グループを作成し、 リスナーの DNS 名を構成します。

  • プライマリ レプリカ: レポート サーバー データベースが 1 つの可用性グループの一部になるように構成し、すべてのレポート サーバー データベースを含んだプライマリ レプリカを作成します。

  • セカンダリ レプリカ: 1 つまたは複数のセカンダリ レプリカを作成します。 プライマリ レプリカからセカンダリ レプリカへとデータベースをコピーする際は、'RESTORE WITH NORECOVERY' を使って、セカンダリ レプリカごとにデータベースを復元するのが一般的です。 セカンダリ レプリカの作成とデータ同期の動作の確認の詳細については、「AlwaysOn セカンダリ データベースでのデータ移動の開始 (SQL Server)」を参照してください。

  • レポート サーバーの資格情報: プライマリに対して作成したセカンダリ レプリカ上に、レポート サーバーの適切な資格情報を作成する必要があります。 実際の手順は、Reporting Services 環境で使用する認証の種類 (Window Reporting Services サービス アカウント、Windows ユーザー アカウント、または SQL Server 認証) によって異なります。 詳細については、レポート サーバー データベース接続の構成 (SSRS Configuration Manager) に関するページを参照してください

  • リスナーの DNS 名を使用するようにデータベース接続を更新します。 ネイティブ モードのレポート サーバーの場合、Reporting Services 構成マネージャーで [レポート サーバー データベース名] を変更します。 SharePoint モードの場合、Reporting Services サービス アプリケーションの [データベース サーバー名] を変更します。

レポート サーバー データベースのディザスター リカバリーの手順

Always On可用性グループがセカンダリ レプリカにフェールオーバーした後、次の手順を完了する必要があります。

  1. Reporting Services のデータベースをホストするプライマリ データベース エンジンによって使用されていた SQL エージェント サービスのインスタンスを停止します。

  2. 新しいプライマリ レプリカとなるコンピューター上の SQL エージェント サービスを開始します。

  3. レポート サーバー サービスを停止します。

    レポート サーバーがネイティブ モードの場合、Reporting Services 構成マネージャーを使用して、レポート サーバーの Windows サーバーを停止します。

    レポート サーバーが SharePoint モードに構成されている場合、SharePoint サーバーの全体管理で Reporting Services 共有サービスを停止します。

  4. レポート サーバー サービスまたは Reporting Services SharePoint サービスを開始します。

  5. 新しいプライマリ レプリカに対してレポートを実行できることを確認します。

フェールオーバー時のレポート サーバーの動作

レポート サーバー データベースのフェールオーバーが発生した後は、新しいプライマリ レプリカを使用するようにレポート サーバー環境を更新することになりますが、このとき、フェールオーバーと復旧処理に起因する運用上の問題がいくつか生じます。 これらの問題の影響は、フェールオーバー時のReporting Servicesの負荷と、Always On可用性グループがセカンダリ レプリカにフェールオーバーし、レポート サーバー管理者が新しいプライマリ レプリカを使用するようにレポート環境を更新するのにかかる時間によって異なります。

  • バックグラウンド処理が繰り返し実行される場合があります。これは、再試行ロジックが作動しても、フェールオーバー中は、スケジューリングされている作業をレポート サーバーが完了済みとしてマークできないためです。

  • SQL Server エージェントがレポート サーバー データベースにデータを書き込むことができず、そのデータが新しいプライマリ レプリカと同期されないために、通常ならフェールオーバー中にトリガーされるバックグラウンド処理が実行されません。

  • データベースのフェールオーバーが完了し、レポート サーバー サービスが再開されると、その後、SQL Server エージェント ジョブが自動的に再作成されます。 SQL エージェント ジョブが再作成されるまで、SQL Server エージェント ジョブに関連するバックグラウンド処理は一切実行されません。 これには、Reporting Services サブスクリプション、スケジュール、スナップショットが含まれます。

参照

AlwaysOn 可用性グループ (SQL Server) での高可用性、ディザスター リカバリーAlwaysOn 可用性グループ (SQL Server)はじめにのサポートSQL Server Native Client接続文字列キーワードを使用SQL Server Native Client高可用性のSQL Server Native Clientのサポート、可用性レプリカへのクライアント接続アクセスに関するディザスター リカバリー (SQL Server)