SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar

Transcrição

1 - Aula 5 PROCESSOS 1. INTRODUÇÃO Em sistemas distribuídos é importante examinar os diferentes tipos de processos e como eles desempenham seu papel. O conceito de um processo é originário do campo de sistemas operacionais no qual ele é definido como um programa em execução. Da perspectiva de Sistema Operacional, o gerenciamento e o escalonamento de processos são talvez as questões mais importantes. 2. PROCESSOS Sistemas Operacionais modernos criam vários processadores virtuais, cada um para executar um programa. Para monitorar os processadores virtuais o sistema operacional tem uma tabela de processos que contém entradas para armazenar valores de registradores de CPU, mapas de memória, arquivos abertos, etc. Como visto os processos podem ser considerados programas em execução, na qual o Sistema Operacional é o responsável por assegurar que processos independentes não afetem (modos intencional, malicioso ou acidental) a correção do comportamento dos outros processos sendo executados. Nesta ótica deve também existir transparência no compartilhamento da mesma CPU e outros recursos de hardware. A transparência implica em custos como: - Criação de espaço de endereços completamente independente - Chavear a CPU entre dois processos - Salvar o contexto da CPU - Troca de informações entre disco e memória principal Neste sentido, em sistemas tradicionais, cada processo deve possuir o seu próprio espaço de endereçamento e um único fluxo de execução. No entanto, em alguns casos é desejável haver diversos fluxos de execução compartilhando um único espaço de endereçamento, ou seja, mesma região de memória. Em havendo um único fluxo de execução ocorre certa perda de desempenho. Como exemplo, um servidor de arquivos deve esperar por requisições feitas ao disco, visto que o fluxo de execução que fez a requisição é bloqueado aguardando a resposta. Com vários fluxos de execução existe melhor vazão (throughput) e ganho de desempenho. Seguindo o mesmo exemplo, se um servidor de arquivos é implementado usando diferentes fluxos de execução, outras requisições de clientes podem ser processadas, enquanto o primeiro fluxo aguarda a resposta do disco. Este é o princípio das threads. 1

2 3. THREADS Embora processos formem um bloco de construção em sistemas distribuídos, a prática indica que a granularidade de processos proporcionada pelos sistemas operacionais sobre os quais os sistemas distribuídos são construídos não é suficiente. Em vez disso, observa-se que ter granularidade sob a forma de múltiplos threads de controle por processo facilita muito a construção de aplicações distribuídas e a obtenção de melhor desempenho. Figura 1 - Processo vs Thread Cada um dos fluxos de execução de um processo é chamado de thread, ou seja, as threads podem ser vistas como mini-processos, onde cada thread executa sua própria porção de código. Cada thread compartilha a CPU do mesmo modo que diferentes processos compartilham (timesharing) Threads em sistemas não-distribuídos As threads que fazem parte de um mesmo processo não são independentes como no caso de diferentes processos. Todas as threads em um mesmo processo possuem a mesma região de memória e compartilhando as mesmas variáveis globais. Sendo assim, uma determinada thread pode ler, escrever ou mudar a pilha de dados de outra thread. Dessa forma, a proteção deve ser implementada na aplicação. As threads podem estar em diferentes estados: - Executando - Bloqueado - Pronto - Finalizado Dadas as características observa-se a seguinte diferença quanto ao conteúdo das threads e processos: 2

3 Quadro 1 Itens da Thread e do Processo Itens por Thread PC Pilha Registradores Threads Filhas Estado Itens por Processo Espaço de endereçamento Variáveis Globais Arquivos abertos Processos filhos Sinais Timers Informações da Conta Semáforos VANTAGENS - Explorar paralelismo ao executar um programa em um sistema multiprocessador. Ex.: Cada thread é designado a uma CPU, enquanto dados compartilhados são armazenados em memória compartilhada. - Em grandes aplicações, desenvolvidas como um conjunto de programas cooperativos evita chaveamento entre diferentes processos devido comunicação através de Interprocess Communication (IPC). Figura 2 - Chaveamento de contexto como resultado de IPC Nas threads a comunicação pode ser feita com a utilização de dados compartilhados. O chaveamento ocorre entre espaços de usuário IMPLEMENTAÇÃO DE THREADS EM SISTEMAS NÃO-DISTRIBUÍDOS Nível Usuário - As threads rodam sobre o runtime system coleção de procedimentos que gerenciam as threads. 3

