MC714: Sistemas Distribu dos Prof. Lucas Wanner Instituto de - - PowerPoint PPT Presentation

MC714: Sistemas Distribu´ ıdos

• Prof. Lucas Wanner

Instituto de Computac ¸ ˜ ao, Unicamp

Aula 1: Introduc ¸ ˜ ao e Fundamentos

MC714 – Sistemas Distrubu´ ıdos

Professor Lucas Wanner – lucas@ic.unicamp.br Hor´ ario Terc ¸as 21:00-23:00, Sala CB 06 Quintas 19:00-21:00, Sala CB 05 Website http://www.lucaswanner.com/sd Lista de Emails https://groups.google.com/d/forum/sd-2016-2 Todos os alunos matriculados foram adicionados ` a lista com seus emails da DAC. Solicite ingresso na lista caso n˜ ao tenha recebido notificac ¸ ˜ ao.

2 / 43

MC714 – Sistemas Distrubu´ ıdos

Ementa

• Sistemas Distribu´

ıdos • Comunicac ¸ ˜ ao entre processos • Sistemas de arquivos

• Servic

¸os de nomes • Coordenac ¸ ˜ ao • Replicac ¸ ˜ ao • Seguranc ¸a Bibliografia Texto principal: A. S. Tanenbaum and M. Van Steen. Distributed Systems: Principles and Paradigms. Second edition, Pearson, 2006. Link para download na p´ agina do curso. Coulouris, J. Dollimore, T. Kindberg, and G. Blair. Distributed Systems: Concepts and Design. Fifth Edition, Addison-Wesley, 2011. A.D. Kshemkalyani, M. Singhal, Distributed Computing: Principles, Algorithms, and

• Systems. Paperback edition, Cambridge University Press, 2011.

3 / 43

Programa: Primeira Parte

T´

• pico

Cap´ ıtulo Introduc ¸ ˜ ao e Fundamentos 1 Arquituras de sistemas distribu´ ıdos 2 Processos e Threads Revis˜ ao, 3 Clientes/Servidores, Virtualizac ¸ ˜ ao e N´ uvem 3 Comunicac ¸ ˜ ao: Revis˜ ao, Sockets Revis˜ ao, 4 Troca de Mensagens, Multicast 4 Disseminac ¸ ˜ ao de informac ¸ ˜ ao 4 Remote Procedure Call 4 Nomeac ¸ ˜ ao 5 Sincronizac ¸ ˜ ao de rel´

• gio

6 Rel´

• gios L´
• gicos

6 Exclus˜ ao m´ utua 6 Eleic ¸ ˜ ao de l´ ıder 6

4 / 43

Programa: Segunda Parte

T´

• pico

Cap´ ıtulo Consistˆ encia: Fundamentos, Modelos 7 Replicac ¸ ˜ ao: Gerˆ encia, Distribuic ¸ ˜ ao de conte´ udo 7 Tolerˆ ancia a falhas: Fundamentos, Comunicac ¸ ˜ ao confi´ avel 8 Commit distribu´ ıdo 8 Recuperac ¸ ˜ ao, Checkpointing 8 Arquivos: Arquitetura, Comunicac ¸ ˜ ao, Sincronizac ¸ ˜ ao 11 Arquivos: Consistencia e replicac ¸ ˜ ao, Tolerˆ ancia a falhas 11 Peer-to-Peer: Introduc ¸ ˜ ao, Distributed Hash Table (DHT) Coulouris 10 Peer-to-Peer: Chrod, Kademlia, BitTorrent Singhal 18 Web: Arquitetura, Comunicac ¸ ˜ ao, HTTP , SOAP , Caching 12 Seguranc ¸a em sistemas distribu´ ıdos 9

5 / 43

Avaliac ¸ ˜ ao

Componentes Provas: (P) Ser˜ ao aplicadas duas provas te´

• ricas, P1 e P2.

Semin´ arios: (S) Semin´ arios ser˜ ao apresentados em sala de aula. Os grupos, datas, e t´

• picos para

apresentac ¸ ˜ ao ser˜ ao definidos durante o semestre. Testes: (T) Ser˜ ao aplicados uma s´ erie de pequenos testes e exerc´ ıcios de implementac ¸ ˜

• ao. A

nota dos testes T ser´ a a m´ edia aritm´ etica entre os testes aplicados. Pol´ ıtica de atraso Cada dia em atraso implicar´ a em um desconto de 2.5/10 pontos para cada entreg´ avel.

