【技術深掘り】ZFSストレージ拡張の「真実」と、後悔しないための運用術(前編)

はじめに

QNAPのQuTS heroなどでおなじみのZFS。「容量が足りなくなったらRAIDグループ（VDEV）を追加すればOK」と簡単に言われますが、その裏側の挙動を正しく理解できていますか？

「RAID50などでストレージプールの容量を増やした場合にどういう動きになるの？」「そもそもストレージプールでは、RAID0のような分散処理なのか、JBODのような順番書き込みかどちら？」といった現場の疑問を解消するための、一歩踏み込んだ質問に回答できるよう独自に調査してみました。

※今回の話はQNAP QuTS heroの実装とは関係ありません。単純な技術的な深堀がメインです。

※深堀に際してAIに協力してもらっていますが、私の視点からも「挙動や設計思想からみても正しかろう」と判断した内容を載せているつもりです。

1. 「動的ストライピング」：ZFSは単純なRAID 50ではない

ZFSで複数のRAIDZグループを束ねたプール（いわゆるRAID 50相当）を運用する場合、データの書き込みは「動的ストライピング」という高度なアルゴリズムで制御されています。

容量ベースの重み付け: ZFSは各グループの空き容量を常に監視しています。

賢い書き込み先選択: 空き容量が多い（新しい）グループに対して、より多くのデータブロックを優先的に割り当てることで、最終的にプール全体の充填率を均等にしようと動きます。

パフォーマンスの最大化: これにより、既存の混雑したディスクの負荷を抑えつつ、新しいディスクのシーケンシャル性能を最大限に活用できる設計になっています。

2. 「データの不変性」がもたらす注意点

ここで多くの方が直面するのが、「古いデータが新しいディスクに移ってくれない」という問題です。これにはZFSの「Copy-on-Write（CoW）」という設計思想が深く関わっています。

一度書いたら動かない: ZFSでは、一度ディスクに書き込まれたブロックは、そのファイルが更新・削除されない限り、物理的な場所が固定されます。

自動リバランスは存在しない: 一般的なRAIDのように、ディスク追加後に既存データを全ディスクへ自動的に「並べ直す」機能は標準では走りません。

読み込みの偏り: そのため、古いファイルの読み込みは「古いディスクセット」からしか行われず、プール全体のIOPS性能を完全には享受できない期間が生じます。

3. プロが実践する「事後最適化」の切り札

では、どうすれば全ディスクの性能をフルに引き出せるのか？最新のOpenZFSでは、画期的な解決策が登場しています。

RAIDZ Expansion: 既存のRAIDグループにディスクを「1本ずつ」追加し、パリティ構成を再定義できるようになりました。

zfs rewrite コマンド: 「論理的な再配置」を可能にする強力なツールです。

ファイルを物理的に別の場所（全ディスクへ均等に分散された場所）へ書き直します。

ユーザーからはファイルが移動したようには見えませんが、バックグラウンドで読み込みIOPSを全ディスクに分散させることが可能です。

運用のヒント

もし、大規模な拡張を行った後にパフォーマンスを最適化したい場合は、スナップショットの保持期間を確認した上で、重要データの zfs send/receive や rewrite を検討してみてください。※スナップショットがある場合は、旧ブロックが保存され続けるので、スナップショットが消されるまで、スナップショットの2～3倍の容量が必要となってしまう場合があるようです。