Planning Server のパフォーマンスとスケーラビリティ

最初のトポロジが決定したら、ビジネス プロセスのパフォーマンスとユーザーの作業負荷の要件に合わせて Planning Server の展開をスケール アウトできます。Planning Server のスケール アウトは、アーキテクチャとアプリケーション計画の異なる 2 つの観点から行います。

ビジネスのモデリングと計画によって PerformancePoint Planning アプリケーションの編成方法が決まり、それによってアプリケーションの発行方法が決まります。つまり、1 つ以上のアプリケーションおよび選択したアプリケーション構造、および各アプリケーションのサポートに必要なデータ ボリュームに基づいたスケール アウトが可能です。アプリケーション設計に含まれるサイトが 1 つだけの場合、PerformancePoint Server の展開は Microsoft SQL Server 2005 を実行する 1 台のコンピュータと SQL Server 2005 Analysis Services を実行する 1 台のコンピュータにしかスケール アウトできません。しかし、複数のモデル サイトを持つ複数のアプリケーションを含むアプリケーション設計の場合は、複数の SQL Server と Analysis Services に PerformancePoint Server の展開をスケール アウトできます。

要約すると、ビジネス モデリングによって可能となるスケール アウトは次のとおりです。

• 各アプリケーションは SQL Server を実行する専用のコンピュータに配置できます。

• 各モデル サイトは専用の Analysis Services サーバーに発行できます。

大量のユーザー作業負荷、複数のビジネス プロセス タスク、および複雑なビジネス プロセスをサポートするには、アーキテクチャ面でのスケール アウトが必要となります。ネットワーク負荷分散が有効になっているクラスタにフロントエンド Web サーバーを展開することで、クライアントからの要求が適切な時間内に処理されるようにすることができます。ユーザーが要求したタスクとアクションに必要なパフォーマンスを提供するためには、複数のサーバーを導入することができます。これは、複数のユーザー アクションが同時に送信され、送信されたすべての要求を処理するための十分なリソースが展開した Planning プロセス サービスにない場合に最も効果があります。Planning プロセス サービスはネイティブの SQL Server 2005 サービス ブローカ機能を使用するため、SQL Server の構成を最適化することも、ユーザーの作業負荷に対応した Planning プロセス サービスのパフォーマンスにつながります。

スケール アウト中には、Planning Server の構成設定に注意する必要があります。接続タイムアウトなどの一部の構成設定は、十分に最適化された環境の場合でも、全体的なパフォーマンスに影響します。

スケール アウトの詳細については、SQL Server 2005 と Analysis Services のドキュメントのベスト プラクティスに関する説明を参照してください。

展開を適切にスケール アウトした後で、小規模な追加的改善をして生産性を向上させる必要が発生した場合は、スケール アップが必要となることがあります。スケール アップでは、ハード ディスクやメモリなどのリソースを追加または再構成して、各サーバー コンピュータの容量を増やします。オペレーティング システムを変更するか、または性能の高いサーバーに置き換える方法でも、展開内のサーバーをスケール アップできます。たとえば、管理者は、プロセッサを追加してシングルプロセッサ コンピュータをデュアルプロセッサ コンピュータにしたり、デュアルプロセッサ コンピュータを 4 つのプロセッサを搭載したマルチプロセッサ コンピュータにすることができます。コンピュータの RAM を増やしたり、ディスク容量を追加したりするスケール アップ方法もあります。最大 3 GB のメモリを搭載した 32 ビット オペレーティング システムを使用すれば、必要なレベルのサービスを提供できるはずです。4 GB を超えるメモリを搭載した 64 ビット オペレーティング システムのサーバーにスケール アップすることもできます。

スケール アップによる変更を利用するために、Planning Server で特別な構成の変更を行う必要はありません。

展開で使用するすべてのサーバーに同じプラットフォームを使用することをお勧めします。プラットフォームが混在した環境ではクラスタ化を使用できません。Windows Server の場合、32 ビット コンピュータと 64 ビット コンピュータのクラスタ化は明示的に禁止されています。

