test

Sun N1 Grid Engine 6.1 管理ガイド

第 6 章 リソース割り当ての管理

この章では、N1 Grid Engine 6.1 ソフトウェアのリソース割り当て機能を使用して、ユーザー、プロジェクト、ホスト、クラスタキュー、並列環境別にリソースを制限する方法を説明します。こうした制限は、ユーザーアクセスリスト、部署、ホストグループを使用して表すことができます。

この章では、次の内容について説明します。

リソース割り当ての概要

ユーザーが使用可能なすべてのリソースを消費しないようにするため、N1 Grid Engine 6.1 ソフトウェアは、グローバル、キュー、またはホスト層で設定可能なコンプレックス属性をサポートしています。この階層型のリソース管理手法は強力ではありますが、ギャップが生じます。多数のさまざまなカスタムリソース、ユーザーグループ、およびプロジェクトで構成される大規模な導入では特に重要な意味を持ちます。リソース割り当て機能は、ボトルネックリソースが不足したときに、あるプロジェクトまたは部署がそのリソースを譲るように制御して、こうした企業環境を管理できるようにすることで、このギャップを埋めます。

リソース割り当て機能によって、数種類のリソース、数種類のリソース消費者、クラスタ内のすべてのジョブ、また消費者の組み合わせに対して制限を適用することができます。この意味では、リソースは N1 Grid Engine 構成で認識されている、定義済みコンプレックス属性のすべてです。コンプレックス属性の詳細は、complex(5) のマニュアルページを参照してください。リソースには、slots、 arch、mem_total、num_proc、swap_total、組み込みリソース、あるいは compiler_license のようなカスタム定義のリソースを指定できます。リソース消費者は、ユーザー、キュー、ホスト、プロジェクト、および並列環境単位になります。

リソース割り当て機能は、消費者が任意の時点で使用可能なリソースを制限する手段を提供します。この制限は、ユーザー、部署、およびプロジェクトに優先順位を付ける間接的な手段になります。ユーザーがリソースを取得する優先順位を直接定義するには、「緊急度ポリシーの構成」および 「共有ベースポリシーの構成」で説明しているリソースの緊急度および共有ベースポリシーを利用します。

N1 Grid Engine 6.1 ソフトウェアを使用してリソースを制限するには、qquota および qconf コマンド、または QMON グラフィカルインタフェースを使用します。詳細は、qquota(1) および qconf(1) のマニュアルページを参照してください。

リソース割り当てセットについて

リソース割り当てセットを使用して、任意のジョブ要求に対して最大リソース消費量を指定することができます。リソース割り当てセットを定義すると、スケジューラはそのセットを利用し、割り当て量の超過がないことに注意しながら、次に実行可能なジョブを選択することができます。リソース割り当て量を設定することの最大の意味は、リソース割り当て量を超えないジョブだけがスケジューリングされて、実行されることです。

リソース割り当てセットでは、特定のジョブ要求に対する最大リソース割り当て量を定義します。構成された規則セットのすべてが、常に適用されます。複数のリソース割り当てセットが定義されている場合は、もっとも制限が厳しいセットが適用されます。リソース割り当てセットはどれも、1 つ以上のリソース割り当て規則で構成されます。これらの規則が順に評価され、特定の要求に合致する最初の規則が使用されます。つまり、リソース割り当てセットの中の 1 つのリソース割り当て規則が特定の要求に対する実効規則になります。

リソース割り当てセットは、次の情報で構成されます。

例 6–1 リソース割り当てセット例

次のリソース割り当てセット例は、user1 と user2 に対して、ホストグループ lx_hosts の各ホストの未使用仮想空間の最大割り当て量を 2 ギガバイトに制限します。

     {
        name         max_virtual_free_on_lx_hosts
        description  "resource quota for virtual_free restriction"
        enabled      true
        limit        users {user1,user2} hosts {@lx_host} to virtual_free=2g
     }

静的リソース割り当てと動的リソース割り当て

リソース割り当て規則では、必ず、使用可能なリソースの最大値を定義します。だいたいの場合、これらは静的であり、一致するすべてのフィルタスコープに対して同じです。いくつかの異なる規則を、異なるスコープに適用することもできますが、それらの規則はほぼ同じです。この場合は、規則を複製する代わりに、動的制限を定義できます。

動的制限では、代数式を使用して規則制限値を導出します。代数式でコンプレックス属性を参照し、その値を使用して制限値を計算することができます。

