Parallel NFS を使ってファイルシステムのスケーリングを行う

毎秒何百ギガバイトものデータを読み書きする

Comments

NFS はサーバー・ソフトウェアとクライアント・ソフトウェア、そしてそれらの間で実行されるプロトコルから構成されます。NFS を利用することで、あるコンピューターが持つ物理的なファイルシステムは、同じネットワークに接続されている他の多くのコンピューターと共有できるようになります。また NFS では、サーバーのファイルシステムの実装やタイプを隠すことができ、NFS クライアント上で実行されるアプリケーションから見ると、共有ファイルシステムはあたかもローカルのネイティブ・ストレージのように見えます。

図 1 は異種混成のオペレーティング・システムから成るネットワークに NFS を展開した場合の一般的な例を示しています。オペレーティング・システムには Linux®、Mac OS X、Windows® が含まれ、いずれも NFS 標準をサポートしています。(NFS は IETF (Internet Engineering Task Force) がサポートしている唯一のファイルシステム標準です。)

図 1. 単純な NFS の構成
単純な NFS の構成
単純な NFS の構成

この図では NFS サーバーとなっている Linux マシンが、このマシンに接続されている 1 つあるいは複数の物理ファイルシステムを共有、つまり (NFS の用語では) エクスポートします。Mac OS X マシンと Windows マシンは NFS クライアントです。各マシンは共有ファイルシステムを利用、つまりマウントします。もちろん、NFS ファイルシステムをマウントすると、ローカル・ドライブのパーティションをマウントした場合と同じ結果になります。つまりアプリケーションはマウントされると単純にファイルを読み書きし、アクセス制御の対象となりますが、データを永続化するために必要な機構を意識することはありません。

NFS によって共有されるファイルシステムの場合、読み書き操作はクライアント (この図では、例えば Windows マシン) とサーバーとの間で行われ、サーバーは最終的に要求に応じてデータを取得したり、データを永続化させたり、あるいはファイルのメタデータ (パーミッションや最終更新時刻など) を変更したりします。

※訳注: 上記段落の原文にある「represented by the blue shadow」は、おそらく読み書き操作の様子を図に青い影を付けて表すつもりだったと思われますが、図 1 にはそのような青い影がないので、訳出していません。

NFS は NAS (Network Attached Storage) として広く使われていることからもわかるように、非常に高機能であり、TCP (Transmission Control Protocol) と UDP (User Datagram Protocol) のどちらを利用しても実行することができ、管理も (比較的) 簡単です。さらに、NFS バージョン 4 (標準として承認されている最新のバージョン) ではセキュリティーが改善され、Windows システムと UNIX® ライクなシステムとの相互運用性がさらに高められており、またロック・リースによって相互排他性能が改善されています (NFSv4 は2003年に承認されました)。NFS のインフラは安価ですが、これは通常 NFS が一般的なイーサネット・ハードウェア上で適切に動作するためです。NFS は大部分の問題領域に適しています。

しかし従来 NFS ではうまく対応できなかった 1 つの領域が、HPC (High-Performance Computing) の領域です。HPC ではデータ・ファイルが非常に大きく (ときには巨大と言えるほどです)、また NFS クライアントの数は何千台にも達します。(何千台ものありふれた計算ノードで構成されるコンピューティング・クラスターまたはコンピューティング・グリッドを考えてみてください。) こうした場合には、NFS がパフォーマンスの妨げとなります。つまり、NFS サーバーの限界 (例えば帯域幅であったり、ストレージ容量であったり、あるいはプロセッサー速度であったり) によって全体としての計算動作のパフォーマンスが制限されてしまい、NFS がボトルネックになるのです。

少なくとも、今まではそうでした。