4 - Quando uma thread executa uma chamada de sistema, ela entra no estado de espera e opera um semáforo enquanto o runtime system verifica se o thread deve ser suspensa. - Existe um custo de criação e alocação da memória para a pilha. - Chaveamento de contexto de thread pode ser feito em apenas algumas instruções. Não há necessidade de mudar mapas de memória, descarregar o TLB (Translation Lookaside Buffer) - As threads precisam entrar em sincronia. Figura 3 - Implementação em nível de usuário A desvantagem de threads de nível de usuário está em como chamadas de sistemas bloqueantes são implementadas, como por exemplo, ler um pipe vazio, na qual a chamada de sistema acarretará em bloqueio de todas as threads. Nível Kernel - A criação, encerramento e sincronização deverão ser feitos pelo kernel. - Chamadas de sistema deverão ser realizadas. - Chavear contextos de threads é tão caro quanto chavear contexto de processos. Figura 4 - Implementação em nível do Kernel 4

5 3.2. Threads em Sistemas Distribuídos Na implementação de threads em sistemas distribuídos uma importante propriedade é que eles podem proporcionar um meio conveniente de permitir chamadas bloqueantes de sistema sem bloquear o processo inteiro. As threads são particularmente atraentes para utilização em sistemas distribuídos, pois facilitam a comunicação na forma de manter múltiplas conexões lógicas ao mesmo tempo CLIENTES MULTITHREADS Os Sistemas distribuídos que operam em redes de longa distância escondem longos tempos de propagação de mensagens entre processos. A maneira de ocultar latências de comunicação é iniciar a comunicação e imediatamente prosseguir com outra atividade. Em um browser web, o documento Web consiste em um texto, imagens, ícones, etc. Cada elemento, browser estabelece uma conexão TCP/IP, para ler os dados e passar ao monitor do usuário. Operações bloqueadoras fazem o estabelecimento da conexão e leitura de dados. Os browsers começam a exibir dados enquanto, à medida que novas informações chegam. Enquanto o texto está sendo disponibilizado para o usuário, incluindo as facilidades de rolamento, o browser continua buscando outros arquivos, como imagens. A vantagem é que o usuário não precisa esperar até que todos os componentes sejam buscados. Threads separados são ativados para se encarregar de buscar diferentes partes de uma página, assim caso o servidor esteja em sobrecarga, ter um cliente multithread possibilita estabelecer conexões com diferentes servidores, permitindo transmissão dos dados em paralelo, onde o cliente pode manipular fluxos de dados de entrada em paralelo, por meio de threads SERVIDORES MULTITHREADS Um servidor de arquivos normalmente espera pela entrada de uma requisição para uma operação de arquivo e, na seqüência, executa a requisição e então devolve a resposta. Com a utilização de threads é possível aumentar seu desempenho. Os servidores multithreads funcionam da seguinte maneira: - requisições são enviadas por clientes para uma porta no servidor. - Uma thread despachante lê requisições que entram para uma operação de arquivo. - O servidor escolhe uma thread operária. - Se o thread escolhido estiver suspenso, outro thread é selecionado para ser executado, como por exemplo, o thread despachante pode ser selecionado para adquirir mais trabalho. 5

6 Figura 5 - Servidor multithread organizado segundo modelo despachante/operário Se o servidor é inteiramente CPU-bound, não existe necessidade de diversos threads, ocorre um aumento de complexidade sem ganho de desempenho. 4. VIRTUALIZAÇÃO Threads e processos podem ser vistos como um modo de fazer diversas tarefas ao mesmo tempo. Em computadores monoprocessados, a execução simultânea é uma ilusão, pois possuem uma única CPU, ou seja, somente uma instrução de um único thread ou processo será executada por vez. A virtualização de recursos possibilita fingir que um determinado recurso está replicado no sistema. Dessa forma, estende ou substitui uma interface existente de modo a imitar o comportamento de outro sistema. Figura 6 - (a) Organização geral entre Programa, Interface e Sistema. (b) Organização geral da virtualização do sistema A sobre o B Na década de 1970 a virtualização foi aplicada com sucesso nos mainframes IBM, que ofereciam uma máquina virtual para executar softwares que incluíam aplicações e também os sistemas operacionais. 6

