囲い込まれた分散データを支援するOpenAFS

次世代のNFSライクなファイル・システムが、頭の痛いデータ問題の解答となるかもしれない

分散ファイル・システムが最近まであまり報道されてこなかったのは、それを利用しているのがほとんど企業や教育機関のネットワークであり、合計利用者数が数千人にすぎなかったからです。概念として、このようなシステムが複雑なオープン・ソース・ファイル・システムにどのように組み込まれるのか、常に明確なわけではありません。Open Andrew File System(OpenAFS)は成熟したテクノロジーであり、ユーザー数の増大に対応できる拡張性を備えているだけで管理コストを軽減しないNetwork File System(NFS)の代替となります。

Frank Pohlmann (frank@linuxuser.co.uk), U.K. Technical Editor, Linuxuser and Developer

Frank Pohlmann は中東の宗教の歴史を少し学びましたが、その後様々な援助委員会が、宗教の歴史に関する研究は現代世界にほとんど関係がないと判断してしまいました。それ以来、彼は趣味であるフリー・ソフトウェアに集中しています。彼は自分がイギリスにある Linuxuser & Developer の技術編集者であることを認めており、彼が Linux や FreeBSD の世界に入ったのは、ライターやアーティストのための UNIX カーネル内部や Linux アプリケーションに強い興味を持っているためです。



2005年 5月 17日

ユーザーはファイル・システムという概念を2通りに理解しています。1つは、ファイル、ファイルを含むディレクトリー、およびディレクトリー構造を保持するパーティションを組織化する手段です。そして第2に、ファイル・システムは、ファイルを組織化して生のメタルにマップする手段です。当然、仮想ファイル・システム(VFS)と実メモリ管理ルーチンなど、この2つの中間に位置する層もありますが、ユーザーからアクセス可能な構造化された情報の管理に関して、パワー・ユーザーがファイル・システムの内部を覗き込んで、カーネル深奥部の硫黄の臭いをかいでみるのは理にかなったことです。

メタルはRAMまたはハード・ディスクで構成されていますが、いずれにしても、ハードウェア製造業者によってフォーマットされたセクターとバイトを組織化するのは、ファイル・システム・データ構造です。かなり大雑把ですが、ユーザーは日常の作業において、このような概念の対立をあまり気にせずに過ごすことができます。たとえば、特定のサイズ以上のファイルへのアクセスを高速化するツールが利用できます。また、ディレクトリーとファイルの再編成を容易にするツールもありますが、これらのツールでは、ビット、バイト、およびセクターを気にする必要がありません。

ファイル・システムのメタ概念

この概念的区別の古典的な例として、FreeBSD(BSD UNIXRの世界に端を発します)がUNIX File System V2(UFS2)を使用してディスク上のデータを組織化する方法や、Flash File System(FFS)を使用してファイルをディレクトリーにまとめ、ディレクトリー・アクセスを最適化する方法に見られます。LinuxRシステムは、少し違います。Linuxでは、1つや2つではなく、さらに多くのファイル・システムが本来的に使用可能だからです。したがって、VFS層によって、Linuxユーザーは、Linuxがメモリーを管理する方法をあまり気にすることなく、新しいファイル・システム・サポートを追加することができます。

静的なジャーナル・ファイル・システムのような区別について話すときには、ファイル・システムの内容の一貫性とある程度までのセキュリティを強調しています。また、BSD UNIXの世界で物事を見るために使用されていた用語では、静的なジャーナル・ファイル・システムは、UNIX File System(UFS)がファイルを組織化し保護する方法に関連しています。Journal File System(JFS)、次世代ファイル・システム(XFS)、および初期のReiserFSが使用可能になっていたので、Linuxファイル・システムはジャーナル・ファイル・システムを包含していましたが、テクニカル・ジャーナリズムや企業報道のいずれにおいても、あまり光を当てられていないもう1つの分野が分散ファイル・システムです。


NFSから学んだこと

この状況は、今日、ネットワーク規模のファイル・システム層をTCPまたはUDP(User Datagram Protocol)経由で多数のユーザーが使用できるようにするのは無謀と考えられているという事実に関係があります。V3以前のNFSには恐ろしいストーリーが付きまとっていたため、数十人以下のネットワークを管理している多くの管理者を敬遠させることになりました。さらに、非常に高速なマザーボード・アーキテクチャーにサポートされたマルチプロセッサ・アーキテクチャーの登場で、分散ファイル・システム問題の優先順位が下がったようです。インテリジェントに実装された分散システムによってではなく、ハードウェアによってスピードが保証されたようです。分散ファイル・システムが基本のファイル・システム実装、たとえば、既存のext2、ext3、およびReiserFSファイル・システム・ドライバーに依存する傾向があることから、分散ファイル・システムは、大規模な大学ネットワークや一時的な科学ネットワークや企業ネットワークの領域に限られているようです。

