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 インフラストラクチャーを共有する他のワークロードをコントロールプレーンノードに併置することは避けてください。

fdatasync を含め、10 ミリ秒未満で 8 KB の 50 IOPS 以上を連続して書き込むことができるブロックデバイスで etcd を実行します。負荷の高いクラスターの場合、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 メンバーデータベースのサイズは、通常の運用時にクラスター内で異なる場合があります。この違いは、リーダーのサイズが他のメンバーと異なっていても、クラスターのアップグレードには影響しません。

2.3.2. 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.3. etcd のノードスケーリング

一般に、クラスターには 3 つのコントロールプレーンノードが必要です。ただし、クラスターがベアメタルプラットフォームにインストールされている場合は、インストール後のタスクとして、クラスターを最大 5 つのコントロールプレーンノードまで拡張できます。たとえば、インストール後に 3 ノードから 4 ノードに拡張するには、ホストを追加してコントロールプレーンノードとしてインストールします。次に、etcd Operator は追加のコントロールプレーンノードを考慮してそれに応じてスケーリングします。

クラスターを 4 つまたは 5 つのコントロールプレーンノードにスケーリングできるのは、ベアメタルプラットフォームのみです。

Assisted Installer を使用してコントロールプレーンノードをスケーリングする方法の詳細は、「API を使用したホストの追加」および「正常なクラスターへのプライマリーコントロールプレーンノードのインストール」を参照してください。

次の表は、さまざまなサイズのクラスターの障害許容度を示しています。

表2.2 クラスターサイズによる障害許容度
クラスターサイズ	過半数	障害許容度
1 ノード	1	0
3 ノード	2	1
4 ノード	3	1
5 ノード	3	2

クォーラム損失からの回復の詳細は、「以前のクラスター状態への復元」を参照してください。

関連情報

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

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

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

注記

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

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.5. 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.5.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.5.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.6. etcd のチューニングパラメーターの設定

コントロールプレーンのハードウェア速度を "Standard"、"Slower"、またはデフォルトの "" に設定できます。

デフォルト設定では、使用する速度をシステムが決定できます。システムは以前のバージョンから値を選択できるため、この値により、この機能が存在しないバージョンからのアップグレードが可能になります。

他の値のいずれかを選択すると、デフォルトが上書きされます。タイムアウトまたはハートビートの欠落が原因でリーダーの選出が多数発生し、システムが "" または "Standard" に設定されている場合は、ハードウェア速度を "Slower" に設定して、遅延の増加に対するシステムの耐性を高めます。

2.3.6.1. ハードウェア速度許容値の変更

etcd のハードウェア速度許容値を変更するには、次の手順を実行します。

手順

次のコマンドを入力して、現在の値を確認します。
```
$ oc describe etcd/cluster | grep "Control Plane Hardware Speed"
```
出力例
```
Control Plane Hardware Speed:  <VALUE>
```
注記
出力が空の場合、フィールドは設定されていないため、デフォルト ("") として考慮される必要があります。

次のコマンドを入力して値を変更します。<value> を有効な値のいずれかに置き換えます (""、"Standard"、または "Slower")。

$ oc patch etcd/cluster --type=merge -p '{"spec": {"controlPlaneHardwareSpeed": "<value>"}}'

次の表は、各プロファイルのハートビート間隔とリーダー選出タイムアウトを示しています。これらの値は変更になる可能性があります。

プロファイル	ETCD_HEARTBEAT_INTERVAL	ETCD_LEADER_ELECTION_TIMEOUT
`""`	プラットフォームによって異なる	プラットフォームによって異なる
`Standard`	100	1000
`Slower`	500	2500

出力を確認します。
出力例
```
etcd.operator.openshift.io/cluster patched
```
有効な値以外の値を入力すると、エラー出力が表示されます。たとえば、"Faster" 値を入力すると、出力は次のようになります。
出力例
```
The Etcd "cluster" is invalid: spec.controlPlaneHardwareSpeed: Unsupported value: "Faster": supported values: "", "Standard", "Slower"
```

