OpenLM LicOps を運用する

LicOps が保持している内容の確認、ジョブが拒否された理由の調査、解放されなかったシートの返却、サーバーを配置の対象から外す作業には、このページのタスクを使います。日常の運用で、LicOps に手をかける必要はありません。LicOps はシート数を OpenLM Platform と同期させ、ジョブが終了するとシートを返却します。

コマンドは、LicOps ホスト、または管理用ネットワーク上のマシンから実行します。Kubernetes では、先に openlm-router-api Service への kubectl port-forward を開始します。

LicOps が保持している内容を確認する

すべてのプールとサーバーを、現在のシート数とともに表示するには、次のコマンドを実行します。

curl -s http://localhost:8100/api/v1/stats \
  | jq -r '.[] | [.vendor, .feature, .host, .total, .used, .reserved, .free, .isHealthy] | @tsv'

MLM       MATLAB  lic01.example.com  50  31  2  17  true
MLM       MATLAB  lic02.example.com  50  28  0  22  true
adskflex  86000ACD_2024_0F  lic03.example.com  25  25  0  0  true

reserved 列は、LicOps がライセンスサーバー自身の数値に上乗せする分で、LicOps が許可したもののまだチェックアウトされていないシートを表します。この値はジョブが許可されると増え、ジョブがチェックアウトするか終了すると減ります。reserved の数が増える一方の場合は、ジョブがシートを解放していません。解放されなかったシートを返却するを参照してください。

used は OpenLM Platform から取得されるため、その鮮度は OpenLM Platform がそのライセンスサーバーを最後に読み取った時点に依存します。

リクエストが拒否された理由を調べる

拒否されたアドミッションには reason が含まれます。まずこれを確認します。理由と確認する場所を次の表に示します。

理由	確認する場所
NoServerAvailable	まずベンダー名またはフィーチャー名を確認します。どのプールにも一致しない名前は、障害とまったく同じように見えます。/api/v1/stats と比較してください。次に、プール内のすべてのサーバーが異常になっていないかを確認します。
NoCapacity	実際の不足です。対象となるどのサーバーにも十分な空きシートがありません。シートが空いているように見える場合は、Keep off a server などのルールが選択肢を狭めている可能性があります。
ConstraintBlocked	予約が原因です。空きシートのあるサーバーが Maximum seats に達しているか、現在の期間中はブロックされています。
PolicyDenied	Deny the request を指定したアドミッションルールが一致しました。
StaleSnapshot	LicOps が OpenLM Platform から最新の数値を受け取れなくなっています。同期が回復するまで、すべてのリクエストが拒否されます。

拒否の背景を詳しく把握するには、可用性レポートを確認します。このレポートには、停止中のものも含めてすべてのプールとすべてのサーバーが、アドミッションで使われる正確な数値とともに表示されます。次のコマンドを実行します。

curl -s http://localhost:8100/api/v1/admission-controller/availability | jq .

次の順序で確認します。

1. coldStart と staleForAdmission。 どちらかが true の場合、LicOps は自身の数値を信頼できないため、回復するまでレポートの他の項目は意味を持ちません。トラブルシューティングを参照してください。
2. プール。 ジョブが要求した vendor と feature を探します。プールが見つからない場合は、ジョブが指定した名前がどのプールにも一致していません。
3. プールの largestAdmittableRequest。LicOps が現時点で許可できる最大のリクエストです。1 つのジョブのシートは 1 台のサーバーから取得する必要があるため、プール全体の free が十分に大きく見えても、これより多くのシートを要求するジョブは拒否されます。
4. 各サーバー。 isHealthy: false のサーバーは候補から外れます。free が 0 未満の場合は、LicOps がサーバーの保有数を超えて許可したことを意味します。通常は、解放されなかったシートが原因です。headroom が 0 の制約は、上限に達した予約を表します。

解放されなかったシートを返却する

ノードのクラッシュやエピローグが実行されなかった場合など、ジョブが解放を行わずに終了すると、LicOps はセッションがタイムアウトするまでそのシートを数え続けます。タイムアウトを変更していない場合、開始しなかったジョブでは 15 分、開始したジョブでは 2 時間です。シートを早く返却するには、セッションを手動で解放します。

curl -X POST http://localhost:8100/api/v1/admission-controller/release \
  -H 'Content-Type: application/json' \
  -d '{"sessionId": "<session-id>"}'

解放は常に成功します。"state": "Released" は、シートが返却されたことを意味します。AlreadyClosed または NotFound は、返却するものがなかったことを意味します。

ジョブのセッション ID は、次の場所で確認できます。

スケジューラー	セッション ID の場所
Slurm	ジョブのコメント。scontrol show job <job-id> | grep -i comment を実行すると olsid=<session-id> が表示されます。複数のライセンスを使うジョブには、ライセンスごとのセッション ID が | で区切られて記録されます。それぞれを解放してください。
LSF	ジョブの環境変数 OL_SESSION_ID。
両方	アダプターのログ /var/log/openlm/hpc-adapter.log。すべてのアドミッションがセッション ID とともに記録されます。Slurm では、アドミッションは投入ホストに、ディスパッチと解放はコントローラーに書き込まれます。

シートのリークが頻繁に起きる場合は、手動で解放するのではなく、解放の経路を修正してください。ワークロードを接続するを参照してください。

ライセンスサーバーを配置の対象から外す

ライセンスサーバーが停止すると、OpenLM Platform がそのサーバーを異常と報告します。LicOps は、その報告から約 10 秒以内にそのサーバーへのシートの配置を停止します。操作は何も必要ありません。そのサーバーで許可されたものの、まだ開始していないジョブは、開始時に同じプール内の正常なサーバーに移されます。

メンテナンスの前やドレインのために、正常なサーバーを意図的に外すには、サーバーを配置の対象から外すの説明に従って Keep off a server のルールを追加します。作業が終わったら、ルールを削除します。

OpenLM Platform との同期を確認する

LicOps は、OpenLM Platform から届く最新の数値に依存しています。数値が届き続けていることを確認するには、次のコマンドを実行します。

curl -s http://localhost:8100/api/v1/admission-controller/availability \
  | jq '{lastPlatformSyncTime, lastReconcileTime, coldStart, staleForAdmission}'

通常、どちらの時刻も数秒前のものです。時刻が進まなくなると、約 30 秒後に LicOps はすべてのリクエストを StaleSnapshot で拒否し始めます。構成の同期は、フェイルオーバー用の Router と同様に、GET /api/v1/status の configurationManagement.lastSync で別途報告されます。

LicOps を再起動またはアップグレードする

開いているセッションは Redis に、構成は OpenLM Platform に保存されているため、再起動してもどちらも失われません。LicOps が停止している間、スケジューラーのアダプターは選択したフェイルモードを適用します。起動後の最初の数秒間は、LicOps が OpenLM Platform に追いつくまで、アドミッションは 503 を返します。アップグレードについては、OpenLM LicOps をデプロイするを参照してください。