DA ネルサ - の設実装 サーバーはマルチスレッドの言れこよるオーバーヘッドの 大半を回避できるが、あらゆる不頁のイベントを統合した 効率的なイベント通知 / 配信オ椒こ加え、真に非同期のイ ンターフェイスが必要になる。 DAFS サーバーは、カー ネルにこのような機能を要求する。 現行の FreeBSD は、 AIO (Asynchronous I/O) シ ステムコールの API は備えているが、バッフア・キャ ッシュへの内部非同期インターフェイスがない。 AIO は POSIX 1003. IB 規格の実装であり、 Solaris などの他の システムにもみられる [ 16 ] 。これは標ま勺なファイルを 扱うファイルシステムへのマルチスレッド・インターフェ イスか、デバイスファイルによる非同期デバイス入出力を 使って実装される。後者の仕組みは、マルチスレッド処 理のオーバーヘッドを回避できるので効率的である。しか し、リレーショナノレ・データベースのような raw テンヾイ スアクセスをおこなうアプリケーションしか使用すること ができない。 ディスクイベントとメモリ間 NIC イベントの処理を 統合するには、ネットワークに特化されたコンプリーショ ン・グループの仕組みを一般化する必要がある。ネット ワークやディスクソースからのイベントは kqueue[13] を使って一律に処理できる。これは描匠、スケーラブルな イベント処理のために FreeBSD カーネルの内音財冓造に導 入された。 kqueue は、以下のようなイベントを統合する ために使える。 1. ネットワーク入出力の完了 2. ディスク入出力の完了 3. プロセス同期のためのシグナル kqueue の構造は、 DAFS サーバーに関係するあらゆ る不頁のイベントを処理できる。非同期操作をおこなうに は、 kqueue を備えた kevents へのる当求が必要である。ネ ットワークやディスクのイベントハンドラは、適切なイベ ントフィルタ ( ディスク用の EVFILT-KAIO とネット ワーク・イベント用の EVFILT-RDMA) を使ってサー バーの kqueue に通知する。通知は kqueue-scan() を使 用したポーリングか、 (kqueue の実装に若干の機能追加 が必要だか ) ハンドラルーチンへの直接もしくは遅延した 呼出しのどちらかでおこなえる。 168 4.2 vnode インターフェイスの機能 vnode/VFS は、特定のファイルシステムの実装から 汎用的なファイルシステム操作を切り離す力ーネル・イン ターフェイスである [ 20 ] 。これは、アプリケーションに カーネルのファイルシステムへの顳勺なアクセスを提供 するために考案されたもので、 NFS のようなネットワー ク・ファイルシステムのクライアントにも対応している。 vnode/VFS インターフェイスは 2 つの部分て構成され ている。 VFS はファイルシステムで実行できる操作を定 義し、 vnode はファイルシステム内のファイルて夫行で きる操作を定義する。表 1 は vnode 操作をまとめたもの で、 NFS や他のさまざまなローカル・ファイルシステム に対応するために当初定義されたものと [ 20 ] 、データを仮 想メモリキャッシュとディスク間で直接転送するために BSD システムに追加されたものから構成される。 既存の vnode 入出力インターフェイスはすべて同期 的である。 VOP-READ と VOP-WRITE は引数とし て struct uio ノヾッフアの記述をとり、コピーのセマ ンティクスをもつ。 VOP-GETPAGES と VOP-PUT- PAGES は、イ瓦想メモリキャッシュとディスク間でデー タを直接変換するゼロコピー型のインターフェイスであ る。 VOP-GETPAGES から返されたイ瓦想メモリページ は、デバイスの入出力に使う物理メモリに明示的に結び つけられる必要がある。状態をもつ入出力のためのイン ターフェイスは、ロックされた状態のバッフアを返すよ うに言 t しなければならない。 vnode インターフェイス は、非同期操作の新機能を備えた低レベルのバッフアキ ャッシュ・インターフェイスにもとづいて作られており、 DAFS サーバーの要件に合致することはさきはども説明 したとおりである。こうした非同期インターフェイスは VOP-GETPAGES や VOP-PUTPAGES の非同期版 より実装しやすいだけでなく、 FreeBSD の統一された仮 想メモリやバッフア・キャッシュのものと同等の機能を もつ。 この新しいインターフェイス ( 表 2 に概要を示す ) の中 心になるのが VOP-AREAD コールで、ディスク読取り リクエストを発行するために使用し、プロッキンクせすに 戻ってくる。 VOP-AREAD は、 kqueue オ冓と統合さ れた新しい aread ( ) バッフアキャッシュ・インターフェ UNIX MAGAZINE 2003.3