次のコマンドを入力して、値が変更したことを確認します。

$ oc describe etcd/cluster | grep "Control Plane Hardware Speed"

出力例

Control Plane Hardware Speed:  ""

etcd Pod がロールアウトされるまで待ちます。

$ oc get pods -n openshift-etcd -w

次の出力は、master-0 の予期されるエントリーを示しています。続行する前に、すべてのマスターのステータスが 4/4 Running になるまで待ちます。

出力例

installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Pending             0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Pending             0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     ContainerCreating   0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     ContainerCreating   0          1s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           1/1     Running             0          2s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          34s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          36s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          36s
etcd-guard-ci-ln-qkgs94t-72292-9clnd-master-0            0/1     Running             0          26m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Terminating         0          11m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Terminating         0          11m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Pending             0          0s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Init:1/3            0          1s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Init:2/3            0          2s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     PodInitializing     0          3s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  3/4     Running             0          4s
etcd-guard-ci-ln-qkgs94t-72292-9clnd-master-0            1/1     Running             0          26m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  3/4     Running             0          20s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Running             0          20s

次のコマンドを入力して値を確認します。
```
$ oc describe -n openshift-etcd pod/<ETCD_PODNAME> | grep -e HEARTBEAT_INTERVAL -e ELECTION_TIMEOUT
```
注記
これらの値はデフォルトから変更されていない可能性があります。

関連情報

フィーチャーゲートについて

2.3.7. etcd のデータベースサイズを増やす

各 etcd インスタンスのディスククォータをギビバイト (GiB) 単位で設定できます。etcd インスタンスにディスククォータを設定する場合は、8 から 32 までの整数値を指定できます。デフォルト値は 8 です。増加値のみ指定できます。

low space アラートが表示された場合は、ディスククォータを増やすことを推奨します。このアラートは、自動コンパクションおよびデフラグにもかかわらず、クラスターが大きすぎて etcd に収まらないことを示します。このアラートが表示された場合、etcd のスペースが不足すると書き込みが失敗するため、すぐにディスククォータを増やす必要があります。

ディスククォータを増やすことが推奨されるもう 1 つのシナリオは、excessive database growth アラートが発生した場合です。このアラートは、今後 4 時間以内にデータベースが大きくなりすぎる可能性があることを警告しています。このシナリオでは、最終的に low space アラートが表示されたり、書き込みが失敗したりしないように、ディスククォータを増やすことを検討してください。

ディスククォータを増やしても、指定したディスク領域はすぐには予約されません。代わりに、etcd は必要に応じてそのサイズまで拡張できます。etcd が、ディスククォータに指定した値よりも大きい専用ディスク上で実行されていることを確認します。

大規模な etcd データベースの場合、コントロールプレーンノードに追加のメモリーとストレージが必要です。API サーバーキャッシュを考慮する必要があるため、最小メモリー要件は etcd データベースの設定サイズの 3 倍以上になります。

重要

etcd のデータベースサイズを増やす機能は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

2.3.7.1. etcd データベースのサイズを変更する

etcd のデータベースサイズを変更するには、次の手順を実行します。

手順

次のコマンドを入力して、各 etcd インスタンスのディスククォータの現在の値を確認します。
```
$ oc describe etcd/cluster | grep "Backend Quota"
```
出力例
```
Backend Quota Gi B: <value>
```

次のコマンドを入力して、ディスククォータの値を変更します。

$ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": <value>}}'

出力例

etcd.operator.openshift.io/cluster patched

検証

次のコマンドを入力して、ディスククォータの新しい値が設定されていることを確認します。
```
$ oc describe etcd/cluster | grep "Backend Quota"
```
etcd Operator は、新しい値を使用して etcd インスタンスを自動的にロールアウトします。

