システム要件

LicOps は、LicOps モードの OpenLM Router として、MongoDB および Redis とともに自社のネットワーク内で実行されます。デプロイする前に、以下を確認してください。

OpenLM ライセンス

OpenLM ライセンスに LicOps が含まれている必要があります。OpenLM Platform で https://<your-platform>/licensemanager/#/license-summary のライセンス概要を開き、LicOps のフィーチャーがあることを確認します。Router フェイルオーバー用のライセンスには LicOps は含まれません。また、LicOps が登場する前に発行されたライセンスには、どちらも含まれていません。

このフィーチャーがない場合でも LicOps Configuration は開きますが、各ページには内容の代わりに次の通知が表示され、保存は拒否されます。

LicOps License is not available with current openLM License, please contact with support team for more information.

通知の末尾には、OpenLM ライセンス情報へのリンクがあります。Platform がライセンスを確認するために OpenLM LicenseManager に到達できない場合は、代わりに次の通知が表示され、確認が成功するまで構成は読み取り専用になります。

The LicOps license check could not be completed: the OpenLM LicenseManager is not reachable. Configuration is read-only until it answers.

すでに構成済みの LicOps デプロイは、このフィーチャーがなくても動作し続けます。拒否されるのは、構成とルールの変更だけです。ライセンスを再発行するには、OpenLM にお問い合わせください。

OpenLM から提供されるもの

OpenLM が提供するものと、それぞれの入手方法を次の表に示します。

項目	内容	入手方法
コンテナーイメージ	Router のイメージ、および Kubernetes の場合はアドミッション Webhook のイメージ	パブリックレジストリから匿名でプルします。OpenLM LicOps をデプロイする を参照してください。
ライセンス上の LicOps	OpenLM ライセンスの LicOps フィーチャー	OpenLM にお問い合わせください。
HPC アダプターパッケージ	Slurm と LSF のアダプター、およびそのインストーラー	OpenLM にお問い合わせください。
インテグレーションキット	ライセンスマップツール、ラッパースクリプト、Python クライアント、OpenAPI 記述、Kubernetes のサンプル	OpenLM にお問い合わせください。
Helm チャート	Kubernetes 用の openlm-router チャートと openlm-gke チャート	OpenLM にお問い合わせください。

プラットフォームを選択する

実行環境ごとの LicOps のデプロイ方法と、得られるものを次の表に示します。

実行環境	LicOps のデプロイ方法	得られるもの
Slurm、LSF、または独自のスケジューラー	OpenLM LicOps をデプロイする の手順に従い、Linux ホスト上の Docker Compose でデプロイします	スケジューラーアダプターが呼び出すアドミッション API。
Kubernetes ワークロード	Kubernetes にデプロイする の手順に従い、Helm でデプロイします	アドミッション API に加えて、アノテーションを付けた Pod にライセンスを割り当てる任意のアドミッション Webhook。Webhook は Kubernetes 上でのみ動作します。

Docker Compose のホスト要件

次の要件を確認します。

• 64 ビットの Linux ホスト。Windows ホストはサポートされていません。
• Docker Compose v2 プラグインを備えた Docker Engine 20.10 以降。docker compose version で確認します。
• イメージは linux/amd64 と linux/arm64 の両方で公開されています。

CPU、メモリ、ディスクの要件を次の表に示します。

リソース	最小	推奨
CPU	2 vCPU	4 vCPU
メモリ	2 GB	4 GB
ディスク	10 GB	20 GB 以上

Kubernetes の要件

次の要件を確認します。

• Helm 3。
• 任意で、クラスターのイングレスコントローラーとして Traefik を使用し、その IngressRoute、IngressRouteTCP、Middleware の各リソースタイプがインストールされていること。Traefik を有効にする場合、Router のチャートはエントリーポイント web、websecure、およびポート 30001 の TCP エントリーポイント routertcp を必要とします。Traefik を使用しない場合は、traefik.enabled=false を設定します。この場合、Router にはクラスター内からしか到達できず、Router UI には kubectl port-forward で接続します。
• アドミッション Webhook を使用する場合: Kubernetes 1.29 以降、MutatingWebhookConfiguration をインストールする権限、および cert-manager またはチャートが独自の証明書を生成する権限のいずれか。Webhook はサイドカーをネイティブのサイドカーコンテナーとして追加するため、Kubernetes 1.29 が必要です。
• インストール前に対象の Namespace に作成しておくシークレット: MongoDB の接続文字列、Redis の接続文字列、暗号化キー、および Traefik が HTTPS を提供する場合（既定）は TLS 証明書。Kubernetes にデプロイする を参照してください。

データストア

データストア、そのバージョン、保存する内容を次の表に示します。

データストア	バージョン	保存する内容
MongoDB	7.x	Router が Platform から取得した構成とルール、および Router の監査ログ。シングルノードで問題ありません。
Redis	7.0 以降	現在のシート数、開いているすべてのセッション、Router のバックグラウンドジョブのスケジュール。

Redis の要件

Redis 7.0 は必須の最小バージョンです。LicOps は、古いバージョンの Redis がサポートしていない機能を使って各許可を記録するため、Redis 6 ではすべての admit が失敗します。

