Red Hat Training

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

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

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

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

通常、noatime 引数および nodiratime 引数を使用して GFS2 ファイルシステムをマウントすることが推奨されます。これにより、アクセスする度に GFS2 がディスク inode を更新する時間を短縮することができます。GFS2 ファイルシステムパフォーマンスにおける、これら 2 つの引数の効果は、「GFS2 のノードロック機能」 を参照してください。

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. GFS2 上の SELinux

Red Hat Enterprise Linux 7.4 以降では、GFS2 ファイルシステムで Security Enhanced Linux (SELinux) を使用できます。
GFS2 で 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 を使用する必要があります。5章クラスターでの GFS2 ファイルシステムの設定 の説明に従って、GFS2 ファイルシステムリソースを作成する際にマウントオプションを指定できます。

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

GFS2 ロッキングサブシステムとそのクラスターの複雑性を考慮し、GFS2 での NFS の設定には、多くの予防措置をとり、注意深く設定を行う必要があります。本セクションでは、GFS2 ファイルシステムで NFS サービスを設定する際に考慮すべき注意事項を説明します。
警告
GFS2 ファイルシステムが NFS でエクスポートされる場合は、localflocks オプションを指定してファイルシステムをマウントする必要があります。localflocks オプションを指定すると、複数の場所から GFS2 ファイルシステムに安全にアクセスできなくなるため、GFS2 を複数のノードから同時にエクスポートすることはできません。そのため、この設定を使用する際に、GFS2 ファイルシステムを一度に 1 つのノードにのみマウントすることが対応要件となります。この目的は、各サーバーからの POSIX ロックをローカル (つまり、クラスター化されず、相互に独立した状態) として強制的に設定することです。これは、GFS2 が NFS からクラスターのノード全体で POSIX ロックを実装しようとすると、複数の問題が発生するためです。NFS クライアントで実行しているアプリケーションでは、2 台のクライアントが異なるサーバーからマウントしている場合は、ローカライズされた POSIX ロックにより、それら 2 台のクライアントが同じロックを同時に保持することがあります。これにより、データが破損する可能性があります。すべてのクライアントがあるサーバーから NFS をマウントすると、同じロックを個別サーバーに付与するという問題が発生しなくなります。localflocks オプションでファイルシステムをマウントするかどうか不明な場合は、このオプションを使用しないでください。データの損失を回避するためにも、すぐに Red Hat サポートに問い合わせ、適切な設定について相談してください。NFS 経由で GFS2 をエクスポートすることは、一部の状況において技術的には可能ですが推奨されません。
NFS を除くすべての GFS2 アプリケーションでは、localflocks を使用してファイルシステムをマウントしないでください。これにより、GFS2 はクラスター (クラスター全体) におけるすべてのノード間で POSIX のロックと flocks を管理できます。localflocks を指定して NFS を使用しないと、クラスター内のその他のノードは相互の POSIX ロックと flocks を認識しないため、クラスター環境において不安定になります。
GFS2 ファイルシステムで NFS サービスを設定する際には、ロックについて考慮する以外に、以下のような点も検討する必要があります。
  • Red Hat は、以下のような特性を持つアクティブ/パッシブ構成のロックを備えた NFSv3 を使用する Red Hat High Availability Add-On 設定のみをサポートしています。
    • バックエンドファイルシステムは、2〜16 のノードクラスターで稼働している GFS2 ファイルシステムです。
    • NFSv3 サーバーは、単一クラスターノードから GFS2 ファイルシステム全体を一度にエクスポートするサービスとして定義されます。
    • NFS サーバーは、1 つのクラスターノードから他のクラスターノードへのフェイルオーバーが可能です (アクティブ/パッシブ構成)。
    • NFS サーバー経由を 除いて、GFS2 ファイルシステムへのアクセスは許可されていません。これには、ローカルの GFS2 ファイルシステムアクセスと、Samba または クラスター化 Samba によるアクセスの両方が含まれます。マウント元のクラスターノードからローカルにファイルシステムにアクセスすると、データが破損する可能性があります。
    • システムで NFS クォータはサポートされていません。
    この構成では、ノードで障害が発生しても、NFS サーバーをあるノードから別のノードへフェイルオーバーするときに fsck コマンドを実行する必要がないため、ファイルシステムに高可用性 (HA) が提供され、システムダウンタイムが削減されます。
  • GFS2 の NFS エクスポートには NFS オプション fsid= が必須です。
  • クラスターで問題が発生した場合 (たとえば、クラスターが定足化し、フェンシングが成功しなくなるなど) は、クラスター化論理ボリュームと GFS2 ファイルシステムがフリーズし、クラスターが定足化されるまでアクセスできなくなります。この手順で定義されているような単純なフェイルオーバーソリューションがシステムにとって最も適しているかどうかを判断する際には、これを考慮してください。

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

アクティブ/アクティブ構成が可能な CTDB を使用する GFS2 ファイルシステムから Samba (SMB または Windows) ファイルサービスを使用できます。
Samba の外部から Samba 共有のデータへの同時アクセスには対応していません。現在、GFS2 クラスターリースはサポート外で、Samba ファイル処理の速度が低下します。Samba のサポートポリシーの詳細は、Red Hat カスタマーポータルの 「Support Policies for RHEL Resilient Storage - ctdb General Policies」および「Support Policies for RHEL Resilient Storage - Exporting gfs2 contents via other protocols」を参照してください。

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

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