NetApp Tech OnTap
コンピュートクラスタにおける共有データへのアクセスの高速化

科学技術アプリケーション、エンジニアリングアプリケーション、ビジネスアプリケーションなど、多様なアプリケーションを実行する今日のコンピュートクラスタでは、共有データへのアクセスがパフォーマンスを大きく左右します。NFSは最も広く利用されている共有データへのアクセスプロトコルですが、大規模なコンピュートクラスタではボトルネックになりかねません。共有ファイルシステムに含まれる全ファイルの唯一のアクセスポイントとなるファイルサーバでは、NFSのために処理の停滞が起こる可能性があります。

図1 コンピュートクラスタの規模が大きくなるにつれ、標準的なNFSファイルサーバがボトルネックになる可能性があります。スループット(T)がサーバの限界に近づくと、遅延時間(L)が許容不可能なレベルにまで増大します。

残念ながら、共有データへのアクセスパフォーマンスの向上に対応したソリューションのほとんどは、多かれ少なかれ各社の独自仕様で設計されています。そのため、NFSなどの標準プロトコルで可能な異種混在システムのサポートや汎用性は提供されません。

パラレルNFS(pNFS)は、NFSバージョン4.1のプロトコル規格に新たに追加された仕様です。pNFSは単一サーバのボトルネック解消に役立ち、パラレルデータアクセス用のソリューションとして、今後広く利用されることになるでしょう。本稿ではpNFSの仕組みを説明するとともに、標準化への取り組み状況について紹介します。


pNFSの概要


pNFSプロトコルを利用すると、2台以上のデータサーバにストライピングされたファイルに、各クライアントから直接アクセスできます。複数のデータサーバに並行してアクセスするため、クライアントのI/Oの所要時間が大幅に短縮されます。pNFSプロトコルは、標準的なNFSプロトコルとの下位互換性を維持しながら、クライアント単位およびファイル単位で優れたパフォーマンス向上を達成できるよう設計されています。そのため各クライアントは、pNFSの拡張機能が実装されていなくても、引き続きデータにアクセスできます。

pNFSアーキテクチャとコアプロトコル

pNFSアーキテクチャは、次の3つの主要コンポーネントで構成されています。
  • メタデータサーバ(MDS):データトラフィック以外のすべてのトラフィックを処理します。メタデータサーバは、各ファイルの格納場所および格納方法を示したメタデータの保持に使用されます。
  • データサーバ:ファイルデータの格納先であり、クライアントの読み取り/書き込み要求に直接応答します。ファイルデータは複数のデータサーバにストライピングできます。
  • 1つ以上のクライアント:メタデータサーバから取得したメタデータ情報に基づいて、データサーバに直接アクセスできます。
クライアント、メタデータサーバ、およびデータサーバ間では、次の3種類のプロトコルが使用されます。
  • 制御プロトコル:メタデータサーバとデータサーバの間で同期処理に使用されます。
  • pNFSプロトコル:クライアントとメタデータサーバの間で使用されます。実質的には、pNFS固有の拡張仕様を実装したNFSv4を表します。pNFSプロトコルは、レイアウト(複数のデータサーバに格納されたファイルにアクセスするため、格納場所および必要なストレージアクセスプロトコルを記述したメタデータを含む)の取得と操作に使用されます。
  • クライアントが使用する一連のストレージアクセスプロトコル:データサーバへのダイレクトアクセスに使用されます。pNFS仕様には現在、3つのカテゴリのストレージプロトコル(ファイルベース、ブロックベース、およびオブジェクトベース)が含まれています。これらのプロトコルを使用することで、pNFSでは多様なレイアウトタイプに対応し、さまざまな種類のストレージインフラをサポートできます。

レイアウトタイプ

