第1章 利用可能なファイルシステムの概要

利用可能な選択肢と、関連するトレードオフが多数あるため、アプリケーションに適したファイルシステムを選択することが重要になります。本章では、Red Hat Enterprise Linux 8 に同梱されているファイルシステムの一部を説明し、アプリケーションに適したファイルシステムに関する過去の背景と推奨事項を示します。

1.1. ファイルシステムの種類

Red Hat Enterprise Linux 8 は、さまざまなファイルシステム (FS) に対応します。さまざまな種類のファイルシステムがさまざまな問題を解決し、その使用はアプリケーションによって異なります。最も一般的なレベルでは、利用可能なファイルシステムを以下の主要なタイプにまとめることができます。

表1.1 ファイルシステムの種類とそのユースケース

タイプファイルシステム属性とユースケース

ディスクまたはローカルのファイルシステム

XFS

XFS は、RHEL におけるデフォルトファイルシステムです。ファイルをエクステントとして配置するため、ext4 と比べて断片化に対する影響はありません。Red Hat は、互換性や、パフォーマンスおいて稀に発生する難しい問題などの特別な理由がない限り、XFS をローカルファイルシステムとしてデプロイすることを推奨します。

ext4

ext4 には、Linux の寿命が長いという利点があります。したがって、ほとんどすべての Linux アプリケーションでサポートされます。多くの場合は、パフォーマンスで XFS に匹敵します。ext4 は、一般的にホームディレクトリーに使用されます。

ネットワーク、またはクライアント/サーバーのファイルシステム

NFS

NFS は、同じネットワークにある複数のシステムでのファイル共有に使用します。

SMB

SMB は、Microsoft Windows システムとのファイル共有に使用します。

共有ストレージまたは共有ディスクのファイルシステム

GFS2

GFS2 は、コンピュートクラスターのメンバーに共有書き込みアクセスを提供します。可能な限り、ローカルファイルシステムの機能的経験を備えた安定性と信頼性に重点が置かれています。SAS Grid、Tibco MQ、IBM Websphere MQ、および Red Hat Active MQ は、GFS2 に問題なくデプロイされています。

ボリューム管理ファイルシステム

Stratis (テクノロジープレビュー)

Stratis は、XFS と LVM を組み合わせて構築されたボリュームマネージャーです。Stratis の目的は、Btrfs や ZFS などのボリューム管理ファイルシステムにより提供される機能をエミュレートすることです。このスタックを手動で構築することは可能ですが、Stratis は設定の複雑さを軽減し、ベストプラクティスを実装し、エラー情報を統合します。

1.2. ローカルファイルシステム

ローカルファイルシステムは、1 台のローカルサーバーで実行し、ストレージに直接接続されているファイルシステムです。

たとえば、ローカルファイルシステムは、内部 SATA ディスクまたは SAS ディスクにおける唯一の選択肢であり、ローカルドライブを備えた内蔵ハードウェア RAID コントローラーがサーバーにある場合に使用されます。ローカルファイルシステムは、SAN にエクスポートされたデバイスが共有されていない場合に、SAN が接続したストレージに最もよく使用されているファイルシステムです。

ローカルファイルシステムはすべて POSIX に準拠しており、サポートされているすべての Red Hat Enterprise Linux リリースと完全に互換性があります。POSIX 準拠のファイルシステムは、read()write()seek() など、明確に定義されたシステムコールのセットに対応します。

アプリケーションプログラマーの観点では、ローカルファイルシステム間の違いは比較的少なくなります。ユーザーの観点で最も重要な違いは、スケーラビリティーとパフォーマンスに関するものです。ファイルシステムの選択を検討する際に、ファイルシステムのサイズ、必要な固有の機能、実際のワークロードにおける実行方法を考慮してください。

利用可能なローカルファイルシステム

  • XFS
  • ext4

1.3. XFS ファイルシステム