6 / 43

Avaliac ¸ ˜ ao

M´ edia A m´ edia M da disciplina ser´ a calculada como: M = P1 ×0.3+P2 ×0.4+T ×0.2+S ×0.1 Exame Alunos com m´ edia 2.5 ≤ M < 5 poder˜ ao fazer um exame final (E). Nota final A nota final F ser´ a calculada como: F =

• min {5, M+E

2

} caso 2.5 ≤ M < 5 e o aluno tenha realizado o exame. M caso contr´ ario.

7 / 43

Avaliac ¸ ˜ ao

Datas Importantes P1: 06/10/2016 P2: 06/12/2016 Exame: 20/12/2017

8 / 43

Integridade Acadˆ emica

Pol´ ıtica de tolerˆ ancia zero Toda e qualquer violac ¸ ˜ ao de integridade acadˆ emica ser´ a punida at´ e o limite da autoridade do professor, incluindo mas n˜ ao limitado ` a nota zero na m´ edia final do curso para todos os envolvidos. Exemplos (n˜ ao exaustivos) de violac ¸ ˜

• es

Cola e pl´ agio Compartilhamento de soluc ¸ ˜

• es e c´
• digo (e.g., “dar uma olhada” no c´
• digo)

Falsificac ¸ ˜ ao de dados e resultados N˜ ao violac ¸ ˜

• es

Grupos de estudo Discuss˜ ao de estrat´ egias de implementac ¸ ˜ ao, excluindo detalhes de c´

• digo

9 / 43

Avaliac ¸ ˜ ao

Como ir bem no curso (em ordem de importˆ ancia)

1

Resolver os exerc´ ıcios de cada aula.

2

Ler os cap´ ıtulos do livro antes da aula correspondente.

3

Entregar soluc ¸ ˜

• es para testes dentro do prazo.

4

Fazer uma boa apresentac ¸ ˜ ao no semin´ ario.

5

Assistir ` as aulas.

10 / 43

Estilo das Aulas

1

Revis˜ ao breve da aula anterior.

2

Discuss˜ ao dos exerc´ ıcos da aula anterior.

3

Apresentac ¸ ˜ ao das perguntas para a aula.

4

Conte´ udo.

5

(em algumas aulas) Testes. Participac ¸ ˜ ao Participac ¸ ˜ ao ser´ a ativamente encorajada na discuss˜ ao, revis˜ ao, e apresentac ¸ ˜ ao do conte´ udo.

11 / 43

Programa

T´

• pico

Cap´ ıtulo Introduc ¸ ˜ ao e Fundamentos 1 Arquituras de sistemas distribu´ ıdos 2 Processos e Threads Revis˜ ao, 3 Clientes/Servidores, Virtualizac ¸ ˜ ao e N´ uvem 3 Comunicac ¸ ˜ ao: Revis˜ ao, Sockets Revis˜ ao, 4 Troca de Mensagens, Multicast 4 Disseminac ¸ ˜ ao de informac ¸ ˜ ao 4 Remote Procedure Call 4 Nomeac ¸ ˜ ao 5 Sincronizac ¸ ˜ ao de rel´

• gio

6 Rel´

• gios L´
• gicos

6 Exclus˜ ao m´ utua 6 Eleic ¸ ˜ ao de l´ ıder 6

12 / 43

Exerc´ ıcios

1

Defina e compare sistemas distribu´ ıdos e sistemas paralelos.

2

Qual ´ e o papel de um middleware em sistemas distribu´ ıdos?

3

Dˆ e exemplos e defina diferentes tipos de transparˆ encia de distribuic ¸ ˜ ao.

4

Qual ´ e a diferenc ¸a entre transparˆ encia de migrac ¸ ˜ ao e transparˆ encia de relocac ¸ ˜ ao?

5

Defina escalabilidade. Quais t´ ecnicas s˜ ao usadas para atingir escalabilidade?

6

Qual ´ e a diferenc ¸a entre replicac ¸ ˜ ao e caching?

7

A vis˜ ao tradicional de transac ¸ ˜

• es diz que quando uma transac

¸ ˜ ao ´ e abortada, ´ e como se a transac ¸ ˜ ao nunca tivesse acontecido. Dˆ e um exemplo onde isto n˜ ao ´ e verdade.

