Sistemas Operacionais 2014 Sistemas Distribuídos

Alexandre Augusto Giron

ROTEIRO

• Conceitos

• Hardware/Software para Sistemas Distribuídos

• Estrutura de Rede

• Objetos Distribuídos

• Sistemas de Arquivos Distribuídos

Conceitos

• O que é um Sistema Distribuído?

– Silberschatz: “Coleção de processadores fracamente acoplados e conectados por uma rede de comunicação”

– Tanembaum: “Um conjunto de máquinas independentes que fornecem uma visão de uma única máquina para os usuários”

Conceitos

Principais Objetivos de um Sistema Distribuído

• Compartilhamento de Recursos

• Ganho de desempenho

• Confiabilidade

• Comunicação

• Transparência

• Escalabilidade

Compartilhamento de Recursos

• Facilitar aos usuários e aplicações acesso aos recursos remotos

• Exemplos de recursos

– Impressoras, computadores, armazenamento, dados, páginas Web, arquivos

Ganho de desempenho

• Tarefas distribuídas e concorrentes

• Exemplo prático

– Distribuição de carga entre servidores Web

• Se um servidor estiver sobrecarregado de requisições, elas podem ser repassadas para outros servidores atenderem

Confiabilidade

• Garantir que haja o funcionamento mesmo em casos de falhas parciais

• Manutenção de serviço (Disponibilidade) – Se uma máquina pertencente ao sistema

distribuído parar, • As outras devem continuar operando de forma

independente

– Redundância • Replicar Hardware/Dados

• Ex: Se um dispositivo falhar, o dispositivo replicado assume

Comunicação

• Sistema distribuído deve se comunicar por uma rede

– Processamento distribuído: troca de mensagens

– Vantagem: grandes distâncias

• Requisitos

– Uma rede com alto desempenho

Transparência

• Um sistema distribuído deve ser transparente

– Ocultar detalhes da distribuição

– Capacidade de se apresentar aos usuários como se fosse um sistema único

Transparência

Tipo Descrição

Acesso Ocultar diferenças na representação de dados e no uso de um recurso

Localização Oculta o lugar onde o recurso se encontra

Migração Usuário não sabe se um recurso foi movido

Replicação Oculta o fato de que um recurso é replicado

Concorrência Oculta o compartilhamento do recurso entre diversos usuários simultâneos

Falha Oculta ocorrência e recuperação de falhas pelo sistema

Escalabilidade

• Facilidade para estender/aumentar capacidades de um sistema distribuído

– Tamanho: fácil adicionar mais usuários e recursos

– Geográfica: usuários e recursos podem estar longe entre si

– Administrativos: facilidade de gerenciar

Robustez

• Um sistema distribuído pode sofrer de vários tipos de falhas

• Para garantir que o sistema é robusto, ele deve fornecer

– Detecção de Falhas

– Reconfiguração (Recuperação)

Robustez

• Detecção de Falhas – Difícil em hardware

– Link de uma rede • Abordagem: “Você está online?”, “X: estou

online”

• Se não chegar nenhuma mensagem em um período, assume-se que o link foi perdido

• Recuperação – Quando o serviço é restaurado, ele deve

ser comunicado e disponibilizado novamente para uso

HARDWARE/SOFTWARE PARA SISTEMAS DISTRIBUÍDOS

Hardware

• Classificação:

– Taxonomia de Flynn: Fluxo de dados

• SISD: Single Instruction Single Data

• SIMD: Single Instruction Multiple Data

– Processamento multimídia

• MISD: Multiple Instruction Single Data

• MIMD: Multiple Instruction Multiple Data

– Máquinas paralelas

MIMD: MultiProcessadores

• Simétricos: SMP

– Memória compartilhada

MIMD: MultiComputador

• Cada computador possui seus recursos

– CPU, memória, interface de rede

MIMD

• Classificação de Tanembaum

Interface de Rede

Software para Sistemas distribuídos

• Arquiteturas de software

– Como estruturar a aplicação

• Arquitetura em camadas

• Arquitetura baseada em objetos

• Características

– Centralizadas, Descentralizadas ou Híbridas

Arquitetura em camadas

• Middleware

– Camada para ocultar dife-renças de SOs

– Mesma interface de aplicação

Arquitetura baseada em objetos

• Objetos (componentes) conectados por chamada de procedimento remota

Arquiteturas Centralizadas

• Arquitetura Cliente-Servidor

• Clientes:

– Requisitam serviços

• Servidor:

– Fornecem os serviços

Arquiteturas Descentralizadas

