Sun N1 Grid Engine 6.1 ユーザーズガイド

第 1 章 N1^TM Grid Engine 6.1 ソフトウェアの概要

この章では、N1 Grid Engine 6.1 ソフトウェア (Grid Engine システムともいう) を実行する、ネットワークに接続されたコンピュータホストシステムの背景について説明します。この章の内容は、次のとおりです。

グリッドコンピューティングおよび N1 Grid Engine 製品については、次の YouTube Web サイトにも優れた紹介があります。Introduction to Grid Engine。

グリッドコンピューティングとは

グリッドは、タスクを実行するコンピューティングリソースの集合です。もっとも簡単な形式のグリッドの場合、ユーザーには、強力な分散リソースへの単一のアクセスポイントを提供する大きなシステムのように見えます。この節の後半で説明するより複雑な形式のグリッドは、多くのアクセスポイントをユーザーに提供できます。いずれの場合でも、ユーザーはグリッドを 1 つのコンピュータリソースとして扱います。N1 Grid Engine 6.1 ソフトウェア (Grid Engine ソフトウェア) などのリソース管理ソフトウェアは、ユーザーが発行したジョブを受け付けます。ソフトウェアは、リソース管理ポリシーによって、ジョブがグリッド内の適切なシステムで実行されるようにスケジューリングを行います。ユーザーは、ジョブの実行場所を気にせずに、一度に数百万ものジョブを発行できます。

同じグリッドというものは 1 つもありません。また、あるサイズのグリッドですべての状況に対応することはできません。グリッドには次の 3 つの主要クラスがあり、単一システムから、数千のプロセッサを使用するスーパーコンピュータクラスの計算ファームまでをカバーしています。

クラスタグリッドは、もっとも単純なクラスです。クラスタグリッドは、連動して動作するコンピュータホストの集合で構成されています。クラスタグリッドは、単一のプロジェクトまたは部署のユーザーに単一のアクセスポイントを提供します。
キャンパスグリッドでは、組織内の複数のプロジェクトまたは部署がコンピューティングリソースを共有できます。組織はキャンパスグリッドを使用して、周期的な業務プロセスからレンダリング、データマイニングなどのさまざまなタスクを処理できます。
グローバルグリッドは、組織の境界を越えて非常に大きな仮想システムを作成するキャンパスグリッドの集合です。ユーザーは、自分自身の組織内で使用できるリソースをはるかに超える計算能力を利用できます。

図 1–1 に 3 つのグリッドクラスを示します。クラスタグリッドでは、ユーザーのジョブはクラスタ内の 1 システムのみによって処理されます。ただし、そのユーザーのクラスタグリッドはより複雑なキャンパスグリッドの一部の場合もあります。そしてキャンパスグリッドはもっとも大きいグローバルグリッドの一部の場合があります。このような場合、ユーザーのジョブは世界中のどこにあるメンバー実行ホストでも処理できます。

図 1–1 3 つのグリッドクラス

N1 Grid Engine 6.1 ソフトウェアは、キャンパスグリッドに必要なパワーと柔軟性を提供します。本製品を使用するとキャンパスグリッドの作成へのスムーズな移行をより簡単に実現できるので、既存のクラスタグリッドにとって有利です。Grid Engine システムは、キャンパスのすべての既存のクラスタグリッドを統合して、この移行を実行します。さらに、Grid Engine システムはグリッドコンピューティングモデルに初めて移行する企業にとっても最適です。

Grid Engine ソフトウェアは、組織の技術スタッフと管理スタッフが策定する企業のリソースポリシーを基に、処理能力の提供を調整します。Grid Engine システムは、これらのポリシーを使用してキャンパスグリッド内の使用可能なコンピュータリソースを調べます。システムはこれらのリソースを収集したあと、リソースの割り当てと提供を自動的に行い、キャンパスグリッド間の使用率を最適化します。

キャンパスグリッド内での協調を実現するために、グリッドを使用するプロジェクトの所有者は次の操作を実行する必要があります。

ポリシー間の折衝
固有のプロジェクト要件に対する、手動による優先のためのポリシーの柔軟性の確保
自動的なポリシーの監視および実施

Grid Engine ソフトウェアは、コンピュータリソースの利用で競合する多くの部署とプロジェクトのエンタイトルメントを調整できます。

リソースとポリシーの管理による作業負荷の管理

Grid Engine システムは、異機種システムが混在する分散コンピューティング環境向けの高度なリソース管理ツールです。作業負荷管理とは、共有リソースの使用を制御して、生産性、適時性、サービスレベルなどの企業目標を最適な形で達成することです。作業負荷管理は、リソースの管理とポリシーの管理によって実現されます。サイトでは使用量とスループットが最大になるようにシステムが構成されますが、システムはさまざまなレベルの適時性と重要性をサポートしています。たとえば、ジョブの期限は適時性の例です。また、重要性の例にはジョブの優先順位やユーザーの共有などがあります。