FreeBSD 用 FS カーネルサーバ - の 設計と実装 要約 UNIX MAGAZINE 2003.3 1> はじめに ル・クライアントは、通常はファイルアクセス API を実 DAFS Collaborative から生まれた。 DAFS ファイ Appliance や lntel を中心とした産学協同組織である うための新しい商用規格である。この規格は、 Network は、 こうしたネットワークでファイルアクセスをおこな しいアプリケーションやサービスか誕生した。 DAFS[6] を実現したネットワークの出現により、それを利用した新 RDMA 、転送プロトコルのハードウェアによる処理など インターフェイスへの低いオーバーヘッドでのアクセス、 ューサーやカーネルのアドレス空間からネットワーク・ ている。 対応させるには、我々カ甘是案するカーネルの機能が必要だと考え ト駆動ファイルサーバーを数ギガピットのネットワーク速度に い FreeBSD カーネルの機能として組み込む予定である。イベン 合されたイベント通知 / 処理、 RDMA 用のイ課メモリなどを新し vnode 入出力インターフェイス、ネットワークやディスクの統 をホストのイ反想メモリシステムに統合するため、将来的には非期 実証した。マルチスレッド処理のオーバーヘッドを低成し、 NIC ネットワークで 100MB/s 以 - ヒの言翹 ( り性能を達成できることを (4K) を先読みする場合でさえ、現行のサーバーが 1.25Gbps の 我々は、非同期のクライアント API で小さなプロックサイズ 用の DAFS カーネルサーバーの最初の実装について説明する。 加えたカーネルと既存のインターフェイスを使用した、 FreeBSD 性のある通信といった機能を寒見する。本稿では、わすかな修正を mote Direct Memory Access) 、効率的なイベント通知、イ頁 troller) は、ユーサーレベルのネットワーク処理、 RDMA (Re- コルレベルの処理をおこなう NIC (Network lnterface Con- 品のための新しい規格である。 DAFS のアーキテクチャとプロト タ工竟て利用する商用 NAS (Network Attached Storage) 製 DAFS (Direct Access File System) は、サーノヾークラス KOStas Magoutis ルのプロトタイフ。実装の生能を紹介し、 6 節では結果を総 パ・モデルか挙げられる。 5 節では現行の DAFS カーネ [ 叫館正する必要があること、新しい BSD デバイスドライ 機能、バッフア・キャッシュのロック処理の仮定条件を 合、 NIC のメモリ管理ハードウェアのためのイ課メモリ と、ネットワークとディスクの入出力イベント配信の統 クするために非同期 vnode インターフェイスが必要なこ フア・キャッシュでファイルページをマップしたり口ッ カーネルの構造上の間題を述べる。問題点としては、バッ を FreeBSD で効果的に機能させようとする際に現れる、 機能を必要とする。 4 節では、 DAFS カーネルサーバー り高い性能を発揮する可帽生がある一方で特別なカーネル 紹介する。これは我々カ甘是案する新設引・のサーバーで、よ 実装について解説する。 3.2 節では Optimistic DAFS を ル・インターフェイスを使った DAFS のプロトタイプの 送技術の致について述べる。 3.1 節では、既存のカーネ でもある。次節では、 DAFS が対応するネットワーク転 囲では、汎用のデマンドベージ型 OS における初の実装 初の実装について解説する。このサーバーは我々の知る範 本稿は、 FreeBSD 用の DAFS カーネルサーバーの最 に実装される。 ーはカーネル ケーションである。 DAFS ファイルサー 装したユーザーレベルのライプラリにリンクされたアプリ を 2> メモリ間転送 括する。 ( 、、メモリ間ネットワーク '(memory-to-memory net- ルアクセス・プロトコルのイ」嘛である。ネットワーク転送 DAFS は、 NFS バージョン 4 [ 22 ] をもとにしたファイ 163

- DA ド S カ尋ルサ編の設計と実 図 3 DAFS の読取り性能 120 100 80 20 0 512 256 128 32 64 プロックサイズ ( KB ) 1 6 8 4 具物グラフカ琲い期 API 、右則か期 APIO もとづいて説明した。我々は、既存のインターフェイス を使用した現行のサーバーの構造を解説した。性能詔面の 結果は、現行の DAFS サーバーのプロトタイフ。実装が、 1.25Gbps のネットワークでも高性能なファイルサーピ スを提供できることを示している。 既存のプロックするカーネル・インターフェイスの間題 は、 DAFS や他のカーネルサーバーがこうしたインター フェイスを使うと、各入出力リクエストにプロセスのコン 現行のプロトタイプは FreeBSD 4.3-RELEASE 用の テキストか憫連してくるためオーバーヘッドが生しること カーネルローダブル・モジュールとして動作し、すべての である。このオーバーヘッドは、数ギガビットのネットワ 基本的なファイルアクセス、性能強イロック処理、クラ ークではさらに顕著になるだろう。我々カ甘是唱する vnode イアントのキャッシュ対 ) 樹巣作などの DAFS の各種仕様 インターフェイスの機能 j 助日は、ネットワークとディスク を実装している。サーバーとは別に、 FreeBSD に多数の のイベント通知 / 配信を統合した非同期ファイル入出力を VI NIC 用デバイスドライバを樹直しているが、そのなか 実現する。 にはリンク層転送としてそれぞれ ATM と Gigabit Eth- 我々は、プログラム可能な RDMA 対応 NIC を Free- ernet を使用する Giganet/EmuIex eLAN 1000 や GN BSD の仮想メモリシステムに統合する設引・上の可能を 9000 VI/IP も含まれる。我々は転送機能か実装されれは 示した。この機能により、 DAFS サーバーはクライアン すぐにでも Optimistic DAFS の生能がどれくらい向上 トから起動される RDMA 操作やサーバーのページング したかを測定したいと考えている。サーバーのソースコー 処理の際に、イ瓦想メモリキャッシュ全体をネットワーク ドや関連する FreeBSD カーネルのパッチは、 http:// を介して利用できるようになるだろう。我々はこうした設 www.eecs.harvard.edu/vino/fs-perf/dafs/から入手 計を具体化し、 Optimistic DAFS に適用できるような実 できる。 装を検討している。 最後に、既存の BSD ネットワークドライパ・モデルは メモリ間 NIC デバイスの要求を満たすには不十分で、新 しいモデルが必要であることカ吩かった。 7> 謝辞 論文の作成を指導してくれた Donn Seeley と、意見を 寄せてくれた Alexandra Fedorova 、 SaIimah Addetia に感謝する。 8 ソフトウェアの状態と入手先 を [ 赭文献 ] [ 1 ] W ' ロれ 9 Device D ロ ? 肥 7 、 s , Sun Microsystems, 2000 [ 2 ] G. Banga, et al. , "Better Operating System Fea- tures for Faster Network Servers ” , Proceedings 可 175 UNIX MAGAZINE 2003.3

” DA ネルサ編の設計と実 システムに完全に統合した場合は、 NIC のページアクセ スにこのポリシーを等しく適用すべきである。 NIC - OS インターフェイス UNIX MAGAZINE 2003.3 行されると、 RDMA は RPC とは非同期で続けられる。 RPC に対応して RDMA 転送を設定する。いったん発 RDMA べースのデータ転送では、サーバーは要求する 出力にノヾッフア・キャッシュを直接使う方法を選んだ。 DAFS サーバーの最初の実装では、我々はプロック入 4.4 / くッフア・キャッシュのロック の処工眄はホスト CPU のほうか処理しやすい。 ならない。複雑なページテープルの検索 ( つまり変換ミス はそれを直イ屑勺なメモリアクセスでおこなえなくては vm-page 上で叫屯なビットの囓換えが必要な場合、 NIC の TPT を使って変換される佖想アドレスかもしれない。 した参照は、物理 ( バス ) アドレスかもしれないし、 NIC を共有し、 vm-page の茁妾参照をもつ必要がある。 的にアクセスするには、 NIC が仮想メモリ構造体の定義 割り込ますにメインメモリ内の vm-page ビットに効率 みに応してすべておこなうことができる。ホスト CPU に ホスト CPU は、この処理を NIC が発生させた割込 ときに、、参照 " 、、ダーティ " ビットを更新する。 3. NIC は仮想メモリページにアクセスしたり書き込んだ 告するかもしれない。 が、 NIC はそれを待たす、代わりに RDMA イ歹收トを報 はミスハンドラによるべージインが始まるかもしれない 変換は NIC の TPT にロードされる。そうでない場合 がメモリに常駐していることが分かった場合、新しい めにページテープルを検索しなければならない。ページ 2. 変換ミスがあると、 NIC は失われた仮想アドレスのた ネル・インターフェイスに似ている。 やページアウト処理中のビジーなページに使われるカー きなくてはならない。インターフェイスは、ページイン て、転送中はにジーな ) イ瓦想メモリページをロックで のあいだで DMA を開始することができる。したがっ クエストのために、メインメモリの仮想メモリページと 1. NIC は、入ってくる RDMA 翹てりまたは書込みリ てイ反想メモリシステムと情報交換を始める。 NIC は、以下の場合に表 4 のインターフェイスを使っ 表 4 NIC カする仮想メモリ・インターフェイス 関数 vm-page-io-start() vm-page-io-finish() vm-nic-fault() vm—page—reference vm-page-dirty() 説明 ページのロック ページの解放 NIC のフォールトの処理 ー、一ジの参照 ページの : 書奐え RPC は RDMA の完了を待たない。非同期に際して共有 ファイルへの同時アクセスをシリアライズするため、ファ イルの vnode (vp) は RPC の実行中はロックされる必 要がある。しかしながら、転送されたデータバッフアは、 RDMA の実行中はすべてロックされている必要がある。 RDMA の実行中の vp ( つまりファイル本 ) をロック することもできるが、共有している場合はファイルの重複 していない部分のリクエストをシリアライズしなければな らないので生能に限界がある。転送中のロックを vp より も細かい粒度で実行するという我々の尺は、以下のよう に現行の FreeBSD のノヾッフア・キャッシュをロックす る条件と衝突する。 マルチスレッドのイベント馬町丿理カーネルサーバーはバ ネルかプロックを解放できるようになる。 ない。これにより、その後 (biodone() において ) カー 期書込みか先読み ) の前にカーネルに移さなければなら 2. ロックの所有権は、非同期ディスク入出力 ( つまり非同 かカーネルだけがおこなえる。 フアのロックの解除は、ロックしたのと同しプロセス に孑羽勺ロックを取得するプロセスが必要である。バッ 1. キャッシュ内のバッフアをロックするには、バッファ上 173 ーネル自体ではなく、 ( 特定のイベントのためのポーリン カーネルに移してもうまくいかない。ロックの解放は、カ ロックの所有権を非同期ネットワーク入出力のあいだ とき。 2. ロックしたのとは別のスレッドがバッフアを解放する クするためにロックしようとしたとき。 るバッフアを、別のスレッドに解放されるまでプロッ 1. スレッドが、 ( 転送中のために ) すでにロックされてい 問題に直面する。 連してイベント処理をおこなうが、以下のような状況では ッフア・キャッシュを直接使用し、カーネルプロセスに関

” DA ド 5 カ編ネルサ・の設計と実装 表 3 低レベル NIC 仮想メモリ・プリミテイプ に NIC マッピングをもつ場合にセットするようにした。 関数 説明 図 2 では、 PG-RDMA ピットをもつ pv-entry は CPU tpt-init() ネ川月化 と NIC マッピングの両方をもっている。イ瓦想メモリペー tpt-enter() マッピングの挿入 ジーヒでのすべての pmap 操作において、 pmap モジュー マッピングの削除 tpt-remove tpt-protect() マッピングク隻 ルは PG-RDMA フラグが pv-entry にセットされたと きだけ NIC 当辭にを交換する。 テムにおける ( 朱な入出力能力 [ 12 ] をもつ ) プロセッサ 高レベルのコードは、高レベルから低レベルのインター と考え、 NIC とメインプロセッサ間でメインメモリ内の フェイス、そして最終的には pmap まで適切なフラグを カーネル仮想メモリ構造体の共有を許している。我々は、 伝達することで、 NIC の仮想メモリ領域の登録トリガー NIC の代理として仮想メモリ構造体にアクセスするのは を発行することができる。たとえば、 DAFS サー CPU で、割込みに対応してドライバハンドラを実行する RDMA のためにバッフアを使用する際、 vnode インター と仮定している。 NIC がメインメモリ内のイ瓦想メモリ構 フェイス ( 表 2 ) の ioflags?S ラメータに IO-RDMA ヒ、ツ 造体に直接アクセスすることについてはこの節の後半て検 トをセットする。これは、最糸勺には NIC に登録されて いるマッピングとなる pmap-enter() インターフェイス FreeBSD ( および 4.4BSD から派生した他のシステ 内の VM-RDMA フラグに変換される。 ム ) では、物理的ページは vm-page 構造体、アドレス空 NIC にも登録されている pv-entry マッピングを無効 間は vm-map 構造体て表される。ページは 1 つ以 . E の 化する際に間題なのは、そのマッピングを使った RDMA vm-map 上にマップされ、各マッピングは pv-entry 構 転送の最中は NIC で無効にするのを遅らせる必要があ 造体で表されることもある。図 2 のメインメモリ上には、 るかもしれないことである。このため、 pmap-remove- 2 つの一里した pv-entry 構造体をもつ vm-page が示さ all() は複雑なものになる。 ( 排 f 勺に処理するために ) ま れている。 す最初に NIC マッピングをもつ pv-entry 構造体の削除 我々の言 1 て、は、イ廨課メモリシステムは OS-NIC イン を試みなければならす、 NIC を適当な時間で無効にでき ターフェイス経由で NIC MMU を操作する。 NIC は ない場合は失敗に終る可能がある。 NIC-OS インターフェイス経由でイ廨課メモリ構造体にア このほかにも、 NIC の特生に合わないアーキテクチャ クセスする。 白鋤反定にもとづいていることが多い、イ瓦想メモリシステム OS - NIC インターフェイス のポリシーをめぐる間題がある。たとえば、 FreeBSD の OS は、 TPT に保存されたイ瓦想メモリマッピングの追 イ瓦想メモリシステムかフ。ロセスページ・テープルからペー 加、削除、修正のため、 NIC と情報を交換する必要があ ジをアンマップするのは、それがアクテイプからインア る。 RDMA に使われそうなイ瓦想メモリページのマッピン クテイプ、またはキャッシュされた状態に移行したとき グは NIC にる当求しなくてはならない。 NIC に対するマッ である。これは仮想メモリシステムが、再開フォールト ピングの登録は、 vm-map に対する CPU マッピングの (reactivation fault) か上交的低コストだというイ反定にも 設定直後に pmap でおこなわれる。 NIC は、 TPT 工ン とづき [ 7 ] 、ページカ躾際にアクテイプかどうかを石忍す トリを追加、削除、修正するため、 pmap てイ吏用する低レ るためにある程度の数の再開フォールトを起こそうとする ベルイ反想メモリ・プリミテイプ俵 3 ) を公開する。 NIC からである。 NIC の再開フォールトは、 NIC とホスト のマッピングは、あとで当求か抹肖されたり ( オリジナル のメモリシステム間で統合を欠いているため、 CPU の のマッピングか削除 / 無効化された場合 ) 、イ矍か変更され 障害とくらべてかなり高くつく。コスト削減のためには、 るかもしれない。 CPU マッピングだけに使用停止 (deactivation) ホリシ ーを適用し、イ反想メモリページがメモリに常駐しているあ NIC に登録された仮想メモリマッピングのアカウン いだは NIC マッピングには手をつけないのか賢明だろう。 トを保持するため、我々は pv-entry 構造体のなかに しかしながら、 NIC のメモリ管理ュニットを仮想メモリ PG-RDMA ピットを追加し、 pv-entry が CPU と同様 1 = ロ 172 UNIX MAGAZINE 2003.3

A 力、ネルサ、の設計と実 work) と呼ばれることも多い ) に最適化されており、ネッ トワーク・インターフェイスへのユーサーレベルのアクセ ス、 RDMA 、効率的な非同期イベント配信機溝、信頼生 のある通信セマンティクスを提供する。メモリ間転送の例 としては、 VI (VirtuaI lnterface) [ 5 ] や InfiniBand[11 ] を挙げることができる。現在商用化されているメモリ間ネ ットワーク・インターフェイスは、長期にわたる研究の賜 である [ 4 , 15 , 23 ] 。また、さらに高度なメモリ管理機能 の可能性も模索されている [ 21 , 24 ] 。 本節では、 DAFS カーネルサーバーの実装に関連した メモリ間ネットワーク製品の特徴を解説する。 RDMA メモリ間ネットワークは、ユーサープロセスやカーネ ルのアドレス空間に仮想的に割り当てられたバッファ間 で、ネットワークを介してデータを転送できる。ホストは RDMA を実行する前にノヾッフアの仮想アドレスのマッ ピングを NIC に登録しなければならないが、実際のデー タ転送に関与しているわけではない。 RDMA のプログラ ミング・インターフェイス ( テパイスドライバが処理する バッフアの登録は除く ) は、通常はメモリにマップされた 転送記述子のデータ構造体にアクセスするためのものであ る。言翹 0 、物ムみ、 ( そしてときには孑羽勺な ) リモー ト・メモリアクセスが可能である。 NIC に対するメモリバッフアの登録 NIC はメモリ管理ュニットを備えている。これは、 DMA 転送の設定時にホストの仮想アドレスを物理 ( バ ス ) アドレスに変換するためのものである。現在市販され ている NIC の大半は、変換ミスのフォールトを処理しな い。ホストは、アクセスが予想されるすべてのイ瓦想メモリ 領域を NIC に登録する ( すべてマッピングする ) 必要が ある。 NIC にマッピングが登録された仮想メモリページは、 すくなくともそこで RDMA が実行されているあいだは ページアウトか引しなくてはならない。入出力を続け るためにページをロックするカーネル・インターフェイス は、 RDMA がローカルで開始された場合はページアウト の防止に十分に役立つ。 RDMA 転送がリモートで開始さ れることもよくあり ( 詳しくは 3.2 節で解説する ) 、その 場合は転送がいつおこなわれるかを正確に知っているのは 164 NIC だけである。ホスト CPU による過剰なページロッ ク処理を避けるため、 NIC には必要なときにトリガーを 発行したり口ック処理を実行する機能が必要である。 NIC を仮想メモリシステムに統合する機能は 4.3 節て解説す る。そのような機能があれば、サーバーは物理メモリを無 駄にすることなく巨大なバッファ ( 仮想メモリキャッシュ 本など ) を提供できるだろう。 効率的な非同期イベント酉言士組み メモリ間ネットワークは、スケーラブルなイベント通知 や配信のために、、コンプリーション・グループ " という仕 組みを提供する。コンプリーション・グループは、イベ ント通知や配信を単一の構造に集約し、大量のコネクショ ンの一斉ポーリングを単純にする。クライアントのリクエ ストを受信したりデータ転送の完了を知らせるイベントを 効率的に検出 / 処理できる。 コネクション指向で信頼性の高い車医 データ転送は、通常はピアツーピアの転送コネクション ( もしくはチャネル ) でおこなう。信頼生があり、 1 回で 確実に転送するセマンティクスク是供か求められる。その ようなセマンティクスは、 (Fibre Channel[3] のように ) ネットワーク内のハードウェア機能や、 (VI/IP[9] のよ うに ) NIC 上のエンドッーエンドのプロトコルで実装され ることが多い。いすれの場合もホストは関与しない。 DAFS は、メモリ間転送によってネットワーク・ファイ ルサービスを提供している。 3.1 節では DAFS の概要を 紹介し、 FreeBSD 用のプロトタイフ。のサーバー実装につ いて角見する。 3.2 節では Optimistic DAFS のオ既要を述 べる。これは通信における RDMA の比重を高めて RPC への依存度を減らした改良版で、とくにイ反想メモリ・サプ システムに特別なカーネル機能が必要である。 3.1 DAFS DAFS クライアントは、ファイルのリクエストをサー バーに伝えるために簡易版の RPC を使用する。、、直接的 な " 読み書きの操作をおこなう際には、クライアントが送 信元 / 宛先メモリバッフアのイ瓦想アドレスを提供し、デー タ転送は RDMA 操作を使って実行される。 RDMA 操 3 Direct Access FiIe System UNIX MAGAZINE 2003.3

MwareWorkstation ふ 図 7 仮想 HDD の容量の言聢 Specify Di C 叩 トⅸ面聞を物 is di&k わ ? 図 8 仮想ディスクのファイル名の言聢 S 0 海 f ー海 tw Ⅲ引 0 復ー朝市 d 一 V*tudl lvlach•r•'± Wizatd 1 ト v• V ま Machre 物 d Disk File Disk 0 ⅳ V をれ地ー d - れ s 鬱 0 & m 式止「 2Y8 記ゴれミ ー物は u d 朝 kc は一物ロ h を m 歌ー確」 m c 叩、 : 示 y 物飜 you set 「 0 k fi\e 0 dtsk createdfr ”ー 2G 日朝 v れー d 、 0 印 : . ! File 新肥 s each れ Y ルに fWst will を on t め引レ 日 t ~ 第弋れ汀 0 ⅶ女 dh 0 ab 、 mware wnware- く日 ack 図 9 仮想ディスクのインターフェイスの言聢 Select ・ Dev 記 0 No ・ーせー v e 「 3 んス旧物は d 、鱸トに d 協 ? とりあえす初期値のままにしておくことにしました。仮想 ディスクの台数はあとで増やせますが、 1 台の仮想ディス クの容量は増やせません。ですから、本来は事前によく考 えて設定したほうがいいでしよう。 仮想ディスクの容量を設定したら、仮想ディスクとし て使う ( ホスト OS 上の ) ファイルを指定します 9 。初期 値は、、 OS の不頁名 " に、、 vmdk" という拡張子を加えた名 前で、 Linux であれば、、 Linux. vmdk" となります。イ反想 ディスクが 1 台だけならどんな名前でもかまいませんが、 あとでイ反想ディスクを増やす予定があるのなら、どのファ マンス・テストによれば、 SCSI 接続のほうが性能がいい イルがどの保想ディスクに対応するのかが分かるようにし ようです。しかし両者の差はかなり縮まっているような ておいたはうがなにかと便利です。 ので、ふだん使っていて気になるほどの違いはないと思い Linux の場合、 IDE 接続のディスクは、 ます。機能の面では、 IDE のはうは接続できる装置 ( ハ ドディスクや CD - ROM ドライプなど ) が 4 台までなの プライマリ IDE チャネルのマスター→ hda プライマリ IDE チャネルのスレープ→ hdb に対し、 SCSI では 7 台までという違いがあります。とは いっても、ゲスト OS でハードディスクや CD ー ROM な ・セカンダリ IDE チャネルのマスター→ hdc どを 5 台以上も使うケースは稀でしようから、この点につ ・セカンダリ IDE チャネルのスレープ→ hdd いても決定的な違いはないといえます。 という名前で認識されます。そこで、図 8 のように したがって、通常はデフォルトの j 尺肢である SCSI を 、 hda. vmdk" に変更しました。 選んでおけばよいのですが、私は VMware が SCSI をサ なお、図 8 でファイル名を設定しただけで次に進むと、 ホートする前から使っているせいか、ついつい IDE を選 イ反想ディスクのインターフェイスは SCSI 接続になりま ふ癖 ( ? ) がついてしまっているようです。 す。 IDE 接続にしたい場合には、図 8 の [Advanced>] 設定工テイタによる設定 ボタンをクリックし、接続するインターフェイスの不頁な どを設定します。今回は、図 9 のように IDE 接続の 1 番 新規作成ウィサードによる設定力院了すると、図 10 の 目 ( プライマリ IDE チャネルのマスター ) のディスクに ように新たなゲスト OS か登録されて起動可能な状態に 変更しました。 なります 10 仮想ディスクの接続インターフェイスとして IDE と あとはゲスト OS としてインストールする Red Hat SCSI のどちらお邇尺するかですが、文献 [ 1 ] のパフォー 10 左側の、 RedHat73 " の上に見える "asurni" は、和めゞふだん使って 9 イ反想ディスクのファイルは、図 3 てオ旨定したフォルダにイ友されます。 いる Kondara MNU/Linux 2.1 の開発コード名です。 糾リ V いし引 Ma 」川澪 W 辷 d mwa re く日 k 94 UNIX MAGAZINE 2003.3

旧 v4 / 旧 v6 テュアルスタック ( 4 ) 表 1 よく不堋する情報収集用のコマンド (admin モード ) IPv4 のコマンド IP IPv4 嬲里の清報の表示 IPv6 のコマンド ip6 IPv6 里の情報の表示 ネットワーク車のコマンド IP インターフェイスの状態の表示 interface ルータの状態を確認するためのコマンド information テンヾイスごとの重川料大況の表示 verslon who ソフトウェアのバージョンとハードウェア情報の表小 ログイン中のユーザーに関する情報の表示 ロ久糸情報のコマンド log ログ情報の表示とネ川月化 図 9 ROUTE-OS のパージョン認 gr2000—2b/admin> version S/W: S ー 9181 ー 6B 07 ー 00 ー / B CROUTE-OS6B, interface KEY 01 / 23 21 : 28 : 38 operator KEY 01 / 23 21 : 32 : 15 operator: 10g Logging lnformation Rout er lnf ormat i on gr2000-2b/admin> 10g 図 10 ログの表示 gr2000—2b/admin> Routing software] GR2000 ー 2B , S ー 9181 ー 6B 07 ー 00 ー / B [ROUTE-OS6B] (Bui1d:42) , :verSIOn RMO (Active) interface コマンドは、 UNIX 系の OS での ifconfig に相当します。、、一 a " オプションを付けて、ルータがもつ インターフェイスの状況を一覧表示したい場合などに利用 します ( 末尾の図 18 ) 。ライン名を引数に茁旨定すれば、 そのラインだけの情報を表示させることもできます。 information UNIX MAGAZINE 2003.3 ったコマンドか実行できないということがあります。その 旧いバージョンのまま利用していると、人から教えてもら OS としてはソフトウェアの更新頻度が上交的高いので、 最新の IPv6 機能に対応するためもあって、ルータ用の は、 version コマンドて市忍することかできます ( 図 9 ) 。 GR ルータで測イ乍している ROUTE-OS のバージョン verslon します ( 末尾の図 19 ~ 20 ) 。 合には、 information コマンドの引数にライン名を指定 インターフェイスに関する情報をより講田に知りたい場 ため、 ROUTE-OS は他のルータ以上にバージョンに注 意するはうがよいでしよう。 log log コマンドは、 GR ルータがルータ内部に保存してい るログメッセージを表示します ( 図 10 ) 。 syslog による情報収集 このとき、もちろんログの書出しを受ける UNIX 側でも この設疋には、 logger コマンドを使います ( 図 12 ) 。 ンを利用してログか参照できます ( 図 11 ) 。 UNIX システムを管理用に用意すれば、その UNIX マシ 用されている口外己録用の機能です。 syslog に対応した ご存しのように、 syslog は UNIX OS では標準的に利 で言当求する方式になっています。 グやエラーログは、 syslog を利用してネットワーク経由 めに必要な記慮装置がありません。そこで、各種の情報ロ GR ルータ本体には、長期にわたってログを保存するた 59

