OpenZFS RAID-Z拡張機能で既存プールにvdevを追加する｜本番投入前の性能検証と安全手順

ZFSプールの容量不足は、ストレージ運用の現場で避けにくい課題です。従来のZFSではRAID-ZのvdevはStorage pool作成後に変更できず、ディスクを追加するには新しいvdevをプールに加えるしかありませんでした。OpenZFS 2.2で追加されたRAID-Z拡張機能（RAIDZ Expansion）は、この制約を緩和し、稼働中のRAID-ZのvdevにHDD/SSDを1台ずつ追加して容量を拡張できるようにします。本記事では、この機能の仕組みと、本番環境に投入する前の性能検証手順・安全な操作ステップ・注意事項を整理します。

RAID-Z拡張機能の背景と動作の仕組み

RAID-Z（raidz1 / raidz2 / raidz3）は、ZFSの書き込み時にデータとパリティを連続したストライプとして記録します。この設計により高いI/O効率を得られる一方、ストライプ幅（vdevを構成するディスク数）はプール作成後に固定されていました。ストライプ幅が変わると、既存データのすべてのブロックを新しいレイアウトに書き直す必要があるためです。

OpenZFS 2.2で導入されたRAIDZ Expansionは、この制約を乗り越えます。新しいディスクをvdevにアタッチすると、バックグラウンドで”reflow”処理が開始されます。reflow処理はプールをオフラインにせず、既存データを新しいストライプ幅に合わせて少しずつ書き直していきます。処理中もプールは読み書き可能な状態を維持します。ただし、拡張できるのは1台ずつであり、パリティレベルはそのまま維持されます（raidz1をraidz2に昇格させるといった変更はできません）。

なお、既存プールに「新しいvdevを丸ごと追加する」操作（zpool add）とは別物です。zpool addは既存のvdevには手を加えず、プールに独立した新しいvdevを増設します。RAIDZ Expansionは既存のRAID-Z vdevの幅を広げる点で動作が異なります。

本番投入前の環境要件と事前確認

RAIDZ Expansionを使う前に、以下の要件を満たしているか確認します。

OpenZFSのバージョン確認

RAIDZ Expansionが利用できるのはOpenZFS 2.2以降です。バージョンは次のコマンドで確認します。

zfs version

2026年時点では、Ubuntu 24.04 LTS（noble）が標準でOpenZFS 2.2系を採用しており、追加設定なしで利用できます。Ubuntu 22.04 LTSは2.1系にとどまる場合があるため、backportsリポジトリや手動ビルドでの更新が必要です。Debian 12（bookworm）はcontribリポジトリにzfsutils-linuxが含まれますが、バージョンはディストリのリリース時期に依存するため、apt show zfsutils-linuxで事前確認することを推奨します。

プールのfeatureフラグ確認

RAIDZ Expansionにはraidz_expansionフィーチャーフラグの有効化が必要です。現在の状態を確認するには次のコマンドを使います。

zpool get feature@raidz_expansion <プール名>

値がenabledまたはactiveであれば利用可能です。disabledの場合は次のコマンドで有効化できます。

zpool set feature@raidz_expansion=enabled <プール名>

フィーチャーフラグの有効化は不可逆操作です。有効化すると、同じプールをOpenZFS 2.1以前のホストにインポートできなくなります。ハードウェア移行や古いバージョンとの共存が必要な環境では、影響範囲を先に確認してください。

追加ディスクのサイズとashift

追加するディスクは、vdev内の既存ディスクと同サイズ以上である必要があります。小さいディスクを混在させることはできません。また、ashiftの不一致はパフォーマンス劣化を招くため、既存ディスクと同じセクターサイズ（4K / 512e）のモデルを選ぶことが望ましいです。

本番投入前の性能検証手順

reflow処理は大量のI/Oをバックグラウンドで実行します。本番ストレージで突然開始すると、通常業務のI/Oレイテンシが悪化する可能性があります。事前に影響度を把握しておくことが重要です。

ベースラインI/Oの測定

本番と同等の構成を持つテスト環境（または本番の非ピーク時間帯）で、拡張前後のI/O性能を比較します。fioによるランダム読み書きと、zpool iostatによるスループット／ウェイト確認を組み合わせると状況が把握しやすいです。

# ベースラインのI/O統計を継続出力（5秒間隔）
zpool iostat -v <プール名> 5

reflow処理の進捗はzpool statusで確認できます。出力中にraidz_expansion in progressのような表示と進捗パーセンテージが現れます。reflowのスピードはシステム負荷やディスクのシーケンシャル性能に依存し、数百GBのプールでも数時間～数十時間かかるケースがあります。

zpool status <プール名>

