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

本章では Red Hat Enterprise Linux 7 で I/O やファイルシステムに関するアプリケーションパフォーマンスに影響を与える対応ファイルシステムおよび設定オプションについて簡単に説明します。「留意事項」ではパフォーマンスに影響を与える I/O およびファイルシステム関連の要因について、「パフォーマンス関連の問題の監視と診断」では I/O やファイルシステムの設定内容に関連するパフォーマンスの問題を分析する Red Hat Enterprise Linux 7 ツールについて説明しています。「設定ツール」では Red Hat Enterprise Linux 7 で I/O やファイルシステムに関するパフォーマンスの問題を解決する際に利用できるツールやストラテジーについて説明しています。

6.1. 留意事項

ストレージおよびファイルシステムのパフォーマンスに適した設定はそのストレージの使用用途に大きく依存します。I/O およびファイルシステムのパフォーマンスに影響を与える要因を以下に示します。
  • データの書き込みと読み取りのパターン
  • ベースとなる配列でデータを整列
  • ブロックサイズ
  • ファイルシステムのサイズ
  • ジャーナルサイズと場所
  • レコーディングのアクセスタイム
  • データ信頼性の確保
  • 事前読み出しのデータ
  • 事前割り当てのディスク領域
  • ファイル断片化
  • リソース競合
本章を読むと、ファイルシステムの処理能力、スケーラビリティ、応答性、リソース使用量、可用性などに影響を与えるフォーマットとマウントのオプションについて理解できます。

6.1.1. I/O スケジューラー

ストレージデバイスでの I/O の実行時間や実行のタイミングを決定するのが I/O スケジューラーです。I/O エレベーターとも呼ばれています。
Red Hat Enterprise Linux 7 では 3 種類の I/O スケジューラーを用意しています。
deadline
SATA ディスク以外のすべてのブロックデバイス向けのデフォルト I/O スケジューラーです。Deadline により、要求が I/O スケジューラーに到達した時点からの要求のレイテンシーが保証されます。このスケジューラーはほとんどのユースケースに適していますが、特に書き込み動作より読み取り動作の方が頻繁に起こるユースケースに適しています。
キュー待ち I/O 要求は、読み取りまたは書き込みのバッチに分けられてから、増大している論理ブロックアドレス順に実行スケジュールに入れられます。アプリケーションは読み取り I/O でブロックする可能性の方が高いため、デフォルトでは読み取りバッチの方が書き込みバッチより優先されます。1 バッチが処理されると deadline は書き込み動作が待機している長さを確認して次の読み取りバッチまたは書き込みバッチを適宜スケジュールします。1 バッチで処理する要求数、書き込みのバッチ 1 つに対して発行する読み取りのバッチ数、要求が期限切れになるまでの時間などはすべて設定、変更が可能です。詳細は「deadline スケジューラーのチューニング」をご覧ください。
cfq
SATA ディスクとして識別されるデバイスに限りデフォルトとなるスケジューラーです。cfq (Completely Fair Queueing) スケジューラーはプロセスをリアルタイム、ベストエフォート、アイドルの 3 種類のクラスに分割します。リアルタイムクラスのプロセスは常にベストエフォートのプロセスより先に処理され、ベストエフォートのプロセスはアイドルクラスのプロセスより先に処理されます。つまり、リアルタイムクラスのプロセスは、ベストエフォートおよびアイドルのクラスプロセス時間を奪うことになります。デフォルトでは、プロセスはベストエフォートクラスに割り当てられます。
Cfq は過去データを使ってアプリケーションで発行される今後の I/O 要求数の増減を予測します。I/O の増加を予測した場合は他のプロセスの I/O が処理を待機している場合であってもアイドリングを行い新しい I/O を待ちます。
cfq スケジューラーはアイドリング状態になりやすいため、意図的な調整を行わない限り、シーク時間を多く要さないハードウェアとは併用しないようにしてください。また、ホストベースのハードウェア RAID コントローラーなど、負荷節約型ではない他のスケジューラーとの併用も避けてください。こうしたスケジューラーを重ねると待ち時間が長くなる傾向があります。
Cfq の動作は高度な設定が可能です。詳細は「cfq スケジューラーのチューニング」を参照してください。
noop
noop I/O スケジューラーはシンプルな FIFO (first-in first-out) のスケジューリングアルゴリズムを実装しています。要求は 単純な last-hit キャッシュを介して汎用のブロック層でマージされます。これは、高速なストレージを使用した CPU バインドシステムに最適な I/O スケジューラーとなります。
異なるデフォルト I/O スケジューラーを設定する方法、特定のデバイスに別のスケジューラーを指定する方法などについては「設定ツール」を参照してください。

