Sistemas Distribuídos e Paralelos

Sistemas Distribuídos e Paralelos Sistemas peer-to-peer Ricardo Mendão Silva Universidade Autónoma de Lisboa r.m.silva@ieee.org December 3, 2014 Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 1 / 23

Outline 1 Introdução 2 Middleware peer-to-peer 3 Routing Overlay 4 Caso de estudo: BitTorrent Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 2 / 23

Introdução O objectivo dos sistemas peer-to-peer (P2P) é permitir a partilha de dados e recursos em larga escala, eliminando qualquer requisito de gestão separada de servidores e infraestrutura associada. O objectivo de expandir serviços populares adicionando mais servidores, gerindo e recuperando falhas e conectividades, embate sempre na limitação física quer da capacidade dos servidores quer na capacidade das ligações a estes. Os sistemas P2P, por outro lado, suportam serviços e aplicações distribuídas utilizando dados e recursos computacionais disponíveis em cada máquina ligada ao sistema. Deste modo, mais máquinas ligadas, mais recursos disponíveis. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 3 / 23

Introdução Os sistemas cliente-servidor, que temos visto até aqui, gerem e fornecem acesso a recursos, tais como, ficheiros, páginas web ou qualquer outro objecto, localizados num servidor ou num conjunto de servidores ligados entre si. Com uma arquitectura centralizada são necessárias uma série de decisões acerca da localização dos recursos e gestão do hardware, sem nunca se resolver por completo o problema da falta de escalabilidade, uma vez que o serviço é sempre limitado pela capacidade dos servidores e das ligações da rede a estes. Em contraste, os sistemas P2P fornecem acesso a recursos localizados em computadores distribuídos na rede, seja na Internet ou numa rede corporativa. O aspecto chave dos sistemas P2P são os algoritmos para posicionamento e obtenção da informação, considerando a distribuição do sistema. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 4 / 23

Introdução O objectivo passa assim por prestar um serviço totalmente descentralizado, auto-organizado, com balanceamento dinâmico de carga de processamento e armazenamento em cada máquina participante, sempre que alguma máquina entra ou sai do sistema. Os sistemas P2P partilham as seguintes características: Cada utilizador do sistema contribuí com recursos para o mesmo. Mesmo contribuindo com pesos diferentes, cada nó do sistema tem as mesmas funcionalidades e responsabilidades. A correcta operação não depende da existência de qualquer sistema central. Podem ser desenhados para oferecer graus diferentes de anonimato para os fornecedores e consumidores de recursos. Partilham o aspecto chave que é a escolha de um algoritmo para a implantação dos dados pelos diferentes hosts, e respectivo consumo, garantindo balanceamento de carga e disponibilidade. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 5 / 23

Introdução Os computadores e redes de ligação pertencentes e geridas por diferentes utilizadores e organizações são recursos voláteis. Não existe garantia que os donos desses recursos os mantenham ligados e livres de falhas. Como tal, a disponibilidade dos processos e computadores participantes num sistema P2P é imprevisível. Os serviços P2P não podem confiar em acessos garantidos, mas podem ser desenhados para que a probabilidade de falha num acesso a um recurso seja a menor possível. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 6 / 23

Introdução Apesar de nos anos 80 já existirem alguns pequenos sistemas P2P, o potencial deste modo de interacção só se tornou real a partir do momento que o número de utilizadores com ligações de banda larga à Internet se massificou, permitindo que partilhassem recursos próprios de modo eficiente (+-2004). Existem três gerações de sistemas P2P que podemos identificar como os seguintes: A primeira geração surgiu com o lançamento do Napster. A segunda fase focou-se na partilha de ficheiros oferecendo grande escalabilidade, anonimato e tolerância a falhas, com o lançamento do Freenet, Gnutella, Kazaa e BitTorrent. A terceira fase surgiu com o lançamento de camadas de middlewares genéricos de gestão de recursos distribuídos à escala global (Pastry e Tapestry). Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 7 / 23