• Arquitetura peer-to-peer (P2P)

• Clientes podem fazer requisições e também atuar como servidores

Peer-to-peer e Client-Server

Software para Sistemas distribuídos

• Serviços disponíveis

– Necessidade de um protocolo de comunicação

• Computadores distribuídos

– Diferentes plataformas!

Software para Sistemas distribuídos

• Software para internet?

– Qual arquitetura de software?

– Como processos em diferentes máquinas se comunicarão?

– Protocolo

• Define o formato de mensagens, formas de comunicação

• TCP

• UDP

Software para Sistemas distribuídos

• Software para internet?

– Qual arquitetura de software?

• Client-Server ou P2P?

– Como processos em diferentes máquinas se comunicarão?

– Protocolo

• Define o formato de mensagens, formas de comunicação

• TCP

• UDP

Estrutura de Rede

• Problema:

– N processos comunicantes em diferentes máquinas

– Como se comunicar?

• Socket

– Número de porta

– Endereço de rede

Estrutura de Rede

• Socket

Estrutura de Rede

• Números de porta: 16 bits

• Alguns números são usados por padrão (http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)

Protocolo Porta

FTP 20 e 21

SSH 22

Telnet 23

SMTP 25

DNS 53

Web 80

Pop3 110

IMAP 143

Protocolos de Transporte

• Aplicações requerem uma forma padronizada de comunicação

– Protocolo de transporte: formato, tipo e fluxo das mensagens

• Protocolos mais usados

– TCP

– UDP

• Diferem na operação e no modelo de serviço fornecido

Protocolos

• TCP – Entrega garantida – Vários serviços utilizam esse protocolo

• UDP – Mais simples, não garante entrega – Mais usado em aplicações tolerantes à

perda

• Uma nova aplicação pode se utilizar de serviços já disponíveis – Troca de arquivos via FTP – Emails: SMTP, POP3..

Java Socket

• API Java permite trabalhar com protocolo TCP ou UDP

• Aplicação: – Código da aplicação

– Camada de middleware

– Protocolo: TCP ou UDP

• TCP Servidor – ServerSocket

• UDP Servidor – DatagramSocket

Java Socket

• API Java permite trabalhar com protocolo TCP ou UDP

• Aplicação: – Código da aplicação

– Camada de middleware

– Protocolo: TCP ou UDP

• TCP Servidor – ServerSocket

• UDP Servidor – DatagramSocket

Necessidade do protocolo para implementação do

Sistema Distribuído!

UDP

• Características – Sem conexão

– Mais simplificado

– Não há garantia de entrega da mensagem

• Experimento prático: – Montar uma aplicação distribuída

• Cliente UDP: Envia uma string

• Servidor UDP: processa a string e devolve ao cliente

Aplicação UDP

• Parâmetros necessários:

– Escolher um número de porta não usado

• 1 a 1024 reservado para protocolos conhecidos

• Cliente deve se comunicar ao servidor pela porta especificada

– Escolher um endereço IP (de rede)

• 127.0.0.1: endereço local (localhost)

Cliente UDP (1)

Cliente UDP (2) – Envio da mensagem

Cliente UDP (3) - resposta

Servidor UDP (1)

Servidor UDP (2) – Aguardando mensagens

• Estado de espera até receber mensagem

Servidor UDP (3) – Processa e responde ao cliente

Aplicação UDP

• Para testar: – Execute o servidor e o cliente

– Digite a mensagem no cliente

– Visualize a resposta

• Considerações – O que acontece se executarmos dois

servidores sobre o mesmo número de porta?

– E se o cliente enviar para um número de porta que não há nenhum processo escutando?

Aplicação TCP

• Mesma aplicação

– Cliente envia uma string

– Servidor processa e responde

• Parâmetros

– Número de porta

– Endereço IP

Características

• Há formação de conexão entre cliente e servidor

• Mais complexo

• Entrega garantida pelo protocolo

Cliente TCP

• Socket diferente

– Orientação à conexão

Servidor TCP

Exercícios

1. Faça uma aplicação UDP que considere: – Envio de dois números inteiros pelo cliente

– Servidor realiza a soma dos números

– Servidor envia a resposta ao cliente

2. Repita o exercício usando TCP

3. Faça uma aplicação (TCP ou UDP) que: – Cliente solicita um arquivo pelo nome;

– Servidor envia o arquivo para o cliente

– Considere tamanho máximo do arquivo igual a 1024 bytes

OBJETOS DISTRIBUÍDOS

Paradigma OO

• Orientação a Objetos bastante comum atualmente

