第二回 Distibuted Systems 読書会

2013/03/01

資料作成 : 大塚健司kok.fdcm@gmail.com

03/04/13

今日の目標

• distributed system 上での いろんなprocess を見てみましょう。– thread, process で high-performance を出す仕組み。

• C/S system でのサーバの問題点に注目

Chapter 3 の冒頭部分

3.1 THREADS

• OSから標準で提供されている Processよりも高い performance を得るための区分。

• Program を実行するために、 OS は virtual processor を作る。

• Process table– OS が Virtual processors を管理するためのもの– CPU register value, memory maps, etc を格納

• Process– 実行中 Program– Process 同士は互いに依存することはなく、また干渉しない。

•Transparent(高コスト ) - 実現するには多くの場合 H/Wのサポートが必要。

• CPU の切り替え、MMU(memory management unit) の変更、 アドレス変換テーブルの変更が必要

• Thread– 他の thread に依存しないように program を実行する。

– 互いの干渉を回避するような機構はない。•Thread-safe はプログラマの配慮• 干渉しない program は作り手にすべて委ねられる。

• Multithreaded process in Non-distributed system– Ex. Spread Sheet

• バックアップ、描画、計算、入力受付を別スレッドにするとよい。

– もしも Single-Thread の Spread Sheet があったら・・・» ひとつのセルの値が変わったら、すべてのセルの再計算が行われるが、その処理が終わるまで描画・入力ができない。

– Ex. Word Processor• スペルチェック、入力待ちうけ、ドキュメントレイアウトの処理を別スレッドにするとよい。

• Ex. Multiprocess– Process の切替では、一度カーネルモードになった後にユーザモードになる必要がある。

• 共有メモリ、メモリマップなどをごっそり書き換える

thread の切り替えは user mode のまま行えるため、multithread

なら performance が向上する。

• Thread Implementation (2 approaches)– User mode で実行される thread library を作る

• Thread の作成・削除は user mode で行われる。– threadのコントロールに必要な部分だけを扱えばよいので低コスト (メモリ全体の書き換えなどは不要 )

• Thread の切替も簡単– メモリマップの変更などは不要

• 欠点 : Process が止まったらすべてが止まる– Light-Weight Processes

• Kernel space で threadをコントロールする process– Kernel mode になっても プロセス全体は止まらない

• LWPそのものの生成・削除が高コスト、 kernel で行う

3.1.2 Threads in Distributed Systems

• Thread を使うと、 process 全体をとめなくても System call できるようになる。

• Multithreaded Clients– Transparency を高くするためには、 message の送受信にかかる時間を減らす必要がある。

– http get request • TCP接続をした後でデータを一気に読み込み、表示する。

• 読み込みながら表示している。• Server も レプリカを同一アドレスで複数設置して並列処理。

• Multithreaded Servers– multithreading は主に server side で用いられる。

– File server• Dispatcher + worker thread• Dispatcher が待ち状態の worker thread に処理を振り分ける。

• もしも single thread の file server …があったら– メインループは Request を受け取ったら、 response を完遂するまでなにも受け付けない。

– 結果、限られた request しか処理されない。• Single thread の解決策 : Finite-state machine

• message を処理する server を起動する。– Server は request を受け取り、キャッシュで処理できればキャッシュを利用し、ディスクを読む必要があればディスクへメッセージを送る。

– Server はそれぞれの request について状態を保存しておき、 request が到着したら状態に応じて処理を変える。

• 新しい request なら処理開始、 disk からの message ならresponse 返却。

3.2 VIRTUALIZATION

• Virtualization– もともとは、 legacy system を新しい machine の上で動かすことを想定。 (1970年代 )

• メインフレームの時代からあった手法。– 現代では、次々と新しくなる H/W でも動かすために

virtualization 利用できる。• H/W, low-level software の interface 変更にも対応できる。

– 複数の server を動かす場合 : H/W などに違いがあっ ても virtualization によって、同じ手順で管理ができ

る。– 簡単にコピーできる。

コンピュータの提供する 4 types of interfaces

• どの PG からも実行できる H/W S/W 間の Machine Instructions•Kernel 等の特別な PG から実行できる H/W S/W 間の Machine Instructions•OS の System Call•API (System Call を隠蔽する )

Virtualization は、これらの interfaceを真似ることで実現される。

3.2.2 VM Architecture

Virtualization は 2つの方法で実装される。

•Run time application – Windows application をUnix で動かす

– Process virtual machine•H/W の偽物 interface (convert instruction set)

–この interfaceは同時に別の PGにも提供される

–複数の異なる OSが、同一 platformで独立して同時に動作する。

– Virtual Machine Monitor (VMM)

Fig 3-7

• VMM• 信頼性 (reliability)と安全性 (security)の点で重要度が増してくる。

• 完全なアプリケーションとその環境の分離ができれば、セキュリティアタック含むエラーによって、ベースの OSが影響を受けることはなくなる。

• H/Wと S/Wの分離、別マシンへの環境の完全な移行が可能。 (portability)

3.3 CLIENTS

• C/S System における CLIENTについて詳しく見てみる。