Introdução Middlewares As plataformas de middleware P2P foram desenhadas basicamente para pegar nos recursos (objectos de dados, ficheiros, etc..) e distribuí-los por um conjunto de computadores, dispersos pela Internet, e para encaminhar mensagens para estes em nome dos clientes. Deste modo, os clientes são libertados de qualquer decisão sobre o posicionamento dos recursos, bem como de manter qualquer informação sobre a localização dos dados que necessitam. Ao contrário da segunda geração, esta terceira geração oferece ainda garantias de entrega em pedidos limitados a um determinado número de hops. Estes middleware colocam réplicas dos recursos nos hosts disponíveis de forma estruturada, considerando a sua disponibilidade, confiabilidade e requisitos de balanceamento de carga e localização dos dados e do uso dos mesmos. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 8 / 23

Introdução Middlewares Nestes middlewares os recursos são globalmente identificados (GUIDs), identificação que resulta de uma hash de segurança, calculada com base no estado de parte ou do todo dos recursos que identifica. O uso da hash de segurança torna os recursos auto-certificados, uma vez que os clientes ao receberem determinado recursos podem verificar a validade da hash. Mantendo-se o estado de um recursos, a hash permite garantir que os nós não alteraram o conteúdo de certos recursos indevidamente. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 9 / 23

Introdução Middlewares A utilização de sistemas P2P em aplicações com elevados requisitos de disponibilidade requerem um desenho cuidado, de modo a evitar que todas as réplicas de um determinado objecto estejam simultaneamente indisponíveis. Existe o risco dos objectos estarem guardados em máquinas pertencentes à mesma entidade, geograficamente próximas, sob a mesma administração, sobre as mesmas ligações à rede, no mesmo pais ou na mesma jurisdição. Se a rede onde o sistema P2P assenta, estiver distribuía por várias organizações, dispersas por todo o globo, o risco de indisponibilidade simultânea é bastante reduzido. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 10 / 23

Introdução Computação distribuída A exploração dos recursos computacionais dos utilizadores finais tem sido assunto de interesse e experimentação em várias áreas. O projecto mais conhecido, como já referimos várias vezes nas aulas é o SETI@home - Search for Extra-Terrestrial Intelligence. O SETI@home pega num fluxo de dados, reparte-os por work units de 107 segundos (+-350Kb) e distribui cada uma para computadores cliente que contribuem voluntariamente com poder computacional. Cada work unit é enviada para 3 ou 4 clientes diferentes, resguardando-se contra nós maliciosos ou erros que ocorram. No caso do SETI, a distribuição das work units é efectuada por um só servidor, responsável por comunicar com cada cliente. Em 2002, cerca de 3.91 Milhões de computadores pessoais tinham participado no projecto, resultando no processamento de 221 Milhões de unidades de trabalho e representando uma média de 27.36 teraflops de poder computacional durante os 12 meses até então. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 11 / 23

Middleware peer-to-peer O problema chave no desenho de sistemas peer-to-peer é fornecer mecanismos que permitam que os clientes acedam aos recursos rapidamente independentemente da sua localização na rede. O Napster utilizava um índice unificado, com os ficheiros disponíveis e o endereço de rede dos host onde estes se encontravam. Os sistemas P2P de segunda geração (Gnutella, Freenet, etc..) utilizavam sistemas de ficheiros com índices particionados e distribuídos, apresentando cada aplicação a sua própria solução. Em contra-partida, os middleware P2P são desenhados para responder à necessidade de implantação automática e consequente posicionamento do objecto distribuído. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 12 / 23

