AlmaLinux 9 総合ガイド 第６章

2025.01.24

第6章: ファイルシステムとストレージ管理

6.1 この章で解説する主要な技術・概念

AlmaLinux9環境では、dnfによるパッケージ管理やSELinuxのセキュリティ設定を前提に、以下の技術・概念を押さえることで、ストレージ基盤の構築・運用を安全かつ効率的に進められます。

6.1.1 ディスクパーティショニング（GPT vs MBR）

AlmaLinux9／RHEL9 では、パーティションテーブルに GPT（GUID Partition Table）を用いることで、2 TiB を超える大容量ディスクを扱え、プライマリパーティションを最大128個まで設定可能です。従来の MBR（Master Boot Record）は 2 TiB 上限かつプライマリ4つまでの制約があり、UEFI ブート環境では必ず GPT を選択します。GPT では保護用 MBR（protective MBR）を先頭に配置し、基本的に 128 個のエントリを持つ主 GPT ヘッダと末尾のバックアップヘッダで信頼性を確保します (Red Hat Documentation)。

  • なぜ GPT を選ぶのか
    • 大容量ディスク対応（最大 8 ZiB）
    • パーティション数を事実上制限なし
    • UEFI 環境との親和性
  • 主な CLI ツール
# fdisk（MBR 操作向け、gdisk で GPT がベター）
sudo fdisk /dev/sda

# parted（GPT、4 KiB セクタディスク、大容量ディスクに最適）
sudo parted /dev/sda --script mklabel gpt

いずれも実行前にバックアップを推奨します (Red Hat Documentation)。

6.1.2 ファイルシステム選択（ext4, XFS）

ファイルシステム特徴
ext4ジャーナリング、互換性と安定性が高くコミュニティ情報が豊富。タイムスタンプ対応が2038年問題まで拡張（標準設定） (Red Hat Documentation)。
XFS64bit ジャーナリング、高速なアロケーショングループ、オンライン拡張対応。RHEL9 では bigtime と inobtcount をデフォルト有効 (Red Hat Documentation)。
# ext4 作成例
sudo mkfs.ext4 -L DATA_PART /dev/sdb1

# XFS 作成例
sudo mkfs.xfs /dev/sdb1
  • なぜ用途で使い分けるか
    • 安定性重視 → ext4
    • 大容量・高スループット → XFS

💡ポイント
ラベルを付与すると /etc/fstab で LABEL=DATA_PART を使ったマウント指定が可能です。

6.1.3 Stratis

Stratis は Red Hat 提供のローカルストレージ管理ソリューションで、Device Mapper と XFS を内部で利用しつつ、シンプルな CLI／API を通じてプール化・スナップショット・Thin プロビジョニングを実現します (Red Hat Documentation, stratis-storage.github.io)。

# Stratis プール作成
sudo stratis pool create pool0 /dev/sdc /dev/sdd

# Stratis ファイルシステム作成
sudo stratis filesystem create pool0 fs0
  • なぜ Stratis を使うか
    • LVM よりも易しい操作感
    • ZFS/Btrfs ライクな機能を既存スタック上で実現

6.1.4 自動マウント設定（/etc/fstab, systemd-automount）

起動時やアクセス時の自動マウントは /etc/fstab と systemd の automount ユニットで制御します。SELinux のコンテキストを設定し、セキュリティ設定を強化する点にも注意します (Red Hat Documentation, Red Hat Documentation)。

# /etc/fstab 例
UUID=abcd-1234-ef56-7890  /data  xfs  defaults,nofail,x-systemd.automount,_netdev  0  2
  • 主なオプション
    • nofail: デバイス未検出でも起動継続
    • x-systemd.automount: アクセス要求時にマウント
    • context=: SELinux ラベル設定
    • _netdev: ネットワーク依存マウント

6.1.5 LVM（PV, VG, LV, スナップショット）

LVM は物理ディスクを抽象化し、柔軟なボリューム管理を提供します。
pvcreate → vgcreate → lvcreate の流れで論理ボリュームを作成し、必要に応じてオンライン拡張・縮小やスナップショットを利用します (Red Hat Documentation)。

sudo pvcreate /dev/sdb1
sudo vgcreate vgdata /dev/sdb1
sudo lvcreate -L 50G -n lvdata vgdata

# 拡張例
sudo lvextend -L +10G /dev/vgdata/lvdata
sudo xfs_growfs /mountpoint  # XFS

💡ポイント
スナップショットは容量計画が必須です。

6.1.6 ソフトウェアRAID（mdadm）

mdadm で RAID0/1/5/6/10 などを構成し、冗長性や性能向上を図ります。RAID メタデータバージョンやチャンクサイズも指定可能です (Wikipedia)。

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
sudo mkfs.xfs /dev/md0
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf

6.1.7 ストレージ監視・メンテナンス（df, du, iostat, smartctl）

システムの健全性を保つために以下ツールで定期監視を実施します。
必要パッケージは sudo dnf install -y sysstat smartmontools で導入可能です (Tenable®, smartmontools.org)。

  • df -h / du -sh <path>: 使用量確認
  • iostat -xz 2: I/O ボトルネック検知
  • smartctl -a /dev/sda: SMART ヘルスチェック
  • smartctl -t short|long /dev/sda: テスト実行

6.2 ディスクパーティショニングの概要

