test

Sun N1 Grid Engine 6.1 管理ガイド

第 4 章 ユーザーアクセスの管理

この章では、ユーザーアカウント、およびそのほかの関連するアカウントの管理について説明します。この章の内容は次のとおりです。

内容説明に加えて、この章では次のタスクの実行方法を詳細に解説します。

ユーザーの設定

Grid Engine システムのユーザーを設定するには、次のタスクを実行する必要があります。

ユーザーアクセスの構成

Grid Engine システムには、次の 4 つのユーザーのカテゴリがあります。

次では、各カテゴリをより詳細に説明します。

管理者アカウントの構成

QMON またはコマンド行から管理者アカウントを構成できます。

QMON を使用した管理者アカウントの構成

「QMON Main Control」ウィンドウで「User Configuration」ボタンをクリックします。「Manager」タブが表示されます。このタブで、どのアカウントが管理コマンドを実行できるかを宣言できます。

このタブには、管理権限を持っていることがすでに宣言されているすべてのアカウントが表示されます。

新しい管理者アカウントを追加するには、管理者アカウントのリストの上にあるフィールドに名前を入力してから、「Add」をクリックするか、Return キーを押します。

管理者アカウントを削除するには、管理者アカウントを選択してから「Delete」をクリックします。

コマンド行からの管理者アカウントの構成

コマンド行から管理者アカウントを構成するには、適切なオプションを使用して、次のコマンドを入力します。


# qconf オプション

次のオプションを使用できます。

オペレータアカウントの構成

QMON またはコマンド行からオペレータアカウントを構成できます。

QMON を使用したオペレータアカウントの構成

「QMON Main Control」ウィンドウで「User Configuration」ボタンをクリックしてから「Operator」タブをクリックします。

「Operator」タブでは、アカウントが管理者アカウントとしても宣言されている場合を除き、どのアカウントに制限された管理権限を付与するかを宣言できます。 「QMON を使用した管理者アカウントの構成」を参照してください。

このタブには、オペレータ権限を持っていることがすでに宣言されているすべてのアカウントが表示されます。

新しいオペレータアカウントを追加するには、オペレータアカウントのリストの上にあるフィールドに名前を入力してから、「Add」をクリックするか、Return キーを押します。

オペレータアカウントを削除するには、オペレータアカウントを選択してから「Delete」をクリックします。

コマンド行からのオペレータアカウントの構成

コマンド行からオペレータアカウントを構成するには、適切なオプションを使用して、次のコマンドを入力します。


# qconf オプション

次のオプションを使用できます。

ユーザーアクセスリストの構成

少なくとも 1 つの発行ホストおよび実行ホストで有効なログイン ID を持つユーザーは、Grid Engine システムを使用できます。ただし、Grid Engine システムの管理者は、一部のキューまたはすべてのキューに対する一部のユーザーのアクセスを禁止できます。また、管理者は特定の並列環境などの機能の使用を制限できます。詳細については、「並列環境の構成」を参照してください。

アクセス権を定義するには、ユーザーアクセスリストを定義する必要があります。ユーザーアクセスリストは、名前付きのユーザーのセットで構成されます。ユーザーアクセスリストの定義には、ユーザー名と UNIX グループ名を使用します。ユーザーアクセスリストは、次の任意の構成で、特定のリソースへのアクセスの拒否や許可の指定に使用されます。

QMON を使用したユーザーアクセスリストの構成

「QMON Main Control」ウィンドウで「User Configuration」ボタンをクリックしてから「Userset」タブをクリックします。「Userset」タブが表示されます。

図 4–1 「Userset」タブ

Grid Engine システムでは、ユーザーセットにはアクセスリストと部署の一方またはその両方を使用できます。「Usersets」リストの下の 2 つのチェックボックスには、選択したユーザーセットの種類が表示されます。このセクションにアクセスリストの詳細が表示されます。部署については、「プロジェクトおよび部署としてのユーザーセットの定義」で説明されています。

「Usersets」リストには、使用可能なすべてのアクセスリストが表示されます。アクセスリストの内容を表示するには、アクセスリストを選択します。内容は「Users/Groups」リストに表示されます。

注 –

グループ名の先頭には @ 記号が付いています。

新しいユーザーセットを追加するには「Add」をクリックします。

既存のユーザーセットを変更するには、ユーザーセットを選択してから「Modify」をクリックします。

ユーザーセットを削除するには、ユーザーセットを選択してから「Delete」をクリックします。

「Add」または「Modify」をクリックすると、「Access List Definition」ダイアログボックスが表示されます。

図 4–2 「Access List Definition」ダイアログボックス

新しいアクセスリストの定義を追加するには、「Userset Name」フィールドにアクセスリストの名前を入力します。既存のアクセスリストを変更している場合は、その名前が「Userset Name」フィールドに表示されます。

