はじめに
ZFSの学習メモです。初学者向けです。
PROXMOX等で使い始めたので、再学習しました。
後述の Oracle/Fujitsu のリンクより学習しています。
ZFSとは
- ZFSは高機能なファイルシステム兼ボリュームマネージャで、Sun Microsystemsが開発しました。
- データの整合性保証、スナップショット、重複排除など多数の機能を持ち、高信頼性と柔軟性を提供します。
- RAID機能を内蔵し、エラーの自己修復やプール単位の管理が可能です。
ZFS のメリットとデメリット
ZFS のメリット
| 項目 |
説明 |
| データ整合性の保証 |
書き込み時にチェックサムを計算し、読み出し時に整合性を検証・修復可能。Silent data corruption（静かなデータ破損）を防止。 |
| スナップショット・クローン |
スナップショット（読み取り専用）とクローン（書き込み可能）を高速かつ省容量で作成可能。 |
| 統合されたRAID機能 |
RAID-ZによってRAID5/6のような冗長性を提供し、write hole問題も回避。 |
| ARCキャッシュによる高速アクセス |
メモリ上にデータをキャッシュし、高速な読み出し性能を実現。 |
| スケーラビリティ |
数ペタバイト規模のデータにも対応でき、大規模ストレージに強い。 |
| プールによる柔軟なディスク管理 |
複数の物理ディスクを1つの「zpool」にまとめて一元管理可能。 |
| 圧縮・重複排除（dedup） |
データ圧縮や同一データの排除により、ディスク容量の節約が可能。 |
ZFSのデメリット
| 項目 |
説明 |
| メモリ使用量が多い |
パフォーマンスを最大限に引き出すには、最低でも8GB以上のRAMが推奨される。 |
| 動的にRAID構成を変更できない |
例えば、RAIDZ1にあとからディスクを1本だけ追加することはできない（新しいvdevとして追加は可能）。 |
| 重複排除の負荷が高い |
Dedup機能は大量のメモリとCPUリソースを消費しやすく、用途によっては逆効果。 |
| 導入難易度がやや高め |
初学者には操作や管理が複雑に感じられる場合がある。特にzpoolやzfsコマンドの理解が必要。 |
| 非公式なLinux対応（OpenZFS） |
LinuxではOpenZFSとして提供されており、カーネル統合が難しくトラブル対応時に注意が必要。 |
ZFS の使用例
ZFSではディスクを「プール（zpool）」としてまとめ、その上にファイルシステム（zfs）を作ります。
1. プールの作成（例：RAID-Z構成）
sudo zpool create tank raidz /dev/sd[bcd]
-
tank: プールの名前
-
raidz: RAID5相当の冗長性
-
/dev/sdb, /dev/sdc, /dev/sdd: 対象のディスク
2. ファイルシステムの作成
sudo zfs create tank/data
-
tank/data: tankプール内のZFSファイルシステム
- 自動で
/tank/data にマウントされる（Linuxでは /tank/data）
3. スナップショットの作成とロールバック
# スナップショットの作成
sudo zfs snapshot tank/data@snap1
# ファイルをいじったあと、スナップショットに戻す
sudo zfs rollback tank/data@snap1
4. 圧縮の有効化
sudo zfs set compression=on tank/data
- ファイルを書き込むと自動で圧縮され、容量節約が可能
5. スペースの確認・管理
zfs list
zpool status
zpool list
-
zfs list: ZFSファイルシステムの使用状況
-
zpool status: プールの健全性チェック
-
zpool list: プールの使用量など概要
6. データ整合性の確認（scrub）
- 全データを読み出してチェックサムで検証
- 問題があれば自動修復（冗長性がある場合）
ZFS を導入するにあたってのポイント
ZFSを導入・設計する際には、初期構成を慎重に決めることが非常に重要です。あとから柔軟に構成変更できない点もあるため、以下のポイントを参考に設計します。
1. 用途に合ったRAIDレベルを選ぶ
| RAIDレベル |
最小台数 |
特徴 |
向いている用途 |
mirror |
2台〜 |
RAID1相当。高速＆シンプル |
重要データ、仮想マシン |
raidz1 |
3台〜 |
RAID5相当、1台故障までOK |
バックアップや低コスト構成 |
raidz2 |
4台〜 |
RAID6相当、2台まで冗長 |
アーカイブ、大容量安全設計 |
raidz3 |
5台〜 |
3台まで冗長性あり |
ミッションクリティカル用途 |
RAIDZはあとからHDDを1本だけ追加できないため、余裕を持った構成がよい
2. vdev（仮想デバイス）の組み合わせを意識する
- ZFSではストレージ構成は「複数のvdevの集合体（pool）」として扱われる。
- vdev単位での性能と冗長性が決まり、プール全体の性能は最も遅いvdevに依存する。
- 性能を求める場合は「複数のmirror vdev」を使うのが有効（RAID10風の構成）。
3. ECCメモリの使用を推奨
- ZFSはデータ整合性に非常に厳格で、誤ったメモリビットによる破損も検知できるが、
メモリ自体が壊れていた場合は「破損したまま整合性が取れてしまう」ことがある。
- そのため、本番運用ではECCメモリ付きのマシンが推奨される。
4. RAMは多めに確保（最低8GB、理想は16GB以上）
- ZFSはキャッシュ（ARC）を活用して性能を引き出す。
- 圧縮・スナップショット・scrub・dedupなどの高度な機能を使うならRAMは多いほど有利。
5. スナップショットの設計
- スナップショットは低コストでバックアップのように使える。
- ただし削除しないとどんどん容量を食うため、自動削除ポリシー（cron +
zfs destroy）の設計が重要。
6. パーティショニングを使わず、ディスク全体を使うのが原則
- 例外もあるが、ZFSは物理ディスクを丸ごと使うことで最大パフォーマンスを発揮。
- 変則的なパーティション分割は将来のトラブル原因になることも。
7. ZIL/SLOGとL2ARCの設計
| 用語 |
説明 |
推奨される場合 |
| ZIL/SLOG |
同期書き込みログ（ZFS Intent Log）を高速SSDに退避 |
DBなどsync writeが多い場合 |
| L2ARC |
セカンドレベルキャッシュ。読み込みキャッシュをSSDに保存 |
大容量データで頻繁に読み込みが発生する場合 |
8. バックアップ戦略は別途用意
- ZFS自体は堅牢だが「rm -rf」やウイルスによるデータ削除までは防げない。
- スナップショット + 別サーバへの
zfs send | zfs recvでオフサイトバックアップを構築するのが理想。
ZFS でよく使うコマンド
ZFSでよく使うコマンドは大きく分けて2種類に分類されます。
zpool（ZFSプール管理）コマンド一覧
| コマンド |
概要 |
zpool create |
プールの作成 |
zpool destroy |
プールの削除 |
zpool import |
既存のプールをインポート |
zpool export |
プールのエクスポート（アンマウント） |
zpool status |
プールの状態確認（エラー・リビルド進行状況など） |
zpool list |
プールの一覧と使用量表示 |
zpool iostat |
I/Oパフォーマンスの表示 |
zpool scrub |
データ整合性チェック（スクラブ）を開始 |
zpool clear |
エラー状態のクリア |
zpool add |
プールにデバイスを追加（vdev単位） |
zpool remove |
一部のvdevやデバイスをプールから削除（※限定機能） |
zpool replace |
故障したデバイスを交換 |
zpool offline / zpool online
|
デバイスを一時的にオフライン/オンラインにする |
zpool upgrade |
プールのフォーマットバージョンをアップグレード |
zfs（ファイルシステム管理）コマンド一覧
| コマンド |
概要 |
zfs create |
ファイルシステムの作成 |
zfs destroy |
ファイルシステムやスナップショットの削除 |
zfs list |
ファイルシステムの使用量・プロパティ表示 |
zfs set |
プロパティの設定（例：圧縮、マウントポイント） |
zfs get |
現在のプロパティの取得 |
zfs snapshot |
スナップショットの作成 |
zfs rollback |
スナップショットに巻き戻す |
zfs clone |
スナップショットからクローンの作成 |
zfs send |
スナップショットをバイナリで出力（バックアップ用） |
zfs receive（recv） |
sendされたデータを受信（レストア） |
zfs rename |
ファイルシステムやスナップショットの名前変更 |
zfs promote |
クローンを独立ファイルシステムに昇格 |
zfs mount / zfs unmount
|
手動でマウント／アンマウント |
よく使う組み合わせ例
# プール作成
zpool create tank mirror /dev/sdb /dev/sdc
# 圧縮付きファイルシステム作成
zfs create -o compression=on tank/data
# スナップショット作成と復元
zfs snapshot tank/data@snap1
zfs rollback tank/data@snap1
# バックアップ送信
zfs send tank/data@snap1 > backup.zfs
# バックアップ受信
zfs receive tank/restore < backup.zfs
運用のポイント
ZFSの運用時には、堅牢な設計とはいえ注意すべきポイントがいくつかあります。
1. データ消失・破損を防ぐための注意
| 項目 |
説明 |
| ECCメモリの使用 |
ZFSはデータ整合性を保証しますが、非ECCメモリでは逆に整合性のある“誤ったデータ”を保持するリスクがあります。 |
定期的なscrubの実行 |
zpool scrubを月1回程度実行し、サイレントデータ破損を検知・修復します。 |
| スナップショットの運用管理 |
多数のスナップショットを放置すると容量を食います。定期的に古いものは削除する仕組みを整えましょう。 |
| バックアップは別途確保 |
ZFSは高信頼でも、「rm -rf」やランサムウェアには無力です。zfs send + zfs recvでオフサイト/他ノードにバックアップを推奨。 |
2. 運用時のパフォーマンス・容量に関する注意
| 項目 |
説明 |
| 空き容量の維持（推奨80%以上使用しない） |
ZFSは空き容量が少ないとパフォーマンスが大きく低下します。使用率は70〜80%程度に留めるよう意識します。 |
| ARCキャッシュのメモリ消費に注意 |
ZFSはメモリを多く使うため、アプリケーションと競合しないように調整 (zfs_arc_max) が必要な場合があります。 |
| dedupは原則使わない |
重複排除はRAMを大量消費し、誤って使うと性能が著しく低下することがあります（検証の上で使用判断）。 |
3. 障害時の対応・運用整備
| 項目 |
説明 |
| ディスクのシリアル番号を記録しておく |
zpool status -vでエラーが出たとき、物理ディスクの特定に役立ちます。 |
| zpool statusを監視 |
zpool statusに出るDEGRADEDやFAULTEDをcronやZabbix等で監視するのがおすすめ。 |
| RAID-Zの特性理解 |
例：RAIDZ1で1台故障時にscrubではなくreplaceを適切に行うこと。操作ミスでプール崩壊する恐れも。 |
| 電源断対策 |
書き込み中に停電するとSLOG（同期書き込み）に依存するワークロードでデータ損失リスクが高くなるため、UPSの導入が理想的です。 |
4. 監視・ログ・通知の仕組み
| 項目 |
説明 |
zpool statusのログを毎日取得 |
zpool statusの結果をログに記録し、異常が出たら通知。 |
zpool listやzfs listで容量監視 |
容量しきい値超過時のアラートを設定。 |
| エラー発生時にメール通知 |
smartd, systemd, cronなどでZFS状態に応じた通知を構成。 |
5. アップグレードと互換性管理
| 項目 |
説明 |
| OSアップデート時のZFS互換性確認 |
OpenZFSのカーネルモジュールはOSバージョン依存。事前検証を行うこと。 |
| zpool upgradeは慎重に |
一度アップグレードすると古いバージョンのZFSでは読み込めない。アップグレード前にバックアップ必須。 |
ZFS の障害時
ZFSの障害時対応については、エラーの検出 → 状況確認 → 適切な修復の3段階で考えるのが基本です。
よくある障害の種類と状態
| 状態名 |
意味 |
対応概要 |
ONLINE |
正常稼働中 |
問題なし |
DEGRADED |
冗長構成の一部に障害 |
冗長性が失われているが稼働継続中、修復が必要
|
FAULTED |
デバイスが致命的に故障 |
ZFSが完全に読み書きできない状態、早急な交換が必要 |
UNAVAIL |
プールにアクセス不可 |
zpool自体が認識不能、復旧困難な場合あり |
REMOVED |
デバイスが物理的に外された |
意図的でなければ再接続・import再試行
|
OFFLINE |
管理者が手動で無効化 |
zpool onlineで再有効化できる |
基本対応フロー
1. 状況の確認
出力結果から、障害の発生しているディスク名・エラー内容・状態を確認します。
2. ディスク障害時の復旧例（RAID構成前提）
ケース：DEGRADED + デバイス交換
# 交換用ディスクの確認（新しいディスクにパーティション不要）
lsblk
# 故障ディスクをオフラインにする（例：/dev/sdb）
sudo zpool offline tank /dev/sdb
# ディスク物理交換後、再構成を開始
sudo zpool replace tank /dev/sdb /dev/sdX # 新しいディスク名に置き換え
# 状態確認（リビルド進行中）
zpool status
3. スクラブを使ってデータ整合性の確認・修復
- 定期実行（週1または月1推奨）
- エラーがあるブロックは他の冗長データから自動修復
scrub後のエラー発見時の対応例
-
errors: Permanent errors have been detected in the following files:
と表示された場合、そのファイルは完全には修復されていないことを意味します。
- バックアップからの復元が必要になるケースがあります。
修復できない場合の対応（緊急）
| 状況 |
対応策 |
| プールがimportできない |
zpool import -f や zpool import -m（mountなし）など試す |
| デバイス名が変わって復旧できない |
zpool import -d /dev/disk/by-idで明示的に指定 |
| プール全体がUNAVAIL |
バックアップからの復元を前提に再構築が必要なことも |
障害通知・検知
| 方法 |
説明 |
zpool statusを定期実行 |
cronでログ保存 or メール送信 |
smartdとの連携 |
SMART障害検知での早期対処が可能 |
zed（ZFS Event Daemon） |
イベント発生時に自動通知スクリプトを実行できる（zpool scrub終了通知なども可能） |
リンク
さいごに
ZFSをつかっていきたい
