Red Hat® GFS 対 NFS: 性能と拡張性の改善
by Matthew O'Keefe
現代的なコンピューティングの世界にデータ共有は無くてはならないものです。クラスタ構成のサーバが汎用のストレージプールのデータにアクセスする必要がある場合、データインフラの簡素化、ストレージのコストの最小化、ストレージの稼働中の追加、連続稼働時間の最大化に対する答えは、Red Hat GFSです。
Red Hat GFSのようなクラスタファイルシステムは、IPネットワーク上でブロックデバイスを共有するiSCSIのようなプロトコルと共に利用され、低コストで拡張性の高いファイルサービスを提供します。Network File System（NFS）は多くのインフラで利用されている汎用の共有ストレージソリューションです。しかし、場合によっては、このソリューションは拡張できません。GFSとNFSは何が違うのでしょうか？ この記事で明らかにしましょう。
NFSの性能問題に直面しているRed Hat® Enterprise Linux®のカスタマが、LinuxのNFSクライアントしか所有していないのであれば、Red Hat GFSとiSCSIベースのIPブロックデバイスネットワークを利用することで、性能と拡張性を改善できる可能性が非常に高いといえます。
比較
NFSはLinuxとUNIXのファイル共有プロトコルとして一般的です。図1「NFSとRed Hat GFS/iSCSIのハードウェア構成の比較」は、クラスタ化されたサーバにおけるNFSとGFSによるデータ共有のハードウェア構成の違いを表しています。図1が示しているのは古くからある最も汎用的なNFSの配置：ローカルストレージを持つ単一のNFSサーバに数多くのクライアントがネットワークを介して接続されている様子です。GFSのデータ共有クラスタはiSCSIサーバと共に全く同一のハードウェアで構成されますが、実際にはもっと高性能です。さらに、NFSとは違ってGFSはローカルファイルシステムと同様、POSIX互換の動作もします。このことは、分散されたLinuxのアプリケーションが、POSIX互換のファイルシステムと同様、クラスタ全体にわたって、良好なパフォーマンスを達成できることを意味します。
- 注記：
- 特に、UNIX（とLinux）のプロセスがサポートするファイル同期を、NFSはサポートしません：UNIXでは、もしあるプロセスがファイルに書き込むと、後からそのファイルを読み込んだプロセスが、その書き込みを読み込めることを保証しています。NFSではそういった保証はなく、パフォーマンスの劣化を伴う、特定の書き込みキャッシュの設定をしなければなりません。
図2「対になっているNFSとRed Hat GFS/iSCSIサーバ」は、2台のNFSサーバがStorage Area Network（SAN）のバックエンドと共にフェイルオーバー構成されていることと、比較としてSANストレージと共に2台のiSCSIサーバを含むデータ共有クラスタの構成を表しています。
図1でみられるように、物理的な構成は同じですが、2つのシステムが実現する機能は全く異なります。NFSサーバは単にフェイルオーバーのペアとして動作するに過ぎません：ファイルを共有しているわけではなく、単なる物理的なブロックストレージです（各NFSサーバがSAN上の共有ボリュームにマップされるローカルファイルをエクスポートしています）。
2つの個別のファイルシステムがそれぞれ保持されなければならず、ある瞬間をみると、片方のNFSサーバしか、特定のファイルシステムへのNFSのリクエストを処理する能力を提供していません。対照的に、SANストレージにマップされる単一の共有ファイルシステムのデータ共有クラスタでは、2台のiSCSIサーバが協調して共有ファイルシステムへのアクセスを提供します。もし片方のiSCSIサーバがフェイルしても、GFSのサーバノードはその異常を回避して、動作しているiSCSIサーバを経由し、ストレージにアクセスできます。
図3「複数のNFSサーバとRed Hat GFS/iSCSIデータ共有クラスタ」は、4台のNFSと4台のiSCSIサーバ以上に拡張されたシステム構成を表しています。NFSサーバにはiSCSIのノードとは異なり、ストレージとしてSANが無いことに注意してください。各NFSサーバは単一のファイルシステムへのアクセスしか提供できないことを重要視してください。つまり、あるファイルシステムを提供する処理能力を増強するためにこれ以上のNFSサーバを追加することは不可能です。
対照的に、SAN経由で共有ストレージに接続されている4台のiSCSIサーバは、4台ともGFSサーバに対して処理能力を提供しています。実際、より多くのiSCSIサーバを追加して、データ共有クラスタを構成するGFSサーバの性能目標に見合うように、SANシステムに必要なパフォーマンスを漸次的に増強することができます。ストレージの能力もまた、SANに徐々に追加し、1つ以上のファイルシステムをまたぐように配置することが可能です。
図3におけるNFSサーバは、現実的には４つの「ストレージの孤島」であり、NFSサーバをまたぐストレージの性能と効率を悪い意味で受け継いでしまいます。
まとめ
Red Hat GFSはiSCSIストレージネットワークと組み合わせることで、NFS単体で達成できるよりもより高い性能を提供できます。
| GFS/iSCSI 対 NFS | GFS/iSCSI | NFS |
|---|---|---|
| クライアントの拡張性 | 300以上 | 10-20もしくは高負荷時にはより少ない台数 |
| サーバとクライアント間の帯域 | 無制限 | NFSサーバの最大帯域によって制限 |
| 大規模拡張時の複雑性 | 同一のボリュームで単一の名前空間を保持することで複雑性を排除し、管理を簡素化する | 大規模拡張では、NFSファイルシステムは個別のボリュームにまたがるように分割せざるを得ず、管理の複雑さを増大し、達成できる性能を制限してしまう |
| POSIX互換 | Yes。 最後に書き込まれたデータを常に読み出すことが可能で、アプリケーションを破壊しない |
No。 最後に書き込まれたデータを読み込めるかどうかは不確定 |
| 小規模拡張、低いパフォーマンスの環境 | GFS/iSCSIはコスト効率を小規模拡張、低いパフォーマンスの環境にもスケールダウンできる | NFSが得意とするのは小規模（5-10クライアント）で、低いパフォーマンスの環境のみ |
参考文献
Red Hat GFSとRed Hat Enterprise Linuxに関するより多くの情報は、以下のウェブサイトを参照してください。
- jp.redhat.com: Red Hat Enterprise Linux
- jp.redhat.com: Red Hat Global File System
- redhat.com: Red Hat Cluster Suite
著者の紹介
1990年から2000年5月まで、Matthew O'Keefeはミネソタ大学で電子コンピュータエンジニアリングの教授として教鞭を執り、ストレージシステムの研究と並列シミュレーションのソフトウェアの研究を行いました。2000年5月にSistina Softwareを創立し、Linux用のストレージインフラソフトウェアの開発をし、その中にGlobal File System（GFS）とLinux Logical Volume Manager（LVM）が含まれていました。Sistinaは2003年12月にRed Hatにより買収され、Matthewは現在ストレージソフトウェア戦略を指揮しています。
原文(英語)はこちら