AlmaLinux9環境で堅牢かつ拡張性の高いストレージ基盤を実現するには、パーティショニングの理解が不可欠です。以下では、主にGPTとMBRの比較、内部構造、アラインメントの考慮点、そしてfdisk/parted/gdiskといったCLIツールの使い分けを詳述します。

6.2.1 GPTとMBRの比較

AlmaLinux9では、UEFIブートや大容量ストレージの利用を前提にGPT（GUID Partition Table）が推奨されています。GPTはMBR（Master Boot Record）の以下の制約を克服しています。

  • 容量制限：MBRは最大2 TiB（約2.2 TB）までしかアドレスできませんが、GPTは8 ZiB（512 Bセクタ）または64 ZiB（4 KiBセクタ）まで対応します (Red Hat Documentation, Red Hat Documentation)
  • パーティション数：MBRはプライマリ4つまたは拡張＋ロジカルで最大15個程度が上限ですが、GPTはデフォルトで128個のプライマリパーティションをサポートします (Red Hat Documentation)
  • UEFI対応：UEFI環境では必須のEFIシステムパーティション（ESP）をGUIDで扱えるため、最新ハードウェアとの互換性が高まります (Red Hat Documentation)

💡ポイント
新規導入環境や大容量ディスクでは基本的にGPTを選択し、MBRはレガシ用途に限定しましょう。

6.2.2 パーティションテーブルの内部構造

MBRはディスク先頭の512 バイトに配置され、先頭446 バイトにブートローダコード、次の64 バイトに4つのパーティションエントリ、最後の2 バイトにシグネチャ「0x55AA」を持ちます。これにより、大きなディスクや多数パーティションには不向きです (Red Hat Documentation, Red Hat Documentation)。

GPTは以下のレイアウトで構成され、信頼性と拡張性に優れます (Red Hat Documentation)：

  1. 保護用MBR (Protective MBR) (LBA 0)：従来ツール向けにディスク全体を1つのパーティションとして保護。
  2. プライマリGPTヘッダ (LBA 1)：ディスクGUID、プライマリ/セカンダリパーティションテーブルの位置、CRC32チェックサムを含む。
  3. パーティションエントリ領域 (通常LBA 2以降)：デフォルト128エントリ、各128 バイトでパーティションタイプGUIDとユニークGUIDを保持。
  4. バックアップGPTヘッダ (最後のセクタ)：プライマリヘッダ破損時の復旧用。

💡ポイント
GPTのバックアップヘッダにより、パーティションテーブルの破損時にも迅速な復旧が可能です。

6.2.3 パーティションアラインメントとパフォーマンス

パーティションの開始オフセットが物理デバイスのセクタ／ブロック境界に整合していないと、追加のI/O操作が発生し、パフォーマンス低下やSSDの消耗増大を招きます。一般的には1 MiB単位でのアラインメントが推奨され、partedやgdiskはデフォルトでこの境界に合わせます (Ask Ubuntu, Red Hat Customer Portal)。

  • 問題例：開始オフセットが512 B境界ではなく不整合なセクタ位置だと、アクセスごとに余分な読み書きが発生します (Red Hat Customer Portal)。
  • 最適アラインメント：1 MiB（2048セクタ）を確保することで、512 B／4 KiB両方の境界を同時にクリアできます。

💡ポイント
高性能ストレージやSSDでは、必ず1 MiB単位でアラインメントを整えてI/O効率とデバイス寿命を最適化しましょう。

6.2.4 CLIツールによるパーティション操作

AlmaLinux9では主にfdisk、parted、gdisk/sgdiskの3つを使い分けます。用途に応じて最適なツールを選択してください。

fdisk

  • 特徴：MBRメイン、対話的UI、シンプルな操作
  • 実行ユーザー: root
  • 期待される結果: 対話シェルが起動し、mでヘルプ、pでパーティションテーブル表示、nで新規パーティション作成が可能
sudo fdisk /dev/sda

💡ポイント
RHCSA試験対策や簡易パーティショニングに最適です (DigitalOcean)。

parted

  • 特徴: GPT／MS-DOS両対応、スクリプト実行可、開始位置に柔軟な単位指定
  • 実行ユーザー: root
  • 期待される結果: デバイス情報表示後、mklabel gptでGPTラベル作成、mkpartでパーティション追加
sudo parted /dev/sda --script mklabel gpt
sudo parted /dev/sda --script mkpart primary 1MiB 100%

💡ポイント
大容量ディスクや自動化シナリオに便利です (Red Hat Documentation, Red Hat Documentation)。

gdisk／sgdisk

  • 特徴: GPT専用、gdiskは対話式、sgdiskは非対話式でスクリプト向け
  • 実行ユーザー: root
  • 期待される結果: gdisk -lでGPTテーブル表示、sgdiskコマンドで即時更新
sudo gdisk -l /dev/sda
sudo sgdisk --new=1:0:+512M --typecode=1:ef00 --change-name=1:'EFI System Partition' /dev/sda

💡ポイント
UEFIシステムパーティションなどのGUID指定が簡単に行えます (linuxconfig.org)。

6.3 ファイルシステムの選択基準と作成