アクセスリストに新しいユーザーまたはグループを追加するには、「User/Group」フィールドにユーザー名またはグループ名を入力します。必ず、グループ名の先頭には @ 記号を付けてください。

「Users/Groups」リストには、現在定義されているすべてのユーザーとグループが表示されます。

「Users/Groups」リストからユーザーまたはグループを削除するには、ユーザーまたはグループを選択してから、ゴミ箱のアイコンをクリックします。

変更を保存して、ダイアログボックスを閉じるには、「OK」をクリックします。変更を保存せずにダイアログボックスを閉じるには、「Cancel」をクリックします。

コマンド行からのユーザーアクセスリストの構成

コマンド行からユーザーアクセスリストを構成するには、適切なオプションを使用して、次のコマンドを入力します。


# qconf オプション

次のオプションを使用できます。

プロジェクトおよび部署としてのユーザーセットの定義

ユーザーセットは、Grid Engine システムのプロジェクトと部署の定義にも使用できます。詳細については、「プロジェクトの定義」を参照してください。

部署は、機能ポリシーと優先ポリシーの構成に使用します。ユーザーは 1 つの部署のみのメンバーになることができるのに対し、1 人のユーザーを複数のアクセスリストに含めることができるという点において、部署はアクセスリストと異なります。詳細については、「機能ポリシーの構成」および 「優先ポリシーの構成」を参照してください。

ユーザーセットが部署であることは、図 4–1 と図 4–2 に示す「Department」フラグで示されます。ユーザーセットは、同時に部署とアクセスリストの両方として定義できます。ただし、複数の部署にユーザーを登録できないという制限が適用されます。

ユーザーの構成

ユーザーに共有ベース、機能、または優先ポリシーを定義する前には、ユーザー名を宣言する必要があります。「QMON を使用したポリシーに基づくリソース管理の構成」を参照してください。

ポリシーを定義する前に明示的にユーザー名を宣言したくない場合、Grid Engine システムでは、定義済みのデフォルト値に基づいて、自動的にユーザーを作成できます。自動的にユーザーを作成することで、多くのユーザーを抱えるサイトの管理上の負担を大幅に軽減できます。

システムにユーザーを自動的に作成させるには、「Cluster Settings」ダイアログボックスの「Enforce User」パラメータを「Auto」に設定します。自動的に作成されるユーザーのデフォルト値を設定するには、「Cluster Settings」ダイアログボックスで、次の「Automatic User Defaults」の値を指定します。

クラスタ構成の詳細については、「基本クラスタ構成」を参照してください。

QMON を使用したユーザーオブジェクトの構成

「QMON Main Control」ウィンドウで「User Configuration」ボタンをクリックしてから「User」タブをクリックします。「User」タブは次の図のようになっています。

新しいユーザーを追加するには、「User」リスト上のフィールドにユーザー名を入力してから、「Add」をクリックするか Return キーを押します。

ユーザーを削除するには、「User」リストでユーザー名を選択してから「Delete」をクリックします。

「Delete Time」カラムは読み取り専用です。このカラムには、自動的に作成されたユーザーが Grid Engine システムから削除される時間が表示されます。ゼロは、そのユーザーが削除されないことを示します。

各ユーザーにはデフォルトのプロジェクトを割り当てることができます。ユーザーが、アクセスできる別のプロジェクトを要求する場合を除き、ユーザーが発行する各ジョブにはデフォルトのプロジェクトが関連付けられます。詳細については、「プロジェクトの定義」を参照してください。

デフォルトのプロジェクトを割り当てるには、ユーザーを選択してから、「Default Project」カラムヘッダーをクリックします。「Project Selection」ダイアログボックスが表示されます。

選択状態のユーザーエントリのプロジェクトを選択します。

デフォルトのプロジェクトを割り当て、ダイアログボックスを閉じるには、「OK」をクリックします。デフォルトのプロジェクトを割り当てることなくダイアログボックスを閉じるには、「Cancel」をクリックします。

コマンド行からのユーザーオブジェクトの構成

コマンド行からユーザーオブジェクトを構成するには、適切なオプションを使用して、次のコマンドを入力します。


# qconf オプション

次のオプションを使用できます。

プロジェクトの定義

プロジェクトは、複数のユーザーの共同計算タスクをまとめる手段となります。またプロジェクトは、そのようなプロジェクトに属するすべてのジョブに対してリソース使用ポリシーを定義します。

プロジェクトは、次の 3 つのスケジューリングポリシーの領域で使用されます。

これらの 3 つのポリシーでプロジェクトを使用するには、前もってプロジェクトを宣言する必要があります。

Grid Engine システムの管理者は、プロジェクトに名前を付け、いくつかの属性を設定することによってプロジェクトを定義します。Grid Engine のユーザーは、ジョブの発行時に、ジョブをプロジェクトに関連付けることができます。共有ベース、機能、優先チケットのプロジェクトの配分に応じて、プロジェクトへのジョブの関連付けは、ジョブの振り分けに影響します。