例 6–2 動的制限例

次は、動的制限の使用例です。ユーザーは、すべての Linux ホストで 1 CPU 当たり 5 つのスロットの使用が許可されます。


limit hosts {@linux_hosts} to slots=$num_proc*5

num_proc の値は、ホスト上のプロセッサ数です。制限は式 $num_proc*5 で求められ、ホストによって異なることがあります。上記の例を展開すると、たとえば次のような制限が考えられます。

num_proc の代わりに、負荷値あるいは消費可能リソースのいずれかとしてホストが認識するほかのコンプレックス属性をすべて使用することができます。

QMON によるリソース割り当ての管理

次のタスクは、QMON グラフィカルインタフェースを使用してリソース割り当て量を設定する例です。

ProcedureQMON を使用してリソース割り当て量を設定する

  1. 「QMON Main Control」ウィンドウで「Resource Quota Configuration」ボタンをクリックします。

  2. テキストフィールドにリソース割り当て情報を入力します。

    次の画面例で示すように、qconf コマンドに対するのと同じ構文を使用してください。

コマンド行からのリソース割り当て利用状況の監視

qquota コマンドを使用して、現在の N1 Grid Engineリソース割り当てに関する情報を表示できます。qquota コマンドは、少なくとも 1 回使用されているか、静的制限を定義した各リソース割り当てを一覧表示します。qquota は、該当するリソース割り当てごとに次の情報を表示します。

qquota コマンドには、特定のホスト、クラスタキュー、プロジェクト、並列環境、リソースまたはユーザーに情報を絞り込むためのオプションがいくつかあります。オプションが使用されなかった場合、qquota は、コマンドの呼び出し元ユーザー名に該当するリソースセットの情報を表示します。詳細は、qquota(1) のマニュアルページを参照してください。

例 6–3 qquota コマンド例

次の例は、ユーザー user1 に該当するリソース割り当てセットの情報を示しています。


$ qquota -u user1
resource quota    limit                filter
--------------------------------------------------------------------------------
maxujobs/1         slots=5/20           -
max_linux/1        slots=5/5            hosts @linux
max_per_host/1     slots=1/2            users user1 hosts host2

コマンド行からのリソース割り当ての設定

qconf コマンドを使用して、リソース割り当てセットおよび規則を追加、変更、削除できます。

qconf の詳細は、 qconf(1) のマニュアルページを参照してください。

例

次の例は、リソース割り当てにさまざまなコマンドを使用する方法を示しています。例 6–4 に示す規則セットが定義している制限は、次のとおりです。

この規則セットを設定するには、次の形式の qconf コマンドを使用します。

複数のユーザーでジョブを発行すると、qstat コマンドは、例 6–5 に示すような情報を出力します。

例 6–4 ルールセット

{
 name maxujobs
 limit users * to slots=20
}

{
 name max_linux
 limit users * hosts @linux to slots=5
}

{
 name max_per_host
 limit users MyUser hosts {@linux} to slots=2
 limit users {*} hosts {@linux} to slots=1
 limit users * hosts * to slots=0
}
例 6–5 qstat の出力


$ qstat
job-ID  prior   name       user       state submit/start at     queue       slots ja-task-ID 
---------------------------------------------------------------------------------------------
     27 0.55500 Sleeper    MyUser     r     02/21/2006 15:53:10 all.q@host1   1        
     29 0.55500 Sleeper    MyUser     r     02/21/2006 15:53:10 all.q@host1   1        
     30 0.55500 Sleeper    MyUser     r     02/21/2006 15:53:10 all.q@host2   1        
     26 0.55500 Sleeper    MyUser     r     02/21/2006 15:53:10 all.q@host2   1        
     28 0.55500 Sleeper    user1      r     02/21/2006 15:53:10 all.q@host2   1
例 6–6 qquota の出力


$ qquota # as user MyUser
resource quota rule    limit                filter
--------------------------------------------------------------------------------
maxujobs/1         slots=5/20           -
max_linux/1        slots=5/5            hosts @linux
max_per_host/1     slots=2/2            users MyUser hosts host2
max_per_host/1     slots=2/2            users MyUser hosts host1

$ qquota -h host2 # as user MyUser
resource quota    limit                filter
--------------------------------------------------------------------------------
maxujobs/1         slots=5/20           -
max_linux/1        slots=5/5            hosts @linux
max_per_host/1     slots=2/2            users MyUser hosts host2

