OpenLM LicOps
空いているシートの数を超えるライセンス対象ジョブをクラスターが開始すると、競争に負けたジョブはノードに到達した後で失敗するか、ライセンスを待つ間ずっとノードを占有します。OpenLM LicOps は、ジョブが開始する前にシートの空きを確認します。ジョブが投入されると、スケジューラーが LicOps にシートを要求し、LicOps が可否を回答します。ジョブが開始すると、LicOps はどのライセンスサーバーからチェックアウトするかをジョブに伝えます。
OpenLM LicOps は早期提供の段階にあります。OpenLM Platform の Products の Downloads には表示されません。OpenLM LicOps をデプロイする で説明するコンテナーイメージからデプロイし、スケジューラーアダプターは 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 を参照してください。
ジョブが LicOps を通過する流れ
LicOps は、各ジョブのライフサイクルの中で 3 つのリクエストに応答します。スケジューラーアダプターを使う場合は、アダプターがこれらのリクエストを送信します。独自の統合では、統合自身がリクエストを送信します。
- Admit (許可): ジョブの投入時。アダプターは、1 つのベンダーとフィーチャーについて必要なシート数を要求します。LicOps は Admit または Deny で応答します。拒否されたジョブはキューに入りません。
- Dispatch (ディスパッチ): ジョブがノードで開始するとき。LicOps は、チェックアウト先のライセンスサーバーを
port@host形式で示します。予定していたサーバーが許可の後に障害を起こしていた場合、LicOps は同じフィーチャーを提供する正常なサーバーにシートを移します。 - Release (解放): ジョブが終了するとき。ジョブが成功した場合も、失敗した場合も、キャンセルされた場合も含みます。シートはプールに戻ります。
LicOps は各ジョブを セッション として追跡します。セッションは、呼び出し元が生成して 3 つのリクエストすべてに付けて送るセッション ID で識別されます。
プール とは、1 つのベンダーデーモンとフィーチャーを提供するすべてのライセンスサーバーのことで、VENDOR:FEATURE と表記します (例: MLM:MATLAB)。リクエストではサーバーではなく必ずプールを指定し、サーバーは LicOps が選択します。
シート数の取得元
LicOps は、ライセンスサーバー、その合計シート数、使用中のシート数、各サーバーのヘルスを、約 10 秒ごとに OpenLM Platform から取得します。Platform はこれらの情報を各ライセンスサーバー上の OpenLM Broker から得ているため、LicOps が使用できるのは、Broker が Platform にレポートしているサーバーだけです。LicOps はこれに、LicOps だけが把握している情報、つまり許可済みでまだチェックアウトされていないシートを加えます。LicOps は、空きシート数を次のように計算します。
free = total − in use − admitted, not yet checked out
この最後の項によって、最後の 1 シートが二重に割り当てられるのを防ぎます。ライセンスマネージャーは開始処理中のジョブを認識できないため、LicOps がなければ、1 つの空きシートに対して 2 つのジョブが両方とも許可される可能性があります。LicOps はリクエストごとにこの計算全体を 1 ステップで評価し、約 10 秒ごとに Platform の数値と照合してカウントを補正します。
ライセンスサーバー側では何も確保されません。LicOps はライセンスをチェックアウトせず、FlexLM で予約することもありません。アプリケーションは、dispatch が示すサーバー、またはすでに使用しているサーバーから、現在とまったく同じ方法でチェックアウトします。
LicOps がサーバーを選ぶ仕組み
ルールがない場合、LicOps は許可した各シートを、プール内で最も負荷の低い正常なサーバーに配置します。特定のチームのためにサーバーを確保する、安価なサーバーから先に埋める、ジョブを均等に分散する、チェックアウトの集中を抑えるなど、この動作を変更するには、OpenLM Platform でアドミッションルールを作成します。アドミッションルールで配置を制御する を参照してください。特定の時間帯に LicOps があるサーバーで割り当てるシート数に上限を設けるには、スケジュールでシート数を制限する を参照してください。
その後アプリケーションが LicOps の選んだサーバーからチェックアウトするかどうかは、ワークロードの接続方法によって決まります。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 があるサーバーで割り当てるシート数を制限します。ライセンスサーバー上でシートを取り置くことはありません。スケジュールでシート数を制限する を参照してください。
- LSF のサポートはアーリーアクセス: 本番で利用する前に、本番以外のキューでアダプターを検証してください。LSF の各ジョブが要求できるのは 1 つのベンダーとフィーチャーだけですが、Slurm アダプターは 1 つのジョブに対して複数のライセンスを許可できます。
- Kubernetes のインターセプトチェーンはプレリリース版: サイドカーと init コンテナーのイメージは開発ビルドです。Kubernetes のジョブから API を直接呼び出す方法には影響しません。
- ポート 8100 と 8101 は管理用のインターフェイス: これらへのアクセスは管理用ネットワークとジョブを投入するホストからだけに許可し、インターネットには公開しないでください。公開するのは、クライアントが使用するライセンスポートだけにしてください。システム要件 を参照してください。
このセクションの内容
各ページを順番に進めてください。
- システム要件: LicOps に必要なライセンス、ホスト、データストア、ネットワーク、Platform へのアクセス。
- OpenLM LicOps をデプロイする: Docker Compose を使って Router を LicOps モードで実行します。Kubernetes にデプロイする場合は、Kubernetes にデプロイする を参照してください。
- OpenLM LicOps を設定する: LicOps を Platform に接続し、プールが認識されていることを確認します。
- アドミッションルールで配置を制御する: 任意: 各ジョブをどのサーバーに配置するかを決めます。
- スケジュールでシート数を制限する: 任意: 指定した時間帯に LicOps が割り当てるシート数を制限します。
- ワークロードを接続する: Slurm、LSF、Kubernetes、または独自のツールを LicOps に接続します。
- OpenLM LicOps を運用する: LicOps が保持している内容を確認し、ジョブが拒否された理由を調べます。
- トラブルシューティング: よくある症状とその意味。
- API リファレンス: すべてのリクエスト、レスポンス、拒否理由。
ドキュメントチームは、大規模言語モデルを使ってこのページを下書きすることがあります。公開前に、テクニカルライターがすべてのページをレビューし、製品と照らし合わせて検証します。最終的な判断は人間が行います。