2.3. etcd に関する推奨されるプラクティス

このトピックでは、OpenShift Container Platform の etcd に関するパフォーマンスとスケーラビリティーの推奨プラクティスを説明します。

2.3.1. etcd に関する推奨されるプラクティス

etcd はデータをディスクに書き込み、プロポーザルをディスクに保持するため、そのパフォーマンスはディスクのパフォーマンスに依存します。etcd は特に I/O を集中的に使用するわけではありませんが、最適なパフォーマンスと安定性を得るには、低レイテンシーのブロックデバイスが必要です。etcd のコンセンサスプロトコルは、メタデータをログ (WAL) に永続的に保存することに依存しているため、etcd はディスク書き込みの遅延に敏感です。遅いディスクと他のプロセスからのディスクアクティビティーは、長い fsync 待ち時間を引き起こす可能性があります。

これらの待ち時間により、etcd はハートビートを見逃し、新しいプロポーザルを時間どおりにディスクにコミットせず、最終的にリクエストのタイムアウトと一時的なリーダーの喪失を経験する可能性があります。書き込みレイテンシーが高いと、OpenShift API の速度も低下し、クラスターのパフォーマンスに影響します。これらの理由により、I/O を区別する、または集約型であり、同一基盤として I/O インフラストラクチャーを共有する他のワークロードをコントロールプレーンノードに併置することは避けてください。

レイテンシーに関しては、8000 バイト長の 50 IOPS 以上を連続して書き込むことができるブロックデバイス上で etcd を実行します。つまり、レイテンシーが 10 ミリ秒の場合、fdatasync を使用して WAL の各書き込みを同期することに注意してください。負荷の高いクラスターの場合、8000 バイト (2 ミリ秒) の連続 500 IOPS が推奨されます。これらの数値を測定するには、fio などのベンチマークツールを使用できます。

このようなパフォーマンスを実現するには、低レイテンシーで高スループットの SSD または NVMe ディスクに支えられたマシンで etcd を実行します。シングルレベルセル (SLC) ソリッドステートドライブ (SSD) を検討してください。これは、メモリーセルごとに 1 ビットを提供し、耐久性と信頼性が高く、書き込みの多いワークロードに最適です。

注記

etcd の負荷は、ノードや Pod の数などの静的要因と、Pod の自動スケーリング、Pod の再起動、ジョブの実行、その他のワークロード関連イベントが原因となるエンドポイントの変更などの動的要因から生じます。etcd セットアップのサイズを正確に設定するには、ワークロードの具体的な要件を分析する必要があります。etcd の負荷に影響を与えるノード、Pod、およびその他の関連要素の数を考慮してください。

最適な etcd パフォーマンスを得るには、ハードドライブで以下を適用します。

専用の etcd ドライブを使用します。iSCSI などのネットワーク経由で通信するドライブは回避します。etcd ドライブにログファイルやその他の重いワークロードを配置しないでください。
読み取りおよび書き込みを高速化するために、低レイテンシードライブを優先的に使用します。
圧縮と最適化を高速化するために、高帯域幅の書き込みを優先的に使用します。
障害からの回復を高速化するために、高帯域幅の読み取りを優先的に使用します。
最小の選択肢としてソリッドステートドライブを使用します。実稼働環境には NVMe ドライブの使用が推奨されます。
高い信頼性を確保するためには、サーバーグレードのハードウェアを使用します。

注記

NAS または SAN のセットアップ、および回転するドライブは避けてください。Ceph Rados Block Device (RBD) およびその他のタイプのネットワーク接続ストレージでは、予測できないネットワーク遅延が発生する可能性があります。etcd ノードに大規模な高速ストレージを提供するには、PCI パススルーを使用して NVM デバイスをノードに直接渡します。

fio などのユーティリティーを使用して、常にベンチマークを行ってください。このようなユーティリティーを使用すると、クラスターのパフォーマンスが向上するにつれて、そのパフォーマンスを継続的に監視できます。

注記

ネットワークファイルシステム (NFS) プロトコルまたはその他のネットワークベースのファイルシステムの使用は避けてください。

デプロイされた OpenShift Container Platform クラスターでモニターする主要なメトリクスの一部は、etcd ディスクの write ahead log 期間の p99 と etcd リーダーの変更数です。Prometheus を使用してこれらのメトリクスを追跡します。

注記