Grid Engine ソフトウェアは、複数の共有リソースで構成される UNIX 環境向けの高度なリソース管理とポリシー管理を提供します。Grid Engine システムは、次の主要機能において標準的な負荷管理ツールより優れています。

Grid Engine ソフトウェアによるサイト固有の管理ポリシーの実行を可能にする画期的な動的スケジューリングおよびリソース管理
スケジューラに最新のジョブレベルのリソース消費およびシステム負荷情報を提供するためのパフォーマンスデータの動的な収集
証明セキュリティープロトコル (CSP) ベースの暗号化による拡張セキュリティー。よりセキュアなこのシステムのメッセージは、平文で転送されるのではなく、秘密鍵で暗号化されます。
生産性、適時性、およびサービスレベルなどの企業目標の定義と実行を実現するハイレベルなポリシー管理

Grid Engine ソフトウェアは、高度なコンピュータ処理が必要なタスクをグリッドに発行し、関連作業負荷の透過的な分散を行う方法をユーザーに提供します。ユーザーは、バッチジョブ、対話型ジョブ、および並列ジョブをグリッドに発行できます。本ソフトウェアは、管理者向けにジョブの監視と制御を行う包括的なツールを提供します。

本製品は、チェックポイント設定プログラムもサポートしています。チェックポイント設定ジョブは、ユーザーの介入なしに負荷の要求を基に、ワークステーション間で移行されます。

システムの動作

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 システムのポリシー間の関係

Grid Engine システムコンポーネント

次の節では、もっとも重要な Grid Engine システムコンポーネントの機能について説明します。

ホスト

Grid Engine システムの基本的なホストは、次の 4 種類です。

マスターホスト
実行ホスト
管理ホスト
発行ホスト

マスターホスト

マスターホストは、クラスタ全体の動作の中心に位置づけられます。マスターホストでは、マスターデーモン sge_qmaster とスケジューラデーモン sge_schedd が実行されます。この 2 つのデーモンは、キューやジョブなどのすべての Grid Engine システムコンポーネントを制御します。デーモンは、コンポーネントのステータスやユーザーのアクセス権などに関するテーブルを維持しています。

デフォルトでは、マスターホストが管理ホストでもあり発行ホストでもあります。

実行ホスト

実行ホストは、ジョブの実行権を持つシステムです。したがって、実行ホストにはキューインスタンスが関連付けられています。実行ホストは、実行デーモン sge_execd を実行します。

管理ホスト

管理ホストは、Grid Engine システムの管理処理をすべて実行する権限を持つホストです。

発行ホスト

発行ホストでユーザーが発行および制御できるのは、バッチジョブだけです。特に、発行ホストにログインしたユーザーは、qsub コマンドでジョブを発行し、qstat コマンドでジョブステータスを監視し、Grid Engine システムの OSF/1 Motif グラフィカルユーザーインタフェースである QMON を使用できます。QMON については、「Grid Engine システムのグラフィカルユーザーインタフェースである QMON」に説明があります。

注 –

システムは、複数の種類のホストとして機能できます。

デーモン

3 つのデーモンが Grid Engine システムの機能を提供します。

`sge_qmaster` – マスターデーモン

クラスタの管理およびスケジューリング処理の中心となる sge_qmaster は、ホスト、キュー、ジョブ、システム負荷、およびユーザーの権限についてのテーブルを維持します。sge_qmaster は、sge_schedd からスケジューリングに関する決定を受け取り、適切な実行ホストの sge_execd に処理を要求します。

`sge_schedd` – スケジューラデーモン

スケジューリングデーモンは、sge_qmaster によってクラスタのステータスの最新ビューを維持します。スケジューリングデーモンは、スケジューリングに関する次の決定を行います。

どのジョブがどのキューに割り振られるか
共有、優先順位、または期限を維持するためにどのようにジョブを再整理し、優先順位を再設定するか

デーモンはこれらの決定を sge_qmaster に転送し、sge_qmaster は、要求された処理を開始します。

`sge_execd` – 実行デーモン

実行デーモンは、ホスト上のキューインスタンスおよびこれらのキューインスタンス内のジョブの実行を担当しています。実行デーモンは、定期的にジョブステータスまたはホストの負荷などの情報を sge_qmaster に転送します。

キュー

