1. Distributed Systems Architecure

2. Architectures Architectural Styles Software Architectures Architectures versus Middleware Self-management in distributed Systems

3. 2.1 Architecture Style (1) 분산 시스템의 중요 중요 시스템 구성 형태 –Layered architectures –Object-based architectures –Data-centered architectures –Event-based architectures

4. 2.1 Architecture Style (2) Figure 2-1. The (a) layered architectural style is used for client-server system

5. 2.1 Architecture Style (3) Figure 2-1. (b) The object-based architectural style for distributed object systems

6. 2.1 Architecture Style (4) Figure 2-2. (a) The event-based architectural style Publish/subscribe [decoupled in space(anonymous)]

7. 2.1 Architecture Style (5) Figure 2-2. (b) The shared data-space architectural style Decoupled in space and time(asynchronous)

8. 2.2 System Architectures 2.2.1 Centralized Architectures (1) Client-Server Model –Server 서비스를 제공하는 process –Client 서비스를 이용하는 process –Client 와 Server 는 다른 machine 에 있을 수 있 음 –Client 는 request/reply 모델에 따라 서비스를 이용함

9. Figure 2-3. General interaction between a client and a server.

10. Connectionless-oriented Connection-oriented

11. 2.2.1 Centralized Architectures (2) Application Layering –The user-interface level –The processing level –The data level

12. 2.2.1 Centralized Architectures (3) Figure 2-3. General interaction between a client and a server.

13. 2.2.1 Centralized Architectures (3) Multitiered Architectures –Single-tiered dumb terminal/mainframe configuration –Two-tiered Client/Single Server configuration –UI/Process, Data –Three-tiered 각 layer 를 모두 분리 –UI/Process/Data

14. 2.2.1 Centralized Architectures (4) Figure 2-5. Alternative client-server organizations (a)–(e).

15. 2.2.1 Centralized Architectures (5) Figure 2-6. An example of a server acting as client.

16. 2.2.2 Decentralized Architectures Structured Peer-to-Peer Architectures Figure 2-7. The mapping of data items onto nodes in Chord.

17. Figure 2-8. (a) The mapping of data items onto nodes in CAN.

22. The Rise of Distributed Systems 컴퓨터 하드웨어 가격의 하락과 파워의 증 가 – 다른 산업이 생각하지 못할 정도의 비약적인 발전이 이루어짐 네트워크로 연결되는 컴퓨터의 증가 주변기기의 연결이 쉬워짐

23. 1.1 Definition (1) “A distributed system is a collection of independent computers that appear to the users of the systems as a single computer.” [Tanenbaum] “A distributed system is a collection of autonomous computers linked by a network with software designed to produce an integrated computing facility.”

24. 1.1 Definition (2) Figure 1-1. A distributed system organized as middleware. The middleware layer extends over multiple machines, and offers each application the same interface.

25. 1.2 Goals Making resources available Distribution transparency Openness Scalability

26. 1.2.1 Making resources available Easy access of users to remote resources –Geographically distributed users can be build groupware –Exchange of various types of data Voice, data, video,… Share resources with other users in an appropriate way –Limited resources can be assigned to multiple users –Cost optimization is done Security is important aspect that should be observed and implemented carefully.

27. 1.2.2vDistribution Transparency (1) Figure 1-2. Different forms of transparency in a distributed system (ISO, 1995). Types of transparency An important goal of a distributed system is to hide the fact that its processes and resources are physically distributed across multiple computes

28. Distribution Transparency (2) Distributed system may have computer systems that run different operating system URL gives no clue about the location main Web Server Distributed system in which resources can be moved without affecting how those resources cab be accessed Mobile users can continue to use their wireless laptop while moving from place to place without ever being (temporarily) disconnected. Resources may be replicated to increase availability or to improve performance. Two independent users may each have stored their files on the same file server or may be accessing the same tables in a shared database. User does not notice that a resource fail to work properly.

29. Degree of Transparency (1) Aiming at full distribution transparency may be too much: –Users may be located in different continents –Completely hiding failures of networks and nodes is impossible You cannot distinguish a slow computer from a failing one You can never be sure that a server actually performed an operation before a crash –Full transparency will cost performance, exposing distribution of the system Keeping Web cashes exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance

