Скачать презентацию Distributed systems Fall 2012 G 22 3033 -001 Скачать презентацию Distributed systems Fall 2012 G 22 3033 -001

231f8afc006be69340361649c0e22eb8.ppt

  • Количество слайдов: 40

Distributed systems [Fall 2012] G 22. 3033 -001 Lec 1: Course Introduction & Lab Distributed systems [Fall 2012] G 22. 3033 -001 Lec 1: Course Introduction & Lab Intro

Know your staff • Instructor: Prof. Jinyang Li (me) – jinyang@cs. nyu. edu – Know your staff • Instructor: Prof. Jinyang Li (me) – [email protected] nyu. edu – Office Hour: Thu 4 -5 pm (715 Bway Rm 708) • Instructional Assistant: Russell Power – [email protected] nyu. edu – Office Hour: TBA (715 Bway Rm 707)

Important addresses • Class URL: http: //www. news. cs. nyu. edu/~jinyang/fa 12 – Check Important addresses • Class URL: http: //www. news. cs. nyu. edu/~jinyang/fa 12 – Check regularly for schedule+reading questions • We’ll use Piazza. com for class discussion

This class will teach … you • Basic tools of distributed systems – Abstractions, This class will teach … you • Basic tools of distributed systems – Abstractions, algorithms, implementation techniques – System designs that worked • Build a real system! – Synthesize ideas from many areas to build working systems

