OpenLM Router を運用する

日常的には、OpenLM Router に手をかける必要はありません。Router は OpenLM Platform が報告するヘルスを監視し、プライマリに障害が発生するとペアをバックアップへ移します。次の作業は手動で行います。本番で頼る前のフェイルオーバーのリハーサル、メンテナンスのためにサーバーを運用から外す作業、切り替え後に何が起きたかの確認があります。

始める前に

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

• Router が OpenLM Platform に接続され、少なくとも 1 つのフェイルオーバーペアを適用していること。OpenLM Router を設定するを参照してください。
• Router ホストのポート 8100 に到達できること、または OpenLM Platform で LicOps Configuration を開けること。

これらの作業は、ポート 8100 の Router の REST API で行います。注記がある作業は OpenLM Platform で行います。コマンドは、Router ホスト、または管理用ネットワーク上のマシンから実行してください。

ペアの状態を確認する

各ペアが現在どのサーバーを使用しているか、またその判断の根拠となるヘルスを確認するには、次のコマンドを実行します。

curl http://localhost:8100/api/v1/status

レスポンスには、pairStatuses の下にペアごとのエントリーが 1 つずつ含まれます。各エントリーの内容を、次の表に示します。

項目	内容
アクティブサーバー	現在どちらのサーバーが処理しているか（Primary または Backup）。
サーバーヘルス	OpenLM Platform が各サーバーについて最後に報告したヘルス（Healthy、Unhealthy、Unknown）。
最近のフェイルオーバー	ペアの最新の切り替えと、そのタイムスタンプおよび理由。

Unknown は、Router がそのサーバーの読み取り値を 10 分間受け取っていないことを意味します。Router はこの空白を障害として扱わず、ペアをその時点の状態に保持します。そのため、Unknown のままのペアがすぐに切り替わることはありません。

フェイルオーバーをリハーサルする

本番で頼る前にペアをテストするには、利用の少ない時間帯にフェイルオーバーを強制します。強制的な切り替えでは新しい接続がバックアップに向かい、すでに開いている接続は閉じられるまでプライマリに残ります。pairId には、OpenLM Platform でのペアの Name を使います。次のコマンドを実行します。

# Move the pair onto its backup.
curl -X POST http://localhost:8100/api/v1/failover/manual \
  -H "Content-Type: application/json" \
  -d '{"pairId": "matlab", "message": "Commissioning test"}'

# Confirm: the pair reports Backup, with a new history entry.
curl http://localhost:8100/api/v1/status

# Return it to the primary.
curl -X POST http://localhost:8100/api/v1/failback \
  -H "Content-Type: application/json" \
  -d '{"pairId": "matlab", "message": "Commissioning test complete"}'

message は省略可能です。指定すると、切り替えとともにフェイルオーバー履歴に保存されます。

Auto フェイルバックモードのペアは、プライマリが正常になるとすぐに、自動的にプライマリへ戻ります。そのため、正常な Auto ペアを強制的にフェイルオーバーしても、その状態は長く続きません。ペアを意図的にバックアップに留めておくには、先にフェイルバックモードを Manual に設定してください。

サーバーを運用から外す

メンテナンス中にサーバーがトラフィックを受け取らないようにするには、OpenLM Platform の LicOps Configuration でペアを編集します。プライマリまたはバックアップの位置からサーバーを入れ替え、作業が終わったら元に戻します。Router は約 10 秒以内に変更を取得し、稼働したまま適用します。リッスンポートは開いたままで、Router 側で何かを停止したり再起動したりする必要はありません。

フェイルオーバー履歴を確認する

すべての切り替えは、理由とともにペアに記録されます。

理由	発生したこと
HealthCheckFailed	障害しきい値に達し、Router が自らペアを切り替えました。
Manual	誰かがフェイルオーバーまたはフェイルバックを強制しました。
FailbackRequested	Auto モードで、ペアが自動的にプライマリへ戻りました。

履歴は、GET /api/v1/status の pairStatuses にあるペアのエントリーで確認できます。履歴は MongoDB に保存され、Router を再起動しても保持されます。

ペアのポリシーを変更する

フェイルバックモードと障害しきい値は、ペアのプロパティです。変更するには、LicOps Configuration の Port Mappings でペアを選択し、Edit を選択します。Router は次回の同期で、再起動なしに変更を適用します。

障害しきい値はヘルスチェックの回数を数えるもので、ヘルスチェックは 30 秒ごとに実行されます。最大値は 10 です。値の選び方は、フェイルオーバーペアを定義するを参照してください。

Router を可用な状態に保つ

Router は、すべてのチェックアウトの最初の接続を中継します。Router が停止している間は、Router だけを指しているクライアントはライセンスサーバーに到達できません。Router を可用な状態に保つには、次の点に注意してください。

• 準備状態を監視する: GET /readyz は、Router が構成を取得するまで 503 を返し、boundPorts と desiredPorts で、すべてのリッスンポートが開いているかどうかがわかります。監視ツールからこれを確認し、503 が返った場合や、boundPorts の一覧が desiredPorts と異なる場合にアラートを出します。
• Redis は別に監視する: Redis は、各ペアがどのサーバーを使用しているかを保持しています。Redis が停止しても /readyz は失敗しないため、GET /api/v1/status の failoverStateStoreReachable も確認してください。Redis は、システム要件の永続化設定で実行します。
• MongoDB をバックアップする: MongoDB のデータボリューム（Compose ファイルの mongo_data）には、Router の ID、暗号化された OpenLM Platform 接続、フェイルオーバー履歴が保存されています。通常のバックアップツールでバックアップしてください。失った場合、代わりに起動する Router は別の Router になります。OpenLM Router の変更、アップグレード、削除を参照してください。
• 直接接続のフォールバックを決める: Router の後にライセンスサーバーを記載したクライアントは、Router が停止していても動作し続けます。同時に、トラフィックが通らなくなった Router も見えにくくなります。直接接続のフォールバックを残すを参照してください。
• Router は 1 つだけ実行する: 同じ OpenLM アカウントに報告する待機用の Router があると、LicOps Configuration が 2 つの Router の間で切り替わります。現在の制限事項を参照してください。

次のステップ

Router をアップグレード、移行、または廃止するには、OpenLM Router の変更、アップグレード、削除に進みます。

関連項目

• OpenLM Router のトラブルシューティング
• OpenLM Router API リファレンス