XFSは、拡張性が高く、高性能で堅牢な、成熟した 64 ビットのジャーナリングファイルシステムで、1 台のホストで非常に大きなファイルおよびファイルシステムに対応します。これは、Red Hat Enterprise Linux 8 のデフォルトのファイルシステムです。XFS は、元々 1990 年代の前半に SGI により開発され、極めて大規模なサーバーおよびストレージアレイで実行されてきた長い歴史があります。

XFS の機能は次のとおりです。

信頼性
  • メタデータジャーナリング - システムの再起動時、およびファイルシステムの再マウント時に再生できるファイルシステム操作の記録を保持することで、システムクラッシュ後のファイルシステムの整合性を確保します。
  • 広範囲に及ぶランタイムメタデータの整合性チェック
  • 拡張性が高く、高速な修復ユーティリティー
  • クォータジャーナリングクラッシュ後に行なわれる、時間がかかるクォータの整合性チェックが不要になります。
スケーラビリティーおよびパフォーマンス
  • 対応するファイルシステムのサイズが最大 1024 TiB
  • 多数の同時操作に対応する機能
  • 空き領域管理のスケーラビリティーに関する B-Tree インデックス
  • 高度なメタデータ先読みアルゴリズム
  • ストリーミングビデオのワークロードの最適化
割り当てスキーム
  • エクステント (領域) ベースの割り当て
  • ストライプを認識できる割り当てポリシー
  • 遅延割り当て
  • 領域の事前割り当て
  • 動的に割り当てられる inode
その他の機能
  • Reflink ベースのファイルのコピー (Red Hat Enterprise Linux 8 の新機能)
  • 密接に統合されたバックアップおよび復元のユーティリティー
  • オンラインのデフラグ
  • オンラインのファイルシステム拡張
  • 包括的な診断機能
  • 拡張属性 (xattr)。これにより、システムが、ファイルごとに、名前と値の組み合わせを追加で関連付けられるようになります。
  • プロジェクトまたはディレクトリーのクォータ。ディレクトリーツリー全体にクォータ制限を適用できます。
  • サブセカンド (一秒未満) のタイムスタンプ

パフォーマンスの特徴

XFS は、エンタープライズレベルのワークロードがある大規模なシステムで優れたパフォーマンスを発揮します。大規模なシステムとは、相対的に CPU 数が多く、さらには複数の HBA、および外部ディスクアレイへの接続を備えたシステムです。XFS は、マルチスレッドの並列 I/O ワークロードを備えた小規模のシステムでも適切に実行します。

XFS は、シングルスレッドで、メタデータ集約型のワークロードのパフォーマンスが比較的低くなります。たとえば、シングルスレッドで小さなファイルを多数作成し、削除するワークロードがこれに当てはまります。

1.4. ext4 ファイルシステム

ext4 ファイルシステムは、ext ファイルシステムファミリーの第 4 世代です。これは、Red Hat Enterprise Linux 6 でデフォルトのファイルシステムです。

ext4 ドライバーは、ext2 および ext3 のファイルシステムの読み取りと書き込みが可能ですが、ext4 ファイルシステムのフォーマットは、ext2 ドライバーおよび ext3 ドライバーと互換性がありません。

ext4 には、以下のような新機能、および改善された機能が追加されました。

  • 対応するファイルシステムのサイズが最大 50 TiB
  • エクステントベースのメタデータ
  • 遅延割り当て
  • ジャーナルのチェックサム
  • 大規模なストレージサポート

エクステントベースのメタデータと遅延割り当て機能は、ファイルシステムで使用されている領域を追跡する、よりコンパクトで効率的な方法を提供します。このような機能により、ファイルシステムのパフォーマンスが向上し、メタデータが使用する領域が低減します。遅延割り当てにより、ファイルシステムは、データがディスクにフラッシュされるまで、新しく書き込まれたユーザーデータの永続的な場所の選択を保留できます。これにより、より大きく、より連続した割り当てが可能になり、より優れた情報に基づいてファイルシステムが決定を下すことができるため、パフォーマンスが向上します。

ext4 で fsck ユーティリティーを使用するファイルシステムの修復時間は、ext2 と ext3 よりも高速です。一部のファイルシステムの修復では、最大 6 倍のパフォーマンスの向上が実証されています。

