Baixe o app para aproveitar ainda mais
Prévia do material em texto
Livros para sistemas distribuídos: Sistemas distribuídos: Princípios de paradigmas (2 edição) A. Tanenbaum e Marten van sete E.d. Pearson Definição de um sistema distribuído: "Um sistema distribuído é um conjunto de computadores independentes, que se apresenta aos seus usuários como um sistema único e corrente". A. Tanenbaum Em outras palavras, é um conjunto de computadores autônomos em conjunto, formam um sistema de grande porte. Capaz de compartilhar recursos e de realizar processamento alto desempenho; Uma importante característica de um sistema distribuído é a sua transparência, isto é, a capacidade de se acessar e utilizar o ambiente distribuído de forma remota, mas como a sensação de um sistema local; A difusão dos sistemas distribuídos se deu na década de 1980, devido à necessidade de compartilhamento de informações, e a possibilidade de expansão dos parques computacionais com custo reduzido. Em um primeiro momento, foi adotado em institutos de pesquisa e, posteriormente, aplicado à indústria; Uma característica atrativa em um sistema distribuído é o fato de não existirem restrições quanto aos computadores que podem fazer parte do sistema. Isto significa que qualquer computador, independente de arquitetura e/ou sistema operacional lide fazer parte do sistema, e ainda operar de forma autônoma. A esta característica, dá-se o nome de heterogeneidade; A heterogeneidade é possível devido a existência de uma camada de abstração denominada “middleanare”, responsável por tratar as diferenças entre os diferentes componentes do sistema. Tipos de sistemas computacionais: Sistemas locais: São definidos como aqueles sistemas cuja gerência é realizada localmente, isto é, sem a existência de nenhum tipo de ação essa remoto. É possível realizar processamento paralelo em sistemas locais, através de trocas de mensagens com memória compartilhada; Sistemas paralelos de alto desempenho: são sistemas formados por dois ou mais recursos computacionais homogêneos. A gerência e realizada através de uma rede privada dedicada e a troca de mensagens é realizada por interfaces próprias implementadas; Sistemas distribuídos: a gerência dos recursos heterogêneos é realizada através de uma rede pública e a troca de mensagens é feita através dos protocolos das camadas de rede e transporte do modelo TCP/IP. Requisitos para estabelecer uma conexão origem/destino em um sistema distribuído: 1 endereço IP origem/destino: identificador dos recursos na rede; 2 portas de comunicação: identificador do processo no recurso remoto. Principais diferenlas entre sistemas paralelos e distribuídos: Distribuídos Paralelos Recursos Heterogêneos Homogêneos Comunicação -- -- Redes Pública Privada Sincronismo Inexistente Fundamental Memória Distribuída Compartilhada ou distribuída Distribuição de Recursos Geograficamente distribuídos Local Arquitetura de Sistemas distribuídos O modelo arquitetural de um sistema distribuído representa a disposição em que cada componente está em relação aos demais, e às funções específicas que ficam sob responsabilidade de cada recurso; É importante ressaltar que é recomendado a não existência de um elemento centralizador em um sistema distribuído, pois tal elemento pode representar um ponto único de falha, que procura vir a compreender todo o funcionamento do sistema; No entanto, como iremos ver a seguir, algumas arquiteturas necessitam de um elemento centralizador para propósitos de coordenação dos processos, nesses casos, são necessárias medidas especiais para prevenir e corrigir eventuais falhas nos elementos centralizadores; As principais arquiteturas utilizadas por sistemas distribuídos são: Anárquica Cliente / Servidor Mestre / trabalhador P2P (peer-to-peer) Arquitetura Anárquica: Tipo de arquitetura que considera que todos os recursos que compõem um sistema capaz de realizar processamento das mesmas tarefas. Isto implica dizer que qualquer processo é capaz de solicitar ou de atender requisições de quaisquer outros processos. O problema desta arquitetura se dá quando existem mais recursos do que o sistema como um todo é capaz de gerenciar. Exemplo: Arquitetura Cliente / Servidor: é a arquitetura mais adotada nos sistemas distribuídos. Considera-se a existência de um servidor que deve permanecer sempre ativo e com endereçamento fixo para ser encontrado, receber requisições e; um cliente, que permanece ativo apenas realiza e aguarda o atendimento da requisição. Esta arquitetura depende de um elemento centralizador, uma vez que, geralmente existe um servidor para vários clientes. Exemplo: Arquitetura Mestre/Trabalhador: Arquitetura que envolve a existência de dois ou mais recursos (Ou processos), que um deles é o responsável pela coordenação e os demais, para o processamento. Considera-se ainda que todos os processos são iguais e capazes de se comprometer tanto com mestres, quanto com trabalhadores. Exemplo: Arquitetura P2P (Peer to Peer): é similar à arquitetura anárquica. No entanto, existem alguns recursos que são “eleitos” Super Peers. Estes recursos são responsáveis por coordenar um conjunto de recursos subordinados a ele e por realizar a comunicação com os demais Super Peers. Exemplo: Chamadas de procedimentos remotos Processos remotos podem estabelecer uma comunicação entre si para realizar trocas de mensagens; Premissa. A comunicação entre processos remotos, em sua forma mais primitiva, é feita através de um par de sockets, sendo um cliente e um servidor. Tal abordagem é a mais adotada para prover a comunicação entre processos em um sistema distribuído. Um socket é uma implementação lógica de um protocolo na camada de transporte. Sua implementação é complexa serve como base para outras técnicas mais simples de comunicação entre processos distribuídos. Uma chamada de procedimento remoto (ou RPC – Remote Procedure Call) promove uma abstração do uso de sockets para a comunicação entre processos distribuídos; Uma chamada RPC precisa tratar dois problemas específicos: Os processos Em Questão encontram-se em maquinas diferentes e executam sobre espaço de memória diferentes; É necessária a passagem remota de parâmetros e dos resultados. A chamada de procedimento remoto pode ser feita por valor ou por referência: No caso de passagem por valor, basta chamar o método com o respectivo valor como argumento; Em chamadas por referência, é passado um ponteiro como argumento. Se o procedimento remoto usa este ponteiro para armazenar algo, ele opera sobre a posição de memória para a qual o ponteiro aponta. Caso contrário, um erro deve ser tratado. Formas de comunicação entre processos remotos Síncrona: Em uma comunicação onde há um processo X (cliente) e um Y (servidor), o processo fica em espera entre o momento em que envia a mensagem de solicitação até o momento em que recebe a mensagem de resposta Exemplo: Assíncrona: Em uma comunicação onde há X (cliente) e um Y (servidor, o processo X, ao fazer uma requisição para o servidor, continua sua execução independente de receber a resposta. Exemplo: Ordem de Eventos Entre Processos Assim como em sistemas operacionais locais, onde dois ou mais processos podem concorrer por um mesmo recurso, também há este problema em sistemas distribuídos. Tal problema se torna mais grave quando a concorrência envolve instruções de escrita; Nos sistemas locais, existem duas formas que resolvem esta questão de maneira satisfatória: Bloqueio em nível de hardware (barramentos compartilhadosde memória); Bloqueio em software (sincronismo através do uso de semáforos); Em sistemas distribuídos, torna-se impraticável a adoção da estratégia por bloqueio em nível de hardware uma vez que processos remotos não possuem tal privilégio Como solução, resta a implementação deste controle através do uso de semáforos e da aplicação do conceito de exclusão mútua; Existem duas estratégias para se implementar o conceito de exclusão mútua; Baseado em fichas, com o objetivo de evitar deadlocks e starvation; Baseado em permissões, onde um processo deve pedir permissão aos demais para utilizar um recurso. Devido à complexidade envolvida na comunicação necessária entre todos os processos para a solicitação de permissão, a segunda estratégia é considerada pouco eficiente. Sendo assim, para utilizar a estratégia baseada em fichas, são consideradas as seguintes premissas: Existe, para cada processo distribuído, uma seção crítica relativa ao acesso do recurso compartilhado; Somente um processo pode estar dentro da seção crítica por vez; Nenhuma hipótese deve ser levantada a respeito da velocidade/quantidade dos processadores/processos; Nenhum processo executado fora da seção crítica pode bloquear ou impedir que outros processos entrem em seção crítica, deadlock. Nenhum processo deve esperar indefinidamente para entrar em ação crítica. Starvation. DeadLock: O processo entra em execução, mas não finaliza e bloqueia o recurso compartilhado. Starvation: O processo se encontra na fila de pronto, mas não consegue entrar em execução por falta de recursos. Exclusão mútua ou Mutex: É uma estratégia de controle implementada de forma a bloquear um recurso compartilhado enquanto este se encontra em utilização. Solução do Problema do Produtor/Consumidor com Semáforo. Empty/Full = Estado do Buffer. //Variáveis globais Semaphore mutex=1 Semaphore Empty = N Semaphore Full = 0 //consumidor Comsumer ( ) { Int iten; While (true) { //início secção critica Down (full); Down (mutex); Remove_iten (iten); //Recurso Compartilhado Up (mutex); UP (empty); //fim seção crítica Consume_iten(iten); } } //produtor Producer( ) { Int iten; While (true) { //inicio seção crítica Down (empty) Down (mutex) Put_iten (iten); //recurso compartilhado Up (mutex); Up (full); //Fim seção crítica } } Algoritmos de Eleição de processos coordenadores Tanenbaum sec. 6.5 Nos sistemas distribuídos, em algumas situações, é necessário que exista um processo responsável por realizar funções específicas dentro do sistema. A estes processos, dá-se o nome de coordenadores. Para que seja possível existir um processo coordenador, admite-se que todos os processos do sistema são iguais. Isto é, todos os processos são coordenadores em potencial. O objetivo dos algoritmos de eleição é garantir que sempre exista um processo coordenador no sistema. Para o correto funcionamento dos algoritmos de eleição acontecer, são adotadas algumas premissas sobre os processos participantes: Cada processo possui um número identificador exclusivo no sistema. Todos os processos conhecem o número identificador de todos os demais processos do sistema. Os processos não conhecem aqueles que não estão em funcionamento ou temporariamente inativos. Partindo destas premissas, um algoritmo de eleição irá garantir que uma eleição será iniciada ao se identificar a queda do processo coordenador, e irá concluir com a escolha de um único novo processo; Principais algoritmos de eleição: Tradicionais _Algoritmo do Valentção (Bully algorithm) _Algoritmo do Anel (Ring Algorithm) Grande escala _Peer-to-peer Algoritmo do Valentão Quando qualquer processo P identifica a queda do processo Coordenador, P inicia uma eleição da seguinte forma: P envia uma mensagem eleição a todos os processos com identificador maior do que P. Se nenhum processo responder dentro de um limite de tempo, P vence a eleição e se torna o novo coordenador. Se um ou mais processos de maior identificador responder, esta resposta é enviada a todos os processos com identificador menor que o dele, e o de maior identificador se elege como o novo coordenador. Algoritmo do anel Para este algoritmo, é necessária a adoção de uma nova premissa: há uma ordenação, física ou lógica entre os processos, de forma a permitir que cada processo conheça o seu sucessor. Sendo assim: Quando um processo P identifica a falha do coordenador, ele envia uma mensagem eleição ao seu sucessor contendo o seu próprio identificador Cada processo que recebe a mensagem de eleição inclui o próprio ID e encaminha ao seu sucessor. Em algum momento a mensagem retorna a P. Quando isto ocorre, P verifica qual o maior ID da lista e o envia para todos os processos, elegendo-o como novo coordenador.
Compartilhar