ワークロードを接続する

LicOps が実行の可否を判断するのは、LicOps に問い合わせたジョブだけです。ライセンスを使うすべてのジョブは、投入時の admit（許可）、開始時の dispatch（ディスパッチ）、終了時の release（解放）という 3 つのリクエストを送る必要があり、環境内の何かがそれらのリクエストを送らなければなりません。ジョブを実行する環境に合った連携方法を選択してください。

ジョブの実行環境	使用するもの	リクエストを送るもの
Slurm	Slurm アダプター	投入ノード上の sbatch ラッパーと、コントローラーの prolog および epilog フック。
IBM Spectrum LSF	LSF アダプター	投入ホスト上の esub と、キューの PRE_EXEC および POST_EXEC フック。
Kubernetes	Kubernetes ワークロード	アノテーションを付けた Pod の場合はアドミッション Webhook、またはジョブ自体。
その他	アドミッション API を呼び出す	独自のラッパー、スクリプト、またはサービス。

OpenLM は、Slurm と LSF のアダプターに加えて、ラッパースクリプト、Python クライアント、API の OpenAPI 記述、Kubernetes のサンプルを含むインテグレーションキットを提供しています。入手するには OpenLM にお問い合わせください。

その他のスケジューラーでは、投入時のフックからアドミッション API を呼び出します。アドミッション API を呼び出すを参照してください。

接続する前に

ワークロードを接続する前に、LicOps のアドレスを確認し、ライセンス名を正しく指定し、LicOps に到達できない場合の動作を決めます。

LicOps のアドレスを確認する

どの連携にも、ポート 8100 の LicOps アドミッション API というアドレスが 1 つ必要です。呼び出し元ごとのアドレスを次の表に示します。

呼び出し元	アドレス
Slurm または LSF のアダプター	http://<licops-host>:8100/api/v1/admission-controller
同じ Kubernetes クラスター内のワークロード	http://openlm-router-api.<namespace>.svc:8100
独自のツール	http://<licops-host>:8100。パスは API リファレンスを参照してください。

アドレスを確認するには、自分のワークステーションからではなく、呼び出しを行うホストから次のコマンドを実行します。

curl -s -o /dev/null -w '%{http_code}\n' http://<licops-host>:8100/api/v1/status

200 が返れば、アドレスは正しいです。ポート 30001 は API ではありません。このポートは FlexLM プロトコルを使うため、HTTP リクエストを送ると応答が返らないか、失敗します。

正確なライセンス名を使う

各リクエストは、MLM と MATLAB のように、ベンダーデーモンとフィーチャーでプールを指定します。名前は大文字・小文字も含めて、プールと完全に一致する必要があります。mlm や Matlab を指定したリクエストはどのプールにも一致せず、NoServerAvailable として拒否されます。これは入力ミスではなく、障害のように見えます。OpenLM LicOps を設定するの説明に従って、GET /api/v1/stats から名前をコピーしてください。

Acrobat Pro のように、スペースを含むフィーチャーもあります。API には実際のスペースを含めて送信します。Slurm のライセンスマップはそれ自体がスペース区切りのため、スペースを %20 と記述します。アダプターは LicOps を呼び出す前に、これをスペースに戻します。

どのような終わり方でも解放する

ジョブのシートは、release が届くか、セッションがタイムアウトするまでカウントされ続けます。失敗したジョブ、キャンセルされたジョブ、タイムアウトしたジョブも、成功したジョブと同じく確実に解放しなければなりません。そうしないと、誰も使っていないのにシートが占有されたままになり、ほかのジョブが拒否されます。スケジューラーのアダプターは、ジョブがどうなっても必ずスケジューラーが実行するフックから解放します。独自の連携を作成する場合は、finally ブロック、trap、または必ず実行されるフックから解放してください。

LicOps に到達できない場合の動作を決める

LicOps が停止しているか応答が遅い場合、アダプターはシートを要求できません。そのときのアダプターの動作は、admit と dispatch でそれぞれ個別に選択します。2 つの選択肢を次の表で比較します。

項目	フェイルオープン: それでもジョブを実行する	フェイルクローズ: ジョブを保留または拒否する
LicOps の停止中	ジョブは流れ続けます。	ジョブは止まります。
リスク	シート数を超えるジョブが開始し、一部はチェックアウトで失敗します。	LicOps が復旧するまで、クラスターがアイドル状態になります。
適している対象	シートがすでに許可されている dispatch と、ライセンス数に余裕のあるツール	スループットよりもコンプライアンスが重要なライセンスの admit

Slurm と LSF のアダプターは、OL_FAIL_MODE_ADMIT と OL_FAIL_MODE_DISPATCH を読み取ります。値はそれぞれ open または closed で、どちらも既定値は open です。インテグレーションキットのラッパースクリプトには独自の設定 OL_FAIL_MODE があり、既定値は closed です。また、これらはリクエストを OL_TIMEOUT 秒（既定値は 2 秒）で打ち切ってからフェイルモードを適用するため、LicOps の応答が遅くても、ジョブの投入が長く止まることはありません。どちらにするかを意図して決め、選んだ内容を記録しておいてください。

LicOps にサーバーも選ばせるかを決める

ジョブを開始してよいかどうかは、常に LicOps が判断します。その後、ジョブが LicOps の選んだサーバーからチェックアウトするかどうかは、チェックアウトがどのようにライセンスサーバーに届くかによって決まります。連携方法ごとのアプリケーションのチェックアウト先を次の表に示します。

連携方法	アプリケーションのチェックアウト先
Slurm または LSF のアダプター（既定）	アプリケーション自身のライセンス設定にあるサーバーからチェックアウトします。LicOps はジョブの実行可否を判断しますが、チェックアウト先は制御しないため、Cascade across servers in priority order のようにサーバーを選ぶルールを設定しても、チェックアウト先は変わりません。
Slurm または LSF のアダプター（チェックアウトルーティングあり）	LicOps のリッスンポート 30001 を経由します。このポートが、LicOps がそのジョブのために選んだサーバーへチェックアウトを渡します。
Kubernetes のアドミッション Webhook	Pod 内のサイドカーを経由します。サイドカーが同じ方法でチェックアウトを LicOps に渡します。
API を呼び出す Kubernetes のジョブまたは独自の連携	dispatch が返す licenseFile を LM_LICENSE_FILE に設定した場合は、dispatch が指定したサーバーからチェックアウトします。

まずはアドミッションのみで始めるのが簡単で、それだけでもシートのないジョブの開始を防げます。配置ルールをチェックアウト自体にも適用したい場合に、チェックアウトルーティングを追加します。

チェックアウトルーティングでは、LicOps は各チェックアウトを、送信元ノードの IP アドレスで識別します。計算ノードは、間にアドレス変換を挟まずに、LicOps ホストへ直接接続できる必要があります。ノードの既存のライセンス設定は LicOps のエントリの後ろにそのまま残るため、LicOps に到達できない場合、アプリケーションは通常のサーバーにフォールバックします。