1.5. XFS と ext4 の比較

XFS は、RHEL におけるデフォルトファイルシステムです。このセクションでは、XFS および ext4 の使用方法と機能を比較します。

メタデータエラーの動作
ext4 では、ファイルシステムがメタデータのエラーに遭遇した場合の動作を設定できます。デフォルトの動作では、操作を継続します。XFS が復旧できないメタデータエラーに遭遇すると、ファイルシステムをシャットダウンし、EFSCORRUPTED エラーを返します。
クォータ

ext4 では、既存のファイルシステムにファイルシステムを作成する場合にクォータを有効にできます。次に、マウントオプションを使用してクォータの適用を設定できます。

XFS クォータは再マウントできるオプションではありません。初期マウントでクォータをアクティブにする必要があります。

XFS ファイルシステムで quotacheck コマンドを実行すると影響しません。クォータアカウンティングを初めてオンにすると、XFS はクォータを自動的にチェックします。

ファイルシステムのサイズ変更
XFS には、ファイルシステムのサイズを縮小するユーティリティーがありません。XFS ファイルシステムのサイズのみを増やすことができます。ext4 は、ファイルシステムの拡張と縮小の両方をサポートします。
Inode 番号

ext4 ファイルシステムは、232 個を超える inode をサポートしません。

XFS は inode を動的に割り当てます。XFS ファイルシステムは、ファイルシステムに空き領域がある限り、inode からは実行できません。

特定のアプリケーションは、XFS ファイルシステムで 232 個を超える inode を適切に処理できません。このようなアプリケーションでは、戻り値 EOVERFLOW で 32 ビットの統計呼び出しに失敗する可能性があります。Inode 番号は、以下の条件下で 232 個を超えます。

  • ファイルシステムが 256 バイトの inode を持つ 1 TiB を超える。
  • ファイルシステムが 512 バイトの inode を持つ 2 TiB を超える。

inode 番号が大きくてアプリケーションが失敗した場合は、-o inode32 オプションを使用して XFS ファイルシステムをマウントし、232 未満の inode 番号を実施します。inode32 を使用しても、すでに 64 ビットの数値が割り当てられている inode には影響しません。

重要

特定の環境に必要な場合を除き、inode32 オプション は 使用しない でください。inode32 オプションは割り当ての動作を変更します。これにより、下層のディスクブロックに inode を割り当てるための領域がない場合に、ENOSPC エラーが発生する可能性があります。

1.6. ローカルファイルシステムの選択

アプリケーションの要件を満たすファイルシステムを選択するには、ファイルシステムをデプロイするターゲットシステムを理解する必要があります。以下の項目で、選択肢を確認できます。

  • 大容量のサーバーがあるか
  • ストレージの要件は大きいか、またはローカルで低速な SATA ドライブが存在するか
  • アプリケーションで期待される I/O ワークロードの種類
  • スループットとレイテンシーの要件
  • サーバーおよびストレージハードウェアの安定性
  • ファイルとデータセットの標準的なサイズ
  • システムで障害が発生した場合のダウンタイムの長さ

サーバーとストレージデバイスの両方が大きい場合は、XFS が最適です。ストレージアレイが小さくても、XFS は、平均のファイルサイズが大きい場合 (たとえば、数百メガバイト) に、非常に優れたパフォーマンスを発揮します。

既存のワークロードが ext4 で良好に機能している場合は、ext4 を引き続き使用することで、ユーザーとアプリケーションに非常に馴染みのある環境を提供できます。

ext4 ファイルシステムは、I/O 機能が制限されているシステムでパフォーマンスが向上する傾向があります。限られた帯域幅 (200MB/s 未満) と、最大約 1000 の IOPS 機能でパフォーマンスが向上します。より高い機能を備えたものであれば、XFS はより高速になる傾向があります。

