etcd に十分なパフォーマンスがあるかどうか fio を使用してディスクをチェックする方法

ノート。 翻訳。: この記事は、etcd データベースの操作に関連する実際の問題の解決策を求めて IBM Cloud エンジニアによって実行されたミニリサーチの結果です。 同様の課題は私たちにも関係がありましたが、著者たちの考察と行動の過程は、より広い文脈で興味深いかもしれません。

記事全体の簡単な要約: fio と etcd

etcd クラスターのパフォーマンスは、基盤となるストレージの速度に大きく依存します。 etcd は、パフォーマンスを監視するためにさまざまな Prometheus メトリクスをエクスポートします。 そのうちの XNUMX つは、 wal_fsync_duration_seconds。 etcd のドキュメント内 それは言うこのメトリクスの 99 パーセンタイルが 10 ミリ秒を超えない場合、ストレージは十分に高速であると見なすことができます。

Linux マシン上で etcd クラスターのセットアップを検討しており、ドライブ (SSD など) が十分に高速であるかどうかをテストしたい場合は、一般的な I/O テスターを使用することをお勧めします。 FIO。 次のコマンドを実行するだけで十分です（ディレクトリ test-data テストしたドライブのマウントされたパーティションに配置する必要があります):

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

あとは出力を見て、99 パーセンタイルが適合するかどうかを確認するだけです。 fdatasync 10ミリ秒以内に。 そうであれば、ドライブは十分に高速に動作しています。 出力例を次に示します。

fsync/fdatasync/sync_file_range:
  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]

いくつかのメモ：

1. 上記の例では、パラメータを調整しました --size и --bs 特定のケースの場合。 意味のある結果を得るには fio、ユースケースに適した値を指定します。 それらを選択する方法については以下で説明します。
2. テスト中のみ fio ディスクサブシステムをロードします。 実際には、他のプロセス (関連するプロセス以外) がディスクに書き込む可能性があります。 wal_fsync_duration_seconds）。 この追加の負荷は増加する可能性があります wal_fsync_duration_seconds。 言い換えれば、次のテストで 99 パーセンタイルが得られた場合、 fio、10 ミリ秒未満しかない場合、ストレージのパフォーマンスが十分ではない可能性が十分にあります。
3. テストにはバージョンが必要です fio 3.5以上古いバージョンでは結果が集計されないため fdatasync パーセンタイルの形式で。
4. 上記の結論は、一般的な結論からのほんの一部の抜粋です fio.

fio と etcd の詳細

WAL などについて一言

一般にデータベースでは、 プロアクティブなロギング (先行書き込みログ、WAL)。 etcd も影響を受けます。 WAL についての説明はこの記事の範囲を超えていますが、この目的のために知っておく必要があるのは、etcd クラスターの各メンバーが WAL を永続ストレージに保存するということです。 etcd は、キーと値のストレージ操作 (更新など) を実行する前に WAL に書き込みます。 ノードがクラッシュしてスナップショット間で再起動した場合、etcd は WAL の内容に基づいて前のスナップショット以降のトランザクションを回復できます。

したがって、クライアントが KV ストアにキーを追加するか、既存のキーの値を更新するたびに、etcd は永続ストア内の通常のファイルである WAL に操作の記述を追加します。 etcd は、続行する前に、WAL エントリが実際に保存されていることを 100% 確認する必要があります。 Linux でこれを実現するには、システム コールを使用するだけでは十分ではありません。 write物理メディアへの書き込み操作自体が遅れる可能性があるためです。 たとえば、Linux は、しばらくの間、WAL エントリをメモリ内カーネル キャッシュ (ページ キャッシュなど) に保持することがあります。 データがメディアに確実に書き込まれるようにするには、書き込み後にシステム コールを呼び出す必要があります。 fdatasync - これはまさに etcd が行うことです (次の出力でわかるように) strace; ここ 8 - WAL ファイル記述子):

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

残念ながら、永続ストレージへの書き込みには時間がかかります。 fdatasync 呼び出しの長時間の実行は、etcd のパフォーマンスに影響を与える可能性があります。 リポジトリのドキュメント内 表示されます十分なパフォーマンスを得るには、すべての呼び出しの継続時間の 99 パーセンタイルが必要です。 fdatasync WAL ファイルへの書き込みは 10 ミリ秒未満でした。 他にもストレージ関連の指標はありますが、この記事ではそれに焦点を当てます。

fio でストレージを大切にする

ユーティリティを使用して、特定のストレージが etcd での使用に適しているかどうかを評価できます。 FIO — 人気の I/O テスター。 ディスク I/O は、同期/非同期、さまざまな syscall クラスなど、さまざまな方法で発生する可能性があることに注意してください。 コインの反対側は、 fio 非常に使いにくい。 ユーティリティには多くのパラメーターがあり、それらの値のさまざまな組み合わせにより、まったく異なる結果が得られます。 etcd の適切な見積もりを取得するには、fio によって生成される書き込み負荷が etcd の WAL ファイル書き込み負荷にできるだけ近いことを確認する必要があります。

• これは、生成された fio ロードは少なくともファイルへの一連の連続書き込みである必要があり、各書き込みはシステム コールで構成されます。 writeに続く fdatasync.
• シーケンシャル書き込みを有効にするには、フラグを指定する必要があります。 --rw=write.
• その fio 呼び出しを使用して書き込んだ write (他のシステムコールではなく、たとえば、 pwrite)、フラグを使用します --ioengine=sync.
• 最後に旗です --fdatasync=1 すべてのことを保証します write でなければなりません fdatasync.
• この例の他の XNUMX つのパラメーターは次のとおりです。 --size и --bs - 特定の使用例によって異なる場合があります。 次のセクションでは、その構成について説明します。