etcd メンバーデータベースのサイズは、通常の運用時にクラスター内で異なる場合があります。この違いは、リーダーのサイズが他のメンバーと異なっていても、クラスターのアップグレードには影響しません。

OpenShift Container Platform クラスターの作成前または作成後に etcd のハードウェアを検証するには、fio を使用できます。

前提条件

Podman や Docker などのコンテナーランタイムは、テストしているマシンにインストールされます。
データは /var/lib/etcd パスに書き込まれます。

手順

fio を実行し、結果を分析します。
- Podman を使用する場合は、次のコマンドを実行します。
```
$ sudo podman run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
```
- Docker を使用する場合は、次のコマンドを実行します。
```
$ sudo docker run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
```

この出力では、実行からキャプチャーされた fsync メトリクスの 99 パーセンタイルの比較でディスクが 10 ms 未満かどうかを確認して、ディスクの速度が etcd をホストするのに十分であるかどうかを報告します。I/O パフォーマンスの影響を受ける可能性のある最も重要な etcd メトリックのいくつかを以下に示します。

etcd_disk_wal_fsync_duration_seconds_bucket メトリックは、etcd の WAL fsync 期間を報告します。
etcd_disk_backend_commit_duration_seconds_bucket メトリクスは、etcd バックエンドコミットの待機時間を報告します。
etcd_server_leader_changes_seen_total メトリックは、リーダーの変更を報告します。

etcd はすべてのメンバー間で要求を複製するため、そのパフォーマンスはネットワーク入出力 (I/O) のレイテンシーによって大きく変わります。ネットワークのレイテンシーが高くなると、etcd のハートビートの時間は選択のタイムアウトよりも長くなり、その結果、クラスターに中断をもたらすリーダーの選択が発生します。デプロイされた OpenShift Container Platform クラスターでのモニターの主要なメトリクスは、各 etcd クラスターメンバーの etcd ネットワークピアレイテンシーの 99 番目のパーセンタイルになります。Prometheus を使用してメトリクスを追跡します。

histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[2m])) メトリックは、etcd がメンバー間でクライアントリクエストの複製を完了するまでのラウンドトリップ時間をレポートします。50 ミリ秒未満であることを確認してください。

関連情報

2.3.2. etcd を別のディスクに移動する

etcd を共有ディスクから別のディスクに移動して、パフォーマンスの問題を防止または解決できます。

Machine Config Operator (MCO) は、OpenShift Container Platform 4.18 コンテナーストレージのセカンダリーディスクをマウントします。

注記

このエンコードされたスクリプトは、次のデバイスタイプのデバイス名のみをサポートします。

SCSI または SATA: /dev/sd*
仮想デバイス: /dev/vd*
NVMe: /dev/nvme*[0-9]*n*

制限事項

新しいディスクがクラスターに接続されると、etcd データベースがルートマウントの一部になります。プライマリーノードが再作成されるとき、ルートマウントはセカンダリーディスクまたは目的のディスクの一部ではありません。そのため、プライマリーノードは個別の /var/lib/etcd マウントを作成しません。

前提条件

クラスターの etcd データのバックアップを作成している。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限でクラスターにアクセスできる。
マシン設定をアップロードする前に、追加のディスクを追加する。
MachineConfigPool は metadata.labels[machineconfiguration.openshift.io/role] と一致する必要があります。これは、コントローラー、ワーカー、またはカスタムプールに適用されます。

注記

この手順では、/var/ などのルートファイルシステムの一部を、インストール済みノードの別のディスクまたはパーティションに移動しません。

重要

コントロールプレーンマシンセットを使用する場合は、この手順がサポートされません。

手順

新しいディスクをクラスターに接続し、デバッグシェルで lsblk コマンドを実行して、ディスクがノード内で検出されることを確認します。
```
$ oc debug node/<node_name>
```
```
# lsblk
```
lsblk コマンドで報告された新しいディスクのデバイス名をメモします。

次のスクリプトを作成し、名前を etcd-find-secondary-device.sh にします。

#!/bin/bash
set -uo pipefail

for device in <device_type_glob>; do 1
/usr/sbin/blkid "${device}" &> /dev/null
 if [ $? == 2  ]; then
    echo "secondary device found ${device}"
    echo "creating filesystem for etcd mount"
    mkfs.xfs -L var-lib-etcd -f "${device}" &> /dev/null
    udevadm settle
    touch /etc/var-lib-etcd-mount
    exit
 fi
done
echo "Couldn't find secondary block device!" >&2
exit 77