XFS は、ext4 と比較して、メタデータあたりの CPU の動作を約 2 倍消費します。そのため、同時に処理できることがほとんどない、CPU にバインドされたワークロードがあると、ext4 の方が高速になります。通常、アプリケーションが 1 つの読み取り/書き込みスレッドと小さなファイルを使用する場合は ext4 の方が優れていますが、アプリケーションが複数の読み取り/書き込みスレッドと大きなファイルを使用する場合は、XFS の方が優れています。

XFS ファイルシステムを縮小することはできません。ファイルシステムを縮小できるようにする必要がある場合は、オフライン縮小に対応する ext4 を使用することを検討してください。

通常、Red Hat は、ext4 に対する特別なユースケースがない限り、XFS を使用することを推奨します。また、ターゲットサーバーとストレージシステムで特定のアプリケーションのパフォーマンスを測定して、適切なタイプのファイルシステムを選択するようにしてください。

表1.2 ローカルファイルシステムに関する推奨事項の概要

シナリオ推奨されるファイルシステム

特別なユースケースなし

XFS

大規模サーバー

XFS

大規模なストレージデバイス

XFS

大規模なファイル

XFS

マルチスレッド I/O

XFS

シングルスレッド I/O

ext4

制限された I/O 機能 (1000 IOPS 未満)

ext4

制限された帯域幅 (200MB/s 未満)

ext4

CPU にバインドされているワークロード

ext4

オフラインの縮小への対応

ext4

1.7. ネットワークファイルシステム

クライアント/サーバーファイルシステムとも呼ばれるネットワークファイルシステムにより、クライアントシステムは、共有サーバーに保存されているファイルにアクセスできます。これにより、複数のシステムの、複数のユーザーが、ファイルやストレージリソースを共有できます。

このようなファイルシステムは、ファイルシステムのセットを 1 つ以上のクライアントにエクスポートする、1 つ以上のサーバーから構築されます。クライアントノードは、基盤となるブロックストレージにアクセスできませんが、より良いアクセス制御を可能にするプロトコルを使用してストレージと対話します。

利用可能なネットワークファイルシステム

  • RHEL で最も一般的なクライアント/サーバーファイルシステムは、NFS ファイルシステムです。RHEL は、ネットワーク経由でローカルファイルシステムをエクスポートする NFS サーバーコンポーネントと、このようなファイルシステムをインポートする NFS クライアントの両方を提供します。
  • RHEL には、Windows の相互運用性で一般的に使用されている Microsoft SMB ファイルサーバーに対応する CIFS クライアントも含まれています。ユーザー空間 Samba サーバーは、RHEL サーバーから Microsoft SMB サービスを使用する Windows クライアントを提供します。

1.8. 共有ストレージファイルシステム

クラスターファイルシステムとも呼ばれる共有ストレージファイルシステムにより、クラスター内の各サーバーは、ローカルストレージエリアネットワーク (SAN) を介して共有ブロックデバイスに直接アクセスできます。

ネットワークファイルシステムとの比較

クライアント/サーバーのファイルシステムと同様、共有ストレージファイルシステムは、クラスターのすべてのメンバーであるサーバーのセットで機能します。ただし、NFS とは異なり、1 台のサーバーでは、その他のメンバーにデータまたはメタデータへのアクセスを提供しません。クラスターの各メンバーが同じストレージデバイス (共有ストレージ) に直接アクセスし、すべてのクラスターメンバーノードが同じファイルセットにアクセスできるようになります。

同時並行性

キャッシュの一貫性は、データの一貫性と整合性を確保するためにクラスター化されたファイルシステムで重要になります。クラスター内のすべてのノードに表示される、クラスター内のすべてのファイルのバージョンが 1 つ必要です。ファイルシステムは、クラスターのメンバーが同じストレージブロックを同時に更新して、データ破損を引き起こさないようにする必要があります。共有ストレージファイルシステムは、クラスター全体のロックメカニズムを使用して、同時実行制御メカニズムとしてストレージへのアクセスを調整します。たとえば、新しいファイルを作成したり、複数のサーバーで開いているファイルに書き込む前に、サーバーにあるファイルシステムコンポーネントが正しいロックを取得する必要があります。