8

Qual ´ e o papel de um coordenador de transac ¸ ˜

• es?

13 / 43

Distributed System: Definition

A distributed system is a piece of software that ensures that: a collection of independent computers appears to its users as a single coherent system Two aspects: (1) independent computers and (2) single system ⇒ middleware.

Local OS 1 Local OS 2 Local OS 3 Local OS 4

• Appl. A

Application B

• Appl. C

Computer 1 Computer 2 Computer 4 Computer 3 Network Distributed system layer (middleware)

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 14 / 43

Distributed System: Alternative Definition

You know you have [a distributed system] when the crash of a computer you’ve never heard of stops you from getting any work done.

• Leslie Lamport

15 / 43

Goals of Distributed Systems

Making resources available Distribution transparency Openness Scalability

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 16 / 43

Distribution Transparency

Transp. Description Access Hide differences in data representation and invocation mechanisms Location Hide where an object is located Relocation Hide that an object may be moved to another location while in use Migration Hide that an object may move to another location Replication Hide that an object is replicated Concurrency Hide that an object may be shared by several independent users Failure Hide failure and possible recovery of an object

Note Distribution transparency is a nice a goal, but achieving it is a different story.

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 17 / 43

Degree of Transparency

Observation Aiming at full distribution transparency may be too much: Users may be located in different continents Completely hiding failures of networks and nodes is (theoretically and practically) 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 caches exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 18 / 43

Openness of Distributed Systems

Open distributed system Be able to interact with services from other open systems, irrespective of the underlying environment: Systems should conform to well-defined interfaces Systems should support portability of applications Systems should easily interoperate Achieving openness At least make the distributed system independent from heterogeneity of the underlying environment: Hardware Platforms Languages

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 19 / 43

Policies versus Mechanisms

Implementing openness Requires support for different policies: What level of consistency do we require for client-cached data? Which operations do we allow downloaded code to perform? Which QoS requirements do we adjust in the face of varying bandwidth? What level of secrecy do we require for communication? Implementing openness 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

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 20 / 43

Scale in Distributed Systems

Observation Many developers of modern distributed system easily use the adjective “scalable” without making clear why their system actually scales. Scalability At least three components: Number of users and/or processes (size scalability) Maximum distance between nodes (geographical scalability) Number of administrative domains (administrative scalability) Observation Most systems account only, to a certain extent, for size scalability. The (non)solution: powerful

• servers. Today, the challenge lies in geographical and administrative scalability.

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 21 / 43

Techniques for Scaling

Hide communication latencies Avoid waiting for responses; do something else: Make use of asynchronous communication Have separate handler for incoming response Problem: not every application fits this model

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 22 / 43

Hiding communication latency

23 / 43

Techniques for Scaling

Distribution Partition data and computations across multiple machines: Move computations to clients (Java applets) Decentralized naming services (DNS) Decentralized information systems (WWW)

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 24 / 43

Distribution: DNS

25 / 43

Techniques for Scaling

Replication/caching Make copies of data available at different machines: Replicated file servers and databases Mirrored Web sites Web caches (in browsers and proxies) File caching (at server and client)

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 26 / 43

Scaling – The Problem

Observation Applying scaling techniques is easy, except for one thing: Having multiple copies (cached or replicated), leads to inconsistencies: modifying

• ne copy makes that copy different from the rest.

Always keeping copies consistent and in a general way requires global synchronization on each modification. Global synchronization precludes large-scale solutions. Observation If we can tolerate inconsistencies, we may reduce the need for global synchronization, but tolerating inconsistencies is application dependent.

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 27 / 43

Developing Distributed Systems: Pitfalls

Observation Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: 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

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 28 / 43

Types of Distributed Systems

Distributed Computing Systems Distributed Information Systems Distributed Pervasive Systems

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 29 / 43

Distributed Computing Systems

Observation Many distributed systems are configured for High-Performance Computing Cluster Computing Essentially a group of high-end systems connected through a LAN: Homogeneous: same OS, near-identical hardware Single managing node

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 30 / 43

Distributed Computing Systems

Local OS Local OS Local OS Local OS Standard network Component

• f

parallel application Component

• f

parallel application Component

• f

parallel application Parallel libs Management application High-speed network Remote access network Master node Compute node Compute node Compute node

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 31 / 43

Distributed Computing Systems

