GFS2 ファイルシステムのインストールおよび設定前に計画する必要がある主要な GFS2 パラメーターが複数あります。

GFS2 ファイルシステムを実行するクラスターで Red Hat からのサポートを受けるには、GFS2 ファイルシステムのサポートポリシーを考慮する必要があります。

GFS2 ファイルシステムを保存してパフォーマンスを最適化するには、以下のような推奨事項を考慮する必要があります。

ファイルシステムサイズ: 小さい方が好ましい

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

GFS2 のファイルシステムは大きくても構いませんが、推奨されているわけではありません。GFS2 の経験則から、小さい方がよいとされています。10 TB のファイルシステムを 1 つ用意するより、1 TB のファイルシステムを 10 個用意するほうがよいとされています。

GFS2 ファイルシステムのサイズを小さくとどめることが推奨される理由として、以下の点があげられます。

また、メンテナンス対象となるリソースグループが少なくなることにより、パフォーマンスが向上します。

当然ながら、GFS2 ファイルシステムのサイズを小さくしすぎると、容量が不足し、それ自体に影響が及ぶ可能性があります。サイズを決定する前に、どのように使用されるかを考慮してください。

ブロックサイズ: デフォルト (4K) ブロックを推奨

mkfs.gfs2 コマンドは、デバイストポロジーに基づいて最適なブロックサイズを推定しようとします。通常、4K ブロックがブロックサイズとして推奨されます。これは、4K が Red Hat Enterprise Linux のデフォルトページサイズ (メモリー) であるためです。その他の一部のファイルシステムとは異なり、GFS2 は 4K カーネルバッファーを使用して多くの操作を実行します。ブロックサイズが 4K であれば、カーネルによるバッファー操作の作業数が減ります。

パフォーマンスを最大にするためにも、デフォルトのブロックサイズを使用することが推奨されます。小さいファイルが大量にある効率的なストレージが必要な場合のみ、別のブロックサイズを使用してください。

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

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

一部のシステム管理者は、128 MB では過剰と考え、ジャーナルのサイズを最低レベルの 8 MB まで、あるいはより従来的な 32MB まで縮小することを望んでいます。動作に問題が起きない場合でも、パフォーマンスに重大な影響を与える可能性があります。多くのジャーナリングファイルシステムと同様に、GFS2 がメタデータを書き込むたびに、メタデータの配置前にジャーナルにコミットされます。これにより、システムがクラッシュしたり、停電したりした場合に、ジャーナルがマウント時に自動的に再生される時に、すべてのメタデータが復元します。ただし、ファイルシステムのアクティビティーでは 8 MB のジャーナルが簡単に埋まってしまいます。ジャーナルがいっぱいになると、GFS2 がストレージへの書き込みを待つ必要があるため、パフォーマンスが低下します。

通常、デフォルトのジャーナルサイズである 128 MB を使用することが推奨されます。ファイルシステムが非常に小さい (例: 5GB) 場合、128 MB のジャーナルでは非現実的である可能性があります。より大きなファイルシステムがあり、容量に余裕があれば、256 MB のジャーナルを使用するとパフォーマンスが向上する可能性があります。

リソースグループのサイズおよび数

mkfs.gfs2 コマンドで GFS2 ファイルシステムを作成すると、ストレージが、リソースグループと呼ばれる均一なスライスに分割されます。最適なリソースグループサイズ (32MB から 2GB) の推定値を計算しようとします。mkfs.gfs2 コマンドに -r オプションを指定すると、デフォルトを上書きできます。

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

どのサイズが最適なパフォーマンスになるかを確認するには、異なるリソースグループのサイズで実験する必要があります。GFS2 を完全な実稼働環境にデプロイする前に、テストクラスターを試すのがベストプラクティスと言えます。

ファイルシステムに含まれるリソースグループの数が多過ぎて、各リソースグループが小さすぎると、ブロックの割り当てにより、空きブロックに対する何万ものリソースグループの検索に時間がかかりすぎることがあります。ファイルシステムが満杯になるほど、検索されるリソースグループが増え、そのすべてにクラスター全体のロックが必要になります。その結果、パフォーマンスが低下します。

ただし、ファイルシステムのリソースグループの数が少なすぎて、各リソースグループが大き過ぎると、同じリソースグループロックへのブロックの割り当てが頻繁に競合する可能性があり、パフォーマンスにも影響が及びます。たとえば、2 GB の 5 つのリソースに分けられた 10GB のファイルがある場合、クラスター内のノードは、同じファイルシステムが 32 MB の 320 個のリソースグループに分けられている場合よりも頻繁に 5 つのリソースグループを奪おうとします。空きブロックを持つリソースグループを見つける前に、各ブロックの割り当てが複数のリソースグループを参照する必要があるため、ファイルシステムがほぼ満杯になると、この問題は悪化します。GFS2 は、次のいずれかの方法でこの問題を軽減しようとします。

最悪のシナリオとしては、集約ディレクトリーが 1 つあり、その中のノードがすべてファイルを作成しようとする場合などです。これは、全ノードが同じリソースグループをロックしようと常に競合するためです。

システムに含まれるノード数を決定する際には、高可用性とパフォーマンスにトレードオフがあることに注意してください。ノードの数が多いと、ワークロードのスケールがますます困難になります。このため、Red Hat は、ノードの数が 16 を超えるクラスターファイルシステムデプロイメントでの GFS2 の使用に対応していません。

クラスターファイルシステムをデプロイすることは、単一ノードデプロイメントのドロップインには代わりません。Red Hat では、システムをテストして必要なパフォーマンスレベルで機能させるためにも、新規インストールにおいて約 8 ～12 週のテストを行うことを推奨しています。この期間中は、パフォーマンスまたは機能の問題を処理できます。また、すべてのクエリーは Red Hat サポートチームに転送する必要があります。