7 Softwares em nível mais alto são mais estáveis que o hardware e sistemas de software de baixo nível. Assim a virtualização pode ajudar transportando as interfaces de softwares para novas plataformas. As novas plataformas são capazes de executar softwares existentes anteriormente Arquiteturas de Máquinas Virtuais Existem vários modos pelos quais a virtualização pode ser realizada na prática. Existem quatro tipos diferentes de interfaces em quatro níveis diferentes como representado na figura a seguir: Figura 7 - Várias interfaces oferecidas por sistemas de computadores A essência da virtualização é imitar o comportamento das interfaces (instruções de máquina, chamadas de sistema) Máquina Virtual de Processo Aplicações desenvolvidas para um Sistema Operacional são executadas em outro Sistema Operacional. A virtualização é feita somente para um único processo. Funcionam como emuladores, com a finalidade de imitar chamadas de sistema Monitor de Máquina Virtual Fornece o conjunto de instruções completo do hardware. Vários sistemas operacionais diferentes executando independente e concorrentemente na mesma plataforma. Importantes no contexto de confiabilidade e segurança proporcionando isolamento de uma aplicação e seu ambiente. As falhas não afetam a máquina inteira. Exemplo: VMware, VirtualBox, VitualPC, etc. 7

8 Figura 8 - (a) Máquina Virtual de processos com várias aplicações (instâncias). (B) Monitor de Máquina Virtual com várias aplicações (instâncias) 5. CLIENTES E SERVIDORES Uma tarefa muito importante de máquinas clientes é proporcionar aos usuários meios de interagir com servidores remotos. Isto pode se dar de duas formas: - Para cada serviço remoto, a máquina cliente terá um servidor separado, com o qual possa estabelecer contato. Algumas operações são feitas no próprio cliente. - Fornecer apenas uma interface de usuário conveniente. Máquina cliente é usada somente como um terminal sem nenhuma necessidade de armazenamento. Figura 9 - Soluções cliente-servidor 5.1. Transparência na Distribuição no Cliente O software no lado cliente pode ser mais do que uma interface. Em alguns casos, parte do nível de processamento e dados são executadas no lado cliente. 8

9 TRANSPARÊNCIA DE MIGRAÇÃO Se um cliente já está vinculado a um servidor, ele pode ser informado quando o servidor mudar de localização. Um Middleware no cliente oculta do usuário a corrente localização do servidor TRANSPARÊNCIA A FALHA O Middleware cliente pode ser configurado para tentar a conexão com um servidor repetidas vezes, ou tentar outro servidor após várias tentativas. O uso de cachê minimiza uma falha na conexão com o servidor Servidores QUESTÕES DE PROJETO Cada servidor é organizado do mesmo modo: - Espera por uma requisição de um cliente. - Assegura o atendimento. - Espera pela próxima requisição TRATAMENTO DE REQUISIÇÕES Em um Servidor Iterativo, o próprio servidor manipula a requisição e, se necessário, retorna uma resposta ao cliente. Um Servidor Concorrente não manipula por si próprio a requisição. Como nos servidores multithreads e processos ou threads que devolvem a resposta ao cliente REQUISIÇÃO DO CLIENTE Clientes enviam requisições a uma porta, na máquina em que o servidor está executando Para alguns serviços conhecidos (FTP,HTTP) existem portas pré-definidas. Para serviços que não requerem porta pré-determinada, uma opção é ter um daemon, onde o cliente o acessa e o sistema operacional informa dinamicamente uma porta. Outra maneira de manipular portas é o uso de superservidores. Para os casos onde diversos servidores que possuem uma porta específica estão rodando em uma mesma máquina. O monitoramento passa a ser realizado por um superservidor à escuta em cada porta associada com um serviço específico. Exemplo é o daemon inetd no Unix. 9

10 Figura 10 - (a) Daemon. (b) Supervisor INTERROMPENDO A COMUNICAÇÃO Na abordagem mais simples o usuário sai abruptamente da aplicação cliente. O servidor encerrará a conexão antiga. Na abordagem mais completa são usados os dados urgentes (fora da banda). Pacotes TCP possuem no header o campo URG. O servidor ao receber um pacote com o campo URG setado é interrompido, através de um sinal MANUTENÇÃO DE ESTADO São três os estados: - Sem estado - Estado flexível - Com estado Servidores sem estado: Não mantém informações sobre os estados dos clientes e podem mudar seu próprio estado sem ter de informar a nenhum cliente, como por exemplo, o Servidor Web que, após processar uma requisição, esquece o cliente. Mesmo sem estado, servidor Web guarda informações de clientes. A perda não resulta na interrupção do serviço. 10