では、分散ファイル・システムは、すでに述べた2つの層の上にある第3の層なのでしょうか。現代のネットワーキングにおける大きな問題の1つは、異種ネットワークの連携が増えてきたことです。(Sambaが好例です。)しかし、今日では、ファイル・システムという舞台には3人の主役がいることを理解する必要があります。すなわち、MicrosoftR WindowsRファイル・システム・グループ(FAT16、FAT32、およびNTFSファイル・システム)、Apple Mac OS X(HFS+)、およびネイティブLinuxジャーナル・ファイル・システム(ほとんどはReiserFSとext3)です。SambaはWindowsとLinuxファイル・システムの連携を助けますが、すべての主要なファイル・システム上のファイルへのアクセスを等しく高速かつ管理しやすくするわけではありません。

NFS V4はこの問題を解決する試みと言えるかもしれませんが、NFS V4に関するRFC(Request for Comments)3530は発表されてからわずか2年であり、カーネルV2.6用のNFS4がかなり新しいことを考えると、実動サーバーとして推奨するにはためらいがあります。Fedoraコア2および3には、NFS4パッチとNFS4ユーティリティーが付属し、開発者によるかなり印象的な進展を見せています。NFSでは、ネットワーク管理者は、より多くのポートを開き、神経質なユーザーにエクスポートされる各ネームスペースについて個別のクライアントを構成する必要があったからです。RFC 3530は、セキュリティに関する懸念のほとんどを解決しています。それでも、NFSディレクトリーは個別にマウントする必要があります。統一サインオンとKerberosを使用してセキュリティを高めることができますが、そのための余分な作業が必要です。


OpenAFSの原理

OpenAFSは、異なるファイル・システムを連携させるためのソフトウェアのインストールと管理の負担を取り除こうとしています。また、OpenAFSは、異なるファイル・システムの効率的な連携を可能にします。UNIXとその魅力的な後継者であるPlan 9のもともとのメタファーはファイルでしたが、商業の現実が命じたのは、現在のネットワーク化ファイル・システムを完全に再構築することではなく、別の分散ファイル・システム層を追加しなければならないということでした。

カーネギー・メロン大学のプログラマーたちがAFSを開発したのは1983年でした。その後まもなく、同大学はAFSに基づくサービスを販売するTransarcという会社を設立しました。IBMは1998年にTransarcを買収し、OpenAFSという名前でAFSをオープン・ソース製品にしました。しかし、神話はここで終わるわけではありません。OpenAFSからCodaやArlaなど、後で述べる他の分散ファイル・システムが生まれたからです。すべての主要なオペレーティング・システム用のクライアントが存在し、時代遅れのものもありますが、ドキュメンテーションも豊富です。Gentoo.orgはOpenAFSをLinuxユーザーにとって使用可能なものにするために特に努力しましたが、他の組織では、分散ファイル・システムが必要なときには、いまだにNFSを好んで使用しているようです。


OpenAFSアーキテクチャー

OpenAFSは、セルと呼ばれるファイル・サーバーのグループを中心として編成されます。各サーバーの識別は、通常、ファイル・システムそのものの下に隠されています。AFSクライアントからログインしたユーザーは、自分がどのサーバーで作業しているのかわかりません。ユーザーから見ると、認識可能なUNIXファイル・システム・セマンティクスを持った単一のシステムで作業しているように見えるからです。ファイル・システムの内容は、通常、セル内で複製されるので、1台のハード・ディスクが故障しても、OpenAFSクライアントでの作業に支障はありません。OpenAFSでは、よく使用されるファイルへのアクセスを可能にするために、最大1GBの大容量クライアント・キャッシング機能が必要とされます。また、完全にセキュアなKerberosベースのシステムとして動作し、アクセス制御リスト(ACL)を使用して、通常のLinuxおよびUNIXセキュリティ・モデルでは不可能なきめ細かなアクセスを可能にしています。