AlmaLinux9 上でのストレージ構築では、ファイルシステムの選択がパフォーマンスや可用性、セキュリティに直結します。ここでは、RHEL 9（AlmaLinux9 互換）でサポートされる主要なファイルシステムである ext4 と XFS の特長を深掘りし、それぞれの作成手順と検証方法を詳しく解説します。ファイルシステムに対する SELinux コンテキスト設定も忘れずに行い、セキュリティ設定 を強化しましょう。 (Red Hat Documentation, Red Hat Documentation)

6.3.1 ファイルシステム選択の基準：ext4 vs XFS

以下の表は、ext4 と XFS の主な特長と、用途別の推奨ポイントをまとめたものです。ディスク容量、I/O 特性、可用性要件に応じて選択してください。 (Red Hat Documentation)

項目ext4XFS
ジャーナリングdata=ordered（デフォルト）。メタデータチェックサム有効（RHEL 9）メタデータ・ジャーナリング。エラー時は FS シャットダウンして EFSCORRUPTED を返す
最大ファイル／FS サイズ個別ファイル最大16 TiB、FS最大50 TiBFS最大1 024 TiB
拡張／縮小オンライン拡張・オフライン縮小対応オンライン拡張のみ（縮小不可）
割り当て方式Extents, Delayed allocation, Multiblock allocation, Stripe-aware allocationExtent-based allocation, Delayed allocation, Stripe-aware allocation, Space pre-allocation, Dynamically allocated inodes
チェック・修復e2fsck：Lazy init, uninit_bg などで高速化xfs_repair：スケーラブルで大容量向け
クォータ有効化後にマウントオプションで制御初回マウント時にのみ有効化。quotacheck不要
特殊機能Subsecond timestamps, Extended attributes, Quota journalingReflink, Online defragmentation, Project quotas, Comprehensive diagnostics
推奨ユースケース単一スレッド／低I/O環境、小規模サーバ、オフライン縮小が必要な用途高スループット、大規模ストレージ、多数同時I/O、エンタープライズ環境

💡ポイント
ベンチマークは必ず実環境で実施し、必要に応じて /etc/fstab に noatime や nodiratime を設定して I/O 負荷を最適化しましょう。 (Red Hat Documentation)

6.3.2 ext4 ファイルシステムの作成と最適化

ext4 は成熟した安定性と豊富な情報資源が特徴です。以下の例では、主要な拡張機能を有効化しつつ、ラベルを付与して管理性を高めます。

実行ユーザー: root
期待される結果: /dev/sdb1 に ext4 ファイルシステムが作成され、ラベル DATA_PART が設定される

# mkfs.ext4 での最適化オプション指定例
sudo mkfs.ext4 \
  -L DATA_PART \
  -O extent,dir_index,uninit_bg,metadata_csum,64bit \
  /dev/sdb1
  • -L: ラベル設定
  • -O: 有効化する機能（extent: エクステント、dir_index: ディレクトリ B-tree、uninit_bg: 未初期化ブロックグループ、metadata_csum: メタデータチェックサム、64bit: 64bit FS） (Red Hat Documentation)

💡ポイント
RAID 環境では -E stride=<数>,stripe-width=<数> を指定し、ストライプジオメトリに合わせるとパフォーマンスが向上します。 (Red Hat Documentation)

6.3.3 XFS ファイルシステムの作成と最適化

XFS は RHEL9 のデフォルトファイルシステムであり、大容量・高並列I/Oに最適化されています。標準機能のほか、メタデータの CRC や inobtcount（inode B-tree カウント）もデフォルト有効です。

実行ユーザー: root
期待される結果: /dev/sdc1 に XFS ファイルシステムが強制作成される

sudo mkfs.xfs \
  -f \
  /dev/sdc1

💡ポイント
大規模ファイルや多数同時アクセスが想定される場合、-d agcount=<数> や -i size=<バイト数> でアロケーショングループや inode サイズを調整すると効果的です。 (Red Hat Documentation)

6.3.4 ファイルシステムの確認：UUID とラベル

作成後は必ずデバイス情報を確認し、/etc/fstab で UUID やラベルを用いた安定マウントを設定します。

実行ユーザー: root
期待される結果: /dev/sdb1 の UUID とラベルが表示される

sudo blkid /dev/sdb1
# 出力例:
# /dev/sdb1: UUID="abcd-1234-ef56-7890" TYPE="ext4" LABEL="DATA_PART"

lsblk -f /dev/sdb1
# 出力例:
# NAME   FSTYPE LABEL     UUID                                 MOUNTPOINT
# sdb1   ext4   DATA_PART abcd-1234-ef56-7890

# XFS の場合
sudo xfs_admin -l /dev/sdc1
# 出力例:
# label = "        "
# uuid = 123e4567-e89b-12d3-a456-426614174000

💡ポイント
UUID 指定（UUID=abcd-1234-ef56-7890）やラベル指定（LABEL=DATA_PART）でデバイスパス変動の影響を抑制できます。

6.4 fstab設定と自動マウント

AlmaLinux9環境では、永続的なマウントポイントの管理と起動時／アクセス時の自動マウントを正しく設定することが、堅牢かつ可用性の高いストレージ構築に不可欠です。本節では、/etc/fstab の役割と構造、主要オプションの解説、systemdとの連携による自動マウントユニット生成、そして動作検証とトラブルシューティング手順を詳述します。

6.4.1 /etc/fstab の役割と構造

/etc/fstab はシステム起動時や mount -a 実行時にファイルシステムを自動的にマウントするための設定ファイルです。各行は以下の6フィールドで構成されます (Red Hat Documentation):

