etcdに適したストレージ速度? フィオに聞いてみよう

fio と etcd についての短い話

クラスターのパフォーマンス etcd ストレージのパフォーマンスに大きく依存します。 etcd はいくつかのメトリクスをにエクスポートします プロメテウス必要なストレージ パフォーマンス情報を提供します。 たとえば、wal_fsync_duration_seconds メトリクスです。 etcd のドキュメントには次のように書かれています: ストレージが十分に高速であるとみなされるには、このメトリクスの 99 パーセンタイルが 10 ミリ秒未満である必要があります。 Linux マシンで etcd クラスターを実行する予定で、ストレージ (SSD など) が十分に高速かどうかを評価したい場合は、次のように使用できます。 FIO は、I/O 操作をテストするための一般的なツールです。 次のコマンドを実行します。ここで、test-data はストレージ マウント ポイントの下のディレクトリです。

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

結果を見て、期間の 99 パーセンタイルであることを確認するだけです。 fdatasync 10ミリ秒未満。 そうであれば、かなり高速なストレージがあることになります。 結果の例を次に示します。

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

注釈

• 特定のシナリオに合わせて --size および --bs オプションをカスタマイズしました。 fio から有用な結果を得るには、独自の値を指定します。 どこで入手できますか? 読む fio の設定方法をどのように学んだか.
• テスト中、すべての I/O 負荷は fio から発生します。 実際のシナリオでは、wal_fsync_duration_seconds に関連するもの以外にも、他の書き込みリクエストがストレージに送信される可能性があります。 追加の負荷により、wal_fsync_duration_seconds の値が増加します。 したがって、99 パーセンタイルが 10 ミリ秒に近い場合、ストレージの速度が不足しています。
• バージョンを取る FIO 3.5以上 (以前のものでは fdatasync 期間のパーセンタイルが表示されません)。
• 上記は fio の結果のほんの一部です。

fio と etcd についての長い話

etcdのWALとは何ですか

通常、データベースが使用するのは 先行書き込みログ; etcdもそれを使用します。 ここでは、先行書き込みログ (WAL) については詳しく説明しません。 etcd クラスターの各メンバーがそれを永続ストレージに維持していることを知っていれば十分です。 etcd は、各キーと値の操作 (更新など) をストアに適用する前に WAL に書き込みます。 ストレージ メンバーの XNUMX つがクラッシュしてスナップショット間で再起動した場合、WAL コンテンツによる最後のスナップショット以降のトランザクションをローカルに復元できます。

クライアントがキー/値ストアにキーを追加するか、既存のキーの値を更新すると、etcd は永続ストレージ内の通常のファイルである WAL に操作を記録します。 etcd は、処理を続行する前に、WAL エントリが実際に発生したことを完全に確認する必要があります。 Linux では、XNUMX つのシステム コールではこれに十分ではありません。 書きます物理ストレージへの実際の書き込みが遅れる可能性があるためです。 たとえば、Linux は、WAL エントリをカーネル メモリ内のキャッシュ (ページ キャッシュなど) にしばらく保存することがあります。 データを永続ストレージに正確に書き込むためには、書き込み後に fdatasync システム コールが必要であり、etcd はそれを使用するだけです (作業の結果からわかるように) ストラス、ここで 8 は WAL ファイル記述子です):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

残念ながら、永続ストレージへの書き込みは即座には行われません。 fdatasync 呼び出しが遅い場合、etcd システムのパフォーマンスが低下します。 etcd のドキュメントには次のように書かれています99 パーセンタイルで、fdatasync 呼び出しが WAL ファイルに書き込むのに 10 ミリ秒未満かかる場合、ストレージは十分に高速であるとみなされます。 ストレージには他にも便利なメトリクスがありますが、この投稿ではこのメトリクスについてのみ説明します。

fio を使用したスト​​レージの見積もり

ストレージが etcd に適しているかどうかを評価する必要がある場合は、非常に人気のある I/O 負荷テスト ツールである fio を使用してください。 ディスク操作は、同期と非同期、多くのクラスのシステム コールなど、非常に異なる可能性があることを覚えておく必要があります。その結果、fio の使用は非常に困難になります。 多くのパラメーターがあり、それらの値のさまざまな組み合わせによって、非常に異なる I/O ワークロードが生成されます。 etcd の適切な数値を取得するには、WAL ファイルを書き込むときに fio からのテスト書き込み負荷が etcd からの実際の負荷にできるだけ近いことを確認する必要があります。