たまたまOpenAFSの一部であるキャッシュ・マネージャーは例外ですが(ためしに、基本ファイル・システムとしてext2を実行しているものなど)、OpenAFSの見かけの基本構造は最近のNFS実装に似ています。しかし、基本アーキテクチャーはまったく違うので、どのような類似点も懐疑的な目で見る必要があります。やはりNFSが使いやすいが、OpenAFSの機能も利用したいという人は、いわゆるNFS/AFSトランスレーターを使用することもできます。OpenAFSクライアント・マシンがNFSサーバー・マシンとして構成されている限り、両方のファイル・システムの利点を享受できるはずです。


OpenAFSが世界を管理する方法

NFSは位置依存型であり、ローカル・ディレクトリーをリモート・ファイル・システムの位置にマップします。OpenAFSは、ファイルの位置をユーザーから隠します。すべてのソース・ファイルがさまざまな複製ファイル・サーバー上の位置に読み取り/書き込み可能コピーとして保存されるので、複製コピーの同期をとらなければなりません。これにはUbikというテクノロジーを使用します。Ubikは、単語ubiquitousと東欧風のスペルによる言葉遊びです。Ubikプロセスは、AFSファイル・システム上のファイル、ディレクトリー、およびボリュームの同期を取りますが、通常、メリットが出るのは、4つ以上のファイル・サーバー・プロセスを実行しているシステムです。システム管理者は複数のAFSセルをAFSサイトにまとめることができます(昔のAFSの略語がOpenAFSファイル・システムのセマンティクスの中に残っています)。管理者は、AFSセルの量と、セルがサイト内の他のAFSセルに対して使用可能にできるストレージとファイルの規模を決めることができます。


パーティション、ボリューム、およびディレクトリー

AFS管理者は、セルをいわゆるボリュームに分けます。ボリュームはハードディスクのパーティションと同じサイズにすることもできますが、ほとんどの管理者は1つのパーティションを1つのボリュームでいっぱいにはしません。AFSボリュームは、実際にはボリューム・マネージャーと呼ばれる別のUNIXタイプのプロセスによって管理されます。ボリュームは、UNIXファイル・システムのディレクトリーと同じようにマウントすることができます。ただし、AFSボリュームはファイル・サーバーから別のファイル・サーバー(やはりUNIXタイプのプロセス)に移動できますが、UNIXディレクトリーをパーティションから別のパーティションに物理的に移動することはできません。AFSは、Volume Location Managerを通じてボリュームとディレクトリーの位置を自動的に追跡し、複製されたボリュームとファイルを追跡します。したがって、ユーザーはファイル・サーバーが予期せずに動作を止めても気にする必要がありません。ユーザーが気づかないうちに、AFSが別のファイル・サーバー・マシン上の複製ボリュームにユーザーを切り替えるからです。

ユーザーがAFSサーバー上にあるファイルで作業することはありません。ユーザーが作業するファイルは、クライアント・サイドのキャッシュ・マネージャーによってファイル・サーバーからフェッチされたファイルです。Cache Managerは、クライアントのオペレーティング・システム・カーネルに住む、かなり面白い生き物です。Linuxの場合、パッチはカーネルに追加されます。(Cache Managerは2.4以上のカーネルで動作します。)


Cache Manager

Cache Managerは、ローカル・アプリケーションからの要求に応えて、AFSファイル・システムからファイルをフェッチすることができます。もちろん、ファイルが、頻繁に変更されるソース・ファイルである場合は、ファイルに複数の複製バージョンが存在するのは理想的ではないかもしれません。ユーザーは頻繁に要求されるソース・ファイルを頻繁に変更する可能性が高く、この場合、2つの問題があります。まず、ファイルはクライアント・キャッシュに残っているだけでなく、複数のファイル・サーバー・マシン上の複数の複製ボリュームにも存在する可能性があります。第2に、Cache Managerはすべてのボリュームを更新しなければなりません。ファイル・サーバー・プロセスはファイルにコールバックを付けてクライアント・キャッシュに送信するので、システムは他の場所で起きた変更に対処できます。ユーザーが他の場所にキャッシュされている複製ファイルに変更を加えた場合、元のファイル・サーバーはコールバックを起動して、更新する必要がある元のキャッシュ・バージョンを通知します。

これは、分散バージョン管理システムも直面する古典的な問題ですが、重要な違いがあります。それは、分散バージョン管理システムは切断時でも完璧に機能しますが、AFSではファイル・システムの一部を切り離すことはできません。個別のAFSセクションを元のファイル・システムに再接続できなくなるからです。ファイル・サーバー・プロセスに障害が発生した場合は、まだ実行しているAFSファイル・サーバーと再同期する必要がありますが、切断後にローカルに保存された新しい変更を追加することはできません。


AFSの子孫