フィールド説明
<デバイス>デバイス名(/dev/sda1)、UUID、LABEL
<マウントポイント>マウント先ディレクトリ(/data)
<ファイルシステム>xfs, ext4, nfs4 など
<オプション>defaults, nofail, x-systemd.automount など
<dump>dumpバックアップの有無（0/1）
<pass>fsck検査順序（0, 1, 2）
# /etc/fstab の例
UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b  /boot  xfs   defaults               0 0
/dev/sdb1                                 /data  ext4  defaults,nofail,x-systemd.automount  0 2

💡ポイント
6つのフィールドは空白またはタブで区切り、誤ったフィールド数やスペルミスが起動エラーを招くため、編集後は必ず検証を行いましょう。

6.4.2 主なマウントオプション

<オプション>フィールドでは、起動時やアクセス時の挙動、セキュリティ設定などを細かく制御できます。代表的なオプションは以下の通りです。

オプション説明参照
defaultsrw,suid,dev,exec,auto,nouser,async の合成オプション(Man7)
nofailデバイス未検出時に起動失敗とせず無視(Википедия — свободная энциклопедия)
noautomount -a 実行時にマウントしない(Man7)
user / owner一般ユーザー（またはデバイス所有者）によるマウントを許可(Man7)
exec / noexecバイナリ実行を許可／禁止(Википедия — свободная энциклопедия)
x-systemd.automountsystemd の automount ユニットを生成、アクセス時にマウント(Arch Linux フォーラム)
x-systemd.device-timeoutデバイス検出待機時間を指定（例: x-systemd.device-timeout=5s）(xinnor.io)
context=…SELinux ラベルを明示的に指定（例: context="system_u:object_r:var_t:s0")(Unix & Linux Stack Exchange)

💡ポイント
USBメディアやオプションディスクでは nofail を、ネットワーク共有では _netdev（起動前のネットワーク待ち）と組み合わせて安定起動を実現しましょう。

6.4.3 systemd-fstab-generator と自動マウントユニット

systemd では起動時に systemd-fstab-generator が /etc/fstab のエントリを読み込み、以下のユニットファイルを動的に生成します (Red Hat Documentation):

  • *.mount ユニット: 通常マウント用
  • *.automount ユニット: x-systemd.automount 指定時のオンデマンドマウント用

これにより、起動シーケンスに組み込まれるだけでなく、アクセス時に遅延マウントさせることが可能です。自動生成されたユニットは /run/systemd/generator/ に配置され、systemctl status や journalctl で管理・確認できます (Eli Billauer’s Home Page)。

💡ポイント
x-systemd.automount を指定すると、アクセス要求時までファイルシステムをマウントせず、I/O負荷や待機時間の削減につながります。

6.4.4 マウント検証とトラブルシューティング

  • fstab全体の検証
sudo mount -a

noauto 以外のエントリを一括マウントし、エラーを即時確認できます (Man7)。

  • systemdユニットの状態確認
systemctl status data.mount
systemctl status data.automount
journalctl -b -u data.mount
  • 失敗ユニットのリセット
    過去にマウント失敗したユニットが残っている場合、再起動時に影響を与えます。
sudo systemctl reset-failed
  • パッケージの最新化
    systemd-fstab-generator や automount機能のバグ修正を適用するため、以下で systemd関連を最新に保ちます。
sudo dnf update systemd

💡ポイント
変更後は sudo systemctl daemon-reload を実行し、generator 設定を再読み込みしてから検証を行うと確実です。

6.5 LVMの高度な活用

AlmaLinux9環境でストレージをさらに柔軟かつ効率的に運用するには、LVMの高度な機能を理解し、適切に活用することが重要です。本節では、以下の4つの主要機能について解説します。

  1. スナップショット管理
  2. キャッシュ機能の利用
  3. カスタム薄プロビジョニングプールの作成
  4. カスタムVDO論理ボリュームの作成

これらを適切に組み合わせることで、バックアップ・リストア戦略の強化、I/O性能の向上、容量効率化が可能になります (Red Hat Documentation)。

6.5.1 論理ボリュームのスナップショット管理

スナップショットは、元のLVのポイントインタイムコピーを取得し、変更前の状態にロールバックしたり、アップグレード時の安全なテスト領域として利用できます。CoW (Copy-on-Write) 機構により、元LVのデータブロックをそのまま参照しつつ、変更が発生したタイミングで変更前のデータだけをコピーするため、効率的に運用できます (Red Hat Documentation)。

6.5.1.1 シックプロビジョニングスナップショットの作成

実行ユーザー: root
期待される結果: /dev/vg0/snap_lv にシックプロビジョニングスナップショットが作成される

sudo lvcreate \
  --snapshot \
  --size 5G \
  --name snap_lv \
  vg0/origin_lv
  • --snapshot：スナップショットモード
  • --size：事前割当するスナップショット領域（例：5G）
  • vg0/origin_lv：元の論理ボリューム名

作成後は以下で状態確認可能です。

lvs -o lv_name,origin,data_percent,lv_size
# スナップショットの使用率と関連元を確認

💡ポイント
スナップショット領域が100%に到達すると無効化されるため、data_percent を定期監視し、必要に応じて lvextend でサイズを拡張してください (Red Hat Documentation)。

