ネットワークに対応した分割圧縮ループバックデバイス
HTTP-FUSE-CLOOP とそれから起動する Linux
http://unit.aist.go.jp/itri/knoppix 須崎有康1), 八木豊志樹1), 飯島賢吾1), 北川健司２) , 田代秀一1) 産業技術総合研究所1), ㈱アルファシステムズ2) 概要：ブロックデバイスを分割圧縮したブロックファイルから再構成できるループバックデバイス HTTP-FUSE-CLOOP を開発した。分割圧縮したブロックファイルを手元の二次記憶からでも HTTP 経由でリモートからでも透過的に扱える。このHTTP-FUSE-CLOOP を使ってルートファイルシステムをInternet から mount して起動する Linux “HTTP-FUSE KNOPPIX”を開発した。この設計の方針と 性能について述べる。
Network compressed loopback device “HTTP-FUSE-CLOOP”
and Linux which boot form it.
Kuniyasu Suzaki1), Toshiki Yagi1), Kengo Iijima1), Kenji Kitagawa2), Shuichi Tashiro1) National Institute of Advanced Industrial Science and Technology 1), Alpha Systems Inc. 2)
Abstract: We developed network compressed loopback device “HTTP-FUSE-COOP” which can re-construct block device from the split-compressed block files. The split-compressed block files are transparently treated between local storage and remote network. We developed a Linux “HTTP-FUSE KNOPPIX” which mounts root file system using HTTP-FUSE-CLOOP via Internet. In this paper we describe the detail of implementation and its performance.
1. はじめに 我々は Internet 上でルートファイルシステムを 公開し、そこからブートするクライアントOS の研 究を行っている。不特定多数のユーザを対象に、世 界中のどこからでも Internet さえ接続できれば ハードディスク不要で利用可能な OS の開発を目 指している。 Internet でルートファイルシステムを公開する方 法にはブロックデバイスレベルの iSCSI[1]やファ イ ル シ ス テ ム レ ベ ル の NFS4[2], Open-AFS[3], SFS[4], SHFS[5]などが考えられる。しかし、これ ら は 専 用 ポ ー ト を 想 定 し て い る た め フ ァ イ ア ウォールを越えた利用が不可能な場合がある、不特 定多数の利用を考慮していない、常時接続を前提と している、純粋なサーバクライアントモデルで拡張 性がない、などの問題点を持つ。我々はこれらの問 題点を解決するため、細かく分割し、圧縮されたブ ロックファイルをまとめて１つのループバックデ バイスに見せるHTTP-FUSE-CLOOP を開発した。 分割圧縮ブロックファイルは、アクセスがあった 時にオンデマンドで HTTP サーバからダウンロー ドされる。ダウンロードされたファイルは二次記憶 に保持し、再度アクセスがあった場合にはそこから 利用する。つまり、ネットワーク透明であり、二次 記憶に必要な分割圧縮ブロックファイルがあれば ネットワークの接続が切れても構わない。分割圧縮 ブロックファイルはダウンロードさえできればよ く、HTTP の場合では Proxy キャッシュを利用して ダウンロードサーバへの負荷集中を避けると共に 短いレンテンシを実現することができる。 また、分割圧縮ブロックファイルへのアクセスに 物理的な番地を利用するのではなく、ブロックコン テンツの内容によるハッシュ値(MD5)による検索に した。この検索のためにハッシュ値のインデックス ファイルを用意した。これにより空のデータを含む ブロックや同一内容のブロックは１つの分割圧縮 ブロックファイルにまとめられ、領域を削減できる。 ハッシュ値によりブロックの内容の確認ができる ため、セキュリティも向上できる。内容更新はハッ シュ値の違う分割圧縮ブロックファイルを追加し、 インデックスファイルを更新するのみで実現でき る。もとの分割圧縮ファイルを消去する必要がない ため以前の状態に戻すことも可能である。このよう なブロックレベルでハッシュ値による検索はPlan9
のVenti[6], CFS[7], Bittorrent[8], BTSlave[9] な どでも使われている手法である。これらとの比較は
2 章で詳細を述べる。 開発した HTTP-FUSE-CLOOP は 1CD/1DVD Linux である”KNOPPIX”[10][11]と組み合わせ、 Internet からルートファイルシステムを取得して起 動するOS である”HTTP-FUSE KNOPPIX”[12]を 開発した。最新版のKNOPPIX4.0 は使用するメディ アがCD から DVD へと拡張されて容量が 3.8GB と なり、ダウンロードも容易ではなくなってきている。 HTTP-FUSE KNOPPIX では、機能的には通常の DVD 版 KNOPPIX と同じであるが、DVD 版のよう に全てのルートファイルシステムをダウンロード し て持ち 歩く 必要は ない 。現在の HTTP-FUSE KNOPPIX のブートローダ部分の iso イメージは 5MB 程度なので、このイメージを CD に焼いたもの で イ ン タ ー ネ ッ ト か ら ブ ー ト す れ ば DVD 版 KNOPPIX と同様な利用ができる。また、アプリケー ションが更新されても、サーバ上のルートファイル システムを変えるだけで新たに DVD を作成する必 要はない。 以 下 、2 章 で 関 連 研 究 と の 比 較 、 3 章 で HTTP-FUSE-CLOOP の詳細、4 章で性能評価につ いて報告する。5 章で HTTP-FUSE KNOPPIX が持 つ問題点を議論し、6 章で今後の課題、7 章でまとめ を述べる。
2. 関連研究
2.1. Plan9 の Venti
Plan9 用に開発された archival block storage server の”Venti[6]”は、データの読み書きをデバイ ス固有のアドレスではなく、書き込むブロックの中 身についてユニークなハッシュ識別子をキーとし て行う。システムのインタフェースはブロックの読 み書きを許す簡単なプロトコルであり、ファイルシ ステムの機能は archival file server である”fossil” などが受け持つ。Venti はバックエンド的な長期 データ保存ストレージである。 HTTP-FUSE KNOPPIX でもブロック内容の MD5 ハッシュ値をキーとするストレージ管理が似 ているが、ブロックの保存先がファイルである点が 大きく異なる。ファイルにすることでHTTP 配信が 可能となり、Venti で用意している特殊なプロトコ ルやソフトウェアは不要である。また、ファイル形 式ならコピーも簡単に作成でき、proxy によるファ イルキャッシュを使った Internet 配信を活用する ことができる。
2.2. CFS: Cooperative File System
CFS[7]は MIT で開発されている分散ハッシュ chord ベースの P2P ファイルシステムである。CFS はファイルが格納されているページを P2P のノー ドに分散配置する。ページの検索にはchord を用い る。CFS ではノードを追加してもブロックの再配置 は即座に行われないため、高速に複製を増やし、高 バンド幅、低レイテンシを実現するファイルシステ ムではない。CFS は実用よりも実験的実装な意味合 いが強く、信頼性、拡張性に主眼が置かれている。
2.3. Bittorrent と BTSlave
Bittorrent[8]は、大規模ファイルに適した高速 P2P ダウンロードソフトウェアである。Bittorrent で は大規 模フ ァイル を細 かいピ ース と呼ば れる データに分割して、その細かいピースを複数のP2P ノードから「バンド幅が太くなる戦略で」ダウン ロードする。この戦略が Bittorent を特長付けるも ので、下記の性質がある。 1. 複数のノードにダウンロードコネクションを 張り、最終的に全てのピースが早く集まる順にダ ウンロードを行う。例えば、ダウンロードサイト 間で保持しているピースのコピーが少ないもの ほど優先してダウンロードする。これはダウン ロードサイトとの通信が断絶したときにそのサ イトしか保持していないピースがネックになら ないようにするためである。 2. ピースは全ダウンロード終了後に bencode によって元のファイルに復元する。この時まで ファイルはBittorrent 管轄のピースのままであり、図１ KNOPPIX での cloop の利用手順 ファイルとして扱うことができない。 このような戦略は大きなファイルの高速なダウン ロードには適するが、ファイルのランダムな読み出 し要求に適するものではない。Bittorent を元とす るファイルシステムに BTSlave[9]があるが単純な 拡張では高速な読み出しが難しいようでプロトコ ルの再実装を検討している。
3. 分割圧縮ブロックファイルによるループ
バックデバイス
KNOPPIX ではルートファイルシステムを圧縮 ループバックデバイスに収録して１ファイルとし て扱う。ループバックデバイスとはファイル内にブ ロ ッ ク デ バ イ ス を 格 納 で き る 仕 組 み で あ る 。 KNOPPIX では CD-ROM 対応のために更に圧縮機 能をつけたcloop(compressed loopback device)によ り容量を小さくしている。今回の開発では、この cloop を改良して、分割圧縮ブロックファイルによ るループバックデバイスを作成した。 3.1 cloop の仕組み cloop ではブロックデバイスを固定サイズ(標準 で64KB)毎に切り出し zlib 圧縮して、2Ｇ程度のブ ロックデバイスイメージを 700MB 程度のループ バックファイルに収納している。元のブロックデバ イス上で使われているファイルシステム(iso, ext2, etc)に依存しない。 CD 版の KNOPPIX がブートするとき、この cloop ファイルをループバック設定してブロックデバイ スとして扱えるようにする（図1）。KNOPPIX では ブ ー ト 時 に CD-ROM 内 の cloop フ ァ イ ル /cdrom/KNOPPX/KOPPIX を/dev/cloop デバイス にセットアップしている。# insmod –f /modules/cloop.o file=/cdrom/KNOPPIX/KNOPPIX
更に通常のファイルシステムとして読み出せる ように mount 操作を行う。
# mount /dev/cloop /KNOPPIX
ここまで設定した後、cloop ファイルに格納したファ イルを読み出すことができる。 この cloop 内のファイルアクセスでは、cloop デ バイスドライバによるブロックの読み出しが通常 の手順と異なる。cloop ではファイルの読み出し要 求があるとcloop driver が要求された読み出しに該 当する圧縮ブロックをcloop ファイルから読み出し、 伸張を行って必要な部分のみを返している。伸張し た結果はデバイスドライバ内にキャッシュされ、直 後に同じブロックがアクセスされた場合の高速化 に役立てる（図1)。 3.2 改良点 この圧縮ループバックデバイス cloop は、ブロッ クデバイスをファイルとして扱えるため便利であ る。しかし、常に一つの大きなファイル(CD 版では 700MB 程度)として扱わなければいけないため、ダ ウンロードするのに時間がかかる。 本開発ではcloop ファイルを分割して複数のファ イルとし、分割したファイルをリモートとローカル で透過的に扱える「分割圧縮ブロックファイルによ るループバックデバイス(HTTP-FUSE-CLOOP)」 を開発した。改良のポイントは下記である。 固定サイズ(現在の標準は 256KB)毎にブロック を切り出し、圧縮したデータを”ファイル”に格納 する（分割圧縮ブロックファイル）。 • • • 多数の分割圧縮ブロックファイルをまとめて、一 つのループバックデバイスとして扱えるように する。 ループバックデバイスでは、必要な時に必要な分
3.3. Internet 対応 割圧縮ブロックファイルを取得すればいいよう にする。つまり、全ての分割圧縮ブロックファイ ルが揃わなくてもループバックデバイスとして 扱えるようにする。 分割圧縮ブロックファイルは、cloop ファイル内 で該当する部分が読み出される時に検索される。そ のコピーが手元の二次記憶（ハードディスクまたは USB メモリ）にあればそれを利用し、無ければ Internet よりオンデマンドでダウンロードする。オ ンデマンドのダウンロード部分も FUSE wrapper としてlibcurl を用いて作成した(図 3)。 • 分割圧縮ブロックファイルのファイル名はその 内容のハッシュ値(MD5)とし、ファイル名で内容 確認ができるようにする。同一内容の場合、ハッ シュ値が同じになりファイル数を減らすことが できる。 ダウンロードした分割圧縮ブロックファイルは RAM-Disk あるいは二次記憶に保存される。二次記 憶に保存された場合、2 回目以降のブートでは保存 された分割圧縮ブロックファイルを利用する。 今回の実装では分割圧縮ブロックファイルをま とめる手段として仮想ファイルシステム FUSE (Filesystem in Userspace)[13]を利用した(図 2)。
開発ではFUSE の wrapper を利用し、FUSE を
通して分割圧縮ブロックファイルを cloop ファイル として再構成する HTTP-FUSE-CLOOP を作成し た。分割圧縮ブロックファイルはcloop と同様に固 定サイズでブロックを切り出し、zlib で圧縮したも のをファイルに保存したものであり、ファイルの内 容はcloop ファイルの分割圧縮ブロックと同一であ る。FUSE を通してブロックファイルを cloop とし て再構成するために、「cloop ヘッダの生成」と 「cloop 内の分割圧縮ブロックと分割圧縮ブロック ファイルの対応」を取る index.idx ファイルを作成 した。cloop ファイルに対してブロック読み出し要 求があると、そのブロックに該当する分割圧縮ブ ロックファイルをFUSE を使って取得し、要求され た cloop ファイルのブロックに割り当てている (図 2)。 図3 HTTP FUSE-cloop の構成 3.4. 差分更新 分割圧縮ブロックデバイスの利点として、アプリ ケーションの更新が起こった場合、その差分部分と index.idx ファイルの入れ替えのみで実現できる （図 4）。この機能は、元のブロックデバイス上の ファイルシステムが ext2 のようにブロック単位で 更新可能なことを条件とする。iso9660 のように一 部の変更が他のブロックの位置まで変えるような ファイルシステムを適用している場合にはこの機 能が利用できない。 今までのCD 版の KNOPPIX では、元のファイル システムが ext2 としても cloop ファイルにする時 に、一部の変更がそれ以降のブロック配置に影響を 与えていたために差分更新することができなかっ た。HTTP-FUSE-CLOOP では、ブロックをファイ ルとして扱えるようにしたために、変更の生じた ファイルの変更とその位置情報であるindex.idx の 図2 FUSE-cloop の構成
3.5. 欠点と対処(netselect と DLAHEAD)
図4 FUSE-cloop による差分更新
HTTP-FUSE-CLOOP を 使 っ た 場 合 の ダ ウ ン ロード要求は下記の手順になる。
ext2 -> cloop -> FUSE -> (HTTP Internet) -> file cloop は仮想ブロックデバイスのためアクセス要求 が逐次化される。これを Internet に適応した場合、 コネクションが１つになってしまう。これではNFS などで一般に使われているネットワークのバンド 幅拡張の手段が適用できない。つまり、バンド幅拡 張はクライアント・サーバ間に複数のコネクション を張り、ネットワークのレイテンシを隠蔽する手法 であるが、その手法が適用できない。特に何も手が かりのないブート時にこの影響を受けやすい。 みの変更で差分更新に対応可能となった。 追加するファイル名は更新したブロックの内容 のMD5 値となる。HTTP-FUSE-CLOOP では、新 しい index.idx と新たな分割圧縮ブロックファイル を追加すれば以前の分割圧縮ブロックファイルを 再利用することができる。これにより、カスタマイ ズを行っても更新差分のファイルのみを提供すれ ばよいので、効率的な配布を行うこと可能となる。 この問題点を解消するために、ブート時に短いレ イテンシのサーバを見つける機構(netselect)と事前 に 解析し た必 要ブロ ック ファイ ルを 平行ダ ウン ロードする機構(DLAHEAD)をブートシーケンスに 組み込んだ。 3.5.1 netselect 差分更新を利用したサーバとクライアントの構 成は図5 になる。サーバ側では、同一ブロックファ イルをシンボリックリンクで共有することで容量 の削減が可能となる。また、クライアントではブー ト時にルートファイルシステムを切り替えること が可能で、１つの HTTP-FUSE KNOPPIX のブー ト用CD-ROM から多くの KNOPPIX カスタマイズ が利用できる。 HTTP-FUSE-CLOOP を使った Internet からの ブートでは、クライアントがレイテンシを短くする ようにダウンロード先を選択する機構を加えた。具 体的には複数のHTTP サーバを用意し、その IP ア ドレスに netselect をかけてレイテンシの短いもの を見つける。netselect は traceroute を使ってクラ イアントから近いサーバを見つけるツールである。 HTTP-FUSE KNOPPIX のブートでは一番短い サーバからダウンロードすることで高速なブート を実現する。 3.5.2 DLAHEAD ブート時に必要なファイルを事前に解析し、必要 と思われるブロックを HTTP-FUSE-CLOOP と平 行 し て ダ ウ ン ロ ー ド す る DLAHEAD(download ahead) の機能を付けた。DLAHEAD では、サーバ 側に置かれたブロックファイルリストを見つける と、複数のコネクション（デフォルトで４本）を張っ て、事前に必要と思われるファイルをダウンロード する。ダウンロードしたファイルは二次記憶に保存 される。HTTP-FUSE-CLOOP から要求があった際 図5 HTTP-FUSE KNOPPIX の構成
にダウンロード済みであれば二次記憶のファイル を利用する。 ただし、この方法でも DLAHEAD のリストに該 当しない読み出し要求があった場合（異なるデバイ スドライバやブートオプションなど）は、逐次にダ ウンロードしなければならない問題点をもつ。
4. 性能測定
4.1. HTTP-FUSE-CLOOP の性能 まず、HTTP-FUSE-CLOOP 単体の性能を測定し た。KNOPPIX4.0 DVD 版を元に分割圧縮ブロック ファイルを作成した。切り出しサイズは論文[12]で 最適とされた256KB とした。結果は表 1 になる。 表1 256KB 分割圧縮ブロックファイルの特徴 元 の cloop ファイル ファイル数 フ ァ イ ル の総容量 フ ァ イ ル の サ イ ズ 3.15GB ( 展 開 後 は 9.7GB) 35,504 3.09GB Max: 2,622,230 Min: 277 Ave: 93,581 元になったcloop ファイルは 64KB ごとに圧縮を かけている。256KB ごとにすることで若干圧縮率が 高まり、総容量が低減できた。また、平均ファイル サイズはネットワークのWindow サイズの 64KB に 乗るようになっている。これ以下の切り出しでは Window サイズを余らせ、バンド幅が小さくなって しまう。輻輳制御のためのスロースタートの影響も 考えられるが、TCP コネクションは keep-alive を 有効にしており、ウインドウサイズに近いデータの ため影響は少ない。 こ の 分 割 圧 縮 ブ ロ ッ ク フ ァ イ ル を 用 い て HTTP-FUSE-CLOOP の性能を測定した。利用した マシン仕様は表2 である。 表2 性能評価マシン仕様HTTP-Server: HTTP-FUSE Client:
IBM ThinkPAD T24 CPU Pentium III 1GHz, メモリ1GB, 100M NIC apache 1.3 IBM ThinkPAD T42 CPU Pentium M 1.8GHz, メモリ2GB, 1000M NIC 24 倍速 CD ドライブ レイテンシの影響を調べるため、FreeBSD の dummynet によるレイテンシ(往復 200msec。日米 間で片道 100msec を想定)も入れて測定した。測定 では「dd によりブロックレベルの読み出し」と「tar によるファイルシステムレベルでの読み出し」をそ れぞれ求めた。比較のために二次記憶(ハードディス ク)にブロックファイルを置いた場合の性能も測定 した。参考のために元になったcloop ファイルとそ れの分割圧縮ブロックファイルのダウンロードに よるスループットも求めた。この結果は表3 になる。 表3 HTTP-FUSE-CLOOP の性能
delay なし 200msec delay HTTP からの dd 2.51 MBps 0.194 MBps HTTP からの tar 6.41 MBps 0.516 MBps HD からの dd 15.4 MBps HD からの tar 20.4 MBps (参考性能) cloop フ ァ イ ル の wget ダウンロード 9.56 MBps 0.320 MBps ブロックファイルの wget ダウンロード 2.71MBps 0.197 MBps この結果から HTTP-FUSE-CLOOP はレイテン シの影響を受けやすいことが判る。これは小さな分 割圧縮ブロックファイルを直接ダウンロードした 場合のバンド幅とほぼ同じ性能であり、細かいファ イルを逐次にダウンロードすることが大きく影響 する。cloop ファイルのような大規模ファイルでは レイテンシが短い場合は NIC の性能に近いバンド 幅を出せるが、分割圧縮ブロックファイルではレイ テンシが短くても、オーバーヘッドの影響でバンド 幅が稼げない。 ファイルシステムを通してtar した場合は、圧縮 の効果が現れており、レイテンシのあるなしに関わ らず、dd のブロックアクセスより約 2.5 倍のバンド 幅に拡張されている。現在の CPU は性能が向上し ているため、ネットワークの性能を隠蔽する良い手 段であることが判る。 4.2. HTTP-FUSE KNOPPIX のブート 次にHTTP-FUSE KNOPPIX のブートについて 測定した。分割圧縮ブロックファイルやマシン条件 は同じである。 事前調査としてブート時にダウンロードされる ファイルを調べた。ファイル数は3,107 であり、そ
の容量は 234MB であった。これは DLAHEAD で 使われるファイルリスト(DL-FULL)になる。残念な がらこのリストを DLAHEAD の標準にするとメモ リが512MB のマシンではブート途中でキャッシュ が溢れ、ブートできないことが判っている。このた め、メモリが 512MB でも動くように最初の 2500 ファイルとしたリスト(DL-2500)も用意した。この 場合の総容量は186MB である。DLAHEAD のダウ ンロードコネクションはデフォルトの４本とした。 測定ではそれぞれの DLAHEAD を行う場合、行わ ない場合についてレイテンシを変えて評価した。 4.2.1 起動時間 起動時間の測定ではboot: プロンプトからルート フ ァ イ ル シ ス テ ム を マ ウ ン ト す る ま で の 時 間 (T-root)、それ以降のブロックファイルのダウンロー ド時間(T-blcok)、最終的にデスクトップマネージャ のKDE が終了するまでの時間(T-KDE)を測定した。 ブートの所要時間を表５にまとめる。 表5 ブートの所要時間(単位 秒) ルートファイ ルシステムを 要求するまで の時間 (T-root) ブ ロ ッ ク フ ァ イ ル の ダ ウ ン ロ ー ド 時 間 (T-block) KDE ま での起動 時間 (T-KDE) DL FULL 23 97 DL 2500 61 98 latency なし DL なし 76 113 DL FULL 402 437 DL 2500 607 644 latency 200msec DL なし 37 1376 1413 DVD 起動(参考性能) 22 273 295 T-root は CD や DVD からのブート処理で消費さ れる時間である。HTTP-FUSE KNOPPIX が通常の DVD 起動より時間が要するのは、T-root の時間内 でネットワークの設定や HTTP-FUFE の準備を行 うためである。
基本的に T-KDE は T-root と T-block の和であ るが、latency なしで DL-FULL の場合は先行ダウ ンロードが早めに終了して HTTP-FUSE-CLOOP の 本体は 二次 記憶の キャ ッシュ を利 用する ため T-block(23sec)が短くなっている。しかし、T-KDE (97sec)を比較すると DL-2500(98sec)とほとんど変 わらない。つまり、ある程度先行ダウンロードを行 えば、ブート処理で律速されていることがわかる。 全体を逐次にダウンロードにした場合は、ダウン ロードに要する時間が隠蔽できず、T-KDE (113sec) も遅くなる。いずれにしてもlatency がない場合は DVD 起動より高速であった。
latency が 200msec の場合は、DLAHEAD あり
でもダウンロード時間を隠蔽できず、いずれもDVD 起動より遅くなってしまう。しかし、DLAHEAD な し(1,413sec) と 比 べ る と ２ 倍 以 上 起 動 時 間 短 縮 (437sec と 644sec)が確認できる。 4.2.2 転送データ量とスループット ブロックファイルのダウンロード状況を調べる ため、時間ごとの転送データ量とスループットを測 定した。測定はサーバ側で tcpdump を用いた。
latency がなしの場合を図 6,7、latency が 200msec
の場合を図8,9 に示した。 4.2.2.1 レイテンシがない場合 図6 より分割圧縮ブロックファイル転送状況が判 る。DLAHEAD がない場合では、起動処理でファイ ルアクセスがある度にダウンロードされているこ とが判る。10-20 秒の間で平坦になっているのは、 KNOPPIX の Autoconfig によるデバイス認識を 行っているため、ファイルアクセスがないからであ る。DLAHEAD があると先行ダウンロードを集中的 に行うため、転送データ量はほぼ一直線に増加する ことが確認できる。DL-FULL では全て先行ダウン ロードしてしまうので、終了後のダウンロードはな い。DL-2500 では途中で先行ダウンロードが終了す るため、残りのファイルアクセス要求があるまでダ ウンロードが停止する。アクセス要求が始まると DLAHEAD なしと同様にダウンロードされている ことが確認できる。
図 7 ではスループットの変化を示している。 DLAHEAD があるとほぼネットワークの性能を使 い切り、高スループット(95Mbps)を維持しているこ とが判る。10 秒ぐらいの一時的な落ち込みは 4 本の ダ ウ ン ロ ー ド に よ る チ ョ ー ク と 思 わ れ る 。 DLAHEAD なしの場合瞬間的な高スループットが 起こるが、通常は低スループットで推移している。 これは、HTTP-FUSE-CLOOP が仮想ブロックデバ イスのためアクセス要求が逐次化され、細かいファ イルをコネクション1 本で読み出さなければいけな いためである。また、表3 のブロックファイル読み 出しスループット(2.71MBps≒21.7Mbps)と比べる と HTTP-FUSE-CLOOP では高スループットが出 ている。これは表３ではwget を使ったのに対して、 libcurl から呼び出していることが影響していると 考えられる。 図7 latency なしでのスループット 図6 laency なしでの転送データ量 図9 latency 200msec でのスループット 図8 laency 200msec での転送データ量 3.2.2.1 レイテンシが 200msec の場合 図8 と図 6 を比べると、レイテンシの影響で転送 が間延びしていることが判る。DLAHEAD では転送 データ量はほぼ一直線に増加するが、その効率は格 段に悪化する。また、ブートに必要な転送データ量 は234MB のはずであるが、DLAHEAD を適用した 場 合 は い ず れ も 250MB を 超 え る 。 こ れ は DLAHREAD が HTTP-FUSE-CLOOP の読み出し に追い抜かれ、二重読み出しされているためである。 現在の実装では二重読み出しを抑制する機構がな いため、先行読み出しが追い抜かれたら余計なデー タ転送を起こしてしまうが、抑制できるように改良 する。
DLAHEAD なしの場合でもほぼ直線のダウン ロードになっているが、これは読み出し要求に対し て常にダウンロードネックになっているためであ る。200msec delay によるバンド幅縮小(Window サ
イズが 64KB の場合 2.5Mbps)がボトルネックなり、 その性能が表面に出ている。 図８のスループットを見ると律速の状況が判る。 DLAHEAD なしではほぼ 2.5Mbps 以下に抑えられ ている。DLAHEAD ありで４本の集中的なダウン ロードを行っても10Mbps 以下に抑えられ、効率的 な転送ができていない。この状況は DLAHEAD の コネクション数を増やすことで改善されるが、元々 の バンド 幅が 狭いの で効 果が薄 い。 できる だけ latency の短いサーバを見つけるのことの方が効果 的であることが推測できる。
5. 議論：公開 HTTP サーバ
以上述べたような HTTP-FUSE KNOPPIX のソ フトウェアを作成した。現在KNOPPIX4.0 DVD 版 対応のものを公開している。HTTP サーバ群として は ring プロジェクトのミラーサーバとニューヨー ク大学のcoral プロジェクトの P2P プロキシを利用 している。 ring[14]は日本のフリーソフト配信の最大ミラー サーバであり、現在20 以上のミラーが利用できる。 地理的にもネットワーク的に分散さており、国内か らの利用では netselect を用いて短いレイテンシの サーバを見つけることが可能となっている。coral では[15,16]は .nyud.net:8090 を URL のサ イト名に付けるのみで、P2P プロキシへ導かれる。 例えば、www.aist.go.jp.nyud.net:8090/index.html により、www.aist.go.jp へのアクセスが P2P プロ キシへ割り当てられる。これは .nyud.net:8090 の 部分で名前解決を行う際にプロキシへの接続と導 いているためである。coral は PlanetLab[17,18]を 利用して、世界中にP2P プロキシを割り当てている。 coral は簡単に利用できるが、P2P プロキシが置 かれているサイトが欧米に偏っており、国内からは その効果が確認できない。また、プロキシではファ イルがキャッシュされていない場合、オリジナルサ イトからのダウンロードを行わなければならず、そ の効率も確認しづらい。プロキシ同士でキャッシュ を融通しあうICP(Internet Cache Protocol)もある が、あまり効率的ではないという報告[19]もある。 このような環境ではプロキシサーバに対する計画 なプッシュも必要と考えられる。 Akamai の FreeFlow によるエッジサーバサービ スのようなものが簡単に利用できるとうれしいの だ が 現 状 で は 難 し い 。 最 近 製 品 が 出 て い る WAFS(Wide Area File System)は、WAFS アプライ
アンス機器をInternet と LAN の間に配置し、LAN
側では SMB/CIFS による通常のファイルシステム としてのアクセス、Internet 側では別の WAFS ア プライアンスと専用プロコルによる高速データ交 換を実現している。WAFS アプライアンスがファイ ルのキャッシュと一貫性管理を行い、レイテンシ隠 蔽を行っている。いずれにしろレイテンシを短く技 術が重要であり、HTTP-FUSE-CLOOP においても 同様のものが必要と考えている。
6.今後の課題
6.1 ファイル単位とブロック単位 HTTP-FUSE KNOPPIX ではデバイスブロック を分割して配信している。これに対して、WebDAV のようなファイル単位での配信も考えられる。しか し、ファイル単位では特殊ファイルが配信できない こと、ブロック差分のような透過的な更新が簡単に できないこと、大きなファイルだと無駄な転送が増 えること、ファイルの詐称が簡単にできること、な どの欠点がある。現在の実装ではこれらの欠点を克 服できる仕組みがないためブロック単位の配信と したが、今後ファイル単位の配信手段についても考 えていきたい。 6.2. セキュリティ 現在の版はハッシュ値(MD5)により内容確認できるようになっているが、セキュリティ的に充分でな い。当面は内容確認できるためセキュリティを心配 する必要がないと思うが、将来的には index.idx ファイルのみはhttps 配信すること、ブロックファ イルの暗号化、ブロックファイルの署名、ダウン ロードサーバの認証、などの対処を考えている。 7.おわりに ブロックデバイスを分割圧縮したファイルから 再 構 成 で き る ル ー プ バ ッ ク デ バ イ ス HTTP-FUSE-CLOOP を開発した。HTTP-FUSE- CLOOP は分割圧縮したファイルを手元の二次記憶 からでも HTTP 経由のリモートからでも透過的に 扱えるようにした。これを KNOPPIX に適用して HTTP-FUSE KNOPPIX を開発した。 分割圧縮ブロックファイルはコピーでも構わず、 Proxy キャッシュなどをも活用できる。この利点は クライアント・サーバの束縛を離れ、広域にOS の イメージを配信可能とする。 HTTP-FUSE KONPPIX はとりあえず利用可能 になったが、まだまだ一般に適用するにはレイテン シの問題やセキュリティの問題を詰める必要があ る。今後はこれらの問題を解決し、使い勝手を高め ていきたい。 参考文献&URL [1] iSCSI, http://www.ietf.org/rfc/rfc3720.txt [2] NFS4 http://www.nfsv4.org/ [3] Open-AFS, http://www.openafs.org/ [4] SFS, “http://www.fs.net/sfswww” [5] SHFS, http://shfs.sourceforge.net/
[6] Quinlan, S. and Dorward, D.: Venti: a new approach to archival storage, the USENIX Conference on File and Storage Technologies, Monterey, CA, pp. 89–102 (2002). [7] Dabek, F. Kaashoek, M. Karger, D. Morris R. Stoica,I.: “Wide-area cooperative storage with CFS”, 18th ACM Symposium on Operating Systems Principles (SOSP '01), (2001).
[8] Cohen, B.: “Incentives Build Robustness in BitTorrent”, First Workshop on Economics of Pexr-to-Peer Systems,(2003).
[9] Cox. B: BTSlave: http://btslave.sf.net/ [10] KNOPPIX, http://www.knopper.net/knoppix
[11] KNOPPIX 日本語版, http://unit.aist.go.jp/itri/knoppix/ [12]須崎,八木,飯島,丹, “HTTP-FUSE KNOPPIX”, ”,Linux
Conference 2005.
http://lc.linux.or.jp/paper/lc2005/CP-02.pdf [13] FUSE, “http://fuse.sourceforge.net/” [14] Ring プロジェクト, http://www.ring.or.jp [15] coral プロジェクト,http://www.coralcdn.org/ [16] M.J.Freedman, E.Freudenthal, and D.Mazières, “Democratizing Content Publication with Coral”, 1st USENIX/ACM Symposium on Networked Systems Design and Implementation (NSDI '04)
http://www.coralcdn.org/docs/coral-nsdi04.pdf
[17] PlanetLab プロジェクト,http://www.planet-lab.org/ [18]L.Peterson and T.Roscoe “The Design Principles of PlanetLab”, Draft Paper, June 2004
http://www.planet-lab.org/PDN/PDN-04-021/pdn-04-021.pdf [19]松本,河合,奥田,門, “Peer-to-Peer Network を用いた Web Cache の提案と実装”, DPS ワークショップ, (2002)