AFSは、新しいファイル・システムの試みの明白な出発点となっています。そのようなシステムの2つには、元の分散ファイル・システム・アーキテクチャーから開発者が学んだ教訓が組み込まれています。すなわち、Codaと、スウェーデンのオープン・ソース・ボランティアの取り組みであるArlaです。

Codaファイル・システムは、オリジナルのAFSを改善しようとした最初の試みでした。1987年からカーネギー・メロン大学の開発者たちは、その当時V2.0になっていたAFSの意識的な改良版としてCodaを生み出しました。1980年代後半と90年代前半にかけて、Codaファイル・システムは別のキャッシュ・マネージャー、Venusを打ち出しました。Codaの基本的な機能セットはAFSに似ていますが、Venusは、クライアントが分散ファイル・システムから切断された場合でもCoda対応クライアントの継続動作を可能にします。VenusはAFS Cache Managerとほとんど同じ機能を備えていますが、ファイル・システムのジョブをVFS層からカーネル内部に取り込みます。

CodaサーバーとVenusキャッシュ・マネージャーの接続が切断されても、ネットワーク機能にとって致命傷とはなりません。ラップトップ・クライアントは、中央サーバーから切り離された状態でも作業できなければなりません。したがって、Venusはすべての更新をクライアント変更ログに格納します。キャッシュ・マネージャーが中央サーバーに再接続されると、システムはクライアント変更ログを再統合して、ファイル・システムの更新のすべてをクライアントから使用可能にします。

切断された作業が別の問題をもたらすこともありますが、Venusキャッシュ・マネージャーは、分散ファイル・システムを拡張して、常時接続状態で実行している複雑なネットワーク以上のものを実現できることを証明しました。

プログラマーたちがOpenAFSのGPL化実装を実現するスウェーデンのプロジェクト、Arlaへの取り組みを開始したのは1993年のことですが、大部分の開発と移植は1997年以降に行われました。ArlaはOpenAFSに非常によく似ていますが、XFSファイル・システムはArlaが動作するすべてのオペレーティング・システムで機能しなければなりません。ArlaはV0.39に達し、OpenAFSと同じように、すべてのBSDフレーバー、カーネルV2.0x以降のLinuxカーネル、およびSun Solarisで動作します。Arlaは、AFSコードには本来存在しなかったAFS向けの機能、すなわち切断操作を部分的に実現しています。ただし、効果はまちまちであり、開発者たちはテストをまだ完了していません。

GPL化InterMezzoなど、他にもAFSタイプのファイル・システムはありますが、AFSのコマンド・ライン・セマンティクスやアーキテクチャーを受け継いではいません。オープン・ソース分散ファイル・システムの世界は活気に満ちた世界であり、モバイル・コンピューティングの世界に用途を見出した分散ファイル・システムもあります。

参考文献

  • OpenAFSのソースやバイナリー、ドキュメンテーションなどに関して、そのホームページを調べてください。
  • NFSは進歩しています。そのRFCやその他のドキュメンテーションを、NFS Version 4 Web siteで見ることができます。
  • オリジナルのAndrew File Systemに関する情報について調べてください。ただし多くのコマンドは、OpenAFSのものと同じです。
  • カーネギー・メロン大学は相変わらず、Codaファイルシステムを維持管理しています。
  • 少し古いですが、Codaファイルシステムのドキュメンテーションを調べてみてください。
  • Arlaは入り口として適当です。ただし資料は非常に簡潔か、全く無いかのどちらかです。
  • 新しい分散ファイルシステムを書くための、非常に人気のある試みとして、InterMezzo分散ファイルシステムがあります。
  • Gentooではダウンロードやドキュメンテーション、それに『ゼロからコンパイルする』、このLinuxに関するニュースなどを提供しています。
  • developerWorksのOpen sourceゾーンでは、IBM製品と合わせてオープンソース技術による開発を行う皆さんのために、ハウツー情報やツール、プロジェクトに関する更新情報などを幅広く提供しています。
  • 皆さんの次期Linux開発プロジェクトを、IBM trial softwareを使って革新してください。ダウンロード、あるいはDVDで入手することができます。
  • Developer Bookstoreのオープンソースのセクションでは、Linuxに関する技術書をはじめ、オープンソースに関する書籍が割り引きで購入できますので、ぜひご利用ください。
  • developerWorks blogsに参加して、developerWorksのコミュニティーに加わってください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Linux
ArticleID=237180
ArticleTitle=囲い込まれた分散データを支援するOpenAFS
publish-date=05172005