6.1.2. ファイルシステム

本セクションを読むと Red Hat Enterprise Linux 7 で対応しているファイルシステム、推奨される使用事例、一般的にファイルシステムに対して使用できるフォーマットとマウントオプションなどについて理解することができます。ファイルシステムを調整する際の推奨については「パフォーマンス改善を目的としたファイルシステムの設定」をご覧ください。

6.1.2.1. XFS

XFS は堅牢で拡張性の高い 64 ビットファイルシステムです。Red Hat Enterprise Linux 7 ではデフォルトのファイルシステムになります。XFS ではエクステントベースの割り当てと、事前割り当てや遅延割り当てを含む複数の割り当てスキームを使用できます。事前割り当てと遅延割り当てを使用すると、断片化が低減し、パフォーマンスが向上します。また、メタデータジャーナリング機能もサポートされるため、クラッシュから容易にリカバリーできます。XFS はマウントしてアクティブな状態のまま最適化や拡張を行うことができます。Red Hat Enterprise Linux 7 では XFS 固有のバックアップや復元用ユーティリティーに対応しています。
Red Hat Enterprise Linux 7.0 GA からは最大ファイルサイズ 500 TB、ファイルの最大オフセット 8 EB (sparse ファイル) に対応します。XFS を管理する方法については https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/ の『Red Hat Enterprise Linux 7 ストレージ管理ガイド』を参照してください。目的別に XFS を調整する方法については「XFS チューニング」を参照してください。

6.1.2.2. Ext4

ext4 は ext3 ファイルシステムの拡張性を高めたファイルシステムです。デフォルトの動作でほとんどの作業に適しています。ただし、対応しているファイルシステムの最大サイズは 50 TB まで、ファイルサイズは最大 16 TB までになります。ext4 の管理については https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/ の『Red Hat Enterprise Linux 7 ストレージ管理ガイド』を参照してください。目的別に ext4 を調整する方法については「ext4 のチューニング」を参照してください。

6.1.2.3. Btrfs (テクノロジープレビュー)

Red Hat Enterprise Linux 7 のデフォルトのファイルシステムは XFS です。Btrfs (B-tree file system) は比較的新しい copy-on-write (COW) ファイルシステムであり、技術プレビュー として提供されます。一部のユニークな Btrfs の機能は以下のとおりです。
  • ファイルシステム全体ではなく特定のファイル、ボリューム、またはサブボリュームのスナップショットを取得する機能。
  • Redundant Array of Inexpensive Disks (RAID) の複数のバージョンのサポート。
  • I/O エラーとファイルシステムオブジェクトのマップの逆参照。
  • 透過的な圧縮 (パーティション上のすべてのファイルは自動的に圧縮されます)。
  • データおよびメタデータのチェックサム。
Btrfs は安定的なファイルシステムと見なされますが、開発が続行されているため、成熟したファイルシステムと比べて修復ツールなどの一部の機能は限定的です。
現時点では、高度な機能 (スナップショット、圧縮、ファイルデータチェックサムなど) が必要な場合は、Btrfs を選択することが適切ですが、パフォーマンスは相対的に重要ではありません。高度な機能が必要でない場合は、障害が発生したり、時間とともにパフォーマンスが低下したりするため、他のファイルシステムを使用することが推奨されます。他のファイルシステムと比較した場合の別の欠点は、サポートされる最大ファイルシステムサイズが 50 TB であることです。
詳細については、「Btrfs のチューニング」と『Red Hat Enterprise Linux 7 ストレージ管理ガイド』の「Btrfs」の章を参照してください。

6.1.2.4. GFS2

Global File System 2 (GFS2) は、クラスター化ファイルシステムのサポートを Red Hat Enterprise Linux 7 に提供する High Availability Add-On の一部です。GFS2 は、1 クラスター内の全サーバーで整合性のあるファイルシステムイメージを提供し、サーバーが 1 つの共有ファイルシステムに対する読み取りと書き込みを行うことができるようにします。
GFS2 ファイルシステムは最大 100 TB のサイズまで対応しています。
GFS2 の管理の詳細については、『Red Hat Enterprise Linux 7 ストレージ管理ガイド』を参照してください。特定の目的のための GFS2 のチューニングについては、「GFS2 のチューニング」を参照してください。