クラスターのデプロイを検討中のお客様は、デプロイメントを行う前に、Red Hat サポートによる設定のレビューを受けておくことを推奨します。これにより、後日にサポートの問題が発生するのを未然に防ぐことができます。

GFS2 ファイルシステムをデプロイする場合に、ハードウェアについて以下の考慮事項を考慮してください。

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

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

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

atime 更新の影響を軽減するには、以下の方法を利用できます。

次のコマンドを使用して、noatime Linux マウントオプションを指定して GFS2 ファイルシステムをマウントします。

mount BlockDevice MountPoint -o noatime

この例では、GFS2 ファイルシステムは /dev/vg01/lvol0 に置かれ、atime 更新がオフの状態で /mygfs2 にマウントされます。

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

すべての Linux ファイルシステムと同様に、GFS2 は仮想ファイルシステム (VFS) と呼ばれるレイヤーの上にあります。VFS は多くのワークロードに対するキャッシュ設定に適したデフォルトを提供しますが、ほとんどの場合で変更する必要はありません。ただし、効率的に実行していないワークロードがある場合 (たとえば、キャッシュが大きすぎる、あるいは小すぎる場合など) は、sysctl(8) コマンドを使用して /proc/sys/vm ディレクトリーの sysctl ファイルの値を調整することでパフォーマンスを向上できます。ファイルのドキュメンテーションは、カーネルソースツリーの Document/sysctl/vm.txt で参照できます。

たとえば、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 オプションをリサーチして、テスト用クラスター上で実験を行ってください。

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 ファイルシステムリソースを作成する際にマウントオプションを指定できます。

GFS2 ロッキングサブシステムとそのクラスターの複雑性を考慮し、GFS2 での NFS の設定には多くの予防措置が必要になります。

GFS2 ファイルシステムで NFS サービスを設定する際には、ロックについて考慮する以外に、以下のような点も検討する必要があります。

アクティブ/アクティブ設定が可能な CTDB を使用する GFS2 ファイルシステムから Samba (SMB または Windows) ファイルサービスを使用できます。

Samba の外部から Samba 共有のデータへの同時アクセスには対応していません。現在、GFS2 クラスターリースはサポート外で、Samba ファイル処理の速度が低下します。Samba のサポートポリシーの詳細は、RHEL Resilient Storage のサポートポリシー - ctdb の一般的なポリシー および RHEL Resilient Storage のサポートポリシー - 他のプロトコルを介した gfs2 コンテンツのエクスポート を参照してください。

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

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

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

通常、データの書き込みのみを行うアプリケーションでも、ブロックの割り当て方法や割り当て場所は重要ではありません。ただし、ブロック割り当ての仕組みに関するある程度の知識は、パフォーマンスの最適化に役立ちます。

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

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

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

# 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

GFS2 ファイルシステムをマウントできるようにするには、そのファイルシステムが存在し、そのファイルシステムが存在するボリュームがアクティブな状態で、かつサポート対象のクラスタリングシステムとロッキングシステムが起動している必要があります。以上の要件を満たすと、Linux ファイルシステムと同様に GFS2 ファイルシステムをマウントできます。

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

# mount /dev/vg01/lvol0 /mygfs2

mount BlockDevice MountPoint -o option

umount MountPoint

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

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

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

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

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

Red Hat では、SAN でハードウェアスナップショットを作成し、そのスナップショットを別のシステムに提供してそこにバックアップを行うことで、GFS2 バックアップを作成することを推奨しています。バックアップシステムはクラスターには含まれないため、-o lockproto=lock_nolock で、スナップショットをマウントする必要があります。

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

GFS2 ファイルシステムの動作を一時停止するコマンドの形式は、次のようになります。

dmsetup suspend MountPoint

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

# dmsetup suspend /mygfs2

GFS2 ファイルシステムで動作の一時停止を終了するコマンドの形式は、次のようになります。

dmsetup resume MountPoint

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

# dmsetup resume /mygfs2

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

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

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

ジャーナルを 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

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

# gfs2_jadd -j 1 /mygfs2

GFS2 ファイルシステムのディスククォータを実装するには、3 つの手順を実行します。

ディスククォータを実装する手順は、以下のとおりです。

この各ステップは、以下のセクションで詳しく説明します。

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

# quotacheck -ug /home

# edquota username

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

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

# quota testuser

# edquota -g devel

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

$ quota -g devel

クォータが実装されている場合には、いくつかの保守が必要となります。大半は、クォータの超過監視および精度確認という形となります。

ユーザーが繰り返しクォータを超過したり、常にソフト制限に達している場合、システム管理者には、ユーザーのタイプや、ユーザーの作業にディスク容量が及ぼす影響の度合に応じて 2 つの選択肢があります。管理者は、ユーザーが使用するディスク領域を節約する方法を決定できるように支援するか、ユーザーのディスククォータを拡大するかのいずれかを行うことができます。

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 ではサポートされないことに注意してください。

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

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

GFS2 は、すべてのクォータ情報をディスク上にある独自の内部ファイルに保存します。GFS2 ノードは、ファイルシステムの書き込みごとにこのクォータファイルを更新するのではなく、デフォルトで 60 秒ごとにクォータファイルを更新します。これは、クォータファイルへの書き込みをノード間で行うことを避けるために必要です。このような場合は、パフォーマンスが低下します。

ユーザーまたはグループがクォータ制限に近づくと、GFS2 はクォータファイルの更新の間隔を動的に短縮し、制限を超えないようにします。クォータ同期の間の通常の期間は、調整可能なパラメーターである quota_quantum です。マウントオプションを指定する GFS2 ファイルシステムのマウント の GFS2 固有のマウントオプションの表に記載されているように、quota_quantum= マウントオプションを使用して、デフォルト値の 60 秒から変更できます。