したがって、fio は少なくとも、ファイルへの一連の連続書き込みの形式でロードを作成する必要があります。各書き込みはシステム コールで構成されます。 書きますその後に fdatasync システム コールが続きます。 fio へのシーケンシャル書き込みには --rw=write オプションが必要です。 fio が書き込み時に write システム コールを使用するようにするには、 書き込む、--ioengine=sync パラメータを指定する必要があります。 最後に、書き込みのたびに fdatasync を呼び出すには、 --fdatasync=1 パラメーターを追加する必要があります。 この例の他の XNUMX つのオプション (--size と -bs) はスクリプト固有です。 次のセクションでは、それらを設定する方法を説明します。

正確に fio を使用する理由とその設定方法を学んだ方法

この記事では、実際のケースについて説明します。 クラスターがあります Kubernetes Prometheus で監視した v1.13。 etcd v3.2.24 は SSD でホストされていました。 etcd メトリクスは、クラスターが何も行っていない場合でも、fdatasync レイテンシが高すぎることを示しました。 指標は奇妙で、それが何を意味するのかよくわかりませんでした。 クラスターは仮想マシンで構成されており、物理 SSD または仮想化レイヤーで問題が何であるかを理解する必要がありました。 さらに、ハードウェアとソフトウェアの構成に変更を加えることが多く、その結果を評価する方法が必要でした。 すべての構成で etcd を実行して Prometheus メトリクスを確認することもできますが、それは面倒すぎます。 私たちは、特定の構成を評価する非常に簡単な方法を探していました。 etcd からの Prometheus メトリクスを正しく理解しているかどうかを確認したいと思いました。

しかし、そのためには XNUMX つの問題を解決する必要がありました。 まず、etcd が WAL に書き込むときに作成する I/O 負荷はどのようなものでしょうか? どのようなシステムコールが使用されていますか? レコードのサイズはどれくらいですか? 次に、これらの質問に答えると、同様のワークロードを fio でどのように再現できるでしょうか? fio は多くのオプションを備えた非常に柔軟なツールであることを忘れないでください。 コマンドを使用するという XNUMX つのアプローチで両方の問題を解決しました。 lsof и ストラス。 lsof は、プロセスとその関連ファイルによって使用されるすべてのファイル記述子をリストします。 また、strace を使用すると、すでに実行中のプロセスを検査したり、プロセスを開始して検査したりできます。 strace は、検査対象のプロセス (およびその子プロセス) からのすべてのシステムコールを出力します。 etcd も同様のアプローチを採用しているため、後者は非常に重要です。

クラスターに負荷がかかっていないときに、最初に strace を使用して Kubernetes の etcd サーバーを調査しました。 ほとんどすべての WAL レコードがほぼ同じサイズ (2200 ～ 2400 バイト) であることがわかりました。 したがって、投稿の冒頭のコマンドでは、パラメータ -bs=2300 を指定しました (bs は各 fio エントリのバイト単位のサイズを意味します)。 etcd エントリのサイズは etcd のバージョン、ディストリビューション、パラメータ値などに依存し、fdatasync の期間に影響することに注意してください。 同様のシナリオがある場合は、strace を使用して etcd プロセスを調べて、正確な数を調べてください。

次に、etcd ファイル システムが何をしているのかをよく理解するために、strace と -ffttT オプションを使用して etcd ファイル システムを開始しました。 そこで、子プロセスを調べて、それぞれの出力を別のファイルに記録し、各システム コールの開始と継続時間に関する詳細なレポートも取得しようとしました。 lsof を使用して、strace 出力の分析を確認し、どのファイル記述子がどの目的で使用されているかを確認しました。 そこで strace の助けを借りて、上記の結果が得られました。 同期時間の統計により、etcd からの wal_fsync_duration_seconds が WAL ファイル記述子を使用した fdatasync 呼び出しと一致していることが確認されました。

fio のドキュメントを確認し、fio が etcd と同様の負荷を生成するようにスクリプトのオプションを選択しました。 また、etcd と同様に strace から fio を実行して、システム コールとその継続時間をチェックしました。

fio からの I/O 負荷全体を表す --size パラメーターの値を慎重に選択しました。 この例では、これはストレージに書き込まれた合計バイト数です。 これは、書き込み (および fdatasync) システム コールの数に正比例することが判明しました。 bs の特定の値では、fdatasync 呼び出しの数 = size/bs になります。 パーセンタイルに興味があるため、確実にするには十分なサンプルが必要であり、10^4 (つまり 22 メビバイト) で十分であると計算しました。 --size が小さい場合、外れ値が発生する可能性があります (たとえば、いくつかの fdatasync 呼び出しに通常より時間がかかり、99 パーセンタイルに影響します)。

自分で試してください

fio を使用して、ストレージが etcd が適切に動作するのに十分な速度であるかどうかを確認する方法を説明しました。 これで、たとえば SSD ストレージを備えた仮想マシンを使用して、自分で試すことができます。 IBMクラウド.

出所： habr.com