Red Hat Training

A Red Hat training course is available for RHEL 8

GFS2ファイルシステムの設定 (機械翻訳)

Red Hat Enterprise Linux 8

GFS2ファイルシステムの設定と管理の手引き (機械翻訳)

Red Hat Customer Content Services

概要

このガイドはRed Hat Enterprise Linux 8用のGFS2ファイルシステムの設定と管理についての情報を提供します。

Red Hat ドキュメントへのフィードバック (機械翻訳)

ご意見ご要望をお聞かせください。ドキュメントの改善点ございませんか。インストールするには、次を実行します。

  • 特定の文章に簡単なコメントを記入する場合は、ドキュメントが Multi-page HTML 形式になっ ているのを確認してください。コメントを追加する部分を強調表示し、そのテキストの下に表示される Add Feedback ポップアップをクリックし、表示された手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトにアクセスします。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 GFS2ファイルシステムの展開を計画する (機械翻訳)

Red Hat Global File System 2(GFS2)ファイルシステムは、共有名前空間を提供し、共通ブロックデバイスを共有する複数のノード間のコヒーレンシを管理する64ビット対称クラスタファイルシステムです。GFS2ファイルシステムは、ローカルファイルシステムにできるだけ近い機能セットを提供すると同時に、ノード間で完全なクラスタ一貫性を確保することを目的としています。

場合によっては、Linux ファイルシステム API では、GFS2 のクラスター化された性質を完全に透過的にすることができません。たとえば、GFS2 で POSIX ロックを使用しているプログラムは、GETLK の使用を回避する必要があります。なぜなら、クラスター環境では、プロセス ID はクラスター内の別のノードに対するものである可能性があるためです。ただし、ほとんどの場合、GFS2ファイルシステムの機能はローカルファイルシステムの機能と同じです。

Red Hat Enterprise Linux(RHEL)Resilient StorageアドオンはGFS2を提供します。GFS2が必要とするクラスター管理を提供するのはRHEL高可用性アドオンに依存します。

gfs2.ko カーネルモジュールは GFS2 ファイルシステムを実装し、GFS2 クラスターノードにロードされます。

GFS2から最高のパフォーマンスを引き出すには、基礎となる設計から生じるパフォーマンス上の考慮事項を考慮に入れることが重要です。ローカルファイルシステムと同じように、GFS2は頻繁に使用されるデータのローカルキャッシュによってパフォーマンスを向上させるためにページキャッシュに依存しています。クラスター内のノード間で一貫性を維持するために、glock ステートマシンによりキャッシュ制御が提供されます。

重要

Red Hat High Availabilityアドオンのデプロイがニーズを満たしており、サポートできることを確認してください。デプロイの前にあなたの設定を確認するためにRed Hat正規代理店に相談してください。

1.1. 決定する主なGFS2パラメーター (機械翻訳)

GFS2をインストールして設定する前に、GFS2ファイルシステムの次の主な特徴に注意してください。

GFS2ノード
クラスタ内のどのノードがGFS2ファイルシステムをマウントするかを決定します。
ファイルシステム数
最初に作成するGFS2ファイルシステムの数を決定します。より多くのファイルシステムを後で追加することができます。
ファイルシステム名
各ファイルシステムに固有の名前を決めます。名前は、クラスター内のすべてのlock_dlm ファイルシステムで固有にする必要があります。各ファイルシステム名はパラメータ変数の形式で必要です。たとえば、このガイドでの手順では、ファイルシステム名 mydata1 および mydata2 を使用しています。
ジャーナル
GFS2ファイルシステムのジャーナル数を決めます。GFS2では、ファイルシステムをマウントする必要があるクラスター内の各ノードに1つのジャーナルが必要です。たとえば、16ノードのクラスタがあり、2つのノードからファイルシステムのみをマウントする必要がある場合、必要なジャーナルは2つだけです。GFS2 では、追加サーバーがファイルシステムをマウントするため、後で gfs2_jadd ユーティリティーを使用して、ジャーナルを動的に追加できます。
ストレージデバイスとパーティション
ファイルシステムに論理ボリュームを作成するために(CLVMを使用して)使用するストレージデバイスとパーティションを決定します。
タイムプロトコル

GFS2ノードのクロックが同期していることを確認してください。Red Hat Enterprise Linuxディストリビューションに同梱されているPTP(Precision Time Protocol)、または設定に必要な場合はNTP(NTP)ソフトウェアの使用をお勧めします。

GFS2ノードのシステムクロックは、不要なinodeタイムスタンプの更新を防ぐために、互いに数分以内になければなりません。不要な inode のタイムスタンプの更新は、クラスタのパフォーマンスに大きな影響を与えます。

注記

同じディレクトリ内の複数のノードから同時に多数の作成および削除操作が発行されると、GFS2でパフォーマンスの問題が発生することがあります。これがシステムのパフォーマンス上の問題を引き起こすならば、あなたは可能な限りそのノードに特定のディレクトリにノードによってファイルの作成と削除をローカライズするべきです。

1.2. GFS2サポートの考慮事項 (機械翻訳)

表1.1「GFS2サポート制限」 は、GFS2 がサポートする現在の最大ファイルシステムサイズとノード数を要約します。

表1.1 GFS2サポート制限

パラメーター最大

ノード数

16 (x86、PowerVM の Power8)

4 (z/VM の s390x)

ファイルシステムサイズ

サポートされているすべてのアーキテクチャで100G

GFS2は64ビットアーキテクチャに基づいており、理論的には8 EBのファイルシステムに対応できます。現在サポートされているよりも大きいGFS2ファイルシステムがシステムに必要な場合は、Red Hatサービス担当者に連絡してください。

注記

GFS2ファイルシステムはスタンドアロンシステムまたはクラスタ構成の一部として実装できますが、Red HatはGFS2をシングルノードファイルシステムとして使用することをサポートしていません。Red Hatは、シングルノード用に最適化されているため、一般的にクラスターファイルシステムよりもオーバーヘッドが少ない、高性能のシングルノードファイルシステムを多数サポートしています。Red Hatは、単一のノードのみがファイルシステムをマウントする必要がある場合には、GFS2よりもこれらのファイルシステムを使用することをお勧めします。Red Hat Enterprise Linux 8 がサポートするファイルシステムは、Managing file systems を参照してください。

Red Hatは、バックアップなどの目的で必要に応じて、クラスタファイルシステムのスナップショットをマウントするためのシングルノードGFS2ファイルシステムを引き続きサポートします。

ファイルシステムのサイズを決定するときは、リカバリのニーズを考慮する必要があります。大規模なファイルシステムで fsck.gfs2 コマンドを実行すると、時間がかかり、大量のメモリーを消費する可能性があります。さらに、ディスクまたはディスクサブシステムに障害が発生した場合、リカバリ時間はバックアップメディアの速度によって制限されます。fsck.gfs2 コマンドが必要なメモリ容量は、Determing required memory for running fsck.gfs2 を参照してください。

GFS2ファイルシステムはLVMの外部でも使用できますが、Red Hatは共有LVM論理ボリューム上に作成されたGFS2ファイルシステムのみをサポートします。

注記

GFS2ファイルシステムをクラスタファイルシステムとして構成するときは、クラスタ内のすべてのノードが共有ストレージにアクセスできるようにする必要があります。一部のノードが共有ストレージにアクセスし、その他のノードがアクセスできない非対称クラスタ構成はサポートされていません。これは、すべてのノードが実際にGFS2ファイルシステム自体をマウントすることを必要としません。

1.3. GFS2フォーマットの考慮事項 (機械翻訳)

GFS2ファイルシステムでは、クラスタ内の複数のコンピュータ(「ノード」)が共同で同じストレージを共有できます。この協調を達成し、ノード間のデータの一貫性を維持するために、ノードはファイルシステムリソースに対してクラスタ全体のロック方式を採用しています。このロック方式は、TCP / IPなどの通信プロトコルを使用してロック情報を交換します。

このセクションでは、パフォーマンスを最適化するためにGFS2ファイルシステムをフォーマットする方法についての推奨事項を示します。

重要

Red Hat High Availabilityアドオンのデプロイがニーズを満たしており、サポートできることを確認してください。デプロイの前にあなたの設定を確認するためにRed Hat正規代理店に相談してください。

ファイルシステムのサイズ小さいほど良い

GFS2は64ビットアーキテクチャに基づいており、理論的には8 EBのファイルシステムに対応できます。ただし、64ビットハードウェア用のGFS2ファイルシステムの現在サポートされている最大サイズは100TBで、32ビットハードウェア用のGFS2ファイルシステムの現在サポートされている最大サイズは16TBです。

GFS2の大規模ファイルシステムが可能であっても、それが推奨されるわけではないことに注意してください。GFS2の経験則では、小さいほうが優れています。10TBのファイルシステムが1つの場合よりも、1TBのファイルシステムが10個あるほうが良いのです。

GFS2ファイルシステムを小さくしなければならない理由はいくつかあります。

  • 各ファイルシステムのバックアップにかかる時間は短くなります。
  • fsck.gfs2 コマンドを使用してファイルシステムをチェックする必要がある場合は、それほど時間がかかりません。
  • fsck.gfs2 コマンドを使用してファイルシステムをチェックする必要がある場合は、必要なメモリが少なくて済みます。

さらに、維持するリソースグループが少ないほど、パフォーマンスが向上します。

もちろん、GFS2ファイルシステムを小さくしすぎると、スペースが足りなくなる可能性があり、それ自体が影響します。サイズを決める前に、あなたはあなた自身のユースケースを考慮するべきです。

ブロックサイズ:デフォルト(4K)ブロックが優先

mkfs.gfs2 コマンドは、デバイストポロジーに基づいて最適なブロックサイズを推定しようとします。4KがRed Hat Enterprise Linuxのデフォルトのページサイズ(メモリー)であるため、一般的に4Kブロックが推奨ブロックサイズです。他のファイルシステムとは異なり、GFS2はほとんどの操作を4Kカーネルバッファを使って行います。ブロックサイズが4Kの場合、カーネルはバッファを操作するための作業を少なくする必要があります。

最高のパフォーマンスが得られるはずのデフォルトブロックサイズを使用することをお勧めします。非常に小さなファイルを多数効率的に格納する必要がある場合にのみ、異なるブロックサイズを使用する必要があります。

ジャーナルサイズ:デフォルト(128MB)が通常最適

mkfs.gfs2 コマンドを実行して GFS2 ファイルシステムを作成すると、ジャーナルのサイズを指定できます。サイズを指定しないと、デフォルトの128MBになります。これは、ほとんどのアプリケーションに最適です。

システム管理者の中には、128MBが過剰であると考えるかもしれず、ジャーナルのサイズを最低8MBまたはもっと保守的な32MBに減らそうとしたくなるかもしれません。それはうまくいくかもしれませんが、パフォーマンスに深刻な影響を与える可能性があります。多くのジャーナリングファイルシステムと同様に、GFS2がメタデータを書き込むたびに、メタデータはジャーナルに配置される前にコミットされます。これにより、システムがクラッシュまたは停電した場合でも、マウント時にジャーナルが自動的に再生されたときにすべてのメタデータを回復できます。ただし、8MBのジャーナルをいっぱいにするのにファイルシステムのアクティビティはそれほどかかりません。ジャーナルがいっぱいになると、GFS2がストレージへの書き込みを待たなければならないため、パフォーマンスが低下します。

通常、デフォルトのジャーナルサイズ128MBを使用することをお勧めします。ファイルシステムが非常に小さい場合(たとえば5GB)、128MBのジャーナルを用意するのは現実的ではないかもしれません。あなたがもっと大きなファイルシステムを持っていて、スペースを空けることができるならば、256MBジャーナルを使うことはパフォーマンスを改善するかもしれません。

リソースグループのサイズと数