– Sistemas Distribuídos + OO = Objetos distribuídos

• Camada de Middleware

– Necessária para tornar o objeto independente de SO e hardware

Objetos Distribuídos

• Suporte de Middleware para Objetos distribuídos

– Java RMI (Sun)

– CORBA (OMG)

– DCOM (Microsoft)

Evolução

RPC

• Remote Procedure Call (RPC)

– Antes do paradigma OO

• Procedimentos executados em máquinas remotas

– Ideia é manter a forma das chamadas iguais à forma das chamadas de procedimentos locais

RPC

• Chamadas síncronas (geralmente)

– Embora alguns sistemas permitem chamadas assíncronas

• Comunicação

– Transparente

• Código gerado pelo compilador (stub, proxy...)

– Objetos serializados para o envio

SUN/RPC

• Rpcgen: – Programa para compilar e gerar stubs

(cliente e servidor) para uma aplicação

– Definição da interface • Linguagem parecida com C

• Fluxo de Implementação 1. Definição da Interface

2. Geração dos stubs • Stub: representação local do objeto

remoto para o cliente

RPC

• Experimento prático com linguagem C

– Aplicação que soma dois números

• Cliente: envia a mensagem

• Servidor: recebe e processa

Interface: adicao.x

Interface: adicao.x

• O número do programa deve ser único

• RPCgen especifica intervalo para uso:

– 0x20000000 -> 0x3fffffff

RPCgen

• Verifique se o rpcbind está instalado

• rpcinfo

• apt-get install rpcbind

• Gerar os stubs:

– rpcgen –N -a adicao.x

RPC

• Arquivos gerados

– adicao.h

– adicao_client.c

– adicao_server.c

– Demais arquivos

• Gerados pelo rpcgen

• Alterações na interface: nova geração de stubs!

RPC Server (adicao_server.c)

RPC Cliente (adicao_client)

• Modifique a função adicao_1

• Faça o teste:

– make –f Makefile.adicao

– ./adicao_server

– ./adicao_client localhost

RPC - Considerações

• Note a abstração para os detalhes de rede

– Programador se preocupa mais com detalhes da aplicação

• Mais detalhes

– Guia de programação com RPC:

• http://docs.freebsd.org/44doc/psd/22.rpcgen/paper.pdf

Exercício

1. Faça uma aplicação com RPC onde:

– Cliente: envia uma string

– Servidor: altera a string para uppercase e responde ao cliente

– Cliente imprime a string alterada.

RMI

• Remote Method Invocation (RMI)

– Objetos podem invocar métodos de outros remotamente

– Transparência:

• Chamada remota ao método igual à chamada local

• Protocolo de transferência implementado sobre o middleware

Java RMI

• Multi-plataforma

– J2SE (Java 2 Standard Edition) e J2EE (Java 2 Enterprise Edition) com suporte ao RMI

• Permite um objeto Java chame método de outro objeto java

Java RMI: 3 camadas

• Stubs e Skeletons interceptam as chamadas de procedimento

– Serialização de objetos

• Referência remota:

– Localização dos objetos

Fluxo de Implementação

1. Definição de uma interface – Conjunto de métodos que podem ser

acessados remotamente – Interface deve estender classe Remote

(java.rmi.Remote)

2. Classes devem ser serializáveis – Fluxo de bytes em um formato definido – Tipos predefinidos na linguagem – Permite que os objetos sejam passados como

parâmetros

3. Geração de Stubs e Skeletons – Pelo compilador com base nessa interface – rmic

Exemplo prático

• Nossa aplicação consiste de

– Um cliente: enviando uma string

– Um servidor: processando e retornando ao cliente

• Registro

– É necessário registrar a execução do servidor

– Assim o cliente pode procurar o objeto na rede

Interface RMI

Servidor (1)

Servidor (2)

• Object Registry: servidor de nomes que mapeia objetos para nomes

– Invocações apenas se objetos estão registrados

Cliente (1)

Java RMI - Considerações

• Note que o cliente é um programa Java simples

– Mas deve conhecer a interface

• Objetos são registrados para que os métodos sejam acessados

– Naming.lookup()

• Objeto local ou remoto

Java RMI

• Mais detalhes:

– Tutorial RMI da Oracle

• http://docs.oracle.com/javase/tutorial/rmi/

– Documentação da API Java

Exercício

1. Faça uma modificação no código para seguinte situação:

– Se o cliente enviar o comando ‘exit’:

• Remover o registro no servidor (servidor “off-line”)

• Cliente deve encerrar a execução

2. Uma aplicação onde:

– Cliente envia dois números

