3.11. コントロールプレーンノード間のネットワークジッターの測定
ハートビート間隔の値は、メンバー間の平均往復時間 (RTT) の最大値にほぼ等しく、通常は往復時間の約 1.5 倍になります。OpenShift Container Platform のデフォルトのハートビート間隔は 100 ミリ秒であるため、コントロールプレーンノード間の推奨 RTT は約 33 ミリ秒未満、最大値は 66 ミリ秒未満 (66 ミリ秒 × 1.5 = 99 ミリ秒) になります。詳細は、「etcd のチューニングパラメーターの設定」を参照してください。ネットワークレイテンシーがこれより高いと、サービスに影響を与えるイベントが発生し、クラスターが不安定になる可能性があります。
ネットワークレイテ因子ーは、以下を含む多くの要因の影響を受けます。
- 銅線、光ファイバー、無線、衛星などのトランスポートネットワークテクノロジー
- トランスポートネットワーク内のネットワークデバイスの数と品質
組織内のネットワークレイテンシーと、通信プロバイダーが公開する商用レイテンシー (月間 IP レイテンシー統計など) の比較は、優れた評価基準として使用できます。
より正確に研鑽するためには、ネットワークジッターによるネットワークレイテンシーを考慮してください。ネットワークジッター とは、ネットワークレイテンシーの変動、より具体的には受信パケットのレイテンシーの変動です。理想的なネットワーク条件下では、ジッターは限りなくゼロに近くなります。ネットワークジッターは etcd のネットワークレイテンシーの計算に影響します。これは、時間の経過に伴う実際のネットワークレイテンシーは RTT にジッターを加算または減算したものになるためです。たとえば、最大レイテンシーが 80 ミリ秒でジッターが 30 ミリ秒のネットワークでは、レイテンシーが 110 ミリ秒になります。これは、etcd がハートビートを失っていることを意味し、要求のタイムアウトと一時的なリーダーの不在が発生します。リーダーの喪失と再選出の間、Kubernetes API は、サービスに影響を与えるイベントやクラスターの不安定性を引き起こす要求を処理できません。
すべてのコントロールプレーンノード間のネットワークジッターを測定することが重要です。そのためには、UDP モードで iPerf3 ツールを使用できます。
前提条件
独自の iPerf イメージをビルドした。詳細は、Red Hat ナレッジベースの以下の記事を参照してください。
手順
いずれか 1 つのコントロールプレーンノードに接続し、iPerf コンテナーをホストネットワークモードで iPerf サーバーとして実行します。サーバーモードで実行している場合、ツールは TCP および UDP テストを受け入れます。次のコマンドを、
<iperf_image>は iPerf イメージに置き換えて入力します。# podman run -ti --rm --net host <iperf_image> iperf3 -s別のコントロールプレーンノードに接続し、次のコマンドを入力して iPerf を UDP クライアントモードで実行します。
# podman run -ti --rm --net host <iperf_image> iperf3 -u -c <node_iperf_server> -t 300デフォルトのテストは 10 秒間実行され、最後にクライアント出力にクライアントの観点から見た平均ジッターが表示されます。
次のコマンドを入力してデバッグノードモードを実行します。
# oc debug node/m1出力例
Starting pod/m1-debug ... To use host binaries, run `chroot /host` Pod IP: 198.18.111.13 If you don't see a command prompt, try pressing enter.次のコマンドを入力します。
sh-4.4# chroot /hostsh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -u -c m0出力例
Connecting to host m0, port 5201 [ 5] local 198.18.111.13 port 60878 connected to 198.18.111.12 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 1.00-2.00 sec 127 KBytes 1.04 Mbits/sec 90 [ 5] 2.00-3.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 3.00-4.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 90 [ 5] 5.00-6.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 6.00-7.00 sec 127 KBytes 1.04 Mbits/sec 90 [ 5] 7.00-8.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 90 [ 5] 9.00-10.00 sec 129 KBytes 1.05 Mbits/sec 91 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/906 (0%) sender [ 5] 0.00-10.04 sec 1.25 MBytes 1.05 Mbits/sec 1.074 ms 0/906 (0%) receiver iperf Done.iPerf サーバーでは、出力に 1 秒間隔ごとのジッターが表示されます。平均値は最後に表示されます。このテストの目的は、テスト中に発生する最大ジッターを特定することです。その際には、無効な測定値が含まれている可能性があるため最初の 1 秒の出力を無視します。以下のコマンドを入力します。
# oc debug node/m0出力例
Starting pod/m0-debug ... To use host binaries, run `chroot /host` Pod IP: 198.18.111.12 If you don't see a command prompt, try pressing enter.次のコマンドを入力します。
sh-4.4# chroot /hostsh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -s出力例
----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 198.18.111.13, port 44136 [ 5] local 198.18.111.12 port 5201 connected to 198.18.111.13 port 60878 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 124 KBytes 1.02 Mbits/sec 4.763 ms 0/88 (0%) [ 5] 1.00-2.00 sec 127 KBytes 1.04 Mbits/sec 4.735 ms 0/90 (0%) [ 5] 2.00-3.00 sec 129 KBytes 1.05 Mbits/sec 0.568 ms 0/91 (0%) [ 5] 3.00-4.00 sec 127 KBytes 1.04 Mbits/sec 2.443 ms 0/90 (0%) [ 5] 4.00-5.00 sec 129 KBytes 1.05 Mbits/sec 1.372 ms 0/91 (0%) [ 5] 5.00-6.00 sec 127 KBytes 1.04 Mbits/sec 2.769 ms 0/90 (0%) [ 5] 6.00-7.00 sec 129 KBytes 1.05 Mbits/sec 2.393 ms 0/91 (0%) [ 5] 7.00-8.00 sec 127 KBytes 1.04 Mbits/sec 0.883 ms 0/90 (0%) [ 5] 8.00-9.00 sec 129 KBytes 1.05 Mbits/sec 0.594 ms 0/91 (0%) [ 5] 9.00-10.00 sec 127 KBytes 1.04 Mbits/sec 0.953 ms 0/90 (0%) [ 5] 10.00-10.04 sec 5.66 KBytes 1.30 Mbits/sec 1.074 ms 0/4 (0%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.04 sec 1.25 MBytes 1.05 Mbits/sec 1.074 ms 0/906 (0%) receiver ----------------------------------------------------------- Server listening on 5201 ------------------------------------------------------------ 算出したジッターをネットワークレイテンシーのペナルティとして追加します。たとえば、ネットワークレイテンシーが 80 ミリ秒で、ジッターが 30 ミリ秒の場合、コントロールプレーンについては、有効なネットワークレイテンシーを 110 ミリ秒と見なします。この例では、その値が 100 ミリ秒のしきい値を超え、システムはハートビートを受信しません。
etcd のネットワークレイテンシーを計算する場合は、実効ネットワークレイテンシー (次の式の合計) を使用します。
RTT + jitter
平均ジッター値を使用してペナルティを計算できる可能性がありますが、etcd ハートビートタイマーが次の式の合計よりも小さい場合、クラスターは断続的にハートビートを受信しない可能性があります。
RTT + max(jitter)
代わりに、回復力の高いデプロイメントのために、99 パーセンタイルまたは最大ジッター値の使用を検討してください。
実効ネットワークレイテンシー = RTT + max(jitter)