キューは、1 台以上のホストで同時に実行できるジョブのクラス用のコンテナです。キューは、ジョブを移行できるかどうかなどの特定のジョブの属性を決定します。実行ジョブはその有効期間中キューに関連付けられています。キューに関連付けられていることで、ジョブで発生する事象の一部が影響を受けます。たとえば、キューが一時停止されると、そのキューに関連付けたすべてのジョブも一時停止されます。

ジョブをキューに直接発行する必要はありません。ジョブの要件プロファイルだけを指定すればすみます。プロファイルには、メモリー、オペレーティングシステム、使用可能なソフトウェアなどの要件が含まれます。Grid Engine ソフトウェアは、適切なキューと実行負荷が少ない適切なホストにジョブを自動的に割り振ります。指定したキューにジョブを発行すると、ジョブはそのキューと結合されます。結果として、Grid Engine システムデーモンは、負荷が少なくより適したデバイスを選択できなくなります。

キューは 1 台のホストに存在する場合と、複数のホストに及ぶ場合があります。このため、Grid Engine システムのキューはクラスタキュー とも呼ばれます。ユーザーと管理者は、クラスタキューを使用すると、1 つのキュー構成によって実行ホストのクラスタを同時に実行できます。クラスタキューに関連付けられた各ホストは、クラスタキューからそれぞれのキューインスタンスを受け取ります。

クライアントコマンド

コマンド行ユーザーインタフェースは、次の作業を行う補助的なプログラム (コマンド) セットです。

キューの管理
ジョブの発行と削除
ジョブステータスのチェック
キューとジョブの一時停止と有効化

Grid Engine システムは、次の補助プログラムセットを提供します。

qacct –クラスタログファイルから任意のアカウンティング情報を抽出します。
qalter – 発行済みで保留中となっているジョブの属性を変更します。
qconf – クラスタ構成とキュー構成用のユーザーインタフェースを提供します。
qdel – ジョブまたはジョブのサブセットに信号を送信する方法をユーザー、オペレータ、または管理者に提供します。
qhold – 発行済みのジョブを実行しないようにします。
qhost – 実行ホストのステータス情報を表示します。
qlogin – より負荷が少なく適切なホストを自動的に選択して、telnet などのログインセッションを開始します。
qmake – 標準 UNIX の make 機能の代わりです。qmake は、 make の各手順を適切なマシンのクラスタ間で分散する make の機能を拡張したものです。
qmod – 所有者がキューを一時停止したり、有効にしたりできるようにします。このキューと関連付けられている現在アクティブなプロセスすべても信号で伝えられます。
qmon – X Windows Motif コマンドインタフェースと監視機能を提供します。
qresub – 実行中または保留中のジョブをコピーして、新しいジョブを作成します。
qrls – qhold などで割り当てられた待機状態からジョブを解放します。
qrsh – 次のようなさまざまな目的に使用できます。
- Grid Engine システムによる対話型アプリケーションのリモート実行。 qrsh は、標準の UNIX 機能である rsh と互換性があります
- 実行時に端末 I/O と端末コントロールをサポートするバッチジョブの発行。端末 I/O には標準出力、標準エラーおよび標準入力が含まれます
- バッチジョブの終了までアクティブな発行クライアントの提供
- Grid Engine ソフトウェアが制御する並列ジョブのタスクのリモート実行
qselect – 指定された選択基準に対応するキュー名のリストの印刷。qselect の出力は、通常選択されたキューセットに処理を適用するほかの Grid Engine システムコマンドに送信されます。
qsh – 負荷の少ないホストの xterm 内で対話型シェルを開く。このシェル内では全種類の対話型ジョブを実行できます。
qstat – クラスタに関連付けられたすべてのジョブとキューのステータスの提供
qsub – バッチジョブを Grid Engine システムに発行するためのユーザーインタフェース
qtcsh – 一般的に使用される UNIX C シェル (csh) の派生コマンド tcsh の、完全な互換性を持つ代用コマンド。 qtcsh は、指定アプリケーションの実行を適切で負荷が少ないホストに Grid Engine ソフトウェアを通して透過的に分散するという拡張機能を持ったコマンドシェルを提供します。

Grid Engine システムのグラフィカルユーザーインタフェースである `QMON`

ユーザーは、グラフィカルユーザーインタフェース (GUI) ツールである QMON を使用して、ほとんどの Grid Engine システムタスクを実行できます。図 1–3 に、ユーザーと管理者の機能の両方を開始することが多い「QMON Main Control」ウィンドウを示します。「Main Control」ウィンドウの各アイコンは、クリックするとさまざまなタスクを開始できる GUI ボタンです。機能の説明にもなっているボタンの名前を見るには、ボタンの上にポインタを置きます。

第 1 章 N1TM Grid Engine 6.1 ソフトウェアの概要