6.5.1.2 シンプロビジョニングスナップショットの作成

シンプロビジョニングLV（thin pool上のLV）からは、事前割当なしでスナップショットを作成できます。ストレージ利用効率を最大化しつつ複数のスナップショットを運用可能です (Red Hat Documentation)。

実行ユーザー: root
期待される結果: /dev/vg0/thin_snap にシンプロビジョニングスナップショットが作成される

sudo lvcreate \
  --snapshot \
  --name thin_snap \
  vg0/thin_lv

💡ポイント
シンプロビジョニングではオーバーコミットが可能ですが、thin pool全体の使用量（thin_percent）が100%に達すると新規書き込みが失敗するため、thin_percent のモニタリングも欠かせません (Red Hat Documentation)。

6.5.2 キャッシュ機能の利用

dm-cache および dm-writecache を使うことで、SSDやNVMeなど高速ストレージをHDDなど低速ストレージのキャッシュとして利用し、読み書き性能を大幅に向上できます (Red Hat Documentation)。

6.5.2.1 dm-cacheによる双方向キャッシュ

実行ユーザー: root
期待される結果: /dev/vg0/data_lv がキャッシュプール cache_pool によって加速される

# 1. キャッシュプールを作成
sudo lvcreate \
  --type cache-pool \
  --name cache_pool \
  --size 20G \
  vg0 /dev/nvme0n1

# 2. キャッシュプールをLVにアタッチ
sudo lvconvert \
  --type cache \
  --cachepool vg0/cache_pool \
  vg0/data_lv
  • --type cache-pool：キャッシュ専用LV作成
  • --cachepool：キャッシュプール指定
  • vg0/data_lv：対象LV名
lvs -o lv_name,pool_lv
# Pool列にキャッシュプール名が表示されれば成功

💡ポイント
読み書き両方を高速化したい場合に有効です。キャッシュデバイスの寿命管理や、キャッシュプールの使用率（cache_percent）監視を忘れずに行ってください (Red Hat Documentation)。

6.5.2.2 dm-writecacheによる書き込みキャッシュ

書き込み集約型ワークロードでは、dm-writecache を使って書き込み操作のみをキャッシュできます。

実行ユーザー: root
期待される結果: /dev/vg0/log_lv の書き込みが高速ストレージ上で一時保持される

# 1. キャッシュ用LVを作成
sudo lvcreate \
  --name writecache_lv \
  --size 10G \
  vg0 /dev/nvme0n2

# 2. 書き込みキャッシュをアタッチ
sudo lvconvert \
  --type writecache \
  --cachevol writecache_lv \
  vg0/log_lv

lvs -o lv_name,pool_lv
# Pool列にキャッシュLV名が表示されれば成功

💡ポイント
書き込みキャッシュ適用後はデータ一貫性に注意し、障害発生時の再起動手順やフェールバックプランを事前に検討してください (Red Hat Documentation)。

6.5.3 カスタムシンプロビジョニングプールの作成

デフォルトのthin poolではなく、独自のデータ領域とメタデータ領域を明示的に分離して管理することで、パフォーマンスチューニングや障害時のリカバリ性を向上できます (Red Hat Documentation)。

実行ユーザー: root
期待される結果: /dev/vg0/thinpool_data と /dev/vg0/thinpool_meta を組み合わせたカスタムthin poolが作成される

# 1. データ用LV作成
sudo lvcreate \
  --name thinpool_data \
  --size 200G \
  vg0 /dev/sdb1

# 2. メタデータ用LV作成
sudo lvcreate \
  --name thinpool_meta \
  --size 2G \
  vg0 /dev/sdb2

# 3. カスタムthin pool結合
sudo lvconvert \
  --type thin-pool \
  --poolmetadata vg0/thinpool_meta \
  vg0/thinpool_data

lvs -o lv_name,seg_type
# thinpool_data が thin-pool と表示されれば成功

💡ポイント
メタデータ領域はthin pool全体の状態を管理するため、小さすぎるとパフォーマンス低下やメタデータ溢れのリスクがあります。運用環境での負荷に応じてサイズを調整してください (Red Hat Documentation)。

6.5.4 カスタムVDO論理ボリュームの作成

Virtual Data Optimizer (VDO) を利用すると、重複排除や圧縮によりストレージ効率を飛躍的に高められます。LVMと組み合わせてVDO LVを作成する方法を示します (Red Hat Documentation)。

実行ユーザー: root
期待される結果: /dev/vg0/vdo_lv としてVDO機能付きLVが作成される

# 1. VDOプール用LV作成
sudo lvcreate \
  --name vdo_pool \
  --size 50G \
  vg0

# 2. VDO LV作成（仮想サイズ200G）
sudo lvconvert \
  --type vdo \
  --name vdo_lv \
  --virtualsize 200G \
  vg0/vdo_pool

lvs -o lv_name,vg_attr,data_percent
# vdo_lv が VdO 属性で、使用率が確認できれば成功

💡ポイント
VDOは重複排除や圧縮の比率がワークロードに依存するため、vdo status コマンドで実効比率をモニタリングし、Thin pool同様にリソース計画を行ってください (Red Hat Documentation)。

6.6 ソフトウェアRAID (mdadm) の基礎

