第18号(2008年3月)

記事:Red Hat Enterprise Linux 5 でクラスタストレージ

前号にて、Red Hat Enterprise Linux 5 Advanced Platform（以下RHEL5APと記述）に同梱され、高いご評価を頂いている2つのクラスタコンポーネントのうち、負荷分散クラスタ及びフェイルオーバクラスタを提供するRed Hat Cluster Suiteについてご紹介いたしました。今号では、Red Hat Global File System（以下GFSと記述）をご紹介いたします。

・Red Hat Global File Systemを20秒で理解する
Red Hat Global File SystemはPOSIX準拠で64bitクリーンなクラスタファイルシステムです。GFSのアドバンテージは3つあります。1つめは、複数ノードから FC-SAN上の同一データ領域に対して矛盾しない読み/書きアクセスが可能です。2つめは、障害ノードからデータを保護する機構を持つことです。3つめは、ファイルシステムのキャッシュ機能をバイパスするダイレクトI/Oの機能を持つことです。さぁ20秒解説はおしまいです。詳しい解説にうつりましょう。

・クラスタ化されるシステムとデータ共有
今、スケールアウトすることでパフォーマンスを向上させることができるwebシステムがあるとします。スケールアウトされたwebサーバは全て同一のデータを保持する必要があります。データがほとんど更新されない静的なものであれば、更新データをコピーし同一のデータを保持することは容易でしょう。

しかし、刻々と変化するデータだった場合はどうでしょうか。サーバ間のデータコピーおよび同一性をメンテナンスすることはより困難なものになり、システムの管理は複雑化します。このシステムに必要なのは、スケールアウトされた全webサーバが共通にアクセスできるデータ領域です。このように企業にはデータ共有の必要なシステムが多数存在します。そして、それはSANやNASによって実装されてきました。

・NFSからGFSへ
データ共有の従来型のアプローチとして、NFSやCIFSを利用したNASがありますが、NFSの抱える問題について考えてみます。ご存じのようにNFSはサーバ/クライアント方式のシステムであり、NFSサーバはクライアントに対してデータ共有を提供します。1つめは、単一のNFSサーバは多くの場合、システムのボトルネックになりやすく、かつ、Single Point of Failureになってしまうことです。

2つめは、充分とは言えないデータ転送速度は、エンタープライズ環境で求められる用件を満たせない場合もあります。3つめとして、サーバが一括してロックを管理するアーキテクチャは効率的ですが、ロックを保持したクライアントに障害が起きた場合、NFSサーバはロックを保持し続けてしまうという致命的な欠点です。

これらに対して、GFSはクラスタメンバ間で協調しながらロックを管理するため、NFSのようなパフォーマンスのボトルネックやSingle Point of Failureは存在しません。必要であればファイバチャネルと言う選択肢もあります。また、各クラスタメンバ毎にロックを保持するため、ノード障害時にロックが開放されない、という問題もありません。このように、GFSはスケーラブルなパフォーマンスとキャパシティ、高い可用性をシステムに提供します。
その使用用途や構成等、詳細なGFSとNFSの比較についてはRed Hat GFS vs. NFS: Improving performance and scalability(英語)をご参照下さい。

・改めて、Red Hat Global File Systemとは
次にSANを利用したデータ共有について考えます。SANによってサーバはブロックデバイスを共有することが出来ますが、データベース等例外を除いて多くのアプリケーションはデバイスを直接扱うことを想定していないため、ファイルシステムが必要になります。ファイルシステムはOSが提供する非常に重要な1コンポーネントですが、ext3のようなローカルファイルシステムは、1台のサーバ上でデータを扱うように設計されており、サーバをまたがってデータを共有することを想定していません。

そのため、ext3のようなファイルシステムを通じて、共有しているブロックデバイスにアクセスしてしまった場合、ファイルに対するサーバ間の排他制御が考慮されないためファイルを壊してしまいます。この問題を解決するために使用されるのが、クラスタファイルシステムです。従来はストレージベンダの提供する高価なクラスタファイルシステムが利用されてきましたが、今日ではGFSを利用することが可能です。GFSはブロックデバイスを共有するノードがクラスタを構成し、分散ロック機構を通じて、ファイルに対する矛盾しない読み/書きアクセスを提供します。

・GFSのロックマネージャ
GFSはバージョンによって、dlm（Distributed Lock Manager）、gulm（Grand Unified Lock Manager）、nolockの3つのロック機構を使用します。Red Hat Enterprise Linux 5（以下version5と記述）はdlmを使用します。version4はdlmとgulmを、version3はgulmを使用します。gulmは1 台以上のロック管理専用のサーバが必要になります。nolockは文字通り、クラスタに対するロックを提供しないため、1台で構成されるシステムで使用されます。

dlmはクラスタメンバ間で互いに協調し、共有したブロックデバイスへのアクセスをコントロールします。dlmは大別すると、ロックマネージャ自身であるdlmカーネルモジュール、dlm_controld、libdlmと3つのコンポーネントで構成されます。libdlmはユーザランドのアプリケーションがdlmを使用する際に呼び出すライブラリです。dlm_controldは、dlmカーネルモジュールとユーザランドで動作するクラスタインフラの相互通信を担当します。ここでクラスタインフラとは、前号のRed Hat Cluster Suiteのコンポーネントにて紹介したcmanやOpenAISを指します。つまり、フェイルオーバクラスタを提供するCluster Managerも、クラスタストレージを提供するGFSも、共通のクラスタ基盤を利用して動作しています。

・ダイレクトI/O
データベース等のアプリケーションは、パフォーマンスのためにそれ自身がキャッシュ管理の機能を実装していることがあります。この場合、ファイルシステムが提供するキャッシングを利用する必要はないので、キャッシュ機能をバイパスします。このファイルシステムのキャッシングをバイパスすることを、ダイレクトI/Oと言い、GFSはこの仕組みを利用することができます。GFS上にoracle RACを構築することは典型的な利用例です。

ダイレクトI/Oは幾つかの方法で呼び出すことができます。1つめは、O_DIRECTフラグ付きでファイルオープンします。2つめは、ファイルにGFSダイレクトI/Oフラグを付加します。GFSダイレクトI/Oフラグを付加したファイルは、ファイルオープンの方法に関係なくダイレクトI/O が適用されます。3つめは、ディレクトリにGFS継承ダイレクトI/Oフラグを付加します。このフラグの付いたディレクトリ内にある全てのファイルとサブディレクトリはダイレクトI/Oの対象になります。これは新規作成されたサブディレクトリを含みます。

・まとめ
データ共有のために、SANとクラスタファイルシステムを採用することは、かつてはコストの高い選択肢だったかもしれません。しかし、SANの選択肢が増えたこと、かつ、GFSがRHEL5APに同梱されたことで、コストをかけずにスケーラブルなパフォーマンスとキャパシティ、そして高い可用性を持ったデータ共有の構成を採用することが可能になりました。もうNFSに悩まされる必要はありません。

前号、今号と2回にわたって、RHEL5APが提供するクラスタ機能についてご紹介いたしました。Red Hat Cluster Suiteが提供する負荷分散クラスタ及びフェイルオーバクラスタ、そして、そのクラスタ環境に単一のファイルアクセスを提供するGFSが同梱された RHEL5APが、オペレーティングシステムの枠を越えた、ITプラットフォームであることをご理解頂けたかと思います。ITプラットフォームとして RHEL5APを100倍使い倒して頂くための、エンタープライズクラスタリング/ストレージ管理のトレーニングコースもございますので、お気軽に sales-jp@redhat.comまでお問い合わせ下さい。

レッドハット株式会社/ニュースレター編集部