次のコマンドを入力して、etcd Pod が起動して実行されていることを確認します。

$ oc get pods -n openshift-etcd

次の出力は、予想されるエントリーを示しています。

出力例

NAME                                                   READY   STATUS      RESTARTS   AGE
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-0                4/4     Running     0          39m
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-1                4/4     Running     0          37m
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-2                4/4     Running     0          41m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-0          1/1     Running     0          51m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-1          1/1     Running     0          49m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-2          1/1     Running     0          54m
installer-5-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          51m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-0         0/1     Completed   0          46m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          44m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-2         0/1     Completed   0          49m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-0         0/1     Completed   0          40m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          38m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-2         0/1     Completed   0          42m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-0   0/1     Completed   0          43m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-1   0/1     Completed   0          43m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-2   0/1     Completed   0          43m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-0   0/1     Completed   0          42m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-1   0/1     Completed   0          42m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-2   0/1     Completed   0          42m

次のコマンドを入力して、etcd Pod のディスククォータ値が更新されていることを確認します。
```
$ oc describe -n openshift-etcd pod/<etcd_podname> | grep "ETCD_QUOTA_BACKEND_BYTES"
```
値はデフォルト値の 8 から変更されていない可能性があります。
出力例
```
ETCD_QUOTA_BACKEND_BYTES:                               8589934592
```
注記
設定する値は GiB 単位の整数ですが、出力に表示される値はバイトに変換されます。

2.3.7.2. トラブルシューティング

etcd のデータベースサイズを増やそうとしたときに問題が発生した場合、次のトラブルシューティング手順が役立つ場合があります。

2.3.7.2.1. 値が小さすぎる

指定した値が 8 未満の場合、次のエラーメッセージが表示されます。

$ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": 5}}'

エラーメッセージの例

The Etcd "cluster" is invalid:
* spec.backendQuotaGiB: Invalid value: 5: spec.backendQuotaGiB in body should be greater than or equal to 8
* spec.backendQuotaGiB: Invalid value: "integer": etcd backendQuotaGiB may not be decreased

この問題を解決するには、8 - 32 の間の整数を指定します。

2.3.7.2.2. 値が大きすぎる

指定した値が 32 より大きい場合、次のエラーメッセージが表示されます。

$ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": 64}}'

エラーメッセージの例

The Etcd "cluster" is invalid: spec.backendQuotaGiB: Invalid value: 64: spec.backendQuotaGiB in body should be less than or equal to 32

この問題を解決するには、8 - 32 の間の整数を指定します。

2.3.7.2.3. 価値が下がっている

値が 8 - 32 の有効な値に設定されている場合、値を減らすことはできません。減らそうとすると、エラーメッセージが表示されます。

次のコマンドを入力して現在の値を確認します。
```
$ oc describe etcd/cluster | grep "Backend Quota"
```
出力例
```
Backend Quota Gi B: 10
```

次のコマンドを入力してディスククォータ値を減らします。

$ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": 8}}'

エラーメッセージの例

The Etcd "cluster" is invalid: spec.backendQuotaGiB: Invalid value: "integer": etcd backendQuotaGiB may not be decreased

この問題を解決するには、10 より大きい整数を指定します。

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

2.3.1. etcd のストレージプラクティス

2.3.2. etcd のハードウェアの検証

2.3.3. etcd のノードスケーリング

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

2.3.5. etcd データのデフラグ

2.3.5.1. 自動デフラグ

2.3.5.2. 手動デフラグ

2.3.6. etcd のチューニングパラメーターの設定

2.3.6.1. ハードウェア速度許容値の変更

2.3.7. etcd のデータベースサイズを増やす

2.3.7.1. etcd データベースのサイズを変更する

2.3.7.2. トラブルシューティング

2.3.7.2.1. 値が小さすぎる

2.3.7.2.2. 値が大きすぎる

2.3.7.2.3. 価値が下がっている

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links