システムの動作

Grid Engine システムは次のすべてを実行します。

• 外部からのジョブを受け付けます。ジョブとは、ユーザーによるコンピュータリソースの要求です。

• ジョブが実行できるようになるまで、ジョブを保留領域に保管します。

• ジョブを保留領域から実行デバイスに送信します。

• 実行中のジョブを管理します。

• ジョブの完了時にジョブの実行レコードを記録します。

リソースを要求に対応させる

たとえば、大都市にある「マネーセンター」としての大手銀行を想像してください。銀行のロビーでは多数の顧客がサービスを受ける順番を待っています。顧客にはそれぞれ別の用事があります。ある顧客は、口座から少額のお金を引き出そうとしています。このすぐあとに入ってきた顧客は、銀行の投資スペシャリストと会う約束があります。この女性は、複雑な投機を始める前にアドバイスを受けたいと考えています。最初の 2 人の前にいる顧客は、彼女の前の 8 人の顧客同様に高額のローンに申し込みたいと考えています。

それぞれ異なるニーズを持つ顧客は、銀行にさまざまなタイプとレベルのサービスを求めています。この日の銀行には、口座からの単純な引き出しを処理できる行員は多数いるかもしれません。しかし、多数のローン申込者に対応するローン担当者は 1 人または 2 人しかいないということも考えられます。別の日には、この反対の状況になることもありえます。

結果、顧客はいたずらにサービスを待つことになります。顧客の多くは、彼らのニーズが即座に認識され、使用可能なリソースと一致させられさえすれば、即座にサービスを受けられるはずです。

Grid Engine システムが銀行の支店長だったならば、サービスは別のやり方で整理されたでしょう。

• 顧客は、銀行のロビーに入る時点で、名前、所属およびサービスニーズを明らかにするように頼まれます。

• 各顧客の到着時間が記録されます。

• ロビーで顧客が提供した情報を基に、銀行は次の顧客にサービスを提供します。

  • ニーズに合ったリソースをすぐに使用できる顧客

  • 優先順位がもっとも高い用件を持つ顧客

  • 一番長くロビーで待っている顧客

• 「Grid Engine システム銀行」では、1 人の銀行員が同時に複数の顧客に対応できることもあります。Grid Engine システムは、もっとも負荷が少なくもっとも適した銀行員に新しい顧客を割り当てようとします。

• 銀行の支店長として、Grid Engine システムは銀行にサービスポリシーを定義させます。一般的なサービスポリシーは、たとえば次のようになります。

  • 利益が大きいので、企業顧客には優先的なサービスを提供します。

  • これまで良いサービスを受けていない特定の顧客グループに対して、十分サービスが提供されることを確認します。

  • 約束のある顧客がタイムリーな対応を受けられるようにします。

  • 銀行役員から直接要請された特定の顧客を優先します。

• このようなポリシーが、Grid Engine システムという支店長により自動的に実行、監視および調整されます。優先アクセスを持つ顧客は、より早くサービスを受けられます。このような顧客には行員がより多くの便宜を図り、この顧客はその支援をほかの顧客と共有するはずです。支店長である Grid Engine は、顧客が待ち状態になっている場合はそれを認識します。支店長は、サービスレベルを調整してすぐに対応し、銀行のサービスポリシーを遵守します。

ジョブとキュー

Grid Engine システムでは、ジョブは銀行の顧客に相当します。ジョブは、ロビーではなくコンピュータの保留領域で待機しています。ジョブにサービスを提供するキューは、銀行員に相当します。銀行の顧客の場合と同じで、使用可能なメモリー、実行速度、使用可能なソフトウェアライセンスなどのニーズといった各ジョブの要件は、それぞれまったく異なります。特定のキューだけが、それに対応サービスを提供できる場合もあります。

たとえば、Grid Engine ソフトウェア は次のように使用可能なリソースとジョブ要件を調整します。

• Grid Engine システムを通してジョブを発行するユーザーは、ジョブの要件プロファイルを宣言します。さらに、システムはユーザーの ID を検索します。システムは、ユーザーのプロジェクトまたはユーザーグループへの所属も検索します。ユーザーがジョブを発行した時間も保存されます。