Redis は、追記型の永続化（append-only）を有効にし、退避（eviction）を行わない設定にします。

appendonly yes
appendfsync everysec
maxmemory-policy noeviction

どちらの設定も省略できません。Redis は許可されたすべてのセッションを保持しています。Redis がセッションをエビクトしたり失ったりすると、LicOps はすでに割り当てを約束したシートを忘れ、ほかのジョブに割り当て済みのシートに対してジョブを許可してしまいます。

Redis は Router のジョブスケジュールも保持しており、Router はこれを起動時にのみ登録します。Router の実行中に Redis が空の状態で復帰すると、Platform との同期が停止し、シート数が失われます。Router を再起動してスケジュールが復元されるまで、admit は Retry-After ヘッダー付きで 503 を返します。

Redis Cluster はサポートされていません。

ネットワーク要件

LicOps に必要なネットワーク接続を次の表に示します。

方向	宛先	目的
Router ホストからのアウトバウンド	OpenLM Platform (HTTPS)	シート数、サーバーヘルス、および定義したルールと予約。
スケジューラーホストから Router ホストへのインバウンド	ポート 8100	アドミッション API。Slurm と LSF のアダプター、および独自のツールがここを呼び出します。
管理用ネットワークのみから Router ホストへのインバウンド	ポート 8101	Router UI。ここで Router を Platform に接続します。
計算ノードから Router ホストへのインバウンド	ポート 30001	ライセンスのチェックアウトを LicOps 経由でルーティングする場合のみ。ワークロードを接続する を参照してください。
LicOps ホストからのアウトバウンド	各ライセンスサーバーの lmgrd ポート (port@host のポートで、通常は 27000)	ライセンスのチェックアウトを LicOps 経由でルーティングする場合のみ。
計算ノードからのアウトバウンド	各ライセンスサーバーのアドミンポートとベンダーデーモンのポート	ライセンスのチェックアウトそのもの。LicOps 経由でルーティングしない限り、LicOps はこの通信をプロキシしません。

ポート 8100 と 8101 へのアクセスを制限する

ポート 8100 と 8101 は管理用のインターフェイスです。これらへのアクセスは管理用ネットワークとジョブを投入するホストからだけに許可し、インターネットには公開しないでください。公開するのは、クライアントが使用するライセンスポートだけにしてください。投入ノードとログインノードはアドミッションのためにポート 8100 に到達する必要があるため、可能な限りスケジューラーホストからのアクセスだけを許可してください。

OpenLM Platform の前提条件

OpenLM Platform で次の前提条件を確認します。

• プール内のすべてのライセンスサーバーが OpenLM Broker を通じて監視されていること: LicOps は、Platform が監視しているライセンスサーバーとフィーチャーからプールを構築し、それらに対してのみ許可を行います。Platform がライセンスサーバー、そのライセンス、ヘルスを把握できるのは、そのマシンにインストールされた Broker を通じてだけです。そのため、Broker が実行されていない、または承認されていないサーバーは、どのプールにも含まれません。各ライセンスサーバーについて、次の手順を実行します。

  1. ライセンスサーバーのマシンに OpenLM Broker をインストールします。
  2. Broker Hub で Broker を承認します。
  3. License Servers、Pending Servers の順に選択し、Approve And Merge を使ってライセンスサーバーを承認します。
  4. License Servers の Live Servers Statistics で、サーバーが Up と表示されていることを確認します。

  詳細については、Broker をインストールする、Broker Hub、Flexera FlexNet (FLEXlm)、License Servers を参照してください。

• LicOps Configuration を開けること。 Platform の Navigation メニューで、Licenses and Features の下にあります。ここでアドミッションルールと予約を定義するため、アカウント管理者など、このアプリにアクセスできるアカウントが必要です。

• Identity で Router クライアントを作成できること。 Platform で Identity を開き、Authorization を選択して、Client Type が Router のクライアントを追加します。LicOps は Router フェイルオーバーと同じクライアントタイプを使用します。OpenLM LicOps を設定する を参照してください。

スケジューラーの要件

スケジューラーごとの要件を次の表に示します。

スケジューラー	要件
Slurm	コントローラーと、すべての投入ノードおよびログインノードに curl と jq があること。slurm.conf への書き込み権限。
IBM Spectrum LSF	管理ホスト、実行ホスト、すべての投入ホストに curl と jq があること。lsb.queues と、各投入ホストの $LSF_SERVERDIR への書き込み権限。
Kubernetes	Kubernetes の要件 を参照してください。
その他	JSON ボディ付きの HTTP POST を送信できる任意のツール。アドミッション API を呼び出す を参照してください。

暗号化キー

Router は、Platform のクライアントシークレットを保存する前に暗号化します。デプロイごとに 1 回、32 バイトのキーを生成するには、次のコマンドを実行します。

openssl rand -base64 32

出力された 44 文字の文字列を、出力されたとおりにそのまま保管します。このキーは MongoDB にすでに保存されている資格情報を復号するため、キーを置き換えても資格情報はローテーションされません。資格情報が読み取れなくなり、Router を Platform に接続し直す必要があります。この文字列をもう一度 base64 にかけないでください。かけると、Platform 接続を初めて保存するときに失敗します。