Microsoft Office Project Server 2007 キュー システム

キューのモジュール

キュー NT サービスは、すべての Project Server アプリケーション サーバー コンピュータに、準備処理の一環としてインストールされます。このサービスは、ファームに定義されている共有サービス プロバイダ (SSP) ごとに 1 つの "キュー ワーカー プロセス" を開始します。キュー ワーカー プロセスは、その SSP に関連付けられているすべての Project Web Access (PWA) インスタンスに対してサービスを提供し、"SSP Administrator" の ID を使用して実行されます。このセクションの残りの部分では、この展開モデルに留意してください。詳細については、後述の「キューの展開」を参照してください。

Project Server のキュー システムは、以下の 4 つのモジュールで構成されます。

1. ジョブの保存 : キューのジョブは、Project Server の下書きデータベースおよび発行済みデータベースに格納されます。これにより、ジョブのバックアップと復元は、Project Server データベースの通常のバックアップおよび復旧ルーチンの一環として行われます。

   

2. ジョブのポーリング : ジョブ ポーリング スレッドによって、ジョブの保存モジュールが一定の間隔でポーリングされ、新しいジョブが存在するかどうかの確認が行われます。ポーリング間隔は、Project Web Access の [キューの管理] ページで管理者によって構成されます。

   

   1. キュー ワーカー プロセスは、サービスする PWA の各インスタンスについてジョブ ポーリング スレッドを開始します。ジョブ ポーリング スレッドは、"キュー ワーカー プロセス" のプロセス内で "キュー ワーカー プロセス" ID を使用して実行されます。

   2. ジョブ ポーリング スレッドには、次の 2 つの主要なプロパティがあります。

      プロパティ	説明
      種類	ジョブ ポーリング スレッドには、"プロジェクト ジョブ ポーリング スレッド" (プロジェクト関連のジョブを探す)、"タイムシート ジョブ ポーリング スレッド" (タイムシート関連のジョブを探す) があります。
      Project Web Access インスタンス	すべてのジョブ ポーリング スレッドは、Project Web Access の特定のインスタンスから発生したジョブを探します。

3. ジョブの処理 : ジョブ ポーリング スレッドは、検出するジョブごとに 1 つのジョブ処理スレッドを生成します。ジョブ処理スレッドの最大数は、管理者によって構成されます。ジョブ処理用スレッドは、"キュー NT サービス" のプロセス内に存在し、"キュー NT サービス" の ID を使用して実行されることに注意してください。

   

4. ジョブの状態確認と管理 : これは、エンド ユーザーに対して表示される Project Server キューのモジュールです。

   

   1. Project Web Access の [キューの管理] ページ : 管理者が、キューに格納されているジョブの状態を確認するために使用します。また、失敗したジョブの取り消しや再試行を実行できます。この機能は PWA に含まれています。特別なツールをダウンロードする必要はありません。

   2. Project Web Access の [キューの設定] ページ : 管理者が、ポーリング間隔、ジョブ処理スレッドの最大数など、キューの設定を表示または変更できます。この機能は PWA に含まれています。特別なツールをダウンロードする必要はありません。

   3. Project Web Access の [自分のキュー ジョブ] ページ : すべてのユーザーは、このインターフェイスを使用してジョブの状態を確認できます。この機能は PWA に含まれています。特別なツールをダウンロードする必要はありません。

   4. キュー状態 PSI : ソフトウェア開発者は、これらの API を使用して、任意のキュー ジョブの状態を取得できます。検索を絞り込むための、いくつかの強力なフィルタがあります。

モジュール間の相互動作

Project Server のキュー システムの各モジュールは、ジョブの追加、ジョブの処理、ジョブ状態の取得などの要求が送られた場合、全体として相互動作する必要があります。

プロジェクト キューとタイムシート キューはどのように使用されるか

