トラブルシューティング

目に見える症状から調べてください。LicOps の問題のほとんどは、LicOps が OpenLM Platform と同期していない、Router が LicOps モードで動作していない、リクエストが存在しないプールを指定している、ジョブが実際には LicOps を経由していない、の 4 つのいずれかです。

コンテナーが起動しないのはなぜですか

LicOps は OpenLM Router 上で動作するため、起動時に失敗する原因はフェイルオーバー用の Router と同じです。接続文字列の変数名の誤り、相関モードの設定の欠落、2 回エンコードされた暗号化キーなどです。Router のトラブルシューティングのコンテナーが起動しないを参照してください。次の表に、症状、原因、対処を示します。

症状	原因	対処
Router は起動するが、すべての admit が失敗し、ログに admit 時の Redis エラーが記録される。	Redis のバージョンが 7.0 より古いです。	Redis を 7.0 以降にアップグレードします。システム要件を参照してください。
Kubernetes で Router が起動を拒否し、ログに TrustedCidrs が出力される。	信頼済みの範囲が空です。	routerapi.admissionController.proxyProtocol.trustedCidrs に Pod の CIDR を設定します。Kubernetes にデプロイするを参照してください。
Kubernetes で、末尾がコロンで終わるイメージ参照によってイメージのプルが失敗する。	チャートの tag が設定されていません。	すべてのタグを明示的に設定します。
Kubernetes で、Webhook の Pod が ImagePullBackOff で失敗する。	イメージ名またはタグが誤っています。	OpenLM のバンドルに含まれるチャートを使用します。これらのチャートは olm-pod-sidecar、olm-dispatch-init、olm-iptables-init を指定しています。

LicOps が OpenLM Platform と同期しないのはなぜですか

LicOps は Platform と同期するまで構成もルールもプールも持たないため、すべてのリクエストを拒否するか、受け付けません。Router UI の Platform Connection の下に理由を示す赤い通知が表示され、GET /api/v1/status も同じ理由を configurationManagement.lastSync.lastFailure で報告します。原因と対処はフェイルオーバー用の Router と同じです。Router が Platform と同期しないのはなぜですかを参照してください。

LicOps には最新のシート数とサーバーヘルスも必要で、これらは構成とは別に収集されます。確認するには、可用性レポートを読みます。

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

次の表に、症状、原因、対処を示します。

症状	原因	対処
coldStart が true のままで、admit が 503 を返し続ける。	LicOps が Platform からシート数を一度も受け取っていません。	GET /api/v1/platform/servers にライセンスサーバーが表示されることを確認します。503 が返る場合は、上記リンク先の Router のトラブルシューティングに従ってください。よくある原因は、クライアントの種類が Router ではない認証情報です。
それまで動作していた admit が、すべてのリクエストを StaleSnapshot で拒否するようになり、lastReconcileTime が更新されなくなった。	Platform との同期が停止しています。Redis が空の状態で再起動されると、Router はバックグラウンドジョブのスケジュールを失い、同期は自動では再開しません。	Router を再起動し、再発しないように Redis を永続化します。システム要件を参照してください。
staleForAdmission が true と false の間で切り替わる。	Platform の応答が遅いか、断続的です。	LicOps ホストから Platform へのネットワーク経路を確認し、Router のログで同期の失敗を確認します。

LicOps Configuration に Port Mappings が表示されるのはなぜですか

LicOps Configuration に LicOps と Rules ではなく Port Mappings が表示される場合は、フェイルオーバー用の Router と連携しています。LicOps Configuration は、連携している Router のモードに応じたページを表示します。フェイルオーバー用の Router には Port Mappings、LicOps 用の Router には LicOps と Rules が表示されます。次の表に、症状、原因、対処を示します。

症状	原因	対処
LicOps のデプロイなのに、LicOps Configuration に Port Mappings が表示される。	Router が ROUTER_CONFIG_BOOTSTRAP_MODE=loadBalancer を指定せずに、または basic を指定して起動されました。	OpenLM LicOps をデプロイするのとおりに変数を設定します。モードは Router の初回起動時に確定します。専用の空の MongoDB データベースを持つ新しい Router をデプロイし、古い Router を停止してください。
再読み込みのたびに、ページが Port Mappings と LicOps の間で切り替わる。	2 つの Router（たとえば、フェイルオーバー用の Router と LicOps 用の Router）が同じ OpenLM アカウントに報告しています。LicOps Configuration は、最後に報告した Router を対象に動作します。	OpenLM アカウントごとに Router を 1 つだけ実行します。使用しない Router は停止します。OpenLM Router の変更、アップグレード、削除を参照してください。
まだどの Router も自身を報告していないとページに表示される。	LicOps がまだ Platform と同期していないか、同期する前にページを開きました。ページは自動では更新されません。	Platform への接続が機能していることを確認してから、ページを再読み込みします。
各ページに LicOps License is not available with current openLM License と表示され、保存が拒否される。	OpenLM のライセンスに LicOps が含まれていません。	OpenLM に連絡して、ライセンスを再発行してもらいます。LicOps は既存の構成で動作し続けます。システム要件を参照してください。

LicOps にプールがないのはなぜですか

GET /api/v1/stats が [] を返し、すべての admit が拒否されます。次の表に、症状、原因、対処を示します。

症状	原因	対処
LicOps を接続してから 1 分以内の時点で、一覧が空になっている。	LicOps が Platform からライセンスサーバーのデータを受け取っていません。	LicOps が OpenLM Platform と同期しないのはなぜですかの手順に従います。
プール、またはプール内の 1 台のサーバーが表示されない。	Platform がそのライセンスサーバーを監視していません。OpenLM Broker がサーバーにインストールされていないか、Broker Hub で承認されていないか、サーバーが License Servers で承認されていません。	システム要件の Broker の手順に従ってから、Live Servers Statistics でサーバーが Up と表示されることを確認します。