quota_quantum パラメーターは、各ノードごとと、ファイルシステムをマウントするたびに設定する必要があります。quota_quantum パラメーターへの変更は、マウントが解除すると元に戻ります。quota_quantum の値は mount -o remount で更新できます。

quotasync コマンドを使用して、GFS2 が実行する自動更新の間に、ノードからディスク上のクォータファイルにクォータ情報を同期させます。クォータ情報を同期する 形式は以下の通りです。

quotasync [-ug] -a|mountpoint...

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

# mount -o quota_quantum=secs,remount BlockDevice MountPoint

次の例では、実行しているノードから、ファイルシステム /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

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

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

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

GFS2 ファイルシステムを修復する fsck.gfs2 コマンドの形式は、以下のとおりです。

fsck.gfs2 -y BlockDevice

この例では、/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

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

GFS2 ファイルシステムでパフォーマンスを最適化するには、操作に関する基本的な理論をある程度理解しておくことが重要となります。単一ノードのファイルシステムはキャッシュと共に実装されます。キャッシュは、頻繁に要求されるデータを使用する場合にディスクへのアクセスの待ち時間をなくすことを目的としています。Linux では、ページキャッシュ (および以前のバッファーキャッシュ) により、このキャシング機能が提供されます。

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

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

glock が排他モード (DLM ロックモード: EX) で許可されると、単一ノードのみがその glock でデータをキャッシュできます。このモードは、データを変更するすべての操作 (write システムコールなど) で使用されます。

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

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

単一ノードのファイルシステムと GFS2 の違いは、単一ノードのファイルシステムにはキャッシュが 1 つだけあり、GFS2 には各ノードに個別のキャッシュがあることです。どちらの場合も、キャッシュされたデータへのアクセスのレイテンシーの長さは同じようになりますが、別のノードが以前同じデータをキャッシュしていると、キャッシュされていないデータにアクセスする場合のレイテンシーは、GFS2 の方がかなり長くなります。

共有 glock を必要とするのは、read (バッファー付き)、stat、readdir などの操作のみです。排他的な glock を必要とするのは、write (バッファー付き)、mkdir、rmdir、unlink などの操作のみです。ダイレクト I/O の読み書き操作では、割り当てが行われていない場合は DF (deffered) 状態の glock が必要です。また、書き込みに割り合てが必要な場合は (つまりファイルの拡張または穴埋めには)、EX (exclusive) 状態の glock が必要です。

この場合、パフォーマンスに関する主な考慮事項が 2 つがあります。まず、読み込み専用操作は各ノードで独立して実行できるため、クラスター全体で並列処理が極めてよく機能します。次に、同じ inode へのアクセスを競うノードが複数あると、排他 glock を必要とする操作によりパフォーマンスが低下する場合があります。たとえば、GFS2 ファイルシステムのバックアップ の説明にあるように、GFS2 ファイルシステムのパフォーマンスにおいては、ファイルシステムのバックアップを行う場合などには、各ノードのワーキングセットを考慮することが重要になります。

これに加え、可能な限り GFS2 で マウントオプションの noatime または nodiratime を指定することが推奨されます。この場合、アプリケーションがこれを許可する noatime が優先されます。これにより、read が atime タイムスタンプを更新する際に排他的なロックが必要なくなります。

ワーキングセットやキャッシュの効率を懸念している場合、GFS2 では、GFS2 ファイルシステムのパフォーマンスを監視できるツール (Performance Co-Pilot や GFS2 トレースポイント) を利用できます。

POSIX ロックを使用する場合は、以下の点を考慮する必要があります。

通常は、面倒なアプリケーションのデータ格納方法を変更すると、パフォーマンスを大幅に向上させることができます。

面倒なアプリケーションの典型的な例は、メールサーバーです。このアプリケーションは多くの場合、各ユーザーのファイルを含むスプールディレクトリー (mbox)、または各メッセージのファイルを含む各ユーザーのディレクトリー (maildir) に配置されます。要求が IMAP 経由で到達する場合は、各ユーザーに特定のノードへのアフィニティーを与えることが理想的です。このようにして、電子メールメッセージの表示や削除の要求は、そのノードのキャッシュから提供される傾向があります。当然ながら、そのノードに障害が発生すると、セッションを別のノードで再起動できます。

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

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

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

当然ながら、バックアップを実行するためにアプリケーションを停止できる場合は、特に問題にはなりません。一方、バックアップが 1 つのノードのみから実行する場合は、バックアップ完了後にそのノード上にファイルシステムの大部分がキャッシュされ、他のノードからの後続アクセスのパフォーマンスが低下します。次のコマンドを実行すると、バックアップ完了後にバックアップノード上の VFS ページキャッシュをドロップすることで、パフォーマンスの低下をある程度緩和できます。

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

ただし、この方法は、各ノードのワーキングセットが共有されているか、大半がクラスター全体で読み取り専用であるか、1 つのノードから大部分がアクセスされるようにするのと比べると、あまり良い解決策ではありません。

GFS2 キャシングの使用効率が悪いためにクラスターのパフォーマンスが影響を受けている場合は、I/O の待機時間が大幅に長くなることがあります。GFS2 のロックダンプ情報を利用すると、この問題の原因を特定できます。

GFS2 ロックダンプ情報は debugfs ファイルから収集できます。このファイルのパス名は以下のとおりです (debugfs が /sys/kernel/debug/ にマウントされていることが前提です)。

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

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

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

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

以下の表は、glock フラグおよび glock ホルダーフラグとその意味について紹介します。

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

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

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

リソースグループロックでキューに置かれている待機要求が多く表示され場合は、複数の理由が考えられます。1 つは、ファイルシステム内のリソースグループ数と比べ、多くのノードが存在するためです。または、ファイルシステムがほぼ満杯になっている可能性もあります (平均して、空きブロックの検索時間が長い場合があります)。どちらの場合も状況を改善するには、ストレージを追加し、gfs2_grow コマンドを使用してファイルシステムを拡張します。

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

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

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