Grid Computing The next step: lots of nodes from everywhere: Heterogeneous Dispersed across several organizations Can easily span a wide-area network Note To allow for collaborations, grids generally use virtual organizations. In essence, this is a grouping of users (or better: their IDs) that will allow for authorization on resource allocation.

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 32 / 43

Distributed Computing Systems: Clouds

Application Infrastructure

Computation (VM), storage (block)

Hardware Platforms

Software framework (Java/Python/.Net) Storage (DB, File)

Infrastructure aa Svc Platform aa Svc Software aa Svc Google Apps YouTube Flickr MS Azure Amazon S3 Amazon EC2 Datacenters

CPU, memory, disk, bandwidth Web services, multimedia, business apps

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 33 / 43

Distributed Computing Systems: Clouds

Cloud computing Make a distinction between four layer: Hardware: Processors, routers, power and cooling systems. Customers normally never get to see these. Infrastructure: Deploys virtualization techniques. Evolves around allocating and managing virtual storage devices and virtual servers. Platform: Provides higher-level abstractions for storage and such. Example: Amazon S3 storage system offers an API for (locally created) files to be organized and stored in so-buckets. Application: Actual applications, such as office suites (text processors, spreadsheet applications, presentation applications). Comparable to the suite of apps shipped with OSes.

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 34 / 43

Distributed Information Systems

Observation The vast amount of distributed systems in use today are forms of traditional information systems, that now integrate legacy systems. Example: Transaction processing systems.

BEGIN TRANSACTION(server, transaction) READ(transaction, file-1, data) WRITE(transaction, file-2, data) newData := MODIFIED(data) IF WRONG(newData) THEN ABORT TRANSACTION(transaction) ELSE WRITE(transaction, file-2, newData) END TRANSACTION(transaction) END IF

Note Transactions form an atomic operation.

35 / 43

Distributed Information Systems: Transactions

Model A transaction is a collection of operations on the state of an object (database, object composition, etc.) that satisfies the following properties (ACID) Atomicity: All operations either succeed, or all of them fail. When the transaction fails, the state of the object will remain unaffected by the transaction. Consistency: A transaction establishes a valid state transition. This does not exclude the possibility of invalid, intermediate states during the transaction’s execution. Isolation: Concurrent transactions do not interfere with each other. It appears to each transaction T that other transactions occur either before T, or after T, but never both. Durability: After the execution of a transaction, its effects are made permanent: changes to the state survive failures.

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 36 / 43

Transaction Processing Monitor

Observation In many cases, the data involved in a transaction is distributed across several servers. A TP Monitor is responsible for coordinating the execution of a transaction

TP monitor Server Server Server Client application Requests Reply Request Request Request Reply Reply Reply Transaction

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 37 / 43

• Distr. Info. Systems: Enterprise Application Integration

Problem A TP monitor doesn’t separate apps from their databases. Also needed are facilities for direct communication between apps.

Server-side application Server-side application Server-side application Client application Client application Communication middleware

Remote Procedure Call (RPC) Message-Oriented Middleware (MOM)

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 38 / 43

Distributed Pervasive Systems

Observation Emerging next-generation of distributed systems in which nodes are small, mobile, and often embedded in a larger system. Some requirements Contextual change: The system is part of an environment in which changes should be immediately accounted for. Ad hoc composition: Each node may be used in a very different ways by different users. Requires ease-of-configuration. Sharing is the default: Nodes come and go, providing sharable services and information. Calls again for simplicity. Note Pervasiveness and distribution transparency: a good match?

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 39 / 43

Distributed Systems

40 / 43

Pervasive Systems: Examples

Home systems Should be completely self-organizing: There should be no system administrator Simplest solution: a centralized home box? Monitoring a person Devices are physically close to a person: Where and how should monitored data be stored? How can we prevent loss of crucial data? What is needed to generate and propagate alerts? How can security be enforced? How can environment provide online feedback?

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 41 / 43

Sensor networks

Characteristics The nodes to which sensors are attached are: Many (10s-1000s) Simple (small memory/compute/communication capacity) Often battery-powered (or even battery-less)

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 42 / 43

Sensor networks as distributed systems

Operator's site Sensor network Sensor data is sent directly to operator Operator's site Sensor network Query Sensors send only answers Each sensor can process and store data (a) (b)

Source: Maarten van Steen, Distributed Systems: Principles and Paradigms 43 / 43