1.2.5. データベースサイズが etcd に与える影響

etcd データベースのサイズは、etcd デフラグプロセスの完了時間に直接影響します。OpenShift Container Platform は、少なくとも 45% の断片化を検出すると、一度に 1 つの etcd メンバーで etcd デフラグを自動的に実行します。デフラグ処理中は、etcd メンバーは要求を処理できません。小さな etcd データベースでは、デフラグ処理は 1 秒未満で実行されます。etcd データベースが大きい場合、ディスクレイテンシーが断片化時間に直接影響し、デフラグの実行中に操作がブロックされるため、追加のレイテンシーが発生します。

etcd データベースのサイズは、ネットワークパーティションによってコントロールプレーンノードが一定期間分離され、通信が再確立された後にコントロールプレーンを同期する必要がある場合に考慮すべき要素です。

etcd データベースのサイズはシステム内の Operator とアプリケーションに依存するため、そのサイズを制御するためのオプションは最小限しかありません。システムが動作するレイテンシー範囲を検討するときは、etcd データベースのサイズごとに同期またはデフラグの影響を考慮してください。

その影響の大きさは、デプロイメントごとに異なります。デフラグが完了するまでの時間は、etcd メンバーがデフラグ処理中に更新を受け入れることができないため、トランザクションレートの低下を引き起こします。同様に、変更率の高い大規模データベースの etcd 再同期にかかる時間は、システム上のトランザクションレートとトランザクションレイテンシーに影響します。計画が必要な影響の種類は、次の 2 つの例を検討してください。

データベースサイズに基づいた etcd デフラグの影響に関する最初の例は、1 GB の etcd データベースを 80 Mb/秒の低速 7200 RPM ディスクに書き込むのに約 1 分 40 秒かかることです。このようなシナリオでは、デフラグが完了するまでに、デフラグプロセスに少なくともこれだけの時間がかかります。

データベースサイズが etcd 同期に与える影響の 2 番目の例は、コントロールプレーンノードの 1 つが切断されている間に etcd データベースの 10% が変更された場合、同期では少なくとも 100 MB を転送する必要があるということです。1 Gbps リンクで 100 MB を転送するには 800 ミリ秒かかります。Kubernetes API を使用した定期的なトランザクションを実行するクラスターでは、etcd データベースのサイズが大きくなるほど、ネットワークの不安定性が増し、コントロールプレーンの不安定性も生じます。

OpenShift Container Platform では、etcd ダッシュボードに etcd データベースのサイズを報告するグラフがあります。または、etcdctl ツールを使用して CLI からデータベースサイズを取得することもできます。

# oc get pods -n openshift-etcd -l app=etcd

NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          22h
etcd-m1   4/4     Running   4          22h
etcd-m2   4/4     Running   4          22h

# oc exec -t etcd-m0 -- etcdctl endpoint status -w simple | cut -d, -f 1,3,4

https://198.18.111.12:2379, 3.5.6, 1.1 GB
https://198.18.111.13:2379, 3.5.6, 1.1 GB
https://198.18.111.14:2379, 3.5.6, 1.1 GB