3.3.1 Network User Interfaces

• Client の Major Task– Remote Server との通信方法の提供

• サーバとの通信方法は 2種類– Client Service が Server Service と通信

• Remote Serverと同期する PDA

– Client が Server Service を利用する (Clientは何も持たない )

• Thin Client• X Window (今はあまり使われない ?)

Fig 3-8

注 ) 各レイヤははっきりと

分けられるものではない。

PDA等 THINC等

Ex. X Window System

• X system– X kernel (X system の core part)

• Capture mouse and keyboard events

– Xlib for application– Xlib and X kernel communicate in X protocol

Ex. X Window System

• Xlib– Send request to the X kernel for creating or killing a

window, setting colors, cursor, … 表示系の指示• X kernel

– Keyboard, mouse のイベント (入力 ) を Xlib に送信– Serve display commands to Xlib.

• Xlib uses X kernel’s displaying service– Server is X kernel, Client is Xlib.

• Problem– Application と X system の通信が絡み合っている (完全に分離されていない )ことが多い

• WANを通した長期間のオペレーションでパフォーマンス低下

Fig 3-9

• THINC– Application からの表示リクエストは、低レベルのコマンドに変換される。

– THINC 自身が常に update コマンドを送信し続けることで、 Application の Display 処理をなくした。 (Xlib のように application 側で実装する必要がない。 )

• Compound Documents–ファイル (テキスト、画像、 ...)の取り扱い– UI: 別の Application が Compound Document の別の部分を使用しているという事実を隠す

• ユーザには、一つの Fileとして問題なく扱えているように見せる。

• 別 Applicationの変更によって不整合が起こる場合は適切な対応をする (Application にメッセージを出すなど )。

• PGは複雑になる。• Ex. あるエディタで変更 ->使用中の別のエディタでも表示が変更される。

3.3.2 Client-Side Software for Distribution Transparency

• Client Software は distributionの透過性を実現するようにできている。

• 理想的には、透過的にアプリケーションが作られるべきだが、多くの場合透過的ではなくなる。 => Chapter 6 で例を見る。

• Server と通信中なら ...– server の場所が変わったら、 server から

client に通知する。 client の S/W は server の場所が変わったことを user に悟られないように振舞う。

Fig 3-10

• Repliation Transparency• 透過性は Client-Side で実装• Replication request を各 Server に送信するが、 User には request が 1つのように見せる。

• Failure Transparency– Client Middleware によって Client Server 間の通信エラーは隠蔽される。• 1 度失敗したらももう一度 Server に Access する。• 何度か失敗したら別の Server に Access する。• Web Browser で、 Server に繋がらない場合に、前回の Cached Data を表示する。

• Concurrency Transparency–特別な中間サーバによってコントロール• トランザクションモニタ

– Client S/W のサポートはあまり必要としない• Persistency Transparency– Server で実装されることが多い。

3.4 Servers

• A Server is a Process– 複数の Client に代わって処理をする。–各 Server は同じやり方で構成される。• Client からの request を待ち受ける。• Request を処理する。• 次の request を待ち受ける。

3.4.1 General Design Issues

• Iterative Server– Server 自身が request を処理し、 response を返す。

• Concurrent Server– Request の処理は別の Thread/Processが行う。

– Multi Threaded Server• Request 毎に process を作成して処理する。 (多

くの UNIX でのパターン。 )

• Where clients contact a server?– Client sends request to an end point (specific port).– Well-known port は Internet Assigned Numbers

Authority によって決定されている。• Ex. Service without preassigned end point– Time-of-day Service

• Server Process の End Point は同的に決定されるため一定でない。

• 待ち受け専用の daemon を特定の port で起動。• Request があったら、 Server Process へ Access

– Inetd

• Whether and how a server can be interrupted?– Uploading a big file to FPT server

• User が不正ファイルだと気付いた場合、 User は Client Soft を Close -> Server は connection の切断を検知して操作を中断 (なかったことにする )。

– Out-of-band data (帯域外データ ): Client から送られて きた data よりも優先して Server で処理されるデー

タ• Server で Client から送信される out-of-band data を別 port で監視する。

• 通常 data と out-of-bound data を同じ port で一緒に扱う。• 使われ方 : out-of-band data として Urgent data/signal が

送信されたらその後の通信を abort する。

• Is whether or not the server stateless?• Stateless server

– not keep information of the state of the clients– Can change own state without informing any client– Ex. Webserver

• Request の処理が終わると、 server は client との一切の関係を捨てる。

• Server 内の files は client に通知することなく変更可能。– 多くの場合、Web Server の Log のように Clients’ information

を保持するが、そういったものは仮に消失しても Service には影響がない。

• Soft-state approach– Server maintains behalf of the client for limited time– Ex. Update server

• Stateful server– Maintains persistent information on its clients– Ex. File Server allowing clients to keep a local copy

• Needs to recover entire state after crashing

• session state と permanent state の区別– Session state

• single user による処理結果であり、 しばらくの間保持されるもの。• よく変更される。• 消失した場合は、 Client から再接続。

– Permanent state• database の顧客データなど。• Issue: durability of the server