次の図は、Project Server のキュー システム内の各モジュールが、プロジェクト キューとタイムシート キューを使用してどのように動作するかを示しています。

1. ジョブ ポーリング スレッドの開始 : キューのサービスの対象となる Project Web Access インスタンスごとに、2 つのポーリング スレッドが開始します (キューは複数の Project Web Access インスタンスにサービスを提供できます)。1 つのスレッドはプロジェクト キューのサービスを、もう 1 つのスレッドはタイムシート キューのサービスを提供します。これらのスレッドはどちらも、"キュー ワーカー プロセス" のプロセス空間内に存在し、"キュー ワーカー プロセス" の ID (共有サービス プロバイダの管理者 ID) を使用して実行されます。

2. ジョブの保存 : 前に説明したように、プロジェクトに関連するジョブ (プロジェクトの保存、発行、レポート、キューブ作成など) は "下書き" データベースに格納されます。タイムシートに関連するジョブ (タイムシートの保存、タイムシートの提出など) は、"発行済み" データベースに格納されます。

3. ジョブの処理 : このモジュールでは、両者に違いはありません。"ジョブ ポーリング スレッド" が新規ジョブを検出すると、新しくジョブ処理用スレッドが作成されます。ジョブ処理用スレッドは、まだ "キュー ワーカー プロセス" のプロセス空間内に存在し、"キュー ワーカー プロセス" の ID (共有サービス プロバイダの管理者 ID) を使用して実行されることに注意してください。

   状態確認モジュールでは違いはありません。これは、ジョブが含まれるキューに関係なく、ジョブの状態を確認するだけです。キューの管理は Project Web Access の [キューの管理] ページで常にキューごとに行われます。管理者は設定を変更するキュー (プロジェクトまたはタイムシート) を選択する必要があります。

Project Server 2007 のインストール時にキュー NT サービスが展開される方法

ここでは、Office Project Server 2007 の展開の簡単な概要と共に、キューがどのように展開されるかについて説明します。

1. コンピュータの準備 : 展開の物理的なアーキテクチャを決定します。この例では、Web アプリケーションの実行用に 2 台 (Web ページの提供)、中間層の処理用に 1 台 (プロジェクトの保存、プロジェクトの発行など)、データベース用に 1 台のコンピュータを使用します。

   

2. Project Server ファームの作成 : いずれかのコンピュータに Project Server のインストールを試みると、ファームの作成 (または既存のファームへの参加) を求められます。Project Server のファームは、インストール環境を概念的に表したものと大まかに考えることができます。ファームのインフラストラクチャは、適切な要素を適切な場所に展開するための土台となります。ファームを作成すると、ファームの SharePoint サーバー全体管理 Web サイトも作成されます。この Web サイトを使用してすべてのファームの動作を集中管理できます。ファームにはファーム構成データベースが含まれます。このデータベースには、ファーム内のすべてのサーバーについての構成情報が格納されます。

   

3. バイナリのインストールとファームへの参加 : 次に、すべてのコンピュータへ Office Project Server 2007 をインストールし、Project Server ファームへ参加します。このプロセスの一環として、インストールを行っているコンピュータに、"フロントエンド Web" または "アプリケーション サーバー" (中間層のコンピュータ) という役割を割り当てる必要があります。

   

4. ファームの共有サービス プロバイダ (SSP) の準備 : ファームの SSP を準備するとき、Project Server 共有サービスに必要なサービスやコンポーネントは、"アプリケーション サーバー" の役割を持つすべてのコンピュータにインストールされます。このとき、さまざまなコンポーネントと同時に、キュー NT サービス、イベント NT サービス、および PSI Web アプリケーションが作成されます。下の図の中にある白い吹き出しは、ファームの論理的な構成を示しています。

   

   注意が必要な点がいくつかあります。

   1. ファームのインフラストラクチャは、それぞれの中間層コンピュータに必要なコンポーネントをインストールするための土台となります。複数の中間層サーバーがある場合、それらのサーバーの間で自動的に負荷が共有されます。

   2. これらの各 NT サービスは、共有サービス プロバイダ アプリケーション プールの ID で実行されます。これは、Windows Server 2003 コントロール パネルの [サービス] を使用して手動で管理することはできません。SharePoint Timer Service は、これらの NT サービス資格情報を、ファーム構成データベース上の Farm Administrator アカウントと定期的に同期します。

   この時点ではサービス対象の Project Web Access サイトが存在しないため、これらの NT サービスは何も行いません。