mkfs.gfs2 コマンドで GFS2 ファイルシステムを実行すると、ストレージが、リソースグループと呼ばれる均一なスライスに分割されます。最適なリソースグループサイズ(32MBから2GBまで)の見積もりを試みます。mkfs.gfs2 コマンドの -r オプションを使用してデフォルトを上書きできます。

最適なリソースグループサイズは、ファイルシステムの使用方法によって異なります。それがどのくらいいっぱいになるか、それがひどく断片化されるかどうかを検討してください。

最適なパフォーマンスが得られる結果を確認するには、さまざまなサイズのリソースグループを試してみてください。GFS2を完全運用に展開する前に、テストクラスターを試すことをお勧めします。

ファイルシステムに非常に多くのリソースグループがあり、それぞれが小さすぎる場合、ブロック割り当てで空きブロックを探すために何万ものリソースグループを検索するのに時間がかかりすぎることがあります。ファイルシステムがいっぱいになればなるほど、検索されるリソースグループが増え、それらすべてにクラスタ全体のロックが必要になります。これによりパフォーマンスが低下します。

ただし、ファイルシステムに含まれるリソースグループの数が少なすぎる(それぞれが大きすぎる)場合、同じリソースグループロックに対してブロック割り当てが競合する可能性があり、これもパフォーマンスに影響します。たとえば、10GBのファイルシステムが2GBの5つのリソースグループに分割されている場合、同じファイルシステムが32MBの320のリソースグループに分割されている場合よりも、クラスタ内のノードがそれら5つのリソースグループを争います。ファイルシステムがほぼいっぱいになると、空きブロックを持つリソースグループが見つかる前に、すべてのブロック割り当てで複数のリソースグループを調べる必要があるため、問題はさらに悪化します。GFS2は2つの方法でこの問題を軽減しようとします。

  • まず、リソースグループが完全に一杯になると、それが記憶され、ブロックが解放されるまで将来の割り当てをチェックしないようにします。ファイルを削除したことがなければ、競合はそれほど深刻ではなくなります。ただし、アプリケーションが常にいっぱいになっているファイルシステムでブロックを削除して新しいブロックを割り当てていると、競合が非常に多くなり、パフォーマンスに深刻な影響を与えます。
  • 次に、新しいブロックが既存のファイルに追加されると(たとえば追加によって)、GFS2は新しいブロックをファイルと同じリソースグループにまとめようとします。これはパフォーマンスを向上させるために行われます。回転しているディスクでは、シーク操作が物理的に接近しているときの時間が短くなります。

最悪のシナリオは、すべてのノードが絶えず同じリソースグループをロックしようと戦うため、すべてのノードがファイルを作成する中央ディレクトリがある場合です。

1.4. クラスタの考慮事項 (機械翻訳)

システムに含めるノード数を決定する際には、高可用性とパフォーマンスの間にはトレードオフがあることに注意してください。ノード数が増えると、ワークロードを拡張することがますます困難になります。そのため、Red Hatは、16ノードを超えるクラスターファイルシステムの導入にGFS2を使用することをサポートしていません。

クラスタファイルシステムの配備は、単一ノード配備の「ドロップイン」代替ではありません。Red Hatは、システムをテストし、システムが必要なパフォーマンスレベルで動作していることを確認するために、新規インストールで約8〜12週間のテスト期間を許可することをお勧めします。この間に、パフォーマンスや機能の問題を解決したり、問い合わせをRed Hatサポートチームに送信したりする必要があります。

Red Hatは、クラスターの展開を検討しているお客様は、サポートの問題が発生する可能性を回避するために、展開前にRed Hatサポートによる構成の確認を受けることをお勧めします。

1.5. ハードウェアの考慮事項 (機械翻訳)

GFS2ファイルシステムを配備するときは、次のハードウェアの考慮事項を考慮に入れる必要があります。

  • 高品質のストレージオプションを使用する

    GFS2は、iSCSIやFCoE(Fibre Channel over Ethernet)などの安価な共有ストレージオプションで動作できますが、キャッシュ容量の大きい高品質のストレージを購入するとパフォーマンスが向上します。Red Hatは、ファイバーチャネル相互接続を使用して、SANストレージでほとんどの品質テスト、健全性テスト、およびパフォーマンステストを実行します。原則として、最初にテストされたものをデプロイすることをお勧めします。

  • 展開前にネットワーク機器をテストする

    高品質で高速なネットワーク機器は、クラスター通信とGFS2をより高い信頼性でより高速に実行します。ただし、最も高価なハードウェアを購入する必要はありません。最も高価なネットワークスイッチの中には、マルチキャストパケットの受け渡しに問題があるものがあります。これは、fcntl ロック (flock) に渡すために使用されます。一方、安価なコモディティネットワークスイッチは、高速で信頼性が高い場合があります。Red Hatは、本格的な運用に導入する前に機器を試すことを推奨します。

第2章 GFS2の使用に関する推奨事項 (機械翻訳)

このセクションではGFS2の使用に関する一般的な推奨事項を説明します。

2.1. マウントオプション:noatimeとnodiratime (機械翻訳)

一般的には、noatime 引数および nodiratime 引数で GFS2 ファイルシステムをマウントすることをお勧めします。これにより、GFS2 は、アクセスごとにディスクの inode の更新にかかる時間を短縮できます。GFS2 ファイルシステムのパフォーマンスに対するこれらの引数の影響は、GFS2 Node Locking を参照してください。

2.2. atime 更新の設定 (機械翻訳)

各ファイルの inode と、ディレクトリーの inode には、3 つのタイムスタンプが関連付けられています。

  • ctime - inode ステータスが最後に変更された日時
  • mtime - ファイル(またはディレクトリ)データが最後に変更された日時
  • atime - ファイル(またはディレクトリ)データが最後にアクセスされた日時

デフォルトで GFS2 などの Linux ファイルシステムにあるため、atime 更新が有効な場合は、ファイルが読み込まれるたびにその inode を更新する必要があります。

ほとんどのアプリケーションは、atime により提供される情報を使用するため、これらの更新では、大量の不要な書き込みトラフィックとファイルロックトラフィックが必要になる可能性があります。そのトラフィックは、パフォーマンスを低下させる可能性があります。したがって、電源を切るか、atime 更新頻度を減らす場合があります。

atime 更新の影響を軽減する 2 つの方法が利用できます。

  • relatime (relative atime) でマウントします。これは、以前の atime 更新プログラムが mtime または ctime の更新より古い場合に、atime を更新します。
  • noatime でマウントします。これは、そのファイルシステムで atime の更新を無効にします。

relatime でマウントします。

ファイルシステムのマウント時に、Linux マウントオプション relatime (relative atime) を指定できます。これにより、前の atime 更新が、mtime または ctime より古い場合に atime が更新されるのが指定されます。使用法

mount  BlockDevice MountPoint -o relatime
BlockDevice
GFS2ファイルシステムが存在するブロックデバイスを指定します。
MountPoint
GFS2ファイルシステムをマウントするディレクトリを指定します。

この例では、GFS2 ファイルシステムは /dev/vg01/lvol0 に配置され、/mygfs2 にマウントされます。atime 更新が行われるのは、前の atime 更新が、mtime または ctime 更新よりも古い場合のみです。

# mount /dev/vg01/lvol0 /mygfs2 -o relatime

noatime でマウントします。

ファイルシステムがマウントされる場合に、Linux マウントオプション noatime を指定できます。そのファイルシステムで atime 更新を無効にします。使用法

mount BlockDevice MountPoint -o noatime
BlockDevice
GFS2ファイルシステムが存在するブロックデバイスを指定します。
MountPoint
GFS2ファイルシステムをマウントするディレクトリを指定します。

この例では、GFS2 ファイルシステムは /dev/vg01/lvol0 に配置され、atime 更新が無効になった状態で、/mygfs2 ディレクトリーにマウントされます。

# mount /dev/vg01/lvol0 /mygfs2 -o noatime

2.3. VFS調整オプション:研究と実験 (機械翻訳)

すべてのLinuxファイルシステムと同様に、GFS2は仮想ファイルシステム(VFS)と呼ばれる層の最上位に位置しています。sysctl(8) コマンドを使用して、VFS レイヤーを調整し、基になる GFS2 のパフォーマンスを向上させることができます。たとえば、dirty_background_ratio および vfs_cache_pressure の値を、状況に応じて調整できます。現在の値を取得するには、以下のコマンドを使用してください。

# sysctl -n vm.dirty_background_ratio
# sysctl -n vm.vfs_cache_pressure

次のコマンドは値を調整します。

# sysctl -w vm.dirty_background_ratio=20
# sysctl -w vm.vfs_cache_pressure=500

/etc/sysctl.conf ファイルを編集して、これらのパラメーターの値を恒久的に変更できます。

ユースケースに最適な値を見つけるには、さまざまなVFSオプションを調べ、テストクラスタで実験してから本番運用に展開します。

2.4. GFS2上のSELinux (機械翻訳)

GFS2でSecurity Enhanced Linux(SELinux)を使用すると、パフォーマンスがわずかに低下します。このオーバーヘッドを回避するために、SELinuxが強制モードになっているシステムであっても、GFS2でSELinuxを使用しないことを選択できます。GFS2 ファイルシステムをマウントするとき、man ページの mount(8) で説明されているように、context オプションのいずれかを使用して、各ファイルシステムオブジェクトで SELinux が seclabel 要素を読もうとしないようにすることができます。SELinux は、ファイルシステム内のすべてのコンテンツを、context マウントオプションで提供される seclabel 要素でラベルを付けます。これは、seclabel 要素が含まれている可能性がある拡張属性ブロックの別のディスク読み取りを回避するため、処理速度が速くなります。

たとえば、SELinux が強制モードになっているシステムで、ファイルシステムに Apache コンテンツが含まれる場合は、次の mount コマンドを使用して GFS2 ファイルシステムをマウントできます。このラベルはファイルシステム全体に適用されます。それはメモリ内に残り、ディスクには書き込まれません。

# mount -t gfs2 -o context=system_u:object_r:httpd_sys_content_t:s0 /dev/mapper/xyz/mnt/gfs2

ファイルシステムに Apache コンテンツが含まれるかどうかわからない場合は、public_content_rw_t ラベルまたは public_content_t ラベルを使用するか、新しいラベルをまとめて定義し、それに関するポリシーを定義することもできます。

Pacemakerクラスタでは、GFS2ファイルシステムを管理するために常にPacemakerを使用する必要があります。GFS2ファイルシステムリソースを作成するときにマウントオプションを指定できます。

2.5. GFS2によるNFSの設定 (機械翻訳)

GFS2ロッキングサブシステムの複雑さとそのクラスタ化された性質により、GFS2上でNFSを設定するには、多くの注意と慎重な設定が必要です。このセクションでは、GFS2ファイルシステム上でNFSサービスを構成する際に考慮すべき注意事項について説明します。

警告

GFS2 ファイルシステムが NFS でエクスポートされていて、NFS クライアントアプリケーションが POSIX ロックを使用している場合は、localflocks オプションでファイルシステムをマウントする必要があります。この効果は、各サーバからのPOSIXロックとフロックの両方をローカルにすることです(クラスタ化されていない、互いに独立している)。GFS2がクラスターのノード間でNFSからPOSIXロックを実装しようとすると多くの問題が存在するため、これは必要です。NFSクライアントで実行されているアプリケーションの場合、ローカライズされたPOSIXロックは、2つのクライアントが異なるサーバーからマウントされている場合、2つのクライアントが同時に同じロックを保持できることを意味します。このため、GFS2 上で NFS を使用する場合は、-o localflocks マウントオプションを指定するのが常に一番安全となります。これにより、NFS がマウントするすべてのクライアント間で POSIX ロックと flock の両方を NFS が調整できるようになります。

