D ISTRIBUTED S YSTEMS [COMP9243] B UILDING A D ISTRIBUTED S YSTEM - PowerPoint PPT Presentation

D ISTRIBUTED S YSTEMS [COMP9243] B UILDING A D ISTRIBUTED S YSTEM Lecture 3: System Architecture Two questions: Slide 1 Slide 3 ➀ System Architectures ➀ Where to place the hardware? ➜ Client-server (and multi-tier) ➁ Where to place the software? ➜ Peer to peer ➜ Hybrid architectures ➁ Processes & Server Architecture System Architecture: ➜ identifying hardware and software elements ➜ placement of machines ➜ placement of software on machines ➜ communication patterns Where to place?: A RCHITECTURE ➜ processing capacity, load balancing Slide 2 Slide 4 ➜ communication capacity ➜ locality Mapping of services to servers: ➜ Partitioning ➜ Replication ➜ Caching B UILDING A D ISTRIBUTED S YSTEM 1 A RCHITECTURE I SSUES 2

C LIENT -S ERVER A RCHITECTURE I SSUES Request Choosing the right architecture involves: Client Server Reply • Splitting of functionality Slide 5 Slide 7 • Structuring the application Kernel Kernel • Reducing complexity Client-Server from another perspective: Wait for result Client Request Reply A RCHITECTURAL P ATTERNS Slide 6 Slide 8 Server Provide service Time How scalable is this? C LIENT -S ERVER 3 C LIENT -S ERVER 4

Example client-server code in C: Example client-server code in Erlang: % Client code using the increment server client (Server) -> client(void) { Server ! {self (), 10}, struct sockaddr_in cin; receive char buffer[bufsize]; {From, Reply} -> io:format ("Result: ~w~n", [Reply]) int sd; end. ... // set server address in cin Slide 9 Slide 11 % Server loop for increment server loop () -> sd = socket(AF_INET,SOCK_STREAM,0); receive connect(sd,(void *)&cin,sizeof(cin)); {From, Msg} -> From ! {self (), Msg + 1}, send(sd,buffer,strlen(buffer),0); loop (); recv(sd,buffer,bufsize,0); stop -> true end. close (sd); % Initiate the server } start_server() -> spawn (fun () -> loop () end). server(void) { struct sockaddr_in cin, sin; Splitting Functionality: int sd, sd_client; ... // set server address in sin Client machine sd = socket(AF_INET,SOCK_STREAM,0); User interface User interface User interface User interface User interface bind(sd,(struct sockaddr *)&sin,sizeof(sin)); Application Application Application Database listen(sd, queuesize); while (true) { User interface Slide 10 Slide 12 sd_client = accept(sd,(struct sockaddr *)&cin,&addrlen)); Application Application Application recv(sd_client,buffer,sizeof(buffer),0); Database Database Database Database Database DoService(buffer); Server machine send(sd_client,buffer,strlen(buffer),0); (a) (b) (c) (d) (e) close (sd_client); } Which is the best approach? close (sd); } C LIENT -S ERVER 5 V ERTICAL D ISTRIBUTION (M ULTI - TIER ) 6

V ERTICAL D ISTRIBUTION (M ULTI - TIER ) H ORIZONTAL D ISTRIBUTION Front end handling Request Request App. Dbase Replicated Web servers each incoming Client Server Server requests containing the same Web pages Reply Reply Requests Disks handled in Kernel Kernel Kernel round-robin fashion Slide 13 Slide 15 Three ’layers’ of functionality: Internet Internet • User interface • Processing/Application logic • Data ➜ Logically equivalent components replicated on different machines ➜ Logically different components on different machines How scalable is this? Leads to Service-Oriented architectures (e.g. microservices). Vertical Distribution from another perspective: Note: Scaling Up vs Scaling Out? Wait for result User interface (presentation) Horizontal and Vertical Distribution not the same as Horizontal Request and Vertical Scaling . Return operation result Wait for data Application Vertical Scaling: Scaling UP Increasing the resources of a Slide 14 server Slide 16 single machine Request data Return data Horizontal Scaling: Scaling OUT Adding more machines. Database server Time Horizontal and Vertical Distribution are both examples of this. How scalable is this? H ORIZONTAL D ISTRIBUTION 7 S ERVICE O RIENTED A RCHITECTURE (SOA) 8

P EER TO P EER S ERVICE O RIENTED A RCHITECTURE (SOA) request Peer Stock Service reply query_stock Peer buy sell Kernel Kernel XML−RPC request reply request Bank Service balance Client tansfer reply HTTP HTTP Peer Slide 17 Slide 19 request Peer XML−RPC reply Kernel Kernel Peer SOAP HTTP Auction Service search get_auction manage_auction Kernel bid Photo Service search add_photo ➜ All processes have client and server roles: servent delete_photo update_photo Why is this special? P EER TO P EER AND O VERLAY N ETWORKS How do peers keep track of all other peers? M ICROSERVICES ➜ static structure: you already know ➜ dynamic structure: Overlay Network ’Extreme’ vertical distribution ➀ structured ➜ split application logic into many (reusable) services ➁ unstructured Slide 18 Slide 20 ➜ services limited in scope: single-purpose, do one thing really Overlay Network: well ➜ Application-specific network ➜ orchestrate execution of services ➜ Addressing ➜ Routing ➜ Specialised features (e.g., encryption, multicast, etc.) P EER TO P EER 9 P EER TO P EER AND O VERLAY N ETWORKS 10