採用すべきストレージアクセスプロトコルは、基盤となるデータサーバ上のストレージの種類によって決まります。クライアントは、メタデータサーバから送信されたファイルレイアウトによって、ファイルの各ストライプの格納場所およびアクセス方法や、使用するプロトコルに関する情報を入手します。

  • ファイルレイアウトを選択した場合、pNFSでは複数のNFSv4.1ファイルサーバをデータサーバとして使用します。NFSv4自体は、ファイルアクセスプロトコルとして使用されます。
  • ブロックレイアウトを選択した場合、ディスクLUNがStorage Area Network(SAN;ストレージエリアネットワーク)上でホストされます。SCSIブロックコマンドセットを使用するSANデバイスには、iSCSIまたはFibre Channel(FC)プロトコルでアクセスします。
  • オブジェクトレイアウトを選択した場合、データをオブジェクトベースストレージデバイス(OSD)に格納できます。データへのアクセスには、標準化作業中のT-10オブジェクトベースストレージデバイスプロトコルが使用されます。
ファイルアクセスの例

図2 pNFSの諸要素。クライアントはメタデータサーバにレイアウトを要求してから(1.pNFSプロトコル)、データサーバに直接アクセスします(2.ストレージアクセスプロトコル)。

レイアウトタイプには関係なく、クライアントはファイルにアクセスするために必ずメタデータサーバに接続し、ファイルをオープンしてレイアウトを要求します。クライアントは受信したファイルレイアウトの情報を使用して、以降はメタデータサーバを介在させることなく、適切なストレージアクセスプロトコルを適用し、複数のデータサーバと直接かつ並行してI/Oを実行します。I/Oが完了すると、クライアントはメタデータサーバに修正したメタデータを送信し、ファイルをクローズします。

レイアウトタイプの選択

次に、pNFSで使用するレイアウトを決定する際、考慮すべき条件を示します。

前提条件

  • NASフレームワークを前提とする場合は明らかに、ファイルレイアウトを選択するのが最適です。既存のNASシステムおよびネットワークを使用できます。
  • 既存のFC SANを使用する場合は、ブロックベースレイアウトを選択するのが妥当です。
  • ゼロの状態から環境を構築する場合は、以降の説明をご確認ください。

ネットワークインフラ

  • ファイルベースレイアウトでは、既存のNASストレージおよび既存のイーサネットインフラを使用できます。必ずしも帯域幅を増やす必要はありません。
  • ブロックベースまたはオブジェクトベースレイアウトの場合、最も一般的に使用されるのはFC SANです。データサーバに直接アクセスするには、すべてのクライアントをFC SANに接続する必要があります。iSCSIを使用すると、FC SANよりもコストを低く抑えることができます。

セキュリティ

  • ファイルベースバックエンドを使用する場合は、Kerberos認証やACLなどを使用して、標準的なNFSサーバと同様の方法でデータサーバごとにセキュリティ対策を行います。セキュリティ強化には従来の一般的な方法を使用できます。
  • ブロックベースまたはオブジェクトベースバックエンドでpNFSを使用する場合、pNFSクライアント側でセキュリティ設定を行うのは困難です。クライアントはクライアントオペレーティングシステムの一部であるため、クライアントに実装されているセキュリティ機能(実装されていない場合もあります)は、あまり変更できない可能性があります。言い換えると、クライアントの実装方式の選択肢が少ないとも言えます。したがって、セキュリティ設定をデータサーバで行うレイアウトのほうが、使い勝手は良いでしょう。

マルチクライアントアクセスと管理

  • ファイルベースレイアウトでは、2つの異なるpNFSクライアントから、同じファイルの同じ論理領域に対して同時に読み取りまたは書き込み処理を実行できます。
  • ブロックベースまたはオブジェクトベースレイアウトでは、ファイル領域には一度に1つのpNFSクライアントだけしか書き込み処理を実行できません。

拡張性

  • オブジェクトベースバックエンドストレージでは、拡張性が制限される可能性があります。

pNFSの現状


pNFS規格

pNFSが含まれるNFSv4.1は、Internet Engineering Task Force(IETF)内で多くの参加者によって標準化が進められています。ワーキンググループには、NetApp、EMC、IBM、ミシガン大学、Sun Microsystemsなど、大手ストレージ/システムベンダーおよび研究機関から、分野を越えた多くのメンバーが参加しています。NFSv4.1およびpNFSの標準化は完了間近であり、IETFでは2008年中に最終的な仕様を完成させる予定です。