fio を選んだ理由とその設定方法を学んだ方法

このメモは、私たちが実際に遭遇したケースに基づいています。 Kubernetes v1.13 上にクラスターを構築し、Prometheus 上でモニタリングを行いました。 etcd v3.2.24 のストレージとして SSD が使用されました。 etcd メトリクスのレイテンシが高すぎることが示されました fdatasyncクラスターがアイドル状態のときでも。 私たちにとって、これらの指標は非常に疑わしいものに見え、それが正確に何を表しているのかわかりませんでした。 さらに、クラスターは仮想マシンで構成されていたため、遅延が仮想化によるものなのか、SSD によるものなのかを判断することはできませんでした。

さらに、ハードウェアおよびソフトウェア構成のさまざまな変更を検討したため、それらを評価する方法が必要でした。 もちろん、各構成で etcd を実行して、対応する Prometheus メトリクスを確認することも可能ですが、それには多大な労力が必要になります。 私たちが必要としていたのは、特定の構成を評価する簡単な方法でした。 etcd からの Prometheus メトリクスの理解をテストしたいと思いました。

これには、次の XNUMX つの問題を解決する必要がありました。

• まず、WAL ファイルに書き込むときに etcd によって生成される I/O 負荷はどのようなものになるでしょうか? どのようなシステムコールが使用されていますか? レコードブロックのサイズはどれくらいですか?
• 次に、上記の質問に対する答えがあるとします。 対応する負荷を再現する方法 fio？ 結局 fio — 豊富なパラメータを備えた非常に柔軟なユーティリティ (これは簡単に確認できます。たとえば、 ここで - 約翻訳）.

同じコマンドベースのアプローチで両方の問題を解決しました lsof и strace:

• ととも​​に lsof プロセスで使用されるすべてのファイル記述子と、それらが参照するファイルを表示できます。
• ととも​​に strace すでに実行中のプロセスを分析したり、プロセスを実行して監視したりできます。 このコマンドは、このプロセスによって行われたすべてのシステム コールと、必要に応じてその子孫を表示します。 後者はフォークするプロセスにとって重要であり、etcd もそのようなプロセスの XNUMX つです。

私たちが最初にやったことは、 strace Kubernetes クラスター内の etcd サーバーがアイドル状態であるときに検査します。

そのため、WAL レコード ブロックは非常に密にグループ化されており、大部分のサイズは 2200 ～ 2400 バイトの範囲にあることがわかりました。 この記事の冒頭のコマンドでフラグを使用するのはそのためです。 --bs=2300 (bs の各書き込みブロックのバイト単位のサイズです。 fio).

etcd 書き込みブロックのサイズは、バージョン、デプロイメント、パラメーター値などによって異なる場合があることに注意してください。 - 持続時間に影響します fdatasync。 同様のユースケースがある場合は、次のように分析してください。 strace etcd プロセスで最新の値を取得します。

次に、etcd がファイル システムでどのように動作するかについて明確かつ包括的なアイデアを得るために、以下から開始しました。 strace フラグ付き -ffttT。 これにより、子プロセスをキャプチャし、それぞれの出力を別のファイルに書き込むことが可能になりました。 さらに、各システム コールの開始時刻と継続時間に関する詳細情報が取得されました。

コマンドも使用しました lsof出力の理解を確認するため strace どのファイル記述子がどの目的で使用されたかという点で。 結論が出ました strace、上記と同様です。 同期時間による統計操作により、メトリクスが次のことを確認しました。 wal_fsync_duration_seconds etcd からの呼び出しと一致する fdatasync WAL ファイル記述子を使用します。

で生成するには fio etcd のワークロードと同様のワークロードでは、ユーティリティのドキュメントが検討され、タスクに適したパラメータが選択されました。 正しいシステムコールが進行中であることを確認し、次のコマンドを実行してその継続時間を確認しました。 fio の strace (etcdの場合と同様)。

パラメータの値の決定には特に注意が払われました --size。 これは、fio ユーティリティによって生成される合計 I/O 負荷を表します。 この例では、これはメディアに書き込まれた合計バイト数です。 通話数に正比例します write （そして fdatasync）。 特定の bs 通話回数 fdatasync 等しい size / bs.

パーセンタイルに興味があったため、サンプル数が統計的に有意になるのに十分な大きさであることが必要でした。 そして決めたのは、 10^4 (22 MB のサイズに相当) で十分です。 パラメータ値を小さくする --size より顕著なノイズが発生しました（通話など） fdatasync、通常よりもはるかに時間がかかり、99 パーセンタイルに影響します)。

それはあなた次第です

記事では使い方を紹介しています fio etcd での使用を目的としたメディアが十分に高速であるかどうかを判断できます。 あとはあなた次第です！ サービス内で SSD ベースのストレージを備えた仮想マシンを探索できます IBMクラウド.

翻訳者からの追伸

既製のユースケースを使用 fio その他のタスクについては、を参照してください。 ドキュメンテーション または直接 プロジェクトリポジトリ (ドキュメントに記載されているものよりもさらに多くのものがあります)。

翻訳者からの PPS

私たちのブログもお読みください:

• «etcd 3.4.3: ストレージの信頼性とセキュリティの調査";
• «etcd Kubernetes クラスター内のデータを直接 (K8s API なしで) 使用した経験";
• «Kubernetes の運用における 6 つの興味深いシステム バグ [およびその解決策]'。

出所： habr.com