Middleware peer-to-peer Requisitos funcionais A função os middleware P2P é a de simplificar a construção de serviços que são implementados transversalmente por vários hosts num sistema amplamente distribuído. Para alcançar tal objectivo, o middleware deve permitir que os clientes localizem e comuniquem com qualquer recursos individual tornado disponível a um serviço. Outro requisito importante inclui a habilidade para adicionar e remover recursos sempre que se adicionam ou removem hosts ao serviço. Como qualquer middleware, os middleware P2P devem oferecer interfaces de programação simples, que devem ser independentes do tipo de recursos que a aplicação manipula. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 13 / 23

Middleware peer-to-peer Requisitos não-funcionais Para operarem eficientemente os middleware P2P devem ainda suportar os seguintes requisitos não-funcionais: Escalabilidade global: Um dos objectivos principais dos sistemas P2P é o de explorarem os recursos de hardware em larga escala. Como tal, os middleware P2P devem suportar aplicações que acedem a milhões de objectos em dezenas ou centenas de milhares de hosts. Balanceamento de carga: A performance de um sistema desenhado para explorar um grande número de computadores depende de uma distribuição de carga equilibrada entre estes. isto pode ser alcançado pela implantação aleatória de recursos, juntamente com as réplicas dos recursos mais utilizados. Optimização para interacções locais entre peers vizinhos: A distância na rede entre hosts que interagem entre si, tem um impacto substancial na latência das interacções. A carga da rede é outro factos que também contribui para o aumento dessa latência.como tal, o middleware P2P deve garantir a implantação dos recursos o mais próximo possível dos nós que os irão consumir. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 14 / 23

Middleware peer-to-peer Requisitos não-funcionais Para operarem eficientemente os middleware P2P devem ainda suportar os seguintes requisitos não-funcionais: Acomodação para disponibilidades altamente dinâmicas: A maioria dos P2P são constituídos por hosts que são livres para entrar e sair do sistema a qualquer momento. Nem as máquinas, nem a rede é gerida por uma única autoridade e, como tal, não é possível garantir a fiabilidade ou participação continua no fornecimento de um serviço. O maior desafio é conseguir manter um serviço up-and-running nestas condições. Sempre que um determinado hosts deixa um serviço, seja voluntariamente ou não, o sistema deve detectar e re-balancear a carga pelos restantes participantes. Segurança dos dados num ambiente altamente heterogéneo: Num sistema à escala global a confiança e segurança deve ser construída com base na autenticação e mecanismos de encriptação que garantam a integridade e privacidade da informação. Anonimato, não-repúdio, resistência à censura: Em muitos casos o anonimato tanto para quem possuí o recurso como para quem o pretende é uma preocupação legitimada pela preocupação de censura. Ricardo Mendão UmSilva requisito (UAL) é que os Sistemas hosts Distribuídos que possuam e Paralelos determinado December recurso 3, 2014possam 15 / 23

Routing Overlay Nos sistemas P2P existe um algoritmo distribuído conhecido como routing overlay que tem a responsabilidade de localizar nós e objectos. O nome routing overlay provem do facto de o middleware ser conhecido como uma layer, juntamente com o facto de que a acção o algoritmo é a de encaminhar pedidos de qualquer cliente para um host que contenha o objecto para o qual o pedido é endereçado. O objecto de interesse pode estar localizado em qualquer local e consequentemente ser re-alocado para qualquer lugar, sem intervenção do cliente. O routing overlay garante que qualquer nó pode aceder a qualquer objecto através do encaminhamento de cada pedido por uma sequência de nós, explorando o conhecimento de cada nó intermédio para localizar o objecto destino. Os sistemas P2P geralmente implantam múltiplas réplicas dos objectos para garantir maior disponibilidade. Nesse caso, o algoritmo mantem conhecimento de todas as localizações das réplicas, entregando o pedido ao nó que contem a réplica mais próximo. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 16 / 23