リクエストが拒否されるのはなぜですか

拒否の reason から調べ始め、リクエストが拒否された理由を調べるの説明に従って可用性レポートを確認します。次の表に、症状、原因、対処を示します。

症状	原因	対処
プールには空きシートが十分あるように見えるのに、NoServerAvailable になる。	リクエストのベンダーまたはフィーチャーがプールと一致していません。原因はほぼ必ず、大文字・小文字の違いかつづりの誤りです。	GET /api/v1/stats と比較します。Slurm の場合は、ライセンスマップを手で編集せずに再生成します。
Slurm のライセンス名の 1 つが NoServerAvailable で拒否されるようになった。ほかの名前は引き続き動作する。	ライセンスマップの生成後に、Platform でそのライセンスが追加されたか、名前が変更されました。	Slurmの説明に従って、マップを再生成し、定期的な更新をスケジュールします。
一部のサーバーの free にシートが表示されているのに、NoCapacity になる。	Keep off a server などのルールが対象のサーバーを絞り込んでいるか、リクエストが、どのサーバー 1 台の空きシートよりも多いシート数を要求しています。	ルールと、そのプールの largestAdmittableRequest を確認します。
ConstraintBlocked になる。	空きシートのあるすべてのサーバーが、予約によって制限またはブロックされています。	スケジュールでシート数を制限するを参照してください。
PolicyDenied になる。	Deny the request ルールに一致しました。	LicOps Configuration でルールを確認します。
ルールが効いていないように見える。	保存してから 1 分経っていないか、Target server がどのサーバーとも一致していないか、条件が大文字・小文字の異なる名前を比較しています。	1 分待ってから、GET /api/v1/rules/router-admission を確認します。対象はピッカーで選択し、名前は GET /api/v1/stats からコピーします。
時間帯のルールや予約期間が、数時間早く、または遅く始まる。	LicOps は UTC で動作しています。	routerapi コンテナーに TZ を設定します。スケジュールをタイムゾーンに合わせるを参照してください。

シートが返却されないのはなぜですか

GET /api/v1/stats のプールの reserved の数が増え続け、実行中のジョブは少ないにもかかわらず、リクエストが NoCapacity で拒否されるようになります。次の表に、原因と対処を示します。

原因	対処
ジョブが、どのような終わり方をしても必ずシートを解放するようになっていません。	必ず実行されるフックまたは trap から解放が実行されるようにします。Slurm と LSF の場合は、アダプターの両方のロールがインストールされ、フックが実行されることを確認します。
LSF の POST_EXEC がセッション ID を見つけられません。	PRE_EXEC と POST_EXEC の両方からアクセスできるディレクトリを OL_STATE_DIR に設定します。IBM Spectrum LSFを参照してください。
ジョブが admit タイムアウトより長くキューで待機してシートを失い、その後そのまま開始してチェックアウトしています。	admit タイムアウトを、キューでの通常の待機時間より長くします。セッションタイムアウトを設定するを参照してください。

解放されなかったシートは、セッションがタイムアウトすると返却されます。すぐに返却するには、解放されなかったシートを返却するを参照してください。

ジョブが LicOps を経由しないのはなぜですか

次の表に、症状、原因、対処を示します。

症状	原因	対処
ライセンスを使うジョブが、アダプターのログに admit が記録されないまま開始する。	ジョブが、（ラッパーではない）本来の sbatch で投入されたか、LSF で -a openlm を付けずに投入されたか、アダプターのない投入ホストから投入されました。	SlurmまたはIBM Spectrum LSFを参照してください。
Kubernetes の Pod が LicOps のコンテナーなしで起動する。	Namespace のラベル、または openlm.io/needs-licensing アノテーションがありません。どちらか一方でも欠けていると、Webhook はエラーを出さずにその Pod をスキップします。	Kubernetes ワークロードを参照してください。
オプトインした Namespace で Pod を 1 つも作成できない。	アドミッション Webhook が利用できず、その失敗ポリシーが Fail になっています。	Webhook を復旧するか、webhook.failurePolicy=Ignore を指定して再インストールします。Kubernetes にデプロイするを参照してください。
ジョブは許可されるが、チェックアウトが LicOps の選んだサーバーに向かわない。	チェックアウトルーティングがない場合、アプリケーションは自身のライセンス設定に従ってチェックアウトします。チェックアウトルーティングがある場合でも、MLM_LICENSE_FILE などのベンダー固有の変数が優先されることがあります。	LicOps にサーバーも選ばせるかを決めるを参照してください。
チェックアウトルーティングを使うと、チェックアウトは LicOps に届くが、対応するジョブと照合されない。	計算ノードがアドレス変換を経由して LicOps に接続しているため、チェックアウトが、dispatch で記録された IP アドレスとは異なるアドレスから届いています。	計算ノードが LicOps ホストに直接接続できるようにします。

診断情報を収集する

診断情報を収集するには、次のコマンドを実行します。

docker compose logs routerapi --tail 200
curl http://localhost:8100/api/v1/status
curl http://localhost:8100/api/v1/stats
curl http://localhost:8100/api/v1/admission-controller/availability
curl http://localhost:8100/api/v1/rules/router-admission

Kubernetes では、kubectl -n <namespace> logs deployment/openlm-routerapi --tail 200 でログを確認し、kubectl port-forward svc/openlm-router-api 8100:8100 を経由してエンドポイントにアクセスします。スケジューラー側については、投入ホストと、コントローラーまたは実行ホストの /var/log/openlm/hpc-adapter.log を含めてください。