通常、Kubernetes プラットフォームには使いやすく信頼性の高いブロック ストレージを見つける必要があります。

そこでこの記事では、複数のオープンソースストレージソリューションをベンチマークし、様々な条件下でのパフォーマンスを把握します。この比較では、DRBD (https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device) を異なるハードウェア構成でテストし、そのテスト結果を Ceph (https://ceph.io/en/) と比較します。

しかし、ソフトウェア定義ストレージ市場は常に進化を続けています。最近リリースされたMayastor（https://github.com/openebs/mayastor）やVitastor（https://vitastor.io/）をはじめ、新しいプロジェクトが次々と登場しています。この記事では、これら2つの新興ストレージソリューションについても取り上げます。

テスト環境

I. ハードウェア

• サーバー: AX61 サーバー 3 台。
• CPU : AMD Ryzen 9 3900 (24) @ 3.100GHz
• メモリ: Micron 32GB DDR4-3200 ECC UDIMM 2Rx8 CL22 (サーバーあたり4モジュール)
• ディスク: SAMSUNG MZQLB1T9HAJR-00007 1.92 TB (サーバーあたり 2 台)。
• ネットワーク: 10G (Intel 82599ES); 1G (Intel I210)

II. コアソフトウェア

• オペレーティング システム: Ubuntu 20.04.3 LTS (Focal Fossa);
• カーネル: 5.4.0-54-generic。

III. 主要なソフトウェアバージョン

• DRBD : 9.1.4 (linstor-server v1.17.0);
• Ceph : 16.2.7 (rook v1.8.2);
• マヤスター：1.0.0;
• Vitastor : 0.6.12 (カーネル 5.13.0-27-generic);
• ZFS: 0.8.3;
• LVM : 2.03.07

IV. テストブロック情報

• 仮想ボリューム サイズ: 100G (単一クライアント テストの場合)、10G (マルチクライアント テストの場合)。
• DRBD 同期プロトコル: C (完全同期)、ビットマップが有効。

ベンチマーク

ベンチマークはいくつかのステップで実行されます。

1. 「生の」NVMe ドライブのパフォーマンスをテストします。
2. バックエンドのオーバーヘッドをテストします (LVM vs LVMThin vs ZFS)。
3. DRBD のオーバーヘッドをテストします。
4. 他のクラスター ファイル システムと比較して、
5. ベンチマークはギガビット ネットワーク経由で実施されました。
6. ストレステスト。

以下は、この記事で提供されている fio を使用したテスト用のコマンドです。

 fio - name = randwrite_fsync - ioengine = libaio - direct = 1 - randrepeat = 0 - rw = randwrite - bs = 4k - numjobs = 1 - iodepth = 1 - fsync = 1
 fio - name = randwrite_jobs4 - ioengine = libaio - direct = 1 - randrepeat = 0 - rw = randwrite - bs = 4 k - numjobs = 4 - iodepth = 128 - group_reporting
 fio - name = randwrite - ioengine = libaio - direct = 1 - randrepeat = 0 - rw = randwrite - bs = 4k - numjobs = 1 - iodepth = 128
 fio - name =書き込み- ioengine = libaio - direct = 1 - randrepeat = 0 - rw =書き込み- bs = 4 M - numjobs = 1 - iodepth = 16
 fio - name = randread_fsync - ioengine = libaio - direct = 1 - randrepeat = 0 - rw = randread - bs = 4k - numjobs = 1 - iodepth = 1 - fsync = 1
 fio - name = randread_jobs4 - ioengine = libaio - direct = 1 - randrepeat = 0 - rw = randread - bs = 4 k - numjobs = 4 - iodepth = 128 - group_reporting
 fio - name = randread - ioengine = libaio - direct = 1 - randrepeat = 0 - rw = randread - bs = 4k - numjobs = 1 - iodepth = 128
 fio - name =読み取り- ioengine = libaio - direct = 1 - randrepeat = 0 - rw =読み取り- bs = 4 M - numjobs = 1 - iodepth = 16

アピールテストコマンドに関しては、この記事 (https://yourcmc.ru/wiki/Ceph_performance) でも詳しく紹介されており、以下に要約されています。

なぜこれらのコマンドがベンチマークに含まれているのでしょうか？ 結局のところ、次のような多くのパラメータがディスクのパフォーマンスに影響を与えるからです。

• ブロックサイズ;
• モード – 読み取り、書き込み、またはさまざまな読み取り/書き込み混合モード。
• 並列処理 – キューの深さとスレッドの数。つまり、並列 I/O 要求の数です。
• テスト時間;
• 初期のディスク状態 – 空、線形に埋められた、ランダムに埋められた、特定の期間内にランダムに書き込まれた。
• データ分散 – たとえば、ホット データの 10% とコールド データまたはホット データの 90% がどこか (たとえば、ディスクの先頭) に配置されます。
• その他のハイブリッド テスト モードには、たとえば、異なるブロック サイズのベンチマークを同時に使用することが含まれます。

結果は、様々なレベルの詳細情報で表示できます。単純な平均操作数や1秒あたりのメガバイト数に加えて、グラフ、ヒストグラム、パーセンタイルなど、様々な形式で表示できます。これらはすべて、現在のテストパフォーマンスを理解するのに役立ちます。

ベンチマークにはいくつかの問題もあります。例えば、一部のサーバーSSDベンダーは、テスト前にディスクを少なくとも2回ランダムに上書きすることで変換テーブルを前処理する必要があると考えています。しかし、これはSSDを現実のシナリオではほとんど遭遇しないような過酷な条件にさらしてしまうことになると私は考えています。

遅延と 1 秒あたりの操作数をプロットする必要があると言う人もいますが、これは「q」自体の関係ではなく、F1(q) と F2(q) の関係をプロットすることになるので、少し奇妙に思えます。

つまり、ベンチマークは時間のかかるプロセスになりかねません。完全な結果を得るには数日かかることもあります。3dnewsのようなSSDレビューサイトは、しばしばこのプロセスを採用しています。しかし、私たちはこれに何日も費やすつもりはありません。パフォーマンスを迅速に評価できるテストが必要なのです。

したがって、いくつかの「極端な」パターンを除外し、それらのパターン内の円盤を調べ、他の結果はこれらの「極端な」パターンの間に位置すると仮定し、パラメータに依存する滑らかな関数を形成します。これらのパターンはそれぞれ、有効なユースケースに対応しており、これも便利です。

• 主にリニアまたはラージブロックアクセスを使用するアプリケーション：このようなアプリケーションでは、リニアI/O速度（MB/秒）が重要な特性となります。そのため、最初のテストモードは、中程度のキュー深度（4MBブロック）で16～32回のオペレーションを実行するリニア読み取り/書き込みです。テスト結果はMB/秒で表されます。
• これは、ランダムな小さなブロックアクセスを使用し、並列処理をサポートするアプリケーション向けです。そのためには、キュー深度が128以上の4KBランダムI/Oパターンを使用する必要があります。4KBは、ほとんどのファイルシステムおよびDBMSの標準ブロックサイズです。テスト中に単一のスレッドでドライブを飽和させられない場合は、複数（2、4、または8）のCPUスレッドを使用する必要があります。テスト結果にはIOPS（1秒あたりのI/O操作数）が含まれますが、レイテンシは含まれません。このテストでは、レイテンシは意味を持ちません。なぜなら、キュー深度を増やすことでレイテンシは任意に増加する可能性があるからです。レイテンシはIOPSと直接関連しており、レイテンシ = キュー/IOPSという式で表されます。
• * ランダムな小さなブロックアクセスを使用し、並列処理をサポートしないアプリケーション。このようなアプリケーションは想像以上に多く存在します。書き込みに関しては、すべてのトランザクション型DBMSが顕著な例です。そのため、キュー深度1で4KBのランダムI/Oテストを実施し、書き込みについては、ディスクまたはストレージシステムが揮発性キャッシュにデータを書き込むという「不正行為」を防ぐため、各操作後にfsyncを実行しました。結果にはIOPSまたはレイテンシのいずれかが含まれますが、両方が含まれることはありません。前述のとおり、これらは互いに直接関連しているためです。

この情報に基づいて、この記事では、各テストを実行し、取得したデータを収集して解析するためのスクリプト (https://gist.github.com/kvaps/e36b82826fb8e36d0362c7f4033948d0) を提供します。

以下のグラフはすべて、上記の8つのテストに基づいています。各テストは1分間のみ実行されました。もちろん、この時間ではすべてのニュアンスを徹底的に検討するには不十分ですが、さまざまなソリューションを大まかに比較するには十分な時間です。

I. 「生の」NVMeパフォーマンスのテスト

あらゆるベンチマーク テストは、基礎となるディスク自体のテストから開始する必要があります。

これは、パフォーマンスがどれだけ低下したかを確認するための出発点です。

テスト結果によると、使用したディスクのパフォーマンス特性が異なっていたことがわかります。これは (おそらく) ディスクの経年劣化によるものです。

II. バックエンドテストのオーバーヘッド

NVMe自体のパフォーマンスデータを取得できたので、次に各バックエンドのパフォーマンスを測定する必要があります。ご存知のとおり、DRBDはパーティション化されていないRAWディスクを含む、あらゆるブロックデバイスで動作します。

しかし、DRBD9のリリース以降、仮想マシンまたはコンテナごとに専用アプライアンスを使用するという考え方が増えています。これは、システム障害の影響を軽減し、スケールアウトを容易にするのに役立つためです。論理ボリュームマネージャーを使用すると、適切なサイズの新しいボリュームを一括で簡単に準備できます。さらに、ライブリサイズ、スナップショット、重複排除など、さまざまな新機能もサポートしています。

LINSTOR ( https://linbit.com/linstor/ ) は、LVM、LVMTHin、ZFS など、様々なバックエンドをサポートしています。以下ではこれらをテストします。テストでは、利用可能な最速のディスク (ノード 3) を使用してパフォーマンスを測定しました。結果は次のとおりです。

上記のように、LVM や ZFS と比較すると、従来の LVM にはオーバーヘッドはほとんどありませんが、サポートされる機能は少なくなります。

スナップショットを作成する場合は、Copy-on-Write (https://en.wikipedia.org/wiki/Copy-on-write) をサポートしており、パフォーマンスに影響を与えずにスナップショットを作成できる LVMThin または ZFS を使用する必要があります。

LVMThinはシーケンシャルな読み書き操作では良好なパフォーマンスを発揮しますが、ランダムな読み書き操作では多くの欠点があります。ボリューム全体にゼロパディング（つまりディスク領域を事前割り当て）を施し、「raw」ディスクの半分のパフォーマンスを実現できれば、パフォーマンスはさらに向上するでしょう。

ZFSのパフォーマンスは著しく低下しました。ブロックサイズを調整してみましたが、残念ながら結果にはほとんど影響がありませんでした（ブロックサイズは512、4K、32K、512Kでテストしました。デフォルトは8Kでした）。ブロックサイズを小さくするとパフォーマンスはわずかに向上しましたが、レイテンシも大幅に増加しました。ブロックサイズを大きくするとシーケンシャルリード/ライト速度は向上しましたが、これは私たちの目標ではありませんでした。

そこで、ZFSを脇に置いて、LVMThinで同じことを試してみることにしました。その後、ブロックサイズを変更してもテスト結果にほとんど影響はありませんでした。

最終的に、デフォルトの LVM または LVMThin のいずれかを選択しました。

LINSTORはLUKS暗号化ボリュームを使用できますが、この暗号化によるパフォーマンスコストについて興味がありました。LUKSへの影響は最小限であることがわかりました。ランダムな読み取り/書き込みやシーケンシャルな操作を時々行う場合、パフォーマンスはほぼ変わりませんが、ランダムな操作を連続して行う場合、パフォーマンスは半分しか低下しません。グラフで確認できます。

III. DRBDオーバーヘッドのテスト

バックエンドが確定した後、DRBDレプリケーションのオーバーヘッドの調査を開始しました。利用可能なバックエンドはそれぞれテストしましたが、ここではLVMを主な例としてのみ使用します。

DRBD ベンチマークには、レプリカ 1 つ (純粋な DRBD オーバーヘッド)、ローカル レプリカ 2 つ、リモート ディスクレス クライアントを持つレプリカ 2 つという 3 つの構成を使用します。

結果は次のとおりです。

この図は、DRBD によってランダム読み取り/書き込み速度が大幅に低下し、順次操作のオーバーヘッドがほとんどなくなることを示しています。

2 つのレプリカを有効にすると、並列処理のないテストでは操作速度がわずかに低下し、待ち時間が増加します。

しかし、これは理にかなっています。2 つのコピーに同時に書き込み、各コピーが操作を完了するまで待機します。

ディスクレス クライアントの場合、両方のコピーがリモート サーバー上にあるため、クライアントはそれらに接続する必要があり、その結果、速度が低下し、待ち時間が増加します。

この時点で、次のような結論を導き出すことができます。

• コピーが 2 つあり、そのうちの 1 つがローカルである場合、パフォーマンスは「生の」デバイスと比較して 3 分の 1 に低下し、レイテンシは 2 倍になります (これは実際には CPU のオーバーヘッドによるものです)。
• 2 つのレプリカとリモート ディスクレス クライアントを使用すると、パフォーマンスは 4 倍以上低下し、レイテンシは 2 倍になりました。

DRBD の調整は最終結果にほとんど影響を与えなかったため、その後のテストでは使用されませんでした。

IV. 他のクラスタファイルシステムとの比較

過度のパフォーマンス低下につながる要因は数多くあると思われるため、この時点でDRBDを他のソリューションと比較することにしました。比較対象となるソリューションは、Ceph RBD、Mayastor、そして実験的なストレージであるVitastorの3つです。

公平を期すために、Mayastor 以外の多くのクラスター ファイル システムと同様に、COW とスナップショットの作成をサポートする、より低速のバックエンド LVMThin を使用することにしました。

私が受け取ったものは次のとおりです:

その結果は私を驚かせた。

ランダム書き込み操作では、ローカル Mayastor が 1 位、Vitastor が 2 位、続いてローカル DRBD、Ceph、ディスクレス DRBD となっています。

ローカル DRBD は読み取りテストで最高のパフォーマンスを発揮し、良好な結果と最低のレイテンシを実現しました。

V. ギガビットネットワークベンチマークテスト

また、各ソリューションがギガビット ネットワーク上でどのように動作するかも知りたいです。

上記のように、4つのソリューションはすべてギガビットイーサネットチャネルを完璧に活用しました。しかし、結果にはまだ多くの欠点があります。Mayastorは他のソリューションよりもわずかに優れたパフォーマンスを示しました。DRBDは読み取り速度は優れていましたが、書き込み速度は依然として低速でした。

VI. ストレステスト

さて、いよいよ最も重要な部分、ストレステストです。前述のテストはストレージ容量を把握するために設計されています。この部分では、実際の負荷をシミュレートし、各ソリューションがどのように対応するかを確認します。

75% のランダム読み取りと 25% のランダム書き込みを含む標準の r/w テストを使用し、その複数のコピーを実行します。

 fio -名前= test -ファイル名=/ dev / xvda - ioengine = libaio - direct = 1 - rw = randrw - rwmixread = 75 - bs = 4 k - numjobs = 1 - iodepth = 64 -サイズ= 4 G

15 分間の制限時間を設定し、その時間内に完了したテストの数を確認して、全体的な統計をまとめます。

LINSTORとMayastは、 volumeBindingMode: WaitForFirstConsumerの設定を推奨しているため、他のソリューションよりも優れています。これにより、最終的にPodが配置されるノードと同じノードにボリュームが構成されます。類似の環境でソリューションを比較するため、この機能を無効にすることにしました。

Ceph は、ドライブごとに 2 つの OSD を実行し、さらに pg (512) を設定するようにも構成されています。

最後の2つのグラフはノード上のリソース消費量の合計を示していますが、この情報は客観的な情報とは言い難いため、鵜呑みにしないでください。より詳細な分析については、Grafanaのグラフを参照することをお勧めします。

Grafna の対応するチャートは次のとおりです。

• LINSTOR (LVMThin): (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/linstor_lvmthin.html);
• Vitastor1: (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/vitastor1.html);
• Vitastor2: (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/vitastor2.html);
• Mayastor: (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/mayastor.html);
• Ceph: (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/ceph.html).​

LINSTOR は、クライアントの読み取りと書き込みが多数あっても、一貫して優れた結果を提供します。Vitastor もほぼ同様に優れています。

MayastorとCephが僅差で続きました。さらに、Grafanaのチャートからも明らかなように、CephはRAMとCPUリソースを大幅に多く消費しました。

ここで、Mayastor は現在 COW とスナップショットをサポートしていないことを指摘する必要があります。そのため、LVM バックエンドを持つ LINSTOR と安全に比較できます。

最後の2つのグラフはノード上のリソース消費量の合計を示していますが、この情報は客観的な情報とは言い難いため、鵜呑みにしないでください。より詳細な分析については、Grafanaのグラフを参照することをお勧めします。

Grafna の対応するチャートは次のとおりです。

• LINSTOR (LVMThin) : (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/linstor_lvmthin.html);
• Vitastor1: (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/vitastor1.html);
• Vitastor2: (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/vitastor2.html);
• Mayastor: (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/mayastor.html);
• Ceph: (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/ceph.html).​

LINSTOR は、クライアントの読み取りと書き込みが多数あっても、一貫して優れた結果を提供します。Vitastor もほぼ同様に優れています。

MayastorとCephが僅差で続きました。さらに、Grafanaのチャートからも明らかなように、CephはRAMとCPUリソースを大幅に多く消費しました。

ここで、Mayastor は現在 COW とスナップショットをサポートしていないことを指摘する必要があります。そのため、LVM バックエンドを持つ LINSTOR と安全に比較できます。

Grafana グラフ:

• Mayastor : (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/mayastor.html);
• Linstor (LVM): (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/linstor_lvm.html)。

LINSTORの24台のローカルクライアントを使ったテストの結果はやや奇妙でした。クラスタが他の処理でビジー状態だった可能性があります。しかし、全体的な傾向は明らかです。LINSTOR + LVM構成はMayastorよりも大幅に優れています。Mayastorの利点は、平均CPU負荷が低いことにあります。

一方、`volumeBindingMode: WaitForFirstConsumer` を有効にして、テスト結果がどの程度変化するかを確認することもできます。このモードでは、少なくとも1つのレプリカがローカル、つまりポッドと同じ場所で実行されることに注意してください。

Grafna グラフ:

• Mayastor (ローカル): (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/mayastor_local.html);
• LINSTOR (LVM ローカル): (https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/linstor_lvm_local.html).​

簡単な要約

ベンチマーク結果と現在の構成情報に基づくと、次のようになります。

• LINSTOR は最速のストレージ ソリューションの 1 つです。
• Vitastorもすぐ後に続き、後者は（Cephに似たアーキテクチャを持つため）有望視されていました。例えば、これにより単一のブロックデバイスの負荷をすべてのクラスタノードに分散することが可能になります。
• Mayastorもパフォーマンスは良好ですが、現時点では機能が限られています。クライアント数が多い場合は、同等の構成のLINSTORの方が高速です。
• Ceph は大量のハードウェアリソースを消費するため、ボトルネックとなることがよくあります。現在、開発者は新しいCrimson (https://www.youtube.com/watch?v=YxbT5MneEL0) バックエンドの開発に取り組んでおり、リリース時には改善されることを期待しています。

私たちのケースでは、最も成熟した本番環境対応ソリューションとして LINSTOR が選択されました。