1: <device_type_glob> は、ブロックデバイスタイプのシェル glob に置き換えます。SCSI または SATA ドライブの場合は /dev/sd* を使用し、仮想ドライブの場合は /dev/vd* を使用し、NVMe ドライブの場合は /dev/nvme*[0-9]*n* を使用します。

etcd-find-secondary-device.sh スクリプトから base64 でエンコードされた文字列を作成し、その内容をメモします。
```
$ base64 -w0 etcd-find-secondary-device.sh
```

次のような内容を含む etcd-mc.yml という名前の MachineConfig YAML ファイルを作成します。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 98-var-lib-etcd
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
        - path: /etc/find-secondary-device
          mode: 0755
          contents:
            source: data:text/plain;charset=utf-8;base64,<encoded_etcd_find_secondary_device_script> 1
    systemd:
      units:
        - name: find-secondary-device.service
          enabled: true
          contents: |
            [Unit]
            Description=Find secondary device
            DefaultDependencies=false
            After=systemd-udev-settle.service
            Before=local-fs-pre.target
            ConditionPathExists=!/etc/var-lib-etcd-mount

            [Service]
            RemainAfterExit=yes
            ExecStart=/etc/find-secondary-device

            RestartForceExitStatus=77

            [Install]
            WantedBy=multi-user.target
        - name: var-lib-etcd.mount
          enabled: true
          contents: |
            [Unit]
            Before=local-fs.target

            [Mount]
            What=/dev/disk/by-label/var-lib-etcd
            Where=/var/lib/etcd
            Type=xfs
            TimeoutSec=120s

            [Install]
            RequiredBy=local-fs.target
        - name: sync-var-lib-etcd-to-etcd.service
          enabled: true
          contents: |
            [Unit]
            Description=Sync etcd data if new mount is empty
            DefaultDependencies=no
            After=var-lib-etcd.mount var.mount
            Before=crio.service

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            ExecCondition=/usr/bin/test ! -d /var/lib/etcd/member
            ExecStart=/usr/sbin/setsebool -P rsync_full_access 1
            ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
            ExecStart=/usr/sbin/semanage fcontext -a -t container_var_lib_t '/var/lib/etcd(/.*)?'
            ExecStart=/usr/sbin/setsebool -P rsync_full_access 0
            TimeoutSec=0

            [Install]
            WantedBy=multi-user.target graphical.target
        - name: restorecon-var-lib-etcd.service
          enabled: true
          contents: |
            [Unit]
            Description=Restore recursive SELinux security contexts
            DefaultDependencies=no
            After=var-lib-etcd.mount
            Before=crio.service

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            ExecStart=/sbin/restorecon -R /var/lib/etcd/
            TimeoutSec=0

            [Install]
            WantedBy=multi-user.target graphical.target

1: <encoded_etcd_find_secondary_device_script> を、メモしておいたエンコードされたスクリプトの内容に置き換えます。

検証手順

ノードのデバッグシェルで grep/var/lib/etcd/proc/mounts コマンドを実行して、ディスクがマウントされていることを確認します。
```
$ oc debug node/<node_name>
```
```
# grep -w "/var/lib/etcd" /proc/mounts
```
出力例
```
/dev/sdb /var/lib/etcd xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
```

関連情報

Red Hat Enterprise Linux CoreOS (RHCOS)

2.3.3. etcd データのデフラグ

大規模で密度の高いクラスターの場合に、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd は低下するパフォーマンスの影響を受ける可能性があります。etcd を定期的に維持および最適化して、データストアのスペースを解放します。Prometheus で etcd メトリックをモニターし、必要に応じてデフラグします。そうしないと、etcd はクラスター全体のアラームを発生させ、クラスターをメンテナンスモードにして、キーの読み取りと削除のみを受け入れる可能性があります。

これらの主要な指標をモニターします。

etcd_server_quota_backend_bytes、これは現在のクォータ制限です
etcd_mvcc_db_total_size_in_use_in_bytes、これはヒストリーコンパクション後の実際のデータベース使用状況を示します。
etcd_mvcc_db_total_size_in_bytes はデフラグ待ちの空き領域を含むデータベースサイズを表します。

etcd データをデフラグし、etcd 履歴の圧縮などのディスクの断片化を引き起こすイベント後にディスク領域を回収します。