– Servidor retorna a soma

SISTEMAS DE ARQUIVOS DISTRIBUÍDOS

Sistemas de Arquivos Distribuídos

• Aplicação importante e comum de sistemas distribuídos

– Distributed File System (DFS)

• Exemplos

– Open AFS

– NFS (Network File System)

Sistemas de Arquivos Distribuídos

• Conceitos

– Serviço:

• Entidade de software executando de forma distribuída e fornecendo um tipo particular de funcionalidades aos clientes

• É executado por meio da rede

– Servidor:

• Uma entre as máquinas que executam o serviço

– Cliente:

• Processo que pode invocar um serviço usando um conjunto de operações

DFS

• Um DFS é disperso – Clientes, servidores e dispositivos de

armazenamento • Localizados entre as máquinas de um

sistema distribuído

– Vantagem • Autonomia e Multiplicidade dos clientes e

servidores

– Requisito • Deve ser transparente ao usuário

• Eficiência: tempo gasto para realizar as operações

DFS

• Interface Cliente

– Composta por um conjunto de primitivas e operações

• Criar, apagar, escrever, ler

– Não deve haver distinção entre arquivos remotos e locais

DFS – Mapeamento de Nomes

• Mapeamento de nomes – Usuário: nomes de arquivos – Sistema de Arquivos: blocos armazenados

no disco

• Local – Endereço do dado no disco

• Ex: número do cluster lógico -> cluster físico

• Remoto – Endereço inclui a máquina que contem o

arquivo/dado • Possibilidade: um conjunto de máquinas, cada

uma com parte do arquivo (File Replication)

DFS – Mapeamento de Nomes

• Diferenças

– Transparência de Localização

• Nome do arquivo não revela localização física do arquivo

• Maioria fornece esse esquema

– Independência de Localização

• Nome do arquivo não necessita ser modificado se a localização física do arquivo mudar de dispositivo de armazenamento

• Nem todos fornecem esse esquema

Esquemas de Nomes

• Absoluto

• Montagem

• Global

Esquema de Nomes: Absoluto

• Mais simples

• Nome da máquina (host) + nome do arquivo

– host:local-name

– URL da Internet também usa esse mesmo esquema

• Desvantagens

– Não há transparência de localização

– Não há independência de localização

Esquema de Nomes: Montagem

• Pontos de Montagem – NFS da Sun usa esse esquema

– Meio de ligar diretórios remotos para diretórios locais • Cada máquina tem nomes locais que

referenciam arquivos remotos

• Mapeamento durante a inicialização

– Automount • Permite que sejam criados pontos de montagem

por demanda

• Tabela guarda informações dos pontos de montagem e os nomes

Network File System

• Estrutura

Network File System

• Montagem remota

Esquema de Nomes: Montagem

• Consegue obter um nível de transparência

– Usuário utiliza o nome local

– Sistema realiza o mapeamento pela tabela

• Porem necessita configuração prévia

– Para as inicializações

Esquema de Nomes: Global

• Estrutura de nomes global

– Vantagem: Todos possuem a mesma estrutura de diretórios

– Clientes obtêm a estrutura do servidor

• Dificuldades

– Características específicas dos arquivos

• Arquivos de dispositivos (Linux), Binários compilados para diferentes arquiteturas

– Confiabilidade no servidor

Acesso aos arquivos

• Acesso Remoto aos Arquivos

– Como implementar?

• RPC, RMI

• Desempenho

– Caches são frequentemente usadas

• Obter blocos recentemente acessados na cache

• Poderão ser acessadas novamente sem novo acesso ao disco

Acesso aos arquivos

• Modelos de cache

– Escrita direta: write-through

• Confiabilidade

• Desempenho baixo nas escritas: cada escrita deve esperar pela atualização no servidor

– Escrita adiada (write-back)

• Atualização no servidor atrasada: maior desempenho nas escritas

• Confiabilidade menor: dados não atualizados podem ser perdidos

Acesso aos arquivos

• OpenAFS: variação • Write-on-close: parte das seguintes

premissas:

– Arquivos abertos por pouco tempo são para leitura não necessitam ser atualizados no servidor constantemente

– Arquivos abertos por mais tempo têm maior chance de serem modificados: atualização apenas quando o arquivo for fechado

Estado nos servidores

• Classificação – Servidores Stateful

• Guardam estado de acordo com arquivos abertos dos clientes

• Identificador para os clientes

• Ex: servidor pode retirar um arquivo aberto após um tempo de inatividade do cliente

– Servidores Stateless • Não guardam informação alguma sobre os

