デマンドデリバリ方式による構築例

本節では、デマンドデリバリ方式の負荷分散環境の構築方法を例にそって説明します。

6.7.4.1. 構築例

下の図はデマンドデリバリ機能を用い、リクエストをネットワーク環境下で分散実行する場合のキューの例で す。

図6.5 デマンドデリバリ方式の利用イメージ

ここでは host0 ～ host3 という 4 台のマシンで負荷分散を行うことにします。リクエストは host0 から投入 することにします。また、ここではマシングループを設定しています。host0 ～ host3 は同一グループ内のマ シンで host0 がスケジューラマシンとして機能していることにします。

リクエストはまずデマンドデリバリ用のパイプキュー (LB-PIPE キュー) である pipeL に投入されます。この キューに投入されたリクエストは host1～ host3 のいずれかのマシンに分散して転送されます。

リクエストを受けるキューには透過型のパイプキューを用いています。これはリクエストに設定された資源制 限によって、自動的にLB-BATCH キューを選択して転送するために使います。

LB-BATCH はデマンドデリバリ機能を使用するために通常のバッチキューの代わりに使用します。

それぞれのキューの設定手順について説明していきます。

■LB-PIPE キューの作成

デマンドデリバリ機能の転送元のパイプキューとして pipeL を host0 に作成します。

ここでは同時実行数 (run_limit) は 2 を指定しています。そしてデマンドデリバリ転送用にそのうちの 1 つ を確保 (reserve_run_limit) しています。デマンドデリバリを使用する場合には必ずこの設定を行ってくだ さい。

Mgr: create pipe_queue pipeL priority=10 run_limit=2 \ server=(/usr/lib/nqs/pipeclient) \

destination=(pipeT@host1,pipeT@host2,pipeT@host3) ↵ Mgr: set load_balance pipe_queue pipeL reserve_run_limit=1 ↵ (R12.7以降のWindows版の場合)

Mgr: create pipe_queue pipeL priority=10 run_limit=2 \ destination=(pipeT@host1,pipeT@host2,pipeT@host3) ↵ Mgr: set load_balance pipe_queue pipeL reserve_run_limit=1 ↵

destination の部分は転送先のマシンおよびキューを指定しています。各マシンの転送先キュー pipeT に は、透過型パイプキューを指定してあります。もし、各マシン上に 1 つのバッチキューしか設定しないなら ば直接バッチキューに転送してもかまいません。

なお、キューの状態は作成された段階では DISABLE, STOPPED の状態ですので、次のコマンドでキューを稼 働状態にしてください。（この作業はこの節で作成する全キューについて行ってください。以後この手順は 省略します）

Mgr: enable queue pipeL ↵ Mgr: start queue pipeL ↵

■LB-BATCH キューの作成

デマンドデリバリ機能を用いるバッチキューとして batch1 ～ batch3 を作成します。それぞれ資源制限の異 なるバッチキューにすることにします。このように異なる大きさの資源制限をバッチキューに施すことに よって、リクエストの使用する資源特性にあわせたスケジューリングを行うことが可能になります。

この例では簡略化のためにメモリの使用量についてのみ資源制限を施します。またキューにはその資源量に 応じて、同時実行数を変えてスケジューリングの優劣をつけることにします。

次のように3 つの LB-BATCH キューを作成します。これは host1 ～ host3 でそれぞれ同じように設定して ください。

Mgr: create batch_queue batch1 priority=10 run=3 ↵ Mgr: set load_balance batch_queue batch1 ↵

Mgr: set per_process memory_limit=(1mb) batch1 ↵ Mgr: create batch_queue batch2 priority=10 run=2 ↵ Mgr: set load_balance batch_queue batch2 ↵

Mgr: set per_process memory_limit=(2mb) batch2 ↵ Mgr: create batch_queue batch3 priority=10 run=1 ↵ Mgr: set load_balance batch_queue batch3 ↵

Mgr: set per_process memory_limit=(3mb) batch3 ↵

■透過型パイプキューの作成

上記の複数のバッチキューの 1 つを自動的に選択してリクエストを投入するために透過型パイプキューを用 います。透過型パイプキューの作成は次のように行います。

Mgr: create pipe_queue pipeT priority=10 run_limit=1 \ server=(/usr/lib/nqs/pipeclient) \

destination=(batch1,batch2,batch3) ↵ Mgr: set transparent pipe_queue pipeT ↵ (R12.7以降のWindows版の場合)

Mgr: create pipe_queue pipeT priority=10 run_limit=1 \ destination=(batch1,batch2,batch3) ↵

Mgr: set transparent pipe_queue pipeT ↵

destination は転送先バッチキューを指定しています。ここでは転送先として指定する順序がたいへん重要 になってきます。透過型パイプキューはリクエストの転送をこの destination で指定された順序に従って試 みていきます。

この例の場合、リクエストに設定された資源制限値とキューに設定された資源制限値を比較して、そのリク エストの制限値の方が小さいか、指定された値がなければそのバッチキューに投入されます。