1 つのディレクトリー上でデータジャーナリングを有効にすると、そのディレクトリーは 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

GFS2 の withdraw (無効) 機能は、GFS2 ファイルシステムのデータ整合性機能であり、ハードウェアまたはカーネルソフトウェアの不良によるファイルシステムの損傷を防ぎます。指定したクラスターノードで GFS2 ファイルシステムを使用している場合に、GFS2 カーネルが非整合性を検出すると、マウントを解除して再マウントするまでそのノードで利用できなくなります (または問題を検出したマシンが再起動します)。マウントしたその他の GFS2 ファイルシステムはすべて、そのノードで完全に機能し続けます。GFS2 の withdraw 機能は、ノードをフェンスする原因となるカーネルパニックよりも厄介なものではありません。

以下は、GFS2 を無効にする可能性のある非整合の種類です。

GFS2 の無効を引き起こす (撤回) 可能性がある不一致の例は、ファイルの inode に対するブロック数が間違っています。GFS2 がファイルを削除すると、そのファイルが参照するすべてのデータおよびメタデータブロックがシステムにより削除されます。完了すると、inode のブロック数を確認します。ブロック数が 1 でない場合 (つまり、残りのすべてがディスクの inode 自体である場合)、inode のブロック数はファイルに使用されている実際のブロックと一致しないため、ファイルシステムが不整合であることを示します。多くの場合、この問題の原因は、ハードウェアの障害 (メモリー、マザーボード、HBA、ディスクドライブ、ケーブルなど) にある可能性があります。また、カーネルのバグ (GFS2 のメモリーを誤って上書きする別のカーネルモジュール) や、実際のファイルシステムの損傷 (GFS2 のバグによる) が原因で発生した可能性もあります。

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

pcs stonith fence node

撤回の原因になった整合性の問題によりシステムがハングアップする可能性があるため、ファイルシステムのサービスを停止できなくなる可能性があります。

再マウントしても問題が解決しない場合は、ファイルシステムサービスを停止して、クラスターの全ノードからファイルシステムのマウントを削除し、以下の手順に従ってサービスを再起動する前に、fsck.gfs2 コマンドでファイルシステムの確認を実行します。

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

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

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

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

GFS2 ファイルシステムがハングし、それに対して実行したコマンドを返さなくても、ある特定のノードをリブートするとシステムが正常な状態に戻る場合には、ロックの問題もしくはバグの兆候である可能性があります。これが発生した場合は、トラブルシューティングに使用する GFS2 データの収集 の説明に従って、これらの発生時に GFS2 データを収集し、Red Hat サポートにサポートチケットを作成してください。

ご使用の GFS2 ファイルシステムがハングし、それに対して実行したコマンドを返さず、使用できる状態にするためにクラスター内の全ノードをリブートする必要がある場合は、以下の問題を確認してください。

新しいノードをクラスターに追加し、そのノードで GFS2 ファイルシステムをマウントできない場合は、GFS2 ファイルシステムのジャーナル数が、GFS2 ファイルシステムへのアクセスを試行しているノードよりも少ない可能性があります。ファイルシステムをマウントする GFS2 ホストごとに、ジャーナルが 1 つ必要です (ただし、spectator マウントオプションを設定してマウントした GFS2 ファイルシステムはジャーナルを必要としないため除外されます)。GFS2 ファイルシステムへのジャーナルの追加 で説明されているように、gfs2_jadd コマンドを使用して、GFS2 ファイルシステムにジャーナルを追加できます。

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

GFS2 ファイルシステムがハングし、それに対して実行したコマンドを返さず、Red Hat サポートのチケットを作成する必要がある場合は、最初に以下のデータを収集してください。

データを収集したら、Red Hat サポートのチケットを作成して、収集したデータを提出してください。

次の手順で、GFS2 ファイルシステムを含む Pacemaker クラスターをセットアップできます。この例では、2 ノードクラスター内の 3 つの論理ボリューム上に 3 つの GFS2 ファイルシステムを作成します。

Pacemaker クラスターの作成とクラスターのフェンシングの設定については、Pacemaker を使用した Red Hat High Availability クラスターの作成 を参照してください。

(RHEL 8.4 以降) 次の手順で、LUKS で暗号化した GFS2 ファイルシステムを含む Pacemaker クラスターを作成できます。この例では、論理ボリュームに 1 つの GFS2 ファイルシステムを作成し、そのファイルシステムを暗号化します。暗号化された GFS2 ファイルシステムは、LUKS 暗号化に対応する crypt リソースエージェントを使用してサポートされます。

この手順は、以下の 3 つの部分で設定されます。

[root@z1 ~]# lvs
  LV         VG          Attr       LSize
  shared_lv1 shared_vg1  -wi-a----- 5.00g

[root@z2 ~]# lvs
  LV         VG          Attr       LSize
  shared_lv1 shared_vg1  -wi-a----- 5.00g

[root@z1 ~]# ls -l /dev/mapper/
...
lrwxrwxrwx 1 root root 7 Mar 4 09:52 luks_lv1 -> ../dm-3
...

GFS2 ファイルシステムを含む RHEL 8 クラスターを設定する場合は、既存の Red Hat Enterprise 7 論理ボリュームを使用できます。

Red Hat Enterprise Linux 8 では、LVM は、clvmd の代わりに LVM ロックデーモン lvmlockd を使用して、アクティブ/アクティブのクラスターで共有ストレージデバイスを管理します。これにより、アクティブ/アクティブのクラスターに共有論理ボリュームとして使用する必要がある論理ボリュームを設定する必要があります。また、これにより、LVM が有効 なリソースを使用して LVM ボリュームを管理し、lvmlockd リソースエージェントを使用して lvmlockd デーモンを管理する必要があります。共有論理ボリュームを使用して、GFS2 ファイルシステムを含む Pacemaker クラスターを設定する手順は、クラスターに GFS2 ファイルシステムを設定 を参照してください。