arquivos abertos por clientes

• Mais simples

Estado nos servidores

• Recuperação de falhas

– Falhas no servidor não são notadas pelos clientes

• Falha

– Em um servidor com estado

• Deve recuperar o estado das conexões com os clientes

• Perda das informações na memória

– Servidor sem estado

• Requisições tendem a ser maiores

MÁQUINAS VIRTUAIS – INTRODUÇÃO

Conceitos

• Objetivo principal de uma máquina virtual – Fornecer uma abstração de um hardware para

diferentes ambientes de execução

• Componentes – Host: Sistema que hospeda máquinas virtuais

– Virtual Machine Manager (VMM ou Hypervisor) • Gerencia as máquinas virtuais

• Fornece interface similar à do host

– Guest • Um sistema operacional executado no ambiente

virtualizado

Sistema Virtualizado vs Não-Virtualizado

Tipos de VMM

• Tipo 0 – Soluções baseadas em hardware/firmware

– Usadas em mainframes e servidores

• Tipo 1 – Software para fornecer virtualização

• Ex: VMWare ESX, Citrix XenServer

– Alguns SOs também fornecem essas funcionalidades • Classificados também como tipo 1

• Windows Server com HyperV

• KVM do Linux RedHat

Tipos de VMM

• Tipo 2:

– VMM como uma aplicação comum

• VMWare Workstation, Virtual Box

– Executam sobre um SO

– Fornecem funções para guests

Benefícios

• Habilidade para fornecer diferentes ambientes de execução diferentes – Executar diferentes SOs concorrentemente

• Proteção – Execução isolada

• Host é protegido de modificações em Guests

– Problemas • Dificulta o compartilhamento de recursos; deve ser

explícito

• Implementação de SO – Erros no kernel, complexidade do SO

dificultam o desenvolvimento de um SO – Máquina virtual fornece maior controle

Benefícios

• Otimização de recursos

– Live migration: move um guest de um host físico para outro

• Maior compartilhamento de recursos

• Se um host estiver sobrecarregado, um guest pode ser movido para outro

– Recursos de hardware compartilhados

• CPU, memória e E/S fornecido como serviço para clientes

Dificuldades

• Implementação de máquinas virtuais complexa – Comunicação entre modo usuário e kernel

• Desempenho

– Gerência de memória • Nested Page Tables

• Requer um apoio de hardware – Atualmente processadores já fornecem

instruções específicas para virtualização • Intel VT-x instructions • Tecnologia AMD-V

– Operação em modo dual • Host e Guest

Exemplo: VMWare

Exemplo: VMWare

• Classificada como VMM do tipo 2

– Executa como uma aplicação do host

– Permite a execução de um ou mais guests de forma independente

• Cada Guest possui (virtualmente)

– CPU, memória, disco, interfaces de redes, etc

• Ex: Um disco corresponde a um arquivo no host

VMM tipo 2

• Normalmente possuem desempenho pior que os de tipo 0 e 1

– VMM é um processo comum sendo escalonado pelo host

• Mas há vantagens

– Versatilidade: pode-se testar um novo SO sem abrir mão do existente

– Não necessitam de muitas modificações no host

Exemplo: JVM

• Java Virtual Machine – Fornece um ambiente de

programação/execução virtualizado • Tipo especial de virtualização • Ambiente como um programa executável no

host • Programas rodam sobre o ambiente:

independente de SO (desde que ele execute a JVM)

• JVM – Implementada em software sobre um host – Como parte de um navegador web – Implementada em hardware específico

para programas Java

JVM

Paravirtualização

• Introdução de camadas para abstração de hardware

– Pode diminuir desempenho

• Conceito de Paravirtualização

– Exige mudança nos SOs

– Fornecer acesso do VMM direto ao hardware subjacente

• Kernel do SO guest executa no VMM

Para casa

• Leitura da parte IV (Sistemas Distribuídos) – Lista de exercícios (Sistemas

Distribuídos e virtualização)

– Data da entrega (Lista de exercícios): • 17/11/2014

• Individual ou em dupla

• Peso: 10

Bibliografia

1. SILBERSHATZ, A. et al. Operating systems Concepts. John Wiley & Sons, New York, 5ª edição. 1997.

2. STALLINGS, W. Operating system concepts. Prentice Hall, New Jersey, 3ª edição, 1997.

3. TANENBAUM, A. et al. Operating systems: design and implementation. Prentice Hall, New Jersey, 1997.

4. TANENBAUM, A. et. al. Modern Operating Systems. Prentice Hall, New Jersey, 1992.