5. Project Web Access の準備 : この準備を行うには、SSP 管理 Web サイトにアクセスして Project Web Access インスタンスを作成します。この手順を終了すると、Project Web Access インスタンスのために必要なサービスおよびコンポーネントが作成されます。また、この準備処理では、キュー サービスとイベント サービスに対して、サービス対象の Project Web Access サイトが作成されたことが通知されます。下の図の中にある白い吹き出しは、ファームの論理的な構成を示しています。この場合、新しい Project Web Access インスタンス (ここでは PWA1) がファームに作成され、前の手順で作成された SSP へリンクされます。

   

   注意が必要な点がいくつかあります。

   1. Windows SharePoint Services サイト コレクションと関連するアプリケーション プールが、フロントエンド Web サーバーであるコンピュータすべてに作成されます。

   2. 4 つの Project Server データベースが作成されます。

   3. PWA サイト、SSP、およびデータベースの間の関係を登録するためのエントリが、構成データベースに作成されます。

6. 追加の Project Web Access インスタンスの準備 : 一般的なシナリオとして、ファームには複数の PWA インスタンスを作成します (たとえば、http://project20007/sales と http://project2007/marketing でサービスを提供します)。この場合、Project Server データベースの新しいセットが作成され、PWA Windows SharePoint Services サイト コレクションとアプリケーション プールが追加されます。下の図の中にある白い吹き出しは、ファームの論理的な構成を示しています。この場合、新しい PWA インスタンス (ここでは PWA2) がファームに作成され、SSP へリンクされます。PWA2 インスタンス用に、新しい Project Server データベースのセットが作成されることに注意してください。この時点で、キュー NT サービスおよびイベント NT サービスは、SSP に接続されているすべての PWA サイトに対してサービスの提供を開始します。この例では、PWA1 と PWA2 の両方に対してサービスの提供を開始します。

   

キュー サービスのプロパティ

前に述べたように、キュー NT サービスは、Project Server ファーム内で SSP が準備されるときに作成されます。キュー NT サービスの中間層コンピュータのプロパティを参照するときは、これらのプロパティのいくつかについて、それらがどのように決定されるかを理解することが重要です。

• キューのサービス名 : サービスの名前は ProjectQueueService です。ファーム内の SSP の数に関係なく、Project Server アプリケーション サーバー上に存在するキュー NT サービスは常に 1 つです。

• キューのスタートアップの種類 : キュー NT サービスは常に実行されている必要があるため、スタートアップの種類は [自動] です。

• キュー NT サービスのログオン アカウント : キュー NT サービスのログオン アカウントには、タイマ サービスのアカウントが設定されます (これはファームを作成するときに使用するアカウントです)。

キュー NT サービスがブートストラップを行い Project Web Access インスタンスへのサービス提供を開始する方法 : キューはタイマ サービス アカウントで実行され、ファーム構成データベースにアクセスします。キュー NT サービスは、開始時に構成データベースに対してクエリを実行し、ファームで準備されているすべての SSP の一覧を取得します。次に、それぞれの SSP に対応するキュー ワーカー プロセスを開始します。各キュー ワーカー プロセスは、SSP に関連付けられている PWA インスタンスの一覧を見つけ、PWA インスタンスごとに 2 つのポーリング スレッドを開始します。

キュー NT サービスの再起動の必要性 : 正常な状態であれば、一切再起動は必要ありません。キュー NT サービスはファーム構成の変更を常に監視しています。そして、変更があった場合は、その変更に自動的に対応します (NT サービスを再起動する必要はありません)。

Windows タスク マネージャに表示されるプロセス : Windows タスク マネージャを開くと、"Microsoft.Office.Project.Server.Queuing.exe" という同じ名前を持つプロセスが複数表示されます。それらのプロセスの中の 1 つは、タイマ サービス アカウントで実行されています。このプロセスがキュー NT サービス本体です。ファームの SSP と同じ数の Microsoft.Office.Project.Server.Queuing.exe プロセスがあり、それぞれが対応する SSP Administrator アカウントで実行されます。これらのプロセスがキュー ワーカー プロセスを表します。したがって、"Microsoft.Office.Project.Server.Queuing.exe" の総数は、SSP の数に タイマ サービス アカウントの分を 1 つ加えた数になります。

各種のトポロジにおけるキューの展開

ここでは、さまざまなトポロジの中でキューを展開する方法について説明します。これらのトポロジには、複数の PWA インスタンスが存在する場合や、複数の共有サービス プロバイダが存在する場合があります。

送信されたジョブ間の親子関係

送信されたジョブで、さらに処理が必要なものについては、親子関係が存在する可能性があることを理解することが重要です。たとえば、ユーザーがプロジェクト 1 を発行すると、プロジェクト 1 へのレポート要求と、プロジェクト 1 に関する通知の要求が生成されます。ここで、プロジェクト 1 の通知は常に生成されますが、プロジェクト 1 のレポートはプロジェクト 1 の発行が成功した場合のみ生成されるため、もし発行ジョブが失敗した場合、プロジェクト 1 のレポート ジョブは生成されないことに注意してください。

同様に、子ジョブが失敗しても、親ジョブには影響がない場合もあります。たとえば、プロジェクト 1 の通知が失敗しても、既に発生しているプロジェクト 1 の発行には影響しません。プロジェクト 1 の発行がキュー経由で処理されたことをユーザーが知ることができても、子ジョブが失敗した場合にそれを知らない可能性があることに注意してください。キューに入れられた親ジョブからどの子ジョブが作成されたか、またそれらのジョブの状態については、Project Web Access の [自分のキュー ジョブ] ページで確認することができます。管理者は、キュー管理 UI を使用して、キュー内のすべてのジョブを参照できます。

キューの状態の変更

ジョブがキューに入れられ処理される際に、キューの状態がどのように変更される可能性があるかを理解することは重要です。次のフローチャートは、各状態の間で発生する可能性のあるパスを示しています。

Project Web Access の [キューの管理] ページ

キューの管理は、Office Project Web Access の [キューの管理] ページを使用して実行できます。これは、一般的なプリンタで使用される、キュー内のすべての印刷ジョブを表示したり、必要に応じて問題を解決したりするための "すべてのジョブを表示" 画面と同様のものです。Project Web Access の [キューの管理] ページは、Project Web Access の [サーバー設定] ページからアクセスできます。

[キューの管理] ページでは、次の操作を行うことができます。

• キュー内のすべてのジョブの状態を参照する

• 失敗したジョブを取り消しまたは再試行する

  [!メモ]  キューの状態の詳細については、「キューの状態」を参照してください。

  [!メモ] キューの管理に関するユーザー インターフェイスの情報を表示するには、この記事の「キューの管理方法」を参照してください。

[自分のキュー ジョブ] ページ

[自分のキュー ジョブ] ページでは、エンド ユーザー用の管理ユーザー インターフェイス (どの PC にもある "印刷スプーラ" と同様のもの) が提供されており、キューに入れた自分の特定のジョブの状態を確認できます。Project Web Access ユーザーは、Project Web Access のホームページでサイド リンク バーの [個人用の設定] リンクを使用すると、[自分のキュー ジョブ] ページにアクセスできます。

ユーザーが、自分がキューに入れたすべてのジョブについての情報を確認するには、Project Web Access の [自分のキュー ジョブ] ページにアクセスします。[自分のキュー ジョブ] ページには、ユーザーがキューに入れたジョブについて次の情報が表示されます。

• キュー エントリの時刻

• キューの完了時間

• ジョブの名前

• ジョブの種類

• ジョブの状態

• 達成率

• キューの位置

• キューの種類

• エラー

さらに、[自分のキュー ジョブ] ページでは、ユーザーが次の条件に基づいてキューのジョブにフィルタを適用できます。

• 進行中または失敗したジョブ

• すべてのジョブ

• 過去 1 週間のすべてのジョブ

• 過去 1 週間の成功したジョブ

パフォーマンス カウンタ

キューに特有のパフォーマンス カウンタは数多く存在し、管理者はこれらのカウンタを使用して、現在の Office Project Server 2007 のシステム パフォーマンスに関するベンチマークを測定できます。これらのパフォーマンス カウンタは、現在の構成が目標とする性能を満たしているかどうか、別のサーバーなど追加のリソースが必要かどうかを判断するために非常に便利です。

特にジョブに関連するカウンタには、次のようなものがあります。

• Average wait time for any job in queue

• Average processing time for Publish jobs

• Percent of jobs failed

• Average wait time

キューに関連するその他の一般的なカウンタには、次のようなものがあります。

• Average queue depth

• % of SQL Retries

• SQL Calls per hour

• Average processing time for Publish jobs

キューのクリーンアップ

Project Server システムの使用中は、ジョブが次々とキューに入れられ、処理されます。キュー システムは、完了したすべてのジョブについて、状態などのメタデータを保持します。これによって、ジョブの状態を後で確認することが可能になります。これらのジョブは、時間と共に集積し、システムのパフォーマンス、特にジョブの状態の問い合わせに影響する可能性があります。この問題を解決するため、キュー システムにはクリーンアップ機構が組み込まれており、定期的にキューからジョブを削除します。削除による最大の影響として、削除されたジョブの状態が PSI または [キューの管理] ページを使用して確認できなくなることが挙げられます。

Project Web Access の [キューの設定] ページには、このクリーンアップ機構を制御する次のような構成パラメータがあります。

• クリーンアップ間隔 – クリーンアップが実行される頻度を決定します。既定値は 24 時間です。

• 成功したジョブのクリーンアップの経過時間制限 – 成功したジョブのクリーンアップの頻度を決定します。既定値は 24 時間です。

• 成功しなかったジョブのクリーンアップの経過時間制限 – 成功以外の状態で完了したジョブ (失敗 (相互関係のブロックなし) のジョブなど) のクリーンアップの頻度を決定します。既定値は 168 時間です。

キューの管理

ここでは、Project Web Access の [サーバー設定] ページの [キュー] セクションで、[キューの管理] を選択して利用可能なキューのフィルタ オプションについて説明します。選択されたキュー オプションの結果も、このページに表示されます。

キューの設定

ここでは、Project Web Access の [サーバー設定] ページの [キュー] セクションで、[キューの設定] を選択して利用可能なキューの構成オプションについて説明します。

キューの設定を構成するときは、以下の点に注意することが重要です。

• キューの設定は、Project Server インスタンス単位で構成されます。

• キューの設定は、キューの種類 (プロジェクトまたはタイムシート) ごとに独立して構成されます。

• 変更を有効にするために、キュー NT サービスを再起動する必要はありません。

• 複数のキュー NT サービスがこの Project Web Access インスタンスに対してサービスを提供する場合 (負荷分散環境など)、この設定によってすべてのキュー サービスが更新されます。

  [!メモ] このページで構成オプションを選択した後は、必ず [保存] ボタンをクリックして構成設定を保存してください。