Routing Overlay As principais tarefas do algoritmo routing overlay são: Encaminhamento dos pedidos de objectos: Um cliente que deseje invocar uma operação num objecto, submete um pedido ao routing overlay incluíndo o GUID desse objecto. Este, por sua vez, encaminha o pedido ao nó que contenha uma réplica do objecto. Inserção de objectos: Um nó que pretende colocar um novo objecto disponível no sistema P2P deve gerar um GUID para esse objecto e anuncia-lo ao routing overlay, que depois garante que esse novo objecto é alcançável por outros clientes. Eliminação de objectos: Quando os clientes pedem a remoção de objectos do serviço, o routing overlay é responsável por torna-los indisponíveis. Adição e remoção de nós: Os nós podem juntar ou deixar o serviço. Quando um nó se junta, o algoritmo routing overlay redistribuí as responsabilidades do sistema também por este novo nó. Quando um nó deixa o serviço, o routing overlay distribui as responsabilidades que esse nó tinha, pelos restantes. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 17 / 23

Routing Overlay O GUID de um objecto é calculado através do todo ou parte do estado do objecto, utilizando uma função que devolve um valor, com alta probabilidade de ser único. A unicidade é depois garantida pela pesquisa de objectos com o mesmo GUID. Uma função hash tipo SHA-1 é utilizada para gerar o GUID. Como estes identificadores são utilizados para determinar a localização dos objectos e devolve-los, os sistemas routing overlay são descritos como distributed hash tables (DHT). Exemplo de funções da API DHT (middleware Pastry): Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 18 / 23

Routing Overlay Uma versão ligeiramente mais flexível que o DHT é a camada distributed object location and routing (DOLR). Com DOLR os objectos podem ser guardados em qualquer lado, com esta camada a ser responsável por manter e mapear entre os GUIDs e os endereços dos nós que contêm as réplicas dos objectos requeridos. Com DHT a localização das réplicas é decidida pelo próprio modelo, enquanto que no DOLR a localização das réplicas é exterior ao modelo, sendo este apenas notificado dos endereços de cada host que contem uma réplica através da operação publish(). Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 19 / 23

Routing Overlay Porque necessitamos de um nível superior de encaminhamento? O encaminhamento IP é demasiado antiquado para os sistemasp2p. IP Escala O IP tem o limite de 32 bits na versão 4 ou 128 bits na versão 6, estando hierarquicamente estruturado. Balanceamento de carga Dinâmica rede da A carga é balanceada nos routers com base na topologia da rede e associada aos padrões de tráfego. As tabelas de encaminhamento IP são actualizadas assincronamente numa base best-effort com constantes de tempo na ordem de 1 hora. Encaminhamento no middleware Com a utilização de GUIDs para ientificar recursos o volume possível é muito mais que 128 bits. A localização dos objectos pode ser aleatória e como tal os padrões de tráfego são separados da topologia da rede. As tabelas de encaminhamento são actualizadas sincronamente ou assincronamente com atrasos de fracções de segundo. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 20 / 23

Routing Overlay Porque necessitamos de um nível superior de encaminhamento? O encaminhamento IP é demasiado antiquado para os sistemasp2p. Tolerância a falhas Identificação do target Segurança anonimato e IP A redundância é desenhada pelo gestor da rede, garantindo tolerância na falha de rotas simples. Replicar n vezes tem um custo elevado. Cada IP identifica um nó. O endereçamento só é seguro quando todos os nós são confiáveis. Não existe anonimato. Encaminhamento no middleware Rotas e referências para objectos podem ser replicadas n-vezes, garantindo tolerância a n falhas. As mensagens podem ser encaminhadas para a replica do objecto mais próxima. É possível obter segurança mesmo em ambientes com confiança limitada. Pode ser fornecido um nível limite de anonimato. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 21 / 23

BitTorrent Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 22 / 23

Sistemas peer-to-peer Capítulo X: George Coulouris, Jean Dollimore, Tim Kindberg and Gordon Blair, "Distributed Systems: Concpets and Design", Fifth Edition, published by Addison Wesley, May 2011 ISBN 0-13-214301-1 rmsilva@ual.pt Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos December 3, 2014 23 / 23