Who should take this class? • Pre-requisite: – Undergrad systems class (OS, compiler etc. Who should take this class? • Pre-requisite: – Undergrad systems class (OS, compiler etc. ) – Programming experience in C or C++ • Fast paced and a lot of work – Labs due every two weeks – Final project – Midterm + Final – 2~3 readings every week + reading question • If you are not sure, do Lab 1 asap.

Course readings • No official textbook • Lectures are based on research papers – Course readings • No official textbook • Lectures are based on research papers – Check webpage for schedules • Useful reference books – Principles of Computer System Design. (Saltzer and Kaashoek) – Distributed Systems (Tanenbaum and Steen) – Advanced Programming in the UNIX environment (Stevens) – UNIX Network Programming (Stevens)

Course structure • Lectures – Read assigned papers before class – Submit your answer Course structure • Lectures – Read assigned papers before class – Submit your answer to assigned reading question on Piazza – Participate in class discussion • 5 programming Labs – Build a networked file system with detailed guidance! • Project (or 2 additional labs)

How are you evaluated? • Class participation 5% – Participate in discussions, hand in How are you evaluated? • Class participation 5% – Participate in discussions, hand in answers • Labs 40% • Project 25% • Quizzes 30% – mid-term and final (90 minutes each)

Questions? Questions?

What are distributed systems? Multiple hosts A local or wide area network Hosts cooperate What are distributed systems? Multiple hosts A local or wide area network Hosts cooperate to provide a unified service • Examples?

Why distributed systems? for ease-of-use • Handle geographic separation • Provide users (or applications) Why distributed systems? for ease-of-use • Handle geographic separation • Provide users (or applications) with location transparency: – Web: access information with a few “clicks” – Network file system: access files on remote servers as if they are on a local disk, share files among multiple computers

Why distributed systems? for availability • Build a reliable system out of unreliable parts Why distributed systems? for availability • Build a reliable system out of unreliable parts – Hardware can fail: power outage, disk failures, memory corruption, network switch failures… – Software can fail: bugs, mis-configuration, upgrade … – To achieve 0. 999999 availability, replicate data/computation on many hosts with automatic failover

Why distributed systems? for scalable capacity • Aggregate resources of many computers – CPU: Why distributed systems? for scalable capacity • Aggregate resources of many computers – CPU: Dryad, Map. Reduce, Grid computing – Bandwidth: Akamai CDN, Bit. Torrent – Disk: Frangipani, Google file system

Why distributed systems? for modular functionality • Only need to build a service to Why distributed systems? for modular functionality • Only need to build a service to accomplish a single task well. – Authentication server – Backup server. • Compose multiple simple services to achieve sophisticated functionality – Our programming lab: file service = lock service + block service

The downside • Much more complex A distributed system is a system in which The downside • Much more complex A distributed system is a system in which I can’t do my work because some computer that I’ve never even heard of has failed. ” -- Leslie Lamport

Topics in this course Topics in this course

Case Study: Distributed file system $ ls /dfs f 1 f 2 $ cat Case Study: Distributed file system $ ls /dfs f 1 f 2 $ cat f 2 test Server(s) $ echo “test” > f 2 $ ls /dfs f 1 f 2 Client 1 Client 2 Client 3 A distributed file system provides: • location transparent file accesses • sharing among multiple clients

A simple distributed FS design Client 1 Client 2 Client 3 • A single A simple distributed FS design Client 1 Client 2 Client 3 • A single server stores all data and handles clients’ FS requests.

Topic: System Design • What is the right interface? – possible interfaces of a Topic: System Design • What is the right interface? – possible interfaces of a storage system • Disk • File system • Database • Run over local cluster or wide area? • Scale of operation? – Must the system handle a large user population? – Store peta-bytes of data?

Topic: Implementation • Build it out of single machine components. – How do clients/server Topic: Implementation • Build it out of single machine components. – How do clients/server communicate? – Hide network communication from app logic • RPC, RMI, Zero. MQ • Build it out of other distributed software/services. – Run on top of Mongo. DB, Amazon’s S 3?

Topic: performance • Optimize for single server performance: – serve multiple clients concurrently – Topic: performance • Optimize for single server performance: – serve multiple clients concurrently – Challenges of multithreaded server • Race, deadlock etc. • Scale out using many machines – Ideal scenario: Nx servers Nx performance – How to distribute a file server’s load? • Split by user? Split by file name? – Load imbalance destroy perfect scalability

Topic: Fault Tolerance • How to keep the system running when some file server Topic: Fault Tolerance • How to keep the system running when some file server is down? – Replicate data at multiple servers • How to update replicated data? • How to fail-over among replicas? • How to incorporate recovered machine correctly?

Topic: Consistency • Contract with apps/users about meaning of operations. Difficult due to: – Topic: Consistency • Contract with apps/users about meaning of operations. Difficult due to: – Partial failure, replication/caching, concurrency • Problem: keep 2 replicas “identical” – If one is down, it will miss updates – If net is broken, both might process different updates • Problem: atomicity of multiple operations – When Alice moves file f 1 from /d 1 to /d 2, do other clients see intermediate results?

Topic: Security • Adversary can manipulate messages – How to authenticate? • Adversary may Topic: Security • Adversary can manipulate messages – How to authenticate? • Adversary may compromise machines – Can the FS remain correct despite a few compromised nodes? – How to audit for past compromises? • Which parts of the system to trust? – System admins? Physical hardware? OS? Your software?

Intro to programming Lab: Yet Another File System (yfs) Intro to programming Lab: Yet Another File System (yfs)

YFS is inspired by Frangipani • Frangipani goals: – Aggregate many disks from many YFS is inspired by Frangipani • Frangipani goals: – Aggregate many disks from many servers – Incrementally scalable – Automatic load balancing – Tolerates and recovers from node, network, disk failures

Frangipani Design Frangipani File server lock server Petal virtual disk Client machines server machines Frangipani Design Frangipani File server lock server Petal virtual disk Client machines server machines

Frangipani Design Frangipani File server • serve file system requests • use Petal to Frangipani Design Frangipani File server • serve file system requests • use Petal to store data • incrementally scalable with more servers • ensure consistent updates by multiple servers • replicated for fault tolerance lock server Petal virtual disk • aggregate disks into one big virtual disk • interface: put(addr, data), get(addr) • replicated for fault tolerance • Incrementally scalable with more servers

Frangipani security • Simple security model: – Runs as a cluster file system – Frangipani security • Simple security model: – Runs as a cluster file system – All machines and software trusted!

Frangipani server implements FS logic • Application program: creat(“/d 1/f 1”, 0777) • Frangipani Frangipani server implements FS logic • Application program: creat(“/d 1/f 1”, 0777) • Frangipani server: 1. 2. 3. 4. 5. GET root directory’s data from Petal Find inode # or Petal address for dir “/d 1” GET “/d 1”s data from Petal Find inode # or Petal address of “f 1” in “/d 1” If not exists alloc a new block for “f 1” from Petal add “f 1” to “/d 1”’s data, PUT modified “/d 1” to Petal

time Concurrent accesses cause inconsistency App: creat(“/d 1/f 1”, 0777) App: creat(“/d 1/f 2”, time Concurrent accesses cause inconsistency App: creat(“/d 1/f 1”, 0777) App: creat(“/d 1/f 2”, 0777) Server S 1: Server S 2: … GET “/d 1” Find file “f 1” in “/d 1” If not exists … PUT modified “/d 1” … GET “/d 1” Find file “f 2” in “/d 1” If not exists … PUT modified “/d 1” What is the final result of “/d 1”? What should it be?

time Solution: use a lock service to synchronize access App: creat(“/d 1/f 1”, 0777) time Solution: use a lock service to synchronize access App: creat(“/d 1/f 1”, 0777) App: creat(“/d 1/f 2”, 0777) Server S 1: Server S 2: . . LOCK(“/d 1”) GET “/d 1” Find file “f 1” in “/d 1” If not exists … PUT modified “/d 1” UNLOCK(“/d 1”) … LOCK(“/d 1”) GET “/d 1”

Putting it together create (“/d 1/f 1”) Frangipani File server 1. LOCK “/d 1” Putting it together create (“/d 1/f 1”) Frangipani File server 1. LOCK “/d 1” 4. UNLOCK “/d 1” 2. GET “/d 1” 3. PUT “/d 1” Petal lock virtual disk server

NFS (or AFS) architecture NFS client NFS server • Simple clients – Relay FS NFS (or AFS) architecture NFS client NFS server • Simple clients – Relay FS calls to the server – LOOKUP, CREATE, REMOVE, READ, WRITE … • NFS server implements FS functions

NFS messages for reading a file NFS messages for reading a file

Why use file handles in NSF msg, not file names? • What file does Why use file handles in NSF msg, not file names? • What file does client 1 read? – Local UNIX fs: client 1 reads dir 2/f – NFS using filenames: client 1 reads dir 1/f – NFS using file handles: client 1 reads dir 2/f • File handles refer to actual file object, not names

Frangipani vs. NFS Frangipani NFS Scale storage Add Petal nodes Buy more disks Scale Frangipani vs. NFS Frangipani NFS Scale storage Add Petal nodes Buy more disks Scale serving capacity Add Frangipani servers Manually partition FS namespace among multiple servers Fault tolerance Data is replicated Use RAID On multiple Petal Nodes

YFS: simplified Frangipani yfs server App User-level kernel Single extent server to store data YFS: simplified Frangipani yfs server App User-level kernel Single extent server to store data Extent server syscall FUSE lock server Communication using remote procedure calls (RPC)

Lab schedule • L 1: lock server – Programming w/ threads – RPC semantics Lab schedule • L 1: lock server – Programming w/ threads – RPC semantics • • • L 2: basic file server L 3: Locking L 4: Caching locks L 5: Caching extend server+consistency L 6: Paxos L 7: Replicated lock server

L 1: lock server • Lock service consists of: – Lock server: grant a L 1: lock server • Lock service consists of: – Lock server: grant a lock to clients, one at a time – Lock client: talk to server to acquire/release locks • Correctness: – At most one lock is granted to any client • Additional Requirement: – acquire() at client does not return until lock is granted