2.5. 使用に関する考慮事項

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

2.5.1. マウントオプション: noatime と nodiratime

通常、GFS2 ファイルシステムは noatime および nodiratime の引数を使用してマウントすることを推奨します。これにより、アクセスする度に GFS2 がディスク inode を更新する時間を短縮することができます。

2.5.2. 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.5.3. SELinux: GFS2 では SELinux の使用を回避する

ほとんどの状況で Security Enhanced Linux (SELinux) の使用が安全確保のために強く推奨されていますが、GFS2 での使用には対応していません。SELinux はすべてのファイルシステムオブジェクトに関する拡張属性を使用して情報を格納し、GFS2 ファイルシステムの SELinux ラベルはメモリーでキャッシュされる方法のため、クラスターノード間で同期が取れなくなることがあります。
GFS2 ファイルシステムをマウントする場合は、mount(8) man ページで説明されたように 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 を使用する必要があります。5章クラスターでの GFS2 ファイルシステムの設定 で説明されているように、GFS2 ファイルシステムリソースを作成するときはマウントオプションを指定できます。

2.5.4. GFS2 上における NFS セットアップ

GFS2 のロッキングサブシステムおよびクラスター化の特性は複雑度が高いため、GFS2 上で NFS をセットアップするにあたっては、数多くの予防措置を取り、細心の注意を払う必要があります。本セクションでは、GFS2 ファイルシステム上で NFS サービスを設定するにあたって考慮すべき注意事項について説明します。

警告

GFS2 ファイルシステムが NFS でエクスポートされ、NFS クライアントアプリケーションが POSIX ロックを使用する場合は、localflocks オプションを使用してファイルシステムをマウントする必要があります。この目的は、各サーバーからの POSIX ロックをローカル (つまり、クラスター化されず、相互に独立した状態) として強制的に設定することです (GFS2 が NFS からクラスターのノード全体で POSIX ロックを実装しようとすると、複数の問題が発生します)。NFS クライアント上で実行されているアプリケーションでは、2 台のクライアントが異なるサーバーからマウントしている場合、ローカルの POSIX ロックにより、それら 2 台のクライアントが同じロックを同時に保持することがあります。すべてのクライアントが単一のサーバーから NFS をマウントする場合は、異なるサーバーが同じロックを別々に許可するという問題が解消されます。localflocks オプションでファイルシステムをマウントするべきかどうかがわからない場合は、このオプションを使用しないでください (ロックはクラスターベースで使用する方が安全です)。
GFS2 システム上で NFS サービスを設定する際には、ロックについて考慮する以外に、以下のような点も検討する必要があります。
  • Red Hat は、以下のような特性を持つアクティブ/パッシブ構成のロックを備えた NFSv3 を使用する Red Hat High Availability アドオン設定のみをサポートしています。
    • バックエンドファイルシステムは、2〜16 のノードクラスターで稼働している GFS2 ファイルシステムです。
    • NFSv3 サーバーは、単一クラスターノードから GFS2 ファイルシステム全体を一度にエクスポートするサービスとして定義されます。
    • NFS サーバーは、一つのクラスターノードから他のクラスターノードへのフェイルオーバーが可能です (アクティブ/パッシブ構成)。
    • NFS サーバー経由 以外の GFS2 ファイルシステムへのアクセスは許可されません。これには、ローカルの GFS2 ファイルシステムアクセスと、Samba または クラスター化された Samba を介したアクセスの両方が含まれます。
    • システム上で NFS クォータはサポートされていません。
    この構成では、ノードで障害が発生しても、NFS サーバーをあるノードから別のノードへフェイルオーバーするときに fsck コマンドを実行する必要がないため、ファイルシステムに高可用性 (HA) が提供され、システムダウンタイムが削減されます。
  • fsid= NFS オプションは、GFS2 の NFS エクスポートには必須です。
  • クラスターに問題が生じた場合 (例: クラスタが定足数に達せず、フェンシングが失敗した場合) には、クラスター化された論理ボリュームと GFS2 ファイルシステムはフリーズされ、クラスターが定足数を満たすようになるまではアクセスできません。この手順で説明したような、単純なフェイルオーバー解決方法がご使用のシステムに最も適切かどうかを判断する際には、この可能性を考慮する必要があります。

2.5.5. GFS2 上の Samba (SMB または Windows) ファイルサービス

アクティブ/アクティブ構成が可能な CTDB を使用する GFS2 ファイルシステムから Samba (SMB または Windows) ファイルサービスを使用できます。
Samba 外からの Samba 共有内のデータへの同時アクセスには対応していません。GFS2 クラスターのリースは Samba ファイルサービスの処理速度を低下させるため現在、対応していません。

2.5.6. GFS2 用仮想マシンの設定

仮想マシンで GFS2 ファイルシステムを使用する場合は、キャッシュを強制的に無効にするために各ノードの VM ストレージ設定を適切に設定することが重要です。たとえば、cache と io に対するこれらの設定を libvirt ドメインに含めると、GFS2 が期待どおりに動作します。 
<driver name='qemu' type='raw' cache='none' io='native'/>
また、デバイス要素内で shareable 属性を設定することができます。これは、デバイスがドメイン間で共有されることを意味します (ハイパーバイザーと OS でサポートされる場合)。shareable が使用される場合は、そのデバイスに対して cache='no' を使用する必要があります。