他の (非 NFS) GFS2アプリケーションの場合は、localflocks を使用してファイルシステムをマウントしないでください。これにより、GFS2 はクラスター内のすべてのノード間の POSIX ロックおよび flock を (クラスター全体で) 管理します。localflocks を指定し、NFS を使用しない場合、クラスター内の他のノードは、互いの POSIX ロックおよび flock に関する情報がないため、クラスタ環境では安全ではありません。

ロックの考慮事項に加えて、GFS2ファイルシステム上でNFSサービスを構成するときには、次の点を考慮する必要があります。

  • Red Hatは、NFSv3を使用したRed Hat High Availabilityアドオン構成のみをサポートします。アクティブ/パッシブ構成では、次のような特徴があります。

    • バックエンドファイルシステムは、2から16ノードのクラスターで実行されているGFS2ファイルシステムです。
    • NFSv3サーバーは、一度に1つのクラスターノードからGFS2ファイルシステム全体をエクスポートするサービスとして定義されています。
    • NFSサーバーは、あるクラスターノードから別のクラスターノードにフェイルオーバーできます(アクティブ/パッシブ構成)。
    • NFS サーバー経由を除いて、GFS2 ファイルシステムへのアクセスは許可されていません。これには、ローカルGFS2ファイルシステムへのアクセスと、SambaまたはClustered Sambaを介したアクセスの両方が含まれます。
    • システムにNFSクォータのサポートはありません。

      この構成では、ファイルシステムに高可用性 (HA) が提供され、システムの停止時間が短縮されます。失敗したノードが、あるノードから別のノードへの NFS サーバーに障害が発生したときに、fsck コマンドを実行するための要件にはなないためです。

  • fsid= NFSオプションはGFS2のNFSエクスポートに必須です。
  • クラスターに問題が発生した場合(例えば、クラスターが不適切になってフェンシングが成功しなかった場合)、クラスター化論理ボリュームとGFS2ファイルシステムは凍結され、クラスターが定足数になるまでアクセスできません。この手順で定義したような単純なフェールオーバーソリューションがシステムに最も適しているかどうかを判断するときには、この可能性を考慮する必要があります。

2.6. GFS2を介したSamba(SMBまたはWindows)ファイルサービス (機械翻訳)

CTDBでGFS2ファイルシステムからSamba(SMBまたはWindows)ファイルサービングを使用できます。これにより、アクティブ/アクティブ構成が可能になります。

Sambaの外部からSamba共有内のデータへの同時アクセスはサポートされていません。Sambaファイルの提供が遅くなるGFS2クラスタリースは現在サポートされていません。

2.7. GFS2用の仮想マシンの構成 (機械翻訳)

仮想マシンでGFS2ファイルシステムを使用する場合、キャッシュを強制的にオフにするために各ノードのVMストレージ設定を正しく構成することが重要です。たとえば、libvirt ドメインで cache および io の設定を追加すると、GFS2 が期待通りに動作できるようになります。

<driver name='qemu' type='raw' cache='none' io='native'/>

代わりに、デバイス要素に shareable を設定できます。これは、デバイスがドメイン間で共有されることが期待されることを示します(ハイパーバイザーとOSがこれをサポートしている限り)。shareable が使用されている場合は、そのデバイスに cache='no' を使用する必要があります。

2.8. ブロック割り当て (機械翻訳)

このセクションでは、GFS2ファイルシステムのブロック割り当てに関連する問題の概要を説明します。データを書き込むだけのアプリケーションでは、通常、ブロックの割り当て方法や割り当て場所を気にする必要はありませんが、ブロック割り当ての仕組みに関するある程度の知識があれば、パフォーマンスの最適化に役立ちます。

2.8.1. ファイルシステムに空き領域を残す (機械翻訳)

GFS2ファイルシステムがほぼいっぱいになると、ブロックアロケータは新しいブロックを割り当てるスペースを見つけるのに苦労し始めます。その結果、アロケータによって割り当てられたブロックは、リソースグループの最後、またはファイルの断片化がはるかに起こりやすい小さなスライスに押し込まれる傾向があります。このファイルの断片化はパフォーマンスの問題を引き起こす可能性があります。さらに、GFS2ファイルシステムがほぼいっぱいになると、GFS2ブロックアロケータは複数のリソースグループを検索するのにより多くの時間を費やすため、十分な空き容量があるファイルシステムでは必ずしもロック競合が発生しません。これもパフォーマンスの問題を引き起こす可能性があります。

これらの理由から、85%を超えるファイルシステムを実行しないことをお勧めします。ただし、この数値はワークロードによって異なる場合があります。

2.8.2. 可能であれば、各ノードに独自のファイルを割り当てさせる (機械翻訳)

GFS2ファイルシステムで使用するアプリケーションを開発するときは、可能であれば、各ノードに独自のファイルを割り当てることをお勧めします。分散ロックマネージャ(DLM)の動作方法のため、すべてのファイルが1つのノードによって割り当てられ、他のノードがそれらのファイルにブロックを追加する必要がある場合は、さらにロック競合が発生します。

DLMでは、リソース(ファイルなど)を最初にロックしたノードがそのロックの「ロックマスター」になります。他のノードはそのリソースをロックするかもしれませんが、それらは最初にロックマスターから許可を求めなければなりません。各ノードは、どのマスターがロックマスターであるかを認識しており、各ノードは、どのノードにロックを貸しているのかを認識しています。マスターノードでロックをロックすることは、ロックを停止してロックのマスターから許可を得なければならない別のノードでロックするよりもはるかに高速です。

多くのファイルシステムと同様に、GFS2アロケータは、ディスクヘッドの移動を減らしてパフォーマンスを向上させるために、同じファイル内のブロックを互いに近くに配置しようとします。ブロックをファイルに割り当てるノードは、新しいブロックに対して同じリソースグループを使用してロックする必要があるでしょう(そのリソースグループ内のすべてのブロックが使用中でない限り)。ファイルを含むリソースグループのロックマスターがデータブロックを割り当てると、ファイルシステムはより速く動作します(最初にファイルを開いたノードにすべての新しいブロックの書き込みを行わせる方が速い)。

2.8.3. 可能であれば事前割り当て (機械翻訳)

ファイルが事前に割り当てられている場合は、ブロック割り当てを完全に回避でき、ファイルシステムをより効率的に実行できます。GFS2には、fallocate(1) システムコールが含まれます。これにより、事前割り当てのデータブロックを使用できます。

第3章 GFS2ファイルシステム (機械翻訳)

このセクションでは、GFS2ファイルシステムの作成、マウント、および拡張に使用するコマンドとオプションについて説明します。

3.1. GFS2ファイルシステムの作成 (機械翻訳)

mkfs.gfs2 コマンドで、GFS2 ファイルシステムを作成できます。アクティブ化されたLVMボリューム上にファイルシステムが作成されます。

3.1.1. GFS2のmkfsコマンド (機械翻訳)

mkfs.gfs2 コマンドを実行するには、クラスター化 GFS2 ファイルシステムを作成するコマンドを実行する必要があります。

  • ロックプロトコル/モジュール名 (クラスターの lock_dlm)
  • クラスタ名
  • ジャーナル数(ファイルシステムをマウントする可能性がある各ノードに1つのジャーナルが必要)
注記

mkfs.gfs2 コマンドで GFS2 ファイルシステムを作成したら、ファイルシステムのサイズを縮小することはできません。ただし、gfs2_grow コマンドで、既存のファイルシステムのサイズを大きくすることができます。

クラスター化GFS2ファイルシステムを作成するためのフォーマットは次のとおりです。Red HatはGFS2のシングルノードファイルシステムとしての使用をサポートしていません。

mkfs.gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

お望みであれば、mkfs コマンドを使用して GFS2 ファイルシステムを作成できます。そのとき、-t パラメーターで、gfs2 タイプのファイルシステムを指定し、その後に GFS2 ファイルシステムオプションを指定します。

mkfs -t gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice
警告

ClusterName:FSName パラメーターが適切でないと、ファイルシステムまたはロック領域が破損する可能性があります。

ClusterName
GFS2ファイルシステムが作成されているクラスターの名前。
FSName
ファイルシステム名。長さは1〜16文字です。名前は、クラスター内のすべての lock_dlm ファイルシステムで固有にする必要があります。
NumberJournals
mkfs.gfs2 コマンドにより作成されるジャーナルの数を指定します。ファイルシステムをマウントするノードごとに1つのジャーナルが必要です。GFS2ファイルシステムの場合は、ファイルシステムを拡張せずに後でさらにジャーナルを追加できます。
BlockDevice
論理または他のブロックデバイスを指定します

表3.1「コマンドオプション: mkfs.gfs2 で、mkfs.gfs2 コマンドオプション (フラグおよびパラメーター) を説明します。

表3.1 コマンドオプション: mkfs.gfs2

フラグパラメーター説明

-c

Megabytes

各ジャーナルのクォータ変更ファイルの初期サイズを Megabytes に設定します。

-D

 

デバッグ出力を有効にします。

-h

 

ヘルプ。利用可能なオプションを表示します。

-J

Megabytes

ジャーナルのサイズをメガバイト単位で指定します。デフォルトのジャーナルサイズは128メガバイトです。最小サイズは8メガバイトです。ジャーナルが大きいほどパフォーマンスが向上しますが、ジャーナルが小さい場合よりも多くのメモリーを使用します。

-j

Number

mkfs.gfs2 コマンドにより作成されるジャーナルの数を指定します。ファイルシステムをマウントするノードごとに1つのジャーナルが必要です。このオプションを指定しないと、ジャーナルが1つ作成されます。GFS2ファイルシステムの場合は、ファイルシステムを増やすことなく、後でジャーナルを追加することができます。

-O

 

mkfs.gfs2 コマンドが、ファイルシステムに書き込む前に確認を求めないようにします。

-p

LockProtoName

*使用するロックプロトコルの名前を指定します。認識されているロックプロトコルは次のとおりです。

* lock_dlm - クラスタファイルシステムに必要な標準のロックモジュール。

* lock_nolock - GFS2がローカルファイルシステムとして動作している場合に使用します(1ノードのみ)。

-q

 

静か。何も表示しません。

-r

Megabytes

リソースグループのサイズをメガバイト単位で指定します。最小リソースグループサイズは32メガバイトです。最大リソースグループサイズは2048メガバイトです。大きなリソースグループサイズは、非常に大きなファイルシステムでパフォーマンスを向上させる可能性があります。これが指定されていない場合は、mkfs.gfs2 が、ファイルシステムのサイズに基づいてリソースグループのサイズを選択します。平均サイズのファイルシステムは 256 メガバイトのリソースグループを持ち、大きいファイルシステムはパフォーマンスを向上させるために、リソースグループがより大きくなります。

-t

LockTableName

* lock_dlm プロトコルを使用する場合にロックテーブルフィールドを指定する一意の識別子。lock_nolock プロトコルは、このパラメータを使用しません。

*このパラメータは、次のようにコロン(スペースなし)で区切られた2つの部分に分かれています。 ClusterName:FSName

* ClusterName GFS2ファイルシステムが作成されているクラスターの名前です。このクラスタのメンバーだけがこのファイルシステムを使用できます。

* FSName, ファイルシステム名は、1から16文字の長さにすることができ、名前はクラスター内のすべてのファイルシステムの中で固有でなければなりません。

-V

 

コマンドのバージョン情報を表示します。

3.1.2. GFS2ファイルシステムの作成 (機械翻訳)

