Resumo sobre Sistemas Distribuidos

Boa tarde a todos!

Estou estudando e fazendo um breve resumo sobre Sistemas Distribuidos, isso me ajudará a estudar e possivelmente ajudará vocês e quem sabe não tirará duvidas de alguém. Enquanto espero meu lanche do MC Entrega chegar. Tenho um exame hoje. Esse tópico é melhor entendido para quem ja tem algum conhecimento de redes de computadores.

Bom nesse POST farei um resumo simples sobre :

• THREADS
• Virtualização
• Multicast
• RMI
• RPC
• Sincronismo usando Relógios Físicos e Lógicos
• Exclusão Mútua

lembrando que estes são resumos das idéias principais sobre cada tópico, todos eles são muito mais abrangentes, mas serve para lembra-los caso você esteja se preparando para uma prova. O que é o meu caso.

SISTEMAS DISTRIBUIDOS

Em um sistema não distribuido nós temos um único fluxo de programa. Isso muitas vezes pode ser um problema. Uma das soluções para esse problema é a utilização de Sistemas Distribuidos, objetivo principal é passar a impressão ao usuário que o sistema funciona com um único fluxo embora ele possa estar executando várias aplicações em locais diferentes. Por exemplo:

Quando um usuário faz uma requisição para um servidor de arquivos, o servidor caso fosse não distribuido ficaria travado até que recebesse a leitura da requisição, em um sistema distribuido ele pode executar outras tarefas ao mesmo tempo que aguarda a requisição do usuário.

Vantagem de um Sistema Distribuido:

• Maior Throughput (melhor vazão)
• Ganho de desempenho

THREADS

Em um sistema não distribuido Threads de um mesmo processo ocupam a mesma região de memória, leem, escrevem e mudam pilhas de dados.

A proteção é feita pela aplicação.

Podem se encontrar nos estados:

"executando","bloqueado","pronto" ou "finalizado" e rodam sobre o RunTime System que é o gerenciador de Threads.

Threads em um sistema Distribuido tem a vantagem de poder bloquear um sistema sem precisar bloquear o processo inteiro.

Mantém múltiplas execuções lógicas ao mesmo tempo.

Resumo de Servidores MultiThread

No caso de um Servidor totalmente CPU Bound (que utilizam maior parte do tempo leitura e uso de CPU - I/O) existem um aumento muito considerável de complexidade sem melhora do desempenho.

Em servidores MultiThread existe um esquema de Hierarquia, Thread despachante e Thread Operario. A thread despachante é responsável por receber solicitações do servidor e despachar a requisição para uma das threads operarias existentes que esteja livre. A thread despachante pode também executar tarefas além dessa.

Resumo de Virtualização

Para recordar sobre virtualização lembrem-se que virtualizar é a arte de "Enganar" o usuário, esse conceito serve basicamente pra quase tudo em sistemas distribuidos. Pensando em Sistema Operacional quando executamos um arquivo de musica num player e usamos o bloco de notas temos a impressão de que o Sistema é Multitarefa, ou seja, esta executando varias coisas simultaneamente, a idéia de Thread é bem parecida, mas na verdade isso é uma ilusão causada pela rápida execução de escalonamento de processos na CPU. O objetivo da virtualização é "fingir" que determinado recurso está replicado.

(Péeeeeeeeeee - *interfone* ... chegou meu lanche... breve pausa

Opa daqui eu continuo engordurando meu teclado enquanto como batatinha e estudo hehe)

Estende ou substitui uma interface existente de modo a imitar o comportamento de um determinado sistema.

Multicast

antes de mais nada quando se lê "cast" tente enteder em algum tipo de comunicação, nesse caso estamos falando de comunicação entre grupos de processos, nós temos o Unicast (um-pra-um) Multicast(muitos para muitos) e o Broadcast(um para muitos).

No caso de um grupo Multicast os membros do grupo são todos transparentes, um envio de mensagem multicast não garante ordem na entrega, ou seja, uma mensagem envia M1 e logo após M2 e M3, pode ser recebida M2,M1,M3.

Porém a Infraestrutura Multicast provê para um Sistema Distribuido maior tolerãncia a falhas baseado em replicação (na verdade, não que ele implique que o sistema tenha uma maior tolerancia, e sim que ele serve para sistemas que tenha maior tolerancia), encontro e registro de serviços, melhor performance tambem através de replicação e a propagação de notificação de eventos.

Um IP multicast é um endereço de internet Classe D e é naturalmente UDP.

Datagramas são enviados passando IP e porta através de sockets.

(ai caracas grudou uma alface no meu dente ... arhhgg)

Um computador faz parte de um grupo multicast se pelo menos um dos seus processor tenha um socket pertencente ao grupo. Como foi dito a desvantagem do multicast é a ordenação não garantida, além da entrega também não ser garantida e também a omissão de falhas.