スケール アップの詳細については、IIS 6.0 Security Best Practices (IIS 6.0) (https://go.microsoft.com/fwlink/?LinkId=102487&clcid=0x411) を参照してください。

ビジネス ユーザーの生産性は、Planning Server を使用してビジネスのタスクと活動を遂行できるかどうかに左右されます。Planning Server を常に実行状態とし、予期しないハードウェア障害から保護するためには、さまざまな戦略を展開できます。

• ネットワーク負荷分散に対応したクラスタにフロントエンド Web サーバーを展開する方法。PerformancePoint Server システムの高可用性を確保できます。

• クラスタ環境に SQL Server を実行するコンピュータを展開する方法。アプリケーションの高可用性を確保できます。

• クラスタ環境に Analysis Services と分析サーバーを展開する方法。サイト モデルとモデルの高可用性を確保できます。

• RAID 5.0 または 6.0 を実装する方法。SQL Server と Analysis Services サーバーをミラーリングして、データの冗長性を確保して高可用性をサポートすることもできます。

展開には複数の非同期サーバーを配置することをお勧めします。ただし、Windows Server 2003 では同じ Windows サービスを実行しているコンピュータはクラスタ化はできないため、これらのサーバーのクラスタ化はサポートされません。

PerformancePoint Server がスタンドアロン展開にインストールされている場合を除き、クライアントとサーバーとのやり取りはすべてはネットワーク経由で実行されます。分散展開では、ネットワークの容量によって、ビジネス データおよびメタデータがやり取りされる速度が決まります。Planning Web サービス コンピュータから SQL Server データベースへと流れるのは、主にメタデータ、参照データ、およびファクト データです。SQL Server データベースから Analysis Services データベースへと流れるのは、トランザクション データと計画データ、および関連するセキュリティ設定です。Analysis Services へのデータの発行はより頻繁に発生する操作であるため、後者のデータ フローは、フロントエンド Web サーバーから SQL Server データベースへのデータ フローを上回ります。

Planning Server では、計画プロセスをサポートするために、オンライン モードとオフライン モードどちらでの操作も可能です。オフライン モードでは、ユーザーのセキュリティ構成に基づいて、Excel 用 PerformancePoint アドインがクライアント コンピュータ上のデータセットを取得および格納します。そのため、ネットワークの負荷はビジネス ユーザーに対して定義されているセキュリティ構成にも左右されます。セキュリティ構成は、最低限のスコープで Planning Business Modeler で定義し、ネットワーク上を行き交うデータ量を最小限にする必要があります。セキュリティが適切に構成されていない場合は、データの取得と更新の遅延がクライアント側で発生することがあります。これは、Excel 用 PerformancePoint アドインのオフライン機能に影響を与えます。

管理者が設計環境とテスト環境で適切なオンラインとオフラインのパフォーマンス ベンチマークを実施して、展開した環境でビジネス ユーザーに必要なレベルのサービスを提供できるようにすることをお勧めします。

Planning Server でのユーザーの作業負荷は、Planning Business Modeler におけるアプリケーションのモデリングおよび設計活動に加え、Excel 用 PerformancePoint アドインからのビジネス プロセスおよびデータの送信によって発生します。クライアントで生成されるユーザーの作業負荷の大部分は、データとビジネス活動をカプセル化した Web サービス要求としてネットワーク経由でサーバーに送信されます。データセットのサイズおよび関連するビジネス活動も、全体的なユーザーの作業負荷にも影響します。

Planning Server の展開をスケール アウトすると、より多くの作業負荷を処理できるようになる可能性があります。Planning Server の管理者が設計環境とテスト環境で基本的なベンチマークを実施して、展開した環境でビジネス ユーザーに必要なレベルのサービスを提供できるようにすることをお勧めします。

Planning Server の展開は 2 段階で行われます。ソフトウェア インストールとソフトウェア構成です。

まず、Planning Server がコンピュータにインストールされます。Planning Server の実行と構成に必要なすべての項目は構成可能です。

2 つの構成オプションは次のとおりです。

• スタンドアロン : このオプションでは、Planning Server データベースを含め、1 台のコンピュータにすべての Planning Server コンポーネントを構成します。構成を完了するには、SQL Server をターゲット コンピュータにインストールする必要があります。

• 分散 : このオプションでは、1 つ、2 つ、またはすべての Planning Server コンポーネントを構成します。これは、Planning Server と Planning Server データベースを個別のコンピュータに分散できるオプションです。分散型のマルチサーバー トポロジでは、複数のコンピュータでカスタムの構成手順が必要となる場合があります。

構成段階では、Planning Server 構成マネージャによって Planning Server コンピュータの構成が実行されます。ただし、クライアント インストール (Planning Business Modeler と Excel 用 PerformancePoint アドイン) では、インストールと構成が一度に実行されます。

Planning Server 構成マネージャは、初回のサーバー インストールの後に自動的に実行されます。Planning Server 構成マネージャで、構成するサーバーを選択してください。たとえば、Web サイトおよび SQL Server を実行するコンピュータを構成します。

Planning Server 構成マネージャは何度でも実行できます。たとえば、Planning Web サービスを構成し、後からリモート管理サービスを構成することもできます。

Planning Server のスタンドアロン インストール

Planning Server の分散インストール

分散インストールで Planning Server を展開する場合には、相互運用性に関する以下の考慮事項があります。これらは、展開を成功させるために必要となります。

Planning Server コンピュータのインストールは、お互いにミラー状態とする必要があります。つまり、ある Planning Server コンピュータ上のすべてのコードまたはコンポーネントを、Web ファーム内のすべての Planning Server コンピュータにインストールする必要があります。たとえば、Planning Web サービスが Web ファーム内の 1 台のコンピュータにインストールされている場合は、すべてのコンピュータにインストールする必要があります。

すべての Planning Server コンピュータは、ファームのサポートを向上するためにステートレスとなっています。つまり、Web ファーム内のどの Planning Server コンピュータも、サーバー構成データとコミットされたユーザー データを失わずに、同様のサーバーで置き換えることができます。これをアプリケーションがステートレスである状態と混同しないでください。障害の発生までにコミットされていなかった処理中のデータだけが、失われた可能性があります。

複数の SQL Server リレーショナル データベースと SQL Analysis Services データベースの使用が可能なだけではなく、推奨される場合があります。これは、以下のような場合です。

• 大規模なデータ ストアがある場合

• 1 つ以上のサービスから SQL Server または Analysis Services の 1 つのインスタンスに対して大量の要求が送信される場合