30. Degree of Transparency (2) Hide blindly all distribution aspects from users is not always a good idea –Content: Morning Paper –Performance: Replication of Failed Server When a data is searched, a failed server is tried several times. In order to getting rid of dealing with failed server, user can cancel the searching that server.

31. 1.2.3 Openness (1) Offers services according to standard rules that describe the syntax and semantics of those services. –Interoperability –Portability –Flexibility of configuration by different developers IDL (Interface Definition Language) is used to describe standard interfaces.

32. Openness (2) Be able to interact with services from other systems, irrespective of the underlying environment: –Systems should conform to well-defined interfaces –Systems should support portability of application –Systems should easily interoperate Achieving openness –At least make the distributed system independent from heterogeneity of the underlying environment: Hardware Platforms Languages

33. Openness (3) Separating Policy From Mechanism –Implementing openness Requires support different policies: –What level of consistency do we require for client-cached data? –Which operations do we allow downloaded code to perform? –Which QoS requirement do we adjust in the face of varying bandwidth? –What level of secrecy do we require for communication? Ideally, a distributed system provides only mechanisms: –Allow (dynamic) setting of caching policies –Support different levels of trust for mobile code –Provide adjustable QoS parameters per data stream –Offer different encryption algorithms

34. 1.2.4 Scalability (1) 분산시스템의 확장성 –In Size 사용자와 자원의 추가 –Geographically 사용자와 자원이 서로 분리되어 있음 –Administratively 다수의 독립적인 관리권한을 가진 주체들이 있음

35. 1.2.4 Scalability (2) 분산 시스템의 성장함에 따라서 집중화된 해결책은 제약을 갖 게 됨 분권화 (Decentralization) 의 단계 – 어떤 기계도 시스템 상태에 대한 정보를 소유하지 않음 – 지역적인 정보에 의거해서 결정을 하게 함 – 하나의 기계의 오류가 전체 알고리즘에 영향을 주지 않도록 함 – 전역적인 시간이 암시적으로 존재한다고 가저하지 않음

36. 1.2.4 Scalability (3) 분권화에 대해 고려해야 할 제약 사항 –Synchronization –Unreliable Connection –Multiple Administrative domains –System Security

37. 1.2.4 Scalability (3) Scaling Techniques –Hiding Communication Latency Asynchronous Communication 응답에 대한 분리된 처리기를 갖도록 함 –Problem 모든 응용 프로그램이 이 모델에 적합한 것은 아님 – 예 : 증권 시스템, 예약 시스템

40. 1.2.4 Scalability (4) Scaling Techniques –Distribution 계산을 client 에서 하도록 함 –Java Applets DNS 이름 공간을 지역화 함 WWW 와 같은 정보 시스템의 content 분산

42. 1.2.4 Scalability (5) Scaling Techniques –Caching & Replication 확장성은 종종 성능의 저하 문제에 직면하게 됨 –P2P Replicate Components Caching 은 replicate 의 특수한 형태 – 선택의 주체 –Problem Data Consistency

43. 1.2.4 Scalability (6) 분산 시스템 개발에 따른 함정 (Pitfalls) – 개발할 때 잘못된 가정 The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator

44. 1.3 Types of distribute systems Distributed Computing System Distributed Information System Distributed Pervasive Systems

45. 1.3.1 Distributed Computing System (1) Cluster Computing System

46. 1.3.1 Distributed Computing System (2) Grid Computing Systems

47. 1.3.2 Distributed Information System (1) Transaction Processing Systems – 특징 Atomic : 개별적으로 이루어짐 Consistent : 시스템의 불변성을 위반하지 않도록 함 Isolate : 병렬적인 처리 (transaction) 이 서로 간섭하지 않도록 함 Durable : 일단 제출된 처리에 의한 변화는 영구적이어야 함

48. TP(Transaction Processing) monitor 의 역 할

49. 1.3.2 Distributed Information System (1) Enterprise Application Integration

50. Internet Search Engine

51. 1.3.3 Distributed Pervasive Systems (1) 편재 시스템의 요구사항 –Embrace contextual changes –Encourage ad hoc composition –Recognize sharing as the default Home System Electronic Health Care System Sensor Network

52. 1.3.3 Distributed Pervasive Systems (2)

53. 1.3.3 Distributed Pervasive Systems (3)

54. 1.3.3 Distributed Pervasive Systems (4)