- DA ドルサ、バ設計と実第 表 1 vnode 操作 vnode 乍 説明 アクセス許可のチェック VOP-ACCESS プロック数のマップ VOP-BMAP プロックの言ムみ VO P -B READ プロックバッフアの解放 VOP-BRELSE ファイルを閉したことをマーク VOP-CLOSE ファイルの作成 VO P -CREATE VOP-FSYNC ダーテイプロックのフラッシュ ファイル属を返す VOP-GETATTR vnode をインアクテイプとマー VOP-INACTIVE ク 入出力制餌牒作の実行 VOP-IOCTL ファイルにリンク VOP-LINK ファイル名の検索 VOP-LOOKUP ディレクトリの作成 VOP-MKDIR ファイルをオープンしたことをマ VOP-OPEN ファイルの言翹 ( り / 書込み VOP -RDWR ファイルの削除 VOP -REMOVE シンポリック・リンクの言翹えり VOP-READLINK ファイルの名前変更 VOP-RENAME ディレクトリ・エントリの言翹 ( り VOP-READDIR ディレクトリの削除 VOP-RMDIR ファイノレシステム・プロックの言冗 VOP-STRATEGY 取り / 書込み シンポリック・リンクの作成 VOP-SYMLINK VOP-SELECT select ファイル属の設定 VOP-SETATTR イ瓦想メモリ内のページの言翹りと VOP-GETPAGES マップ マップされたページのディスクへ VOP-PUTPAGES の書込み Sandberg らによる [ 20 ] 。 イス ( 後を内部で使用する。これは引数の 1 っとして、 リクエストの状態を参照できる非い期入出力制徊ワ・ロック (kaiocb) をとる。 aread(struct vnode *VP , struct kaiocb *Cb) cb からプロック入出力リクエストを得る ; bp = getblk(vp, プロック・リクエスト ) ; if ( パッフア・キャッシュ内に bp がみつからない ) { EVFILT_KAIO を使って kevent を登録 ; bp をもつ kaio-biodone ハンドラを登録 ; VOP_STRATEGY ()p , (p) ; 表 2 ′くッフア・キャッシュへの vnode インターフェイス vnode 操作 説明 入出力に必要なすべてのバッフアを VOP-BREAD ロック。 vp からの言もムみ 入出力に必要なすべてのバッフアを VO P -A READ ロック。 vp からの言ムみ。プロッ クしない ダーティエントリをマーク。 vp へ VOP-BDWRITE の遅延書込み。リクエストがあれば 状態を史新 vp へのプロック書込み。リクエス VO P -BWRITE トがあれは態を更新 ダーティエントリをマーク。 vp へ VOP-BAWRITE の非同期書込み。リクエストがあれ は状態を更新 バッフアを解放。リクエストがあれ は状態を更新 ための kaio-biodone() か呼び出される。 kaio—biodone (struct buf *bp) bp から kaiocb を取得 ; kaiocb の klist 内の knote にイベントを配信 バッフアを解放し、必要に応してファイルシステムの 状態を更新するために VOP-BRELSE か使われる。ロー カルのファイルシステムは、 DAFS サーバーの効率的な 実行のために表 2 のインターフェイスを実装する。このイ ンターフェイスや他の適当なインターフェイスがない場合 でも、ローカルのファイルシステムは既存のインターフェ イスを使って DAFS サーバーを構成することができる。 しかし、マルチスレッド処理などのためにオーバーヘッド が大きくなってしまう。 ネットワーク・イベント配信は、前述のように kevent 冫欟冓を通してディスク入出力のものと統合することができ る。 RDMA ⅱ当子が発行されるたびに、 kevent が EV- FILT-RDMA フィルタを使って登録さオ t 、コンプリー ション・グループ (CG) 構造体に言当求される。コンプリー ション・グルーフのハンドラは kqueue のイベント配信 を扱う必要がある。 send—event ()G *cq, Transport *vi) CG の klist 内の knote にイベントを配信 ; VOP-BRELSE aread() か発行したリクエストか完了した点では、デ ータはロックされた状態で bp に存し、イベント配信の DAFS サーバーは、 kqueue の定期的なポーリングに 169 UNIX MAGAZINE 2003.3

- DA ド S 力、ネルサ編の設計と実第 図 1 イベントー DAFS サーパー : ディスク入出力 : 駆動状態遷移 bio-done bp がロックされた : ネットワーク入出力 ー駆動状態遷移 recv-d 0 ne リクエストがキュー に加えられた アイドル bread 上 で封鎖 テータがキャッシュ : データがキャッシュー にある場合は RDMA を開始 : リクエスト の処理 bp がロック されている ) いだはプロック bp が解放された send-done 既存のインターフェイスでプロックは可能である。 作はつねにサーバーから発行される。本稿では、 の構造と入出力性能を中心に解説する。 3.1.1 サーパーの言雌十と実装 サーバー こでは、既存のカーネル・インターフェイスを使用し た現行の DAFS サーバーの言妬と実装について解説する。 フロトタイプの DAFS カーネルサーバーは、図 1 のイベ ント駆伏態遷移図のように衄乍する。イベントは太字の 關本て示している。イベントの下の矢印は、イベントか起 きたときの重川乍を示している。おもなイベントトリガーの 状態遷移は、 recv-done ( クライアントて始まる転送が 実行された ) 、 send-done ( サーバーて始まる転送か夫行 された ) 、 bio-done ( ディスクからのプロック入出力リ クエストか実行された ) である。以下に、現行の実装にお ける DAFS サーバーの言 1 ・」 : マ吽芋徴をまとめる。 1. サーバーは、ディスク入出力をおこなうためーンヾッファ キャッシュ・インターフェイス (bread() 、 bwrite() な ど ) を使用する。これはゼロコピー型のインターフェイ スで、 RDMA を継続するためにバッファ ( ページや マッピンクつをロックすることができる。 RDMAEGL は、バッフア・キャッシュとのあいだで直接おこなわ れる。 2. RDMA 転送は RPC ハンドラのコンテキストのなかで 開始されるが、非期でおこなわれる。開始した RPC UNIX MAGAZINE 2003.3 の終了後かなり時間か経ってから RDMA カ院了す る場合もある。 RDMA に関与するバッフアは、転送 を続けるためにロックされたままでなければならない。 RDMA の完了イベントハンドラはこうしたバッファ のロックを解放し、必要であ川ま RPC の応答を送信 する。 3. カーネルのバッフアキャッシュ・マネージャーは、物 理ページがバッフアから追加または削除されるときに バッフアのマッピングを NIC に随時登録 / 掘肖するよ うに修正された。このため NIC か変換ミスのフォール トを起こすことはなく、ページは RDMA を続けるあ いだだけ石呆される。 ネットワークやディスクの各イベントに対して、カーネ にまとめられている。どの転送コネクションにメッセージ 転送コネクションは、同しコンプリーション・グルーフ りはデータ中応当こ関与する作業スレッドになる。すべての つカ噺しいコネクションを受け付ける役目を担い、残 内部の rfork() 操作によって作成される。スレッドの 1 ドを生成して並列処理を実現する。カーネルスレッドは、 プロッキングに対処するため、サーバーは複数のスレッ ネージャーによって処理される。 は biodone() 内のカーネルのバッフアキャッシュ・マ クしていたスレッドを起こす。このイベントは、現伏で で、以前に bread() か始したディスク入出力でプロッ 3. bio-done はディスク・コントローラが発生させるもの 使って ) 解放し、 RPC の応答を送信する。 ンドラは転送に関した bp のロックを (brelse() を まった ( 読み書き ) RDMA 操作の完了を通知する。ハ 2. send-done は NIC が発生させるもので、サーバーで始 の状態になる。 開始され、 bp は転送を続けるためにロックされたまま クされる ( 以後はこれを、、 bp" と呼ぶ ) と、 RDMA が ノヾッフア・キャッシュのなかでノヾッフアにデータがロッ ルシステムでプロック入出力を開始するかもしれない。 み書き操作の場合、ハンドラは bread() を使い、ファイ RPC リクエストの処理のトリガーになる。たとえは読 1. recv-done は NIC が発生させるもので、入ってくる ドラがある。 ルスレッドのコンテキストのなかで実行するイベントハン 165