OpenLM Router のトラブルシューティング
始める前に
次の前提条件を確認します。
- Router ホストで
docker composeとcurlを実行できること。 - デプロイした各 Router イメージのビルドを把握していること。OpenLM Router をデプロイするを参照してください。
目に見えている症状から調べてください。Router の問題のほとんどは、コンテナーが起動していない、Router が OpenLM Platform と同期していない、クライアントが Router に移されていない、の 3 つのいずれかです。
Router のコンテナーが起動しないのはなぜですか
起動しないコンテナーの症状、原因、対処を、次の表に示します。
| 症状 | 原因 | 対処 |
|---|---|---|
起動時にコンテナーが Mongo ConnectionString cannot be null or empty. で終了する。 | 接続文字列の変数名が間違っています。Router が読み取るのは、アンダースコアが 2 つの MONGODB__CONNECTIONSTRING です。アンダースコアが 1 つの変数は無視され、値は空になります。 | 環境ファイルの変数名を修正し、コンテナーを作成し直します。REDIS__CONNECTIONSTRING についても同様です。 |
起動時にコンテナーが Failed to convert configuration value '' at 'admissionController:routing:CorrelationMode' で終了する。 | ROUTER_CORRELATION_MODE と ROUTER_PROXY_PROTOCOL_ENABLED はどちらも必須ですが、少なくとも一方が設定されていません。 | OpenLM Router をデプロイするのとおり、Router の環境に ROUTER_CORRELATION_MODE=Ip と ROUTER_PROXY_PROTOCOL_ENABLED=false を追加します。示されているとおりの値のままにしてください。 |
| MongoDB または Redis に接続できないことが Router のログに記録される。 | 接続文字列に、mongo や redis などの Compose のサービス名を使っています。Router はホストネットワークを使うため、これらの名前は名前解決できません。 | OpenLM Router をデプロイするのとおり、データストアのポートをホストに公開し、接続文字列には localhost を使います。 |
OpenLM Platform 接続の保存が Platform encryption key must be 32 bytes (256-bit) after Base64 decoding, but was 44 bytes. で失敗する。 | 暗号化キーが 2 回 Base64 エンコードされています。 | openssl rand -base64 32 が出力した文字列を、出力されたとおりに保存します。この文字列はすでに Base64 であり、もう一度エンコードすることがこのエラーの原因です。正しいキーは、デコードすると 32 バイトになります。 |
Router UI のコンテナーが invalid number of arguments in "server_name" directive をログに記録し、再起動を繰り返す。 | UI イメージには LB_FQDN が必要です。 | OpenLM Router をデプロイするのとおり、routerui コンテナーに LB_FQDN を設定します。 |
| Router UI が空白のページとして開く。 | /router-management プレフィックスを取り除く仕組みがないため、すべてのスクリプト要求にページの HTML が返されています。 | OpenLM Router をデプロイするで説明しているプロキシの背後に Router UI を配置し、ポート 8101 で開きます。 |
Router が OpenLM Platform と同期しないのはなぜですか
Router が OpenLM Platform に接続されるまでは、構成もサーバー一覧もヘルスデータもありません。理由を確認するには、Router UI の Platform Connection の下にある通知、または GET /api/v1/status の configurationManagement.lastSync.lastFailure を確認します。どちらも同じ理由を報告します。新しい Router では、理由は次のように表示されます。
No Platform connection is configured, so the Router has no address for the LicOps Configuration service
Router に構成がない間は、/readyz と /health/ready はどちらも 503 を返します。
通知と lastSync が対象とするのは、Router が OpenLM Platform から取得する構成です。Router はサーバーヘルスを別に取得するため、GET /api/v1/platform/servers も確認してください。ここにライセンスサーバーが一覧表示される必要があります。
同期していない Router の症状、原因、対処を、次の表に示します。
| 症状 | 原因 | 対処 |
|---|---|---|
lastFailure に、Platform 接続が構成されていないと表示される。 | OpenLM Platform 接続が保存されていません。 | OpenLM Router を設定するの説明に従って、Router を接続します。 |
lastFailure に、名前解決できないアドレスまたは到達できないアドレスが表示される。 | ベース URL が間違っているか、ホストから OpenLM Platform への送信方向のアクセスがありません。 | ベース URL を修正し、ホストから HTTPS で OpenLM Platform に到達できることを確認します。 |
接続は問題なく保存されるが、GET /api/v1/platform/servers が 503 を返し続ける。 | 認証情報は有効ですが、種類が Router の ID クライアントではないため、OpenLM Platform が Router の問い合わせを拒否しています。Router のログには、Platform serversStatistics returned Unauthorized と snapshot sync skipped … (servers: AuthFailed, licenses: AuthFailed) が記録されます。 | OpenLM Platform の Identity で Client Type が Router の ID クライアントを作成し、その認証情報を入力し直します。ほかの種類のクライアント（たとえば External API クライアント）は、認証には成功しても問い合わせを拒否されます。 |
クライアントの種類は Router で、lastSync には成功した同期が表示されているが、GET /api/v1/platform/servers が 503 を返し続ける。Router のログには、serversStatistics と licenseStatistics に対する AUTH_NOT_AUTHORIZED とともに、snapshot sync skipped … (servers: PartialFailure, licenses: PartialFailure) が記録される。 | OpenLM Platform が、この Router クライアントへのライセンスサーバーデータの提供を拒否しています。 | OpenLM サポートに連絡し、そのログ行を伝えてください。 |
それまで動作していた GET /api/v1/platform/servers が 503 を返すようになり、ヘルスが更新されなくなり、フェイルオーバーが一度も発生しない。 | OpenLM Platform との同期が 10 分間成功していません。同期が失敗しているか、Redis が空の状態で再起動されたために Router の定期ジョブが失われ、同期が実行されなくなっています。 | GET /api/v1/status の lastFailure を確認します。問題が示されている場合は、それを修正します。空の場合は、Router を再起動してジョブを再登録し、再発しないように Redis の永続化を修正します。システム要件を参照してください。 |
進んでいた lastSuccessfulSync が止まった。 | 同期が失敗しています。通常は、OpenLM Platform 接続が機能しなくなったことが原因です。 | lastFailure を確認します。現在の問題が表示され、次に成功するとクリアされます。 |
ペアのヘルスが Unknown と表示される。 | Router がそのサーバーの読み取り値を 10 分間受け取っていません。 | Router はペアを現在の状態のまま維持し、Unknown ではフェイルオーバーしません。OpenLM Platform との同期を修正してください。読み取り値が戻ると、ペアは通常の動作を再開します。 |
OpenLM Platform で行った変更が Router に反映されないのはなぜですか
反映されない変更の症状、原因、対処を、次の表に示します。
| 症状 | 原因 | 対処 |
|---|---|---|
OpenLM Platform でペアを保存したが、Router が引き続き unconfigured を報告する。 | 保存から 10 秒経っていないか、Router が同期していないか、別の Router がより最近 OpenLM Platform に報告したため LicOps Configuration にその Router のペアが表示されていました。 | GET /api/v1/status の lastSync を確認します。LicOps Configuration は、最後に報告した Router を対象に動作します。OpenLM アカウントに複数の Router が報告している場合は、使用していない Router を停止してから、ページを再読み込みします。 |
| Choose server にライセンスサーバーが表示されない。 | OpenLM Platform がそのサーバーを監視していません。OpenLM Broker がサーバーにインストールされていないか、Broker Hub で承認されていないか、サーバーが License Servers で承認されていません。 | システム要件の Broker の手順に従い、Live Servers Statistics でサーバーが Up と表示されることを確認します。 |
LicOps Configuration で保存したペアがリッスンポートを開かず、lastFailure に The Router has not collected any Platform license-server data yet と表示される。 | Router にサーバー一覧がないため、ペアのサーバーを解決できず、構成を拒否しています。この拒否は OpenLM Platform には表示されません。 | Router が OpenLM Platform と同期しないのはなぜですかの説明に従い、先にサーバー一覧を取得できるようにします。Router は同期のたびに再試行するため、サーバー一覧が届くとペアが有効になります。 |
lastAppliedConfigVersion が遅れたままで、lastFailure にサーバー名が表示される。 | ペアで指定しているサーバーが、この Router の OpenLM Platform サーバー一覧に含まれていないため、Router が適用を拒否しました。 | この Router の GET /api/v1/platform/servers に表示されるサーバーを選択します。 |
| LicOps Configuration に、まだどの Router も自身を報告していないと表示される。 | Router がまだ OpenLM Platform と同期していないか、同期する前にページを開きました。ページは自動では更新されません。 | Router の OpenLM Platform 接続が機能していることを確認してから、ページを再読み込みします。Router は最初の同期が成功したときに自身を登録します。 |
LicOps Configuration に別の Router が表示されるのはなぜですか
LicOps Configuration が扱うのは、お使いの OpenLM アカウントに最後に報告した Router です。2 つの Router が報告している場合、ページには最後に報告した Router のペアが表示され、再読み込みのたびに切り替わることがあります。
- ページに表示されている Router の識別子を、設定したい Router の
GET /api/v1/statusにあるrouterIdと比較します。 - 使用していない Router をすべて停止します。OpenLM Router の変更、アップグレード、削除を参照してください。
- ページを再読み込みします。ページは自動では更新されません。
OpenLM アカウントごとに Router を 1 つだけ実行してください。現在の制限事項を参照してください。
クライアントが Router を使用していないのはなぜですか
Router は動作しているのにクライアントが使用していない場合の症状、原因、対処を、次の表に示します。
| 症状 | 原因 | 対処 |
|---|---|---|
| フェイルオーバーが発生したが、クライアントが引き続き古いサーバーに接続する。 | クライアントが、Router ではなくライセンスサーバーを指しています。 | LM_LICENSE_FILE と、アプリケーションのベンダー固有の変数を確認します。ベンダーの変数が優先されます。OpenLM Router を設定するを参照してください。 |
Router 経由の lmutil lmstat は成功するが、アプリケーションがチェックアウトできない。 | Router が中継するのは lmgrd への接続だけです。チェックアウトはその後、ワークステーションからアクティブなサーバー上のベンダーデーモンへ直接行われますが、そのポートが閉じているか、再起動のたびに変わっています。 | 各ライセンスファイルの VENDOR 行に PORT= を指定してベンダーデーモンのポートを固定し、ワークステーションから両方のサーバーへのそのポートを開きます。 |
| 設定したポートで何も待ち受けていない。 | 構成が適用されていないか、コンテナーがそのポートを公開せずにブリッジネットワークを使っています。 | curl http://localhost:8100/readyz でバインド済みのポートと必要なポートを比較します。ホストネットワークの使用をお勧めします。 |
フェイルオーバーを強制すると 409 "Already on backup" が返るが、ペアはプライマリから提供されている。 | pairId が存在しないか、ペアにバックアップがありません。Router は、どちらの場合も、すでに切り替わったペアと同じ応答を返します。 | GET /api/v1/config で名前を確認し、ペアにバックアップサーバーがあることを確認します。 |
/api/v1/status が unconfigured を報告する。 | Router が OpenLM Platform から構成を取得していないか、OpenLM Platform にペアが定義されていません。 | OpenLM Platform 接続と GET /api/v1/status の lastSync を確認し、OpenLM Platform にペアが存在することを確認します。 |
| フェイルオーバーしていたペアが、誰も要求していないのにプライマリに戻っている。 | Redis がロールキーを失いました。退避（eviction）、フラッシュ、または永続化なしでの再起動が原因です。 | maxmemory-policy noeviction を設定し、追記型の永続化（append-only）を有効にします。システム要件を参照してください。 |
診断情報を収集する
Router ホストで、次のコマンドを実行します。
docker compose logs routerapi --tail 200
curl http://localhost:8100/api/v1/status
curl http://localhost:8100/readyz
curl http://localhost:8100/api/v1/config
/readyz は、どのリッスンポートがバインドされていて、どのポートが必要とされているかを報告します。構成が適用されていないのか、ネットワークの問題なのかを見分ける最も手早い方法です。
関連項目
ドキュメントチームは、大規模言語モデルを使ってこのページを下書きすることがあります。公開前に、テクニカルライターがすべてのページをレビューし、製品と照らし合わせて検証します。最終的な判断は人間が行います。