11 Servidores com estado flexível: Servidor promete manter estado em nome do cliente, por um tempo limitado. Após o tempo limitado, o servidor descarta estas informações. Exemplo: Servidor promete manter um cliente informado sobre atualizações Servidores com estado: O servidor mantém as informações persistentes sobre seus clientes. As informações precisam ser explicitamente removidas pelo servidor. Exemplo: Servidor de arquivos que permite a um cliente manter cópia local de um arquivo. O servidor mantém uma tabela, com entradas (cliente, arquivo). Permite monitorar as permissões sobre um arquivo, etc. O problema aqui é a recuperação de Falhas. 6. MIGRAÇÃO DE CÓDIGO Além a passagem de dados entre diferentes máquinas, em alguns casos é importante migrar código de uma máquina para outra. A principal razão em se fazer a migração de código é obter um aumento de desempenho Desempenho O envio de processos de máquinas sobrecarregadas para máquinas com cargas mais leves evita grande quantidade de mensagens trocadas entre aplicações cliente-servidor. Exemplos: - Operações de banco de dados que envolvem uma grande quantidade de dados (aplicação cliente/servidor) - Formulários enviados do servidor para o cliente Modelos para Migração de Código A migração de código é algo muito mais amplo: podemos também migrar status de um programa, sinais pendentes e outras partes do ambiente. Um processo consiste em três segmentos: - Segmento de código: contém o conjunto de instruções que compõem o programa que está em execução. - Segmento de recursos: contém referências a recursos externos (arquivos, impressoras). -Segmento de execução: armazenar o estado em execução de um processo no momento da migração (dados privados, pilha, contador de programa). A mobilidade pode ser de dois tipos: - Mobilidade Fraca: possível transferir somente o segmento de código, junto com alguns dados de inicialização. Requer somente que a máquina-alvo possa executar o código (portabilidade). 11

12 - Mobilidade Forte: segmento de execução também pode ser transferido. O processo em execução pode ser parado e movido para uma outra máquina e retomar a execução no ponto original. Em relação do ponto de início da migração: - Iniciada pelo remetente: a migração é iniciada na máquina em que o código está em execução no momento em questão. Exemplo é enviar programa de busca pela Internet a um servidor de banco de dados para realização de pesquisas. - Iniciada pelo destinatário: Iniciativa da migração de código é tomada pela máquina-alvo. Figura 11 - Alternativas para migração de código 6.3. Migração e Recursos Locais Segmentos de recursos requerem uma atenção especial. Exemplo: A comunicação de um processo sendo feita através de uma porta TCP. Ao mudar de localização, este processo deverá devolver a porta e requisitar uma nova no destino. Existem três tipos de vinculações do processo-recurso: - Vinculação por identificador: o processo requer exatamente o recurso referenciado (URL de um site). - Vinculação por valor: É necessário somente um valor. Se outro recurso fornece o mesmo valor, execução não é afetada (bibliotecas padronizadas) - Vinculação por tipo: Processo requer um recurso de um tipo específico (monitores, impressoras). Existem também três tipos de vinculações recurso-máquina: - Recursos não ligados: recursos podem ser movidos com facilidade entre maquinas diferentes (arquivos de dados). 12

13 - Recursos amarrados: recursos podem ser movidos ou copiados, mas só a custo relativamente alto (banco de dados locais). - Recursos fixos: recursos estão intimamente vinculados a uma máquina ou ambiente especifico e não podem ser movidos (porta). - Referência global: Caso vários processos referenciem um recurso, uma alternativa é estabelecer uma referência global, que atravesse as fronteiras das máquinas. Exemplo: URL (baixa complexidade), Memória compartilhada entre processos (referência global significa memória compartilhada). Pode haver várias combinações entre vinculação processo-recurso e recurso-máquina. Exemplos: - Processo admite que a memória pode ser compartilhada entre processos (recurso fixo, vinculação de valor). - Bibliotecas de tempo de execução (recurso amarrado, vinculação de valor). A complexidade está ligada aos tipos de vínculo processo-recurso e recurso-máquina. - Recursos não ligados: Melhor solução é copiar ou mover o recurso para o novo destino. - Vinculações por tipo: A solução é vincular novamente o processo a um recurso do mesmo tipo disponível no local Migração em Sistemas Heterogêneos A migração em sistemas heterogêneos requer segmento de código que possa ser executado em cada plataforma e um segmento de execução pode ser adequadamente representado em cada plataforma. O efeito global é migrar sistema operacional inteiro, em vez de migrar processos. 13