GFS2 ファイルシステムを含む RHEL8 クラスターを設定する際に、既存の Red Hat Enterprise Linux 7 論理ボリュームを使用する場合は、RHEL8 クラスターから以下の手順を実行します。この例では、クラスター化された RHEL 7 論理ボリュームが、ボリュームグループ upgrade_gfs_vg に含まれます。

この手順を実行すると、各論理ボリュームに、LVM が有効 なリソースを作成できます。

現在、GFS2 トレースポイントには、glock (gee-lock と発音します) トレースポイント、bmap トレースポイント、および ログ トレースポイントがあります。これは、実行中の GFS2 ファイルシステムを監視するために使用できます。トレースポイントは、ハングやパフォーマンスの問題が再現可能で、問題のある操作中にトレースポイント出力を取得できる場合に特に役立ちます。GFS2 では、glock は主要なキャッシュ制御メカニズムで、GFS2 のコアのパフォーマンスを理解するときの鍵となります。bmap (ブロックマップ) トレースポイントを使用して、ブロック割り当てとブロックマッピング (ディスク上のメタデータツリーですでに割り当てられているブロックのルックアップ) を監視し、アクセスの局所性に関する問題を確認できます。ログトレースポイントは、ジャーナルに書き込まれ、ジャーナルから公開されるデータを追跡し、GFS2 の対象部分に関する有用な情報を提供できます。

トレースポイントは、できるだけ汎用性が保たれるように設計されています。つまり、Red Hat Enterprise Linux 8 を使用している場合には API を変更する必要がありません。一方、このインターフェイスを使用している場合は、これがデバッグインターフェイスであり、通常の Red Hat Enterprise Linux 8 API セットの一部ではないことを認識する必要があります。そのため、Red Hat では、GFS2 トレースポイントのいんたターフェースが変更されないことを保証できません。

トレースポイントは、Red Hat Enterprise Linux の汎用機能で、トレースポイントの対象範囲は GFS2 をはるかに超えています。特に、トレースポイントは、blktrace インフラストラクチャーの実装に使用されており、blktrace トレースポイントを GFS2 のトレースポイントと組み合わせて使用して、システムパフォーマンスの全体像を把握できます。トレースポイントの動作レベルでは、非常に短い時間で大量のデータを生成できます。トレースポイントは、有効になったときにシステムにかかる負荷が最小限になるように設計されていますが、何らかの影響は避けられません。さまざまな方法でイベントをフィルタリングすることで、データ量が減り、特定の状況を理解するのに有用な情報だけを取得することに集中できます。

debugfs が、/sys/kernel/debug ディレクトリーの標準的な場所にマウントされていると仮定すると、トレースポイントは /sys/kernel/debug/tracing/ ディレクトリーの下にあります。events サブディレクトリーには、指定可能なすべてのトレーシングイベントが格納されます。gfs2 モジュールが読み込まれると、各 GFS2 イベントごとにサブディレクトリーを含む gfs2 サブディレクトリーが現れます。/sys/kernel/debug/tracing/events/gfs2 ディレクトリーの内容は以下のようになります。

[root@chywoon gfs2]# ls
enable            gfs2_bmap       gfs2_glock_queue         gfs2_log_flush
filter            gfs2_demote_rq  gfs2_glock_state_change  gfs2_pin
gfs2_block_alloc  gfs2_glock_put  gfs2_log_blocks          gfs2_promote

すべての GFS2 トレースポイントを有効にするには、次のコマンドを入力します。

[root@chywoon gfs2]# echo -n 1 >/sys/kernel/debug/tracing/events/gfs2/enable

特定のトレースポイントを有効にするために、各イベントサブディレクトリーに enable ファイルがあります。これは、各イベントまたはイベントのセットにイベントフィルターを設定するために使用できる filter ファイルにも当てはまります。各イベントの意味は、以下で詳しく説明します。

トレースポイントからの出力は、ASCII またはバイナリーの形式で提供されます。現在、この付録ではバイナリーインターフェイスに関する説明は含まれません。ASCII インターフェイスは 2 つの方法で利用できます。リングバッファーの現在の内容をリスト表示するには、以下のコマンドを実行します。

[root@chywoon gfs2]# cat /sys/kernel/debug/tracing/trace

このインターフェイスは、一定期間にわたって長時間実行しているプロセスを使用し、イベントの後にバッファー内の最新のキャプチャー情報を確認する必要がある場合に便利です。代替インターフェイスである /sys/kernel/debug/tracing/trace_pipe は、すべての出力が必要な場合に使用できます。イベントは、発生時にこのファイルから読み取られます。このインターフェイスを介して利用可能な履歴情報はありません。出力の形式は両方のインターフェイスで同じであり、各 GFS2 イベントはこの付録の後のセクションで説明します。

トレースポイントのデータの読み取りには、trace-cmd と呼ばれるユーティリティーを利用できます。このユーティリティーの詳細は、 http://lwn.net/Articles/341902/ を参照してください。trace-cmd ユーティリティーは strace ユーティリティーと同様に使用することができ、さまざまなソースからトレースデータを収集している間にコマンドを実行できます。

