Microsoft Office Project Server 2007 キュー システム
更新日: 2009年5月
トピックの最終更新日: 2015-03-09
この記事の内容 :
概要
キューのプロセス
キューのアーキテクチャ
プロジェクト キューとタイムシート キュー
キューの展開
キューのグループ化
キューの状態
キューの管理作業
キューの管理方法
この記事では、このバージョンの Project Server の主要な新機能である Microsoft Office Project Server 2007 のキュー システムについて説明します。キュー システムの概要、キューのプロセスとアーキテクチャ、キューに入れられたジョブがグループ化される方法、キューに入れられたジョブの状態の移行、および Microsoft Office Project Web Access のユーザー インターフェイスでキューを管理する方法について示します。
概要
キューとは、サービス要求の数がサービスの処理能力を超えたときに必要となる待ち行列です。エンタープライズ プロジェクト管理システムでは、これに当てはまる状況がしばしば発生します。次に例を示します。
ある小さな企業では金曜日の営業時間が終わるときに 500 人近くの従業員全員がタイムシートを提出する。
進捗報告会議の数時間前に、ほとんどのプロジェクト管理者が、自分が担当しているプロジェクトを発行する。
Office Project Server 2007 のキュー システムの目的は、このような突発的な要求の変化に、スマートかつ信頼性の高い方法で対処することです。Office Project Server 2007 のキュー システムはすべてのユーザーの入力を受け付け、要求のエントリを Microsoft SQL Server に記録し、データを先着順で非同期に処理します。キューを使用することで、要求が急激に増加しても Office Project Server 2007 EPM ソリューションが処理を停止しないようになります。
Office Project Server 2007 システムのほとんどの重要な処理は、Office Project Server 2007 のキュー システムを経由します。たとえば、次のような処理が挙げられます。
プロジェクトの保存
プロジェクトの発行
タイムシートの保存
タイムシートの提出
プロジェクトのバックアップおよび復旧
レポート データ サービスの操作
キューブ作成サービスの操作
サーバー側のスケジュール処理 (およびノード整合性の処理)
Project Server のキュー システムには、次のような利点があります。
信頼性
データの整合性 : キュー内のすべてのジョブを保存するための適切に定義されたプロトコルがあります。中途半端に保存されたジョブは処理されません。すべてのジョブは、ファイル システムではなく SQL Server に保存され、SQL Server トランザクションの利点を活用できます。
順序正しい実行 : Project Professional のユーザーが [保存] をクリックしてから [発行] をクリックすると、Project のキュー システムの機能により、保存ジョブが最初に処理され、その後に発行ジョブが処理されます。
フォールト トレランス : キュー内の失敗したジョブは再試行できます。また、キュー NT サービスの複数のインスタンスが実行されていて、いずれかのインスタンスが応答を停止した場合、別のインスタンスがその負荷を自動的に引き継ぎます (このプロセスは透過的フェールオーバーと呼ばれます)。
拡張性
マルチスレッド : Office Project Server 2007 のキュー システムは、複数のジョブを同時に処理できます。たとえば、プロジェクト 1 の保存、プロジェクト 2 の発行、およびキューブ作成のジョブを同時に処理することができます。
中間層サーバーを追加するだけで負荷を適切に処理できます。それぞれの中間層サーバーには Project キュー サービスがあり、負荷が自動的に分散されます。
キューに格納されるジョブ数は、SQL Server の規模の限界のみによって制限されます。
管理性
キューのプロセス
次の図は、キューのプロセスを示しています。
.gif "Project Server 2007 キュー プロセス")
ユーザーがクライアント アプリケーションからサーバー要求を行います (たとえば、Project Professional からプロジェクトを発行します)。ユーザーは、ジョブ ID (要求を追跡するための一意の識別子) を要求の一部として渡します。
Project Web サービスが要求を受け付け、キューに格納します。
ジョブ ID が確認用としてユーザーに発行されます。
ユーザーは、発行されたジョブ ID を使用して、要求の状態を確認するクエリを実行します。
Office Project Server 2007 のキュー システムは、要求の状態をユーザーに返します。
キュー アーキテクチャ
Project Server のキュー システムの論理アーキテクチャは、次の 4 つのモジュールで構成されます。
ジョブの保存
ジョブのポーリング
ジョブの処理
ジョブの状態確認と管理
Project Server キュー サービスに対して、ジョブの追加や処理、または状態取得などの要求が行われると、これらのモジュールは総体として動作し、要求されたタスクを実行します。ここでは、このプロセスの詳細について説明します。
キューのモジュール
キュー NT サービスは、すべての Project Server アプリケーション サーバー コンピュータに、準備処理の一環としてインストールされます。このサービスは、ファームに定義されている共有サービス プロバイダ (SSP) ごとに 1 つの "キュー ワーカー プロセス" を開始します。キュー ワーカー プロセスは、その SSP に関連付けられているすべての Project Web Access (PWA) インスタンスに対してサービスを提供し、"SSP Administrator" の ID を使用して実行されます。このセクションの残りの部分では、この展開モデルに留意してください。詳細については、後述の「キューの展開」を参照してください。
.gif "Project Server 2007 の NT サービスのキュー")
Project Server のキュー システムは、以下の 4 つのモジュールで構成されます。
ジョブの保存 : キューのジョブは、Project Server の下書きデータベースおよび発行済みデータベースに格納されます。これにより、ジョブのバックアップと復元は、Project Server データベースの通常のバックアップおよび復旧ルーチンの一環として行われます。
.gif "ジョブの記憶域")
ジョブのポーリング : ジョブ ポーリング スレッドによって、ジョブの保存モジュールが一定の間隔でポーリングされ、新しいジョブが存在するかどうかの確認が行われます。ポーリング間隔は、Project Web Access の [キューの管理] ページで管理者によって構成されます。
.jpg "ジョブのポーリング")
キュー ワーカー プロセスは、サービスする PWA の各インスタンスについてジョブ ポーリング スレッドを開始します。ジョブ ポーリング スレッドは、"キュー ワーカー プロセス" のプロセス内で "キュー ワーカー プロセス" ID を使用して実行されます。
ジョブ ポーリング スレッドには、次の 2 つの主要なプロパティがあります。
プロパティ 説明 種類
ジョブ ポーリング スレッドには、"プロジェクト ジョブ ポーリング スレッド" (プロジェクト関連のジョブを探す)、"タイムシート ジョブ ポーリング スレッド" (タイムシート関連のジョブを探す) があります。
Project Web Access インスタンス
すべてのジョブ ポーリング スレッドは、Project Web Access の特定のインスタンスから発生したジョブを探します。
ジョブの処理 : ジョブ ポーリング スレッドは、検出するジョブごとに 1 つのジョブ処理スレッドを生成します。ジョブ処理スレッドの最大数は、管理者によって構成されます。ジョブ処理用スレッドは、"キュー NT サービス" のプロセス内に存在し、"キュー NT サービス" の ID を使用して実行されることに注意してください。
.gif "Project Server 2007 - ジョブの処理のキュー")
ジョブの状態確認と管理 : これは、エンド ユーザーに対して表示される Project Server キューのモジュールです。
.gif "ジョブの状態のチェックと管理")
Project Web Access の [キューの管理] ページ : 管理者が、キューに格納されているジョブの状態を確認するために使用します。また、失敗したジョブの取り消しや再試行を実行できます。この機能は PWA に含まれています。特別なツールをダウンロードする必要はありません。
Project Web Access の [キューの設定] ページ : 管理者が、ポーリング間隔、ジョブ処理スレッドの最大数など、キューの設定を表示または変更できます。この機能は PWA に含まれています。特別なツールをダウンロードする必要はありません。
Project Web Access の [自分のキュー ジョブ] ページ : すべてのユーザーは、このインターフェイスを使用してジョブの状態を確認できます。この機能は PWA に含まれています。特別なツールをダウンロードする必要はありません。
キュー状態 PSI : ソフトウェア開発者は、これらの API を使用して、任意のキュー ジョブの状態を取得できます。検索を絞り込むための、いくつかの強力なフィルタがあります。
モジュール間の相互動作
Project Server のキュー システムの各モジュールは、ジョブの追加、ジョブの処理、ジョブ状態の取得などの要求が送られた場合、全体として相互動作する必要があります。
ジョブの追加
キューにジョブを追加する方法は多数あります。たとえば、プロジェクト管理者は Project Professional でプロジェクトを保存し、チーム メンバはタイムシートを提出し、サードパーティ アプリケーションはプロジェクトを発行します。これらの各操作によって Project Server インターフェイス (PSI) の要素への呼び出しが生成され、呼び出しによって適切なジョブがキューに追加されます。
.gif "ジョブの追加--アーキテクチャ")
ジョブの処理
ジョブの処理はさまざまなフェーズで発生し、各種モジュール間の相互動作が発生します。
キュー ワーカー プロセスの開始 : キュー NT サービスが開始するときに、ファームに定義されている共有サービス プロバイダごとに 1 つのキュー ワーカー プロセスが開始されます。Project のキュー システムが動作するためには、キュー NT サービスが常に実行されている必要があります。
ジョブ ポーリング スレッドの開始 : キュー ワーカー プロセスが開始するときに、ジョブ ポーリング スレッドが開始されます。それぞれのジョブ ポーリング スレッドは、Project Web Access のインスタンスごとに固有です。
新規ジョブの探索 : ポーリング スレッドは、プロジェクト データベース内の新規ジョブを探します。
ジョブ処理用スレッドの作成 : 新規ジョブがある場合、ジョブ処理用スレッドが作成されます。
状態の書き込み : ジョブ処理用スレッドが完了すると、ジョブの状態 (成功または失敗) がデータベースに書き戻されます。
.gif "Project Server 2007 ジョブ プロセス キュー")
状態の取得
ジョブの状態はさまざまな方法で調べることができます。管理者は Project Web Access の [キューの管理] ページを使用し、チーム メンバは [自分のキュー ジョブ] ページを使用し、ソフトウェア開発者はキュー PSI の方法を利用してプログラムによって状態を取得できます。PSI の方法の詳細については、「MSDN Library online (英語)」(https://msdn2.microsoft.com/en-us/library/bb187390.aspx) の「Project 2007 SDK Documentation (英語)」を参照してください。
.gif "Project Server 2007 ジョブの状態の確認")
プロジェクト キューとタイムシート キュー
Office Project Server 2007 のキュー システムは、2 つの独立したキューで構成されます。
プロジェクト キュー 保存、発行、レポート、キューブ作成など、プロジェクト関連のメッセージに主に使用されますが、他の種類のメッセージもこのキューへ送られることがあります。このキューのテーブルとストアド プロシージャは、Office Project Server 2007 の下書きデータベースに格納されます。
タイムシート キュー タイムシートの保存、タイムシートの提出など、タイムシート関連のメッセージに主に使用されますが、他の種類のメッセージもこのキューへ送られることがあります。このキューのテーブルとストアド プロシージャは、Office Project Server 2007 の発行済みデータベースに格納されます。
これら 2 つのキューは同様に設計されていますが、ジョブは異なるデータベースに格納されます。2 種類のキューが存在することで、以下のような利点があります。
パフォーマンス : キューのジョブ データをコア データと同じデータベースに格納することで、キューがジョブを処理する際に、コストの高いデータベース間の呼び出し回数を減らすことができます。たとえば、タイムシートの提出ジョブが発生すると、ユーザーによって入力されたデータ (就業時間など) は、提出されるキュー ジョブにパッケージ化されて、SQL Server のジョブ ストアに格納されます。また、タイムシートについては既に情報 (期間、名前など) が存在し、この情報は "発行済み" データベースにあります。タイムシートの提出ジョブを処理するには、両方のデータ セットが必要です。両方のデータ セットが同じデータベースに存在すれば、パフォーマンスが向上します。このため、タイムシート キューのジョブは "発行済み" データベース (タイムシートのすべてのコア データを含む) に格納され、プロジェクト キューのジョブは "下書き" データベース (プロジェクトのほとんどのコア データを含む) に格納されます。
細かな調整 : キューのすべての設定は、プロジェクト キューとタイムシート キューで個別に指定できます。このため、管理者は柔軟に構成を行うことができます。たとえば、Office Project Server 2007 を主にタイムシートに使用し、プロジェクトにはほとんど使用していない場合、プロジェクト キューのポーリング間隔を 1 分に、タイムシート キューのポーリング間隔を 10 秒に設定できます。
[!メモ] ポーリング間隔によって、キュー サービスがどちらかのキューで新しいジョブの存在を確認する間隔が指定されます。この設定は、Project Web Access の [キューの設定] ページで指定できます。
プロジェクト キューとタイムシート キューはどのように使用されるか
次の図は、Project Server のキュー システム内の各モジュールが、プロジェクト キューとタイムシート キューを使用してどのように動作するかを示しています。
.jpg "Project Server 2007 のキュー アーキテクチャ")
ジョブ ポーリング スレッドの開始 : キューのサービスの対象となる Project Web Access インスタンスごとに、2 つのポーリング スレッドが開始します (キューは複数の Project Web Access インスタンスにサービスを提供できます)。1 つのスレッドはプロジェクト キューのサービスを、もう 1 つのスレッドはタイムシート キューのサービスを提供します。これらのスレッドはどちらも、"キュー ワーカー プロセス" のプロセス空間内に存在し、"キュー ワーカー プロセス" の ID (共有サービス プロバイダの管理者 ID) を使用して実行されます。
ジョブの保存 : 前に説明したように、プロジェクトに関連するジョブ (プロジェクトの保存、発行、レポート、キューブ作成など) は "下書き" データベースに格納されます。タイムシートに関連するジョブ (タイムシートの保存、タイムシートの提出など) は、"発行済み" データベースに格納されます。
ジョブの処理 : このモジュールでは、両者に違いはありません。"ジョブ ポーリング スレッド" が新規ジョブを検出すると、新しくジョブ処理用スレッドが作成されます。ジョブ処理用スレッドは、まだ "キュー ワーカー プロセス" のプロセス空間内に存在し、"キュー ワーカー プロセス" の ID (共有サービス プロバイダの管理者 ID) を使用して実行されることに注意してください。
状態確認モジュールでは違いはありません。これは、ジョブが含まれるキューに関係なく、ジョブの状態を確認するだけです。キューの管理は Project Web Access の [キューの管理] ページで常にキューごとに行われます。管理者は設定を変更するキュー (プロジェクトまたはタイムシート) を選択する必要があります。
キューの展開
Project Server のキュー システムの展開方法を理解するには、Office Project Server 2007 の全般的な展開方法を理解する必要があります。ここでは、展開プロセスの概要を簡単に説明します。詳細については、「サーバー ファーム環境に Project Server 2007 を展開する」を参照してください。
これまでの説明を読み終えても、次のようないくつかの基本的な疑問が残ると思います。
そもそも、キュー NT サービスはどのように作成されるのか。
キュー NT サービスはどのように開始されるのか。たとえば、Project の下書きデータベースおよび発行済みデータベースの場所をどうやって検出するのか。
複数の Project Web Access インスタンスが準備されると、どのような動作が行われるのか (より多くの Project データベースが作成されるのか)。
複数の SSP が準備されると、どのような動作が行われるのか (より多くのキュー NT サービスが作成されるのか)。
ここでは、これらの疑問に回答します。
Project Server 2007 のインストール時にキュー NT サービスが展開される方法
ここでは、Office Project Server 2007 の展開の簡単な概要と共に、キューがどのように展開されるかについて説明します。
コンピュータの準備 : 展開の物理的なアーキテクチャを決定します。この例では、Web アプリケーションの実行用に 2 台 (Web ページの提供)、中間層の処理用に 1 台 (プロジェクトの保存、プロジェクトの発行など)、データベース用に 1 台のコンピュータを使用します。
.gif "コンピュータを準備する")
Project Server ファームの作成 : いずれかのコンピュータに Project Server のインストールを試みると、ファームの作成 (または既存のファームへの参加) を求められます。Project Server のファームは、インストール環境を概念的に表したものと大まかに考えることができます。ファームのインフラストラクチャは、適切な要素を適切な場所に展開するための土台となります。ファームを作成すると、ファームの SharePoint サーバー全体管理 Web サイトも作成されます。この Web サイトを使用してすべてのファームの動作を集中管理できます。ファームにはファーム構成データベースが含まれます。このデータベースには、ファーム内のすべてのサーバーについての構成情報が格納されます。
.gif "ファームを作成する")
バイナリのインストールとファームへの参加 : 次に、すべてのコンピュータへ Office Project Server 2007 をインストールし、Project Server ファームへ参加します。このプロセスの一環として、インストールを行っているコンピュータに、"フロントエンド Web" または "アプリケーション サーバー" (中間層のコンピュータ) という役割を割り当てる必要があります。
.gif "バイナリをインストールして、ファームに参加させる")
ファームの共有サービス プロバイダ (SSP) の準備 : ファームの SSP を準備するとき、Project Server 共有サービスに必要なサービスやコンポーネントは、"アプリケーション サーバー" の役割を持つすべてのコンピュータにインストールされます。このとき、さまざまなコンポーネントと同時に、キュー NT サービス、イベント NT サービス、および PSI Web アプリケーションが作成されます。下の図の中にある白い吹き出しは、ファームの論理的な構成を示しています。
.gif "共有サービス プロバイダのプロビジョニング")
注意が必要な点がいくつかあります。
ファームのインフラストラクチャは、それぞれの中間層コンピュータに必要なコンポーネントをインストールするための土台となります。複数の中間層サーバーがある場合、それらのサーバーの間で自動的に負荷が共有されます。
これらの各 NT サービスは、共有サービス プロバイダ アプリケーション プールの ID で実行されます。これは、Windows Server 2003 コントロール パネルの [サービス] を使用して手動で管理することはできません。SharePoint Timer Service は、これらの NT サービス資格情報を、ファーム構成データベース上の Farm Administrator アカウントと定期的に同期します。
この時点ではサービス対象の Project Web Access サイトが存在しないため、これらの NT サービスは何も行いません。
Project Web Access の準備 : この準備を行うには、SSP 管理 Web サイトにアクセスして Project Web Access インスタンスを作成します。この手順を終了すると、Project Web Access インスタンスのために必要なサービスおよびコンポーネントが作成されます。また、この準備処理では、キュー サービスとイベント サービスに対して、サービス対象の Project Web Access サイトが作成されたことが通知されます。下の図の中にある白い吹き出しは、ファームの論理的な構成を示しています。この場合、新しい Project Web Access インスタンス (ここでは PWA1) がファームに作成され、前の手順で作成された SSP へリンクされます。
.gif "Project Web Access のプロビジョニング")
注意が必要な点がいくつかあります。
Windows SharePoint Services サイト コレクションと関連するアプリケーション プールが、フロントエンド Web サーバーであるコンピュータすべてに作成されます。
4 つの Project Server データベースが作成されます。
PWA サイト、SSP、およびデータベースの間の関係を登録するためのエントリが、構成データベースに作成されます。
追加の 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 の両方に対してサービスの提供を開始します。
.gif "別の Project Web Access インスタンスをプロビジョニングする")
複数の Project Server アプリケーション サーバー上のキュー NT サービス
キュー NT サービスは、ファーム内のすべての Project Server アプリケーション サーバー ("中間層サーバー" とも呼ばれます) に作成されます。たとえば、2 つの Project Server アプリケーション サーバーがある場合、Project Server ファームで新規 SSP の準備を行うと、両方のコンピュータに新しいキュー NT サービスが作成されます。重要な点として、キュー NT サービスは、親の SSP に接続されているすべての PWA インスタンスに対してサービスを提供することが挙げられます。
キュー サービスのプロパティ
前に述べたように、キュー NT サービスは、Project Server ファーム内で SSP が準備されるときに作成されます。キュー NT サービスの中間層コンピュータのプロパティを参照するときは、これらのプロパティのいくつかについて、それらがどのように決定されるかを理解することが重要です。
.jpg "キュー サービスのプロパティ")
キューのサービス名 : サービスの名前は 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 インスタンスが存在する場合や、複数の共有サービス プロバイダが存在する場合があります。
キューの開始と複数の PWA へのサービス提供
キューが開始されると、最初にファーム構成データベースと通信し、サービス対象のすべての Project Web Access インスタンスについて問い合わせます。キューは、共有サービス プロバイダの GUID を使用して自身を識別します。これは、キュー NT サービスの起動時のパラメータです (詳細については、「キューの展開」を参照してください)。
.gif "Project Server 2007 デュアル Web キュー")
キュー NT サービスは、ファーム構成データベースと通信し、ファームに定義されているすべての SSP についての情報を問い合わせます。
キュー NT サービスは、それぞれの SSP に対応する "キュー ワーカー プロセス" を開始します。これらのプロセスは、対応する SSP Admin アカウントで実行されます。
キュー NT サービスは、それぞれの SSP について、関連付けられている PWA サイトの一覧を取得します。
キュー NT サービスは、各 PWA サイトについて、PWA データベースへの接続情報を取得します。
キュー NT サービスは、PWA のインスタンスごとに 2 つのジョブ ポーリング スレッドを開始します。
これらのジョブ ポーリング スレッドが、新規ジョブのポーリングを行います。
単一 SSP、複数 PWA 環境におけるキューの展開
ここでは、単一 SSP 環境において、この SSP に対して 2 つの Project Web Access インスタンスが準備されている場合のキューのアーキテクチャを示します。
.gif "Project Server 2007 キュー システムの単一 SSP")
キュー NT サービスは、ファーム構成データベースと通信し、ファームに定義されているすべての SSP についての情報を問い合わせます。
キュー NT サービスは、それぞれの SSP に対応する "キュー ワーカー プロセス" を開始します。これらのプロセスは、対応する SSP Admin アカウントで実行されます。
キュー NT サービスは、それぞれの SSP について、関連付けられている PWA サイトの一覧を取得します。
キュー NT サービスは、各 PWA サイトについて、PWA データベースへの接続情報を取得します。
キュー NT サービスは、PWA のインスタンスごとに 2 つのジョブ ポーリング スレッドを開始します。
これらのジョブ ポーリング スレッドが、新規ジョブのポーリングを行います。
新規ジョブが検出されると、ジョブ ポーリング スレッドは、ジョブ処理用スレッドを新たに開始します。
デュアル SSP 環境におけるキューの展開
ここでは、2 つの SSP が存在する環境で、それぞれの SSP に対して単一の Project Web Access インスタンスが準備されている場合のキューのアーキテクチャを示します。
.gif "Project Server メッセージ キュー")
キュー NT サービスは、ファーム構成データベースと通信し、ファームに定義されているすべての SSP についての情報を問い合わせます。
キュー NT サービスは、それぞれの SSP に対応する "キュー ワーカー プロセス" を開始します。これらのプロセスは、対応する SSP Admin アカウントで実行されます。
キュー NT サービスは、それぞれの SSP について、関連付けられている PWA サイトの一覧を取得します。
キュー NT サービスは、各 PWA サイトについて、PWA データベースへの接続情報を取得します。
キュー NT サービスは、PWA のインスタンスごとに 2 つのジョブ ポーリング スレッドを開始します。
これらのジョブ ポーリング スレッドが、新規ジョブのポーリングを行います。
新規ジョブが検出されると、ジョブ ポーリング スレッドは、ジョブ処理用スレッドを新たに開始します。
キューのグループ化
キューに格納されたデータは、次の 3 つの異なるレベルでグループ化されます。
**ジョブ **ジョブとは、Project Server によって実行される、追跡可能な作業のパケットです (プロジェクトの保存、プロジェクトの発行、タイムシートの提出など)。ジョブの中には、ユーザーによって明示的に開始されないものもあります (電子メールによる通知、データの同期の報告など)。キューの追跡はジョブのレベルで行われます (ジョブ ID を使用)。
**相互関係ジョブ グループ **相互関係ジョブ グループは、Project Server 内部のルールによって適用されるジョブの分類です。相互関係ジョブ グループ内のジョブは、常に一緒に、順番に処理されます (一部例外はあります)。下記の例では、プロジェクト 1 が Project Professional で編集、保存され、チェックインされます。次に、他のユーザーがプロジェクト 1 をチェックアウトし、発行します。プロジェクト 1 を発行すると、レポートが起動され、レポート ジョブもキューに追加されます。Project Server は、プロジェクト 1 に関係する 4 つのジョブで構成される相互関係グループを組み立てます。Project Server の内部ルールによってこれらのジョブ間の依存関係が指定されるため、ジョブの処理は順番に試みられます。プロジェクト 1 の発行とレポート データベースの更新は、プロジェクト 1 が保存されるまでは行えないという依存関係が存在します。また、相互関係ジョブのいずれかが失敗した場合、相互関係グループ内でそのジョブの後にある他のジョブはブロックされます。たとえば、プロジェクト 1 の保存ジョブ (ジョブ ID 12) が失敗した場合、プロジェクト 1 のチェックイン ジョブ (ジョブ ID 13) はブロックされる必要があります。この場合、プロジェクト 1 のチェックイン ジョブが実行されると、問題が発生します。チェックインが実行されると、他のユーザーがプロジェクト 1 (保存が失敗しているため、このプロジェクトは不整合な状態の可能性があります) をチェックアウトし、変更を試みる可能性があります。
**サブジョブ **各ジョブは、"サブジョブ" と呼ばれるさらに小さいセグメントに分割できます。ジョブが非常に大きい場合 (10 MB のプロジェクトの保存など)、複数のサブジョブに分割されます。サブジョブは、PSI や Project Web Access ユーザーには公開されません。
.gif "異なるレベルのキューのグループ化")
送信されたジョブ間の親子関係
送信されたジョブで、さらに処理が必要なものについては、親子関係が存在する可能性があることを理解することが重要です。たとえば、ユーザーがプロジェクト 1 を発行すると、プロジェクト 1 へのレポート要求と、プロジェクト 1 に関する通知の要求が生成されます。ここで、プロジェクト 1 の通知は常に生成されますが、プロジェクト 1 のレポートはプロジェクト 1 の発行が成功した場合のみ生成されるため、もし発行ジョブが失敗した場合、プロジェクト 1 のレポート ジョブは生成されないことに注意してください。
.gif "ジョブ間の親子関係")
同様に、子ジョブが失敗しても、親ジョブには影響がない場合もあります。たとえば、プロジェクト 1 の通知が失敗しても、既に発生しているプロジェクト 1 の発行には影響しません。プロジェクト 1 の発行がキュー経由で処理されたことをユーザーが知ることができても、子ジョブが失敗した場合にそれを知らない可能性があることに注意してください。キューに入れられた親ジョブからどの子ジョブが作成されたか、またそれらのジョブの状態については、Project Web Access の [自分のキュー ジョブ] ページで確認することができます。管理者は、キュー管理 UI を使用して、キュー内のすべてのジョブを参照できます。
[!メモ] Project Web Access の [自分のキュー ジョブ] ページおよび [キューの管理] ページについては、この記事の「キューの管理」で説明しています。
キューの状態
ジョブがキューに送信されると、ジョブはさまざまな状態を遷移します。次の表は、それぞれの状態について示しています。
| 状態 | 説明 |
|---|---|
キューに配置中 |
ジョブがキューに入れられます。ジョブ ID が発行されます。 |
処理待機中 |
ジョブはキューに存在し、処理待機中です。 |
処理中 |
ジョブは処理中です。 |
成功 |
ジョブは正しく処理されました。これは終了状態で、このジョブに対してこれ以上の処理は行われません。 |
ブロック |
ジョブは、同じ相互関係グループ内の前にある別のジョブが失敗していることにより、ブロックされています。再試行または取り消しを行います。 |
失敗 (相互関係のブロックなし) |
ジョブは失敗しましたが、グループ内の他のジョブをブロックしていません。これは終了状態で、このジョブに対してこれ以上の処理は行われません。 |
失敗 (相互関係をブロック中) |
ジョブは失敗し、依存関係にある 1 つ以上のジョブをブロックしている可能性があります。 |
最適化のため無視 |
グループ内で、このジョブの後に重複ジョブが見つかったため、このジョブは無視されました。たとえば、プロジェクト管理者がプロジェクトの作業を行うとき、以下の作業を順番に試みたとします。
プロジェクト 1 に対する 3 回の保存と変更は、すべて処理されます。ただし、3 回の発行すべてを処理する必要はありません。最後の発行ジョブが処理されると、3 回の発行ジョブがすべて処理された場合と同じ結果になります。最適化のため、最初の 2 回の発行の試みは無視されます。 |
取り消し |
ジョブは取り消されました。"成功" と "失敗 (相互関係のブロックなし)" の 2 つの終了状態を除く任意の状態のジョブを取り消すことができます。 |
キューの状態の変更
ジョブがキューに入れられ処理される際に、キューの状態がどのように変更される可能性があるかを理解することは重要です。次のフローチャートは、各状態の間で発生する可能性のあるパスを示しています。
.jpg "Project Server 2007 のキュー システム - 状態の編集")
| 状態 | 可能性のある次の状態 |
|---|---|
キューに配置中 |
|
処理待機中 |
|
処理中 |
|
成功 |
|
ブロック |
|
失敗 (相互関係のブロックなし) |
|
失敗 (相互関係をブロック中) |
|
最適化のため無視 |
|
取り消し |
|
キューの管理作業
Office Project Server 2007 のミッションクリティカルな処理のほとんどは、キューを経由します。このため、Microsoft Office Enterprise Project Management (EPM) Solutionのインストールが円滑に機能するためには、キューについての理解と管理が非常に重要です。たとえば、以下のような場合には、キューの管理をより適切に行うことが求められます。
プロジェクトを発行するのに時間が長くかかる。
キューの管理ページが読み込まれるのに長い時間を要し、ジョブ数が 100,000 と表示される。
上司から、新しい中間層 Office Project Server 2007 サーバー (アプリケーション サーバー) の購入によって実際にパフォーマンスが向上するのかどうかを確認する方法を質問された。
キューの管理を行うには、次のものを使用します。
Project Web Access の [キューの管理] ページ
[自分のキュー ジョブ] ページ
パフォーマンス カウンタ
キューのクリーンアップ
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 の [サーバー設定] ページで行います。[サーバー設定] ページの [キュー] セクションには、キューを管理するための 2 つのオプションがあります。
[キューの管理] このページを使用して、キュー内のジョブを参照できます。構成オプションを使用して、ジョブにフィルタを適用し、目的のジョブだけを表示することができます。また、このページでは、1 つまたは複数のジョブを再試行したり、取り消すこともできます。
[キューの設定] プロジェクト キューおよびタイムシート キューからどのジョブを取り出して、どのように処理するかを制御する構成オプションを設定できます。これらの設定を適用する際、キュー NT サービスの再起動は必要ありません。
キューの管理
ここでは、Project Web Access の [サーバー設定] ページの [キュー] セクションで、[キューの管理] を選択して利用可能なキューのフィルタ オプションについて説明します。選択されたキュー オプションの結果も、このページに表示されます。
フィルタの種類
このフィルタは、[ジョブ グリッド] セクションにジョブが表示される順序を決定します。利用可能なオプションは以下のとおりです。
状態順
自分のジョブ
プロジェクト順
ID 順
ジョブ履歴
このパラメータを使用して、[ジョブ グリッド] に表示されるジョブの日付範囲を選択できます。[開始日] フィールドと [終了日] フィールドを使用して、開始日付と終了日付を選択します。
[ジョブの最大数] フィールドを使用し、ある日付範囲に対して表示されるジョブ数を制限します。選択した日付範囲に大量のジョブが含まれており、それらを [ジョブ グリッド] に表示する必要があるとき、[キューの管理] ページのロード時間が非常に長くなることがあります。[ジョブの最大数] フィールドを使用すると、表示されるジョブを制限できます。既定値は 500 です。
ジョブの種類
このセクションでは、[ジョブ グリッド] に表示されるジョブの種類 (プロジェクトの発行、タイムシートの提出、リソース計画のチェックインなど) を選択できます。既定では、すべての種類のジョブが [選択したジョブ] リストに表示されます。
ジョブ完了状態
このセクションでは、[ジョブ グリッド] に表示されるジョブ完了状態を選択できます。既定では、"成功" を除くすべてのジョブ完了状態が [選択したジョブの状態] リストにあります。つまり、正常に終了したジョブは [ジョブ グリッド] には表示されません。
列の選択
このセクションでは、[ジョブ グリッド] セクションに表示される列を選択できます。
詳細オプション
このセクションでは、取り消し操作に適用される特別な操作を指定できます。次の操作を選択することができます。
キューに入っているジョブの取り消し
相互関係にある後続ジョブの取り消し
ジョブ グリッド
このセクションでは、[キューの管理] ページに指定した条件に一致するジョブを表示できます。このセクションに含まれるオプションを使用して、ジョブ、またはジョブのグループを選択し、可能ならば次のオプションを適用できます。
ジョブの再試行
ジョブの取り消し
[!メモ] 表示または選択しているジョブ一覧を更新するには、ページを手動で更新する必要があります。この操作は、このセクションにある [更新] ボタンで実行できます。
キューの設定
ここでは、Project Web Access の [サーバー設定] ページの [キュー] セクションで、[キューの設定] を選択して利用可能なキューの構成オプションについて説明します。
キューの設定を構成するときは、以下の点に注意することが重要です。
キューの設定は、Project Server インスタンス単位で構成されます。
キューの設定は、キューの種類 (プロジェクトまたはタイムシート) ごとに独立して構成されます。
変更を有効にするために、キュー NT サービスを再起動する必要はありません。
複数のキュー NT サービスがこの Project Web Access インスタンスに対してサービスを提供する場合 (負荷分散環境など)、この設定によってすべてのキュー サービスが更新されます。
[!メモ] このページで構成オプションを選択した後は、必ず [保存] ボタンをクリックして構成設定を保存してください。
キューの種類
このセクションでは、設定を適用するキューの種類 (プロジェクトまたはタイムシート) を指定できます。
ジョブ処理用スレッドの最大数
このセクションでは、同時に実行できるジョブ処理用スレッドの最大数を指定できます。有効な値の範囲は 1 ～ 20 で、既定値は 4 です。
ポーリング間隔
このセクションでは、キュー NT サービスがプロジェクト データベースまたはタイムシート データベース (選択したジョブの種類に応じます) をポーリングして、新規ジョブを探す間隔をミリ秒単位で指定します。有効な値の範囲は 500 ～ 300000 で、既定値は 1000 です。
再試行間隔
このセクションでは、SQL のデッドロックなど、SQL 関連の問題で失敗したジョブの再試行の間隔をミリ秒単位で設定できます。有効な値の範囲は 0 (直ちに再試行) ～ 300000 で、既定値は 1000 です。
再試行制限回数
このセクションでは、失敗したポーリング クエリの再試行回数の制限を設定できます。Project Server のキュー システムは、データベースを定期的にポーリングし、処理が必要なジョブを取得します。このクエリが SQL 関連の理由で失敗した場合、システムは一定時間後にデータベースのポーリングを再度試みます。
SQL 再試行間隔
キューはデータベースを定期的にポーリングして、処理が必要なジョブを調べます。このセクションでは、このクエリが失敗してから再試行できるようになるまでの期間 (ミリ秒) を設定できます。有効な値の範囲は 0 (直ちに再試行) ～ 60000 で、既定値は 1000 です。
SQL の再試行制限回数
キューはデータベースを定期的にポーリングして、処理が必要なジョブを調べます。このセクションでは、このクエリが失敗した場合に再試行する回数を設定できます。有効な値の範囲は 0 (再試行なし) ～ 100 で、既定値は 5 です。
SQL のタイムアウト
キューは、ジョブの取得と実行のために SQL 呼び出しを行います。このセクションでは、これらの呼び出しのタイムアウト値 (秒) を設定できます。ジョブが SQL タイムアウト エラーで失敗した場合は、この設定の値を増やしてジョブを再試行できます。有効な値の範囲は 19 ～ 86400 (1 日) で、既定値は 30 です。
クリーンアップ間隔
このセクションでは、キューのクリーンアップ ジョブを実行する間隔 (時間) を設定できます。有効な値の範囲は 1 ～ 100000 で、既定値は 24 (1 日) です。
クリーンアップ間隔のオフセット値
このセクションでは、キューのクリーンアップ ジョブを実行する時刻を設定できます。値として 12:00 a.m. からの経過分数を入力すると、その時刻にキューのクリーンアップ ジョブが実行されます。有効な値の範囲は 0 (12:00 a.m.) ～ 1439 (11:59 p.m.) で、既定値は 0 です。
成功したジョブのクリーンアップの経過時間制限
このセクションでは、キューのクリーンアップ ジョブを実行して、成功したジョブをパージするための経過時間制限 (時間) を設定できます。各ジョブの経過時間は、ジョブが完了した日付と時刻に基づいて判別されます。たとえば、あるジョブが 2007 年 10 月 1 日の 10:40 p.m. に正常終了し、キューのクリーンアップ ジョブを 2007 年 10 月 2 日の 11:55 p.m. に実行したとき、そのジョブはパージされます ([成功したジョブのクリーン アップの経過時間制限] の値が既定値の 24 時間だった場合)。
有効な値の範囲は 1 ～ 100000 で、既定値は 24 (1 日) です。
[!メモ] 通常、成功したジョブの数は、成功しなかったジョブに比べて非常に多くなります。このため、[成功したジョブのクリーン アップの経過時間制限] は [成功しなかったジョブのクリーンアップの経過時間制限] の値よりも短く設定します。
成功しなかったジョブのクリーンアップの経過時間制限
このセクションでは、キューのクリーンアップ ジョブを実行して、完了したが成功しなかった状態のジョブ ("失敗 (相互関係のブロックなし) " など) をパージするための経過時間制限 (時間) を設定できます。各ジョブの経過時間は、ジョブが完了した日付と時刻に基づいて判別されます。たとえば、あるジョブが 2007 年 10 月 1 日の 10:40 p.m. に取り消され、キューのクリーンアップ ジョブを 2007 年 10 月 2 日の 11:55 p.m. に実行したとき、そのジョブはパージされます ([成功しなかったジョブのクリーン アップの経過時間制限] の値が既定値の 24 時間だった場合)。
有効な値の範囲は 1 ～ 100000 で、既定値は 168 (7 日) です。
ブックキーピング間隔
キュー システムによって実行される "ブックキーピング" タスクがいくつかあります。たとえば、"休止中" 状態のジョブをアクティブにするタスク、パルスのタイムスタンプを更新するタスク、キューのクリーンアップ ジョブを実行する必要があるかどうかを調べるタスクなどです。この設定によって、これらのタスクが実行される間隔 (ミリ秒) が制御されます。
有効な値の範囲は 500 ～ 300000 で、既定値は 10000 (10 秒) です。
キューのタイムアウト
複数のアプリケーション サーバーを含むファームでは、いずれかのサーバーでキュー NT サービスが失敗しても、ジョブは、キュー NT サービスがアクティブなその他のアプリケーション サーバーに自動的に分散されます。キュー NT サービスは、[キューのタイムアウト] の値 (分) よりも長い間パルスが更新されないとタイムアウトします。すべての Project Web Access データベースでパルスがキューによって更新されるのは、データベースがキューによってアクセスされるときです (たとえば、発行済みデータベースと下書きデータベースでジョブがポーリングされるたびに更新されます)。
有効な値の範囲は 2 ～ 20 で、既定値は 3 です。
[!メモ] [キューのタイムアウト] の値は、常に [ブックキーピング間隔] の 4 倍以上に設定してください。この規則に違反すると、[キューのタイムアウト] の値がブックキーピングの値の 4 倍に自動的に変更されます。
高速ポーリング
高速ポーリングの設定は既定で有効になっています。この設定では、[処理待機中] 状態のすべてのジョブがキューによってできるだけ早く処理されます。ただし、高速ポーリングによってサーバーの状態が不安定になり、キューの処理速度を下げる必要がある場合には、この設定を無効にすることができます。
高速ポーリングを無効にすると、キューは、ジョブを処理するための空きスレッドがあるかどうかを調べます。空きスレッドがあるときは、[処理待機中] 状態のジョブがロードされます。その後、キューはポーリング間隔の待機を行ってから、このプロセスを繰り返します。
高速ポーリングが有効なときには、保留中のジョブがあると、キューはポーリング間隔の待機を行いません。ジョブが処理されるときに、保留中のすべてのジョブの処理がすぐに開始されます。