「5.0を待ちながら」連載 NT5.0エッセイ

・ Chapter 3 ・

-- NTでもDFSをとうとう実現 --

BY Keith Walls 翻訳 岡登 洋平

 この連載「5.0を待ちながら」では,今度はバージョン5.0の新しい統合された分散ファイルシステム(Distributed File System:DFS)に焦点を当てることにしよう.PC の名残りで頭を悩ませていた人にとって,DFSは朗報である.

―――――――――・―――――――――

 ちょうどこのコラムを書いている時に,マイクロソフトは Windows NT バージョン 5.0 が今年の終わりまで出荷されない見込みであることを発表した.この声明によって,マイクロソフトは報道陣,ユーザー団体から大変な非難を受けることになるだろう.ウオールストリートの金融機関でさえ,マイクロソフトの指導力と技術的な安定性に関する中傷騒ぎに加わるかもしれない.さらに,司法省は Windows バージョン 5.0を元のスケジュール通りに交付しなかったということで,マイクロソフトに対する新しい訴訟の種を見つけたに違いない.マイクロソフトバッシングは急速に国民的な気晴らしになってきていると言ってもよいだろう.

 しかし私は祝辞を述べて,この決定を支持したい.連載1回目でも言ったように,開発者やそれに近い人にとって,安定性の低いものを出されるより,待ったとしてもより安定して,信頼できる OS のプラットホームを出される方がはるかに良いからだ.

 もちろん,分散ファイルシステム(Distributed File System:DFS)は産業界にとって新しい考えというわけではない.我々はいろいろな UNIX環境やOpenVMS,それ以外のプラットホームでDFSを見てきている.基本的にDFSはクライアントにあるファイルの名前空間を拡張するものだ.本当の問題は,どのように実現するかである.

 エンドユーザーが Resume.doc というファイルを作り,後でそれを探して編集する必要が生じたとしよう.そのシステムには同名のファイルを含む6つのディスクがあるとしたら,どのように探せばよいだろうか?

 Windows NT バージョン 4.0では,唯一の選択は検索ツールを使って6つのディスクすべてを検索することだ.ユーザーが遠隔のディスクにファイルを作成したり移動したりすると,それを探す作業はさらにやる気を失せさせるものであり,時間のかかるものとなる.しかし,適切に設定されたDFSはこの問題を軽減することになる.

名前(空間)に含まれるもの

 「名前空間」という言葉にはいくつもの意味があり,それは文脈に依存する.一般的には名前の付いたオブジェクトの集合を意味し,それはコンテナーとして働くものがコンテナーのユーザーに示すものである.例えば,あるディスクの名前空間とは,そのディスク上のディレクトリーとファイル名の完全な集合である.この例ではディスクボリューム上の名前空間は自然に階層的になる.

 さらに技術的に言うと,名前空間とは,名前とオブジェクトへのポインタを集めたものである.それは類似したオブジェクトをグループ化した集合を表しており,それは階層の一番高いレベルになる(ディレクトリーなので階層構造を成すが,これより上のディレクトリー<名前空間>は無い).

 例えば,Windows NTではシステム管理者が「共有名(share name)」を作成できる.これらの共有名はいくつかのUNIX環境における「マウントポイント」のように利用できる.既にある名前の局所的リストの中に,自分で選んだ新しい名前を挿入する.それから目的に合うように名前を変換するのである.

 すべてのユーザーのファイルをあるディスクのボリューム,ここではデータベースと一緒に,F:に置くことを考えてみよう.我々は "Users" というディレクトリーを作り,その中にそれぞれのユーザーごとのディレクトリーを置くことができる.それから"Disk4Users" という共有名を作って,"F:\Users"にあてることができ,共有している共有名に関してどんなユーザーについてもデフォルトのログインディレクトリーを表すことができる.

 手始めとしては,手堅くて良いやり方ではある.しかしWindows NT ベータバージョンを入れた初日からシステム管理者が直面する大きな問題が2つある.1つは Windows NT は1文字のドライブ名しか使えないことだ.これはその企業でやろうとしている OS の利用とまったく合わない.もう1つは論理名に関する準備がまったくないことだ.Windows NT のレジストリを隅から隅まで見てみると,アプリケーションからデータファイルに至るまで,すべて明示的に1文字で示されるドライブ名で始まる場所に結びつけられていることがわかるはずだ.

 しかし,論理名があったとしても,普遍的で万能な方策ではない.例として OpenVMSの論理名の実装を取り上げよう.そこでは論理名に変換できるのはOSのみである.

 論理名に変換するアプリケーションは,システムのサービスを呼び出さなければならない.その結果として,OSはすべての階層的名前空間の管理人となってしまう.この状況は,さらにたちの悪い問題をひき起こすことになりうる.

 OS が論理名空間の唯一の管理者だとすると,名前が完全に変換されたかどうかシステムの上位コンポーネントはどのように知るのだろうか?言いかえると,名前の変換が行われないとき,どうやって OS がそのことを知るのだろうか?さらにアプリケーションは論理名が変換されていないことを,どのように宣言しうるのだろうか?

 OpenVMS では,ディスクを "SERVER$DKA200" のように命名できる.しかし,"SERVER$DKA500" は同じく正当な論理名でもある.解決するには結果を定義する少数の単純な規則を繰り返し適用することだ.もしデバイス名が2つのアンダースコアで始まっていたら完全に変換されたと考える,というのも1つの規則である.この良い解決方法もまた別の混乱を招く.というのもアンダースコアは論理名としてもまた正しいからである.いくつもの曲がりくねった論理の後で,OSは論理名の変換を行うには不適当であることが明らかになる.では,どこでそのような変換が行われるべきなのだろうか?