NFS の次期バージョンであるバージョン 4.1 には pNFS (Parallel NFS) と呼ばれる拡張機能が含まれており、pNFS は現状の NFS の持つさまざまなメリットと並列 I/O (Input and Output) によって実現される非常に高い転送レートとを併せ持っています。pNFS を利用すると、サーバー上のファイルシステムは今までと同じくクライアントとの間で共有されますが、データは NFS サーバーを経由しません。これまでとは違ってクライアント・システムとデータ・ストレージ・システムは直結され、膨大なデータを転送するために膨大な数の並列高速データ・パスが提供されます。簡単な初期化とハンドシェークが終わると pNFS サーバーは「ループの外」に置かれるため、pNFS サーバーが原因で転送レートが劣化することはなくなります。

図 2 は pNFS の構成を示しています。上側にはコンピューティング・クラスターのノード群 (例えば大量の安価な Linux ベースのブレードなど) があります。左側にあるのは NFSv4.1 サーバーです (ここでは単に pNFS サーバーと呼ぶことにします)。下側には大規模な並列ファイルシステムがあります。

図 2. pNFS の構成の概念
pNFS の構成の概念
pNFS の構成の概念

NFS の場合と同様、pNFS サーバーはファイルシステムをエクスポートし、データ・ストアの中にある各ファイルすべてを記述した基準となるメタデータを保持、管理します。また NFS の場合と同様、pNFS クライアント (この場合はクラスター内のノード) はサーバーがエクスポートしたファイルシステムをマウントします。NFS の場合と同様、各ノードはあたかも物理的に接続されたローカルのファイルシステムであるかのようにファイルシステムを扱います。メタデータの変更はネットワークを経由して pNFS サーバーに伝達されます。しかし NFS の場合とは異なり、データの読み書きは pNFS によって管理され、ノードとストレージ・システムそのものとの間で直接行われます (図 2 の下側を参照)。pNFS サーバーはデータのやり取りから除外されるため、pNFS には明らかなパフォーマンスのメリットがもたらされます。

このように、pNFS は NFS の便利さや細かな点をすべてそのまま保持しつつも、NFS に比べてパフォーマンスとスケーラビリティーが改善されています。さらに pNFS ではクライアントの数を増やして計算能力を増強することができ、またストレージ・システムのサイズを拡張してもクライアントの構成にほとんど影響を与えません。pNFS に関して行わなければならないことは、カタログ・システムとストレージ・システムとを常に同期させておくことのみです。

pNFS の仕組み

では pNFS はどのように動作するのでしょう。図 3 では pNFS が 3 つのプロトコルの集合として実装されています。

図 3. pNFS の 3 つのプロトコル
pNFS の 3 つのプロトコル
pNFS の 3 つのプロトコル

pNFS プロトコルは、pNFS サーバーとクライアント・ノードとの間でファイルのメタデータ (正式にはレイアウトと呼ばれます) を転送する際に使われます。レイアウトはマップと考えることができ、データ・ストアの間でファイルがどのように分散されるか (例えば複数のスピンドル間でファイルがどうストライピングされているか、など) を記述します。さらにレイアウトにはパーミッションやその他のファイル属性が含まれています。メタデータがレイアウトの中に取り込まれ、pNFS サーバーに永続化されると、ストレージ・システムは単純に I/O を実行します。

ストレージ・アクセス・プロトコルは、クライアントがデータ・ストアからデータにアクセスする方法を指定します。ご想像のとおり、各ストレージ・アクセス・プロトコルによって独自のレイアウト形式が定義されます。これはアクセス・プロトコルとデータの構成が一致している必要があるためです。

制御プロトコルは、メタデータ・サーバーの状態とデータ・サーバーの状態との同期を取る際に使われます。同期化動作 (例えば、媒体上のファイルの再構成など) はクライアントからは見えません。またこの制御プロトコルは NFSv4.1 では規定されていないため、さまざまな形式を取ることができ、ベンダーはパフォーマンスやコスト、機能などで自由に競争することができます。