QMON を使用したプロジェクトの定義

Grid Engine システムの管理者は、「Project Configuration」ダイアログボックスを使用して、プロジェクトを定義し、定義を更新することができます。

プロジェクトを定義するには、「QMON Main Control」ウィンドウで「Project Configuration」ボタンをクリックします。 「Project Configuration」ダイアログボックスが表示されます。

図 4–3 「Project Configuration」ダイアログボックス

現在定義されているプロジェクトは、「Projects」リストに表示されます。

選択したプロジェクトのプロジェクト定義が「Configuration」の下に表示されます。

プロジェクトをただちに削除するには、プロジェクトを選択してから「Delete」をクリックします。

新しいプロジェクトを追加するには「Add」をクリックします。プロジェクトを変更するには、プロジェクトを選択してから「Modify」をクリックします。「Add」または「Modify」をクリックすると、「Add/Modify Project」ダイアログボックスが開きます。

選択したプロジェクトの名前が「Name」フィールドに表示されます。プロジェクトにより、プロジェクトへのアクセスが許可または拒否されているユーザーのアクセスリストが定義されます。

「User Lists」の下のアクセスリストに含まれているユーザーは、プロジェクトにアクセスするアクセス権を持っています。「Xuser Lists」の下のアクセスリストに含まれているユーザーは、プロジェクトへのアクセスを拒否されます。詳細については「ユーザーの構成」を参照してください。

両方のリストが空である場合、すべてのユーザーがプロジェクトにアクセスできます。「User Lists」と「Xuser Lists」の両方に関連付けられている、異なるアクセスリストに含まれるユーザーは、プロジェクトへのアクセスを拒否されます。

「User Lists」または「Xuser Lists」にアクセスリストを追加したり、いずれかのリストからアクセスリストを削除することができます。このためには、「User Lists」または「Xuser Lists」の右側のボタンをクリックします。

「Select Access Lists」ダイアログボックスが表示されます。

「Select Access Lists」ダイアログボックスには、「Available Access Lists」の下で現在定義されているすべてのアクセスリストが表示されます。ダイアログボックスの「Chosen Access Lists」の下には、関連付けられているリストが表示されます。一方のリストでアクセスリストを選択できます。赤い矢印を使用すると、一方のリストからもう一方のリストにアクセスリストを起動できます。

変更を保存するには「OK」をクリックし、ダイアログ ボックスを閉じます。変更を保存せずにダイアログボックスを閉じるには、「Cancel」をクリックします。

コマンド行からのプロジェクトの定義

コマンド行からプロジェクトを構成するには、適切なオプションを使用して、次のコマンドを入力します。


# qconf オプション

次のオプションを使用できます。

パスの別名設定の使用

Solaris などのネットワーク UNIX 環境では、ユーザーがいくつかのマシンに同じホームディレクトリ (あるいはその一部) を持つことがよくあります。たとえば、ディレクトリが NFS でアクセス可能になっている場合などです。しかし、すべてのマシンでホームディレクトリのパスが完全には同じでないことがあります。

たとえば NFS と オートマウンタで使用可能なユーザーのホームディレクトリを考えてみます。ユーザーが NFS サーバー上に /home/foo というホームディレクトリを持っている場合、オートマウンタを実行する適切にインストールされたすべての NFS クライアント上では、このパスでこのホームディレクトリはアクセスできます。しかし、クライアントの /home/foo は、/tmp_mnt/home/foo へのシンボリックリンクにすぎません。オートマウンタがディレクトリを物理的にマウントしている NFS サーバー上の実際の場所は、/tmp_mnt/home/foo です。

クライアントホスト上のユーザーが qsub -cwd コマンドを使用してホームディレクトリツリー内のある場所からジョブを発行した場合、-cwd フラグは、そのジョブが現在の作業ディレクトリで実行されることを要求します。ただし、実行ホストが NFS サーバーである場合、Grid Engine システムは、そのホストで現在の作業ディレクトリを見つけられない可能性があります。これは、発行ホスト上の現在の作業ディレクトリが、(発行ホスト上の物理的な位置である) /tmp_mnt/home/foo であるためです。このパスは実行ホストに渡されます。ただし、実行ホストが NFS サーバーである場合、物理的なホームディレクトリパスは /home/foo で、/tmp_mnt/home/foo ではないため、パスが解決できません。

そのほか、同じような問題を引き起こすケースとしては、次のような場合があります。

このような問題を防ぐため、Grid Engine ソフトウェアでは、管理者とユーザーがどちらもパス別名設定ファイルを構成できます。このような 2 つのファイルは、次の場所にあります。

パス別名設定ファイルの形式

