RAIDZの幅はAIワークロードのランダム読み取りレイテンシにどのような影響を与えるか？

RAIDZの幅を広げると容量効率やシーケンシャル帯域幅は向上しますが、小さなランダム読み取りのレイテンシは通常、vdevの動作、ブロックレイアウト、キューイングによって制約されます。

家庭用AIワークロードでは、大きなモデルファイルに加えて、小さなメタデータ、ベクトルインデックスのページ、サムネイル、データベース読み取りが混在することがよくあります。1つのRAIDZ vdevにディスクを追加すると、各ストライプで利用できるデータ列が増えますが、1つの小さなブロックではすべての列を使わない場合があり、1つのvdevは依然として1つのスケジューリング領域として機能します。幅の広いレイアウトでは、複数のサービスが同時にランダムリクエストを発行すると、縮退モードでの処理量とテールレイテンシが増加することもあります。

幅が変えるのはデータ列であり、vdev数ではない

RAIDZは、1つの仮想デバイス内で複数のディスクにデータとパリティを分散します。幅の広いvdevでは、パリティディスクあたりの使用可能容量が増え、大きなレコードでより高い合計帯域幅を提供できます。しかし、プールは各ディスクを独立したランダム読み取り対象として扱うのではなく、vdev間でトップレベルのI/Oを分散します。

OpenZFSのRAIDZレイアウトのドキュメントでは、小さなブロックのワークロードに関する推奨事項を含め、RAIDZとdRAIDのレイアウト概念を説明しています。このモデルから、データRAIDZグループの幅を単に広げるよりも、ミラー構成のspecial vdevを追加するほうがメタデータに大きな効果をもたらす場合がある理由が分かります。

ブロックサイズ、圧縮、recordsize、アライメントによって、読み取りがアクセスする列の数が決まります。小さな圧縮ブロックは、大きなモデルファイルの読み取りよりも少ないセクターやディスクを使用する場合があるため、幅が1つのレイテンシ結果を決めるわけではありません。

ランダム読み取りはIOPSとキュー分散に左右される

大きなシーケンシャルリクエストは複数のディスクにまたがって並列処理できますが、独立した小さな読み取りは、vdevが各リクエストをどのようにスケジュールし完了させるかによって制限されます。複数の狭いvdevを構成すると、トップレベルのI/O対象は増えますが、より多くのパリティディスクを消費し、障害ドメインも変わります。

あるエンジニアリングランダム読み取り動作の分析では、RAIDZレイアウト全体でランダム読み取り動作を測定し、同じドライブをより多くのvdevに分割した場合、ストライプ幅を小さくすることでプールのIOPSが向上する理由を示しています。これはトポロジーによる効果であり、ディスク速度に関する普遍的な法則ではありません。

ARCキャッシュにヒットした読み取りはディスクを経由せず、メタデータまたはspecial vdevによって、選択した小さなブロックをより高速なメディアへ移動できます。RAM内に完全に収まるベンチマークでは、RAIDZの幅に起因するオンディスクレイテンシの差を明らかにできません。

幅の広いグループでは復旧処理とテールリスクの結び付きが強まる

スクラブ、リシルバー、またはディスク欠落時には、読み取りで残存する列からの再構築が必要になる場合があります。幅の広いグループでは、各vdevの縮退ワークロードにさらされるディスクが増え、AIクエリが復旧I/Oと競合する期間が長引く可能性があります。

ZFSエンジニアリングによるvdevトポロジーの概要では、ミラーとRAIDZ vdevの特性を比較し、プールの性能がvdevトポロジーに従うことを説明しています。ドライブ数のベンチマークを解釈する前に必要となる、アーキテクチャ上の違いを示しています。この効果は、想定するホームサーバーのワークロードで測定可能な状態にしておく必要があります。

シーケンシャルスループットテストの結果を、ベクトル検索や写真メタデータに外挿することには限界があります。キャッシュされた読み取り、小さなブロック、キュー深度、recordsize、縮退状態によって、幅の広いグループの見かけ上の優位性が逆転することがあります。複数のパイプライン段階が同じストレージとメモリ予算を共有する場合、この違いが重要になります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ローカルAI向けRAIDZ幅に関するFAQ

幅の広いRAIDZ vdevは、ランダム読み取りで常に遅くなりますか？

いいえ。結果は、ブロックサイズ、キャッシュヒット、圧縮、ディスク、キュー深度、プールトポロジーによって異なります。一般的な懸念は、vdevをもう1つ追加する場合と同じように、幅の広い1つのvdevでは独立したトップレベルIOPSが増えないことです。

ベクトルデータベースでは、ミラーが常に優れていますか？

ミラーは、小規模なランダムIOPSが高く、復旧動作も単純になることが多い一方、未加工容量をより多く消費します。判断では、レイテンシだけでなく、耐久性、使用可能容量、バックアップ設計、測定したデータベースワークロードも考慮する必要があります。この点は、想定で済ませるのではなく、代表的な家庭内データで検証しなければなりません。

special vdevでRAIDZのメタデータレイテンシを改善できますか？

冗長構成のspecial vdevにはメタデータや、任意で小さなブロックを保持でき、データRAIDZへの負荷を軽減できます。special vdevはプールにとって重要なインフラになるため、これを失うとプールを失う可能性があり、冗長性はリスクに見合うものにする必要があります。

コールド状態と縮退状態の読み取りで幅をベンチマークする

ベクトルページ、SQLiteまたはメタデータ、サムネイル、モデルファイルの代表的な読み取りを、管理されたブロックサイズとキュー深度で再現します。候補となるトポロジー全体で、p50、p95、p99レイテンシ、IOPS、ARCヒット率、ディスク使用率、スクラブまたはリシルバーによる干渉を測定します。

モデルへのリモートアクセスを、リモートモデルアクセスにおけるネットワーク制約と関連付けます。総ディスク数、ドライブモデル、recordsize、圧縮、データセット、キャッシュ状態、空き容量を固定し、繰り返し行うホット読み取りだけでなく、コールドキャッシュ条件でもテストします。

トポロジーは、レイテンシ目標、使用可能容量、冗長性、復旧動作を総合して選択します。ランダムなAI I/Oが重要な場合は、列を追加すれば同等のIOPSが得られると考えるのではなく、複数のvdevまたは冗長構成のspecial tierを、幅の広い1つのRAIDZと比較してください。