GFS2 を理解するために、理解する必要がある最も重要な概念で、他のファイルシステムと区別されるのは、glocks の概念です。ソースコードの観点から、glock は、DLM を統合して 1 台のマシンにキャッシュするデータ構造です。各 glock は、1 つの DLM ロックと 1:1 の関係を持ち、そのロック状態のキャッシュを提供します。これにより、ファイルシステムの 1 つのノードから実行される反復操作が DLM を繰り返し呼び出す必要がないため、不要なネットワークトラフィックを回避できます。glock には、メタデータをキャッシュするカテゴリーとキャッシュしない広範なカテゴリーが 2 つあります。inode の glock およびリソースグループの glock の両方がキャッシュメタデータをキャッシュし、他のタイプの glock はメタデータをキャッシュしません。inode の glock はメタデータに加えてデータのキャッシングにも関与し、すべての glock の中で最も複雑なロジックを持っています。

Glock は、(別のノードの要求または仮想マシンの要求で) ロックが解除されるまでメモリー内に残り、ローカルユーザーはありません。この時点で、glock ハッシュテーブルから削除され、解放されます。glock が作成されると、DLM ロックは glock に即座に関連付けられません。DLM ロックは、DLM への最初の要求時に glock に関連付けられます。この要求が成功すると、I(initial) フラグが glock に設定されます。glock debugfs インターフェイス の Glock Flags の表は、さまざまな glock フラグの意味を示しています。DLM が glock に関連付けられていると、DLM ロックは、少なくとも解放されるまで常に NL (Null) ロックモードのままになります。NL からロック解除への DLM ロックの降格は、常に glock の有効期間時の最後の操作になります。

各 glock には多数のホルダーを関連付けることができ、それぞれが上位レイヤーからのロック要求を表します。コードの重要なセクションを保護するために、GFS2 キューに関連するシステムコールおよびホルダーを glock のキューからからキューから取り出します。

glock 状態のマシンはワークキューに基づいています。パフォーマンス上の理由から、タスクレットを使用することが推奨されます。ただし、現在の実装では、そのコンテキストから I/O を送信し、使用を禁止する必要があります。

以下の表は、各 glock モードでキャッシュされる状態と、キャッシュされた状態がダーティーである可能性があるかどうかを示しています。これは、inode ロックとリソースグループロックの両方に適用されますが、リソースグループロック用のデータコンポーネントはなく、メタデータのみです。

glock debugfs インターフェイスを使用すると、glock とホルダーの内部の状態を視覚化でき、場合によってはロックされたオブジェクトの概要情報も含まれます。ファイルの各行は、インデントなしで G: で始まるか (glock 自体を参照します)、または 1 つのスペースでインデントされた別の文字で始まり、ファイル内のそのすぐ上にある glock に関連付けられた構造を参照します (H: ホルダー、I: i ノード、R: リソースグループ)。このファイルの内容の例は、以下のようになります。

G:  s:SH n:5/75320 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:3/258028 f:yI t:EX d:EX/0 a:3 r:4
 H: s:EX f:tH e:0 p:4466 [postmark] gfs2_inplace_reserve_i+0x177/0x780 [gfs2]
 R: n:258028 f:05 b:22256/22256 i:16800
G:  s:EX n:2/219916 f:yfI t:EX d:EX/0 a:0 r:3
 I: n:75661/219916 t:8 f:0x10 d:0x00000000 s:7522/7522
G:  s:SH n:5/127205 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:2/50382 f:yfI t:EX d:EX/0 a:0 r:2
G:  s:SH n:5/302519 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/313874 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/271916 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/312732 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]

上記の例は、1 つのノードの GFS2 ファイルシステムでポストマークのベンチマークの実行時に、cat /sys/kernel/debug/gfs2/unity:myfs/glocks >my.lock コマンドにより生成された (約 18MB ファイルからの) 一連の抜粋です。この図の glock は、glock ダンプのより興味深い機能のいくつかを示すために選択されています。

glock の状態は、EX (排他的)、DF (据え置き)、SH (共有)、または UN (ロック解除) になります。この状態は、DLM null ロック状態を表す可能性がある UN を除いて、または GFS2 が DLM ロックを保持しないことを除いて、DLM ロックモードに直接対応します (上記の I フラグにより異なります)。glock の s: フィールドはロックの現在の状態を示し、ホルダーの同じフィールドは要求されたモードを示します。ロックが許可されると、ホルダーのフラグに H ビットが設定されます (f: フィールド)。設定されていない場合は、W wait ビットが設定されます。

N: フィールド (数値) は、各項目に関連付けられた番号を示します。glock の場合、タイプ番号の後に glock 番号が続くため、上記の例では最初の glock は n:5/75320 となり、inode 75320 に関連する iopen glock を示します。inode と iopen glock の場合、glock 番号は常に inode のディスクブロック番号と同じになります。

ホルダーと glock の両方に対するフラグの完全一覧は、Glock Flags の表と、Glock ホルダー の Glock Holder Flags の表に記載されています。ロック値のブロックの内容は、現在 debugfs インターフェイスからは利用できません。以下の表は、さまざまな glock タイプの意味を示しています。

重要な glock フラグの 1 つは、l (locked) フラグです。これは、状態変更が行われるときに glock 状態へのアクセスを調整するのに使用されるビットロックです。これは、ステートマシンが DLM を介してリモートロック要求を送信するときに設定され、完全な操作が実行された場合にのみ消去されます。これは、複数のロック要求が送信され、その間にさまざまな無効化が発生することを意味します。

以下の表は、さまざまな glock フラグの意味を示しています。

ローカルノードで保持されているノードと競合するモードでロックを取得する必要のあるノードからリモートコールバックを受け取ると、D (降格) または d (降格保留) のフラグのいずれかが設定されます。特定のロックの競合が発生した場合の枯渇状態を防ぐために、各ロックには最小保持時間が割り当てられます。最小保持時間の間にロックされていないノードは、その期間が経過するまでロックを保持できます。

期間が過ぎると、D (降格) フラグが設定され、必要な状態が記録されます。この場合、次にホルダーキューに許可されたロックがなくなると、ロックが降格になります。期間が過ぎていない場合は、代わりに d (降格保留) フラグが設定されます。また、これによりステートマシンが d (降格保留) を消去し、最小保持期間が過ぎた場合に D (降格) を設定します。