次の例では、2つのGFS2ファイルシステムを作成します。どちらのファイルシステムでも、lock_dlm`はファイルシステムが使用するロックプロトコルです。これはクラスタ化されたファイルシステムであるためです。両方のファイルシステムは、alpha という名前のクラスターで使用できます。

最初のファイルシステムの場合、ファイルシステム名は mydata1 です。8 個のジャーナルが含まれ、/dev/vg01/lvol0 に作成されます。2 番目のファイルシステムの場合、ファイルシステム名は mydata2 になります。8 個のジャーナルが含まれ、/dev/vg01/lvol1 に作成されます。

# mkfs.gfs2 -p lock_dlm -t alpha:mydata1 -j 8 /dev/vg01/lvol0
# mkfs.gfs2 -p lock_dlm -t alpha:mydata2 -j 8 /dev/vg01/lvol1

3.2. GFS2ファイルシステムのマウント (機械翻訳)

注記

mount を使用して、手動でファイルシステムをマウントするのではなく、本番環境で GFS2 ファイルシステムを管理するには、常に Pacemaker を使用する必要があります。手動でマウントすると、Unmounting a GFS2 file system に記載されているように、システムのシャットダウン時に問題が発生する可能性があるためです。

GFS2ファイルシステムをマウントする前に、ファイルシステムが存在し、ファイルシステムが存在するボリュームをアクティブにし、サポートしているクラスタリングとロックシステムを起動する必要があります。これらの要件が満たされたら、他のLinuxファイルシステムと同じようにGFS2ファイルシステムをマウントできます。

ファイルのACLを操作するには、-o acl を使用して、次のようにしてファイルシステムをマウントする必要があります。ファイルシステムが -o acl を使用せずにマウントされている場合は、(getfacl で) ACL を表示できますが、(setfacl で) それを設定することはできません。

3.2.1. オプションを指定せずにGFS2ファイルシステムをマウントする (機械翻訳)

この例では、/dev/vg01/lvol0 の GFS2 ファイルシステムは、/mygfs2 ディレクトリーにマウントされています。

# mount /dev/vg01/lvol0 /mygfs2

マウントオプションを指定したGFS2ファイルシステムをマウントするコマンドの形式は次のとおりです。

mount BlockDevice MountPoint -o option
BlockDevice
GFS2ファイルシステムが存在するブロックデバイスを指定します。
MountPoint
GFS2ファイルシステムをマウントするディレクトリを指定します。

-o option 引数は、GFS2 固有のオプション (表3.2「GFS2固有のマウントオプション」 を参照)、または許容できる標準の Linux mount -o オプション、もしくはその両方の組み合わせで構成されています。複数の option パラメーターはカンマで区切り、スペースは入れません。

注記

mount コマンドは、Linux のシステムコマンドです。本セクションで説明されている GFS2 固有のオプション以外に、その他の標準の mount コマンドオプション (-r など) を使用できます。その他の Linux mount コマンドオプションは、Linux mount の man ページを参照してください。

表3.2「GFS2固有のマウントオプション」 は、マウント時に GFS2 に渡すことができる、利用可能な GFS2 固有の -o option 値を説明します。

注記

この表には、ローカルファイルシステムでのみ使用されるオプションの説明が含まれています。ただし、Red HatはGFS2のシングルノードファイルシステムとしての使用をサポートしていません。Red Hatは、クラスターファイルシステムのスナップショットをマウントするためのシングルノードGFS2ファイルシステムのサポートを継続します(バックアップ目的など)。

表3.2 GFS2固有のマウントオプション

オプション説明

acl

ファイルのACLを操作することを許可します。ファイルシステムが acl を使用せずにマウントされている場合は、(getfacl で) ACL を表示できますが、(setfacl で) それを設定することはできません。

data=[ordered|writeback]

data=ordered が設定されている場合、トランザクションにより変更されたユーザーデータは、トランザクションがディスクにコミットされる前にディスクにフラッシュされます。これにより、クラッシュ後にファイル内の初期化されていないブロックがユーザーに表示されなくなります。data=writeback モードが設定されている場合は、データがダーティになるとディスクに書き込まれます。これは、ordered と同じような一貫性保証は行わないため、ワークロードによって少し速くなります。デフォルト値は ordered モード。

* ignore_local_fs

* Caution: このオプションは、GFS2 ファイルシステムを共有しているときは使用すべき ではありません

GFS2にファイルシステムをマルチホストファイルシステムとして処理させます。デフォルトでは、localflocks フラグで、lock_nolockの使用が自動的に有効になります。

* localflocks

* Caution: GFS2ファイルシステムが共有されている場合は、このオプションを使用しないでください。

GFS2にVFS(仮想ファイルシステム)層にすべてのflockとfcntlを実行させるように指示します。lock_nolock フラグは、localflocks により自動的にオンになります。

lockproto=LockModuleName

ユーザーがファイルシステムで使用するロックプロトコルを指定できるようにします。LockModuleName 指定しない場合、ロックプロトコル名は、ファイルシステムのスーパーブロックから読み取られます。

locktable=LockTableName

ユーザーがファイルシステムで使用するロックテーブルを指定できるようにします。

quota=[off/account/on]

ファイルシステムのクォータをオンまたはオフにします。クォータを account 状態に設定すると、各 UID または GID の使用統計がファイルシステムによって正しく管理され、limit と warn の値は無視されます。デフォルト値は off です。

errors=panic|withdraw

errors=panic を指定すると、ファイルシステムのエラーによりカーネルパニックが発生します。errors=withdraw を指定 (デフォルトの動作) は、ファイルシステムエラーによりシステムはファイルシステムから撤退し、次回の再起動までアクセスできなくなります。場合によっては、システムは稼働したままになります。

discard/nodiscard

解放されたブロックに対してGFS2に「廃棄」入出力要求を生成させます。これらは、シンプロビジョニングおよび同様の方式を実装するために適切なハードウェアで使用できます。

barrier/nobarrier

ジャーナルをフラッシュするときにGFS2に入出力バリアを送信させます。デフォルト値は on です。基礎となるデバイスが I/O バリアをサポートしていない場合、このオプションは自動的に offになります。GFS2でのI / Oバリアの使用は、ブロックデバイスがライトキャッシュの内容を失うことがないように設計されていない限り(たとえば、UPS上にある場合やライトキャッシュがない場合など)、常に強くお勧めします。

quota_quantum=secs

クォータ情報の変更がクォータファイルに書き込まれるまでに1つのノードに存在する秒数を設定します。これはこのパラメータを設定するのに推奨される方法です。値は、ゼロより大きい整数の秒数です。デフォルトは60秒です。設定を短くすると、レイジークォータ情報の更新が速くなり、誰かがクォータを超える可能性が少なくなります。設定を長くすると、クォータを含むファイルシステムの操作がより速く効率的になります。

statfs_quantum=secs

statfsを遅いバージョンに設定するには、statfs_quantum を 0 に設定することを推奨します。デフォルト値は 30 秒で、statfs 変更がマスターの statfs ファイルにに同期されるまでの最大期間を設定します。これは、statfsを、速いが正確さが劣る、もしくは遅いが正確さが上げるように調整できます。このオプションを 0 に設定すると、statfs は、常に true 値を報告します。

statfs_percent=value

その期間が経過していなくても、マスターの statfsに同期するまでの、ローカルベースでのstatfs情報の最大変化率の上限を設定します。statfs_quantum の設定が 0 の場合、この設定は無視されます。

3.2.2. GFS2ファイルシステムのマウント解除 (機械翻訳)

Pacemakerを使用して自動的にではなく手動でマウントされたGFS2ファイルシステムは、システムのシャットダウン時にファイルシステムがマウント解除されたときにシステムに認識されません。その結果、GFS2リソースエージェントはGFS2ファイルシステムをマウント解除しません。GFS2リソースエージェントがシャットダウンされた後、標準のシャットダウンプロセスはクラスタインフラストラクチャを含む残りのすべてのユーザープロセスを強制終了し、ファイルシステムのマウント解除を試みます。このアンマウントはクラスタインフラストラクチャがないと失敗し、システムがハングします。

GFS2ファイルシステムがマウント解除されたときにシステムがハングアップしないようにするには、次のいずれかを実行する必要があります。

  • GFS2ファイルシステムの管理には、常にPacemakerを使用してください。
  • GFS2 ファイルシステムが、mount コマンドを使用して手動でマウントされている場合は、システムを再起動またはシャットダウンする前に umountコマンドを使用して、そのファイルシステムを手動でアンマウントします。

このような状況で、システムのシャットダウン中にマウント解除中にファイルシステムがハングアップした場合は、ハードウェアの再起動を実行してください。ファイルシステムはシャットダウンプロセスの早い段階で同期されるため、データが失われることはほとんどありません。

GFS2 ファイルシステムは、umount コマンドを使用して、他の Linux ファイルシステムと同じ方法でマウント解除できます。

注記

umount コマンドは、Linux のシステムコマンドです。このコマンドに関する情報は、Linux umount コマンドの man ページを参照してください。

使用法

umount MountPoint
MountPoint
GFS2ファイルシステムが現在マウントされているディレクトリを指定します。

3.3. GFS2ファイルシステムのバックアップ (機械翻訳)

ファイルシステムのサイズに関係なく、緊急の場合にはGFS2ファイルシステムの定期的なバックアップを作成することが重要です。多くのシステム管理者は、RAID、マルチパス、ミラーリング、スナップショット、およびその他の冗長性によって保護されているため安全だと感じていますが、それほど安全なことはありません。

ノードまたはノードのセットをバックアップするプロセスでは、通常、ファイルシステム全体を順番に読み取る必要があるため、バックアップを作成するのは問題になる可能性があります。これが単一のノードから行われた場合、そのノードは、クラスタ内の他のノードがロックの要求を開始するまで、すべての情報をキャッシュに保持します。クラスターの稼働中にこのタイプのバックアッププログラムを実行すると、パフォーマンスに悪影響があります。

バックアップが完了した後でキャッシュを削除すると、他のノードがクラスタのロック/キャッシュの所有権を取り戻すのに必要な時間が短縮されます。ただし、バックアッププロセスが開始される前に他のノードがキャッシュしていたデータのキャッシュを他のノードが停止しているため、これはまだ理想的ではありません。バックアップが完了したら、次のコマンドを使用してキャッシュを削除できます。

echo -n 3 > /proc/sys/vm/drop_caches

タスクがノード間で分割されるように、クラスター内の各ノードが独自のファイルをバックアップすると、より高速になります。これは、ノード固有のディレクトリーに rsyncコマンドを使用するスクリプトで実現できます。

Red Hatは、SAN上にハードウェアスナップショットを作成し、そのスナップショットを別のシステムに提示してそこにバックアップすることによってGFS2バックアップを作成することをお勧めします。バックアップシステムは、クラスターには含まれないため、-o lockproto=lock_nolockで、スナップショットを次のようにマウントします。

3.4. GFS2ファイルシステムでのアクティビティの中断 (機械翻訳)

ファイルシステムへの書き込み動作を一時停止するには、dmsetup suspend コマンドを使用します。書き込みアクティビティを中断すると、ハードウェアベースのデバイススナップショットを使用してファイルシステムを一貫した状態でキャプチャできます。の dmsetup resume コマンドは中断を終了します。

GFS2ファイルシステムの動作を一時停止するコマンドの形式は次のとおりです。

dmsetup suspend MountPoint

この例では、ファイルシステム /mygfs2への書き込みを中断します。

# dmsetup suspend /mygfs2

GFS2ファイルシステムの運用一時停止コマンドの形式は、以下のとおりです。

dmsetup resume MountPoint

この例では、ファイルシステム /mygfs2への書き込みの中断を終了します。

# dmsetup resume /mygfs2

3.5. GFS2ファイルシステムの拡大 (機械翻訳)

gfs2_grow コマンドは、ファイルシステムが存在するデバイスが拡張された後にGFS2ファイルシステムを拡張するために使用されます。既存の GFS2 ファイルシステムで gfs2_grow コマンドを実行すると、ファイルシステムの現在の末尾とデバイスの末尾の間にあるすべてのスペアスペースが、新しく初期化された GFS2 ファイルシステム拡張子で埋められます。クラスタ内のすべてのノードは、追加された追加の記憶領域を使用できます。

注記

GFS2ファイルシステムのサイズを縮小することはできません。

gfs2_grow コマンドはマウントされたファイルシステムで実行する必要があります。次の手順では、/mnt/gfs2の マウントポイントで、論理ボリューム shared_vg/shared_lv1にマウントされているクラスター内の GFS2 ファイルシステムのサイズを大きくします。

  1. ファイルシステム上のデータのバックアップを実行します。
  2. 拡張するファイルシステムに使用されている論理ボリュームがわからない場合は、df mountpoint コマンドを実行して確認できます。これにより、デバイス名が次の形式で表示されます。

    /dev/mapper/vg-lv

    たとえば、デバイス名 /dev/mapper/shared_vg-shared_lv1 論理ボリュームが shared_vg/shared_lv1

  3. クラスターのノードの 1つで、基になるクラスターボリュームを、--lockopt skiplv オプションを付けた lvextend コマンドで拡張し、通常の論理ボリュームロックを無効にします。

    # lvextend --lockopt skiplv -L+1G shared_vg/shared_lv1
    WARNING: skipping LV lock in lvmlockd.
    Size of logical volume shared_vg/shared_lv1 changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).
    Logical volume shared_vg/shared_lv1 successfully resized.
  4. クラスターのすべての追加ノードで、論理ボリュームをリフレッシュしてそのノード上のアクティブな論理ボリュームを更新します。

    注記

    追加の各クラスタノードでこの手順を実行しないと、クラスタ全体でデータが利用できなくなる可能性があります。

    # lvchange --refresh shared_vg/shared_lv1
  5. クラスタの1つのノード、GFS2ファイルシステムのサイズを増やします。

    # gfs2_grow /mnt/gfs2
    FS: Mount point:             /mnt/gfs2
    FS: Device:                  /dev/mapper/shared_vg-shared_lv1
    FS: Size:                    1310719 (0x13ffff)
    DEV: Length:                 1572864 (0x180000)
    The file system will grow by 1024MB.
    gfs2_grow complete.
  6. すべてのノードで df コマンドを実行して、新しいスペースがファイルシステムで使用可能になったことを確認します。すべてのノードに df コマンドを実行して同じファイルシステムサイズを表示するには、最大 30 秒かかることに注意してください。

    # df -h /mnt/gfs2
    Filesystem                        Size  Used Avail Use% Mounted on
    /dev/mapper/shared_vg-shared_lv1  6.0G  4.5G  1.6G  75% /mnt/gfs2

3.6. GFS2ファイルシステムへのジャーナルの追加 (機械翻訳)

GFS2では、ファイルシステムをマウントする必要があるクラスター内の各ノードに1つのジャーナルが必要です。追加のノードをクラスタに追加する場合は、gfs2_jadd コマンドで、ジャーナルを GFS2 ファイルシステムに追加できます。基礎となる論理ボリュームを拡張することなく、いつでも動的にジャーナルをGFS2ファイルシステムに追加できます。gfs2_jadd コマンドは、マウントしたファイルシステムで実行する必要がありますが、クラスター内の ノードの 1 つでのみ実行する必要があります。他のすべてのノードは、展開が行われたことを感知します。

注記

GFS2 ファイルシステムが満杯になると、ファイルシステムを含む論理ボリュームが拡張され、ファイルシステムよりも大きい場合でもgfs2_jadd コマンドは失敗します。これは、GFS2ファイルシステムでは、ジャーナルは埋め込みメタデータではなくプレーンファイルであるため、基になる論理ボリュームを単に拡張してもジャーナル用のスペースが提供されないためです。

GFS2 ファイルシステムにジャーナルを追加する前に、次の例のように gfs2_edit -p jindex コマンドを実行して、GFS2 ファイルシステムに現在含まれているジャーナルの数を確認できます。

# gfs2_edit -p jindex /dev/sasdrives/scratch|grep journal
   3/3 [fc7745eb] 4/25 (0x4/0x19): File    journal0
   4/4 [8b70757d] 5/32859 (0x5/0x805b): File    journal1
   5/5 [127924c7] 6/65701 (0x6/0x100a5): File    journal2

GFS2ファイルシステムにジャーナルを追加する基本的なコマンドの形式は次のとおりです。

gfs2_jadd -j Number MountPoint
Number
追加する新規ジャーナルの数を指定します。
MountPoint
GFS2ファイルシステムがマウントされているディレクトリを指定します。

この例では、1 つのジャーナルが、/mygfs2 ディレクトリーのファイルシステムに追加されます。

gfs2_jadd -j 1 /mygfs2

第4章 GFS2クォータ管理 (機械翻訳)

ファイルシステムクォータは、ユーザーまたはグループが使用できるファイルシステムスペースの量を制限するために使用されます。ユーザーまたはグループは、設定されるまでクォータ制限を持ちません。GFS2 ファイルシステムが quota=on または quota=account オプションでマウントされていると、GFS2 は、制限がない場合でも、各ユーザーおよびグループによって使用されているスペースを追跡します。GFS2は、トランザクションによる方法でクォータ情報を更新するので、システムクラッシュの際にクォータの使用法を再構築する必要はありません。

パフォーマンスの低下を防ぐために、GFS2ノードは定期的にのみクォータファイルへの更新を同期します。ファジークォータアカウンティングでは、ユーザーまたはグループが設定限度をわずかに超えることができます。これを最小限に抑えるために、GFS2は、ハードクォータ制限に近づくと同期期間を動的に短縮します。

注記

GFS2は標準のLinuxクォータ機能をサポートしています。これを使用するためには、quota RPM をインストールする必要があります。これはGFS2でクォータを管理するための好ましい方法であり、クォータを使用するGFS2のすべての新しい展開に使用する必要があります。このセクションでは、これらの機能を使ったGFS2クォータ管理について説明します。

ディスククォータの詳細は、以下のコマンドの man ページを参照してください。

  • quotacheck
  • edquota
  • repquota
  • quota

4.1. GFS2ディスククォータの設定 (機械翻訳)

ディスククォータを実装するには、次の手順に従います。

  1. 強制モードまたはアカウンティングモードでクォータを設定します。
  2. 現在のブロック使用情報を使用してクォータデータベースファイルを初期化します。
  3. クォータポリシーを割り当てます。(アカウンティングモードでは、これらのポリシーは適用されません。)

これらの各ステップについては、以降のセクションで詳しく説明します。

4.1.1. 強制モードまたはアカウンティングモードでクォータを設定する (機械翻訳)

GFS2ファイルシステムでは、クォータはデフォルトで無効になっています。ファイルシステムのクォータを有効にするには、quota=on オプション指定して、ファイルシステムを次のようにマウントします。

クォータを有効にしてファイルシステムをマウントするには、GFS2 ファイルシステムリソースをクラスターに作成する場合に、options 引数に quota=onを指定します。たとえば、次のコマンドは、作成する GFS2 Filesystem リソースが、クォータを有効にしてマウントすることを指定します。

# pcs resource create gfs2mount Filesystem options="quota=on" device=BLOCKDEVICE directory=MOUNTPOINT fstype=gfs2 clone

制限を強制したり値を警告したりすることなく、ディスク使用量を追跡し、すべてのユーザーおよびグループのクォータアカウンティングを維持することができます。これを行うには、quota=account オプションを指定して、ファイルシステムをマウントします。

クォータを無効にしてファイルシステムをマウントするには、GFS2 ファイルシステムリソースをクラスターに作成する場合に、options 引数に quota=offを指定します。

4.1.2. クォータデータベースファイルの作成 (機械翻訳)

各割り当て対応ファイルシステムがマウントされた後、システムはディスク割り当てを処理することができます。ただし、ファイルシステム自体はまだクォータをサポートする準備ができていません。次のステップは、quotacheck コマンドを実行します。

quotacheck コマンドは、割り当てが有効になっているファイルシステムを調べ、ファイルシステムごとに現在のディスク使用量のテーブルを作成します。このテーブルは、オペレーティングシステムのディスク使用量のコピーを更新するために使用されます。さらに、ファイルシステムのディスククォータファイルが更新されます。

ファイルシステムにクォータファイルを作成するには、quotacheck コマンドの -u オプションおよび -g オプションを使用します。両方のオプションを指定して、ユーザーおよびグループのクォータを初期化する必要があります。たとえば、クォータが /home ファイルシステムに対して有効な場合は、/home ディレクトリーにファイルを作成します。

quotacheck -ug /home

4.1.3. ユーザーごとにクォータを割り当てる (機械翻訳)

最後のステップは、edquota コマンドでディスククォータを割り当てます。(quota=account オプションを指定して) ファイルシステムをアカウンティングモードでマウントした場合、クォータは適用されません。

シェルプロンプトでrootとしてユーザーのクォータを設定するには、次のコマンドを実行します。

# edquota username

クォータが必要な各ユーザーに対してこの手順を実行します。たとえば、クォータが /home パーティションに対して有効になっている場合 (以下の例では /dev/VolGroup00/LogVol02) に edquota testuser を実行すると、システムのデフォルトとして設定されているエディターに次のように表示されます。

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436        0        0
注記

EDITOR 環境変数により定義されたテキストエディターは、edquotaにより使用されます。エディターを変更するには、~/.bash_profile ファイルの EDITOR環境変数を、使用するエディターのフルパスに設定します。

最初の列は、割り当てが有効になっているファイルシステムの名前です。2列目は、ユーザーが現在使用しているブロック数を示します。次の2つの列は、ファイルシステム上のユーザーに対するソフトブロック制限とハードブロック制限を設定するために使用されます。

ソフトブロック制限は、使用できる最大ディスク容量を定義します。

ハードブロック制限は、ユーザーまたはグループが使用できる絶対最大ディスク容量です。この制限に達すると、それ以上ディスク容量を使用することはできません。

GFS2 ファイルシステムは inode のクォータを維持しないため、この列は GFS2 ファイルシステムには適用されず、空白になります。

いずれかの値が0に設定されていると、その制限は設定されません。テキストエディタで制限を変更します。以下に例を示します。

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436   500000   550000

ユーザーのクォータが設定されたことを確認するには、次のコマンドを使用します。

# quota testuser

setquota コマンドを使用して、コマンドラインからクォータを設定することもできます。setquota コマンドの詳細は、man ページの setquota(8) を参照してください。

4.1.4. グループごとにクォータを割り当てる (機械翻訳)

割り当て量は、グループごとに割り当てることもできます。(account=on オプションを指定して) ファイルシステムをアカウンティングモードでマウントした場合、クォータは適用されません。

develグループのグループクォータを設定する (グループはグループクォータを設定する前に存在している必要があります) には、次のコマンドを使用します。

# edquota -g devel

このコマンドは、グループの既存のクォータをテキストエディタに表示します。

Disk quotas for group devel (gid 505):
Filesystem                blocks    soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440400       0        0

GFS2 ファイルシステムは inode のクォータを維持しないため、この列は GFS2 ファイルシステムには適用されず、空白になります。制限を変更してからファイルを保存します。

グループクォータが設定されたことを確認するには、次のコマンドを使用します。

$ quota -g devel

4.2. GFS2ディスククォータの管理 (機械翻訳)

クォータが実装されている場合、クォータを超えていないかどうかを確認し、クォータが正確であることを確認するという形で、何らかのメンテナンスが必要です。

ユーザーが繰り返しクォータを超過したり、常にソフト制限に達したりする場合、システム管理者は、ユーザーの種類と仕事に影響を与えるディスク容量に応じて、いくつかの選択肢を選択できます。管理者は、より少ないディスク容量を使用する方法をユーザーが判断するか、ユーザーのディスククォータを増やすことができます。

repquota ユーティリティーを実行して、ディスク使用量のレポートを作成できます。たとえば、repquota /home コマンドは、以下の出力を生成します。

* Report for user quotas on device /dev/mapper/VolGroup00-LogVol02
Block grace time: 7days; Inode grace time: 7days
			Block limits			File limits
User		used	soft	hard	grace	used	soft	hard	grace
----------------------------------------------------------------------
root      --      36       0       0              4     0     0
kristin   --     540       0       0            125     0     0
testuser  --  440400  500000  550000          37418     0     0

すべてのディスク使用状況レポートを表示するには(オプション -a)クォータ対応ファイルシステムの場合は、次のコマンドを使用します。

# repquota -a

各ユーザーの後に表示される -- で、ブロック制限を超えたかどうかを簡単に判断できます。ブロックのソフト制限を超えると、出力の最初が -ではなく、+ となります。2 番目の - は inode の制限を示しますが、GFS2 ファイルシステムは inode の制限を示していないため、その文字はそのまま -となります。GFS2ファイルシステムは猶予期間をサポートしていません。 grace 列は空白のままになります。

repquota コマンドが、基板のファイルシステムに関係なく、NFS ではサポートされないことに注意してください。

4.3. quotacheckコマンドを使用してGFS2ディスクのクォータを正確に保つ (機械翻訳)

クォータを無効にして実行していた期間の経過後に。ファイルシステムでクォータを有効にした場合は、クォータファイルを作成、確認、修復する quotacheck コマンドを実行する必要があります。また、システムクラッシュ後にファイルシステムが正しくアンマウントされていない場合など、クォータファイルが正確でない可能性があると思われる場合は、quotacheck コマンドを使用してください。

quotacheck コマンドの詳細は、quotacheck のman ページを参照してください。

注記

ディスクアクティビティーが、計算するクォータ値に影響を与える可能性があるために、ファイルシステムがすべてのノードでアイドル状態になっている場合は、quotacheck を実行します。

4.4. quotasyncコマンドによるクォータの同期 (機械翻訳)

GFS2はすべてのクォータ情報をディスク上の独自の内部ファイルに保存します。GFS2ノードは、ファイルシステムの書き込みごとにこのクォータファイルを更新するわけではありません。むしろ、デフォルトでは60秒に1回クォータファイルを更新します。これは、クォータファイルに書き込むノード間で競合が発生してパフォーマンスが低下するのを防ぐために必要です。

ユーザーまたはグループが割り当て制限に近づくと、GFS2は割り当てファイルの更新間隔を動的に短縮して、制限を超えないようにします。クォータ同期の間の通常の期間は、quota_quantumパラメータです。quota_quantum= マウントオプションを使用して、デフォルト値の 60 秒から変更できます。Table 25.2. GFS2-Specific Mount Options。の quota_quantum パラメータは各ノードで、ファイルシステムがマウントされるたびに設定する必要があります。quota_quantum パラメーターへの変更は、マウントが解除すると元に戻ります。mount -o remount。 を使用して、quota_quantum の値を更新できます。

quotasync コマンドを使用して、GFS2 が実行する自動更新の間に、ノードからディスク上のクォータファイルに、クォータ情報を同期させます。使用法 Synchronizing Quota Information

# `quotasync [-ug -a|mountpoint..a`].
u
ユーザークォータファイルを同期します。
g
グループクォータファイルを同期する
a
現在クォータ対応で同期をサポートしているすべてのファイルシステムを同期します。-aがない場合は、ファイルシステムのマウントポイントを指定する必要があります。
mountpoint
アクションが適用されるGFS2ファイルシステムを指定します。

quota-quantum マウントオプション を指定して、同期の間隔を調整できます。

# mount -o quota_quantum=secs,remount BlockDevice MountPoint
MountPoint
アクションが適用されるGFS2ファイルシステムを指定します。
secs
GFS2による通常のクォータファイル同期の間の新しい期間を指定します。値を小さくすると、競合が増えてパフォーマンスが低下する可能性があります。

次の例では、実行されているノードから、ファイルシステム /mnt/mygfs2 のディスク上のクォータファイルに、キャッシュされているすべてのダーティクォータを同期します。

# quotasync -ug /mnt/mygfs2

次の例では、ファイルシステムを論理ボリューム /dev/volgroup/logical_volumeに再マウントする場合は、ファイルシステム /mnt/mygfs2 で通常クォータファイルを更新する間隔を、デフォルトから、1 時間 (3600秒) に変更します。

# mount -o quota_quantum=3600,remount /dev/volgroup/logical_volume /mnt/mygfs2

第5章 GFS2ファイルシステムの修復 (機械翻訳)

ファイルシステムがマウントされた状態でノードに障害が発生した場合、ファイルシステムのジャーナリングによって高速リカバリが可能になります。ただし、ストレージデバイスの電源が切れるか、物理的に切断されると、ファイルシステムが破損する可能性があります。(ジャーナリングは、ストレージサブシステムの障害からの回復には使用できません。) そのような破損が発生した場合は、fsck.gfs2 コマンドを使用して、GFS2 ファイルシステムを回復できます。

重要

fsck.gfs2 コマンドは、すべてのノードからマウント解除されているファイルシステムでのみ実行する必要があります。ファイルシステムがPacemakerクラスタリソースとして管理されている場合は、ファイルシステムリソースを無効にしてファイルシステムをマウント解除できます。fsck.gfs2 コマンドを実行すると、ファイルシステムリソースが再び有効になります。pcs resource disable--waitオプションで指定した タイムアウト 値の単位は秒です。

# pcs resource disable --wait=timeoutvalue resource_id
[fsck.gfs2]
# pcs resource enable resource_id

fsck.gfs2 コマンドが、システムの起動時に GFS2 ファイルシステムで実行しないようにするには、クラスターに GFS2 ファイルシステムリソースをクラスタに作成する際に、options 引数の run_fsck パラメーターを設定できます。"run_fsck=no" は、fsck コマンドを実行しないことを示します。

5.1. fsck.gfs2を実行するために必要なメモリの決定 (機械翻訳)

fsck.gfs2 コマンドを実行すると、オペレーティングシステムとカーネルに使用されているメモリー以上のシステムメモリーを必要とする場合があります。特に大規模なファイルシステムでは、このコマンドを実行するために追加のメモリが必要になる場合があります。

次の表に、サイズが1TB、10TB、および 100TB で、ブロックサイズが 4K の、GFS2 ファイルシステムで、fsck.gfs2 ファイルシステムの実行に必要となる可能性のあるメモリーの概算値を示します。

GFS2ファイルシステムのサイズfsck.gfs2の実行に必要な概算メモリー

1 TB

0.16 GB

10 TB

1.6 GB

100 TB

16ギガバイト

ファイルシステムのブロックサイズを小さくすると、より多くのメモリが必要になることに注意してください。たとえば、ブロックサイズが1KのGFS2ファイルシステムでは、この表に示されているメモリ量の4倍が必要になります。

5.2. gfs2ファイルシステムの修復 (機械翻訳)

以下には、GFS2 ファイルシステムを修復する fsck.gfs2 コマンドの形式を表示します。

fsck.gfs2 -y BlockDevice
-y
-y フラグにより、すべての質問の回答が yesとなります。-y フラグを指定すると、fsck.gfs2 コマンドは、変更を加える前に回答を求めるプロンプトを出しません。
BlockDevice
GFS2ファイルシステムが存在するブロックデバイスを指定します。

この例では、/dev/testvg/testlvブロックデバイスに常駐する GFS2 ファイルシステムが修復されます。修復するすべての質問に、自動的に yesと答えます。

# fsck.gfs2 -y /dev/testvg/testlv
Initializing fsck
Validating Resource Group index.
Level 1 RG check.
(level 1 passed)
Clearing journals (this may take a while)...
Journals cleared.
Starting pass1
Pass1 complete
Starting pass1b
Pass1b complete
Starting pass1c
Pass1c complete
Starting pass2
Pass2 complete
Starting pass3
Pass3 complete
Starting pass4
Pass4 complete
Starting pass5
Pass5 complete
Writing changes to disk
fsck.gfs2 complete

第6章 GFS2パフォーマンスの向上 (機械翻訳)

このセクションでは、GFS2のパフォーマンスを向上させるためのアドバイスを提供します。

高可用性アドオンおよびRed Hat Global File System 2(GFS2)を使用してRed Hat Enterprise Linuxクラスターをデプロイおよびアップグレードするための一般的な推奨事項については、次のWebサイトの記事「Red Hat Enterprise Linuxクラスター、高可用性、およびGFSデプロイメントのベストプラクティス」を参照してください。 Red Hatカスタマーポータル https://access.redhat.com/kb/docs/DOC-40821

6.1. GFS2ファイルシステムの最適化 (機械翻訳)

Red Hat Enterprise Linux には GFS2 用のデフラグツールがありませんが、個々のファイルを filefrag ツールで識別して一時ファイルにコピーし、一時ファイルの名前を変更してオリジナルを置き換えることで個々のファイルをデフラグできます。

6.2. GFS2ノードのロック (機械翻訳)

GFS2ファイルシステムから最高のパフォーマンスを引き出すには、その動作の基本的な理論を理解することが重要です。シングルノードファイルシステムはキャッシュと並行して実装されます。その目的は、頻繁に要求されるデータを使用するときにディスクアクセスの待ち時間をなくすことです。Linuxでは、ページキャッシュ(および歴史的にはバッファキャッシュ)がこのキャッシュ機能を提供しています。

GFS2では、各ノードは、ディスク上のデータの一部を含む可能性がある独自のページキャッシュを持っています。GFS2 は、glocks (ジーロックと発音します) と呼ばれるロック機構を使用して、ノード間のキャッシュの整合性を維持します。glock サブシステムは、キャッシュ管理機能を提供します。これは、分散ロックマネージャ (DLM) を基になる通信層として使用して実装されます。

glock は、inode ごとにキャッシュを保護するため、キャッシング層を制御するために使用される inode ごとにロックが 1 つあります。そのglockが共有モードで許可されている場合(DLMロックモード:PR) その場合、その glock の下のデータは、同時に 1 つまたは複数のノードにキャッシュすることができるため、すべてのノードはそのデータへのローカルアクセスを有することができます。

glockが排他モード(DLMロックモード)で許可されている場合EX) その場合、1 つのノードだけが、その glock の下でデータをキャッシュに入れることができます。このモードは、データを変更するすべての操作 (write システムコールなど) で使用されます。

別のノードが即時に許可できない glock を要求した場合、DLM は、現在その glock を保持している 1 つまたは複数のノードに、新しい要求をブロックしてロックを解除するように依頼するメッセージを送信します。glock の削除は、(ほとんどのファイルシステム操作の標準では) 長いプロセスになる可能性があります。共有 glock を削除することはキャッシュが無効にされることだけを必要とし、それは比較的速く、キャッシュされたデータの量に比例します。

排他的glockを削除するには、ログをフラッシュし、変更されたデータをディスクに書き戻す必要があります。その後、共有glockによる無効化が行われます。

シングルノードファイルシステムとGFS2の違いは、シングルノードファイルシステムは単一キャッシュを持ち、GFS2は各ノードに別々のキャッシュを持つことです。どちらの場合も、キャッシュされたデータにアクセスするための待ち時間は同程度ですが、別のノードが同じデータを以前にキャッシュしたことがある場合、GFS2ではキャッシュされていないデータにアクセスするための待ち時間がはるかに長くなります。

read (バッファー)、stat,readdir などの操作には、共有 glock のみが必要です。write (バッファー) 、mkdirrmdirunlink などの操作には、排他 glock が必要です。I/O の直接の読み取りおよび書き込みの操作では、割り当てが行われていない場合は遅延 glock、書き込みで割り当てが必要な場合は排他 glock が必要です (つまり、ファイルの拡張または穴埋め)。

これに続く2つの主なパフォーマンスの考慮事項があります。まず、読み取り専用操作はすべてのノードで独立して実行できるため、クラスター全体で非常によく並列化されています。第二に、同じ inode へのアクセスを競うノードが複数ある場合、排他 glock を必要とする操作はパフォーマンスを低下させる可能性があります。したがって、各ノードのワーキングセットを検討することは、GFS2 ファイルシステムのパフォーマンスにおける重要な要素です。たとえば、Backing up a GFS2 file systemで説明しているように、ファイルシステムのバックアップを実行する場合などです。

これにより、noatime そして nodiratime 可能な限り GFS2 で noatime マウントオプションおよび nodiratime マウントオプションを使用することが推奨されます。これにより、atime タイムスタンプを更新するのに、読み取りが排他ロックを必要ではなくなります。

ワーキングセットやキャッシュの効率性が心配な場合に、GFS2 は、GFS2 ファイルシステムのパフォーマンスを監視することを可能にするツールを提供します。パフォーマンスコパイロットおよび GFS2 トレースポイント。

注記

GFS2のキャッシングが実装されている方法により、次のいずれかが行われたときに最高のパフォーマンスが得られます。

  • inode は、すべてのノードにわたって読み取り専用で使用されます。
  • inode は、1 つのノードからのみ書き込みまたは変更されます。

ファイルの作成中および削除中に、ディレクトリーにエントリーを挿入したりディレクトリーからエントリーを削除すると、ディレクトリーへの inode の書き込みとしてカウントされます。

比較的まれに破られるのであれば、この規則を破ることは可能です。この規則を無視しすぎると、パフォーマンスが著しく低下します。

読み書きのマッピングがある GFS2 のファイルに mmap() を行い、そこからのみ読み込む場合、み、これは読み込みとしてのみカウントされます。

noatime mount パラメーター設定しないと、読み込みが、ファイルのタイムスタンプを更新するための書き込みにもなります。すべての GFS2 ユーザーが、atime に特定の要件がない限り、noatime を使用してマウントすることが推奨されます。

6.3. Posixロックに関する問題 (機械翻訳)

Posixロックを使用するときは、次の点に注意する必要があります。

  • Flockを使用すると、Posixロックを使用するよりも処理が速くなります。
  • GFS2 で Posix ロックを使っているプログラムは、GETLKの機能を使用しないようにする必要があります。なぜなら、クラスター環境では、プロセス ID がクラスター内の別のノードに対するものである可能性があるためです。

6.4. GFS2によるパフォーマンスチューニング (機械翻訳)

かなりのパフォーマンス上の利点を得るために、面倒なアプリケーションがそのデータを格納する方法を変更することは通常可能です。

面倒なアプリケーションの典型的な例は電子メールサーバーです。これらは多くの場合、各ユーザーのファイルを含むスプールディレクトリー (mbox)、または各メッセージのファイルを含む各ユーザーのディレクトリー (maildir) に配置されます。要求がIMAPを介して到着するとき、理想的な配置は各ユーザに特定のノードへの親和性を与えることです。このように、電子メールメッセージを表示および削除するという彼らの要求は、その1つのノード上のキャッシュから処理される傾向があります。そのノードに障害が発生した場合、セッションは別のノードで再開できます。

SMTPでメールが届くと、デフォルトで特定のユーザーのメールを特定のノードに渡すように個々のノードを設定できます。デフォルトノードが起動していない場合、メッセージは受信ノードによってユーザーのメールスプールに直接保存されます。この設計も、通常は特定のファイルセットを1つのノードにのみキャッシュすることを目的としていますが、ノードに障害が発生した場合は直接アクセスできるようにするためのものです。

この設定により、GFS2 のページキャッシュを最大限に活用することができ、また障害が発生してもアプリケーション (imap または smtp) からは見えないようにすることができます。

バックアップはしばしば別の扱いにくい分野です。繰り返しますが、可能であれば、各ノードの作業セットを、その特定の inode のセットをキャッシュしているノードから直接バックアップすることが強く推奨されます。定期的に実行されるバックアップスクリプトがあり、それがGFS2上で実行されているアプリケーションの応答時間の急上昇と一致するように思われる場合、クラスタが最も効率的に動作していない可能性があります。ページキャッシュの使用

明らかに、あなたがバックアップを実行するためにアプリケーションを停止することができるという立場にあれば、これは問題にならないでしょう。一方、バックアップが1つのノードだけから実行されると、ファイルシステムの大部分がそのノードにキャッシュされ、他のノードからの後続のアクセスにはパフォーマンスが低下します。次のコマンドを使用してバックアップが完了した後に、バックアップノード上のVFSページキャッシュを削除することで、ある程度これを軽減できます。

echo -n 3 >/proc/sys/vm/drop_caches

ただし、これは、各ノードのワーキングセットがクラスタ全体で共有されているか、ほとんどが読み取り専用であること、または単一のノードからアクセスされていることを確認するのに十分注意してください。

6.5. GFS2ロックダンプを使用したGFS2パフォーマンスのトラブルシューティング (機械翻訳)

GFS2キャッシングの使用効率が悪いためにクラスターのパフォーマンスが低下している場合は、入出力待ち時間が長くなります。GFS2のロックダンプ情報を利用して、問題の原因を突き止めることができます。

このセクションでは、GFS2ロックダンプの概要を説明します。

GFS2 ロックダンプ情報は、次のパス名にある debugfs ファイルから収集できます。debugfs は、/sys/kernel/debug/にマウントされているものとします。

/sys/kernel/debug/gfs2/fsname/glocks

ファイルの内容は一連の行です。G: で始まる行はそれぞ 1 つの glock を表し、それに続く 1 行のスペースでインデントされた行は、ファイル内で直前の glock に関する情報の項目を表します。

debugfs ファイルを使用する最良の方法は、cat コマンドを使用して、アプリケーションで問題が発生している間にファイル全体のコピーを取り (RAM が大きくて、キャッシュされた inode がある場合は時間がかかる場合があります)、後日、その結果得られたデータを調べることです。

注記

debugfs ファイルのコピーを 2 部作成すると便利です。数秒または 1 ~ 2 分かかります。同じ glock 番号に関する 2 つのトレースの所有者情報を比較することで、ワークロードが進行中であるか (遅いだけ)、それとも動かなくなったか (この場合は常にバグが原因であるため、Red Hat サポートに報告する必要があります) 判断できます。

debugfs ファイルで H: (ホルダー) で始まるの行は、許可された、または許可されるのを待っているロック要求を表します。ホルダーの f: 行のフラグフィールドには、次のものが表示されます。「W」フラグは待機中の要求を表し、「H」フラグは許可された要求を表します。待機要求が多数ある glock は、特定の競合が発生している可能性があります。

表6.1「glock フラグ」 は、さまざまな glock フラグの意味を示しており、表6.2「glock ホルダーフラグ」 は、glock ホルダーのさまざまなフラグの意味を示します。

表6.1 glock フラグ

フラグ名前意味

b

ブロッキング

ロック・フラグが設定されているときに有効であり、DLMから要求された操作がブロックされる可能性があることを示します。このフラグは、降格操作と "try"ロックのためにクリアされます。このフラグの目的は、他のノードがロックを降格するのにかかる時間とは無関係に、DLM応答時間の統計を収集できるようにすることです。

d

保留中の降格

遅延(リモート)降格要求

D

降格

降格要求(ローカルまたはリモート)

f

ログフラッシュ

このglockを解放する前にログをコミットする必要があります

F

フローズン

リモートノードからの返信は無視されます - リカバリが進行中です。このフラグは、異なるメカニズムを使用するファイルシステムのフリーズとは関係ありませんが、リカバリでのみ使用されます。

i

無効化中

この glock の下でページを無効にする過程で

I

初期

DLMロックがこのglockに関連付けられているときに設定されます

l

ロック済み

glock は、状態を変える過程にあります

L

LRU

glock が LRU リストにあるときに設定します。

o

オブジェクト

glock がオブジェクトに関連付けられている (つまり、タイプ 2 の glock の場合は inode、タイプ3の glock の場合はリソースグループ) ときに設定されます。

p

進行中の降格

glock は、降格要求に応答しています。

q

キューに登録

ホルダーが glock にキューイングされると設定され、glock が保持されるとクリアされますが、残りのホルダーはありません。アルゴリズムの一部として使用され、glock の最小保持時間を計算します。

r

返信保留

リモートノードから受信した応答は処理を待っています

y

ダーティー

このglockを解放する前にデータをディスクにフラッシュする必要があります

表6.2 glock ホルダーフラグ

フラグ名前意味

a

非同期

glock の結果を待ちません (結果は後でポーリングします)

A

すべて

互換性のある任意のロックモードが許容されます

c

キャッシュなし

ロック解除されたら、直ちにDLMロックを降格します

e

無期限

後続のロック取り消し要求を無視します

E

正確な

正確なロックモードが必要

F

最初

ホルダーがこのロックに対して最初に付与されるときに設定されます。

H

保有者

要求されたロックが許可されていることを示します

p

優先度

キューの先頭にあるエンキューホルダー

t

試行

「試行」ロック

T

1CBを試す

コールバックを送信する「試行」ロック

W

待つ

要求の完了を待っている間に設定

問題の原因になっている glock を特定したら、それがどの inode に関連しているかを調べることが次のステップになります。glock 番号 (G: の n:) はこれを示します。これは、type/number の形式になっており、type が 2 の場合、glock は inode glock となり、number は inode の番号になります。inode を追跡するには、find -inum numberを実行できます。ここで、 number は、glock のファイルを 16 進数から 10 進数に変換した inode になります。

警告

あなたが実行した場合 find ロック競合が発生しているときにファイルシステムに対してコマンドを実行すると、問題がさらに悪化する可能性があります。競合する inode を探す際に、アプリケーションを停止してから find コマンドを実行することをお勧めします。

表6.3「glock タイプ」 は、さまざまな glock タイプの意味を示しています。

表6.3 glock タイプ

型番ロックタイプ使用方法

1

Trans

トランザクションロック

2

inode

inode のメタデータとデータ

3

Rgrp

リソースグループメタデータ

4

Meta

スーパーブロック

5

Iopen

最後に閉じた inode の検出

6

Flock

flock(2) システムコール

8

Quota

クォータ操作

9

Journal

ジャーナルミューテックス

識別された glock のタイプが異なれば、それはタイプ 3: (リソースグループ) である可能性が最も高いです。通常の負荷の下で他の種類のglockを待っているプロセスが大量に見られる場合は、これをRed Hatサポートに報告してください。

リソースグループのロックで待機中の要求がいくつか待ち行列に入っているのを見た場合、これにはいくつかの理由が考えられます。1つは、ファイルシステム内のリソースグループの数に比べて多数のノードがあることです。もう1つは、ファイルシステムが非常にいっぱいになっている可能性があることです(平均して、空きブロックの検索に時間がかかる)。どちらの場合も状況を改善するには、ストレージを追加し、gfs2_grow コマンドを使用してファイルシステムを拡張します。

6.6. データジャーナリングを有効にする (機械翻訳)

通常、GFS2はそのジャーナルにメタデータのみを書き込みます。その後、ファイルシステムのバッファをフラッシュするカーネルの定期的な同期によって、ファイルの内容がディスクに書き込まれます。ファイルで fsync() ファイルを呼び出すと、ファイルのデータがただちにディスクに書き込まれます。すべてのデータが安全に書き込まれたことがディスクから報告されると、呼び出しは戻ります。

ファイルデータは、メタデータとともにジャーナルにも書き込まれるため、データジャーナリングは、非常に小さいファイルには fsync()が減少する可能性があります。ファイルサイズが大きくなると、この利点は急激に減少します。中規模以上のファイルへの書き込みは、データジャーナリングがオンになっているとはるかに遅くなります。

ファイルデータを同期するのに fsync()依存しているアプリケーションは、データジャーナリングを使用してパフォーマンスが向上することがあります。フラグの付いたディレクトリ(およびそのすべてのサブディレクトリ)に作成されたGFS2ファイルに対して、データジャーナリングを自動的に有効にすることができます。長さ0の既存のファイルでも、データジャーナリングを有効または無効にすることができます。

ディレクトリでデータジャーナリングを有効にすると、そのディレクトリは "inherit jdata"に設定されます。これは、その後そのディレクトリに作成されたすべてのファイルとディレクトリがジャーナル処理されることを示します。chattr コマンドを使用して、ファイルのデータジャーナリングを有効または無効にできます。

次のコマンドは、/mnt/gfs2/gfs2_dir/newfile ファイルでデータジャーナリングを有効にし、フラグが正しく設定されているかどうかを確認します。

# chattr +j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

次のコマンドは、/mnt/gfs2/gfs2_dir/newfile ファイルにおけるデータジャーナリングを無効にし、フラグが正しく設定されているかどうかを確認します。

# chattr -j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
------------- /mnt/gfs2/gfs2_dir/newfile

また、chattrコマンドを使用して、ディレクトリーに j フラグを設定できます。このフラグをディレクトリに設定すると、そのディレクトリ内に後で作成されたすべてのファイルとディレクトリがジャーナル処理されます。次の一連のコマンドは、gfs2_dirディレクトリーに j フラグを設定し、フラグが正しく設定されたかどうか確認します。この後、コマンドは、/mnt/gfs2/gfs2_dirディレクトリーに、newfile という名前の新しいファイルを作成し、そのファイルに j フラグが設定されているかどうかを確認します。ディレクトリーに j フラグが設定されてから、newfile はジャーナリングも有効にする必要があります。

# chattr -j /mnt/gfs2/gfs2_dir
# lsattr /mnt/gfs2
---------j--- /mnt/gfs2/gfs2_dir
# touch /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

第7章 GFS2ファイルシステムに関する問題の診断と修正 (機械翻訳)

このセクションでは、GFS2に関する一般的な問題とその対処方法について説明します。

7.1. ノードに対してGFS2ファイルシステムが使用不可(GFS2撤回機能) (機械翻訳)

GFS2 の 撤回 機能は、GFS2 ファイルシステムのデータ整合性機能であり、ハードウェアまたはカーネルソフトウェアの不良によるファイルシステムの損傷を防ぎます。任意のクラスタノードでGFS2ファイルシステムの使用中にGFS2カーネルモジュールが不整合を検出すると、GFS2カーネルモジュールはファイルシステムから撤退し、アンマウントおよび再マウントされるまで(または問題を検出したマシンが再起動されるまで)そのノードで使用できなくなります。他のすべてのマウントされたGFS2ファイルシステムはそのノード上で完全に機能し続けます。(GFS2の撤回機能は、ノードがフェンスされる原因となるカーネルパニックよりも厳しくありません。)

GFS2の撤回を引き起こす可能性がある矛盾の主なカテゴリーは以下のとおりです。

  • inode 整合性エラー
  • リソースグループの整合性エラー
  • ジャーナル整合性エラー
  • マジックナンバーメタデータの一貫性エラー
  • メタデータ型の一貫性エラー

GFS2 の撤回を引き起こす可能性がある不一致の例は、ファイルの inode に対するブロック数が間違っています。GFS2がファイルを削除すると、そのファイルによって参照されているすべてのデータブロックとメタデータブロックが体系的に削除されます。完了すると、inode のブロック数をチェックします。ブロック数が 1 でない場合 (つまり、残りのすべてがディスク inode 自体である場合)、inode のブロック数はファイルに使用されている実際のブロックと一致しないため、ファイルシステムの不整合を示します。

多くの場合、問題はハードウェアの不良(メモリ、マザーボード、HBA、ディスクドライブ、ケーブルなどの不良)が原因である可能性があります。カーネルのバグ(別のカーネルモジュールが誤ってGFS2のメモリを上書きする)、または実際のファイルシステムの損傷(GFS2のバグが原因)によっても引き起こされる可能性があります。

ほとんどの場合、撤回されたGFS2ファイルシステムから回復するための最善の方法は、ノードを再起動またはフェンスすることです。撤回されたGFS2ファイルシステムは、クラスタ内の別のノードにサービスを移動する機会を与えてくれます。サービスを移動した後は、このコマンドを使用してノードを再起動するかフェンスを強制することができます。

# pcs stonith fence node
警告

umountコマンドおよび mount コマンドを使用して、手動でファイルシステムをアンマウントおよび再マウントしようとしないでください。pcs コマンドを使用する必要があります。このコマンドを使用しないと、Pacemaker はファイルシステムサービスが消失したことを検出し、ノードを隔離します。

撤退を引き起こした一貫性の問題はそれがシステムをハングさせるかもしれないのでファイルシステムサービスを停止することを不可能にするかもしれません。

再マウントしても問題が解決しない場合は、ファイルシステムサービスを停止してクラスタ内のすべてのノードからファイルシステムをマウント解除し、fsck.gfs2コマンドでファイルシステムのチェックを実行してから次の手順でサービスを再開します。

  1. 影響を受けるノードを再起動します。
  2. Pacemakerで非クローンファイルシステムサービスを無効にして、クラスタ内のすべてのノードからファイルシステムをマウント解除します。

    # pcs resource disable --wait=100 mydata_fs
  3. クラスターの 1 つのノードから、ファイルシステムデバイスで fsck.gfs2 コマンドを実行し、ファイルシステムの損傷を確認して修復します。

    # fsck.gfs2 -y /dev/vg_mydata/mydata > /tmp/fsck.out
  4. ファイルシステムサービスを再度有効にして、すべてのノードからGFS2ファイルシステムを再マウントします。

    # pcs resource enable --wait=100 mydata_fs

ファイルシステムサービスに指定した -o errors=panic オプションを使用してファイルシステムをマウントすることで、GFS2 の撤回機能を無効にできます。

# pcs resource update mydata_fs “options=noatime,errors=panic”

このオプションが指定されている場合、通常システムに撤回させるようなエラーが発生すると、代わりにカーネルパニックが発生します。これによりノードの通信が停止し、ノードが隔離されます。これは、監視や介入なしに長期間無人のままになっているクラスタに特に役立ちます。

内部的には、GFS2の撤回機能は、ロッキングプロトコルを切断することによって機能し、それ以降のすべてのファイルシステム操作で入出力エラーが発生するようにします。その結果、撤回が発生すると、デバイスマッパーデバイスから多数のI / Oエラーがシステムログに報告されるのが普通です。

7.2. GFS2ファイルシステムがハングアップし、1つのノードの再起動が必要 (機械翻訳)

GFS2ファイルシステムがハングアップし、それに対して実行されたコマンドが返されないが、特定のノードを再起動するとシステムが正常に戻る場合、これはロックの問題またはバグを示している可能性があります。これが発生した場合は、Gathering GFS2 data for troubleshootingの説明に従って、これらの発生時に GFS2 データを収集し、Red Hat サポートにサポートチケットを作成してください。

7.3. GFS2ファイルシステムがハングアップし、全ノードの再起動が必要 (機械翻訳)

GFS2ファイルシステムがハングアップし、それに対して実行されるコマンドが返されないため、使用する前にクラスタ内のすべてのノードを再起動する必要がある場合は、次の点を確認してください。

  • あなたは失敗したフェンスを持っていたのかもしれません。GFS2ファイルシステムは、フェンスが失敗した場合にデータの整合性を確保するためにフリーズします。メッセージログをチェックして、ハング時に失敗したフェンスがあるかどうかを確認します。フェンシングが正しく設定されていることを確認してください。
  • GFS2ファイルシステムが撤退した可能性があります。メッセージログで withdrawという単語を確認し、GFS2 のメッセージおよびコールトレースで、ファイルシステムが撤回されたことを示すメッセージがないかどうかを確認します。撤回は、ファイルシステムの破損、ストレージの障害、またはバグを示しています。ファイルシステムをマウント解除するのが便利な早い時期に、次の手順を実行する必要があります。

    1. 撤回が発生したノードを再起動します。

      # /sbin/reboot
    2. ファイルシステムリソースを停止して、すべてのノードでGFS2ファイルシステムをマウント解除します。

      # pcs resource disable --wait=100 mydata_fs
    3. gfs2_edit savemeta…​ コマンドでメタデータをキャプチャします。ファイルに十分なスペースがあることを確認する必要があります。場合によっては、それが大きくなることがあります。この例では、メタデータは、/root ディレクトリーのファイルに保存されます。

      # gfs2_edit savemeta /dev/vg_mydata/mydata /root/gfs2metadata.gz
    4. gfs2-utils パッケージを更新します。

      # sudo yum update gfs2-utils
    5. 1 つのノードで、ファイルシステムで fsck.gfs2 コマンドを実行し、ファイルシステムの整合性を確認し、損傷を修復します。

      # fsck.gfs2 -y /dev/vg_mydata/mydata > /tmp/fsck.out
    6. fsck.gfs2 コマンドが完了したら、ファイルシステムリソースを再度有効にしてサービスに戻します。

      # pcs resource enable --wait=100 mydata_fs
    7. Red Hat サポートに、サポートチケットを作成します。GFS2 の撤回が発生したことを伝え、sosreports コマンドおよび gfs2_edit savemeta コマンドで収集した、ログとデバッグ情報を提出してください。

      GFS2の撤回の場合には、ファイルシステムまたはそのブロックデバイスにアクセスしようとしているコマンドがハングすることがあります。このような場合、クラスタを再起動するにはハードリブートが必要です。

      GFS2 撤回機能は、GFS2 filesystem unavailable to a node (the GFS2 withdraw function)を参照してください。

  • このエラーは、ロックの問題またはバグを示している可能性があります。Gathering GFS2 data for troubleshootingに従ってこれらの発生時にデータを収集し、Red Hat サポートにサポートチケットを開きます。

7.4. GFS2ファイルシステムが新しく追加されたクラスタノードにマウントされない (機械翻訳)

新しいノードをクラスタに追加しても、そのノードにGFS2ファイルシステムをマウントできないことがわかった場合は、GFS2ファイルシステムにアクセスしようとしているノードよりもGFS2ファイルシステム上のジャーナルが少なくなる可能性があります。ファイルシステムをマウントする GFS2 ホストごとに、ジャーナルが 1 つ必要です (ただし、spectator マウントオプションを設定してマウントした GFS2 は、ジャーナルを必要としないため除外)。gfs2_jadd コマンドを使用して、GFS2 ファイルシステムにジャーナルを追加できます (Adding journals to a GFS2 file system)。

7.5. 空のファイルシステムで使用されていると示されたスペース (機械翻訳)

空の GFS2 ファイルシステムがある場合は、df コマンドで、占有されているスペースがあることを示します。これは、GFS2ファイルシステムジャーナルがディスク上のスペース(ジャーナル数*ジャーナルサイズ)を消費するためです。多数のジャーナルを含む GFS2 ファイルシステムを作成した場合、または大きいジャーナルサイズを指定した場合は、df コマンドを実行すると、(ジャーナルの数 * ジャーナルのサイズ) が使用されているものとして表示されます。多数のジャーナルまたは大きいジャーナルを指定しなかった場合でも、小さいGFS2ファイルシステム(1GB以下の範囲)では、デフォルトのGFS2ジャーナルサイズで使用されているため、大量のスペースが表示されます。

7.6. トラブルシューティングのためのGFS2データの収集 (機械翻訳)

GFS2ファイルシステムがハングアップし、それに対して実行されたコマンドが返されず、Red Hat Supportでチケットを開く必要があるとわかった場合は、まず次のデータを収集する必要があります。

  • 各ノード上のファイルシステムのGFS2ロックダンプ

    cat /sys/kernel/debug/gfs2/fsname/glocks >glocks.fsname.nodename
  • 各ノード上のファイルシステムのDLMロックダンプこの情報は、dlm_tool で取得できます。

    dlm_tool lockdebug -sv lsname.

    このコマンドでは、lsname は、問題のファイルシステムに対して DLM が使用するロックスペース名です。group_tool コマンドの出力で、この値を確認できます。

  • sysrq -t コマンドの出力。
  • /var/log/messages ファイルの内容。

データを収集したら、Red Hat Supportでチケットを開き、収集したデータを提供することができます。

法律上の通知

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.