• 他の方法• Cookie• Server では保存しない。 Client は保存するだけでそれ自体使わない。

3.4.2 Server Clusters (LAN with high bandwidth and low latency)

• General organization– server cluster• network で結合された machine の集合体• 各 machine が 1 つ以上の Server を実行している。• General pattern

• 構成– 2-tier, 3-tier などさまざま。–それぞれのmachineが local storage を持つ場合もある。

• Cluster 内のある machine が idle 状態で 、別の machine が busy 状態のとき

– switch が動的に Migration を行って資産を活用

• Fig 3.4: Example of Access Transparency– Switch は request を server に渡すが、 header 情報は Switch のままにして、再

び Client が Switch に access するようにしている。

36

• Distributed Servers– Use several access points

• DNS: DNS を探しまわればいい。ただし ある access point にaccess できなくなることがある。 (not static)

• MIPv6– A mobile’s home network address: HoA

» 通信時に使用する。– 特殊 router: Home Agent

» Mobile node が遠くに行った場合に、mobile node へのaccess を処理する。

– Temporary Care of Address: CoA» Mobile node が外の network に入った時に通知される

address» Home agent に通知される。» 通信時には使用しない。

– A single unique contact address» Server Cluster の address(不変 )» 外部との通信に使用する。

• ルート最適化 (route optimization)– 異なる clients が一つの server を介して通信をしているように見せかける。

3.4.3 Managing Server Clusters

• Common Approach– 1 つの computer に対して行っていたことを

複数の computer に対して行う。– 管理用の interface を通して管理を行う。– ただし computer 1000 台それぞれが 0.1% の

確率で故障すると仮定すると、すべてのcomputer が正常に動く確率は 36%。

• Massive system を扱う系統的な方法はない。

• Cluster management はまだ始まったばかり。

• Ex. PlanetLab–複数の企業がお金を出して Clusterを構築する。

– 1-tier server cluster– 1 つの node はそれ自体 cluster になれる。–それぞれの vserver は独立して動く。

VMM

• Slice– A set of vservers (virtual server cluster)

• PlanetLab の問題点– 各 Node は異なる組織に所属する。各組織がそれぞれどの nodeのどの applicationの実行権限、 access権限を持つのか適切に設定する必要がある。

– 様々な monitoring tool があるが、どれも特定のH/W, S/W の組み合わせでしか動作が保障されていない、また 1つの組織で使うことが前提になっている。

– 同じ node の異なる slice 上で動く application が干渉してはならない。

3.5 Code Migration

• 概要– Process が、読み込みの多い machine から読

み込みの少ない machine に移れば system 全体の performance が向上する。

– Flexibility(柔軟性 )

Client は最初の時点で program を setup しておく必要はない。

必要になった時にある場所からdownload して server と通信を行う。

必要がなくなったら program を捨てるようにしておけば、 通

信プロトコルの変更なども柔軟に行える。

• Process– Code segment

• 実行されているプログラムの命令セット– Resource segment

• ファイル、プリンタなど外部リソースへの参照– Execution segment

• プロセスの状態、変数の値、スタックなど• Weak mobility

– Code segment だけを移す。– Java applet はブラウザで読み込まれブラウザのアドレ

ス空間内で完結。ただし実行環境の resource を守る ための security が必要。

• Strong mobility– Code segment, execution segment を移す。– 一旦止めて別環境へコピーした後再開する。– 実装は難しい。

• Sender-initiated– Upload のように、送信側から開始。– Sender を登録しておくなど、 security 対策が必要• 変なものを upload されると困る。

• Receiver-initiated– Java Applet のように、受信側から要求を出して開始する。

– Sender-initialized migration より簡単。• Clone process– Remote machine が元の process を copy して実行。

3.5.2 Migration and Local Resources

• Resource segment は特別に注意が必要– 変更されないままの状態で移して動かすのが難しい。

• 参照している TCP port は別machineで同じように参照しても通信を継続できない。

• URL指定でファイルを参照している場合は弊害なし。そのまま移しても問題ない。

• 3 types of process-to-resource binding– Binding by identifier

• URLなど絶対固定のものを PGで使用。– Binding by value

• ライブラリなどの内部は多少違っても、同じ値さえ出せれば同じように動く。

– Binding by type• モニタ、プリンタといった、型で指定して PG内で使っている。

• Migration では、 resourceへの参照を変える必要が出てくるが、 binding に影響を与えてはならない。

• リソースの種類– Unattached resources

• 簡単に移せる• 移される data は、 PGからしか使われていない。

– Fastened resources• 移すのは高コスト• Local DB や Web Site。ただ移すだけでは実行不可能かもしれない。

– Fixed resources• 移せない• ポートなど

3.5.3 Migration in Heterogeneous Systems

• VM の migration–問題• 完全な memory の migration• Local resources への参照

– 3つの方法• メモリページを新しいマシンに写し、migration中が終わった後でもう一度新しいマシンに移す。• VMを停止して移し、再開する。

– ダウンタイムに注意。• 新しいリクエストがきたら新しいマシンで対応する。– 時間がかかる。