えらく感動したので、分散ファイルシステム(Distributed File System：以下DFS)について自分の理解を含めて記事に。
DFS、基本は「名前空間管理機構＋実ファイル格納場所」
DFSは仮想的なディレクトリツリーを管理して、実ファイルの場所を知っている"名前空間管理サーバ"と、実際のファイルデータを格納する"実データサーバ"から構成されている。
※呼び方は一般的を目指した適当です、実データのほうはソフトによって ターゲットサーバ とか チャンクサーバ とか呼ばれます。
クライアントはファイルのパスを "名前空間管理サーバ" に問い合わせ、実際のファイルデータ格納先にデータを取得しにいくという動き。
DNSの名前解決や仮想メモリのマッピングがよく似ている。それどころか単一HDD(FilrSystem)にファイルを保管するときもポインタと実データという組み合わせがほとんど。
基本は特に変わってなく、むしろデータ扱いのお手本のような動作をしている、そんなDFSのメリットは拡張性と耐障害性。
HDD一つならファイルがどこにあるかと言う情報は一つ、実データの場所も一つ。しかもそれらは1箇所にまとまっていて、手違いで洗濯機に放り込んだら復活は厳しいでしょう。
それをディレクトリの構造だけ知ってるサーバと、データだけ持ってるサーバに分けてみる。
ディレクトリの構造は単純な情報、小さなメタデータなので複数のサーバで共有しておける。そして各ディレクトリについて保管先のサーバ情報が必要なのだが、複数もってもよいわけで。
「AAと言うディレクトリはサーバ1号と3号にある」としておけばDFSは両方にデータを書くし、使う側もどれかを適当に選択して使う。
これならサーバが一台くらい火を噴いても、ファイルシステムはびくともしない。
DFSをまとめると、
ツリーは一つ、でもぶら下がっているデータが複数の場所に格納してあって、コピーもあちこち保管されてるからどれ使ってもOK、少しくらいならぶっ壊れてもOK。という仕組みだ。
クライアントからはいつまでも単一のツリーで変わらないが、保管先を増やせば容量が増える、レプリケーション先を増やせば耐障害性があがる、過去の様々な問題をクリアするべく考えられている。
WindowsServer2003(R2)以降のDFS
初めて触ったDFS、 ActiveDirectory(以下：AD) スゴー と思った。
分散だけなら一応ADなくてもできるけど、レプリケーションはAD必須だった気がする。
特徴として、見た目が既存の共有ファイルシステムと変わらない、名前空間の管理にADを使えば管理も楽ちん。
ツリーの分散はディレクトリ単位で行う、レプリケーションもディレクトリ単位だけど、レプリカされるディレクトリは同時に書くのではなく、更新があったら差分を転送するだけなのでパフォーマンスはよい。
ちゃんと知りたかったら下記とか見たほうがいいです
参考/@IT：強化された分散ファイル・システムDFS
参考/@IT：強化された分散ファイル・システムDFS
以前ファイルサーバの移行をする必要があったときに、いかにシームレスにやるか考えた結果利用したのですが、まぁ殆どほったらかし。
ファイルが2重化されるまで待って新しいサーバ(DFS仮想パス)を案内、マルチマスタのレプリケーションなので、いつまでも古いほうが使われてデータの整合性が取れなくなるとか心配もなく、ファイルサーバ更改のアナウンスが浸透するまでまた暫くほったらかし。
ほとぼり冷めたら古いほうをDFSから切り離して移行完了と。古いサーバもしばらく撤去しなかったのでそのままレプリケーションをしてファイルの冗長性を確保。なんと素敵な移行計画でしたでしょうか。
ただ私の設定詰めやらネットワーク環境の把握が甘いのか、Windows以外のクライアントではどうもきっちりとDFSの名前空間が使えない点で困った。
サーバに直接接続できる共有パス(UNCとか)を使えば名前空間関係ないので普通に利用できるし、直接ターゲット側をいじってもレプリケーションはできるから気にしないでいいんですが。
印象としてはADを使った社内ネットワークインフラと親和性が高い、レプリケーションは時間帯で帯域幅を制限できるし、マスタは中央だけどパフォーマンス向上のためVPNで繋いだ事業所にレプリカを設置など、工夫次第でとても便利に使えそうだ。
あと重要なのが名前空間がぶっ壊れた場合、元がWindowsの普通のフォルダなので直接見ればファイルはちゃんと残っている。この辺があるのでそこそこ気軽に導入できるでしょう。
GFS、HDFSに見られるDFS
再度書くけど、関西レンタルサーバ会関連の方にHadoopというのを教えていただいた。
GFSは "Google File System" 、HDFSは "Hadoop Fire System"で、Googleの基盤を支えるGFSの仕様を参考にオープンソースでHDFSが作られたらしい。
株式会社 Preferred Infrastructureさんの解析発表 ⇒ と解析資料
CodeZineの構築記事
業務の待ち時間に上記リンクを見た瞬間、実際にCentOS5上にHDFSを作ってみた(興味を煽られたため作らざるを得なかった)、ファイルシステムそのものを形成するという仕様にとても驚いた。
特徴、名前空間が仮想なら、実データも領域が仮想化された空間に格納される。通常のファイルシステムと全然違うので、クライアントからのファイル操作もAPIを通じて行われる。
例えばls をしたければ付属のファイル操作コマンドを "-ls" オプションで実行するといった具合。
最初から大規模なアプリケーションを動かすことを前提に作られていて、アレコレも各サーバに散らばせている、物理サーバを意識しなくともよい作りといえばよいのかな。
詳しく書くと長くなりすぎるのでHadoopに興味があるなら前述のリンク先がお勧め、しっかり理解できる。レプリケーションの考え方とか単純にすごい。
このHDFSはそれに依存するhBaseというDBの仕組みがある。広大につくったHDFSの記憶域上に作るテーブル群、DFSの特徴である拡張性と耐障害性に優れたDBを使うことができるようになる。
正直これは凄い、と思う反面、検索エンジンくらいしか使い道が思いつかない。。
次点でログ収集＆解析サーバか。クライアントさえ入れておけばサーバ何台増設しようと同じ設定でログを集積することができるかも。
ファイルシステム操作が独自のAPIなので普通のアプリケーションからは使いにくい、まさに大規模向けというかGoogleが自分で使うために作り出した仕組みのように思える。
中途半端に使い始めて、名前解決サーバがイカレたらどうなるんだろう、WindowsのDFSのようにはいかないだろう、というか諸行無常？
一言でまとめるとWEBアプリ向けだ。多分。
しかし折角Hadoopのような面白い仕組みがあっても普通のファイルシステムでない時点で、プログラムが作れないと何もできない気になるのはインフラばっかりやっているからでしょうね。
インフラ理解して作れるだけのエンジニアというのも中途半端だなぁと考えつつも、アプリは作れる人が作ってくれるのでまあいいかとも思う。
できないところは誰かに補ってもらう、これってやっぱり楽しいと思う。
↓GFSを知ったので次はこれを読みたい。
しかし文字ばっかりのエントリになったな。。。
