View
219
Download
0
Category
Preview:
Citation preview
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.
Recommended