クラスターファイルシステムの要件は、Apache Web サーバーのような可用性の高いサービスを提供することです。クラスターのすべてのメンバーに、共有ディスクのファイルシステムに保存されているデータに関する、完全に一貫した表示が提供され、すべての更新がロックメカニズムにより正しく調整されます。

パフォーマンスの特徴

共有ディスクファイルシステムは、ロックオーバーヘッドの計算コストのため、同じシステムで実行しているローカルファイルシステムと同じように機能するとは限りません。共有ディスクのファイルシステムは、各ノードが、その他のノードと共有していない特定のファイルセットにほぼ排他的に書き込むか、ファイルセットが、ノードセット間でほぼ排他的に読み取り専用で共有されるワークロードで良好に機能します。これにより、ノード間のキャッシュの無効化が最小限に抑えられ、パフォーマンスを最大化できます。

共有ディスクファイルシステムの設定は複雑で、共有ディスクのファイルシステムで適切に動作するようにアプリケーションを調整することが困難な場合があります。

利用可能な共有ストレージファイルシステム

  • Red Hat Enterprise Linux は、GFS2 ファイルシステムを提供します。GFS2 は、Red Hat Enterprise Linux High Availability Add-On および Resilient Storage Add-On と密接に統合されています。

    Red Hat Enterprise Linux は、サイズが 2 ノードから 16 ノードのクラスターで GFS2 に対応します。

1.9. ネットワークと共有ストレージファイルシステムの選択

ネットワークと共有ストレージのファイルシステムのいずれかを選択する際は、以下の点を考慮してください。

  • NFS ベースのネットワークファイルシステムは、NFS サーバーを提供する環境において、ごく一般的で評判が良い選択肢です。
  • ネットワークファイルシステムは、Infiniband や 10 ギガビットイーサネットなど、非常に高性能なネットワークテクノロジーを使用してデプロイできます。これは、ストレージに、生の帯域幅を取得するだけのために、共有ストレージのファイルシステムを有効にすべきではないことを意味します。アクセスの速度が非常に重要な場合は、NFS を使用して、XFS などのローカルファイルシステムをエクスポートします。
  • 共有ストレージのファイルシステムは、設定や維持が容易ではないため、ローカルまたはネットワークのファイルシステムのいずれかで必要な可用性を提供できない場合に限りデプロイしてください。
  • クラスター環境の共有ストレージのファイルシステムは、高可用性サービスの再配置を伴う一般的なフェールオーバーシナリオで、マウント解除およびマウントに必要な手順を省くことで、ダウンタイムを短縮できます。

Red Hat は、共有ストレージのファイルシステムに対する特別なユースケースがない限り、ネットワークのファイルシステムを使用することを推奨します。共有ストレージのファイルシステムは、主に、最小限のダウンタイムで高可用性サービスを提供する必要があり、サービスレベルの要件が厳しいデプロイメントに使用します。

1.10. ボリューム管理ファイルシステム

ボリューム管理ファイルシステムは、簡素化とスタック内の最適化の目的で、ストレージスタック全体を統合します。

利用可能なボリューム管理ファイルシステム

  • Red Hat Enterprise Linux 8 は、Stratis ボリュームマネージャーがテクノロジープレビューとして提供します。Stratis は、ファイルシステム層に XFS を使用し、LVM、Device Mapper、およびその他のコンポーネントと統合します。

    Stratis は、Red Hat Enterprise Linux 8.0 で初めてリリースされました。Red Hat が Btrfs を非推奨にした時に生じたギップを埋めると考えられています。Stratis 1.0 は、ユーザーによる複雑さを隠しつつ、重要なストレージ管理操作を実行できる直感的なコマンドラインベースのボリュームマネージャーです。

    • ボリュームの管理
    • プールの作成
    • シンストレージプール
    • スナップショット
    • 自動化読み取りキャッシュ

    Stratis は強力な機能を提供しますが、現時点では Btrfs や ZFS といったその他の製品と比較される可能性がある機能をいつくか欠いています。たとえば、セルフ修復を含む CRC には対応していません。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。