AlmaLinux 9（RHEL 9互換）では、複数のブロックデバイスを論理的にまとめて冗長性や性能を向上させるために、カーネル標準の md (Multiple Devices) ドライバとユーザー空間ツール mdadm を使用します。ここでは、RAIDの基本概念から構築、運用、トラブルシュートについて解説します。

6.6.1 RAIDの概要と設計指針

RAID（Redundant Array of Independent Disks）は、複数の物理ディスクをまとめて一つの論理ボリュームとして扱い、以下のようなメリットを提供します (Man7, Red Hat Documentation)：

  • 冗長性（信頼性向上）：ディスク障害時もデータを保持（RAID 1, 5, 6, 10 など）
  • 性能向上（スループット・I/O分散）：並列アクセスによるスループット向上（RAID 0, 10 など）
  • 容量効率：パリティ方式により、ミラーリングよりも効率的な冗長化（RAID 5, 6）

主な RAID レベルと特徴は以下の通りです：

レベル構成特徴最低デバイス数
RAID 0ストライピングデータ分散で性能↑、冗長性×2
RAID 1ミラーリング完全ミラーで信頼性↑、読み取り性能↑、書き込み性能↓2
RAID 5パリティ付き容量効率◎、冗長性（1台分）、性能バランス3
RAID 6ダブルパリティ同時2台障害許容、容量効率↔、書き込み性能↓4
RAID 10ミラー×ストライプ高性能＋高冗長性、コスト高4

6.6.2 mdadmのインストールとメタデータ形式

AlmaLinux 9では、mdadmパッケージが標準リポジトリに含まれています。

実行ユーザー: root
期待される結果: mdadmコマンドが利用可能になる

sudo dnf install -y mdadm

mdadmはディスク上にメタデータ（スーパーブロック）を埋め込むことでRAID情報を管理します。主なメタデータバージョンは以下の3種類です (raid.wiki.kernel.org)：

  • 0.90：古典的フォーマット、ディスク末尾に配置、2 TiB上限
  • 1.0 ：0.90と同様だが先頭に配置
  • 1.2 ：先頭1 MiBに配置（大容量ディスク対応）、デフォルト

大容量ディスク（>2 TiB）やUEFI環境では、デフォルトの 1.2 メタデータを利用してください。

6.6.3 RAIDアレイの作成

6.6.3.1 基本的な作成手順

実行ユーザー: root
期待される結果: /dev/md0 に指定レベルのRAIDが構築される

sudo mdadm --create /dev/md0 \
  --level=5 \
  --raid-devices=3 \
  --metadata=1.2 \
  --chunk=64K \
  /dev/sdb1 /dev/sdc1 /dev/sdd1
  • --level：RAIDレベル
  • --raid-devices：メンバー数
  • --metadata：メタデータバージョン
  • --chunk：ストライプチャンクサイズ（例: 64KiB） (Red Hat Documentation)

チャンクサイズの選定

  • 小さすぎるとオーバーヘッド増
  • 大きすぎると小規模I/Oに不向き
  • ファイルシステムのストライプ幅やワークロードに合わせて調整

6.6.3.2 永続化設定

作成後、以下でスキャンと自動再構築用設定を行います。

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf
  • /etc/mdadm.conf：ARRAY, DEVICE, MAILADDR などを記述
  • システム起動時に自動構成

6.6.4 RAIDアレイの状態確認と監視

6.6.4.1 リアルタイム状態チェック

cat /proc/mdstat
sudo mdadm --detail /dev/md0
  • /proc/mdstat：全RAIDデバイスの同期状況
  • --detail：UUID、レベル、スロット状況、リビルド進捗 (Red Hat Documentation)

6.6.4.2 メール通知設定

/etc/mdadm.conf に MAILADDR を追記し、mdadm --monitor を有効化すると、障害検知時にメールが飛びます (Red Hat Documentation)。

# /etc/mdadm.conf
MAILADDR admin@example.com

サービス化例:

sudo systemctl enable --now mdmonitor.service

6.6.5 障害時のディスク交換とデグレードモード

6.6.5.1 障害ディスクのマークと除外

実行ユーザー: root
期待される結果: /dev/sdc1 が故障扱いとなり、リビルド対象になる

sudo mdadm --manage /dev/md0 --fail /dev/sdc1
sudo mdadm --manage /dev/md0 --remove /dev/sdc1

6.6.5.2 代替ディスクの追加とリビルド

sudo mdadm --manage /dev/md0 --add /dev/sde1
# リビルド進捗を確認
cat /proc/mdstat
  • 再同期（リビルド）にはI/O帯域を専有するため、業務時間外や --bitmap=external を活用した段階同期を検討します (Kernel)。

6.6.6 RAIDアレイの拡張とレベル変換

mdadmでは既存アレイの容量・レベル変更が可能です。

6.6.6.1 容量拡張

sudo mdadm --grow /dev/md0 --size=max
# パーティションテーブル再読み込み
sudo partprobe /dev/md0

6.6.6.2 レベル変換

# RAID 1→RAID 5（最低3台必要）
sudo mdadm --grow /dev/md0 --level=5 --raid-devices=3 --add /dev/sdf1
  • 途中段階でRAID 0に変換し、さらにRAID 5へ移行する場合は段階的に実行 (Red Hat Documentation)。