6.1.3. ファイルシステムの一般的なチューニングで考慮すべき点

本セクションではすべてのファイルシステムに共通した注意点について記載しています。特定のファイルシステムのチューニングに関する推奨事項については「パフォーマンス改善を目的としたファイルシステムの設定」をご覧ください。

6.1.3.1. 時刻のフォーマットに関する注意点

デバイスのフォーマットを一旦行うと設定により決定される事項を変更できないファイルシステムがあります。本セクションではストレージデバイスのフォーマット化を行う前に決定しておかなければならないオプションについて説明します。
サイズ
負荷に適したサイズのファイルシステムを作成します。ファイルシステムのサイズが小さければ比例してバックアップに要する時間も短くなり、ファイルシステムのチェックにかかる時間やメモリーも少なくてすみます。ただし、ファイルシステムが小さ過ぎると深刻な断片化によるパフォーマンスの低下が発生します。
ブロックサイズ
ブロックとはファイルシステムの作業単位であり、ブロックサイズとは 1 ブロック内に格納できるデータ量です。つまり 1 度に書き込まれる、または読み取られる最小限のデータ量になります。
一般的な使用例のほとんどでデフォルトのブロックサイズが適したサイズになります。ただし、ブロックサイズ (または複数ブロックのサイズ) は一度に読み取られるまたは書き込まれる一般的なデータ量と同じか若干大きい方がファイルシステムのパフォーマンスが向上しデータをより効率的に格納するようになります。ファイルサイズは小さくても 1 ブロック全体が使用されます。複数ファイルが複数ブロックをまたいで使用することがありますが、実行時に余分なオーバーヘッドが生まれる可能性があります。また、ブロック数に制限のあるファイルシステムがあるため、この場合はファイルシステムの最大サイズも制限されることになります。
デバイスを mkfs コマンドでフォーマット化する際にファイルシステムのオプションとしてブロックサイズを指定します。ブロックサイズを指定するパラメーターはファイルシステムにより異なります。詳細は mkfs の man ページをご覧ください。たとえば、XFS ファイルシステムをフォーマット化する場合に利用できるオプションを表示させるには次のコマンドを実行します。 
$ man mkfs.xfs
配置
ファイルシステムの配列はファイルシステム全体にデータを配分することに関係しています。RAID などのストライプ型ストレージを使用する場合はデバイスのフォーマット時にベースとなるストレージの配列でデータやメタデータを揃えることでパフォーマンスを改善できます。
多くのデバイスは特定のファイルシステムでフォーマットを行う際に自動的に設定される推奨配列をエクスポートします。使用するデバイスが推奨配列をエクスポートしない、または推奨されている設定を変更したい場合などは mkfs でデバイスのフォーマットを行う際に手作業で配列を指定する必要があります。
ファイルシステムの配列を指定するパラメーターはファイルシステムによって異なります。詳細は使用するファイルシステムの mkfs man ページをご覧ください。たとえば、ext4 ファイルシステムのフォーマット時に使用できるオプションを表示させる場合は次のコマンドを実行します。 
$ man mkfs.ext4
外部ジャーナル
ファイルシステムのジャーナル機能は書き込み動作が実行される前にその書き込み動作で加えられる予定の変更をジャーナルファイルに記録します。これによりシステムクラッシュや停電などが発生した場合のデバイスの破損の可能性を低減し、復元プロセスをスピード化します。
メタデータの処理率が高い負荷の場合はジャーナルへの更新がかなり頻繁に必要になります。ジャーナルが大きいほどメモリー使用量も高くなりますが書き込み動作の頻度は減ります。また、メタデータの処理率が高い負荷を処理するデバイスのシーク時間を改善するには、そのジャーナルをより高速な処理が行えるプライマリーストレージとは別の専用ストレージに配置します。

警告

外部ジャーナルが信頼できるものであることを確認してください。外部のジャーナルデバイスが失われるとファイルシステムが破損します。
外部ジャーナルはフォーマット時に作成してください。ジャーナルデバイスはマウント時に指定されたものを使用します。詳細については mkfs の man ページおよび mount の man ページを参照してください。 
$ man mkfs
$ man mount

6.1.3.2. マウント時の注意点