スロットリングの検討

本番環境での業務I/Oを守るため、reflow処理の帯域をスロットリングすることを検討します。zfs_rebuild_max_activeなどのzfsカーネルパラメータを調整することで、背景処理のI/O優先度を下げることができます。変更前にはカーネルモジュールのドキュメントで対象バージョンのパラメータ名を確認してください。バージョン間でパラメータ名が変わることがあるため、事前確認は省かないことを推奨します。

vdev追加の安全手順

実際の操作に入る前に、スナップショットの取得とオフサイトバックアップの確認を必ず行います。reflow処理中にディスクが故障すると、プールが縮退状態になります。バックアップなしで作業を開始しないことを強く推奨します。

追加ディスクの確認とアタッチ

追加するディスクのデバイスパスをあらかじめ特定しておきます。/dev/sdX形式の名称はリブート後に変わることがあるため、/dev/disk/by-id/以下のパスを使うことが安全です。

準備ができたら、zpool attachコマンドで既存RAIDZのvdevに新しいディスクをアタッチします。

# raidz内の既存コンポーネントデバイスを指定して新ディスクをアタッチ
zpool attach <プール名> <既存のコンポーネントデバイス> <追加デバイス>

# by-idパスを使用する例（想定例）
zpool attach tank \
  /dev/disk/by-id/ata-WDC_WD40EFRX-xxxx_AAAAAA \
  /dev/disk/by-id/ata-WDC_WD40EFRX-xxxx_BBBBBB

コマンドが受け付けられると、reflow処理がバックグラウンドで開始されます。ミラーへのzpool attachと構文は同じですが、対象がRAID-ZのvdevであればOpenZFSが自動的にRAIDZ Expansionとして処理します。

進捗モニタリングと完了確認

処理中は定期的にzpool statusを実行してエラーの有無を確認します。完了後にはスクラブを実行し、データ整合性に問題がないことを確認してから通常業務のI/Oに戻すことを推奨します。

# reflow完了後のスクラブ実行
zpool scrub <プール名>

# スクラブ結果確認
zpool status <プール名>

切り戻しと注意点

切り戻しは原則として不可

一度アタッチしてreflowが始まると、ディスクを取り外して元の構成に戻すことはできません。reflowの途中でも完了後でも同様です。これはZFSの設計上の制約であり、スナップショットのロールバックでもvdevの構成は元に戻せません。操作前に「後戻りできない」という前提でリスク評価を行ってください。

reflow中の電源断・ディスク故障

reflow処理は中断・再開をサポートしています。電源断やサーバ再起動後もプールをインポートすれば処理は再開されます。ただしreflow処理中にraidz1のプールでディスクが1台故障すると、冗長性がなくなりデータロストのリスクが生じます。raidz2 / raidz3であれば許容できるディスク故障台数の範囲内に限り、より安全に操作できます。作業期間中はディスクの健全性監視（S.M.A.R.T.の定期確認など）を通常より高い頻度で実施することを推奨します。

容量増加のタイミング

プールの実際の使用可能容量がフルに増加するのは、reflowが100%完了してからです。処理中は段階的に増えていきます。容量不足が差し迫っている状況での拡張作業は、reflow完了まで余裕がない状態が続くリスクがあります。可能であれば、プール使用率が70%を超える前に拡張作業を計画することが望ましいです。

2026年現行環境での差分と留意点

Rocky Linux / AlmaLinux 9では、ZFSモジュールをELリポジトリから提供するzfs-releaseを使う構成が標準的です。2026年時点では2.2以降が提供されていますが、カーネルアップデートとモジュールバージョンの追従に注意が必要です。カーネル更新後にDKMSのビルドが失敗すると、プールをインポートできなくなる事故につながります。dnf update前にZFSモジュールのDKMS状態を確認する運用手順を組み込んでおくことを推奨します。

TrueNAS SCALEはOpenZFSを内包しており、バージョン管理はTrueNASのリリースサイクルに依存します。RAIDZ Expansionは2024年以降のリリースで対応済みですが、UIから直接操作できるかはリリースごとに確認が必要です。CLIから操作する場合は、TrueNASが推奨するシェル操作の手順を守ることが重要です。

また、zfs-auto-snapshotなどの自動スナップショットツールを併用している環境では、reflow処理中のスナップショット取得がI/Oを増幅させる場合があります。拡張作業中は自動スナップショットの間隔を一時的に広げるか、手動管理に切り替えることも選択肢です。

RAIDZ Expansionは長年の要望に応えた大きな前進ですが、reflow処理のI/O負荷・切り戻し不可という制約はどの環境でも変わりません。バックアップと環境要件の確認を徹底したうえで、計画的に活用してください。