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 Acesso Tipo Localização Migração Replicação Descrição Ocultar diferenças na representação de dados e no uso de um recurso Oculta o lugar onde o recurso se encontra Usuário não sabe se um recurso foi movido 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 diferenç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
Socket Estrutura de Rede
Estrutura de Rede Números de porta: 16 bits Alguns números são usados por padrão (http://www.iana.org/as signments/servicenames-portnumbers/servicenames-portnumbers.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 Necessidade de middleware do protocolo Protocolo: para TCP implementação ou UDP do Sistema Distribuído! TCP Servidor ServerSocket UDP Servidor DatagramSocket
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.rpcge n/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)
Conceitos Sistemas de Arquivos Serviço: Distribuídos 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.