次の方法で共有

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

  • [アーティクル]

このトピックでは、SQL Server 2012 の AlwaysOn 可用性グループ (AG) と Reporting Services を組み合わせて利用する方法について説明します。 Reporting Services と AlwaysOn 可用性グループ を使用するデータベースのシナリオとしては、レポート データ ソース、レポート サーバー データベース、レポート デザインの 3 つが考えられます。 3 つのシナリオでは、それぞれサポートされる機能と必要な構成が異なります。

Reporting Services データ ソースで AlwaysOn 可用性グループ を使用する大きな利点は、プライマリ データベースのフェールオーバー機能としての読み取り可能なセカンダリ レプリカをレポート データ ソースとしても利用できることです。

AlwaysOn 可用性グループ に関する一般情報については、「SQL Server 2012 の AlwaysOn に関する FAQ (https://msdn.microsoft.com/en-us/sqlserver/gg508768)」を参照してください。

このトピックの内容

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

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

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

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

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

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

    • レポート サーバー データベースの災害復旧の手順

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

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

SQL Server 2012 Reporting Services で AlwaysOn 可用性グループ を使用するためには、.Net 3.5 SP1 の修正プログラムをダウンロードしてインストールする必要があります。 この修正プログラムを適用すると、AG 機能を使う SQL クライアントが新たにサポートされ、さらに、接続文字列プロパティとして ApplicationIntent および MultiSubnetFailover がサポートされます。 レポート サーバーをホストする各コンピューターにこの修正プログラムがインストールされていない場合、ユーザーがレポートをプレビューしようとすると、以下のようなエラー メッセージが表示され、レポート サーバーのトレース ログに記録されます。

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

このメッセージは、Reporting Services の接続文字列に AlwaysOn 可用性グループ のプロパティが含まれているとき、そのプロパティをサーバー側が認識できなかった場合に生成されます。 レポート サーバー側でリモート エラーが有効にされている場合、Reporting Services のユーザー インターフェイスで [接続テスト] ボタンをクリックしたときや、レポートをプレビューしたときにこのエラー メッセージが表示されます。

必要な修正プログラムの詳細については、「KB 2654347 - .NET Framework 3.5 SP1 に SQL Server 2012 の AlwaysOn 機能のサポートを導入する修正プログラム」を参照してください。

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

  

注意注

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

[トップに戻る] リンクで使用される矢印アイコン先頭に戻る

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

AlwaysOn 可用性グループ を使用した Reporting Services データ ソースの動作は、AG 環境の構成内容によって異なります。

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

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

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

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

AG グループを使用する SSRS データソース

 

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

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

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

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

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

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

  • レポート デザイン: SQL Server 2012 用 SQL Server レポート ビルダーまたは SQL Server データ ツール (SSDT) (新しいレポートを作成する場合)。 詳細については、このトピックの「レポートのデザイン」のセクションを参照してください。

その他のリソース:

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

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

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

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

読み取り専用のセカンダリ レプリカを Reporting Services のデータ ソースとして使用する場合は、データ更新の時間差が、レポート ユーザーの想定を越えることのないように注意してください。

[トップに戻る] リンクで使用される矢印アイコン先頭に戻る

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

SQL Server 2012 用 SQL Server レポート ビルダーまたは SQL Server データ ツール (SSDT) のレポート プロジェクトでレポートをデザインする際、ユーザーは、レポート データ ソースの接続文字列に、AlwaysOn 可用性グループ の新しい接続プロパティを含めることができます。 新しい接続プロパティのサポート状況は、ユーザーがどこでレポートをプレビューするかによって異なります。

  • ローカル プレビュー: SQL Server 2012 用 SQL Server レポート ビルダーと SQL Server データ ツール (SSDT) には、.Net framework 4.0 が使われており、AlwaysOn 可用性グループ の接続文字列プロパティがサポートされます。

  • リモートまたはサーバー モード プレビュー: SQL Server 2012 用 SQL Server レポート ビルダーでレポートをプレビューするか、レポート サーバーに対してレポートをパブリッシュした後、次のようなエラーが表示された場合、プレビュー対象となるレポートのレポート サーバーに .Net Framework 3.5 SP1 Hotfix for AlwaysOn 可用性グループ がインストールされていません。

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

[トップに戻る] リンクで使用される矢印アイコン先頭に戻る

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

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

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

注意注

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

 

[トップに戻る] リンクで使用される矢印アイコン先頭に戻る

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

このセクションでは、AlwaysOn 可用性グループ との連携の観点から、SharePoint モードのレポート サーバーとネイティブ モードのレポート サーバーの違いについて説明します。

SharePoint レポート サーバーでは、作成した Reporting Services サービス アプリケーションごとに 3 つのデータベースが作成されます。 SharePoint モードのレポート サーバー データベースへの接続は、サービス アプリケーションを作成するときに、SharePoint サーバーの全体管理で構成します。 データベースの既定の名前には、サービス アプリケーションに関連付けられた GUID が含まれます。 SharePoint モードのレポート サーバーのデータベース名の例を次に示します。

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

ネイティブ モードのレポート サーバーでは、2 つのデータベースを使用します。 ネイティブ モードのレポート サーバーのデータベース名の例を次に示します。

  • ReportServer

  • ReportServerTempDB

Alerting データベースとそれに関連する機能は、ネイティブ モードではサポートされず、使用されません。 ネイティブ モードのレポート サーバーの構成は、Reporting Services 構成マネージャーで行います。 SharePoint モードの場合、サービス アプリケーション データベースには、SharePoint 構成の過程で作成した "クライアント アクセス ポイント" の名前を使用します。 AlwaysOn 可用性グループ と連動する SharePoint の構成の詳細については、「SharePoint Server の SQL Server 可用性グループの構成と管理 (https://go.microsoft.com/fwlink/?LinkId=245165)」を参照してください。

注意注

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

  • コンテンツ データベースを復元またはフェールオーバーします。差し替わるコンテンツ データベースのコピーには、レポート サーバー データベースに対する直近の変更が反映されていません。

  • Reporting Services の同期処理で、コンテンツ データベースとレポート サーバー データベース内の一連の項目について両者の相違点が検出されます。

  • 同期処理では、コンテンツ データベース内の項目が削除または更新されます。

[トップに戻る] リンクで使用される矢印アイコン先頭に戻る

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

以下に示したのは、レポート サーバー データベースを準備して AlwaysOn 可用性グループ に追加する基本的な手順です。

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

  • プライマリ レプリカ: レポート サーバー データベースを 1 つの可用性グループにまとめ、そのすべてのレポート サーバー データベースを含んだプライマリ レプリカを作成します。 含まれる内容は次のとおりです。

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

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

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

[トップに戻る] リンクで使用される矢印アイコン先頭に戻る

レポート サーバー データベースの災害復旧の手順

次の手順は、セカンダリ レプリカへの AlwaysOn 可用性グループ フェールオーバー後に実施する必要があります。

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

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

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

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

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

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

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

 

[トップに戻る] リンクで使用される矢印アイコン先頭に戻る

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

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

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

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

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

[トップに戻る] リンクで使用される矢印アイコン先頭に戻る

関連項目

概念

SQL Server Native Client の HADR サポート

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

AlwaysOn 可用性グループの概要 (SQL Server)

SQL Server Native Client での接続文字列キーワードの使用

SQL Server Native Client の HADR サポート

可用性レプリカに対するクライアント接続アクセスについて (SQL Server)