[再投稿] ETCDのハードウェア構成要件

ハードウェアの推奨事項

https：// github.com/etcd-io/etcd/blob/master/Documentation/op-guide/hardware.md

etcdは通常、開発またはテストの目的で限られたリソースでうまく動作します。ラップトップまたは安価なクラウドマシンでetcdを使用して開発するのが一般的です。ただし、本番環境でetcdクラスターを実行する場合、適切な管理にはいくつかのハードウェアガイドラインが役立ちます。これらの提案は難しいルールではありません。これらは、堅牢な運用展開の出発点として役立ちます。いつものように、展開は運用環境で実行する前に、シミュレートされたワークロードでテストする必要があります。

CPU

ほとんどのetcdデプロイメントでは、多くのCPU容量が必要です。通常のクラスターでは、スムーズに実行するために2〜4個のコアが必要です。etcdはメモリからのリクエストを処理できるため、負荷の高いetcdデプロイメントは数千のクライアントまたは1秒あたり数万のリクエストを処理しますが、CPUバウンドになる傾向があります。このような重い展開には、通常8〜16個の専用コアが必要です。

記憶

etcdのメモリフットプリントは比較的小さいですが、そのパフォーマンスはまだ十分なメモリがあるかどうかに依存します。etcdサーバーは、キーと値のデータを積極的にキャッシュし、残りのメモリー追跡ウォッチャーのほとんどを費やします。通常は8GBで十分です。数千のウォッチャーと数百万のキーを使用する大規模な展開では、それに応じて16 GB〜64 GBのメモリを割り当てます。

ディスク

高速ディスクは、etcdのデプロイメントのパフォーマンスと安定性にとって最も重要な要素です。

ディスクが遅いと、etcdリクエストのレイテンシが増加し、クラスターの安定性が損なわれる可能性があります。etcdのコンセンサスプロトコルはメタデータをログに永続的に保存することに依存しているため、etcdクラスターメンバーの大半はすべてのリクエストをディスクに書き込む必要があります。さらに、etcdは状態をディスクにインクリメンタルにチェックポイントするため、このログを切り捨てることができます。これらの書き込みに時間がかかりすぎると、ハートビートがタイムアウトして選択がトリガーされ、クラスターの安定性が損なわれる可能性があります。一般に、ディスクがetcdに対して十分高速かどうかを判断するには、fioなどのベンチマークツールを使用できます。例については、こちらをお読みください。

etcdはディスク書き込みレイテンシーに非常に敏感です。通常、50の順次IOPS（たとえば、7200 RPMディスク）が必要です。負荷の高いクラスターでは、500のシーケンシャルIOPS（たとえば、一般的なローカルSSDまたは高性能仮想化ブロックデバイス）が推奨されます。ほとんどのクラウドプロバイダーは、シーケンシャルIOPSではなく、同時IOPSを公開することに注意してください。公開された同時IOPSは、順次IOPSの10倍になる可能性があります。実際のシーケンシャルIOPSを測定するには、diskbench や fioなどのディスクベンチマークツールを使用することをお勧めします。

etcdは適度なディスク帯域幅のみを必要としますが、障害が発生したメンバーがクラスターに追いつく必要がある場合、ディスク帯域幅を増やすと回復時間が短縮されます。通常、10MB /秒は15秒以内に100MBのデータを回復します。大規模なクラスターの場合、15秒以内に1GBのデータを回復するには、100MB /秒以上が推奨されます。

可能であれば、SSDでetcdのストレージをバックアップしてください。SSDは通常、書き込みレイテンシが低く、回転ディスクよりも変動が少ないため、etcdの安定性と信頼性が向上します。回転ディスクを使用している場合は、最速のディスク（15,000 RPM）を入手してください。RAID 0を使用することも、回転ディスクとSSDの両方でディスク速度を上げる効果的な方法です。少なくとも3つのクラスターメンバーがあれば、RAIDのミラーリングやパリティーバリアントは不要です。etcdの一貫したレプリケーションは、すでに高可用性を備えています。

通信網

マルチメンバーのetcdデプロイメントは、高速で信頼性の高いネットワークの恩恵を受けます。etcdの一貫性とパーティショントレラントの両方を実現するには、パーティション分割の停止による信頼性の低いネットワークが原因で可用性が低下します。待ち時間が短いため、etcdメンバーは高速に通信できます。高帯域幅は、失敗したetcdメンバーを回復する時間を短縮できます。一般的なetcdデプロイメントには1GbEで十分です。大規模なetcdクラスターの場合、10GbEネットワークは平均復旧時間を短縮します。

可能であれば、単一のデータセンター内にetcdメンバーをデプロイして、レイテンシのオーバーヘッドを回避し、イベントを分割する可能性を減らします。別のデータセンターの障害ドメインが必要な場合は、既存のデータセンターに近いデータセンターを選択してください。データセンター間の導入の詳細については、チューニングのドキュメントもご覧ください。

ハードウェア構成の例

AWSとGCE環境でのハードウェア設定の例をいくつか示します。前述のように、ストレスを感じる必要がありますが、管理者は、運用環境に配置する前に、シミュレートされたワークロードでetcdデプロイメントをテストする必要があります。

これらの構成では、これらのマシンが完全にetcd専用であると想定しています。これらのマシンでetcdとともに他のアプリケーションを実行すると、リソースの競合が発生し、クラスターが不安定になる可能性があります。

小さなクラスター

小さなクラスターは、クライアント数が100未満、1秒あたりのリクエスト数が200未満で、100 MB以下のデータを格納します。

アプリケーションワークロードの例：50ノードのKubernetesクラスター

プロバイダー	タイプ	vCPU	メモリ（GB）	最大同時IOPS	ディスク帯域幅（MB /秒）
AWS	m4.large	2	8	3600	56.25
GCE	n1-standard-2 + 50GB PD SSD	2	7.5	1500	25

中規模クラスター

中規模クラスターは、500クライアント未満、1秒あたり1,000リクエスト未満のサービスを提供し、500 MB以下のデータを保存します。

アプリケーションワークロードの例：250ノードのKubernetesクラスター

プロバイダー	タイプ	vCPU	メモリ（GB）	最大同時IOPS	ディスク帯域幅（MB /秒）
AWS	m4.xlarge	4	16	6000	93.75
GCE	n1-standard-4 + 150 GB PD SSD	4	15	4500	75

大きなクラスター

大規模なクラスターは、クライアント数が1,500未満、1秒あたりのリクエスト数が10,000未満で、1 GB以下のデータを格納します。

アプリケーションワークロードの例：1,000ノードのKubernetesクラスター

プロバイダー	タイプ	vCPU	メモリ（GB）	最大同時IOPS	ディスク帯域幅（MB /秒）
AWS	m4.2xlarge	8	32	8000	125
GCE	n1-standard-8 + 250GB PD SSD	8	30	7500	125

xLargeクラスター

xLargeクラスターは、1,500を超えるクライアント、1秒あたり10,000を超えるリクエストに対応し、1 GBを超えるデータを保存します。

アプリケーションワークロードの例：3,000ノードのKubernetesクラスター

プロバイダー	タイプ	vCPU	メモリ（GB）	最大同時IOPS	ディスク帯域幅（MB /秒）
AWS	m4.4xlarge	16	64	16,000	250
GCE	n1-standard-16 + 500GB PD SSD	16	60	15,000	250