履歴の圧縮は 5 分ごとに自動的に行われ、これによりバックエンドデータベースにギャップが生じます。この断片化された領域は etcd が使用できますが、ホストファイルシステムでは利用できません。ホストファイルシステムでこの領域を使用できるようにするには、etcd をデフラグする必要があります。

デフラグは自動的に行われますが、手動でトリガーすることもできます。

注記

etcd Operator はクラスター情報を使用してユーザーの最も効率的な操作を決定するため、ほとんどの場合、自動デフラグが適しています。

2.3.3.1. 自動デフラグ

etcd Operator はディスクを自動的にデフラグします。手動による介入は必要ありません。

以下のログのいずれかを表示して、デフラグプロセスが成功したことを確認します。

etcd ログ
cluster-etcd-operator Pod
Operator ステータスのエラーログ

警告

自動デフラグにより、Kubernetes コントローラーマネージャーなどのさまざまな OpenShift コアコンポーネントでリーダー選出の失敗が発生し、失敗したコンポーネントの再起動がトリガーされる可能性があります。再起動は無害であり、次に実行中のインスタンスへのフェイルオーバーをトリガーするか、再起動後にコンポーネントが再び作業を再開します。

最適化が成功した場合のログ出力の例

etcd member has been defragmented: <member_name>, memberID: <member_id>

最適化に失敗した場合のログ出力の例

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>

2.3.3.2. 手動デフラグ

Prometheus アラートは、手動でのデフラグを使用する必要がある場合を示します。アラートは次の 2 つの場合に表示されます。

etcd が使用可能なスペースの 50% 以上を 10 分を超過して使用する場合
etcd が合計データベースサイズの 50% 未満を 10 分を超過してアクティブに使用している場合

また、PromQL 式を使用した最適化によって解放される etcd データベースのサイズ (MB 単位) を確認することで、最適化が必要かどうかを判断することもできます ((etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024)。

警告

etcd のデフラグはプロセスを阻止するアクションです。etcd メンバーはデフラグが完了するまで応答しません。このため、各 Pod のデフラグアクションごとに少なくとも 1 分間待機し、クラスターが回復できるようにします。

以下の手順に従って、各 etcd メンバーで etcd データをデフラグします。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

リーダーを最後にデフラグする必要があるため、どの etcd メンバーがリーダーであるかを判別します。

etcd Pod のリストを取得します。

$ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

出力例

etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

Pod を選択し、以下のコマンドを実行して、どの etcd メンバーがリーダーであるかを判別します。

$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

出力例

Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

この出力の IS LEADER 列に基づいて、https://10.0.199.170:2379 エンドポイントがリーダーになります。このエンドポイントを直前の手順の出力に一致させると、リーダーの Pod 名は etcd-ip-10-0-199-170.example.redhat.com になります。

etcd メンバーのデフラグ。

実行中の etcd コンテナーに接続し、リーダーではない Pod の名前を渡します。
```
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
```
ETCDCTL_ENDPOINTS 環境変数の設定を解除します。
```
sh-4.4# unset ETCDCTL_ENDPOINTS
```
etcd メンバーのデフラグを実行します。
```
sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
```
出力例
```
Finished defragmenting etcd member[https://localhost:2379]
```
タイムアウトエラーが発生した場合は、コマンドが正常に実行されるまで --command-timeout の値を増やします。

データベースサイズが縮小されていることを確認します。

sh-4.4# etcdctl endpoint status -w table --cluster

出力例

+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

この例では、この etcd メンバーのデータベースサイズは、開始時のサイズの 104 MB ではなく 41 MB です。

これらの手順を繰り返して他の etcd メンバーのそれぞれに接続し、デフラグします。常に最後にリーダーをデフラグします。
etcd Pod が回復するように、デフラグアクションごとに 1 分以上待機します。etcd Pod が回復するまで、etcd メンバーは応答しません。

領域のクォータの超過により NOSPACE アラームがトリガーされる場合、それらをクリアします。
1. NOSPACE アラームがあるかどうかを確認します。
```
sh-4.4# etcdctl alarm list
```
  出力例
```
memberID:12345678912345678912 alarm:NOSPACE
```
2. アラームをクリアします。
```
sh-4.4# etcdctl alarm disarm
```

2.3. etcd に関する推奨されるプラクティス

2.3.1. etcd に関する推奨されるプラクティス

2.3.2. etcd を別のディスクに移動する

2.3.3. etcd データのデフラグ

2.3.3.1. 自動デフラグ

2.3.3.2. 手動デフラグ

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links