6.6.7 ベストプラクティスとチューニング

  • チャンク/ストライプ整合：ファイルシステムやアプリケーションのI/Oパターンに合わせる
  • 外部ビットマップ：--bitmap=external /path/to/bitmap.file で段階同期時のI/O削減
  • スペア有り：--spare-devices で自動フェイルオーバー
  • 定期スクラブ：echo check > /sys/block/md0/md/sync_action や cron/systemd.timer で実施
  • モニタリング：mdadm --monitor、Prometheus Exporter などとの連携
  • バックアップ：重要データはRAIDだけでなく別媒体やリモートにも保持

6.7 ストレージ監視とメンテナンス

AlmaLinux9 環境では、ストレージの健全性維持とパフォーマンス最適化のために、定期的な監視とメンテナンスが欠かせません。sysstat パッケージ（iostat, sar）や smartmontools（smartctl）といった標準ツールを活用し、可用性と性能の両立を図ります (Red Hat Documentation, Tenable®)。

6.7.1 ディスク使用量と容量分析 (df, du)

ディスク全体および特定ディレクトリの使用量を把握することで、不意の容量枯渇を防ぎます。

  • df: マウントされたファイルシステム全体の使用状況を表示
  • du: 指定ディレクトリ以下のファイル・ディレクトリ別使用量を集計
# 全ファイルシステムの使用率を人間可読形式で表示
df -h
# 実行ユーザー: any
# 期待される結果: 各マウントポイントの容量、使用量、空き容量が MB/GB 単位で表示される

# /var/log 配下の合計サイズを人間可読形式で表示
du -sh /var/log
# 実行ユーザー: any
# 期待される結果: /var/log 配下の総使用量が MB/GB 単位で表示される

💡ポイント
定期的に大容量ログやキャッシュのクリーニングを行い、不要ファイル削除を自動化すると管理負荷が軽減します (The world’s open source leader, The world’s open source leader)。

6.7.2 I/O 性能監視 (iostat, sar, vmstat)

I/O ボトルネック検出のために、ブロックデバイス毎のスループットや待機時間を計測します。

# sysstat のインストール
sudo dnf install -y sysstat
# 実行ユーザー: root
# 期待される結果: iostat と sar コマンドが利用可能になる

# 拡張統計を 2 秒間隔で表示
iostat -xz 2
# 実行ユーザー: any (要 sysstat インストール)
# 期待される結果: 各デバイスの %util, await, r/s, w/s, rMB/s, wMB/s が表示される

# 過去の統計を含むレポートを取得
sar -d
# 実行ユーザー: root
# 期待される結果: デバイス毎の I/O 統計履歴が表示される

# CPU, メモリ, I/O, スワップを総合的に監視
vmstat 2 5
# 実行ユーザー: any
# 期待される結果: 2 秒間隔で 5 回のシステム全体リソース統計が表示される

💡ポイント
%util（ディスク利用率）や await（平均待機時間）が長期的に高止まりする場合、I/O サブシステムのボトルネックを疑い、必要に応じてストレージレイアウトを見直しましょう (Tenable®)。

6.7.3 リアルタイム I/O プロセス監視 (iotop, pidstat)

どのプロセスがディスク I/O を多く消費しているかをリアルタイムに把握します。

  • iotop: プロセス別の I/O 使用量を「top」形式で表示 (GeeksforGeeks)
  • pidstat: プロセス毎の累積 I/O 統計を取得 (Server Fault)
# iotop のインストール
sudo dnf install -y iotop
# 実行ユーザー: root
# 期待される結果: iotop コマンドが利用可能になる

# iotop の起動（I/O 実行中のプロセスのみ表示）
sudo iotop -o
# 実行ユーザー: root
# 期待される結果: 実際に I/O を行っているプロセスのみが表示される

# pidstat を使って 20 秒毎のプロセス別 I/O 統計を表示
pidstat -dl 20
# 実行ユーザー: any
# 期待される結果: プロセス毎の読み書きバイト数などが 20 秒間隔で表示される

💡ポイント
バッチジョブ実行時やピーク負荷時に監視を行い、「どのプロセスがディスクを占有しているか」を特定するとトラブルシュートが効率化します。

6.7.4 ディスクヘルスチェック (smartctl)

S.M.A.R.T. 情報を活用して、ディスクの故障予兆を早期検知します。

  • smartmontools: smartctl コマンドを提供 (contabo.com)
  • S.M.A.R.T. 属性やテストステータスを確認
# smartmontools のインストール
sudo dnf install -y smartmontools
# 実行ユーザー: root
# 期待される結果: smartctl コマンドが利用可能になる

# ディスクの全 S.M.A.R.T. 情報を表示
sudo smartctl -a /dev/sda
# 実行ユーザー: root
# 期待される結果: 各種属性値、エラー履歴、セルフテスト結果が表示される

# 短期セルフテストを実行
sudo smartctl -t short /dev/sda
# 実行ユーザー: root
# 期待される結果: 短期テストが開始され、数分後に結果が `-a` オプションで参照可能になる

💡ポイント
定期的（例: 週次）にテストを実行し、閾値超過した属性（Reallocated_Sector_Count など）を監視ツールでアラート化すると信頼性が向上します。

6.7.5 定期メンテナンス (fstrim, systemd-timer)

SSD やシンプロビジョニング環境では、未使用ブロックの解放（TRIM）が性能維持に重要です。