NetAppはこのワーキンググループの共同議長として、NFSv4.1およびpNFSの作成について主導的な役割を担ってきました。また、NFSv4.1仕様のかなりの部分は、NetAppが作成および編集しています。NetAppではこうした活動を、業界標準によるストレージの諸問題の解決という、当社の一貫したポリシーに基づいて行っています。

IETFによるNFSv4.1およびpNFSの仕様については、IETF NFSv4ワーキンググループのWebサイト(英語)を参照してください。

NFSv4.1/pNFSのテスト

かつてのNFSがそうであったように、pNFSの普及には相互接続性が不可欠です。クライアントマシンとサーバマシンのシームレスな連携は、pNFSの導入を促進する要因となります。2005年3月以来、さまざまなpNFSの実装方式について、相互接続性テストが実施されています。NFSv4.1およびpNFSについては、ハードウェアとソフトウェアの相互接続性テストを実施するベンダー中立フォーラムの、Connectathonでテスト済みです。

そのほかにも、年に何回かBake-a-thonが実施されています。直近のBake-a-thonは2008年9月に実施され、6つのpNFSサーバ実装方式および2つのクライアント実装方式がテストされました。NFSv4.1仕様とpNFS仕様はどちらもまったく問題がなく、このプロトコルの標準化は順調に進んでいます。pNFSのテストの最新情報については、NFSに関するMikeのブログ(英語)をチェックしてみてください。

Linuxクライアントおよびサーバの開発

pNFSの利用価値が最も高いと思われるのは科学技術やエンジニアリングなどのアプリケーションですが、これらの多くで利用されるコンピュートクラスタは、Linux®をベースとするものが一般的です。そのため、これらのアプリケーションのパフォーマンスのニーズを満たすような、使い勝手の良い動作確認済みのLinux用pNFSクライアントが必要とされています。このニーズを認識したNetAppをはじめとする複数の企業は、安定したLinux用pNFSクライアントの開発に注力しています。完成度の高いLinux用クライアントが実現すれば、Linuxのメインラインカーネルにも実装されるでしょう。そうなれば、追加ソフトウェアのインストールや保守を行うことなく、Linuxマシン上でpNFSを使用できるようになります。

NetAppはpNFSクライアントおよびファイルレイアウトドライバの開発に大きく貢献しているほか、Linux用サーバの開発も進めています。クライアントだけでなくシンプルなpNFSサーバを完成させることで、pNFSを導入するためのテスト、概念実証、および試験運用に使用するプラットフォームを提供できます。

まとめ

間もなく標準化が終わるpNFSは、多くのベンダーでサポートされ、既存のストレージインフラの活用手段として役立ちます。pNFSがアプリケーションに提供できるI/Oパフォーマンスは、単一のファイルサーバよりも優れているため、ハイパフォーマンスなパラレルI/Oを実現する標準プロトコルとして、今後幅広く導入されることになるでしょう。


Mike Eisler Mike Eisler
NetApp、シニアテクニカルディレクター

MichaelはNetAppのサーバ仮想化技術者のリーダーであり、ストレージテクノロジに関しては13年以上に及ぶ経験があります。NetAppに入社する以前は、EMC Corporationで上級システムエンジニア兼ソリューションアーキテクトとして勤務し、Compaqの上級テクノロジコンサルタントを務めた経験もあります。

Joshua Konkle Joshua Konkle
NetApp、NASおよびエンジニアリングアプリケーション担当テクニカルエバンジェリスト

Joshuaは、お客様の生産性向上に役立つテクノロジおよびソリューションの普及活動を行っています。彼はUNIX®とWindows®の両方に精通し、特にセキュリティを専門としています。これまでに、多くの業界および技術関連イベントで、ストレージとセキュリティに関するさまざまな講演を行った経験があります。


関連情報