つまり、投入を試すキューの順序は制限の厳しいバッチキューから行わなければいけないということです。

■マシングループ・スケジューラマシンの作成

最後にマシングループの設定を行います。これは LB-PIPE で負荷分散性能を向上させるために必要な設定で す。次のコマンドで host0 ～ host3 に同じように設定してください。

Mgr: set machine_group=(host0, host1, host2, host3) ↵

上記の設定で、 host0 ～ host3 のマシンがグループを形成していることになります。この場合、最初に指定 した host0 がスケジューラマシンとして機能することになります。

以上で、上図に示したようなキュー作成が完了しました。次のように qstat(1) コマンドを用いてキュー構成 を確認してください。下記の出力結果は、実際の表示内容を省略してあります。

マシン host0 のキューを表示します。

# qstat -x ↵

pipeL@host0; type=PIPE; [ENABLED, INACTIVE]; pri=10

0 depart; 0 route; 0 queued; 0 wait; 0 hold; 0 arrive;

Run_limit = 2;

Reserved_run_limit = 1;

Unrestricted access Load_balance

Queue server: /usr/lib/nqs/lbpipeclient

Destset = {pipeT@host1, pipeT@host2, pipeT@host3};

マシン host1 のキューを表示します。

host2,host3 についても同様な表示が得られます。

# qstat -x ↵

pipeT@host1; type=PIPE; [ENABLED, INACTIVE]; pri=10

0 depart; 0 route; 0 queued; 0 wait; 0 hold; 0 arrive;

Run_limit = 1;

Unrestricted access Transparent

Queue server: /usr/lib/nqs/pipeclient

Destset = {batch1@host1, batch2@host1, batch3@host1};

batch1@host1; type=BATCH; [ENABLED, INACTIVE]; pri=10

0 exit; 0 run; 0 stage; 0 queued; 0 wait; 0 hold; 0 arrive;

Run_limit = 3;

Unrestricted access Load_balance

Per-process memory size limit = 1 megabytes

batch2@host1; type=BATCH; [ENABLED, INACTIVE]; pri=10

0 exit; 0 run; 0 stage; 0 queued; 0 wait; 0 hold; 0 arrive;

Run_limit = 2;

Unrestricted access

Load_balance

Per-process memory size limit = 2 megabytes

batch3@host1; type=BATCH; [ENABLED, INACTIVE]; pri=10

0 exit; 0 run; 0 stage; 0 queued; 0 wait; 0 hold; 0 arrive;

Run_limit = 1;

Unrestricted access Load_balance

Per-process memory size limit = 3 megabytes

6.7.4.2. リクエストの投入と操作

それでは前節で作成したキューに、リクエストを投入してみましょう。 pipeL に 3 個のリクエストを投入して みます。ただし、 3 つめのリクエストには 2.5MB のメモリサイズ制限を指定します。

# qsub -q pipeL job1 ↵

Request 1.host0 submitted to queue: pipeL.

# qsub -q pipeL job2 ↵

Request 2.host0 submitted to queue: pipeL.

# qsub -lm 2.5mb -q pipeL job3 ↵

Request 3.host0 submitted to queue: pipeL.

では、投入したリクエストが、どこで実行されているか確認してみます。リクエストの確認には qstatr(1) コ マンドを使います。ただし、負荷分散の場合リクエストがどこのマシンに転送されるかわからないので、

qstatr(1) コマンドに -t オプションをつけてください。

そうすると自動的に転送先のマシンを探し出して状態を表示します。ただし、以下の表示では投入したリクエ ストがまだ実行状態であると仮定しています。

# qstatr -t 2 ↵

=================================================

NQS (R11.10) BATCH REQUEST HOST: host1

=================================================

REQUEST ID NAME OWNER QUEUE PRI NICE STT PGRP R 1.host0 job1 root batch1 31 0 RUN -

---=================================================

NQS (R11.10) BATCH REQUEST HOST: host2

=================================================

REQUEST ID NAME OWNER QUEUE PRI NICE STT PGRP R 2.host0 job2 root batch1 31 0 RUN -

---=================================================

NQS (R11.10) BATCH REQUEST HOST: host3

=================================================

REQUEST ID NAME OWNER QUEUE PRI NICE STT PGRP R 3.host0 job3 root batch3 31 0 RUN - ---この場合、リクエストはうまく分散され実行されているようです。

負荷分散パイプキューに投入したリクエストは、投入後どこのマシンに行くかわかりません。しかし、どこの マシンに転送されたかは投入元のマシンに記録されています。そしてリクエストを操作する各コマンドはこの 記録を読んで、そのマシンに操作要求を転送します。

上記例での 1 つめのリクエストをキャンセルしたい場合には、 host0 で次のように入力します。

# qdel -k 1.host0 ↵

これで、 1.host0 がどのマシンに転送されていてもキャンセルすることができます。