文脈,文脈,文脈!

 概して変換する元の名前は,変換が要求されていることが明白な文脈で現れる.もしOpenVMS を動かしているシステム管理者がSHOW LOGICAL コマンドの出力をきっちりと見たら,論理名が以下のものに限られることがわかるだろう.それはアプリケーション,ファイル,ディスク,フォントやサーチパスのようなものにのみ関係するもの,である.  Windows NT のバージョン5.0 において期待されるのは,マイクロソフトがこれらのような問題に対して2つの完全で洗練された解決を示すことである.1つはアクティブディレクトリー(Active Directory)であり,それは先月述べた.もう1つがDFSである.

 マイクロソフトがバージョン5.0でしていることは,論理名と論理名テーブルの概念を置き換え,実質的にそれらを改良してしまうことだ.それは本質的にさまざまなレベルにおいて目的を特定した論理名を示しており,全体を整理された,まとまったものとして結びつけるために,アクティブディレクトリーサービスを行う.この整理は,システム管理者とプログラマーの両方に対してである.

 先月述べたように,アクティブディレクトリーは完全に安全なディレクトリー(つまり階層的名前空間)である.バージョン5.0の統合コンポーネントとして分配されるDFSもまた,LAN や WAN を介して広がるファイルを参照するポインタを持つ階層的名前空間である.さらに, DFSの定義はオブジェクトであるから,アクティブディレクトリー内に含まれることを妨げるものはない.

 これが何を提供したのかを見てみよう.アクティブディレクトリーは Windows NT 5.0 の多くの機能のうち中心的なものである.オブジェクトやそのインターフェースを探したいときは,アクティブディレクトリーの内を見ればよい.目的のオブジェクトが別のディスクや異なる DFS ボリュームに移ったとき,アクティブディレクトリーは新しい位置を反映させるように更新されることになる.アクティブディレクトリーは,それゆえ潜在的にはネットワーク内のあらゆる種類のオブジェクトを指定し,また探し出す,巨大な名前空間である.

 Windows NT バージョン5.0のDFSに話を戻そう.DFS の目標はシステム管理者がDFSの共有名を定義できることだ.共有名は順次,共有名のリストを指定する(指すようになる).システム管理者が DFSの共有名を作成したとき,エクスプローラ内に DFSのルートが出現する.エクスプローラを使うとユーザーはルートを開くことができ,DFSの構成要素の共有が表示される.そうなれば,ファイルの検索の仕事はとても簡単だ.DFSルートボリュームを定義したら,それが複数のサーバーにまたがっているとしても,エクスプローラ内の正規のすべてのツールは,文書の検索のほとんどのアプリケーションベースの検索ユーティリティーと同様に,そのDFSツリーをサポートするだろう.

 とはいえDFSには別の利点もある.それは単純なファイルシステムよりも検索の処理をもっと速く,便利にすることである.複数の物理ボリュームにまたがることによって,多くの共有を起動し継続的に記録する手間が省ける.DFS は必要が生じたとき,コネクションを生成するからだ.このことはまた,ネットワークのディスクに付けるドライブ名が1文字であるというクライアントの制限を解消するのに役立つ.

