Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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

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

8.1. 留意事項

ストレージおよびファイルシステムのパフォーマンスに適した設定はそのストレージの使用用途に大きく依存します。I/O およびファイルシステムのパフォーマンスは、以下のいずれかの要因により影響を受ける可能性があります。
  • データの書き込みと読み取りのパターン
  • 基礎となるジオメトリーとのデータ調整
  • ブロックサイズ
  • ファイルシステムのサイズ
  • ジャーナルサイズおよび場所
  • アクセス時間の記録
  • データの信頼性確保
  • 事前にフェッチするデータ
  • ディスク領域の事前割り当て
  • ファイルの断片化
  • リソースの競合
この章を読んで、ファイルシステムのスループット、スケーラビリティ、応答性、リソースの使用、および可用性に影響するフォーマットおよびマウントオプションについて理解してください。

8.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 でブロックする可能性の方が高いため、デフォルトでは読み取りバッチの方が書き込みバッチより優先されます。バッチが処理されると、deadline は書き込み操作がプロセッサー時間を使い果たした時間を確認し、必要に応じて次の読み取りまたは書き込みバッチをスケジュールします。1 バッチで処理する要求数、書き込みのバッチ 1 つに対して発行する読み取りのバッチ数、要求が期限切れになるまでの時間などはすべて設定、変更が可能です。詳細は、「deadline スケジューラーのチューニング」 をご覧ください。
cfq
SATA ディスクとして識別されるデバイスに限りデフォルトとなるスケジューラーです。Completely Fair Queueing スケジューラー cfq は、プロセスをリアルタイム、ベストエフォート、アイドルの 3 つのクラスに分割します。リアルタイムクラスのプロセスは常にベストエフォートのプロセスより先に処理され、ベストエフォートのプロセスはアイドルクラスのプロセスより先に処理されます。つまり、リアルタイムクラスのプロセスは、ベストエフォートおよびアイドルのクラスプロセス時間を奪うことになります。デフォルトでは、プロセスはベストエフォートクラスに割り当てられます。
cfq は履歴データを使用して、アプリケーションが近い将来より多くの I/O 要求を発行するかどうかを予測します。より多くの I/O が予想される場合、cfq は、他のプロセスからの I/O が処理を待機している場合でも、新しい I/O を待機するようアイドル状態になります。
cfq スケジューラーはアイドリング状態になりやすいため、意図的な調整を行わない限り、シーク時間を多く要さないハードウェアとは併用しないようにしてください。また、ホストベースのハードウェア RAID コントローラーなど、負荷節約型ではない他のスケジューラーとの併用も避けてください。こうしたスケジューラーを重ねると待ち時間が長くなる傾向があります。
cfq の動作は高度な設定が可能です。詳細は、「CFQ スケジューラーのチューニング」 を参照してください。
noop
noop I/O スケジューラーは、単純な FIFO （先入れ先出し）スケジューリングアルゴリズムを実装します。要求は 単純な last-hit キャッシュを介して汎用のブロック層でマージされます。これは、高速なストレージを使用した CPU バインドシステムに最適な I/O スケジューラーとなります。
異なるデフォルト I/O スケジューラーを設定する方法、特定のデバイスに別のスケジューラーを指定する方法などについては、「設定ツール」 を参照してください。

8.1.2. ファイルシステム

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

8.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 を管理する方法についてはRed Hat Enterprise Linux 7 ストレージ管理ガイドを参照してください。目的別に XFS を調整する方法については、「XFS チューニング」 を参照してください。

8.1.2.2. Ext4

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

8.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 の章を参照してください。

8.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 の管理に関する詳細はGlobal File System 2またはRed Hat Enterprise Linux 7 ストレージ管理ガイドを参照してください。目的別に GFS2 を調整する方法については、「GFS2 のチューニング」 を参照してください。

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

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

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