• キューが新しいジョブを実行できるようになると、Grid Engine システムはそのキューに適したジョブを判断します。システムは、優先順位がもっとも高いジョブまたは待ち時間がもっとも長いジョブを即座に振り分けます。

• キューでは、多数のジョブを同時に実行できます。Grid Engine システム は、負荷がもっとも少なくもっとも適したキューで新しいジョブを開始しようとします。

使用ポリシー

クラスタの管理者は、サイトに適した条件によってカスタマイズされたハイレベルの使用ポリシーを定義できます。次の 4 つの使用ポリシーが使用できます。

• 緊急度。 このポリシーを使用する場合、各ジョブの優先順位の基準は緊急度の値になります。緊急度の値は、ジョブのリソース要件、ジョブの期限指定、およびジョブの実行までの待機時間を元に計算されます。

• 機能。 このポリシーを使用する場合、管理者は特定のユーザーグループやプロジェクトなどへのユーザーまたはジョブの所属によって特別な取り扱いを行うことができます。

• 共有ベース。 このポリシーを使用する場合、サービスのレベルは、割り当てられた共有、その他のユーザーやユーザーグループの共有、ユーザー全員の過去のリソース使用率、およびシステムにおける現在のユーザーの存在によって異なります。

• 優先。このポリシーでは、クラスタ管理者が手動で介入して、ポリシーの自動的な実行を変更する必要があります。

ポリシー管理は、クラスタ内の共有リソースの使用を自動的に管理して、管理目標を最適な形で達成します。優先順位の高いジョブは優先的に振り分けられます。このようなジョブは、ほかのジョブとリソースを争っている場合に、より大きな CPU 共有を取得できます。Grid Engine ソフトウェア は、すべてのジョブの進行状況を監視し、適宜ポリシーで定義されている目標と照らし合わせて、ジョブの相対的な優先順位を調整します。

チケットの使用によるポリシーの管理

機能、共有ベース、および優先ポリシーは、チケットと呼ばれる Grid Engine システムの概念によって定義されます。 チケットは、株式会社の株式保有数に例えることができます。株式保有数が多いと、その株主の重要度は高くなります。株主 A が株主 B の 2 倍の株式を持っている場合、A の投票も B の 2 倍になります。したがって、株主 A は 2 倍重要だということになります。同様に、ジョブのチケット保有数が多いと、そのジョブの重要性は高くなります。ジョブ A がジョブ B の 2 倍のチケットを持っている場合、ジョブ A はジョブ B の 2 倍リソースを使用できます。

ジョブは、 機能、共有ベースおよび優先ポリシーからチケットを検索できます。チケットの合計数および各チケットポリシーから検索された数は、時間と共に変わります。

管理者は、各チケットポリシーに割り当てられるチケット数を全体として管理します。ジョブのチケット割り当てと同じように、この割り当てでは、チケットポリシー同士の相対的な重要性が判断されます。特定のチケットポリシーに割り当てられたチケットプールを通して、管理者は Grid Engine システムを複数の方法で実行できます。たとえば、システムを共有ベースモードだけで実行することもできます。または、90% が共有ベースモードで 10% が機能モードというように、モードを組み合わせてシステムを実行することもできます。

緊急度ポリシーによるジョブ優先順位の割り当て

緊急度ポリシーは、ほかの 2 つのジョブ優先順位指定と組み合わせて使用することができます。

• 機能、共有ベース、および優先ポリシーによって割り当てられるチケットの数

• qsub –p コマンドによって指定される優先順位

ジョブには、次の 3 つを元に計算される緊急度の値を割り当てることができます。

• ジョブのリソース要件

• 実行前にジョブが待機する時間の長さ

• ジョブが実行を終了する時間、つまりジョブの期限

管理者は、これらの各要素の重要性を別々に重み付けして、ジョブ全体の緊急度の値を割り出すことができます。詳細は、『Sun N1 Grid Engine 6.1 管理ガイド』の第 5 章「ポリシーとスケジューラの管理」を参照してください。

図 1–2 に、ポリシー間の相関関係を示します。

図 1–2 Grid Engine システムのポリシー間の関係