glock に DLM ロックが割り当てられている場合は、I (初期) フラグが設定されます。これは、glock が最初に使用され、最終的に glock が解放されるまで (DLM ロックが解除されるまで)I フラグが設定された状態が続く場合に発生します。

以下の表は、さまざまな glock ホルダーフラグの意味を示しています。

前述のように、それぞれ許可されたロック要求とキューに追加されたロック要求に設定されるため、ホルダーフラグで最も重要となるのは H (ホルダー) および W (待機) です。リスト内でのホルダーの順序は重要です。許可されたホルダーがある場合は常にキューの先頭にあり、その後にキューに追加されているホルダーが続きます。

許可されたホルダーがない場合は、リストの最初のホルダーが次の状態変更をトリガーするホルダーになります。降格要求は常にファイルシステムからの要求よりも高い優先順位で考慮されるため、要求された状態が直接変更されるとは限りません。

glock サブシステムは、2 種類の try ロックに対応しています。これらは、(適切なバックオフと再試行により) 通常の順序からロックを解除でき、他のノードで使用されているリソースを回避するために使用できるため役立ちます。通常の t (試行) ロックは、その名前が示すとおりです。特別なことは行わない試行ロックです。一方、T (try 1CB) ロックは、DLM が現在互換性のないロックホルダーにコールバックを 1 つ送信するのを除き、t ロックと同じです。T (try 1CB) ロックには、iopen ロックがあります。これは、inode の i_nlink 数がゼロの場合にノード間の調整に使用されます。また、inode の割り当てに対応するノードを決定します。iopen glock は通常、共有状態で保持されますが、i_nlink リンク数がゼロになり、→evict_inode() が呼び出されると、T (try 1CB) セットによる排他的ロックが要求されます。ロックが許可されると、inode の割り当て解除が継続されます。ロックが許可されていない場合は、ロックの付与を妨げていたノードが glock を D (降格) フラグでマークします。これは、割り当て解除が忘れられていないことを確認するために、→drop_inode() 時間で確認されます。

つまり、リンク数がゼロであるがまだ開いている inode が、最後の close() が発生したノードによって割り当て解除されます。また、inode のリンク数もゼロにデクリメントされますが、inode はリンク数がゼロの特別な状態にあるとマークされますが、引き続きリソースグループのビットマップで使用されています。これは ext3 ファイルシステム 3 の孤立リストと同様に機能し、ビットマップの後続のリーダーは、再利用される可能性のある領域があることを認識し、再利用を試みることができます。

また、トレースポイントは、blktrace 出力と組み合わせたり、ディスク上のレイアウトの知識を組み合わせたりして、キャッシュ制御の正確さを確認できるように設計されています。次に、特定の I/O が発行され、正しいロックの下で完了したこと、および競合が存在しないことを確認できます。

gfs2_glock_state_change トレースポイントを理解することは、最も重要なものです。これは、glock の最初の作成から最後の降格までのすべての状態変化を追跡します。最後の降格は、gfs2_glock_put とロック解除の遷移までの最後の NL で終わります。glock フラグの l (locked) は、常に状態が変更される前に設定され、終了するまで削除されません。状態変更中は、許可されたホルダー (H glock ホルダーフラグ) が存在することはありません。キューに格納されたホルダーがある場合、それらは常に W (waiting) 状態になります。状態の変更が完了すると、glock の l フラグを削除する前の最後の操作で、ホルダーを付与できます。

gfs2_demote_rq トレースポイントは、ローカルおよびリモートの両方の降格要求を追跡します。ノードに十分なメモリーがある場合、ローカルの降格要求はほとんど発生せず、多くの場合は umount または場合によってはメモリーの再取得によって作成されます。リモート降格要求の数は、特定の inode またはリソースグループのノード間の競合の測定値です。

gfs2_glock_lock_time トレースポイントは、DLM への要求に要した時間に関する情報を提供します。このトレースポイントと組み合わせて使用するために、ブロック (b) フラグが glock に導入されました。

ホルダーにロックが付与されると、gfs2_promote が呼び出されます。これは、glock 状態が適切なモードのロックをすでにキャッシュしているため、状態変更の最終段階、または即時に付与できるロックが要求されたときに発生します。ホルダーがこの glock に付与される最初のホルダーである場合は、f (最初の) フラグがそのホルダーに設定されます。これは現在、リソースグループでのみ使用されます。

ブロックマッピングは、どのファイルシステムでも中心となるタスクです。GFS2 は、ブロックごとに 2 ビットとなる従来のマテリアルベースのシステムを使用します。このサブシステムにおけるトレースポイントの主な目的は、ブロックの割り当ておよびマッピングにかかる時間の監視を可能にすることです。

gfs2_bmap トレースポイントは、各 bmap 操作で 2 回呼び出されます。まずは bmap リクエストを表示するとき、次に終了時に結果を表示するときです。これにより、要求と結果を容易に一致させ、ファイルシステムの異なる部分、異なるファイルオフセット、または異なるファイルのブロックをマッピングするのに要した時間を測定できます。返されたエクステントサイズの平均と、要求されるエクステントサイズを比較することもできます。

gfs2_rs トレースポイントは、ブロックアロケーターで作成、使用、破棄されたブロック予約を追跡します。

割り当て済みブロックを追跡するには、割り当てだけでなく、ブロックの解放でも gfs2_block_alloc を呼び出します。割り当てはすべて、ブロックの対象となる inode に従って参照されるため、これを使用して、どの物理ブロックがライブファイルシステムのどのファイルに属しているかを追跡できます。これは blktrace と組み合わせると特に便利です。これにより、問題のある I/O パターンが表示され、このトレースポイントで取得したマッピングを使用して、関連する inode に戻って参照されることがあります。

