Show Table of Contents
このページには機械翻訳が使用されている場合があります (詳細はこちら)。
2.5. 使用に関する考慮事項
本セクションでは、GFS2 の使用に関する一般的な推奨事項について説明します。
2.5.1. マウントオプション: noatime と nodiratime
通常、GFS2 ファイルシステムは
noatime
および nodiratime
の引数を使用してマウントすることを推奨します。これにより、アクセスする度に 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 を使用すると、パフォーマンスに多少の影響が起こります。これを回避するには、Enforcing モードで SELinux を動作させているシステム嬢であっても GFS2 で SELinux を使用するべきではありません。GFS2 ファイルシステムをマウントする場合は、
mount
(8) man ページで説明されたように context
オプションのいずれかを使用して SELinux が各ファイルシステムオブジェクトの 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 を同時にエクスポートすることは現実的ではなくなるため、この設定を使用して同時に 1 つのノードに GFS2 ファイルシステムをマウントすることがサポート要件となります。これの目的は、各サーバからの POSIX ロックをローカルに強制することです。つまり、クラスタ化されておらず、互いに独立しています。なぜなら、GFS2 がクラスターのノード間で NFS から POSIX ロックを実装しようとすると、多くの問題が発生するためです。NFS クライアントで実行しているアプリケーションでは、別のサーバーから 2 台のクライアントがマウントしている場合に、ローカルの POSIX ロックにより、その 2 台のクライアントが同じロックを同時に保持することがあり、これによりデータが破損する場合があります。すべてのクライアントが 1 台のサーバーから 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 サーバーは、一つのクラスターノードから他のクラスターノードへのフェイルオーバーが可能です (アクティブ/パッシブ構成)。
- 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 ファイルサービスの処理速度を低下させるため現在、対応していません。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 ファイルシステムを使用する場合は、キャッシュを強制的に無効にするために各ノードの VM ストレージ設定を適切に設定することが重要です。たとえば、
cache
と io
に対するこれらの設定を libvirt
ドメインに含めると、GFS2 が期待どおりに動作します。
<driver name='qemu' type='raw' cache='none' io='native'/>
また、デバイス要素内で
shareable
属性を設定することができます。これは、デバイスがドメイン間で共有されることを意味します (ハイパーバイザーと OS でサポートされる場合)。shareable
が使用される場合は、そのデバイスに対して cache='no'
を使用する必要があります。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。