配置トポロジの計画
SQL Server 2008 Reporting Services (SSRS) のサーバー コンポーネントを配置するには、複数の方法があります。このトピックの以下のセクションでは、Reporting Services のネイティブ モードと SharePoint 統合モードの両方の配置トポロジについて概要を紹介します。
.gif "注意") 注意 |
|---|
このトピックに記載されている図には、Windows SharePoint Services (WSS) 3.0 や Microsoft Office SharePoint Server (MOSS) 2007 を使った配置構成は含まれていません。ただし、WSS または MOSS をレポート サーバーと同じコンピュータで構成するか、WSS または MOSS を別々のアプリケーション層で構成することにより、このドキュメントに記載されているものと同じ配置トポロジを使用できます。SharePoint 統合に向けた計画の詳細、および、SharePoint 配置トポロジに関連した考慮事項については、このトピックの「SharePoint 統合の計画」を参照してください。 |
配置トポロジを検討する際の重要な考慮事項として、ハードウェアとソフトウェアの要件があります。これらの要件は、サーバー上で実行されるコンポーネントに影響を及ぼします。このトピックで配置トポロジを確認すると共に、「SQL Server 2008 のインストールに必要なハードウェアおよびソフトウェア」および「レポート サーバー データベースの必要条件の評価」で、Reporting Services を実行するための要件を確認してください。
次の図に示した各レポート サーバー データベースは、Reporting Services がメタデータおよびオブジェクト定義を保存するときに使用する reportserver データベースと reportservertempdb データベースを表しています。レポート データの取得元となるデータベースまたはデータ ソースは、同じコンピュータ (つまり、レポート サーバー データベースをホストするコンピュータ) に存在する場合もあれば、それ以外のコンピュータに存在する場合もあります。詳細については、「レポート サーバー データベース」および「Reporting Services でサポートされるデータ ソース」を参照してください。
シングル サーバー配置
シングル サーバー配置構成では、レポート サーバー インスタンスが、レポート サーバー データベースをホストするデータベース エンジンと同じコンピュータで実行されます。次の図は、シングル サーバー配置構成の例を示しています。
.gif "シングル サーバー配置構成")
次の条件に該当する場合は、シングル サーバー配置構成をお勧めします。
小中規模のレポート ボリュームで、レポート処理の要求が 1 日をとおして均等に発生し、同時セッション数もコンピュータの処理能力の範囲内にある場合。
開発者が SSRS と連携するカスタム ソリューションを開発するとき。
ソフトウェアを評価するとき。
この配置構成は、インストールおよび保守が最も簡単です。既定のインストール オプションを選択した場合は、この配置トポロジが選択されます。この配置構成が組織のニーズに合致するとわかったら、この配置構成を継続して使用してください。レポートの要求が増加した場合は、後でハードウェアをアップグレードするかサーバー インスタンスを追加できます。
標準的なサーバー配置
標準的なサーバー配置では、レポート サーバー インスタンスが、レポート サーバー データベースをホストする SQL Server データベース エンジンのインスタンスとは異なるコンピュータで実行されます。次の図は、標準的な配置構成の例を示しています。
.gif "標準的なサーバー配置構成")
次の条件に該当する場合は、標準的な配置構成をお勧めします。
- レポート ボリュームが中程度であり、レポート処理の要求が 1 日をとおして均等に発生し、同時セッション数もコンピュータの処理能力の範囲内にある場合。
レポート サーバーとデータベース エンジンとが同じコンピュータでホストされるシングル サーバー配置では、両者が CPU 時間、メモリ、ディスク アクセスなどの処理リソースを奪い合うことになります。その点で、標準的な配置構成では、シングル サーバー配置よりも高いパフォーマンスを期待できます。レポート サーバーの処理内容によってはリソースが著しく消費されるため、レポート サーバーを別のコンピュータで実行すると、処理リソースに対する競合を軽減できます。また、最初はレポート サーバー データベースのサイズが小さくても、実行時には、必要なディスク領域や I/O サブシステムの使用率が大幅に増加する場合があります。
シングル サーバー配置と標準的なサーバー配置のどちらを選択するかは、ハードウェアの構成に応じて、次の点を考慮しながら判断するようにしてください。
リソースの処理
メモリ リソース
使用できるディスク領域
I/O 容量
この配置構成が組織のニーズに合致するとわかったら、この配置構成を継続して使用してください。レポートの要求が増加した場合は、後でハードウェアをアップグレードするかサーバー インスタンスを追加できます。
標準的なスケールアウト サーバー配置
標準的なスケールアウト サーバー配置は、1 つのレポート サーバー データベースを共有する複数のレポート サーバーで構成されます。レポート サーバー データベースは、リモートの SQL Server インスタンス上にインストールする必要があります。次の図は、レポート サーバー データベースがリモートの SQL Server インスタンスにインストールされた、標準的なスケールアウト サーバー配置の例を示しています。
.gif "標準的なスケールアウト配置構成")
Reporting Services をスケールアウト配置で構成することにより、可用性の高いスケーラブルなレポート サーバー環境を実現することができます。スケールアウト配置では、環境内の各レポート サーバーを "ノード" と呼びます。他のレポート サーバーと同じレポート サーバー データベースを使用するようにレポート サーバーが構成されると、各ノードがスケールアウトに参加している状態になります。レポート サーバー ノード間では、大量の対話型レポートをサポートするために負荷分散を行うことができます。
次の条件に該当する場合は、スケールアウト サーバー配置構成をお勧めします。
同時ユーザー数が多い、あるいは、レポートが複雑で処理または表示に時間がかかるなど、レポート処理による高負荷に対応する必要がある場合。
予定外のダウンタイムや機能不全が許されない重要なレポート環境など、高可用性が求められる場合。
スケジュールされた操作とサブスクリプションの配信のパフォーマンスを向上させる必要がある場合。
SQL Server の一部のエディションでは、スケールアウト配置がサポートされません。環境内のすべてのレポート サーバー ノードは、同じバージョン、同じサービス パック レベルの SQL Server で統一する必要があります。SQL Server 2008 のエディションの詳細については、「SQL Server 2008 のエディションとコンポーネント」および「SQL Server 2008 の各エディションがサポートする機能」を参照してください。スケールアウト配置の詳細およびネットワーク負荷分散 (NLB) クラスタの使用については、「スケールアウト配置の計画」を参照してください。
フェールオーバー クラスタに参加している SQL Server インスタンス上で、レポート サーバー データベースをホストする方法もあります。次の図は、フェールオーバー クラスタに参加しているインスタンス上でレポート サーバー データベースをホストしたスケールアウト サーバー配置構成の例です。
.gif "フェールオーバー対応の標準的なスケールアウト配置")
フェールオーバー クラスタに参加しているインスタンス上でレポート サーバー データベースをホストすることによって、レポート環境のフォールト トレランスを強化できます。フェールオーバー クラスタリングは標準的な配置に適用することも可能ですが、高可用性を想定して構成された環境 (スケールアウト配置環境など) 以外では、その必要性はさほど高くありません。詳細については、「SQL Server フェールオーバー クラスタでのレポート サーバー データベースのホスト」を参照してください。
高度なスケールアウト サーバー配置
標準的なスケールアウト配置の他にも、レポート環境を強化することができる、より高度なスケールアウト配置構成もあります。たとえば、対話型のレポート処理のために負荷分散されたレポート サーバーを使用することも、スケジュールされたレポートだけを実行する専用のレポート サーバー コンピュータを追加することもできます。次の図は、こうした高度なスケールアウト サーバー配置構成の例を示しています。
.gif "高度なスケールアウト配置構成")
高度なスケールアウト配置によって得られるメリットは、標準的なスケールアウト配置と基本的には変わりません。ただし、(対話型のレポート処理を行う) 負荷分散されたレポート サーバーと、スケジュールされたレポートだけを実行するレポート サーバーとを分けることによって、環境のパフォーマンスを最大限に引き出すことができます。