ダイレクト I/O (iomap) は、ディスクとユーザーのバッファー間でファイルデータ転送を直接実行することができる別のキャッシュポリシーです。これは、キャッシュヒット率が低いと予想される状況で利点があります。gfs2_iomap_start トレースポイントおよび gfs2_iomap_end トレースポイントの両方がこれらの操作を追跡し、ダイレクト I/O、および操作タイプでダイレクト I/O のファイルシステム上の位置を追跡するのに使用できます。

このサブシステムのトレースポイントは、ジャーナル (gfs2_pin) に追加されたブロックや削除されたブロックと、ログ (gfs2_log_flush) へのトランザクションのコミットにかかった時間を追跡します。これは、ジャーナリングのパフォーマンス問題をデバッグしようとする際に非常に便利です。

gfs2_log_blocks トレースポイントは、ログ内の予約ブロックを追跡し、たとえば、ログがワークロードに対して小さすぎるかどうかを表示するのに役立ちます。

gfs2_ail_flush トレースポイントは、AIL リストのフラッシュの開始と終了を追跡する点で gfs2_log_flush トレースポイントと似ています。AIL リストには、ログが通過したけど書き込まれていないバッファーが含まれています。これは、ファイルシステムで使用できるようにログ領域を解放するため、またはプロセスが sync または fsync を要求したときに定期的にフラッシュされます。

GFS2 は、ファイルシステム内で何が発生しているかを追跡するのに役立つ統計を維持します。これにより、パフォーマンスの問題を特定できます。

GFS2 は、2 つのカウンターを維持します。

また、GFS2 では、平均と分散のペアが維持されます。平均/分散ペアは平滑化された指数予測であり、使用されるアルゴリズムはネットワークコードで往復時間を計算するために使用されるものです。

GFS2 で維持される平均と分散のペアは見積もられませんが、整数のナノ秒で表されます。

ブロック以外の要求とは、問題の DLM ロックの状態に関係なく、すぐに完了する要求のことです。これは現在、(a) ロックの現在の状態が排他的、(b) 要求された状態が null またはアンロックである、または (c) try lock フラグが設定されている場合の要求を意味します。ブロックリクエストは、他のすべてのロックリクエストに対応します。

時間が長いほど IRTT に適していますが、時間が短いほど RTT に適しています。

統計は sysfs ファイルに保存されます。

トレースポイントと GFS2 glocks ファイルに関する詳細情報は、以下の資料を参照してください。

GFS2 PMDA が正しく動作するには、debugfs ファイルシステムをマウントする必要があります。debugfs ファイルシステムがマウントされていない場合は、GFS2 PMDA をインストールする前に以下のコマンドを実行します。

# mkdir /sys/kernel/debug
# mount -t debugfs none /sys/kernel/debug

GFS2 PMDA は、デフォルトのインストールでは有効になっていません。PCP で GFS2 メトリックの監視を使用するには、インストール後に有効にする必要があります。

以下のコマンドを実行して PCP をインストールし、GFS2 PMDA を有効にします。PMDA インストールスクリプトは root で実行する必要があることに注意してください。

# yum install pcp pcp-pmda-gfs2
# cd /var/lib/pcp/pmdas/gfs2
# ./Install
Updating the Performance Metrics Name Space (PMNS) ...
Terminate PMDA if already installed ...
Updating the PMCD control file, and notifying PMCD ...
Check gfs2 metrics have appeared ... 346 metrics and 255 values

pminfo ツールは、利用可能なパフォーマンスメトリックに関する情報を表示します。以下の例は、このツールで表示可能なさまざまな GFS2 メトリックを示しています。

# pminfo -f gfs2.glocks

gfs2.glocks.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glocks.shared
    inst [0 or "afc_cluster:data"] value 25
    inst [1 or "afc_cluster:bin"] value 25

gfs2.glocks.unlocked
    inst [0 or "afc_cluster:data"] value 43652
    inst [1 or "afc_cluster:bin"] value 2063

gfs2.glocks.deferred
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glocks.exclusive
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

# pminfo -f gfs2.glstats

gfs2.glstats.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glstats.trans
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

gfs2.glstats.inode
    inst [0 or "afc_cluster:data"] value 17
    inst [1 or "afc_cluster:bin"] value 17

gfs2.glstats.rgrp
    inst [0 or "afc_cluster:data"] value 43642
    inst [1 or "afc_cluster:bin"] value 2053

gfs2.glstats.meta
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

gfs2.glstats.iopen
    inst [0 or "afc_cluster:data"] value 16
    inst [1 or "afc_cluster:bin"] value 16

gfs2.glstats.flock
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.quota
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.journal
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

# pminfo -f gfs2.holders.flags.wait

gfs2.holders.flags.wait
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pmstore gfs2.control.tracepoints.all 1
gfs2.control.tracepoints.all old value=0 new value=1

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.latency.grant.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.latency.demote.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.tracepoints.promote.other.null_lock
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.exclusive
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.demote_rq.requested

gfs2.tracepoints.demote_rq.requested.remote
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.demote_rq.requested.local
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.log_flush.total]

gfs2.tracepoints.log_flush.total
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

次の表は、GFS2 ファイルシステム用の pcp-pmda-gfs2 パッケージが提供するパフォーマンスメトリックの全リストを説明します。

以下の手順では、Red Hat Enterprise Linux で統計を収集するために最小限の PCP 設定をインストールする方法を説明します。この設定は、詳細な分析のためにデータを収集するために必要な、実稼働システムに最低限のパッケージを追加します。

結果として得られる pmlogger 出力の tar.gz アーカイブは、追加の PCP ツールを使用して分析でき、他のソースのパフォーマンス情報と比較できます。