これらのプロトコルを元に、クライアントがアクセスするプロセスを追うと次のようになります。

  1. クライアントは、クライアントが持っているファイルに対するレイアウトを要求します。
  2. クライアントはメタデータ・サーバー上のファイルを開くことでアクセス権を取得します。
  3. 認証され、レイアウトが与えられると、クライアントはデータ・サーバー上の情報に直接自由にアクセスすることができます。アクセス動作はそのデータ・ストアのタイプに応じたストレージ・アクセス・プロトコルに従って進められます。(これについては下記でさらに説明します。)
  4. クライアントがファイルを変更すると、それに従ってクライアントのレイアウト・インスタンスも変更され、すべての変更はメタデータ・サーバーにコミットされます。
  5. そのファイルがクライアントにとって必要なくなると、クライアントは残っているすべての変更をコミットし、そのクライアントが持っているレイアウトのコピーをメタデータ・サーバーに返し、そのファイルを閉じます。

もっと具体的に言うと、読み取り動作は次のような一連のプロトコルの動作として行われます。

  1. クライアントは pNFS サーバーに LOOKUP+OPEN 要求を送信します。サーバーはファイル・ハンドルと状態情報を返します。
  2. クライアントは LAYOUTGET コマンドを使ってサーバーにレイアウトを要求します。サーバーはファイルのレイアウトを返します。
  3. クライアントはストレージ・デバイスに READ 要求を発行します。それによって、複数の読み取り操作が並行して開始されます。
  4. クライアントが読み取りを終了すると、クライアントは LAYOUTRETURN を使って読み取り操作の終了を表現します。
  5. クライアントとの間で共有されているレイアウトが別のアクティビティーによって古くなった場合には、サーバーは CB_LAYOUTRECALL を発行し、そのレイアウトがもはや有効ではなく、消去と再取得のいずれか、または両方が必要なことを示します。

書き込み動作も読み取り動作と似ていますが、クライアントは LAYOUTRETURN を発行する前に LAYOUTCOMMIT を発行し、ファイルへの変更を pNFS サーバーに対して「公開」する必要がある点が異なります。

レイアウトは各クライアントにキャッシュされるため速度がさらに向上し、またクライアントはレイアウトを使わなくなったらそのレイアウトを自主的にサーバーから解放することができます。またサーバーは、クォータの制約を避けるため、あるいは割り当てのオーバーヘッドを減らすためなどの理由から、書き込みレイアウトのバイト範囲を制限することもできます。

古くなったキャッシュの中身が参照されるのを防ぐため、メタデータ・サーバーは不正確になったレイアウトの再呼び出しを行います。再呼び出しが行われると、それに続いて、再呼び出しの影響を受けるすべてのクライアントは I/O を停止しなければなりません。そして新たにレイアウトを取得するか、単純な NFS を使ってそのファイルにアクセスする必要があります。再呼び出しは、サーバーが何らかのファイル管理 (マイグレーションや再ストライピングなど) を行う前には、必ず行わなければなりません。

ストレージ内で割り当てられた場所こそが問題

先ほど触れたように、各ストレージ・アクセス・プロトコルではレイアウトのタイプを指定しますが、新しいアクセス・プロトコルやレイアウトを自由に追加することもできます。pNFS を迅速に広く普及させるために、pNFS を作成しているベンダーや研究者達は既に、ファイル、ブロック、オブジェクトによるデータ・ストアという 3 種類のストレージ手法を定義しています。

  • ファイル・ストレージは従来の NFS サーバー (Network Appliance 社の製品など) で一般的に実装されています。ストレージ・ファームは NFS サーバーの集合として実現され、各ファイルはサーバー群 (のサブセットまたは全体) にわたってストライピングされるため、クライアントはファイルのさまざまな部分を同時に取得することができます。この場合、レイアウトには、ファイルの各部分や各サーバー上のストライプのサイズ、そして各セグメントの NFS ファイル・ハンドルを保持するサーバーが列挙されます。
  • ブロック・ストレージは、多くのディスクつまり RAID アレイから成る SAN (storage-area network) の場合に非常によく実装されます。SAN のソリューションは、IBM や EMC をはじめとする多くのベンダーによって提供されています。ブロック・ストレージの場合、ファイルはブロックに分割され、そのブロックが複数のドライブに分散されて保持されます。ファイル・ブロックと物理的なストレージ・ブロックとの対応付けは、ブロック・ストレージのレイアウトによって行われます。ブロック・ストレージでのストレージ・アクセス・プロトコルは SCSI のブロック・コマンド・セットです。
  • オブジェクト・ストレージはファイル・ストレージに似ていますが、ファイル・ハンドルがオブジェクト ID で置き換えられており、またストライピングが多様で複雑、そして高機能である点が異なります。