Quando se lê sobre UDP/Multicast logo pensamos, pra que serve um sistema que não me garante entrega, pois bem, lembrem-se para tudo sempre há uma utilidade, no caso de Streams de video e audio, radioweb, etc. Tem muita utilidade, pense num jogo de futebol sendo comentado pelo galvão bueno, se um dos pacotes tinha com uma palavra do que ele disse seja extraviado e não chegue ao destino, uma falha durante a transmissão,se perdemos aquele instante não iremos correr atras para saber oq foi que não entedemos.

RMI - Remote Method Invocation

Objetod Distribuido podem adotar arquitetura Cliente/Servidor. Nesse caso Clientes invocam metodos dos servidores via RMI.

Em uma arquitetura RMI alguns objetos podem receber uma invocação remota, todos os tipos desse objeto tem uma interface que servirá para o Cliente saber como invocar aquele método. Tipicamente RMI é cliente/servidor.

O intuito aqui é dar uma prévia então seguem apenas algumas das classes mais importantes do RMI:

• RMI REGISTRY - classe naming;
• rebind - registra por nome;
• bind - tenta registrar o nome, caso já exista retorna um erro;
• unbind - remove um nome;
• remote loockup - busca por objeto remoto.

RPC - Remote Procedure Call

Importante:

Aspectos -> IDL (Linguagem de Definição de Interfaces)

Passagem de parametros podem ser: in , out ou in/out

Passagem de exceções

binding

modelo de falhas e interações entre Cliente e Servidor

Multiprogramação

Segurança(autenticação, controle de acesso...)

SINCRONIZAÇÂO

Utiliza-se para sincronização o esquema de relógios físicos e lógicos. Para se ter uma

idéia de quando utiliza-se cada um deles pense da seguinte forma:

Quando há um servidor de tempo utiliza-se o relógio físico com algoritmo de Cristian, se não há servidor

de tempo, utiliza-se relógio físico com algoritmo de Berkeley.

Caso o horario em si não seja importante, entao utiliza-se relógios lógicos.

Breve definicações sobre relógios lógicos:

IAT - Hora Atômica Internacional

UTC - Hora Coordenada Internacional

Utilizam-se também um broadcast por estações de rádio: WWV e satélites (GPS).

Resumo do Algoritmo de Cristian:

Basicamente os computadores ligados entre sim vão repassando as horas um ao outro para atualização.

Imagine que o servidor de Horas passe o horario ao PC1, cada vez que o horario é passado

o computador atualiza o seu horario incrementado ao valor de hora recebido um valor de delay da

transmissão. Sendo assim o PC1 atualiza seu relógio e passa o horario ao PC2, que repete o processo.

até que todos os computadores estejam atualizados e sincronizados.

Resumo do Algoritmo de Berkeley:

Quando em uma rede interna não há um servidor de horas, é eleito um Master da rede que iniciará

a coleta dos valores de relógios, ele então ao receber todos os valores cria uma média de horas e envia

uma mensagem ao outros do grupo informando o quanto este deve ajustar seu relógio.

Caso o Master da rede caia, outro é eleito.

Sobre Relógios Lógicos

Nem sempre é possivel utilizar relógios, ao muitas vezes apenas não convém. Nesses casos utilizam-se

algoritmos que indicam após distribuir as tarefas qual tarefa precisa ser executada antes.

Sincornizando apenas as ordens de execução. Existem os algoritmos de Lamport e uma melhoria deste

o relógio vetorial.

Exclusão Mútua

Em um conjunto de processos existem problemas para quando mais de um usuário/sistema que utilizar um

recurso, ou alterar algum arquivo. As soluções para isso são os servidores Centralizados, Completamente Distribuidos

sem topologia ou Completamente Distribuidos com topologia em Anel.

Algoritmos distribuidos são os de Ricart e o de Agrawala:

Processo precisa de uso exclusivo e envia uma mensagem a todos do grupo pedindo

liberação, quando todos dão OK ele utiliza.

Token Ring

A rede tem uma topologia lógica em anel com um Token rodando na rede, aquele de

posse do token, caso queira fazer uso da região critica, tem a liberação.

Algoritmos de Eleição

Algoritmo do Valentão (Bully)

Basicamente os computadores tem cada um o seu ID. Quando o coordenador oficial cai, um PC

qualquer que perceba inicia uma eleição dizendo que será o novo coordenador, se ninguém responder

ele assume, caso alguém com um ID maior responda o de ID maior avisa que ele será o novo. E assim

sucessivamente até que o maior ID realmente assuma o Posto. Caso o Coordenador Oficial volte e retoma

seu posto de volta.

Algoritmo em Anel.

Funciona como o valentão mas a mensagem é passada de uma a um conforme o anel lógico, quando

a mensagem retorna a quem começou verifica quem insiriu o maior ID e recomeça a passar as mensagem

para indicar quem é o novo coordenador.

(acabou meu tempo... bora fazer o exame, depois eu posto mais sobre Banco de Dados dsitribuidos)

Valew. Fui e bons estudos!