性能と負荷の均等化

 DFSボリュームはそれぞれ代替の複数の下位のボリュームを指すことができる.これは通常の'AND'関係に加えて'OR'の関係の表現を許す.ある下位ボリュームが失敗した場合に,代替ボリュームが置き換わる.

 DFS共有を通して多くの作業が行われているとき,DFSは主要ボリュームに加えて代替ボリュームに対するクライアントの要求を延期する.DFSのボリュームメンバーシップセットを介して自動的に負荷が均等化されることになる.

 Windows NT バージョン 5.0 は古いバージョンの Windows NTのサーバーやワークステーションと同様に Windows95/98のワークステーション用のDFS クライアントソフトウエアを供給する.さらに,DFS は NetWare と Windows NT のネイティブボリュームの両方との連結も可能である.

 アプリケーションの,あるいはユーザーのデータ空間を移動する必要があるとき,そのデータは移動でき,ユーザー,あるいはアプリケーションに直接目につくことなく DFSボリューム定義を完全に独立して調整できる.

 つまり論理名ポインタを通してデータへのアクセスを行っているため,データの実際の場所は関係ないのである!ロードバランスがとれていること,データの位置に対して透過性があることは,自然にフェイルオーバーに対する保護になっている.下位ボリュームあるいはそのホストサーバーが動作しない場合には,代替のボリュームが代理を務め,サービスは中断することなく続けられる.

バックアップに関する利点

 DFS はボリューム管理を容易にるため,DFS 管理者プログラム(DFS Administrator Program)という GUI プログラムが準備されている.少なくとも重要な点は,DFSはまたプログラミングインターフェースも備えていることだ.これらは追加,削除,DFSボリュームの数え上げを含んでいる.さらにDFS共有定義における接続ポイント内部で,情報の取り出しの設定が可能である.

 またバックアップに関して,DFSは大きな利点をもたらしている.しかしDFSを用いたバックアップには,これまでと異なる要因の,注意すべき大事な点がある.単一のDFSボリュームというものが作成可能である――これを「"All_Disks"(すべてのディスク)」と呼ぼう――それはドメイン内の各システム(サーバー,ワークステーション)の各ディスクをその下位ボリュームとして持つ.DFSボリューム All_Disks はオブジェクトなので,Windows NT の持つすべての安全性制御を持つ.結果として,我々のDFSボリュームである All_Disks はドメイン内のすべてのストレージのバックアップの指定が容易になりうる.

 この"All_Disks" の枠組みを小さくするとどうなるだろうか?まずバックアップのサイズを考えてみよう.それは直接テープサブシステムの装備に影響を与える.さらにシステム管理者は今や遅いメディアで複数のディスク全体の回復を行うのを避けるために, DFS がわかるパッケージでファイルの回復を行うか,バックアップメディアの内容について,しっかり把握していなければならない.Windows NT DFSの最もはっきりした利点は,組織に合わせて最良の方法でデータタイプとグループ化する能力があることだ.データの区分はディレクトリー構造によって制限されない.このことは,単一のDFS 共有名が,まったく無関係で全体として独立しているディレクトリーやサブディレクトリー以外のものはすべて指し示すことができることを意味している.

 例えばシステム管理者は "Public" という名前のDFS 共有名を作ることを選択したとしよう.その共有名の参照先は以下のようになる.
\\CorpSvr1\Public Files,
\\AcctSvr4\SalesFigures,
\\UserSvr7\UserUtils,
\\UserSvr9\UserRootDir
 Windows NT のDFSは,より柔軟な管理,より良い設定制御,より良いバックアップ制御,ついには実際的な論理名の定義と管理まで可能としているのだ.

―――――――――・―――――――――

 今後のコラムでは,Windows NT バージョン5.0全体のフェールオーバーの許容能力について,インテリミラー(Intelli-mirror)が提供する機能に関する議論を通じて,理解を深めていこう.

出典 BackOffice Magazine February 1998, pp.88-91.
ゥ1997 BACKOFFICE MAGAZINE by PennWell Publishing Company.