$ qquota -u user1
resource quota    limit                filter
--------------------------------------------------------------------------------
maxujobs/1         slots=5/20           -
max_linux/1        slots=5/5            hosts @linux
max_per_host/1     slots=1/2            users user1 hosts host2

$ qquota -u *
resource quota    limit                filter
--------------------------------------------------------------------------------
maxujobs/1         slots=5/20           -
max_linux/1        slots=5/5            hosts @linux
max_per_host/1     slots=2/2            users MyUser hosts host1
max_per_host/1     slots=2/2            users MyUser hosts host2
max_per_host/1     slots=1/2            users user1 hosts host2

パフォーマンス上の検討事項

効率的な規則セット

キュー内のジョブおよびリソースの処理効率を最大限に高めるには、もっとも厳しい規則を規則セットの先頭に置きます。この仕様に従うと、N1 Grid Engineスケジューラが特に効率的な方法で適切なキューインスタンスの量を絞り込むのに役立ちます。なぜなら、先頭の規則は、同じ規則セット内の後続の規則に影響されることはなく、常にその規則の代表になるためです。

このことを具体的に理解するために、次のような環境を考えてみます。

こうした環境で、次のような規則セットを 1 つ定義したと仮定します。


{
      name         30_for_each_project
      description  "not more than 30 per project"
      enabled      TRUE
      limit projects {*} queues Q001 to F001=30
      limit projects {*} queues Q002 to F002=30
      limit projects {*} queues Q003 to F003=30
      limit projects {*} queues Q004 to F004=30
      limit to F001=0,F002=0,F003=0,F004=0
   }

この 1 つの規則セットは、プロジェクト 1 つ当たりの各管理対象リソースの使用量を 30 に制限し、同時に適格のキュー内のジョブを制限します。この規則は問題なく機能しますが、多数のホストからなる大規模なクラスタでは、ジョブの割り当てに時間がかかる原因になります。

N1 Grid Engineスケジューラが仲介中にできるだけ多くのキューインスタンスを除外できるようにするには、この単一規則セットを 4 つの規則セットに分ける方が優れています。


{
      name         30_for_each_project_in_Q001
      description  "not more than 30 per project of F001 in Q001"
      enabled      TRUE
      limit queues !Q001 to F001=0
      limit projects {*} queues Q001 to F001=30
   }

   {
      name         30_for_each_project_in_Q002
      description  "not more than 30 per project of F002 in Q002"
      enabled      TRUE
      limit queues !Q002 to F002=0
      limit projects {*} queues Q002 to F002=30
   }

   {
      name         30_for_each_project_in_Q003
      description  "not more than 30 per project of F003 in Q003"
      enabled      TRUE
      limit queues !Q003 to F003=0
      limit projects {*} queues Q003 to F003=30
   }

   {
      name         30_for_each_project_in_Q004
      description  "not more than 30 per project of F004 in Q004"
      enabled      TRUE
      limit queues !Q004 to F004=0
      limit projects {*} queues Q004 to F004=30
   }

この 4 つの規則セットは、単一の規則セットと同じプロジェクト単位のリソース割り当て量制限を課します。しかし、4 つの規則セットは、不適切なキューインスタンスが最初にシールドされているため、ずっと効率的に処理できます。この場合、これらのシールドを 1 つのリソース割り当てセットにまとめることはできません。

注 –

前述の例の目的は、リソース 1 つ当たりクラスタキュー 1 つを推奨することではありません。実際は、その逆です。次に示すように、キューを少なくすることで、常にシールドをより少なく、より強力にできます。


  {
      name         30_for_each_project_in_Q001
      description  "not more than 30 per project of F001/F002 in Q001"
      enabled      TRUE
      limit queues !Q001 to F001=0,F002=0
      limit projects {*} queues Q001 to F001=30,F002=30
   }

   {
      name         30_for_each_project_in_Q002
      description  "not more than 30 per project of F003/F004 in Q002"
      enabled      TRUE
      limit queues !Q002 to F003=0,F004=0
      limit projects {*} queues Q002 to F003=30,F004=30
   }

この例では、キューが Q001 〜 Q004 から Q001 〜 Q002 に整理されています。しかし、実際にはこうすることで、クラスタ全体の稼働率とスループットが向上します。