本セクションではほとんどのファイルシステムに適用でき、デバイスのマウント時に指定することができるチューニングについて説明しています。
バリア
ファイルシステムバリアによりメタデータが正しく順番通りに永続ストレージに書き込まれ、停電時には fsync で送信したデータが必ず維持されるようになります。Red Hat Enterprise Linux の旧バージョンではファイルシステムバリアを有効にすると fsync に大きく依存するアプリケーションや小さなファイルを多数作成したり削除したりするアプリケーションなどの速度が著しく低下することがありました。
Red Hat Enterprise Linux 7 ではファイルシステムバリアのパフォーマンスが改善され、ファイルシステムバリアを無効にしても、パフォーマンスに対する影響はごくわずかになります (3 % 未満)。
詳細については https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/ の『Red Hat Enterprise Linux 7 ストレージ管理ガイド』を参照してください。
アクセス時間
ファイルが読み込まれる度、アクセスが起きた時間 (atime) でそのメタデータが更新されます。これによりさらに書き込み I/O が発生します。デフォルトでは Red Hat Enterprise Linux 7 は前回のアクセス時間が最後の変更 (mtime) または状態変更 (ctime) の時間より古い場合にのみ atime フィールドを更新するため、ほとんどの場合、このオーバーヘッドが最小になります。
ただし、このメタデータの更新に時間がかかり、また正確なアクセス時間のデータは必要としない場合、noatime マウントオプションを付けてファイルシステムをマウントすることができます。このオプションを付けるとファイルの読み取り時のメタデータへの更新が無効になります。また、nodiratime 動作が有効になるためディレクトリーの読み取り時のメタデータへの更新も無効になります。
先読み (read-ahead)
先読みは、すぐに必要になる可能性が高いデータを先に取得してページキャッシュにロードすることでディスクからより早くデータを読み出すことが可能になるため、ファイルアクセスの速度が速くなります。先読みの値が高いほどより多くのデータを先に取得します。
Red Hat Enterprise Linux は検出対象に応じて適切な先読み値の設定を試行します。ただし、正確な検出が常に可能なわけではありません。たとえば、ストレージアレイを単一の LUN としてシステムに提示すると、システム側はそれを単一の LUN として検出するためアレイに適切な先読み値を設定しません。
連続 I/O による多量のストリーミングを必要とする作業負荷の場合は先読み値を高くすると役に立つことがよくあります。Red Hat Enterprise Linux 7 で用意されているストレージ関連の調整済みプロファイルでは LVM ストライプを使用するため先読み値が高く設定されています。しかし、この調整が必ずしもあらゆる作業負荷に十分なわけではありません。
先読み動作を定義するパラメーターはファイルシステムにより異なります。詳細は mount の man ページをご覧ください。 
$ man mount

6.1.3.3. メンテナンス

SSD およびシンプロビジョンのストレージいずれの場合もファイルシステムで使用されていないブロックは定期的に破棄することを推奨しています。未使用ブロックの破棄方法はバッチ破棄とオンライン破棄の 2 通りの方法があります。
バッチ破棄
このタイプの破棄は fstrim コマンドの一部になります。指定した基準と一致するファイルシステム内の未使用ブロックをすべて破棄します。
Red Hat Enterprise Linux 7 では、物理的な破棄動作に対応している XFS と ext4 フォーマットのデバイスでバッチ破棄がサポートされます (つまり、/sys/block/devname/queue/discard_max_bytes の値がゼロ以外の HDD デバイスおよび /sys/block/devname/queue/discard_granularity の値が 0 以外の SSD デバイス)。
オンライン破棄
このタイプの破棄動作はマウント時に discard オプションを使って設定します。ユーザーの介入を必要とせずリアルタイムで実行されます。ただし、オンライン破棄は使用中から空きの状態に移行しているブロックしか破棄しません。Red Hat Enterprise Linux 7 では XFS および ext4 フォーマットのデバイスでオンライン破棄をサポートしています。
パフォーマンス維持にオンライン破棄が必要な状況やシステムの作業負荷上バッチ破棄が実行できないような状況を除き、バッチ破棄の使用を推奨しています。
事前割り当て
事前割り当てではディスク領域にデータを書き込むことなくその領域がファイルに割り当てられたという印を付けます。データの断片化および読み取り能力の低下などを制限する場合に便利です。Red Hat Enterprise Linux 7 では XFS、ext4、GFS2 のデバイスでのマウント時の領域事前割り当てに対応しています。ファイルシステムに適したパラメーターについては mount man ページをご覧ください。fallocate(2) glibc 呼び出しを使用するとアプリケーションに対しても領域の事前割り当てが有効に働きます。