--- title: OpenLM LicOps description: OpenLM LicOps は、ライセンスのシートが空いている場合にのみ HPC または Kubernetes のジョブを許可し、どのライセンスサーバーからチェックアウトするかをジョブに伝えます。 product: OpenLM Platform --- 空いているシートの数を超えるライセンス対象ジョブをクラスターが開始すると、競争に負けたジョブはノードに到達した後で失敗するか、ライセンスを待つ間ずっとノードを占有します。OpenLM LicOps は、ジョブが開始する前にシートの空きを確認します。ジョブが投入されると、スケジューラーが LicOps にシートを要求し、LicOps が可否を回答します。ジョブが開始すると、LicOps はどのライセンスサーバーからチェックアウトするかをジョブに伝えます。 :::note[OpenLM LicOps は早期提供です] OpenLM LicOps は早期提供の段階にあります。OpenLM Platform の **Products** の **Downloads** には表示されません。[OpenLM LicOps をデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/deployment) で説明するコンテナーイメージからデプロイし、スケジューラーアダプターは OpenLM が提供します。本番環境への展開を計画する前に、OpenLM にお問い合わせください。 ::: ## Router か LicOps か、どちらかを選ぶ OpenLM は、2 つの製品を 1 つのプログラムである OpenLM Router として提供しています。初回起動時に Router に指定するモードによって、どちらの製品として動作するかが決まります。 | | OpenLM Router (フェイルオーバー) | OpenLM LicOps | | --- | --- | --- | | 対象 | FlexLM クライアントが 1 台のライセンスサーバーを使用する、ワークステーション上のエンジニア | 多数のライセンス対象ジョブを一度に開始する HPC クラスターと Kubernetes ワークロード | | 機能 | 障害が発生したプライマリサーバーから、そのバックアップへクライアントを移します | シートが空いている場合にのみジョブを許可し、プール (同じベンダーとフィーチャーを提供するサーバー群) からそのジョブのライセンスサーバーを選びます | | ライセンスサーバー | アプリケーションごとにプライマリ 1 台と任意のバックアップ 1 台 | ベンダーとフィーチャーごとに任意の台数のサーバー | | OpenLM Platform で設定する内容 | ポートマッピング | アドミッションルールと予約 | | Router のモード | `basic` | `loadBalancer` | OpenLM アカウントごとに、フェイルオーバーと LicOps のどちらか一方を選択します。両方は使用できません。OpenLM Platform の **LicOps Configuration** は、一度に 1 つの Router でのみ動作し、それは最後に報告した Router です。ワークステーションのユーザー向けにフェイルオーバーが必要な場合は、代わりに [OpenLM Router](https://www.openlm.com/documentation/ja/cloud/deployment-operations/router/) を参照してください。 ## ジョブが LicOps を通過する流れ LicOps は、各ジョブのライフサイクルの中で 3 つのリクエストに応答します。スケジューラーアダプターを使う場合は、アダプターがこれらのリクエストを送信します。独自の統合では、統合自身がリクエストを送信します。 1. **Admit** (許可): ジョブの投入時。アダプターは、1 つのベンダーとフィーチャーについて必要なシート数を要求します。LicOps は **Admit** または **Deny** で応答します。拒否されたジョブはキューに入りません。 2. **Dispatch** (ディスパッチ): ジョブがノードで開始するとき。LicOps は、チェックアウト先のライセンスサーバーを `port@host` 形式で示します。予定していたサーバーが許可の後に障害を起こしていた場合、LicOps は同じフィーチャーを提供する正常なサーバーにシートを移します。 3. **Release** (解放): ジョブが終了するとき。ジョブが成功した場合も、失敗した場合も、キャンセルされた場合も含みます。シートはプールに戻ります。 LicOps は各ジョブを *セッション* として追跡します。セッションは、呼び出し元が生成して 3 つのリクエストすべてに付けて送るセッション ID で識別されます。 ```mermaid sequenceDiagram participant A as Scheduler adapter participant L as LicOps participant P as OpenLM Platform P-->>L: Seat counts and server health, about every 10 seconds A->>L: Admit: 1 seat of MLM:MATLAB L-->>A: Admit A->>L: Dispatch: the job starts on a node L-->>A: 27000@lic01.example.com Note over A: The application checks out from lic01 A->>L: Release: the job ends ``` *プール* とは、1 つのベンダーデーモンとフィーチャーを提供するすべてのライセンスサーバーのことで、`VENDOR:FEATURE` と表記します (例: `MLM:MATLAB`)。リクエストではサーバーではなく必ずプールを指定し、サーバーは LicOps が選択します。 ### シート数の取得元 LicOps は、ライセンスサーバー、その合計シート数、使用中のシート数、各サーバーのヘルスを、約 10 秒ごとに OpenLM Platform から取得します。Platform はこれらの情報を各ライセンスサーバー上の OpenLM Broker から得ているため、LicOps が使用できるのは、Broker が Platform にレポートしているサーバーだけです。LicOps はこれに、LicOps だけが把握している情報、つまり許可済みでまだチェックアウトされていないシートを加えます。LicOps は、空きシート数を次のように計算します。 ```text free = total − in use − admitted, not yet checked out ``` この最後の項によって、最後の 1 シートが二重に割り当てられるのを防ぎます。ライセンスマネージャーは開始処理中のジョブを認識できないため、LicOps がなければ、1 つの空きシートに対して 2 つのジョブが両方とも許可される可能性があります。LicOps はリクエストごとにこの計算全体を 1 ステップで評価し、約 10 秒ごとに Platform の数値と照合してカウントを補正します。 ライセンスサーバー側では何も確保されません。LicOps はライセンスをチェックアウトせず、FlexLM で予約することもありません。アプリケーションは、dispatch が示すサーバー、またはすでに使用しているサーバーから、現在とまったく同じ方法でチェックアウトします。 ### LicOps がサーバーを選ぶ仕組み ルールがない場合、LicOps は許可した各シートを、プール内で最も負荷の低い正常なサーバーに配置します。特定のチームのためにサーバーを確保する、安価なサーバーから先に埋める、ジョブを均等に分散する、チェックアウトの集中を抑えるなど、この動作を変更するには、OpenLM Platform でアドミッションルールを作成します。[アドミッションルールで配置を制御する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/admission-rules) を参照してください。特定の時間帯に LicOps があるサーバーで割り当てるシート数に上限を設けるには、[スケジュールでシート数を制限する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/reservations) を参照してください。 その後アプリケーションが LicOps の選んだサーバーからチェックアウトするかどうかは、ワークロードの接続方法によって決まります。[LicOps にサーバーの選択も任せるかどうかを決める](https://www.openlm.com/documentation/ja/cloud/deployment-operations/integrations/index#licops-にサーバーも選ばせるかを決める) を参照してください。 ## デプロイするもの LicOps は、自社のネットワーク内でスケジューラーと並べて実行します。LicOps が行うのは OpenLM Platform への送信方向の接続だけで、Platform 側から LicOps への接続が開かれることはありません。 デプロイするコンポーネントを次の表に示します。 | コンポーネント | 実行場所 | 役割 | | --- | --- | --- | | LicOps モードの Router | Docker を備えた Linux ホスト、または Kubernetes クラスター (MongoDB と Redis を併用) | admit、dispatch、release のリクエストに応答します。ブラウザー用のページから OpenLM Platform に接続します。 | | Slurm または LSF のアダプター | スケジューラーのコントローラーと投入ホスト | ライセンスを使用するすべてのジョブについて、投入時、開始時、終了時に 3 つのリクエストを送信します。OpenLM が提供します。 | | Kubernetes アドミッション Webhook | Kubernetes クラスター | アノテーションを付けた Pod について 3 つのリクエストを送信します。任意です。 | | OpenLM Broker | プール内の各ライセンスサーバー | サーバー、そのライセンス、ヘルスを OpenLM Platform にレポートします。すでに実行している場合もあります。 | アドミッションルールと予約は、OpenLM Platform の **LicOps Configuration** で定義します。Router は、フェイルオーバー用の Router がポートマッピングを取得するのと同じ方法で、約 10 秒ごとにこれらを取得します。 ## LicOps の用語 LicOps を扱うときに目にする名前を次の表に示します。 | 名前 | 説明 | | --- | --- | | OpenLM Router | LicOps が動作するプログラム。LicOps モードでは、ステータスに `Load balancer mode active` と表示され、モードは `loadBalancer` です。 | | **LicOps Configuration** | LicOps の設定を確認し、アドミッションルールと予約を定義する、**Licenses and Features** にある OpenLM Platform のアプリ。フェイルオーバー用の OpenLM Router も設定し、その場合は **Port Mappings** が表示されます。 | | プール | 1 つのベンダーデーモンとフィーチャー (`MLM:MATLAB` など) を提供するすべてのライセンスサーバー。 | | セッション | admit から release までの、1 つのジョブのシート。呼び出し元が生成するセッション ID で識別されます。 | | リッスンポート | LicOps ホストのポート `30001`。チェックアウトを LicOps 経由でルーティングする場合にのみ関係します。 | | Router UI | LicOps ホスト上のブラウザー用ページで、ここで LicOps を Platform に接続します。 | | Client Type `Router` | LicOps がサインインに使う ID クライアントの種類。フェイルオーバー用の Router と同じです。 | | OpenLM Broker | 各ライセンスサーバー上の OpenLM コンポーネントで、サーバー、そのライセンス、ヘルスを Platform にレポートします。 | ## 現在の制限事項 LicOps には次の制限事項があります。 - **FlexLM でのみ検証済み**: プールとチェックアウトの対象は、FlexLM のベンダーデーモンとフィーチャーです。 - **シートはカウントされるだけで、確保されない**: LicOps を経由せずに (たとえばワークステーションから) ライセンスをチェックアウトしたユーザーも、シートを 1 つ使用します。LicOps がそのシートを認識するのは、Platform が次に使用中の数値を報告したときであり、それより前ではありません。 - **予約はシート数に上限を設けるだけで、シートは確保されない**: 予約は、LicOps があるサーバーで割り当てるシート数を制限します。ライセンスサーバー上でシートを取り置くことはありません。[スケジュールでシート数を制限する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/reservations) を参照してください。 - **LSF のサポートはアーリーアクセス**: 本番で利用する前に、本番以外のキューでアダプターを検証してください。LSF の各ジョブが要求できるのは 1 つのベンダーとフィーチャーだけですが、Slurm アダプターは 1 つのジョブに対して複数のライセンスを許可できます。 - **Kubernetes のインターセプトチェーンはプレリリース版**: サイドカーと init コンテナーのイメージは開発ビルドです。Kubernetes のジョブから API を直接呼び出す方法には影響しません。 - **ポート 8100 と 8101 は管理用のインターフェイス**: これらへのアクセスは管理用ネットワークとジョブを投入するホストからだけに許可し、インターネットには公開しないでください。公開するのは、クライアントが使用するライセンスポートだけにしてください。[システム要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/system-requirements) を参照してください。 ## このセクションの内容 各ページを順番に進めてください。 1. [システム要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/system-requirements): LicOps に必要なライセンス、ホスト、データストア、ネットワーク、Platform へのアクセス。 2. [OpenLM LicOps をデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/deployment): Docker Compose を使って Router を LicOps モードで実行します。Kubernetes にデプロイする場合は、[Kubernetes にデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/deploy-kubernetes) を参照してください。 3. [OpenLM LicOps を設定する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/configuration): LicOps を Platform に接続し、プールが認識されていることを確認します。 4. [アドミッションルールで配置を制御する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/admission-rules): 任意: 各ジョブをどのサーバーに配置するかを決めます。 5. [スケジュールでシート数を制限する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/reservations): 任意: 指定した時間帯に LicOps が割り当てるシート数を制限します。 6. [ワークロードを接続する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/integrations/index): Slurm、LSF、Kubernetes、または独自のツールを LicOps に接続します。 7. [OpenLM LicOps を運用する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/operations): LicOps が保持している内容を確認し、ジョブが拒否された理由を調べます。 8. [トラブルシューティング](https://www.openlm.com/documentation/ja/cloud/deployment-operations/troubleshooting): よくある症状とその意味。 9. [API リファレンス](https://www.openlm.com/documentation/ja/cloud/deployment-operations/reference): すべてのリクエスト、レスポンス、拒否理由。