どのようなタイプのレイアウトを使用する場合であっても、pNFS は共通の仕組みを使ってサーバーを参照します。サーバーは、ホスト名やボリューム名ではなく、固有の ID で参照されます。この ID は、そのアクセス・プロトコル専用のサーバー参照に対応付けられます。

これらのストレージ手法のうち、どれが良いのでしょう。その答えは「状況次第」です。予算、速さ、スケール、単純さ、その他さまざまな要因をすべて含めて検討する必要があります。

pNFS の現状

pNFS への投資を考える前に、pNFS の現状を見てみましょう。

2008年11月におけるこの記事の執筆時点で、NFSv4.1 に対する RFC (Request for Comments) のドラフトが「ラスト・コール」の段階に入ろうとしています。ラスト・コールは、RFC を公開して業界全体での精査を受ける前段階として、コメントを収集して検討するために設けられている 2 カ月の期間です。

RFC に盛り込まれ、ドラフトとして提案されている標準は、広く一般に公開されると同時に実際の製品を開発するための確固とした基礎になります。今後のレビュー期間中に標準に加えられる変更はごくわずかなものと予想されるため、ベンダーは実際に動作する販売可能なソリューションの設計や構築を今から進めることができます。おそらく来年のどこかの時点で、複数の会社から製品を入手できるようになるはずです。

今すぐということであれば、ミシガン大学の Git リポジトリーから pNFS のオープンソース・プロトタイプ実装の Linux 版を入手することができます (「参考文献」のリンクを参照)。IBM、Panasas 社、Netapp 社、そしてミシガン大学の CITI (Center for Information Technology Integration) が NFSv4.1 と Linux 用 pNFS の開発を積極的に進めています。

オープンソースの並列ファイルシステム・クライアントとしての pNFS の可能性は計り知れないものがあります。(Top500 の調査によるランキングで) 世界最速のスーパーコンピューターであり、しかもペタフロップに達した最初のコンピューターは、Panasas 社が構築した並列ファイルシステム (pNFS のオブジェクト・ベースの実装をサポートするシステム) を使っています (ペタフロップは毎秒千兆回の演算を意味します)。Roadrunner と呼ばれ、米国のロス・アラモス国立研究所に置かれた巨大なシステム (図 4 に写真があります) は、12,960 個のプロセッサーを持ち、Linux を実行し、タイプの異なるプロセッサーの混成によって構築された最初のスーパーコンピューターです。AMD の Opteron X64 プロセッサーと IBM の Cell Broadband Engine™ の両方を使って計算が実行されています。2006年、Roadrunner は Panasas 社による並列ファイルシステムの初期バージョンを使って、ピーク値で毎秒 1.6 ギガバイトの転送レートを示しました。2008年には、Roadrunner による並列ストレージ・システムは毎秒数百ギガバイトという転送レートを維持することができています。対照的に、従来の NFS での典型的なピーク値は毎秒数百メガバイトです。

図 4. 世界で最初にペタフロップを記録した Roadrunner
世界で最初にペタフロップを記録した Roadrunner
世界で最初にペタフロップを記録した Roadrunner

NFSv4.1 標準と pNFS 全体が NFS 標準から大幅に改善されており、その変更は 1980年代に Sun Microsystems の Bill Joy が最初に考案してから 20 数年経過した技術に対する最も劇的なものです。5 年間の開発期間を経て、NFSv4.1 と pNFS は今や (あるいはまもなく) スーパーコンピューティング・マシンにスーパー・ストレージの速さを提供するための準備が完了しています。

ここまで将来を見てきました。そしてこれからは並列ストレージの時代なのです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=355285
ArticleTitle=Parallel NFS を使ってファイルシステムのスケーリングを行う
publish-date=11262008