# 手動で単一ファイルシステムのバッチ TRIM
sudo fstrim /mnt/data
# 実行ユーザー: root
# 期待される結果: /mnt/data 上の未使用ブロックが解放され、合計解放量が表示される

# すべてのマウント済みファイルシステムで一括 TRIM
sudo fstrim --all
# 実行ユーザー: root
# 期待される結果: 各ファイルシステムごとの解放量が順次表示される

# 定期実行用の systemd タイマーを有効化
sudo systemctl enable --now fstrim.timer
# 実行ユーザー: root
# 期待される結果: 毎週日曜の午前3時頃に自動で fstrim を実行するタイマーが有効になる

💡ポイント
Red Hat はバッチまたは periodic discard を推奨しており、オンライン discard（discard マウントオプション）は必要な場合のみ有効化すると安定性が向上します (Red Hat Documentation)。

6.8 学習のまとめ

6.8.1 パーティショニング

AlmaLinux 9環境では、UEFIブートや大容量ストレージを前提にGPT（GUID Partition Table）が必須です。GPTは従来のMBRが抱える2 TiB上限を克服し、512 Bセクタでは最大8 ZiB、4 KiBセクタでは64 ZiBまで対応、標準で128個のプライマリパーティションを保有できます (Red Hat Documentation, Red Hat Documentation)。また、SSDやRAIDにおけるI/O性能とデバイス寿命維持のため、パーティション開始オフセットを1 MiB（2048セクタ）境界に整合させることが極めて重要であり、fdisk 2.17.1以降やparted/gdiskがデフォルトで1 MiB整合を実施します (Thomas-Krenn.AG, Unix & Linux Stack Exchange)。

6.8.2 ファイルシステム選択

RHEL 9系のデフォルトはXFSで、大規模データや高並列I/Oに最適化され、オンライン拡張やダイナミックinode、Reflinkなどの先進機能を備えます (Red Hat Documentation, Red Hat Documentation)。一方、ext4は成熟した安定性と広範な互換性を持ち、最大ファイルサイズ16 TiB・FSサイズ50 TiBをサポート、metadata_csumや64bit拡張をデフォルト有効としています。用途に応じ、パフォーマンスベンチマークを実環境で実施し、必要に応じてmountオプション（noatime, nodiratime）でチューニングを行います (Red Hat Documentation, Red Hat Documentation)。

6.8.3 fstab設定と自動マウント

永続的マウントは /etc/fstab にUUIDまたはLABEL指定で行い、defaults,nofail,_netdev,x-systemd.automount,context= などのオプションを組み合わせることで、起動時の堅牢性とオンデマンドマウントを両立します (Red Hat Documentation, The world’s open source leader)。systemd-fstab-generatorがエントリを *.mount／*.automount ユニットに動的生成し、daemon-reload→mount -a や systemctl status／journalctl で検証・トラブルシュートが可能です (Red Hat Documentation, Baeldung)。

6.8.4 LVMの高度な活用

LVMは pvcreate→vgcreate→lvcreate の基本フローに加え、CoW方式のスナップショット（thick/thin）、dm-cache/dm-writecache によるSSDキャッシュ、カスタムthin pool、VDO（重複排除・圧縮）など多彩な機能を提供します (Red Hat Documentation, Red Hat Documentation)。各種使用率（data_percent, thin_percent, cache_percent）は lvs や vdo status でモニタリングし、lvextend や poolmetadata 拡張で容量管理を継続的に行うことが重要です。

6.8.5 ソフトウェアRAID (mdadm)

mdadm はデフォルトでメタデータ1.2（先頭1 MiB）を用い、--chunk でチャンクサイズをI/Oパターンに合わせて最適化可能です。また、mdadm --scan | tee -a /etc/mdadm.conf で自動構成を永続化し、/proc/mdstat と mdadm --detail で同期状況、--manage --fail/--remove/--add で障害ディスク交換、--grow で容量・レベル変換を行えます。段階同期には内部/外部ビットマップ（--bitmap）を活用し、再同期時のI/O負荷を大幅に軽減できます (Red Hat Documentation, tgharold.com: Tech Blog)。

6.8.6 ストレージ監視とメンテナンス

可用性と性能を維持するには、sysstat の iostat -xz, sar、vmstat でディスク利用率（%util）や待機時間（await）、CPU/メモリを定期的に計測し、iotop, pidstat でプロセス別I/O占有を把握します (Red Hat Documentation, Pure Storage Blog)。また、smartmontools の smartctl/smartd でS.M.A.R.T属性（Reallocated_Sector_Count, Wear_Leveling_Count等）とセルフテスト（short/long）を自動化し、閾値超過時にアラートを発行して計画的交換を行います。SSDやシンプロビジョニング環境では fstrim --all と fstrim.timer を定期実行し、オンラインdiscardは必要時のみ有効化して性能劣化を防ぎます (Red Hat Documentation, smartmontools.org)。

6.9 さらなる学習リソース

以下に、AlmaLinux 9 のストレージ関連技術をさらに深く学ぶためのリソースをカテゴリ別にまとめました。公式ドキュメントから実践的なチュートリアル、トレーニングコース、コミュニティ情報まで幅広く網羅しています。

公式ドキュメント

オンラインチュートリアル

トレーニングコース

コミュニティ & フォーラム

これらのリソースを活用し、AlmaLinux 9 のストレージ管理技術をさらに深掘りしてください。

スポンサーリンク