高度なネットワーキング
OpenShift Container Platform クラスターのインストールおよび設定
概要
第1章 エンドポイントへの接続の確認 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は、クラスター内のリソース間の接続ヘルスチェックを実行するコントローラーである接続性チェックコントローラーを実行します。ヘルスチェックの結果を確認して、調査している問題が原因で生じる接続の問題を診断したり、ネットワーク接続を削除したりできます。
1.1. 実行される接続ヘルスチェック リンクのコピーリンクがクリップボードにコピーされました!
クラスターリソースにアクセスできることを確認するために、次の各クラスター API サービスへの TCP 接続が確立されます。
- Kubernetes API サーバーサービス
- Kubernetes API サーバーエンドポイント
- OpenShift API サーバーサービス
- OpenShift API サーバーエンドポイント
- ロードバランサー
サービスおよびサービスエンドポイントがクラスター内のすべてのノードで到達可能であることを確認するには、以下の各ターゲットに対して TCP 接続が行われます。
- ヘルスチェックターゲットサービス
- ヘルスチェックターゲットエンドポイント
1.2. 接続ヘルスチェックの実装 リンクのコピーリンクがクリップボードにコピーされました!
接続チェックコントローラーは、クラスター内の接続検証チェックをオーケストレーションします。接続テストの結果は、openshift-network-diagnostics namespace の PodNetworkConnectivity オブジェクトに保存されます。接続テストは、1 分ごとに並行して実行されます。
Cluster Network Operator (CNO) は、接続性ヘルスチェックを送受信するためにいくつかのリソースをクラスターにデプロイします。
- ヘルスチェックのソース
-
このプログラムは、
Deploymentオブジェクトで管理される単一の Pod レプリカセットにデプロイします。このプログラムはPodNetworkConnectivityオブジェクトを消費し、各オブジェクトで指定されるspec.targetEndpointに接続されます。 - ヘルスチェックのターゲット
- クラスターのすべてのノードにデーモンセットの一部としてデプロイされた Pod。Pod はインバウンドのヘルスチェックをリッスンします。すべてのノードにこの Pod が存在すると、各ノードへの接続をテストすることができます。
ノードセレクターを使用して、ネットワーク接続ソースとターゲットが実行されるノードを設定できます。さらに、ソース Pod とターゲット Pod で許容できる tolerations を指定することもできます。この設定は、config.openshift.io/v1 API グループの Network API のシングルトン cluster カスタムリソースで定義されます。
Pod のスケジュールは、設定を更新した後に実行されます。したがって、設定を更新する前に、セレクターで使用する予定のノードラベルを適用する必要があります。ネットワーク接続チェック Pod の配置を更新した後に適用されたラベルは無視されます。
次の YAML のデフォルト設定を参照してください。
接続ソースおよびターゲット Pod のデフォルト設定
- 1
- ネットワーク診断設定を指定します。値が指定されていないか、空のオブジェクトが指定されており、
clusterという名前のnetwork.operator.openshift.ioカスタムリソースでspec.disableNetworkDiagnostics=trueが設定されている場合、ネットワーク診断は無効になります。設定されている場合、この値はspec.disableNetworkDiagnostics=trueをオーバーライドします。 - 2
- 診断モードを指定します。値は、空の文字列、
All、またはDisabledです。空の文字列はAllを指定するのと同じです。 - 3
- オプション: 接続チェックのソース Pod のセレクターを指定します。
nodeSelectorおよびtolerationsフィールドを使用して、sourceNodePod をさらに指定できます。これは、ソース Pod とターゲット Pod の両方でオプションです。省略することも、両方使用することも、いずれか一方だけ使用することもできます。 - 4
- オプション: 接続チェックのターゲット Pod のセレクターを指定します。
nodeSelectorおよびtolerationsフィールドを使用して、targetNodePod をさらに指定できます。これは、ソース Pod とターゲット Pod の両方でオプションです。省略することも、両方使用することも、いずれか一方だけ使用することもできます。
1.3. Pod 接続チェックの配置の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、cluster という名前の network.config.openshift.io オブジェクトを変更することで、接続チェック Pod が実行するノードを設定できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを入力して、接続チェックの設定を編集します。
oc edit network.config.openshift.io cluster
$ oc edit network.config.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
テキストエディターで、
networkDiagnosticsスタンザを更新して、ソース Pod とターゲット Pod に必要なノードセレクターを指定します。 - 変更を保存してテキストエディターを終了します。
検証
- 次のコマンドを入力して、ソース Pod とターゲット Pod が目的のノードで実行されていることを検証します。
oc get pods -n openshift-network-diagnostics -o wide
$ oc get pods -n openshift-network-diagnostics -o wide
出力例
1.4. PodNetworkConnectivityCheck オブジェクトフィールド リンクのコピーリンクがクリップボードにコピーされました!
PodNetworkConnectivityCheck オブジェクトフィールドは、以下の表で説明されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
以下の形式のオブジェクトの名前:
|
|
|
|
オブジェクトが関連付けられる namespace。この値は、常に |
|
|
|
接続チェックの起点となる Pod の名前 (例: |
|
|
|
|
|
|
| 使用する TLS 証明書の設定。 |
|
|
| 使用される TLS 証明書の名前 (ある場合)。デフォルト値は空の文字列です。 |
|
|
| 接続テストの状態を表す、および最近の接続の成功および失敗に関するログ。 |
|
|
| 接続チェックと最新のステータスと以前のステータス。 |
|
|
| 試行に失敗した接続テストのログ。 |
|
|
| 停止が生じた期間が含まれる接続テストのログ。 |
|
|
| 試行に成功した接続テストのログ。 |
以下の表は、status.conditions 配列内のオブジェクトのフィールドを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| 接続の条件がある状態から別の状態に移行した時間。 |
|
|
| 人が判読できる形式の最後の移行に関する詳細。 |
|
|
| マシンの読み取り可能な形式での移行の最後のステータス。 |
|
|
| 状態のテータス。 |
|
|
| 状態のタイプ。 |
以下の表は、status.conditions 配列内のオブジェクトのフィールドを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| 接続の障害が解決された時点からのタイムスタンプ。 |
|
|
| 接続ログエントリー (停止の正常な終了に関連するログエントリーを含む)。 |
|
|
| 人が判読できる形式の停止に関する詳細情報の要約。 |
|
|
| 接続の障害が最初に検知された時点からのタイムスタンプ。 |
|
|
| 元の障害を含む接続ログのエントリー。 |
1.4.1. 接続ログフィールド リンクのコピーリンクがクリップボードにコピーされました!
接続ログエントリーのフィールドの説明は以下の表で説明されています。オブジェクトは以下のフィールドで使用されます。
-
status.failures[] -
status.successes[] -
status.outages[].startLogs[] -
status.outages[].endLogs[]
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| アクションの期間を記録します。 |
|
|
| ステータスを人が判読できる形式で提供します。 |
|
|
|
ステータスの理由をマシンが判読できる形式で提供します。値は |
|
|
| ログエントリーが成功または失敗であるかを示します。 |
|
|
| 接続チェックの開始時間。 |
1.5. エンドポイントのネットワーク接続の確認 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、API サーバー、ロードバランサー、サービス、Pod などのエンドポイントの接続を確認し、ネットワーク診断が有効になっていることを確認できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
次のコマンドを入力して、ネットワーク診断が有効になっていることを確認します。
oc get network.config.openshift.io cluster -o yaml
$ oc get network.config.openshift.io cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、現在の
PodNetworkConnectivityCheckオブジェクトをリスト表示します。oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
$ oc get podnetworkconnectivitycheck -n openshift-network-diagnosticsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続テストログを表示します。
- 直前のコマンドの出力から、接続ログを確認するエンドポイントを特定します。
次のコマンドを入力してオブジェクトを表示します。
oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yaml
$ oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>はPodNetworkConnectivityCheckオブジェクトの名前を指定します。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第2章 クラスターネットワークの MTU 変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのインストール後にクラスターネットワークの最大転送単位 (MTU) を変更できます。MTU 変更の適用には、クラスターノードを再起動する必要があるため、変更により致命的な問題が発生する可能性があります。
2.1. クラスター MTU について リンクのコピーリンクがクリップボードにコピーされました!
クラスターネットワークの MTU は、インストール中に、クラスターノードのプライマリーネットワークインターフェイスの MTU に基づいて自動的に設定されます。通常、検出された MTU をオーバーライドする必要はありません。
場合によっては、次のいずれかの理由で、クラスターネットワークの MTU を変更する必要があります。
- クラスターのインストール中に検出された MTU が使用中のインフラストラクチャーに適していない
- クラスターインフラストラクチャーに異なる MTU が必要となった (例: パフォーマンスの最適化にさまざまな MTU を必要とするノードが追加された)。
OVN-Kubernetes ネットワークプラグインのみが MTU 値の変更をサポートしています。
2.1.1. サービス中断に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで最大転送単位 (MTU) の変更を開始すると、サービスの可用性が次のような影響を受ける可能性があります。
- 新しい MTU への移行を完了するには、少なくとも 2 回のローリングリブートが必要です。この間、一部のノードは再起動するため使用できません。
- 特定のアプリケーションに、絶対 TCP タイムアウト間隔よりもタイムアウトの間隔が短いクラスターにデプロイされた場合など、MTU の変更中に中断が発生する可能性があります。
2.1.2. MTU 値の選択 リンクのコピーリンクがクリップボードにコピーされました!
最大転送単位 (MTU) の移行を計画する際には、2 つの MTU 値を考慮する必要があります。これらの値は、関連しているが異なるものです。
- ハードウェア MTU: この MTU 値は、ネットワークインフラストラクチャーの詳細に基づいて設定されます。
-
クラスターネットワーク MTU: この MTU 値は、クラスターネットワークオーバーレイのオーバーヘッドを考慮して、常にハードウェア MTU よりも小さくなります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。OVN-Kubernetes の場合、オーバーヘッドは
100バイトです。
クラスターがノードごとに異なる MTU 値を必要とする場合は、クラスター内の任意のノードで使用される最小の MTU 値から、ネットワークプラグインのオーバーヘッド値を差し引く必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。
ノードが受け入れられない MTU 値の選択を回避するには、ip -d link コマンドを使用して、ネットワークインターフェイスが受け入れる最大 MTU 値 (maxmtu) を確認します。
2.1.3. 移行プロセスの仕組み リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。
| ユーザーが開始する手順 | OpenShift Container Platform アクティビティー |
|---|---|
| Cluster Network Operator 設定で次の値を指定します。
| Cluster Network Operator (CNO): 各フィールドが有効な値に設定されていることを確認します。
指定の値が有効な場合に、CNO は、クラスターネットワークの MTU が Machine Config Operator (MCO): クラスター内の各ノードのローリングリブートを実行します。 |
| クラスター上のノードのプライマリーネットワークインターフェイスの MTU を再設定します。これは、次のいずれかの方法を使用して実行できます。
| 該当なし |
|
ネットワークプラグインの CNO 設定で | Machine Config Operator (MCO): 新しい MTU 設定を使用して、クラスター内の各ノードのローリングリブートを実行します。 |
2.2. クラスターネットワーク MTU の変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターの最大伝送単位 (MTU) を増減できます。
MTU 移行プロセス中にノードの MTU 値をロールバックすることはできません。ただし、MTU 移行プロセスの完了後に値をロールバックすることはできます。
移行には中断が伴うため、MTU 更新が有効になると、クラスター内のノードが一時的に使用できなくなる可能性があります。
次の手順では、マシン設定、Dynamic Host Configuration Protocol (DHCP)、または ISO イメージを使用してクラスターネットワーク MTU を変更する方法を説明します。DHCP または ISO アプローチを使用する場合は、クラスターのインストール後に保持した設定アーティファクトを参照して、手順を完了する必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つアカウントを使用してクラスターにアクセスできる。 -
クラスターのターゲット MTU を特定している。OVN-Kubernetes ネットワークプラグインの MTU は、クラスター内の最小のハードウェア MTU 値から
100を引いた値に設定する必要があります。 - ノードが物理マシンである場合は、クラスターネットワークと、接続されているネットワークスイッチがジャンボフレームをサポートしていることを確認する。
- ノードが仮想マシン (VM) である場合は、ハイパーバイザーと、接続されているネットワークスイッチがジャンボフレームをサポートしていることを確認する。
2.2.1. 現在のクラスターの MTU 値を確認する リンクのコピーリンクがクリップボードにコピーされました!
クラスターネットワークの現在の最大転送単位 (MTU) を取得するには、次の手順を使用します。
手順
クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。
oc describe network.config cluster
$ oc describe network.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.2. ハードウェア MTU 設定の準備 リンクのコピーリンクがクリップボードにコピーされました!
クラスターノードのハードウェア最大転送単位 (MTU) は、複数の方法で設定できます。次の例では、最も一般的な方法のみを示します。インフラストラクチャー MTU の正確性を検証します。クラスターノードでハードウェア MTU を設定するための優先される方法を選択します。
手順
ハードウェア MTU の設定を準備します。
ハードウェア MTU が DHCP で指定されている場合は、次の dnsmasq 設定などで DHCP 設定を更新します。
dhcp-option-force=26,<mtu>
dhcp-option-force=26,<mtu>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<mtu>- DHCP サーバーがアドバタイズするハードウェア MTU を指定します。
- ハードウェア MTU が PXE を使用したカーネルコマンドラインで指定されている場合は、それに応じてその設定を更新します。
ハードウェア MTU が NetworkManager 接続設定で指定されている場合は、以下のステップを実行します。OpenShift Container Platform では、これは、DHCP、カーネルコマンドラインなどの方法でネットワーク設定を明示的に指定していない場合のデフォルトのアプローチです。変更なしで次の手順を機能させるには、全クラスターノードで、同じ基盤となるネットワーク設定を使用する必要があります。
次のコマンドを入力して、プライマリーネットワークインターフェイスを見つけます。
oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
$ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<node_name>- クラスター内のノードの名前を指定します。
<interface>-mtu.confファイルに次のNetworkManager設定を作成します。[connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>
[connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<interface>- プライマリーネットワークインターフェイス名を指定します。
<mtu>- 新しいハードウェア MTU 値を指定します。
2.2.3. MachineConfig オブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
MachineConfig オブジェクトを作成するには、次の手順を使用します。
手順
1 つはコントロールプレーンノード用、もう 1 つはクラスター内のワーカーノード用に、2 つの
MachineConfigオブジェクトを作成します。control-plane-interface.buファイルに次の Butane 設定を作成します。注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0です。たとえば、4.18.0です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow worker-interface.buファイルに次の Butane 設定を作成します。注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0です。たとえば、4.18.0です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、Butane 設定から
MachineConfigオブジェクトを作成します。for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done$ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 警告これらのマシン設定は、後で明示的に指示されるまで適用しないでください。これらのマシン設定を適用すると、クラスターの安定性が失われます。
2.2.4. MTU の移行の開始 リンクのコピーリンクがクリップボードにコピーされました!
MTU の移行を開始するには、次の手順を使用します。
手順
MTU の移行を開始するには、次のコマンドを入力して移行設定を指定します。Machine Config Operator は、MTU の変更に備えて、クラスター内のノードをローリングリブートします。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<overlay_from>- 現在のクラスターネットワークの MTU 値を指定します。
<overlay_to>-
クラスターネットワークのターゲット MTU を指定します。この値は、
<machine_to>の値を基準にして設定します。OVN-Kubernetes の場合、この値は<machine_to>の値から100を引いた値である必要があります。 <machine_to>- 基盤となるホストネットワークのプライマリーネットワークインターフェイスの MTU を指定します。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Machine Config Operator は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true、UPDATING=false、DEGRADED=falseのステータスがあります。注記Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。
2.2.5. マシン設定の検証 リンクのコピーリンクがクリップボードにコピーされました!
マシン設定を検証するには、次の手順を使用します。
手順
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/stateフィールドの値はDoneです。 -
machineconfiguration.openshift.io/currentConfigフィールドの値は、machineconfiguration.openshift.io/desiredConfigフィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
oc get machineconfig <config_name> -o yaml | grep ExecStart
$ oc get machineconfig <config_name> -o yaml | grep ExecStartCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<config_name>-
machineconfiguration.openshift.io/currentConfigフィールドからマシン設定の名前を指定します。
マシン設定には、systemd 設定に以下の更新を含める必要があります。
ExecStart=/usr/local/bin/mtu-migration.sh
ExecStart=/usr/local/bin/mtu-migration.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.6. 新しいハードウェア MTU 値の適用 リンクのコピーリンクがクリップボードにコピーされました!
新しいハードウェア最大転送単位 (MTU) 値を適用するには、次の手順を使用します。
手順
基盤となるネットワークインターフェイスの MTU 値を更新します。
NetworkManager 接続設定で新しい MTU を指定する場合は、次のコマンドを入力します。MachineConfig Operator は、クラスター内のノードのローリングリブートを自動的に実行します。
for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml done$ for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - DHCP サーバーオプションまたはカーネルコマンドラインと PXE を使用して新しい MTU を指定する場合は、インフラストラクチャーに必要な変更を加えます。
Machine Config Operator は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true、UPDATING=false、DEGRADED=falseのステータスがあります。注記Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/stateフィールドの値はDoneです。 -
machineconfiguration.openshift.io/currentConfigフィールドの値は、machineconfiguration.openshift.io/desiredConfigフィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
oc get machineconfig <config_name> -o yaml | grep path:
$ oc get machineconfig <config_name> -o yaml | grep path:Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<config_name>-
machineconfiguration.openshift.io/currentConfigフィールドからマシン設定の名前を指定します。
マシン設定が正常にデプロイされた場合、前の出力には
/etc/NetworkManager/conf.d/99-<interface>-mtu.confファイルパスとExecStart=/usr/local/bin/mtu-migration.sh行が含まれます。
2.2.7. MTU の移行の完了 リンクのコピーリンクがクリップボードにコピーされました!
MTU の移行を完了するには、次の手順を使用します。
手順
MTU の移行を完了するために、OVN-Kubernetes ネットワークプラグインに対して次のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<mtu>-
<overlay_to>で指定した新しいクラスターネットワーク MTU を指定します。
MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true、UPDATING=false、DEGRADED=falseのステータスがあります。
検証
クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。
oc describe network.config cluster
$ oc describe network.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードのプライマリーネットワークインターフェイスの現在の MTU を取得します。
クラスター内のノードをリスト表示するには、次のコマンドを入力します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードのプライマリーネットワークインターフェイスの現在の MTU 設定を取得するには、次のコマンドを入力します。
oc adm node-logs <node> -u ovs-configuration | grep configure-ovs.sh | grep mtu | grep <interface> | head -1
$ oc adm node-logs <node> -u ovs-configuration | grep configure-ovs.sh | grep mtu | grep <interface> | head -1Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<node>- 前のステップの出力をもとに、ノードを指定します。
<interface>- ノードのプライマリーネットワークインターフェイス名を指定します。
出力例
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第3章 Stream Control Transmission Protocol (SCTP) の使用 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ベアメタルクラスターで Stream Control Transmission Protocol (SCTP) を使用できます。
3.1. OpenShift Container Platform での SCTP のサポート リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのホストで SCTP を有効にできます。Red Hat Enterprise Linux CoreOS (RHCOS) で、SCTP モジュールはデフォルトで無効にされています。
SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。
これを有効にすると、SCTP を Pod、サービス、およびネットワークポリシーでプロトコルとして使用できます。Service オブジェクトは、type パラメーターを ClusterIP または NodePort のいずれかの値に設定して定義する必要があります。
3.1.1. SCTP プロトコルを使用した設定例 リンクのコピーリンクがクリップボードにコピーされました!
protocol パラメーターを Pod またはサービスリソース定義の SCTP 値に設定して、Pod またはサービスを SCTP を使用するように設定できます。
以下の例では、Pod は SCTP を使用するように設定されています。
以下の例では、サービスは SCTP を使用するように設定されています。
以下の例では、NetworkPolicy オブジェクトは、特定のラベルの付いた Pod からポート 80 の SCTP ネットワークトラフィックに適用するように設定されます。
3.2. SCTP (Stream Control Transmission Protocol) の有効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのワーカーノードでブラックリストに指定した SCTP カーネルモジュールを読み込み、有効にできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の YAML 定義が含まれる
load-sctp-module.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfigオブジェクトを作成するには、以下のコマンドを入力します。oc create -f load-sctp-module.yaml
$ oc create -f load-sctp-module.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが
Readyに移行すると、設定の更新が適用されます。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. SCTP (Stream Control Transmission Protocol) が有効になっていることの確認 リンクのコピーリンクがクリップボードにコピーされました!
SCTP がクラスターで機能することを確認するには、SCTP トラフィックをリッスンするアプリケーションで Pod を作成し、これをサービスに関連付け、公開されたサービスに接続します。
前提条件
-
クラスターからインターネットにアクセスし、
ncパッケージをインストールすること。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
SCTP リスナーを起動する Pod を作成します。
以下の YAML で Pod を定義する
sctp-server.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力して Pod を作成します。
oc create -f sctp-server.yaml
$ oc create -f sctp-server.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SCTP リスナー Pod のサービスを作成します。
以下の YAML でサービスを定義する
sctp-service.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを作成するには、以下のコマンドを入力します。
oc create -f sctp-service.yaml
$ oc create -f sctp-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SCTP クライアントの Pod を作成します。
以下の YAML で
sctp-client.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Podオブジェクトを作成するには、以下のコマンドを入力します。oc apply -f sctp-client.yaml
$ oc apply -f sctp-client.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サーバーで SCTP リスナーを実行します。
サーバー Pod に接続するには、以下のコマンドを入力します。
oc rsh sctpserver
$ oc rsh sctpserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow SCTP リスナーを起動するには、以下のコマンドを入力します。
nc -l 30102 --sctp
$ nc -l 30102 --sctpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サーバーの SCTP リスナーに接続します。
- ターミナルプログラムで新規のターミナルウィンドウまたはタブを開きます。
sctpserviceサービスの IP アドレスを取得します。以下のコマンドを入力します。oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'$ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow クライアント Pod に接続するには、以下のコマンドを入力します。
oc rsh sctpclient
$ oc rsh sctpclientCopy to Clipboard Copied! Toggle word wrap Toggle overflow SCTP クライアントを起動するには、以下のコマンドを入力します。
<cluster_IP>をsctpserviceサービスのクラスター IP アドレスに置き換えます。nc <cluster_IP> 30102 --sctp
# nc <cluster_IP> 30102 --sctpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 セカンダリーインターフェイスメトリクスのネットワーク割り当てへの関連付け リンクのコピーリンクがクリップボードにコピーされました!
管理者は、pod_network_info メトリクスを使用して、セカンダリーネットワークインターフェイスを分類および監視できます。メトリクスは、通常、特に関連付けられた NetworkAttachmentDefinition リソースに基づき、インターフェイスタイプを識別するラベルを追加することでこれを実行します。
4.1. モニタリングのためのセカンダリーネットワークメトリクスの拡張 リンクのコピーリンクがクリップボードにコピーされました!
セカンダリーデバイス (インターフェイス) は、各種の用途に合わせて使用されます。効果的な集約と監視を可能にするには、セカンダリーネットワークインターフェイスからのメトリクスを分類する必要があります。
公開されるメトリクスにはインターフェイスが含まれますが、インターフェイスの出所は指定されません。これは、追加のインターフェイスがない場合に実行できます。ただし、セカンダリーインターフェイスが追加された場合、インターフェイス名のみに依存すると、その目的を識別してメトリクスを効果的に使用することが困難になるため、問題が発生します。
セカンダリーインターフェイスを追加する場合、名前は追加された順序によって異なります。セカンダリーインターフェイスは、それぞれ異なる目的に使用できる別のネットワークに属することができます。
pod_network_name_info を使用すると、現在のメトリクスをインターフェイスタイプを識別する追加情報を使用して拡張できます。このようにして、メトリクスを集約し、特定のインターフェイスタイプに特定のアラームを追加できます。
ネットワークタイプは、それぞれのセカンダリーネットワーククラスを区別する NetworkAttachmentDefinition リソースの名前から生成されます。たとえば、異なるネットワークに属するインターフェイスや、異なる CNI を使用するインターフェイスは、異なるネットワーク割り当て定義名を使用します。
4.2. Network Metrics Daemon リンクのコピーリンクがクリップボードにコピーされました!
Network Metrics Daemon は、ネットワーク関連のメトリクスを収集し、公開するデーモンコンポーネントです。
kubelet はすでに確認できるネットワーク関連のメトリクスを公開しています。以下は、これらのメトリクスになります。
-
container_network_receive_bytes_total -
container_network_receive_errors_total -
container_network_receive_packets_total -
container_network_receive_packets_dropped_total -
container_network_transmit_bytes_total -
container_network_transmit_errors_total -
container_network_transmit_packets_total -
container_network_transmit_packets_dropped_total
これらのメトリクスのラベルには、とくに以下が含まれます。
- Pod の名前
- Pod の namespace
-
インターフェイス名 (例:
eth0)
これらのメトリクスは、たとえば Multus を使用して、新規インターフェイスが Pod に追加されるまで正常に機能します。
インターフェイスのラベルはインターフェイス名を参照しますが、そのインターフェイスの用途は明確ではありません。多くの異なるインターフェイスがある場合、監視しているメトリクスが参照するネットワークを把握することはできません。
これには、以降のセクションで説明する新規の pod_network_name_info を導入して対応できます。
4.3. ネットワーク名を持つメトリクス リンクのコピーリンクがクリップボードにコピーされました!
Network Metrics daemonset は、固定の値が 0 の pod_network_name_info 測定メトリクスを公開します。
pod_network_name_info の例
pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
ネットワーク名ラベルは、Multus によって追加されるアノテーションを使用して生成されます。これは、ネットワークの割り当て定義が属する namespace の連結と、ネットワーク割り当て定義の名前です。
新しいメトリクスのみでは十分な値が提供されませんが、ネットワーク関連の container_network_* メトリクスと組み合わせて、セカンダリーネットワークの監視に対するサポートを強化します。
以下のような promql クエリーを使用すると、k8s.v1.cni.cncf.io/network-status アノテーションから取得した値とネットワーク名を含む新規のメトリクスを取得できます。
第5章 PTP ハードウェアの使用 リンクのコピーリンクがクリップボードにコピーされました!
5.1. OpenShift クラスターノードの Precision Time Protocol について リンクのコピーリンクがクリップボードにコピーされました!
Precision Time Protocol (PTP) は、ネットワーク内のクロックを同期するのに使用されます。ハードウェアサポートと組み合わせて使用すると、PTP はマイクロ秒未満の精度を実現でき、Network Time Protocol (NTP) よりも正確になります。
PTP を使用する openshift-sdn クラスターで、ハードウェアタイムスタンプに User Datagram Protocol (UDP) を使用している場合、OVN-Kubernetes プラグインに移行すると、Open vSwitch (OVS) ブリッジなどのプライマリーインターフェイスデバイスにハードウェアタイムスタンプを適用できなくなります。そのため、UDP バージョン 4 の設定は、br-ex インターフェイスでは機能しません。
OpenShift Container Platform クラスターノードで linuxptp サービスを設定し、PTP 対応ハードウェアを使用できます。
OpenShift Container Platform Web コンソールまたは OpenShift CLI (oc) を使用して、PTP Operator をデプロイして PTP をインストールします。PTP Operator は linuxptp サービスを作成し、管理し、以下の機能を提供します。
- クラスター内の PTP 対応デバイスの検出。
-
linuxptpサービスの設定の管理。 -
PTP Operator
cloud-event-proxyサイドカーによるアプリケーションのパフォーマンスおよび信頼性に悪影響を与える PTP クロックイベントの通知。
PTP Operator は、ベアメタルインフラストラクチャーでのみプロビジョニングされるクラスターの PTP 対応デバイスと連携します。
5.1.1. PTP ドメインの要素 リンクのコピーリンクがクリップボードにコピーされました!
PTP は、ネットワークに接続された複数のノードを各ノードのクロックと同期するために使用されます。PTP によって同期されるクロックは、リーダーとフォロワーの階層で構成されています。この階層は、1 クロックごとに実行される best master clock (BMC) アルゴリズムによって自動的に作成および更新されます。フォロワークロックはリーダークロックと同期しており、フォロワークロック自体が他のダウンストリームクロックのソースになることができます。
図5.1 ネットワーク内の PTP ノード
PTP クロックの 3 つの主要なタイプを以下に説明します。
- グランドマスタークロック
- グランドマスタークロックは、ネットワーク全体の他のクロックに標準時間情報を提供し、正確で安定した同期を保証します。タイムスタンプを書き込み、他のクロックからの時間の要求に応答します。グランドマスタークロックは、Global Navigation Satellite System (GNSS) のタイムソースと同期します。グランドマスタークロックは、ネットワーク内の時刻の信頼できるソースとして、他のすべてのデバイスに時刻同期を提供します。
- 境界クロック
- 境界クロックには、2 つ以上の通信パスにあるポートがあり、ソースと宛先の宛先を同時に他の宛先クロックに指定できます。境界クロックは、宛先クロックアップストリームとして機能します。宛先クロックはタイミングメッセージを受け取り、遅延に合わせて調整し、ネットワークを渡す新しいソースタイムシグナルを作成します。境界クロックは、ソースクロックと正しく同期され、ソースクロックに直接レポートする接続されたデバイスの数を減らすことができる新しいタイミングパケットを生成します。
- 通常のクロック
- 通常のクロックには、ネットワーク内の位置に応じて、送信元クロックまたは宛先クロックのロールを果たすことができる単一のポート接続があります。通常のクロックは、タイムスタンプの読み取りおよび書き込みが可能です。
5.1.1.1. NTP 上の PTP の利点 リンクのコピーリンクがクリップボードにコピーされました!
PTP が NTP を経由した主な利点の 1 つは、さまざまなネットワークインターフェイスコントローラー (NIC) およびネットワークスイッチにあるハードウェアサポートです。この特化されたハードウェアにより、PTP はメッセージ送信の遅れを説明でき、時間同期の精度を高められます。可能な限りの精度を実現するには、PTP クロック間のすべてのネットワーキングコンポーネントが PTP ハードウェアを有効にすることが推奨されます。
NIC は PTP パケットを送受信した瞬間にタイムスタンプを付けることができるため、ハードウェアベースの PTP は最適な精度を提供します。これをソフトウェアベースの PTP と比較します。これには、オペレーティングシステムによる PTP パケットの追加処理が必要になります。
PTP を有効にする前に、必要なノードに対して NTP が無効になっていることを確認します。MachineConfig カスタムリソースを使用して chrony タイムサービス (chronyd) を無効にすることができます。詳細は、chrony タイムサービスの無効化 を参照してください。
5.1.2. OpenShift Container Platform ノードの linuxptp および gpsd の概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、高精度のネットワーク同期のために、PTP Operator とともに linuxptp および gpsd パッケージを使用します。linuxptp パッケージは、ネットワーク内の PTP タイミング用のツールとデーモンを提供します。Global Navigation Satellite System (GNSS) 対応の NIC を備えたクラスターホストは、GNSS クロックソースとのインターフェイスに gpsd を使用します。
linuxptp パッケージには、システムクロック同期用の ts2phc、pmc、ptp4l、および phc2sys プログラムが含まれています。
- ts2phc
ts2phcは、PTP デバイス間で PTP ハードウェアクロック (PHC) を高精度で同期します。ts2phcはグランドマスタークロック設定で使用されます。Global Navigation Satellite System (GNSS) などの高精度クロックソースから正確なタイミング信号を受信します。GNSS は、大規模な分散ネットワークで使用するための、正確で信頼性の高い同期時刻ソースを提供します。GNSS クロックは通常、数ナノ秒の精度で時刻情報を提供します。ts2phcシステムデーモンは、グランドマスタークロックから時刻情報を読み取り、PHC 形式に変換することにより、グランドマスタークロックからのタイミング情報をネットワーク内の他の PTP デバイスに送信します。PHC 時間は、ネットワーク内の他のデバイスがクロックをグランドマスタークロックと同期させるために使用されます。- pmc
-
pmcは、IEEE 標準 1588.1588 に従って PTP 管理クライアント (pmc) を実装します。pmcは、ptp4lシステムデーモンの基本的な管理アクセスを提供します。pmcは、標準入力から読み取り、選択されたトランスポート経由で出力を送信し、受信した応答を出力します。 - ptp4l
ptp4lは、PTP 境界クロックと通常のクロックを実装し、システムデーモンとして実行されます。ptp4lは、以下を行います。- ハードウェアタイムスタンプを使用して PHC をソースクロックに同期します。
- ソフトウェアタイムスタンプを使用してシステムクロックをソースクロックに同期します。
- phc2sys
-
phc2sysは、システムクロックをネットワークインターフェイスコントローラー (NIC) 上の PHC に同期します。phc2sysシステムデーモンは、PHC のタイミング情報を継続的に監視します。PHC はタイミングエラーを検出すると、システムクロックを修正します。
gpsd パッケージには、ホストクロックと GNSS クロックを同期するためのプログラム ubxtool、gspipe、gpsd が含まれています。
- ubxtool
-
ubxtoolCLI を使用すると、u-blox GPS システムと通信できます。ubxtoolCLI は、u-blox バイナリープロトコルを使用して GPS と通信します。 - gpspipe
-
gpspipeはgpsd出力に接続し、それをstdoutにパイプします。 - gpsd
-
gpsdは、ホストに接続されている 1 つ以上の GPS または AIS 受信機を監視するサービスデーモンです。
5.1.3. PTP グランドマスタークロックの GNSS タイミングの概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内の Global Navigation Satellite System (GNSS) ソースおよびグランドマスタークロック (T-GM) からの高精度 PTP タイミングの受信をサポートします。
OpenShift Container Platform は、Intel E810 Westport Channel NIC を使用した GNSS ソースからの PTP タイミングのみをサポートします。
図5.2 GNSS および T-GM との同期の概要
- Global Navigation Satellite System (GNSS)
GNSS は、測位情報、ナビゲーション情報、タイミング情報を世界中の受信機に提供するために使用される衛星ベースのシステムです。PTP では、高精度で安定した基準クロックソースとして GNSS 受信機がよく使用されます。これらの受信機は、複数の GNSS 衛星から信号を受信し、正確な時刻情報を計算できます。GNSS から取得したタイミング情報は、PTP グランドマスタークロックの基準として使用されます。
GNSS を基準として使用することにより、PTP ネットワークのグランドマスタークロックは、他のデバイスに高精度のタイムスタンプを提供し、ネットワーク全体での正確な同期を可能にします。
- Digital Phase-Locked Loop (DPLL)
- DPLL はネットワーク内の各 PTP ノード間のクロック同期を提供します。DPLL は、ローカルシステムクロック信号の位相を、受信同期信号 (PTP グランドマスタークロックからの PTP メッセージなど) の位相と比較します。DPLL は、ローカルクロックの周波数と位相を継続的に調整して、ローカルクロックと基準クロック間の位相差を最小限に抑えます。
5.1.3.1. GNSS 同期 PTP グランドマスタークロックでのうるう秒イベントの処理 リンクのコピーリンクがクリップボードにコピーされました!
うるう秒は、協定世界時 (UTC) を国際原子時 (TAI) と同期させるために、時折適用される 1 秒の調整です。UTC のうるう秒は予測できません。leap-seconds.list に、国際的に合意されたうるう秒が掲載されています。このファイルは、Earth Rotation and Reference Systems Service (IERS) によって定期的に更新されます。うるう秒が処理されないと、遠端の RAN ネットワークに大きな影響が及ぶ可能性があります。これにより、遠端の RAN アプリケーションが音声通話とデータセッションを直ちに切断する可能性があります。
5.1.4. PTP およびクロック同期エラーイベントについて リンクのコピーリンクがクリップボードにコピーされました!
仮想 RAN (vRAN) などのクラウドネイティブアプリケーションでは、ネットワーク全体の機能に重要なハードウェアタイミングイベントに関する通知へのアクセスが必要です。PTP クロック同期エラーは、分散ユニット (DU) で実行している vRAN アプリケーションなど、低レイテンシーアプリケーションのパフォーマンスおよび信頼性に悪影響を及ぼす可能性があります。
PTP 同期の損失は、RAN ネットワークでは重大なエラーです。ノードで同期が失われると、無線がシャットダウンされ、ネットワークの OTA(Over the Air) トラフィックがワイヤレスネットワーク内の別のノードにシフトされる可能性があります。高速のイベント通知は、クラスターノードが DU で実行している vRAN アプリケーションに対して PTP クロック同期ステータスと通信できるようにすることで、ワークロードのエラーを軽減します。
イベント通知は、同じ DU ノード上で実行されている vRAN アプリケーションで利用できます。パブリッシュ/サブスクライブ REST API は、イベント通知をメッセージングバスに渡します。パブリッシュ/サブスクライブメッセージング (pub-sub メッセージング) は、非同期のサービス間通信アーキテクチャーです。このアーキテクチャーでは、トピックにパブリッシュされたメッセージが、そのトピックのすべてのサブスクライバーによって即座に受信されます。
PTP Operator は、すべての PTP 対応ネットワークインターフェイスの高速イベント通知を生成します。このイベントには、HTTP メッセージバス経由で cloud-event-proxy サイドカーコンテナーを使用してアクセスできます。
PTP 高速イベント通知は、PTP 通常クロック、PTP グランドマスタークロック、または PTP 境界クロックを使用するように設定されたネットワークインターフェイスで使用できます。
5.1.5. 2 カード E810 NIC 設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、シングルおよびデュアル NIC Intel E810 ハードウェアをサポートし、グランドマスタークロック (T-GM) および境界クロック (T-BC) の PTP タイミングを実現します。
- デュアル NIC グランドマスタークロック
デュアル NIC ハードウェアを備えたクラスターホストを PTP グランドマスタークロックとして使用できます。1 枚目の NIC は、Global Navigation Satellite System (GNSS) からタイミング情報を受信します。2 枚目の NIC は、E810 NIC フェイスプレート上の SMA1 Tx/Rx 接続を使用して、1 枚目の NIC からタイミング情報を受信します。クラスターホストのシステムクロックは、GNSS 衛星に接続されている NIC から同期されます。
デュアル NIC グランドマスタークロックは、Remote Radio Unit (RRU) と Baseband Unit (BBU) が同じ無線セルサイトに配置されている分散型 RAN (D-RAN) 構成の機能です。D-RAN は、コアネットワークにリンクするバックホール接続により、複数のサイトに無線機能を分散します。
図5.3 デュアル NIC グランドマスタークロック
注記デュアル NIC T-GM 設定では、1 つの
ts2phcプログラムが、各 NIC に 1 つずつ存在する合計 2 つの PTP ハードウェアクロック (PHC) 上で動作します。- デュアル NIC 境界クロック
ミッドバンドスペクトルカバレッジを提供する 5G 電話会社ネットワークの場合、各仮想分散ユニット (vDU) には 6 つの無線ユニット (RU) への接続が必要です。これらの接続を確立するには、各 vDU ホストに境界クロックとして設定された 2 つの NIC が必要です。
デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の
ptp4lインスタンスをダウンストリームクロックに供給することができます。- デュアル NIC 境界クロックを備えた高可用性システムクロック
Intel E810-XXVDA4 Salem チャネルデュアル NIC ハードウェアを、高可用性システムクロックのタイミングを提供するデュアル PTP 境界クロックとして設定できます。この設定は、別々の NIC 上に複数のタイムソースがある場合に便利です。高可用性があれば、どちらかのタイミングソースが失われたり切断されたりしても、ノードのタイミング同期が失われることはありません。
各 NIC は同じアップストリームリーダークロックに接続されます。高可用性境界クロックは、複数の PTP ドメインを使用してターゲットシステムクロックと同期します。T-BC が高可用性である場合、NIC PHC クロックを同期する 1 つ以上の
ptp4lインスタンスが失敗した場合でも、ホストシステムクロックは正しいオフセットを維持できます。単一の SFP ポートまたはケーブルに障害が発生した場合、境界クロックはリーダークロックと同期したままになります。境界クロックリーダーソースの選択は、A-BMCA アルゴリズムを使用して行われます。詳細は、ITU-T recommendation G.8275.1 を参照してください。
5.1.6. デュアルポート NIC を使用して PTP 通常クロックの冗長性を向上させる リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、PTP タイミングの通常のクロックとして、単一ポートのネットワーキングインターフェイスカード (NIC) をサポートします。冗長性を向上させるために、1 つのポートをアクティブ、もう 1 つのポートをスタンバイとしてデュアルポート NIC を設定できます。
linuxptp サービスをデュアルポート NIC 冗長性を備えた通常のクロックとして設定することは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
この設定では、デュアルポート NIC のポートは次のように動作します。
-
アクティブポートは、
Followingポート状態では通常のクロックとして機能します。 -
スタンバイポートは
Listeningポート状態のままになります。 - アクティブポートに障害が発生した場合、スタンバイポートがアクティブに遷移し、継続的な PTP タイミング同期が確保されます。
-
両方のポートに障害が発生した場合、クロック状態は
HOLDOVER状態に移行し、ホールドオーバータイムアウトが経過するとFREERUN状態に移行します。その後、リーダークロックに再同期します。
PTP の通常クロックは、冗長性を追加して設定することができますが、これはデュアルポート NIC を搭載した x86 アーキテクチャーのノードに限られます。
5.1.7. 3 カード Intel E810 PTP グランドマスタークロック リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、PTP グランドマスタークロック (T-GM) として 3 つの Intel E810 NIC を使用するクラスターホストをサポートしています。
- 3 カードグランドマスタークロック
3 枚の NIC を備えたクラスターホストを PTP グランドマスタークロックとして使用できます。1 枚目の NIC は、Global Navigation Satellite System (GNSS) からタイミング情報を受信します。2 枚目と 3 枚目の NIC は、E810 NIC フェイスプレート上の SMA1 Tx/Rx 接続を使用して、1 つ目の NIC からタイミング情報を受信します。クラスターホストのシステムクロックは、GNSS 衛星に接続されている NIC から同期されます。
3 カード NIC グランドマスタークロックは、Radio Unit (RU) がフロントホールスイッチなしで分散ユニット (DU) に直接接続される分散 RAN (D-RAN) 構成に使用できます (例: RU と DU が同じ無線セルサイトにある場合)。D-RAN は、コアネットワークにリンクするバックホール接続により、複数のサイトに無線機能を分散します。
図5.4 3 カード Intel E810 PTP グランドマスタークロック
注記3 カードの T-GM 設定では、1 つの
ts2phcプロセスがシステム内の 3 つのts2phcインスタンスとして報告されます。
5.2. PTP デバイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
PTP Operator は NodePtpDevice.ptp.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。
PTP Operator は、インストールされている場合、クラスター内の各ノードで Precision Time Protocol (PTP) 対応のネットワークデバイスを検索します。この Operator は、互換性のある PTP 対応ネットワークデバイスを提供する各ノードの NodePtpDevice カスタムリソース (CR) オブジェクトを作成および更新します。
PTP 機能が組み込まれたネットワークインターフェイスコントローラー (NIC) ハードウェアでは、デバイス固有の設定が必要な場合があります。PtpConfig カスタムリソース (CR) でプラグインを設定することで、PTP Operator でサポートされているハードウェア固有の NIC 機能を使用できます。linuxptp-daemon サービスが、plugin スタンザ内の名前付きパラメーターを使用して、特定のハードウェア設定に基づいて linuxptp プロセス、ptp4l および phc2sys を起動します。
OpenShift Container Platform 4.18 では、Intel E810 NIC が PtpConfig プラグインでサポートされています。
5.2.1. CLI を使用した PTP Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- PTP に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
PTP Operator の namespace を作成します。
次の YAML を
ptp-namespace.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow NamespaceCR を作成します。oc create -f ptp-namespace.yaml
$ oc create -f ptp-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PTP Operator の Operator グループを作成します。
次の YAML を
ptp-operatorgroup.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupCR を作成します。oc create -f ptp-operatorgroup.yaml
$ oc create -f ptp-operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PTP Operator にサブスクライブします。
次の YAML を
ptp-sub.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SubscriptionCR を作成します。oc create -f ptp-sub.yaml
$ oc create -f ptp-sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Phase 4.18.0-202301261535 Succeeded
Name Phase 4.18.0-202301261535 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.2. Web コンソールを使用した PTP Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Web コンソールを使用して PTP Operator をインストールできます。
先のセクションで説明されているように namespace および Operator グループを作成する必要があります。
手順
OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator のリストから PTP Operator を選択してから Install をクリックします。
- Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。
オプション: PTP Operator が正常にインストールされていることを確認します。
- Operators → Installed Operators ページに切り替えます。
PTP Operator が Status が InstallSucceeded の状態で openshift-ptp プロジェクトにリスト表示されていることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
- Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
-
Workloads → Pods ページに移動し、
openshift-ptpプロジェクトで Pod のログを確認します。
5.2.3. クラスター内の PTP 対応ネットワークデバイスの検出 リンクのコピーリンクがクリップボードにコピーされました!
PTP 対応ネットワークデバイスを設定できるように、クラスター内に存在する PTP 対応ネットワークデバイスを特定します。
前提条件
- PTP Operator がインストールされている。
手順
クラスター内の PTP 対応ネットワークデバイスの一覧を返すには、以下のコマンドを実行します。
oc get NodePtpDevice -n openshift-ptp -o yaml
$ oc get NodePtpDevice -n openshift-ptp -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.4. linuxptp サービスをグランドマスタークロックとして設定する リンクのコピーリンクがクリップボードにコピーされました!
ホスト NIC を設定する PtpConfig カスタムリソース (CR) を作成することで、linuxptp サービス (ptp4l、phc2sys、ts2phc) をグランドマスタークロック (T-GM) として設定できます。
ts2phc ユーティリティーを使用すると、システムクロックを PTP グランドマスタークロックと同期できるため、ノードは高精度クロック信号をダウンストリームの PTP 通常クロックおよび境界クロックにストリーミングできます。
次の PtpConfig CR の例をベースとして使用して、linuxptp サービスを Intel Westport Channel E810-XXVDA4T ネットワークインターフェイスの T-GM として設定してください。
PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
- 実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに Intel E810 Westport Channel NIC がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfigCR を作成します。以下に例を示します。要件に応じて、デプロイメントに次の T-GM 設定のいずれかを使用します。YAML を
grandmaster-clock-ptp-config.yamlファイルに保存します。例5.1 E810 NIC の PTP グランドマスタークロック設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記E810 Westport Channel NIC の場合は、
ts2phc.nmea_serialportの値を/dev/gnss0に設定します。以下のコマンドを実行して CR を作成します。
oc create -f grandmaster-clock-ptp-config.yaml
$ oc create -f grandmaster-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.4.1. デュアル E810 NIC のグランドマスタークロックとして linuxptp サービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
NIC を設定する PtpConfig カスタムリソース (CR) を作成することにより、linuxptp サービス (ptp4l、phc2sys、ts2phc) を 2 カード E810 NIC のグランドマスタークロック (T-GM) として設定できます。
次の E810 NIC の場合、T-GM として linuxptp サービスを設定できます。
- Intel E810-XXVDA4T Westport Channel NIC
- Intel E810-CQDA2T Logan Beach NIC
分散型 RAN (D-RAN) のユースケースでは、次の方法で 2 カード NIC の PTP を設定できます。
- NIC 1 を、Global Navigation Satellite System (GNSS) のタイムソースに同期します。
-
NIC 2 を、NIC 1 によって提供される 1PPS タイミング出力に同期します。この設定は、
PtpConfigCR の PTP ハードウェアプラグインによって提供します。
2 カード PTP T-GM 設定では、ptp4l のインスタンス 1 つと ts2phc のインスタンス 1 つが使用されます。ptp4l および ts2phc プログラムは、各 NIC に 1 つずつ存在する 2 つの PTP ハードウェアクロック (PHC) 上で動作するようにそれぞれ設定されています。ホストのシステムクロックは、GNSS タイムソースに接続されている NIC から同期されます。
次の PtpConfig CR の例をベースとして使用し、linuxptp サービスをデュアル Intel E810 ネットワークインターフェイスの T-GM として設定します。
PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
- 実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに 2 枚の Intel E810 NIC がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfigCR を作成します。以下に例を示します。次の YAML を
grandmaster-clock-ptp-config-dual-nics.yamlファイルに保存します。例5.2 デュアル E810 NIC の PTP グランドマスタークロック設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ts2phc.nmea_serialportの値を/dev/gnss0に設定します。以下のコマンドを実行して CR を作成します。
oc create -f grandmaster-clock-ptp-config-dual-nics.yaml
$ oc create -f grandmaster-clock-ptp-config-dual-nics.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.4.2. 3 カード E810 NIC のグランドマスタークロックとして linuxptp サービスを設定する リンクのコピーリンクがクリップボードにコピーされました!
NIC を設定する PtpConfig カスタムリソース (CR) を作成することにより、linuxptp サービス (ptp4l、phc2sys、ts2phc) を 3 カード E810 NIC のグランドマスタークロック (T-GM) として設定できます。
次の E810 NIC の場合、3 枚の NIC を使用する T-GM として linuxptp サービスを設定できます。
- Intel E810-XXVDA4T Westport Channel NIC
- Intel E810-CQDA2T Logan Beach NIC
分散型 RAN (D-RAN) のユースケースでは、次の方法で 3 カード NIC の PTP を設定できます。
- NIC 1 を、Global Navigation Satellite System (GNSS) に同期します。
- NIC 2 と 3 を、1PPS フェイスプレート接続で NIC 1 に同期します。
次の PtpConfig CR の例をベースとして使用し、linuxptp サービスを 3 カード Intel E810 の T-GM として設定します。
前提条件
- 実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに 3 枚の Intel E810 NIC がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfigCR を作成します。以下に例を示します。次の YAML を
three-nic-grandmaster-clock-ptp-config.yamlファイルに保存します。例5.3 3 カード E810 NIC の PTP グランドマスタークロック設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ts2phc.nmea_serialportの値を/dev/gnss0に設定します。以下のコマンドを実行して CR を作成します。
oc create -f three-nic-grandmaster-clock-ptp-config.yaml
$ oc create -f three-nic-grandmaster-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m3q 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x6zkn 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m3q 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x6zkn 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。次のコマンドを実行し、
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを調べます。oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.5. グランドマスタークロックの PtpConfig 設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
このリファレンスでは、linuxptp サービス (ptp4l、phc2sys、ts2phc) をグランドマスタークロックとして設定する PtpConfig カスタムリソース (CR) の設定オプションを説明します。
| PtpConfig CR フィールド | 説明 |
|---|---|
|
|
grandmaster クロック動作用に NIC を設定する
プラグインメカニズムにより、PTP Operator は自動ハードウェア設定を行うことができます。Intel Westport Channel NIC または Intel Logan Beach NIC では、 |
|
|
|
|
|
|
|
| データを破棄する前に、送信者からの送信 (TX) タイムスタンプを待機する最大時間を指定します。 |
|
| JBOD 境界クロック時間遅延値を指定します。この値は、ネットワーク時間デバイス間で受け渡される時間値を修正するために使用されます。 |
|
|
注記
ここにリストされているネットワークインターフェイスがグランドマスターとして設定されており、 |
|
|
|
|
|
|
|
|
オプション: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.5.1. グランドマスタークロッククラスの同期状態のリファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の表は、PTP グランドマスタークロック (T-GM) の gm.ClockClass の状態を示しています。クロッククラスの状態では、Primary Reference Time Clock (PRTC) またはその他のタイミングソースに関連する精度と安定性に基づいて T-GM クロックが分類されます。
ホールドオーバー仕様とは、PTP クロックがプライマリータイムソースから更新を受信せずに同期を維持できる時間です。
| クロッククラスの状態 | 説明 |
|---|---|
|
|
T-GM クロックは |
|
|
T-GM クロックは |
|
|
T-GM クロックは |
詳細は、"Phase/time traceability information", ITU-T G.8275.1/Y.1369.1 Recommendations を参照してください。
5.2.5.2. Intel E810 NIC ハードウェア設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
ここでは、Intel E810 ハードウェアプラグイン を使用して E810 ネットワークインターフェイスを PTP グランドマスタークロックとして設定する方法を説明します。ハードウェアピンの設定により、ネットワークインターフェイスがシステム内の他のコンポーネントやデバイスとどのようにやり取りするかが決まります。Intel E810 NIC には、外部 1PPS 信号用のコネクターが 4 つあります (SMA1、SMA2、U.FL1、U.FL2)。
| ハードウェアピン | 推奨設定 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
次の例に示すように、spec.profile.plugins.e810.pins パラメーターを使用して、Intel E810 NIC のピン設定を行うことができます。
pins:
<interface_name>:
<connector_name>: <function> <channel_number>
pins:
<interface_name>:
<connector_name>: <function> <channel_number>
ここでは、以下のようになります。
<function>: ピンのロールを指定します。以下の値は、pin ロールに関連付けられています。
-
0: 無効 -
1: Rx (受信タイムスタンプ) -
2:Tx (送信タイムスタンプ)
<channel number>: 物理コネクターに関連付けられた番号。次のチャネル番号が物理コネクターに関連付けられています。
-
1:SMA1またはU.FL1 -
2:SMA2またはU.FL2
例:
-
0 1:SMA1またはU.FL1にマッピングされたピンを無効にします。 -
1 2: Rx 機能をSMA2またはU.FL2に割り当てます。
SMA1 コネクターと U.FL1 コネクターはチャネル 1 を共有します。SMA2 コネクターと U.FL2 コネクターはチャネル 2 を共有します。
PtpConfig カスタムリソース (CR) で GNSS クロックを設定するには、spec.profile.plugins.e810.ublxCmds パラメーターを設定します。
T-GM GPS アンテナケーブルシグナルの遅延を補正するには、オフセット値を設定する必要があります。最適な T-GM アンテナオフセット値を設定するには、GNSS アンテナケーブルシグナルの遅延を正確に測定します。Red Hat はこの測定をサポートしたり、必要な遅延オフセットの値を提供したりすることはできません。
これらの ublxCmds スタンザはそれぞれ、ubxtool コマンドを使用してホスト NIC に適用する設定と対応しています。以下に例を示します。
- 1
- 測定された T-GM アンテナ遅延オフセット (ナノ秒単位)。必要な遅延オフセット値を取得するには、外部テスト機器を使用してケーブル遅延を測定する必要があります。
次の表は、同等の ubxtool コマンドを示しています。
| ubxtool コマンド | 説明 |
|---|---|
|
|
アンテナ電圧制御を有効にし、 |
|
| アンテナが GPS 信号を受信できるようにします。 |
|
| Galileo GPS 衛星から信号を受信するようにアンテナを設定します。 |
|
| アンテナが GLONASS GPS 衛星から信号を受信できないようにします。 |
|
| アンテナが BeiDou GPS 衛星から信号を受信できないようにします。 |
|
| アンテナが SBAS GPS 衛星から信号を受信できないようにします。 |
|
| GNSS 受信機のサーベイインプロセスを設定して、初期位置の推定を改善します。最適な結果が得られるまでに最大 24 時間かかる場合があります。 |
|
| ハードウェアの自動スキャンを 1 回実行し、NIC の状態と構成設定を報告します。 |
5.2.5.3. デュアル E810 NIC 設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
ここでは、Intel E810 ハードウェアプラグイン を使用して、E810 ネットワークインターフェイスのペアを PTP グランドマスタークロック (T-GM) として設定する方法を説明します。
デュアル NIC クラスターホストを設定する前に、1PPS フェイスプレート接続を使用して 2 つの NIC を SMA1 ケーブルで接続する必要があります。
デュアル NIC T-GM を設定する際は、SMA1 接続ポートを使用して NIC を接続する場合に発生する 1PPS 信号遅延を補正する必要があります。ケーブルの長さ、周囲温度、コンポーネントと製作公差などのさまざまな要因が信号遅延に影響を与える可能性があります。遅延を補正するには、信号遅延のオフセットに使用する特定の値を計算する必要があります。
| PtpConfig フィールド | 説明 |
|---|---|
|
| PTP Operator E810 ハードウェアプラグインを使用して E810 ハードウェアピンを設定します。
|
|
|
|
|
|
複数の NIC のサポートを有効にするには、 |
spec.profile.plugins.e810.pins リスト内の各値は、<function> <channel_number> 形式に従います。
ここでは、以下のようになります。
<function>: pin ロールを指定します。以下の値は、pin ロールに関連付けられています。
-
0: 無効 -
1: 受信 (Rx) - 1PPS IN 用 -
2: 送信 (Tx) - 1PPS OUT 用
<channel_number>: 物理コネクターに関連付けられた番号。次のチャネル番号が物理コネクターに関連付けられています。
-
1:SMA1またはU.FL1 -
2:SMA2またはU.FL2
例:
-
2 1:SMA1で1PPS OUT(Tx) を有効にします。 -
1 1:SMA1で1PPS IN(Rx) を有効にします。
PTP Operator は、これらの値を Intel E810 ハードウェアプラグインに渡し、各 NIC の sysfs ピン設定インターフェイスに書き込みます。
5.2.5.4. 3 カード E810 NIC 設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
ここでは、3 カード E810 NIC を PTP グランドマスタークロック (T-GM) として設定する方法を説明します。
3 カードのクラスターホストを設定する前に、1PPS フェースプレート接続を使用して 3 枚の NIC を接続する必要があります。プライマリー NIC の 1PPS_out 出力は、他の 2 枚の NIC に提供されます。
3 カードの T-GM を設定する際は、SMA1 接続ポートを使用して NIC を接続する場合に発生する 1PPS 信号遅延を補正する必要があります。ケーブルの長さ、周囲温度、コンポーネントと製作公差などのさまざまな要因が信号遅延に影響を与える可能性があります。遅延を補正するには、信号遅延のオフセットに使用する特定の値を計算する必要があります。
| PtpConfig フィールド | 説明 |
|---|---|
|
| PTP Operator E810 ハードウェアプラグインを使用して E810 ハードウェアピンを設定します。
|
|
|
|
|
|
複数の NIC のサポートを有効にするには、 |
5.2.6. GNSS をソースとするグランドマスタークロックのホールドオーバー リンクのコピーリンクがクリップボードにコピーされました!
ホールドオーバーにより、Global Navigation Satellite System (GNSS) ソースが利用できない場合でもグランドマスター (T-GM) クロックは同期パフォーマンスを維持できます。この期間中、T-GM クロックは内部オシレーターとホールドオーバーパラメーターに依存してタイミングの中断を削減します。
PTPConfig カスタムリソース (CR) で次のホールドオーバーパラメーターを設定することにより、ホールドオーバー動作を定義できます。
MaxInSpecOffset-
許容される最大オフセットをナノ秒単位で指定します。T-GM クロックが
MaxInSpecOffset値を超えると、FREERUN状態 (クロッククラス状態gm.ClockClass 248) に遷移します。 LocalHoldoverTimeout-
T-GM クロックが
FREERUN状態に遷移するまでホールドオーバー状態を維持する最大期間 (秒単位) を指定します。 LocalMaxHoldoverOffSet- ホールドオーバー状態にあるときに T-GM クロックが到達できる最大オフセットをナノ秒単位で指定します。
MaxInSpecOffset 値が LocalMaxHoldoverOffset 値より小さく、T-GM クロックが最大オフセット値を超える場合、T-GM クロックはホールドオーバー状態から FREERUN 状態に遷移します。
LocalMaxHoldoverOffSet 値が MaxInSpecOffset 値より小さい場合、クロックが最大オフセットに達する前にホールドオーバータイムアウトが発生します。この問題を解決するには、MaxInSpecOffset フィールドと LocalMaxHoldoverOffset フィールドを同じ値に設定します。
クロッククラスの状態の詳細は、「グランドマスタークロッククラス同期状態リファレンス」のドキュメントを参照してください。
T-GM クロックは、ホールドオーバーパラメーターの LocalMaxHoldoverOffSet と LocalHoldoverTimeout を使用してスロープを計算します。スロープは、位相オフセットが時間の経過とともに変化するレートです。これはナノ秒/秒単位で測定され、設定された値は、指定された期間内にオフセットがどれだけ増加するかを示します。
T-GM クロックはスロープ値を使用して時間ドリフトを予測および補正し、ホールドオーバー中のタイミングの中断を削減します。T-GM クロックは、次の式を使用してスロープを計算します。
スロープ =
localMaxHoldoverOffSet/localHoldoverTimeoutたとえば、
LocalHoldOverTimeoutパラメーターが 60 秒に設定され、LocalMaxHoldoverOffsetパラメーターが 3000 ナノ秒に設定されている場合、スロープは次のように計算されます。スロープ = 3000 ナノ秒/60 秒 = 50 ナノ秒/秒
T-GM クロックは 60 秒で最大オフセットに達します。
位相オフセットはピコ秒からナノ秒に変換されます。その結果、ホールドオーバー中に計算された位相オフセットはナノ秒で表され、スロープはナノ秒/秒で表されます。
次の図は、GNSS をソースとする T-GM クロックのホールドオーバー動作を示しています。
図5.5 GNSS をソースとする T-GM クロックのホールドオーバー
GNSS シグナルが失われ、T-GM クロックが HOLDOVER モードになります。T-GM クロックは内部クロックを使用して時間の精度を維持します。
GNSS シグナルが復元され、T-GM クロックは再び LOCKED モードになります。GNSS シグナルが復元されると、ts2phc オフセット、Digital Phase-Locked Loop (DPLL) 位相オフセット、GNSS オフセットなど、同期チェーン内のすべての依存コンポーネントが安定した LOCKED モードに達した後にのみ、T-GM クロックは再び LOCKED モードになります。
GNSS シグナルが再び失われ、T-GM クロックは再度 HOLDOVER モードになります。タイムエラーの増加が始まります。
トレーサビリティの長期的な損失により、タイムエラーが MaxInSpecOffset しきい値を超えます。
GNSS シグナルが復元され、T-GM クロックが同期を再開します。タイムエラーの減少が始まります。
タイムエラーが減少し、MaxInSpecOffset しきい値内に戻ります。
5.2.7. PTP グランドマスタークロックの動的なうるう秒処理の設定 リンクのコピーリンクがクリップボードにコピーされました!
PTP Operator コンテナーイメージには、リリース時に利用可能な最新の leap-seconds.list ファイルが含まれています。PTP Operator は、Global Positioning System (GPS) アナウンスを使用してうるう秒ファイルを自動的に更新するように設定できます。
うるう秒情報は、openshift-ptp namespace の leap-configmap という名前の自動生成された ConfigMap リソースに保存されます。PTP Operator は、ts2phc プロセスがアクセスできる linuxptp-daemon Pod 内のボリュームとして leap-configmap リソースをマウントします。
GPS 衛星が新しいうるう秒データをブロードキャストすると、PTP Operator は leap-configmap リソースを新しいデータで更新します。ts2phc プロセスは変更を自動的に取得します。
次の手順は参考用です。PTP Operator のバージョン 4.18 では、デフォルトで自動うるう秒管理が有効になります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールし、クラスターに PTP グランドマスタークロック (T-GM) を設定した。
手順
PtpConfigCR のphc2sysOptsセクションで自動うるう秒処理を設定します。以下のオプションを設定します。phc2sysOpts: -r -u 0 -m -N 8 -R 16 -S 2 -s ens2f0 -n 24
phc2sysOpts: -r -u 0 -m -N 8 -R 16 -S 2 -s ens2f0 -n 241 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記以前は、過去のうるう秒を考慮するために、
phc2sys設定 (-O -37) のオフセット調整が T-GM に必要でした。これは不要になりました。PtpConfigCR のspec.profile.plugins.e810.ublxCmdsセクションで、GPS レシーバーによるNAV-TIMELSメッセージの定期的な報告を有効にするように Intel e810 NIC を設定します。以下に例を示します。- args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248"- args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
設定した T-GM が接続先の GPS から
NAV-TIMELSメッセージを受信していることを確認します。以下のコマンドを実行します。oc -n openshift-ptp -c linuxptp-daemon-container exec -it $(oc -n openshift-ptp get pods -o name | grep daemon) -- ubxtool -t -p NAV-TIMELS -P 29.20
$ oc -n openshift-ptp -c linuxptp-daemon-container exec -it $(oc -n openshift-ptp get pods -o name | grep daemon) -- ubxtool -t -p NAV-TIMELS -P 29.20Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow leap-configmapリソースが PTP Operator によって正常に生成され、leap-seconds.list の最新バージョンに更新されていることを確認します。以下のコマンドを実行します。oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}'$ oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.8. linuxptp サービスを境界クロックとして設定 リンクのコピーリンクがクリップボードにコピーされました!
PtpConfig カスタムリソース (CR) オブジェクトを作成して、linuxptp サービス (ptp4l、phc2sys を設定できます。
次の例の PtpConfig CR を、特定のハードウェアおよび環境の境界クロックとして linuxptp サービスを設定する基礎として使用します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
以下の
PtpConfigCR を作成してから、YAML をboundary-clock-ptp-config.yamlファイルに保存します。PTP 境界クロックの設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表5.7 PTP 境界クロックの CR 設定オプション CR フィールド 説明 namePtpConfigCR の名前。profile1 つ以上の
profileオブジェクトの配列を指定します。nameプロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
ptp4lOptsptp4lサービスのシステム設定オプションを指定します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名-i <interface>およびサービス設定ファイル-f /etc/ptp4l.confを含めないでください。ptp4lConfptp4lを境界クロックとして起動するために必要な設定を指定します。たとえば、ens1f0はグランドマスタークロックから同期し、ens1f3は接続されたデバイスを同期します。<interface_1>同期クロックを受信するインターフェイス。
<interface_2>synchronization クロックを送信するインターフェイス。
tx_timestamp_timeoutIntel Columbiaville 800 Series NIC の場合、
tx_timestamp_timeoutを50に設定します。boundary_clock_jbodIntel Columbiaville 800 Series NIC の場合、
boundary_clock_jbodが0に設定されていることを確認します。Intel Fortville X710 シリーズ NIC の場合、boundary_clock_jbodが1に設定されていることを確認します。phc2sysOptsphc2sysサービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator はphc2sysサービスを開始しません。ptpSchedulingPolicyptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値は
SCHED_OTHERです。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFOを使用してください。ptpSchedulingPriorityptpSchedulingPolicyがSCHED_FIFOに設定されている場合に、ptp4lおよびphc2sysプロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。ptpSchedulingPriorityフィールドは、ptpSchedulingPolicyがSCHED_OTHERに設定されている場合は使用されません。ptpClockThresholdオプション:
ptpClockThresholdが存在しない場合、ptpClockThresholdフィールドにはデフォルト値が使用されます。ptpClockThresholdは、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。recommendprofileがノードに適用される方法を定義する 1 つ以上のrecommendオブジェクトの配列を指定します。.recommend.profileprofileセクションで定義される.recommend.profileオブジェクト名を指定します。.recommend.priority0から99までの整数値でpriorityを指定します。数値が大きいほど優先度が低くなるため、99の優先度は10よりも低くなります。ノードがmatchフィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。.recommend.match.recommend.matchルールをnodeLabelまたはnodeNameの値に指定します。.recommend.match.nodeLabeloc get nodes --show-labelsコマンドを使用して、ノードオブジェクトのnode.LabelsフィールドのkeyでnodeLabelを設定します。例:node-role.kubernetes.io/worker。.recommend.match.nodeNameoc get nodesコマンドを使用して、nodeNameをノードオブジェクトのnode.Nameフィールドの値に設定します。compute-1.example.comはその例です。以下のコマンドを実行して CR を作成します。
oc create -f boundary-clock-ptp-config.yaml
$ oc create -f boundary-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.8.1. linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定 リンクのコピーリンクがクリップボードにコピーされました!
NIC ごとに PtpConfig カスタムリソース (CR) オブジェクトを作成することにより、linuxptp サービス (ptp4l、phc2sys) をデュアル NIC ハードウェアの境界クロックとして設定できます。
デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l インスタンスをダウンストリームクロックに供給することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
「linuxptp サービスを境界クロックとして設定」の参照 CR を各 CR の基礎として使用して、NIC ごとに 1 つずつ、2 つの個別の
PtpConfigCR を作成します。以下に例を示します。phc2sysOptsの値を指定して、boundary-clock-ptp-config-nic1.yamlを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow boundary-clock-ptp-config-nic2.yamlを作成し、phc2sysOptsフィールドを完全に削除して、2 番目の NIC のphc2sysサービスを無効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 2 番目の NIC の境界クロックとして
ptp4lを開始するために必要なインターフェイスを指定します。
注記2 番目の NIC で
phc2sysサービスを無効にするには、2 番目のPtpConfigCR からphc2sysOptsフィールドを完全に削除する必要があります。
次のコマンドを実行して、デュアル NIC
PtpConfigCR を作成します。1 番目の NIC の PTP を設定する CR を作成します。
oc create -f boundary-clock-ptp-config-nic1.yaml
$ oc create -f boundary-clock-ptp-config-nic1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 2 番目の NIC の PTP を設定する CR を作成します。
oc create -f boundary-clock-ptp-config-nic2.yaml
$ oc create -f boundary-clock-ptp-config-nic2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PTP Operator が両方の NIC に
PtpConfigCR を適用したことを確認します。デュアル NIC ハードウェアがインストールされているノードに対応するlinuxptpデーモンのログを調べます。たとえば、以下のコマンドを実行します。oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ptp4l[80828.335]: [ptp4l.1.config] master offset 5 s2 freq -5727 path delay 519 ptp4l[80828.343]: [ptp4l.0.config] master offset -5 s2 freq -10607 path delay 533 phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1 s2 freq -87239 delay 539
ptp4l[80828.335]: [ptp4l.1.config] master offset 5 s2 freq -5727 path delay 519 ptp4l[80828.343]: [ptp4l.0.config] master offset -5 s2 freq -10607 path delay 533 phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1 s2 freq -87239 delay 539Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.8.2. デュアル NIC Intel E810 PTP 境界クロック用の高可用性システムクロックとして linuxptp を設定する リンクのコピーリンクがクリップボードにコピーされました!
linuxptp サービス ptp4l および phc2sys を、デュアル PTP 境界クロック (T-BC) の高可用性 (HA) システムクロックとして設定できます。
高可用性システムクロックは、2 つの境界クロックとして設定されたデュアル NIC Intel E810 Salem チャネルハードウェアからの複数のタイムソースを使用します。2 つの境界クロックインスタンスが HA セットアップに参加し、それぞれ独自の設定プロファイルを持ちます。各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l インスタンスをダウンストリームクロックに供給します。
NIC を T-BC として設定する 2 つの PtpConfig カスタムリソース (CR) オブジェクトと、2 つの NIC 間の高可用性を設定する 3 番目の PtpConfig CR を作成します。
HA を設定する PtpConfig CR で phc2SysOpts オプションを 1 回設定します。2 つの NIC を設定する PtpConfig CR で phc2sysOpts フィールドを空の文字列に設定します。これにより、2 つのプロファイルに対して個別の phc2sys プロセスがセットアップされなくなります。
3 番目の PtpConfig CR は、高可用性システムクロックサービスを設定します。CR は、ptp4l プロセスが実行されないように、ptp4lOpts フィールドを空の文字列に設定します。CR は、spec.profile.ptpSettings.haProfiles キーの下に ptp4l 設定のプロファイルを追加し、それらのプロファイルのカーネルソケットパスを phc2sys サービスに渡します。ptp4l 障害が発生すると、phc2sys サービスはバックアップ ptp4l 設定に切り替わります。プライマリープロファイルが再びアクティブになると、phc2sys サービスは元の状態に戻ります。
HA を設定するために使用する 3 つの PtpConfig CR すべてに対して、spec.recommend.priority を同じ値に設定していることを確認します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
- Intel E810 Salem チャネルデュアル NIC を使用してクラスターノードを設定します。
手順
「linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定」の CR を各 CR の参照として使用して、NIC ごとに 1 つずつ、2 つの個別の
PtpConfigCR を作成します。phc2sysOptsフィールドに空の文字列を指定して、ha-ptp-config-nic1.yamlファイルを作成します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、NIC 1 に
PtpConfigCR を適用します。oc create -f ha-ptp-config-nic1.yaml
$ oc create -f ha-ptp-config-nic1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow phc2sysOptsフィールドに空の文字列を指定して、ha-ptp-config-nic2.yamlファイルを作成します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、NIC 2 に
PtpConfigCR を適用します。oc create -f ha-ptp-config-nic2.yaml
$ oc create -f ha-ptp-config-nic2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
HA システムクロックを設定する
PtpConfigCR を作成します。以下に例を示します。ptp-config-for-ha.yamlファイルを作成します。2 つの NIC を設定するPtpConfigCR で設定されているmetadata.nameフィールドと一致するようにhaProfilesを設定します。例:haProfiles: ha-ptp-config-nic1,ha-ptp-config-nic2Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ptp4lOptsフィールドを空の文字列に設定します。空でない場合、p4ptlプロセスは重大なエラーで開始されます。
重要個々の NIC を設定する
PtpConfigCR の前に、高可用性PtpConfigCR を適用しないでください。次のコマンドを実行して、HA
PtpConfigCR を適用します。oc create -f ptp-config-for-ha.yaml
$ oc create -f ptp-config-for-ha.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PTP Operator が
PtpConfigCR を正しく適用したことを確認します。以下の手順を実行します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkrb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com ptp-operator-657bbq64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkrb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com ptp-operator-657bbq64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記linuxptp-daemonPod は 1 つだけ存在する必要があります。次のコマンドを実行して、プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.9. linuxptp サービスを通常のクロックとして設定 リンクのコピーリンクがクリップボードにコピーされました!
PtpConfig カスタムリソース (CR) オブジェクトを作成して、linuxptp サービス (ptp4l、phc2sys) を通常のクロックとして設定できます。
次の例の PtpConfig CR を、特定のハードウェアおよび環境の通常クロックとして linuxptp サービスを設定する基礎として使用します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効な場合にのみ必要です。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
以下の
PtpConfigCR を作成してから、YAML をordinary-clock-ptp-config.yamlファイルに保存します。PTP 通常クロックの設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表5.8 PTP 通常クロック CR 設定のオプション CR フィールド 説明 namePtpConfigCR の名前。profile1 つ以上の
profileオブジェクトの配列を指定します。各プロファイルの名前は一意である必要があります。interfaceptp4lサービスで使用するネットワークインターフェイスを指定します (例:ens787f1)。ptp4lOptsptp4lサービスのシステム設定オプションを指定します。たとえば、-2で IEEE 802.3 ネットワークトランスポートを選択します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名-i <interface>およびサービス設定ファイル-f /etc/ptp4l.confを含めないでください。このインターフェイスで PTP 高速イベントを使用するには、--summary_interval -4を追加します。phc2sysOptsphc2sysサービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator はphc2sysサービスを開始しません。Intel Columbiaville 800 Series NIC の場合、phc2sysOptsオプションを-a -r -m -n 24 -N 8 -R 16に設定します。-mはメッセージをstdoutに出力します。linuxptp-daemonDaemonSetはログを解析し、Prometheus メトリクスを生成します。ptp4lConfデフォルトの
/etc/ptp4l.confファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。tx_timestamp_timeoutIntel Columbiaville 800 Series NIC の場合、
tx_timestamp_timeoutを50に設定します。boundary_clock_jbodIntel Columbiaville 800 Series NIC の場合、
boundary_clock_jbodを0に設定します。ptpSchedulingPolicyptp4lとphc2sysプロセスのスケジューリングポリシー。デフォルト値はSCHED_OTHERです。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFOを使用してください。ptpSchedulingPriorityptpSchedulingPolicyがSCHED_FIFOに設定されている場合に、ptp4lおよびphc2sysプロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。ptpSchedulingPriorityフィールドは、ptpSchedulingPolicyがSCHED_OTHERに設定されている場合は使用されません。ptpClockThresholdオプション:
ptpClockThresholdが存在しない場合、ptpClockThresholdフィールドにはデフォルト値が使用されます。ptpClockThresholdは、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。recommendprofileがノードに適用される方法を定義する 1 つ以上のrecommendオブジェクトの配列を指定します。.recommend.profileprofileセクションで定義される.recommend.profileオブジェクト名を指定します。.recommend.priority通常クロックの
.recommend.priorityを0に設定します。.recommend.match.recommend.matchルールをnodeLabelまたはnodeNameの値に指定します。.recommend.match.nodeLabeloc get nodes --show-labelsコマンドを使用して、ノードオブジェクトのnode.LabelsフィールドのkeyでnodeLabelを設定します。例:node-role.kubernetes.io/worker。.recommend.match.nodeNameoc get nodesコマンドを使用して、nodeNameをノードオブジェクトのnode.Nameフィールドの値に設定します。compute-1.example.comはその例です。次のコマンドを実行して、
PtpConfigCR を作成します。oc create -f ordinary-clock-ptp-config.yaml
$ oc create -f ordinary-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.9.1. PTP の通常クロックリファレンスとしての Intel Columbiaville E800 シリーズ NIC リンクのコピーリンクがクリップボードにコピーされました!
次の表は、Intel Columbiaville E800 シリーズ NIC を通常のクロックとして使用するために、PTP リファレンス設定に加える必要がある変更を説明します。クラスターに適用する PtpConfig カスタムリソース (CR) に変更を加えます。
| PTP 設定 | 推奨設定 |
|---|---|
|
|
|
|
|
|
|
|
|
phc2sysOpts の場合、-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリクスを生成します。
5.2.9.2. デュアルポート NIC 冗長性を備えた通常のクロックとして linuxptp サービスを設定する リンクのコピーリンクがクリップボードにコピーされました!
PtpConfig カスタムリソース (CR) オブジェクトを作成することで、linuxptp サービス (ptp4l、phc2sys) をデュアルポート NIC 冗長性を備えた通常のクロックとして設定できます。通常のクロックのデュアルポート NIC 設定では、1 つのポートに障害が発生した場合、スタンバイポートが引き継ぎ、PTP タイミング同期を維持します。
linuxptp サービスをデュアルポート NIC 冗長性を備えた通常のクロックとして設定することは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
- ノードは、デュアルポート NIC を備えた x86_64 アーキテクチャーを使用します。
手順
次の
PtpConfigCR を作成し、YAML をoc-dual-port-ptp-config.yamlファイルに保存します。PTP 通常クロックデュアルポート設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ptp4lサービスのシステム設定オプションを指定します。- 2
ptp4lサービスのインターフェイス設定を指定します。この例では、ens3f2およびens3f3インターフェイスにmasterOnly 0を設定すると、ens3インターフェイスの両方のポートがリーダークロックまたはフォロワークロックとして実行できるようになります。この設定は、slaveOnly 1仕様と組み合わせることで、1 つのポートがアクティブな通常クロックとして動作し、他のポートがListeningポート状態でスタンバイ通常クロックとして動作するようにします。- 3
ptp4lを通常のクロックとしてのみ実行するように設定します。
次のコマンドを実行して、
PtpConfigCR を作成します。oc create -f oc-dual-port-ptp-config.yaml
$ oc create -f oc-dual-port-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.10. PTP ハードウェアの FIFO 優先スケジューリングの設定 リンクのコピーリンクがクリップボードにコピーされました!
低遅延のパフォーマンスを確保する必要のある通信業者などのデプロイメントタイプでは、PTP デーモンスレッドが、残りのインフラストラクチャーコンポーネントとともに、限られた CPU リソースで実行されます。デフォルトでは、PTP スレッドは SCHED_OTHER ポリシーで実行されます。負荷が高いと、エラーなしで運用する必要のある、これらのスレッドのスケジューリングでレイテンシーが発生する可能性があります。
スケジューリングのレイテンシーでエラーが発生する可能性を軽減するために、SCHED_FIFO ポリシーでスレッドを実行できるように、PTP Operator の linuxptp サービスを設定できます。PtpConfig CR に SCHED_FIFO が設定されている場合には、ptp4l と phc2sys は、PtpConfig CR の ptpSchedulingPriority フィールドで設定された優先順位で、chrt の下の親コンテナーで実行されます。
ptpSchedulingPolicy の設定は任意です。レイテンシーエラーが発生している場合にのみ必要です。
手順
PtpConfigCR プロファイルを編集します。oc edit PtpConfig -n openshift-ptp
$ oc edit PtpConfig -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow ptpSchedulingPolicyとptpSchedulingPriorityフィールドを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
保存して終了すると、
PtpConfigCR に変更が適用されます。
検証
PtpConfigCR が適用されたlinuxptp-daemonPod と対応するノードの名前を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow ptp4lプロセスが、更新されたchrtFIFO 優先度で実行されていることを確認します。oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt
$ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2 --summary_interval -4 -m
I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2 --summary_interval -4 -mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.11. linuxptp サービスのログフィルタリングの設定 リンクのコピーリンクがクリップボードにコピーされました!
linuxptp デーモンは、デバッグに使用できるログを生成します。ストレージ容量が制限されている通信業者などのデプロイメントタイプでは、これらのログによりストレージ需要が増大する可能性があります。
ログメッセージの数を減らすために、PtpConfig カスタムリソース (CR) を設定して、master offset 値をレポートするログメッセージを除外できます。master offset ログメッセージは、現在のノードのクロックとマスタークロックの違いをナノ秒単位でレポートします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfigCR を編集します。oc edit PtpConfig -n openshift-ptp
$ oc edit PtpConfig -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.profileで、ptpSettings.logReduce仕様を追加し、値をtrueに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デバッグの目的で、この仕様を
Falseに戻すと、マスターオフセットメッセージを含めることができます。-
保存して終了すると、
PtpConfigCR に変更が適用されます。
検証
PtpConfigCR が適用されたlinuxptp-daemonPod と対応するノードの名前を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マスターオフセットメッセージがログから除外されていることを確認します。
oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset"
$ oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset"1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <linux_daemon_container> は、
linuxptp-daemonPod の名前です (例:linuxptp-daemon-gmv2n)。
logReduce仕様を設定する場合、このコマンドはlinuxptpデーモンのログにmaster offsetのインスタンスを報告しません。
5.2.12. 一般的な PTP Operator の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を実行して、PTP Operator で典型的な問題のトラブルシューティングを行います。
前提条件
-
OpenShift Container Platform CLI (
oc) をインストールします。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP をサポートするホストを使用して、PTP Operator をベアメタルクラスターにインストールします。
手順
設定されたノードのクラスターに Operator とオペランドが正常にデプロイされていることを確認します。
oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記PTP 高速イベントバスが有効な場合には、準備できた
linuxptp-daemonPod の数は3/3になります。PTP 高速イベントバスが有効になっていない場合、2/2が表示されます。サポートされているハードウェアがクラスターにあることを確認します。
oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードで利用可能な PTP ネットワークインターフェイスを確認します。
oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <node_name>
問い合わせるノードを指定します (例:
compute-0.example.com)。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
対応するノードの
linuxptp-daemonPod にアクセスし、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。以下のコマンドを実行して、
linuxptp-daemonPod の名前と、トラブルシューティングに使用するノードを取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow リモートシェルが必要な
linuxptp-daemonコンテナーへのリモートシェルです。oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <linux_daemon_container>
-
診断するコンテナーです (例:
linuxptp-daemon-lmvgn)。
linuxptp-daemonコンテナーへのリモートシェル接続では、PTP 管理クライアント (pmc) ツールを使用して、ネットワークインターフェイスを診断します。以下のpmcコマンドを実行して、PTP デバイスの同期ステータスを確認します (例:ptp4l)。pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
# pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードがプライマリークロックに正常に同期されたときの出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
GNSS をソースとするグランドマスタークロックの場合は、次のコマンドを実行して、ツリー内 NIC ice ドライバーが正しいことを確認します。
oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-74m2g ethtool -i ens7f0
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-74m2g ethtool -i ens7f0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
driver: ice version: 5.14.0-356.bz2232515.el9.x86_64 firmware-version: 4.20 0x8001778b 1.3346.0
driver: ice version: 5.14.0-356.bz2232515.el9.x86_64 firmware-version: 4.20 0x8001778b 1.3346.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow GNSS をソースとするグランドマスタークロックの場合は、
linuxptp-daemonコンテナーが GNSS アンテナから信号を受信していることを確認します。コンテナーが GNSS 信号を受信していない場合、/dev/gnss0ファイルにデータが入力されません。検証するには、次のコマンドを実行します。oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-jnz6r cat /dev/gnss0
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-jnz6r cat /dev/gnss0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
$GNRMC,125223.00,A,4233.24463,N,07126.64561,W,0.000,,300823,,,A,V*0A $GNVTG,,T,,M,0.000,N,0.000,K,A*3D $GNGGA,125223.00,4233.24463,N,07126.64561,W,1,12,99.99,98.6,M,-33.1,M,,*7E $GNGSA,A,3,25,17,19,11,12,06,05,04,09,20,,,99.99,99.99,99.99,1*37 $GPGSV,3,1,10,04,12,039,41,05,31,222,46,06,50,064,48,09,28,064,42,1*62
$GNRMC,125223.00,A,4233.24463,N,07126.64561,W,0.000,,300823,,,A,V*0A $GNVTG,,T,,M,0.000,N,0.000,K,A*3D $GNGGA,125223.00,4233.24463,N,07126.64561,W,1,12,99.99,98.6,M,-33.1,M,,*7E $GNGSA,A,3,25,17,19,11,12,06,05,04,09,20,,,99.99,99.99,99.99,1*37 $GPGSV,3,1,10,04,12,039,41,05,31,222,46,06,50,064,48,09,28,064,42,1*62Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.13. Intel 800 シリーズ NIC の CGU の DPLL ファームウェアバージョンを取得する リンクのコピーリンクがクリップボードにコピーされました!
クラスターノードへのデバッグシェルを開き、NIC ハードウェアを照会することで、Intel 800 シリーズ NIC の Clock Generation Unit (CGU) の digital phase-locked loop (DPLL) ファームウェアバージョンを取得できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - クラスターホストに Intel 800 シリーズ NIC がインストールされている。
- PTP をサポートするホストを含むベアメタルクラスターに PTP Operator をインストールしている。
手順
次のコマンドを実行してデバッグ Pod を起動します。
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <node_name>
- Intel 800 シリーズ NIC をインストールしたノードです。
devlinkツールと、NIC がインストールされているバスおよびデバイス名を使用して、NIC の CGU ファームウェアバージョンを確認します。たとえば、以下のコマンドを実行します。devlink dev info <bus_name>/<device_name> | grep cgu
sh-4.4# devlink dev info <bus_name>/<device_name> | grep cguCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <bus_name>
-
NIC がインストールされているバスです (例:
pci)。 - <device_name>
-
NIC デバイス名です (例:
0000:51:00.0)。
出力例
cgu.id 36 fw.cgu 8032.16973825.6021
cgu.id 361 fw.cgu 8032.16973825.60212 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ファームウェアバージョンには、先頭のニブルと、バージョン番号の各部分に対する 3 つのオクテットがあります。
16973825を 2 進数で表すと0001 0000 0011 0000 0000 0000 0001になります。バイナリー値を使用してファームウェアバージョンをデコードします。以下に例を示します。Expand 表5.10 DPLL ファームウェアバージョン バイナリー部分 10 進数値 00011
0000 00113
0000 00000
0000 00011
5.2.14. PTP Operator データの収集 リンクのコピーリンクがクリップボードにコピーされました!
oc adm must-gather コマンドを使用すると、PTP Operator に関連する機能やオブジェクトなど、クラスターに関する情報を収集できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。 - PTP Operator がインストールされている。
手順
must-gatherを使用して PTP Operator データを収集するには、PTP Operatormust-gatherイメージを指定する必要があります。oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel9:v4.18
$ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel9:v4.18Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. REST API v2 を使用した PTP イベントコンシューマーアプリケーションの開発 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスターノードで Precision Time Protocol (PTP) イベントを利用するコンシューマーアプリケーションを開発する場合は、コンシューマーアプリケーションを別のアプリケーション Pod にデプロイします。コンシューマーアプリケーションは、PTP イベント REST API v2 を使用して PTP イベントをサブスクライブします。
以下の情報は、PTP イベントを使用するコンシューマーアプリケーションを開発するための一般的なガイダンスです。完全なイベントコンシューマーアプリケーションの例は、この情報の範囲外です。
5.3.1. PTP 高速イベント通知フレームワークについて リンクのコピーリンクがクリップボードにコピーされました!
Precision Time Protocol (PTP) 高速イベント REST API v2 を使用して、ベアメタルクラスターノードが生成する PTP イベントにクラスターアプリケーションをサブスクライブします。
高速イベント通知フレームワークは、通信に REST API を使用します。PTP イベント REST API v1 および v2 は、O-RAN ALLIANCE Specifications で提供されている O-RAN O-Cloud Notification API Specification for Event Consumers 4.0 に基づいています。
PTP イベント REST API v2 のみが O-RAN v4 に準拠しています。
5.3.2. PTP イベント REST API v2 を使用した PTP イベントの取得 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションは、プロデューサー側のクラウドイベントプロキシーサイドカーで O-RAN v4 互換の REST API を使用して PTP イベントをサブスクライブします。cloud-event-proxy サイドカーコンテナーは、プライマリーアプリケーションのリソースをまったく使用せずに、大幅な待機時間なしで、プライマリーアプリケーションコンテナーと同じリソースにアクセスできます。
図5.6 PTP イベントプロデューサー REST API v2 からの PTP 高速イベントの使用の概要
-
イベントはクラスターホストで生成されます。 -
PTP Operator が管理する Pod の
linuxptp-daemonプロセスは、KubernetesDaemonSetとして実行され、さまざまなlinuxptpプロセス (ptp4l、phc2sys、およびオプションでグランドマスタークロック用のts2phc) を管理します。linuxptp-daemonは、イベントを UNIX ドメインソケットに渡します。 -
イベントが cloud-event-proxy サイドカーに渡されます。 -
PTP プラグインは、UNIX ドメインソケットからイベントを読み取り、PTP Operator が管理する Pod 内の
cloud-event-proxyサイドカーに渡します。cloud-event-proxyは、イベントを Kubernetes インフラストラクチャーから Cloud-Native Network Functions (CNF) に低レイテンシーで配信します。 -
イベントが公開される -
PTP Operator 管理 Pod 内の
cloud-event-proxyサイドカーはイベントを処理し、PTP イベント REST API v2 を使用してイベントを公開します。 -
コンシューマーアプリケーションがサブスクリプションをリクエストし、サブスクライブされたイベントを受信します -
コンシューマーアプリケーションは、プロデューサー
cloud-event-proxyサイドカーに API リクエストを送信して、PTP イベントサブスクリプションを作成します。サブスクライブされると、コンシューマーアプリケーションはリソース修飾子で指定されたアドレスをリッスンし、PTP イベントを受信して処理します。
5.3.3. PTP 高速イベント通知パブリッシャーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のネットワークインターフェイスの PTP 高速イベント通知の使用を開始するには、PTP Operator PtpOperatorConfig カスタムリソース (CR) で高速イベントパブリッシャーを有効にし、作成する PtpConfig CR に ptpClockThreshold 値を設定する必要があります。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator がインストールされている。
手順
デフォルトの PTP Operator 設定を変更して、PTP 高速イベントを有効にします。
次の YAML を
ptp-operatorconfig.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、
PtpOperatorConfigリソースのspec.ptpEventConfig.transportHostフィールドを設定する必要はありません。PtpOperatorConfigCR を更新します。oc apply -f ptp-operatorconfig.yaml
$ oc apply -f ptp-operatorconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PTP 対応インターフェイスの
PtpConfigカスタムリソースを作成し、ptpClockThresholdおよびptp4lOptsに必要な値を設定します。次の YAML は、PtpConfigCR で設定する必要のある値 (必須) を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--summary_interval -4を追加して、PTP 高速イベントを使用します。- 2
phc2sysOptsの値が必要です。-mはメッセージをstdoutに出力します。linuxptp-daemonDaemonSetはログを解析し、Prometheus メトリクスを生成します。- 3
- デフォルトの
/etc/ptp4l.confファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。 - 4
- オプション:
ptpClockThresholdスタンザが存在しない場合は、ptpClockThresholdフィールドにデフォルト値が使用されます。スタンザは、デフォルトのptpClockThreshold値を示します。ptpClockThreshold値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。
5.3.4. PTP イベント REST API v2 コンシューマーアプリケーションリファレンス リンクのコピーリンクがクリップボードにコピーされました!
PTP イベントコンシューマーアプリケーションには次の機能が必要です。
-
POSTハンドラーで実行され、クラウドネイティブ PTP イベントの JSON ペイロードを受信する Web サービス -
PTP イベントプロデューサーをサブスクライブするための
createSubscription関数 -
PTP イベントプロデューサーの現在の状態をポーリングする
getCurrentState関数
次の Go スニペットの例は、これらの要件を示しています。
Go での PTP イベントコンシューマーサーバー関数の例
PTP イベントの例 Go の createSubscription 関数
- 1
<node_name>を、PTP イベントを生成しているノードの FQDN に置き換えます。compute-1.example.comはその例です。
Go の PTP イベントコンシューマー getCurrentState 関数の例
- 1
<node_name>を、PTP イベントを生成しているノードの FQDN に置き換えます。compute-1.example.comはその例です。
5.3.5. PTP イベント REST API v2 を使用したイベントコンシューマーのデプロイメントとサービス CR の参照 リンクのコピーリンクがクリップボードにコピーされました!
PTP イベント REST API v2 で使用するために PTP イベントコンシューマーアプリケーションをデプロイする場合は、次の PTP イベントコンシューマーカスタムリソース (CR) の例を参照として使用します。
参照クラウドイベントコンシューマー namespace
リファレンスクラウドイベントコンシューマーのデプロイメント
参照クラウドイベントコンシューマーサービスアカウント
apiVersion: v1 kind: ServiceAccount metadata: name: consumer-sa namespace: cloud-events
apiVersion: v1
kind: ServiceAccount
metadata:
name: consumer-sa
namespace: cloud-events
リファレンスクラウドイベントコンシューマーサービス
5.3.6. REST API v2 を使用した PTP イベントのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
cloud-event-consumer アプリケーションコンテナーをデプロイし、PTP Operator が管理する Pod 内の cloud-event-proxy コンテナーが投稿する PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。
適切なサブスクリプション要求ペイロードを渡して、http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions に POST 要求を送信することにより、コンシューマーアプリケーションを PTP イベントにサブスクライブします。
9043 は、PTP イベントプロデューサー Pod にデプロイされた cloud-event-proxy コンテナーのデフォルトポートです。必要に応じて、アプリケーションに異なるポートを設定できます。
5.3.7. PTP イベント REST API v2 コンシューマーアプリケーションがイベントを受信していることを確認 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーション Pod 内の cloud-event-consumer コンテナーが Precision Time Protocol (PTP) イベントを受信していることを確認します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールして設定している。
- クラウドイベントアプリケーション Pod と PTP イベントコンシューマーアプリケーションをデプロイしている。
手順
デプロイされたイベントコンシューマーアプリケーションのログを確認します。たとえば、以下のコマンドを実行します。
oc -n cloud-events logs -f deployment/cloud-consumer-deployment
$ oc -n cloud-events logs -f deployment/cloud-consumer-deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
linuxptp-daemonデプロイメントからocとポート転送ポート9043を使用して REST API をテストします。たとえば、以下のコマンドを実行します。oc port-forward -n openshift-ptp ds/linuxptp-daemon 9043:9043
$ oc port-forward -n openshift-ptp ds/linuxptp-daemon 9043:9043Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Forwarding from 127.0.0.1:9043 -> 9043 Forwarding from [::1]:9043 -> 9043 Handling connection for 9043
Forwarding from 127.0.0.1:9043 -> 9043 Forwarding from [::1]:9043 -> 9043 Handling connection for 9043Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいシェルプロンプトを開き、REST API v2 エンドポイントをテストします。
curl -X GET http://localhost:9043/api/ocloudNotifications/v2/health
$ curl -X GET http://localhost:9043/api/ocloudNotifications/v2/healthCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
OK
OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.8. PTP 高速イベントメトリクスのモニタリング リンクのコピーリンクがクリップボードにコピーされました!
linuxptp-daemon が実行されているクラスターノードから PTP 高速イベントメトリクスを監視できます。事前に設定された自己更新型の Prometheus モニタリングスタックを使用して、OpenShift Container Platform Web コンソールで PTP 高速イベントメトリクスをモニタリングできます。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP 対応ハードウェアを搭載したノードに PTP Operator をインストールし、設定します。
手順
次のコマンドを実行して、ノードのデバッグ Pod を起動します。
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow linuxptp-daemonコンテナーによって公開された PTP メトリクスを確認します。たとえば、以下のコマンドを実行します。curl http://localhost:9091/metrics
sh-4.4# curl http://localhost:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
cloud-event-proxyコンテナーのログでも PTP イベントを見つけることができます。たとえば、以下のコマンドを実行します。oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxyCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
OpenShift Container Platform Web コンソールで PTP イベントを表示するには、クエリーする PTP メトリクスの名前 (例:
openshift_ptp_offset_ns) をコピーします。 - OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
- PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。
5.3.9. PTP 高速イベントメトリクスのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の表は、linuxptp-daemon サービスが実行されているクラスターノードから利用できる PTP 高速イベントメトリクスを説明します。
| メトリクス | 説明 | 例 |
|---|---|---|
|
|
インターフェイスの PTP クロッククラスを返します。PTP クロッククラスの可能な値は、6 ( |
|
|
|
インターフェイスの現在の PTP クロック状態を返します。PTP クロック状態の可能な値は、 |
|
|
| タイミングパケットを送信するプライマリークロックとタイミングパケットを受信するセカンダリークロックの間の遅延をナノ秒単位で返します。 |
|
|
|
異なる NIC に複数のタイムソースがある場合に、高可用性システムクロックの現在のステータスを返します。可能な値は 0 ( |
|
|
|
2 つの PTP クロック間の周波数調整をナノ秒単位で返します。たとえば、アップストリームクロックと NIC の間、システムクロックと NIC の間、または PTP ハードウェアクロック ( |
|
|
|
インターフェイスに設定された PTP クロックの役割を返します。可能な値は、0 ( |
|
|
|
2 つのクロックまたはインターフェイス間の最大オフセットをナノ秒単位で返します。たとえば、アップストリーム GNSS クロックと NIC ( |
|
|
| DPLL クロックまたは GNSS クロックソースと NIC ハードウェアクロック間のオフセットをナノ秒単位で返します。 |
|
|
|
|
|
|
| PTP プロセスが実行中かどうかを示すステータスコードを返します。 |
|
|
|
|
|
5.3.9.1. T-GM が有効な場合のみ PTP 高速イベントメトリクス リンクのコピーリンクがクリップボードにコピーされました!
次の表は、PTP グランドマスタークロック (T-GM) が有効な場合にのみ使用できる PTP 高速イベントメトリクスを示しています。
| メトリクス | 説明 | 例 |
|---|---|---|
|
|
NIC の Digital Phase-Locked Loop (DPLL) 周波数の現在のステータスを返します。可能な値は、-1 ( |
|
|
|
NMEA 接続の現在のステータスを返します。NMEA は、1PPS NIC 接続に使用されるプロトコルです。可能な値は 0 ( |
|
|
|
NIC の DPLL 位相のステータスを返します。可能な値は、-1 ( |
|
|
|
NIC 1PPS 接続の現在のステータスを返します。1PPS 接続は、接続された NIC 間のタイミングを同期するために使用します。可能な値は 0 ( |
|
|
|
Global Navigation Satellite System (GNSS) 接続の現在のステータスを返します。GNSS は、衛星ベースの測位、ナビゲーション、およびタイミングサービスを世界中に提供します。可能な値は、0 ( |
|
5.4. PTP イベント REST API v2 リファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の REST API v2 エンドポイントを使用して、PTP イベントプロデューサー Pod の http://localhost:9043/api/ocloudNotifications/v2 に投稿された Precision Time Protocol (PTP) イベントに cloud-event-consumer アプリケーションをサブスクライブします。
api/ocloudNotifications/v2/subscriptions-
POST: 新しいサブスクリプションを作成します。 -
GET: サブスクリプションの一覧を取得します。 -
DELETE: すべてのサブスクリプションを削除します
-
api/ocloudNotifications/v2/subscriptions/{subscription_id}-
GET: 指定されたサブスクリプション ID の詳細を返します。 -
DELETE: 指定されたサブスクリプション ID に関連付けられたサブスクリプションを削除します
-
api/ocloudNotifications/v2/health-
GET:ocloudNotificationsAPI の正常性ステータスを返します
-
api/ocloudNotifications/v2/publishers-
GET: クラスターノードの PTP イベントパブリッシャーのリストを返します。
-
api/ocloudnotifications/v2/{resource_address}/CurrentState-
GET:{resouce_address}で指定されたイベントタイプの現在の状態を返します。
-
5.4.1. PTP イベント REST API v2 エンドポイント リンクのコピーリンクがクリップボードにコピーされました!
5.4.1.1. api/ocloudNotifications/v2/subscriptions リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/subscriptions
説明
サブスクリプションのリストを返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK のステータスコードが返されます。
API 応答の例
HTTP メソッド
POST api/ocloudNotifications/v2/subscriptions
説明
適切なペイロードを渡すことで、必要なイベントの新しいサブスクリプションを作成します。
次の PTP イベントをサブスクライブできます。
-
sync-stateイベント -
lock-stateイベント -
gnss-sync-status eventsイベント -
os-clock-sync-stateイベント -
clock-classイベント
| パラメーター | 型 |
|---|---|
| subscription | data |
同期状態サブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
PTP ロック状態イベントサブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
PTP gnss-sync-status イベントサブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
PTP os-clock-sync-state イベントサブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
PTP clock-class イベントサブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
API 応答の例
次のサブスクリプションステータスイベントが発生する可能性があります。
| ステータスコード | 説明 |
|---|---|
|
| サブスクリプションが作成されたことを示します。 |
|
| リクエストが不正または無効であったため、サーバーが要求を処理できなかったことを示します。 |
|
| サブスクリプションリソースが利用できないことを示します。 |
|
| サブスクリプションがすでに存在することを示します。 |
HTTP メソッド
DELETE api/ocloudNotifications/v2/subscriptions
説明
すべてのサブスクリプションを削除します。
API 応答の例
{
"status": "deleted all subscriptions"
}
{
"status": "deleted all subscriptions"
}
5.4.1.2. api/ocloudNotifications/v2/subscriptions/{subscription_id} リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/subscriptions/{subscription_id}
説明
ID が subscription_id のサブスクリプションの詳細を返します。
| パラメーター | 型 |
|---|---|
|
| string |
API 応答の例
HTTP メソッド
DELETE api/ocloudNotifications/v2/subscriptions/{subscription_id}
説明
ID subscription_id のサブスクリプションを削除します。
| パラメーター | 型 |
|---|---|
|
| string |
| HTTP レスポンス | 説明 |
|---|---|
| 204 No Content | Success |
5.4.1.3. api/ocloudNotifications/v2/health リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/health/
説明
ocloudNotifications REST API の正常性ステータスを返します。
| HTTP レスポンス | 説明 |
|---|---|
| 200 OK | Success |
5.4.1.4. api/ocloudNotifications/v2/publishers リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/publishers
説明
クラスターノードの発行者の詳細のリストを返します。関連する機器の状態が変化すると、システムは通知を生成します。
機器の同期ステータスのサブスクリプションを組み合わせて使用すると、システム全体の同期状態の詳細なビューを提供できます。
API 応答の例
| HTTP レスポンス | 説明 |
|---|---|
| 200 OK | Success |
5.4.1.5. api/ocloudNotifications/v2/{resource_address}/CurrentState リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/ptp-status/lock-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/ptp-status/clock-class/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/sync-status/sync-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/gnss-status/gnss-sync-state/CurrentState
説明
クラスターノードの os-clock-sync-state、clock-class、lock-state、gnss-sync-status、または sync-state イベントの現在の状態を返します。
-
os-clock-sync-state通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKEDまたはFREERUN状態になります。 -
clock-class通知は、PTP クロッククラスの現在の状態を説明します。 -
lock-state通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED、HOLDOVER、またはFREERUN状態になります。 -
sync-state通知は、PTP クロックのlock-state状態とos-clock-sync-state状態のうち、最も同期されていない状態の現在のステータスを示します。 -
gnss-sync-status通知は、GNSS クロックの同期状態を説明します。
| パラメーター | 型 |
|---|---|
|
| string |
ロック状態 API レスポンスの例
os-clock-sync-state API レスポンスの例
clock-class API レスポンスの例
同期状態 API 応答の例
gnss-sync-state API 応答の例
5.5. REST API v1 を使用した PTP イベントコンシューマーアプリケーションの開発 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスターノードで Precision Time Protocol (PTP) イベントを利用するコンシューマーアプリケーションを開発する場合は、コンシューマーアプリケーションを別のアプリケーション Pod にデプロイします。コンシューマーアプリケーションは、PTP イベント REST API v1 を使用して PTP イベントをサブスクライブします。
以下の情報は、PTP イベントを使用するコンシューマーアプリケーションを開発するための一般的なガイダンスです。完全なイベントコンシューマーアプリケーションの例は、この情報の範囲外です。
PTP イベント REST API v1 およびイベントコンシューマーアプリケーションサイドカーは非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、この製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。
5.5.1. PTP 高速イベント通知フレームワークについて リンクのコピーリンクがクリップボードにコピーされました!
Precision Time Protocol (PTP) 高速イベント REST API v2 を使用して、ベアメタルクラスターノードが生成する PTP イベントにクラスターアプリケーションをサブスクライブします。
高速イベント通知フレームワークは、通信に REST API を使用します。PTP イベント REST API v1 および v2 は、O-RAN ALLIANCE Specifications で提供されている O-RAN O-Cloud Notification API Specification for Event Consumers 4.0 に基づいています。
PTP イベント REST API v2 のみが O-RAN v4 に準拠しています。
5.5.2. PTP イベント REST API v1 を使用した PTP イベントの取得 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションは、cloud-event-proxy コンテナーをサイドカーパターンで実行して、PTP イベントをサブスクライブします。cloud-event-proxy サイドカーコンテナーは、プライマリーアプリケーションのリソースをまったく使用せずに、大幅な待機時間なしで、プライマリーアプリケーションコンテナーと同じリソースにアクセスできます。
図5.7 コンシューマーサイドカーと HTTP メッセージトランスポートを使用した PTP 高速イベントの概要
-
イベントはクラスターホストで生成されます。 -
PTP Operator が管理する Pod の
linuxptp-daemonは、KubernetesDaemonSetとして実行され、さまざまなlinuxptpプロセス (ptp4l、phc2sys、およびオプションでグランドマスタークロック用のts2phc) を管理します。linuxptp-daemonは、イベントを UNIX ドメインソケットに渡します。 -
イベントが cloud-event-proxy サイドカーに渡されます。 -
PTP プラグインは、UNIX ドメインソケットからイベントを読み取り、PTP Operator が管理する Pod 内の
cloud-event-proxyサイドカーに渡します。cloud-event-proxyは、イベントを Kubernetes インフラストラクチャーから Cloud-Native Network Functions (CNF) に低レイテンシーで配信します。 -
イベントが永続化される -
PTP Operator が管理する Pod 内の
cloud-event-proxyサイドカーは、REST API を使用してイベントを処理し、クラウドネイティブイベントを発行します。 -
メッセージはトランスポートされます。 -
メッセージトランスポーターは、HTTP 経由でアプリケーション Pod 内の
cloud-event-proxyサイドカーにイベントを転送します。 -
イベントは REST API から入手できます。 -
アプリケーション Pod の
cloud-event-proxyサイドカーはイベントを処理し、REST API を使用して利用できるようにします。 -
コンシューマーアプリケーションがサブスクリプションをリクエストし、サブスクライブされたイベントを受信します -
コンシューマーアプリケーションは、API 要求をアプリケーション Pod の
cloud-event-proxyサイドカーに送信して、PTP イベントサブスクリプションを作成します。cloud-event-proxyサイドカーは、サブスクリプションで指定されたリソースの HTTP メッセージングリスナープロトコルを作成します。
アプリケーション Pod の cloud-event-proxy サイドカーは、PTP Operator が管理する Pod からイベントを受信し、クラウドイベントオブジェクトをラッピング解除してデータを取得し、イベントをコンシューマーアプリケーションにポストします。コンシューマーアプリケーションは、リソース修飾子で指定されたアドレスをリッスンし、PTP イベントを受信して処理します。
5.5.3. PTP 高速イベント通知パブリッシャーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のネットワークインターフェイスの PTP 高速イベント通知の使用を開始するには、PTP Operator PtpOperatorConfig カスタムリソース (CR) で高速イベントパブリッシャーを有効にし、作成する PtpConfig CR に ptpClockThreshold 値を設定する必要があります。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator がインストールされている。
手順
デフォルトの PTP Operator 設定を変更して、PTP 高速イベントを有効にします。
次の YAML を
ptp-operatorconfig.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
enableEventPublisherをtrueに設定して、PTP 高速イベント通知を有効にします。
注記OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、
PtpOperatorConfigリソースのspec.ptpEventConfig.transportHostフィールドを設定する必要はありません。PtpOperatorConfigCR を更新します。oc apply -f ptp-operatorconfig.yaml
$ oc apply -f ptp-operatorconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PTP 対応インターフェイスの
PtpConfigカスタムリソースを作成し、ptpClockThresholdおよびptp4lOptsに必要な値を設定します。次の YAML は、PtpConfigCR で設定する必要のある値 (必須) を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--summary_interval -4を追加して、PTP 高速イベントを使用します。- 2
phc2sysOptsの値が必要です。-mはメッセージをstdoutに出力します。linuxptp-daemonDaemonSetはログを解析し、Prometheus メトリクスを生成します。- 3
- デフォルトの
/etc/ptp4l.confファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。 - 4
- オプション:
ptpClockThresholdスタンザが存在しない場合は、ptpClockThresholdフィールドにデフォルト値が使用されます。スタンザは、デフォルトのptpClockThreshold値を示します。ptpClockThreshold値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。
5.5.4. PTP イベントコンシューマーアプリケーションのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
PTP イベントコンシューマーアプリケーションには次の機能が必要です。
-
POSTハンドラーで実行され、クラウドネイティブ PTP イベントの JSON ペイロードを受信する Web サービス -
PTP イベントプロデューサーをサブスクライブするための
createSubscription関数 -
PTP イベントプロデューサーの現在の状態をポーリングする
getCurrentState関数
次の Go スニペットの例は、これらの要件を示しています。
Go での PTP イベントコンシューマーサーバー関数の例
PTP イベントの例 Go の createSubscription 関数
- 1
<node_name>を、PTP イベントを生成しているノードの FQDN に置き換えます。compute-1.example.comはその例です。
Go の PTP イベントコンシューマー getCurrentState 関数の例
5.5.5. cloud-event-proxy のデプロイメントとサービス CR を参照する リンクのコピーリンクがクリップボードにコピーされました!
PTP イベントコンシューマーアプリケーションをデプロイするときは、次の cloud-event-proxy デプロイメントとサブスクライバサービス CR の例を参考として使用してください。
HTTP トランスポートを使用した cloud-event-proxy デプロイメントの参照
cloud-event-proxy サブスクライバーサービスの参照
5.5.6. REST API v1 を使用した PTP イベントのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
cloud-event-consumer アプリケーションコンテナーおよび cloud-event-proxy サイドカーコンテナーを別のアプリケーション Pod にデプロイします。
アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/ にある cloud-event-proxy コンテナーによって投稿された PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。
9089 は、アプリケーション Pod にデプロイされた cloud-event-consumer コンテナーのデフォルトポートです。必要に応じて、アプリケーションに異なるポートを設定できます。
5.5.7. PTP イベント REST API v1 コンシューマーアプリケーションがイベントを受信していることを確認 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーション Pod の cloud-event-proxy コンテナーが PTP イベントを受信していることを確認します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールして設定している。
手順
アクティブな
linuxptp-daemonPod の一覧を取得します。以下のコマンドを実行します。oc get pods -n openshift-ptp
$ oc get pods -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 8h linuxptp-daemon-k8n88 3/3 Running 0 8h
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 8h linuxptp-daemon-k8n88 3/3 Running 0 8hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、必要なコンシューマー側
cloud-event-proxyコンテナーのメトリックにアクセスします。oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
$ oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <linuxptp-daemon>
問い合わせる Pod を指定します (例:
linuxptp-daemon-2t78p)。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.8. PTP 高速イベントメトリクスのモニタリング リンクのコピーリンクがクリップボードにコピーされました!
linuxptp-daemon が実行されているクラスターノードから PTP 高速イベントメトリクスを監視できます。事前に設定された自己更新型の Prometheus モニタリングスタックを使用して、OpenShift Container Platform Web コンソールで PTP 高速イベントメトリクスをモニタリングできます。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP 対応ハードウェアを搭載したノードに PTP Operator をインストールし、設定します。
手順
次のコマンドを実行して、ノードのデバッグ Pod を起動します。
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow linuxptp-daemonコンテナーによって公開された PTP メトリクスを確認します。たとえば、以下のコマンドを実行します。curl http://localhost:9091/metrics
sh-4.4# curl http://localhost:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
cloud-event-proxyコンテナーのログでも PTP イベントを見つけることができます。たとえば、以下のコマンドを実行します。oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxyCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
OpenShift Container Platform Web コンソールで PTP イベントを表示するには、クエリーする PTP メトリクスの名前 (例:
openshift_ptp_offset_ns) をコピーします。 - OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
- PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。
5.5.9. PTP 高速イベントメトリクスのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の表は、linuxptp-daemon サービスが実行されているクラスターノードから利用できる PTP 高速イベントメトリクスを説明します。
| メトリクス | 説明 | 例 |
|---|---|---|
|
|
インターフェイスの PTP クロッククラスを返します。PTP クロッククラスの可能な値は、6 ( |
|
|
|
インターフェイスの現在の PTP クロック状態を返します。PTP クロック状態の可能な値は、 |
|
|
| タイミングパケットを送信するプライマリークロックとタイミングパケットを受信するセカンダリークロックの間の遅延をナノ秒単位で返します。 |
|
|
|
異なる NIC に複数のタイムソースがある場合に、高可用性システムクロックの現在のステータスを返します。可能な値は 0 ( |
|
|
|
2 つの PTP クロック間の周波数調整をナノ秒単位で返します。たとえば、アップストリームクロックと NIC の間、システムクロックと NIC の間、または PTP ハードウェアクロック ( |
|
|
|
インターフェイスに設定された PTP クロックの役割を返します。可能な値は、0 ( |
|
|
|
2 つのクロックまたはインターフェイス間の最大オフセットをナノ秒単位で返します。たとえば、アップストリーム GNSS クロックと NIC ( |
|
|
| DPLL クロックまたは GNSS クロックソースと NIC ハードウェアクロック間のオフセットをナノ秒単位で返します。 |
|
|
|
|
|
|
| PTP プロセスが実行中かどうかを示すステータスコードを返します。 |
|
|
|
|
|
5.5.9.1. T-GM が有効な場合のみ PTP 高速イベントメトリクス リンクのコピーリンクがクリップボードにコピーされました!
次の表は、PTP グランドマスタークロック (T-GM) が有効な場合にのみ使用できる PTP 高速イベントメトリクスを示しています。
| メトリクス | 説明 | 例 |
|---|---|---|
|
|
NIC の Digital Phase-Locked Loop (DPLL) 周波数の現在のステータスを返します。可能な値は、-1 ( |
|
|
|
NMEA 接続の現在のステータスを返します。NMEA は、1PPS NIC 接続に使用されるプロトコルです。可能な値は 0 ( |
|
|
|
NIC の DPLL 位相のステータスを返します。可能な値は、-1 ( |
|
|
|
NIC 1PPS 接続の現在のステータスを返します。1PPS 接続は、接続された NIC 間のタイミングを同期するために使用します。可能な値は 0 ( |
|
|
|
Global Navigation Satellite System (GNSS) 接続の現在のステータスを返します。GNSS は、衛星ベースの測位、ナビゲーション、およびタイミングサービスを世界中に提供します。可能な値は、0 ( |
|
5.6. PTP イベント REST API v1 リファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の Precision Time Protocol (PTP) 高速イベント REST API v1 エンドポイントを使用して、アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/ にある cloud-event-proxy コンテナーが投稿した PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。
PTP イベント REST API v1 およびイベントコンシューマーアプリケーションサイドカーは非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、この製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。
以下の API エンドポイントを利用できます。
api/ocloudNotifications/v1/subscriptions-
POST: 新しいサブスクリプションを作成します。 -
GET: サブスクリプションの一覧を取得します。 -
DELETE: すべてのサブスクリプションを削除します
-
api/ocloudNotifications/v1/subscriptions/{subscription_id}-
GET: 指定されたサブスクリプション ID の詳細を返します。 -
DELETE: 指定されたサブスクリプション ID に関連付けられたサブスクリプションを削除します
-
api/ocloudNotifications/v1/health-
GET:ocloudNotificationsAPI の正常性ステータスを返します
-
api/ocloudNotifications/v1/publishers-
GET: クラスターノードの PTP イベントパブリッシャーのリストを返します。
-
api/ocloudnotifications/v1/{resource_address}/CurrentState-
GET:sync-state、os-clock-sync-state、clock-class、lock-state、またはgnss-sync-statusイベントのいずれかの現在の状態を返します。
-
5.6.1. PTP イベント REST API v1 エンドポイント リンクのコピーリンクがクリップボードにコピーされました!
5.6.1.1. api/ocloudNotifications/v1/subscriptions リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v1/subscriptions
説明
サブスクリプションのリストを返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK のステータスコードが返されます。
API 応答の例
HTTP メソッド
POST api/ocloudNotifications/v1/subscriptions
説明
適切なペイロードを渡すことで、必要なイベントの新しいサブスクリプションを作成します。サブスクリプションが正常に作成されるか、すでに存在する場合は、201 Created ステータスコードが返されます。次の PTP イベントをサブスクライブできます。
-
lock-stateイベント -
os-clock-sync-stateイベント -
clock-classイベント -
gnss-sync-statusイベント -
sync-stateイベント
| パラメーター | 型 |
|---|---|
| subscription | data |
PTP イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/compute-1.example.com/ptp"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/compute-1.example.com/ptp"
}
PTP ロック状態イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
PTP os-clock-sync-state イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
PTP clock-class イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
PTP gnss-sync-status イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
同期状態サブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
HTTP メソッド
DELETE api/ocloudNotifications/v1/subscriptions
説明
すべてのサブスクリプションを削除します。
API 応答の例
{
"status": "deleted all subscriptions"
}
{
"status": "deleted all subscriptions"
}
5.6.1.2. api/ocloudNotifications/v1/subscriptions/{subscription_id} リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v1/subscriptions/{subscription_id}
説明
ID が subscription_id のサブスクリプションの詳細を返します。
| パラメーター | 型 |
|---|---|
|
| string |
API 応答の例
HTTP メソッド
DELETE api/ocloudNotifications/v1/subscriptions/{subscription_id}
説明
ID subscription_id のサブスクリプションを削除します。
| パラメーター | 型 |
|---|---|
|
| string |
API 応答の例
{
"status": "OK"
}
{
"status": "OK"
}
5.6.1.3. api/ocloudNotifications/v1/health リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v1/health/
説明
ocloudNotifications REST API の正常性ステータスを返します。
API 応答の例
OK
OK
5.6.1.4. api/ocloudNotifications/v1/publishers リンクのコピーリンクがクリップボードにコピーされました!
api/ocloudNotifications/v1/publishers エンドポイントは、PTP Operator が管理する Pod 内の cloud-event-proxy コンテナーからのみ利用できます。アプリケーション Pod 内のコンシューマーアプリケーションでは使用できません。
HTTP メソッド
GET api/ocloudNotifications/v1/publishers
説明
クラスターノードの発行者の詳細のリストを返します。関連する機器の状態が変化すると、システムは通知を生成します。
機器の同期ステータスのサブスクリプションを組み合わせて使用すると、システム全体の同期状態の詳細なビューを提供できます。
API 応答の例
5.6.1.5. api/ocloudNotifications/v1/{resource_address}/CurrentState リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/ptp-status/lock-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/ptp-status/clock-class/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/sync-status/sync-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/gnss-status/gnss-sync-state/CurrentState
説明
クラスターノードの os-clock-sync-state、clock-class、lock-state、gnss-sync-status、または sync-state イベントの現在の状態を返します。
-
os-clock-sync-state通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKEDまたはFREERUN状態になります。 -
clock-class通知は、PTP クロッククラスの現在の状態を説明します。 -
lock-state通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED、HOLDOVER、またはFREERUN状態になります。 -
sync-state通知は、ptp-status/lock-stateエンドポイントおよびsync-status/os-clock-sync-stateエンドポイントのうち最も同期されていないエンドポイントの現在のステータスを説明します。 -
gnss-sync-status通知は、GNSS クロックの同期状態を説明します。
| パラメーター | 型 |
|---|---|
|
| string |
ロック状態 API レスポンスの例
os-clock-sync-state API レスポンスの例
clock-class API レスポンスの例
同期状態 API 応答の例
gnss-sync-status API 応答の例
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.