パス別名設定ファイルは、両方とも同じ形式です。

パス別名設定ファイルの解釈法

    ファイルは、次のように解釈されます。

  1. qsub が物理的な現在の作業ディレクトリのパスを検索したあとで、グローバルパス別名設定ファイルが存在する場合は、そのファイルが読み取られます。ユーザーパス別名設定ファイルは、グローバルファイルの最後に付加されているかのように、あとで読み取られます。

  2. 無視されないファイルは、ファイルの先頭から1 行ずつ読み取られます。必要に応じて、それらの行により指定された置換内容が格納されます。

    置換内容が保存されるのは、次の条件がいずれも真である場合のみです。

    • 発行ホストの文字列が、qsub コマンドが実行されるホストに一致する。

    • ソースパスが、すでに格納されている現在の作業ディレクトリまたはソースパス置換の先頭部分の構成要素になっている。

  3. 両方のファイルが読み取られると、格納されているパス別名設定情報が、発行されたジョブとともに実行ホストに渡されます。

  4. 実行ホストで、別名設定情報が評価されます。実行ホストの文字列が実行ホストに一致する場合は、現在の作業ディレクトリの先頭部分が、ソースパス置換により置き換えられます。この場合、現在の作業ディレクトリ文字列が変更されます。以降のパス別名は、適用されるためには、置換された作業ディレクトリパスに一致する必要があります。

例 4–1 は、上記の NFS オートマウンタの問題が、別名設定ファイルエントリを使用してどのように解決できるかを示す例です。

例 4–1 パス別名設定ファイルの例


# cluster global path aliases file
# src-path  subm-host   exec-host   dest-path
/tmp_mnt/   *           *           /

デフォルト要求の構成

通常、バッチジョブは、要求プロファイルを基にキューに割り当てられます。ユーザーは、特定のジョブに対して要求プロファイルを定義します。ユーザーは、ジョブを正しく実行するために満たされなければならない要求のセットを組み立てます。スケジューラは、このジョブに関する要求のセットを満たすキューだけを考慮します。

ユーザーがジョブに関する要求を指定しない場合、スケジューラは、ユーザーがアクセス可能なあらゆるキューを考慮します。この場合、キューがアクセス可能であること以外の制約はありません。ただし、Grid Engine ソフトウェアでは、ユーザーがリソース要求を明示的に指定しなくてもジョブのリソース要求を定義するデフォルト要求を構成することができます。

デフォルト要求は、クラスタのユーザー全員にグローバルに構成することも、任意のユーザーに対して個人用として構成することもできます。デフォルト要求の構成は、デフォルト要求ファイルに格納されます。グローバル要求ファイルは sge-root/cell /common/sge_request にあります。ユーザー別の要求ファイルは、ユーザーのホームディレクトリまたは現在の作業ディレクトリのいずれかに置くことができます。 作業ディレクトリは、qsub コマンドが実行される場所です。ユーザー別の要求ファイルは、.sge_request と呼ばれます。

    これらのファイルが存在する場合は、あらゆるジョブでその評価が行われます。評価の順序は次のとおりです。

  1. グローバルデフォルト要求ファイル

  2. ユーザーのホームディレクトリにあるユーザー別デフォルト要求ファイル

  3. 現在の作業ディレクトリにあるユーザー別デフォルト要求ファイル

注 –

ジョブスクリプトまたは qsub コマンドで指定された要求は、デフォルト要求ファイルの要求より優先されます。ジョブに対する明示的なリソース要求方法についての詳細は、『Sun N1 Grid Engine 6.1 ユーザーズガイド』の第 3 章「ジョブの発行」を参照してください。

(以前の要求の指定を破棄する) qsub -clear コマンドを使用することで、Grid Engine システムがデフォルト要求ファイルを使用しないようにすることができます。

デフォルト要求ファイルの形式

ローカルおよびグローバル両方のデフォルト要求ファイルの形式は次のようになります。

あるユーザーのローカルのデフォルト要求ファイルが例 4–2 のスクリプト、test.sh と同じ構成であると仮定します。

例 4–2 デフォルト要求ファイルの例


# Local Default Request File
# exec job on a sun4 queue offering 5h cpu
-l arch=solaris64,s_cpu=5:0:0
# exec job in current working dir
-cwd

このスクリプトを実行するには、ユーザーは次のコマンドを入力します。


% qsub test.sh

次のように、ユーザーが直接コマンド行ですべての qsub オプションを指定した場合、test.sh スクリプトを実行した結果と同じになります。


% qsub -l arch=solaris64,s_cpu=5:0:0 -cwd test.sh
注 –

qsub を使用して発行したバッチジョブ同様、qsh を使用して発行した対話形式のジョブでもデフォルト要求ファイルは考慮されます。QMON を使用して発行した対話形式またはバッチジョブでも、これらの要求ファイルが考慮されます。