一部のファイルシステム設定は一旦決定すると、デバイスのフォーマット後に変更できません。本セクションではストレージデバイスのフォーマット化を行う前に決定しておかなければならないオプションについて説明します。
Size (サイズ)
ワークロードに適したサイズのファイルシステムを作成します。ファイルシステムのサイズが小さければ比例してバックアップに要する時間も短くなり、ファイルシステムのチェックにかかる時間やメモリーも少なくてすみます。ただし、ファイルシステムが小さ過ぎると深刻な断片化によるパフォーマンスの低下が発生します。
ブロックサイズ
ブロックは、ファイルシステムの作業単位です。ブロックサイズで、単一のブロックに保存可能なデータ量が決まるので、1 度に書き込みまたは読み取りされる最小データ量を指します。
デフォルトのブロックサイズは、ほとんどのユースケースに適しています。ただし、ブロックサイズ (または複数ブロックのサイズ) は一度に読み取られるまたは書き込まれる一般的なデータ量と同じか若干大きい方がファイルシステムのパフォーマンスが向上しデータをより効率的に格納するようになります。ファイルサイズは小さくても 1 ブロック全体が使用されます。ファイルは複数のブロックに分散できますが、ランタイム時のオーバーヘッドが増える可能性があります。また、ファイルシステムによっては、特定のブロック数が上限となっており、ファイルシステムの最大数が制限されます。
デバイスを mkfs コマンドでフォーマットする場合、ブロックサイズはファイルシステムのオプションの一部として指定されます。ブロックサイズを指定するパラメーターはファイルシステムによって異なります。詳細は mkfs の man ページをご覧ください。たとえば、XFS ファイルシステムをフォーマット化する場合に利用できるオプションを表示させるには次のコマンドを実行します。 
$ man mkfs.xfs
配置
ファイルシステムジオメトリーは、ファイルシステム全体でのデータの分散に関係があります。システムで RAID などのストライプ化ストレージを使用する場合は、デバイスのフォーマット時にデータおよびメタデータを下層にあるストレージジオメトリーに合わせて調整することで、パフォーマンスを向上させることができます。
多くのデバイスは推奨のジオメトリーをエクスポートし、デバイスが特定のファイルシステムでフォーマットされるとそのジオメトリーが自動的に設定されます。デバイスでこれらの推奨事項をエクスポートしない場合、または推奨される設定を変更する場合は、mkfs でデバイスをフォーマットする際にジオメトリーを指定する必要があります。
ファイルシステムジオメトリーを指定するパラメーターはファイルシステムによって異なります。詳細は、ファイルシステムの mkfs man ページを参照してください。たとえば、ext4 ファイルシステムのフォーマット時に使用できるオプションを表示させる場合は次のコマンドを実行します。 
$ man mkfs.ext4
外部ジャーナル
ジャーナリングファイルシステムは、操作を実行する前に、ジャーナルファイルに書き込み操作中に加えられる変更を文書化します。これにより、システムクラッシュや電源異常の発生時にストレージデバイスが破損する可能性が低下し、復旧プロセスが高速化されます。
メタデータ集約型のワークロードでは、ジャーナルへの更新頻度が非常に多くなります。ジャーナルが大きいと、より多くのメモリーを使用しますが、書き込み操作の頻度は低減します。さらに、プライマリーストレージと同じか、それ以上の速度の専用ストレージにジャーナルを配置することで、メタデータ集約型のワークロードでデバイスのシーク時間を短縮できます。
警告
外部ジャーナルが信頼できることを確認します。外部のジャーナルデバイスが失われるとファイルシステムが破損します。
外部ジャーナルは、フォーマット時に作成し、マウント時にジャーナルデバイスを指定する必要があります。詳細は mkfs および mount の man ページを参照してください。 
$ man mkfs
$ man mount

8.1.3.2. マウント時の注意点

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

8.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 呼び出しを使用して、事前割り当てした領域の利点を活用することもできます。