---
title: OpenLM LicOps を運用する
description: OpenLM LicOps が保持しているシートを確認し、ジョブが拒否された理由を調べ、解放されなかったシートを返却します。
product: OpenLM Platform
---

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

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

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

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

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

```text
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 から最新の数値を受け取れなくなっています。同期が回復するまで、すべてのリクエストが拒否されます。 |

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

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

次の順序で確認します。

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

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

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

```bash
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 では、アドミッションは投入ホストに、ディスパッチと解放はコントローラーに書き込まれます。 |

シートのリークが頻繁に起きる場合は、手動で解放するのではなく、解放の経路を修正してください。[ワークロードを接続する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/index)を参照してください。

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

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

メンテナンスの前やドレインのために、正常なサーバーを意図的に外すには、[サーバーを配置の対象から外す](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/admission-rules#サーバーを配置の対象から外す)の説明に従って **Keep off a server** のルールを追加します。作業が終わったら、ルールを削除します。

## OpenLM Platform との同期を確認する

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

```bash
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 をデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/deployment#アップグレード)を参照してください。