来週は休講
だから今日入れて後3回くらい
課題はあと1回くらいは出す
残念ですが付き合ってください
分散ファイルシステム
データを共有するためにはどういうことを考えなければいけないか
Network Attaced Storage
ファイルサーバ専用機
ネットワークに接続して共有ディスクとして利用
ネットワーク越しにデータを放り込んでおける便利なもの
外付けのHDDのようなもの
見たことない人は生協で売ってるので探してください
外付けのUSBディスクだったらUSBケーブルだけどその代わりにLANケーブル
ネットワーク越しにデータをやりとりするのに便利
今日はこういうのを作るときにどういう仕組みになっているのか話をする
生協に売ってるのは安価な市販品
せいぜいPCが1台か2台くらい繋げればよい
いい加減に作ってそんなに性能がでなくてもそんなに困らない
これのもうちょっと大規模なやつは普通ファイルサーバーと呼ばれる
ラックに入っていて、でかい、電気を食う、うるさい
こういうのだと100人とかファイルをサーヴィスするのにも使えるはずなので
かなり真面目に設計をする必要がある
理学部の情報化学科の演習室の
Macはマシンについているディスクは使われていなくて
ネットワークを通じてファイルサーバーに保存される
演習室の席を決める必要がない
別な大きなコンピュータのディスクに保存しておけばどのマシンからでも見ることができる
みんなわりと使っている縁の下の力持ちてきな存在
問題は、どうやって作るかなんですけど
アイディアは簡単
ハードディスクは物理的にマシンと繋がっている
ファイルを読みたい場合、
OSがハードディスクにアクセスしてデータをもらってくる
ネットワーク
ファイルシステムの場合は、
まずOSに頼む
OSからネットワークを通じて相手のOSに要求する
相手のOSがハードディスクを読み込んで送る
ファイルを書く場合も同じような感じ
読んで上書きすればいい
これで終わり
簡単です
ただいろいろな
アーキテクチャというか
プロトコルがあって
UNIXの場合は
NFSがよく使われる
Windowsの場合は通称SMB
最近だと
iSCSIとか色々なものが出ている
やりとりするときのデータフォーマットが違うだけ
データフォーマットのことを
プロトコルという
今日は
プロトコルの詳細を話すことではないがともかく色んな物がある
HTTPもある意味
分散ファイルシステムの
プロトコルとみなすことができる
HTTPはウェブブラウザとウェブサーヴァの間のやりとり
やっていることは結局ファイルのやりとり
HTTPの場合は読むだけで普通は書くことはできない
でも
プロトコルの仕様では書くこともできることになっている
Linuxの
ファイルシステムでHTTPを使うものもあった気がする
なので基本的なところはすごく簡単
簡単で終わってしまうと話すことがないので
わざわざ話すと言うことは簡単ではない
安いやつを作るときにはこれくらい知っておけばいい
大規模なものを作るときには工夫しなければいけない
一般に、こういう
分散ファイルシステムを作るときには4つの指針がある
Performance
読み出しにかかる時間がどれだけ少ないか
これはわかりやすい
Scalability
近年では結構重要なキーワード
どのくらいたくさんのクライアントに対応できるか
ウェブサーヴァなんかでも重要
誰も見に来ないマイナーなブログだとどうでもいいけど
YouTubeみたいなサイトをつくろうとすると重要
ScalabilityとPerformanceは独立ではない
トレードオフになりがち
設計上はどちらが大切か良く見極めてバランスをとることが重要
Consistency
ファイルシステムなのだから、
同じファイルであればどのマシンから見ても同じ内容であるべき
どのマシンからみても同じファイルは一緒じゃないかと思うかもしれないが
パフォーマンスを上げるためにキャッシュを使うとか
Dependability
サーヴァがクラッシュしたときにどれだけ頑強か
クライアントPCも巻き添えを食ってクラッシュすると困る
そういう事態にどう対応するか
4つの指針を全て満たすのは難しい
あちらを立てればこちらが立たず、というのはコンピュータシステム一般に言える
その分野の指針を見極めて、どこを重視するのか考える
そういうことを
分散ファイルシステムを題材にして考える
Sun microsystems'
NFS
Sunが元気がよかったのは80年代
90年代あたりからおかしくなってきて
2000年代にはいつつぶれてもおかしくないと言われつつまだつぶれていない
1980年代に登場
80年代というところが重要
当時のマシンのスペックによって4つの指針のバランスがとられた
1
MIPS以下 + 10Mbps Ethenet + 10台程度
Scalabilityをあきらめた
Dependabilityはあきらめていない
当時のファイルサーヴァは不安定だった
1日1回くらいはダウンする
そういう不安定な場合でも動き続けることが大事
何故成功したのか
どのように
ファイルシステムが使われるのかを分析して技術的に詰めていった
現在のマシンのスペックを考えて作り直した方がいいけれどそのまんま
なぜそのままなのか
世の中は良い技術だけが残るわけではない
互換性とか社会的な原因
Sunがつぶれても残り続ける
携帯電話とか新しい
プロトコルでは互換性を気にしなくて良いので
新しいものが使われているのだけど
MicrosftのSMBもずーっと引きずっている
そんなことをいったら
x86の
アーキテクチャも電卓用にべストな設計
64bitの時代になっても未だに使っている
今でも使われているからといって
その技術がベストとはいえない
ベストでないことが多い
出来たときはベストだけど今では違う
それがわかっていても使われ続ける
みんなが使っているからといって技術的にベストだと信じてしまうのは恥ずかしい
設計したときにどうだったのか見直すことは大事
Performance bottleneck
ネットワーク速度ではない
どちらかというとサーヴァ側のマシンのCPU速度
これは今でもそう
TCP/IPは重い
100Mbpsは今でもそんなに早くはないが、
1GHzのCPUとの組み合わせで
パケットサイズが小さいと実際の速度は20Mbpsくらいになってしまうのがざら
システムの設計としてはできるだけネットワーク通信をしないことが
1Gbpsでも大切
どんなに早いネットワークを入れてもPCの方の性能を上げないと
せっかく早い
光ファイバーを入れても意味がない
そこで登場する技術
File cache
手許のマシンがネットワーク越しにファイルを読むと
それが手許のマシンに読み込まれる
次に同じファイルにアクセスするときにはすでにローカルメモリにあるので
ネットワーク通信をしなくて良い
問題はreadonlyのファイルをキャッシュしておくぶんには何の問題もない
ファイルが書き換わると古いデータのキャッシュは全部無効にして
それ以上使われないようにする
その管理は非常に難しい
Write-invalidate
書き込まれたら他のマシン上のキャッシュは破棄
破棄しろと命令を送りつける
Write-update
書き込まれたら他のマシン上のキャッシュも更新
新しい内容を送りつける
Migration
一時的に特定のマシンだけに書き込み許す
同時に書き込みが起こった時の混乱を避ける
いろんなのがある
一般的にはWrite-invalidateが良いと言われている
Write-updateだとネットワークの流量が増えてしまう
サーヴァのクラッシュを考えなければWrite-invalidateがよい
Write-invalidateだと
どのクライアントにキャッシュがあるかサーヴァか管理しなければならない
ブロードキャストでは、届いたかどうかわからない
キャッシュを持ったクライアントマシンがダウンしている可能性もある
そのときにファイルがが書き換わる
その通知は届かない
僕が来週休講だと言って、全員来ていればよい
たまたま休んでいる人がいた
文字通りダウンしていた
その人には伝わらない
掲示を出すとかしても見ない
完璧を期すには
一人一人の名簿をもって個別に電話をするくらいはしないといけない
今はサーヴァがクラッシュすることはまれ
NFSでは弱い一貫性制御の採用
片方のマシンでソースを書いて別のマシンで
コンパイルするときに困るくらいで
実用上そんなに困らない しばらく待てば良い
古くなったかどうかはクライアントが自分で判断
完璧な一貫性は保たない
クライアントは一定時間ごとに機械的にキャッシュを破棄
もうちょっとマシな実装だとディレクトリキャッシュを取って確認
Writeの場合も30秒に一回サーヴァに送るとかする
後は細かい話だけれど
毎回のアクセスにどのファイルのどの何バイト目から何バイトを読むとか送る
毎回ファイル名を送るのは、サーヴァにデータを残したくないから
一定時間内に応答がなければクライアントはリクエストを再送
ファイルロックはなし
ファイルシステムとは別にロックをするメカニズムをつける
NFSはすぱっと割り切っている
同じファイルが
複数のユーザに同時に使われることはそんなにない
Performance
プロトコルに由来する問題
サーヴァの負荷が高い
サーヴァは誰がキャッシュを持っているかわからない
各クライアントは一定時間経ったらキャッシュを捨てて毎回サーヴァにアクセスする
賞味期限が切れていなくても万が一腐ってたら捨てて毎回新しいものを買ってくる
つまりScalabilityがない
4台程度のサーヴァで100台のクライアントをホストすると不安定（90年代末）
80年代のデザインで10台のマシンが不安定な環境でも動くように、
というデザインだからうまくいかない
対応策
Andrew File System (AFS)
キャンパスにある全部のマシンがアクセスしても耐えられる
という壮大な企画
この頃になるとサーヴァはそんなに落ちない 信頼性がある
サーヴァは誰がキャッシュをもっているか覚えている
キャッシュをメモリではなくローカルディスクに置く
こういうことをしてサーヴァへの負荷を下げる
細かい話をしていないのであんまりよくないかもしれないが
Scalabilityを上げるためにConsistencyは悪くなった
サーヴァがクラッシュしたときの復旧も大変
Scalabilityは上がったが失っているものも多い
普及していない
今はScalabilityはすごく重要な問題
Webシステムもファイルサーヴァと同じ問題を抱えている
AFSでも1000台程度のクライアント
しかし人気のあるサイトだとすぐにユーザ数が10000とかになる
動画を1000とか10000のユーザがアクセスするとScalabilityの性能がよくないと耐え切れない
HTTPにはそもそもまともなキャッシュ機能がない
P2PはScalabilityを上げたので注目されている
しかしConsistencyとDepandabilityは犠牲になった
