Upload
kenji-ohtsuka
View
459
Download
4
Embed Size (px)
DESCRIPTION
アップロードしたら見事にデザインが崩れました。 http://www.amazon.co.jp/gp/product/0132392275/ref=as_li_ss_tl?ie=UTF8&camp=247&creative=7399&creativeASIN=0132392275&linkCode=as2&tag=mezurashinews-22
Citation preview
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を停止して移し、再開する。
– ダウンタイムに注意。• 新しいリクエストがきたら新しいマシンで対応する。– 時間がかかる。