Anotações – Padi

System Models • Plataforma – camada inferior que oferece serviços e suporte às camadas superiores • Middleware – camada intermédia que mascara a heterogeneidade das diversas plataformas. Esta camada oferece, às aplicações,

um conjunto de serviços de comunicação, persistência de dados, etc. A existência de um middleware permite que as aplicações sejam mais simples e rápidas de construir. Considera-se que é um software de suporte a aplicações distribuídas (SAD)

o Limitações do middleware: Maior overhead – introduz por vezes verificações desnecessárias ou repetidas pela aplicação Oculta alguns aspectos que podem ser relevantes para a aplicação

System architectures • Cliente-servidor

o 2 niveis nível 1: interface com utilizador (cliente) nível 2: servidor intermédio que executa a lógica da aplicação e armazena os dados

o 3 niveis nível 1: interface com utilizador (cliente) nível 2: servidor intermédio que executa a lógica da aplicação nível 3: servidor que armazena os dados

• Mainframe – vários terminais (apenas visualizam a informação) ligados a um super-computador • Peer-to-peer – partilha de recursos de forma distribuída e em larga escala

Fundamental models

Interaction model Define a performance do sistema e dos canais de comunicação.

• Síncrono – modelo onde são definidos limites temporais para a entrega das mensagens e execução; o drift do relógio de cada processo é bem conhecido, mensagem de rede tem limite máximo de tempo, tempo de execução de um processo tem limite inferior e superior de tempo. Num sistema síncrono é possível, por exemplo, detectar falhas de processos usando timeouts

• Assíncrono – neste modelo não existem limites temporais (ex: internet) • Desempenho do Canal de Comunicação (latência, throughput, largura de banda, delay jitter)

Síncrono vs Assíncrono

• As soluções algorítmicas que sejam válidas para sistema assíncronos são também válidas para sistemas síncronos. • Sistemas assíncronos são mais abstractos e gerais. • Sistemas síncronos são mais fáceis de tratar, mas determinar limites realistas pode ser díficil ou mesmo impossível

Failure model • Classifica as falhas dos processos e da comunicação. • Falhas:

o Fail-stop – halt de processo detectado pelos outros processos o Crash – halt de processo não detectado pelos outros processos o Omission – drop da mensagem no canal o Send/Receive omission – a mensagem não é enviada para o canal/processo o Bizantine – falha arbitrária

• Tolerância a faltas é conseguida através de recuperação e redundância. Não esquecer que os sistemas distribuídos devem manter-se disponíveis mesmo perante falhas dos seus constituintes.

Security model Identifica os possíveis perigos para os processos e para os canais de comunicação. Como ataques denial of service.

Distributed objects and remote invocation • Remote Procedure Call ou RPC (ou function-shipping) • Data-shipping – descarrega os dados para aplicação cliente • Code-shipping – descarrega o código para aplicação cliente (ex: JAVA applets) • Agente móvel - descarrega o código + dados para aplicação cliente • Publicação-Subscrição

Tempo • Happened before • Skew – diferença entre dois relógios • Drift – desvio em relação ao relógio de referência • Um relógio hardware é correcto se o seu drift rate (ritmo de desvio por unidade de tempo) é limitado: p >0.

Sincronização de relógios

Sistema síncrono • P1 envia o seu tempo para P2 • P2 actualiza o seu relógio para t2=t1+(max+min)/2 • Incerteza u = Max-min • O skew é <= u/2

Algoritmo de Cristian (sistema assíncrono) Um servidor S recebe informação de uma fonte UTC:

• P envia o pedido para S • P contabiliza o RTT (Tround) • P ajusta o seu relógio para t+RTT/2 • Precisão = +- (RTT – 2min)/2 • Desvantagem: utiliza apenas um servidor, pode levar à indisponibilidade do serviço • A solução consiste em usar um grupo de servidores

Algoritmo de Berkley Permite fazer a sincronização interna de um grupo de computadores

• O master faz poll aos slaves e obtem os seus tempos • Usa RTT pra estimar os tempos de cada slave (como no Cristian) • Envia um valor de ajuste (positivo ou negativo), ponderado com a média dos tempos obtidos • Se o master falhar é preciso eleger um novo entre os servidores disponíveis

NTP • Reconfigurável quando ocorrem falhas(ex: servidor que perde ligação à fonte UTC torna-se secundário; servidor que perde

ligação ao primário pode ligar-se a outro primário) • Modos de sincronização:

o Multicast (vocacionado para uma rede lan) Servidor faz lan multicast para outros servidores que ajustam o seu relógio assumindo um delay (não muito

preciso) o Invocação remota (analogamente ao algoritmo de Cristian)

Servidor aceita pedidos de outros Responde com o seu tempo actual Útil se não houver multicast hardware

o Simétrica (maior precisão) Pares de servidores trocam mensagens que contem informação sobre o tempo Usado quando é necessário maior precisão

• Usa UDP (em todos os casos) • Cada mensagem leva os timestamps de eventos recentes • Servidor receptor anota o momento da recepção • No modo simétrico pode haver um delay significativo entre mensagens • É possível obter precisão de dezenas de milissegundos na internet e 1 milissegundo em LANs

Tempo lógico

Relógios Lógicos de Lamport Utiliza tempo lógico para ordenar eventos em vez de contar o tempo real. Um relógio lógico é um contador (software) monotónico (não é preciso dispor de um relógio físico nem se relaciona com tal)

• Cada processo p tem um relógio lógico L, inicializado a zero que é usado para carimbar (timestamping) os eventos. • Eventos concorrentes (ex: A e E) • A relação happened-before é transitiva • Eventos com relação causal - happened-before (ex: B->C) • Contador numérico • Para ordenar T iguais pode-se usar o par (T,pi) onde pi é o índice do processo

Relógios vectoriais Surgem para colmatar desvantagem do relógio lógico de Lamport:

• L(e) < L(e’) não implica que e happened before e’ Relógio vectorial V no processo p é um array de N inteiros São usados para carimbar eventos locais e tem aplicação em:

• Protocolos de coerência para dados replicados (e.g Gossip) • Protocolos de comunicação causal (e.g Coda)

• V=V’ sse V[j] = V’[j] para j=1,2,...N • V<=V’ sse V[j] <= V’[j] para j=1,2,...N • V<V’ sse V<= V’ e V !=V’ • cc, eventos são concorrentes

Estado do sistema

• Um corte é consistente sse, para todos os eventos nele contidos, também contem que os que happened-before dele. Portanto

um processo p não pode conhecer eventos que ocorrem no futuro em p. • Um estado global consistente é aquele que corresponde a um corte consistente

Exclusão mútua Pretende resolver problemas de multi-tarefas como acesso a memoria, recursos e dados partilhados.

• Propriedades 1. Safety: um processo de cada vez na região crítica 2. Liveness: pedido para entrar na região crítica irá ser bem-sucedido 3. Causal: A entrada na secção critica deve respeitar a ordem dos pedidos

Servidor central

• Servidor central atribui token de permissão para utilização de recursos e guarda uma fila de pedidos em espera • Satisfaz propriedades 1 e 2, mas não satisfaz 3 (atrasos na rede podem reordenar pedidos) • Desvantagem: servidor é um bottleneck

Ring

• Só o processo em posse do token pode utilizar os recursos • Satisfaz propriedades 1 e 2, mas não satisfaz 3 ( porque processos podem trocar mensagens independentemente da rotação do

token) • Desvantagem: utiliza banda constantemente (o token está sempre a circular); pode levar muito tempo até obter o token (no

pior caso o token tem que dar uma volta completa ao anel – N mensagens); não tolera a falha de um processo (o token pode perder-se para sempre)

Ricart e Agrawala

• Arquitectura p2p • Utiliza multicast – boa performance • Um processo só entra na zona crítica depois de todos os processos responderem positivamente • Satisfaz propriedades 1,2 e 3

Maekawa’s • Semelhante ao Ricart e Agrawala • Os processos são agrupados em conjuntos de votação (que se sobrepõem) • Para obter permissão um processo envia o pedido para os conjuntos de votação • Vantagem: tolera falhas (se o processo falhado não estiver no conjunto de votação) • Desvantagem: deadlock • Satisfaz as propriedades 1,2 e 3

Eleições Algoritmos projectados para designar um processo único de um conjunto de processos com capacidades semelhantes para tomar o controle de certas funções num sistema distribuído. Exemplos de quando este algoritmos são usados: falha do servidor, servidor sai do grupo, o sistema é reiniciado.

Ring 1. Todos os processos são marcados como não participantes 2. Para começar, um processo coloca o seu ID numa mensagem que envia para a rede e marca-se como participante 3. Quando um processo recebe uma mensagem de eleição:

o Se o ID da mensagem > que o seu ID, então reencaminha a mensagem o Se ID da mensagem = ao seu ID, então envia para a rede a mensagem de eleito (com o seu ID) o c.c. e se não é ainda participante, então coloca o seu ID na mensagem e reencaminha

• Desvantagem: não tolera falhas

Algoritmo Bully 1. Para começar um processo verifica se o seu ID é o maior de todos, se sim anuncia a sua “vitória” 2. Cada processo envia para os processos com ID superior ao seu, uma mensagem

o Senão obtiver qualquer resposta em RTT + delta, então anuncia a sua “vitória” o Se obtiver resposta, aguarda a mensagem de vitória de um outro processo

Multicast Comunicação de grupo: enviar e entregar mensagens a mais do que um receptor. Problemas: coordenação – garantir que as mensagens são entregue a um grupo de receptores, entrega ordenada dentro do grupo de membros

IP Multicast • Grupos são dinâmicos • Utiliza UDP – sem garantias de entrega, de ordem, duplicação, etc. • Implementado apenas por alguns routers e em LANs.

Grupos • Fechados - só os membros do grupo podem enviar mensagens para o grupo • Abertos – os membros externos ao grupo podem enviar mensagens para o grupo

Basic Multicast • Garante entrega, a menos que o multicaster crash. • Envia uma mensagem por cada destinatário • Problema: recepção dos acks em simultâneo leva a buffer overflow e consequente perda de acks – leva a mais transmissão de

acks (ack-implosion) • Propriedades:

o Validade – a mensagem é entregue (se não for abaixo) o Integridade – mensagem não sofre alteração e é entregue at-most-once

Basic Multicast sobre IP • Cada processo guarda referente a cada grupo g (onde participa):

o o número da última mensagem recebida (Sg) o o número da última mensagem que entregou do processo q (Rg) o Quando um processo recebe uma mensagem (g, m, S):

Se Sg = Rg + 1, então entrega a mensagem

Se Sg < Rg + 1, então rejeita a mensagem (porque já foi entregue antes) c.c. faltam mensagens, então guarda a mensagem numa queue para entregar mais tarde

Reliable Multicast • Propriedades

o Validade + Integridade + o Agreement – se um recebe, todos recebem

• Para garantir o agreement: o Todos os processos correctos B-multicasts a mensagem para os outros o Se p não R-deliver então é porque não B-deliver – porque os outros também não.

Reliable Multicast sobre IP • É baseado na observação que multicast tem êxito na maiora dos casos.

Ordered Multicast • Assume que cada processo pertence no máximo a um grupo • Propriedades

o Ordem FIFO: First in First Out. o Ordem Causal: se multicast(g,m) -> multicast(g,m’) onde -> é induzido mensagens enviadas entre membros de g

então qualquer processo correcto que entregue m’ deve primeiro m antes de m’. (Ordem Causal implica ordem FIFO)

o Ordem Total: a ordem pela qual um processo correcto envia mensagens é a ordem pela qual todos os outros processos enviam as mensagens

Ordenação das mensagens

Total • A ordem da recepção é igual em todos os processos

FIFO • A ordem da recepção em cada processo respeita a ordem envio de cada processo

Causal • Respeita o happen-before do envio das mensagens

Persistência e Transacções

Suporte de Persistência • Sistema de ficheiros

o Não suporta dados complexos o Não suporta transacções o Independentes da linguagem de programação

• Base de dados relacionais o Simples de usar o Interacção via RPC ou código na BD o Suporte de transacções limitado o Dependente da linguagem de programação o Não suporta dados complexos

• Base de dados orientadas a objectos o Simples de usar o Limitado a ambientes single-vendor/single-server o Não há standard que seja de facto utilizado o Suporta dados complexos o Dependente da linguagem de programação

Transacções • Podem ser centralizadas ou distribuídas • Programação das transacções pode ser manual ou automático • Transacções centralizadas vs distribuídas:

o Centralizadas – as DBMS (database management system) controla a execução das transacções, implementa o controle de concorrência

Surgem dificuldades se os dados acedidos encontram-se em bases de dados distintas o Distribuídas – consiste em várias entidades que colaboram entre si, cliente, servidor e coordenador da transição

• Normalmente usa-se o algoritmo Two-Phase Commit (2PC) para garantir as propriedades ACID o Fase 1 – votação o Fase 2 – terminação

• Transacção automática o Required - que o objecto tenha de ser acedido no âmbito de uma transacção o RequiresNew – análoga a anterior mas é sempre criada uma nova transacção o NotSupported – o objecto é acedido fora de qualquer transacção e se existe uma em curso, é criado um contexto não

transaccional no qual o objecto é acedido o Supports – o objecto é acedido no âmbito da transacção em curso e se não existe transacção em curso, o objecto é

acedido fora de qualquer transacção o Mandatory – o objecto é acedido no âmbito da transacção em curso e caso não haja transacção em curso, gera erro o Never – o objecto é acedido fora do âmbito transaccional e se existe transacção em curso, gera erro

Replicação • Aumento de performance • Tolerância a faltas

o f falhas para f+1 servidores o f falhas para 2f+1 servidores com falhas bizantinas (votação por maioria)

• Aumento da disponibilidade • Problemas com a replicação:

o Transparência o Consistência

Replicação vs Caching • Replicação tem o objectivo principal de tolerar faltas • O caching tem o objectivo principal de aumentar a performance

Modelo arquitectural

• Front-ends tornam a replicação transparente para os clientes • Front-end envia o pedido para um RM específico ou efectua multicast • Fornt-ends:

o Devolve a primeira resposta recebida pelas replicas (maior disponibilidade) o Devolve a resposta com maior consenso (previne falhas bizantinas)

Comunicação de grupo • Interface para adicionar e remover membros • Detecção de falhas • Notifica os membros de alteração do grupo • “Expande o endereço do grupo”

View delivery • Trata cada membro do grupo de uma forma consistente quando o grupo “membership” se altera. • Propriedades

o Ordem - se um processo entrega duas vista por uma determinada ordem, então todos os outros processos do grupo entregam-nas pela mesma ordem

o Integridade – Se algum processo entrega uma vista p do grupo g, então p pertence a g. o Não trivial – Se q se inscreve no grupo e se torna indefinidamente contactável então eventualmente será incluído em

todas as vistas o Se existir partições de grupo, uma vista entregue a uma partição, exclui ser entregue nas outras partições.

View synchronous group • Propriedades:

o Validade – os processos correctos fazem deliver das mensagens que enviaram (se falhar um envio o sender muda a vista)

o Integridade – at-most-once; o sender está na mesma lista o Agreement – se um processo faz deliver numa vista, todos o farão nessa lista

Consistência

Linearizability • A ordem das operações tem de estar de acordo com o instante em que elas ocorreram (tendo em conta todos os utilizadores) • Cópia correcta dos objectos • Ordem global das operações • Implica sequential consistency

Sequential consistency • A ordem das operações deve estar de acordo com a ordem local a cada cliente (cada utilizador vê as suas operações ordenadas) • Cópia correcta dos objectos • Ordem local (a cada utilizador) das operações

Passive primary-backup

1. Request – o FE envia o pedido ao Primary RM 2. Coordination – o PRM efectua as operações pela ordem em que foram pedidas; se a operação já foi executada previamente ele

envia a resposta ao FE imediatamente 3. Execution – o PRM executa a operação e guarda a resposta 4. Agreement – o PRM envia a actualização para as réplicas; as réplicas respondem com ack 5. Response – o PRM responde ao FE que por sua vez responde ao cliente • Pode tolerar falhas

Active replication

1. Request – FE envia um pedido em totally ordered multicast 2. Coordination – o multicast entrega os pedidos pela ordem (total) 3. Execution – os RMS executam o pedido 4. Agreement – não é necessário porque todos executam os pedidos pela mesma ordem (todos chegam à mesma conclusão) 5. Response – o FE recolhe uma ou mais respostas dos RM’s; para tolerar falhas bizantinas pode responder com base na maioria

das respostas • RMs são máquinas de estados • Funciona num sistema síncrono; num sistema assíncrono é necessário haver detectores de falhas

State transfer vs Operation transfer • State transfer – envio do dados de uma réplica para outra réplica (transferência de estado – dados) (ex: DNS) • Operation transfer – envio do registo das operações (ex: Bayou)

o Mais complexo, mas mais flexível na resolução de conflitos e eficiente em termos de quantidade de informação a transmitir

• Solução híbrida •

Scheduling • O objectivo é ordenar as operações para produzirem estados equivalentes nas várias réplicas • Ordenação sintáctica – baseia-se na informação tipicamente temporal (time-stamps)

• Ordenação semântica – explora as propriedades semânticas (comutatividade, idempotencia, transformação operacional, optimistic approach)

Prevenção de conflictos • Single-master vs Multi-master – o Single-master permite maior prevenção porque coordena todas as alterações • Algoritmos pessimistas (previnem bloqueando ou abortando as operações sempre que necessário) • Aumentar a velocidade de propagação de actualizações (ex: Push-transfer) • Dividir os objectos em unidades mais pequenas • Políticas sintácticas (simples e genéricas mas causam mais conflitos) • Políticas semânticas (mais flexíveis mas especificas da aplicação)

Eventual Consistency • “Réplicas irão atingir um mesmo estado após algum tempo” • Schedule equivalence (começam do mesmo estado inicial e produzem o mesmo estado final)

Replica-state convergence

Thomas Write Rule • Cada réplica tem um timestamp associado que indica a data da última alteração • Quando uma réplica se sincroniza com outra, o conteúdo e o timestamp da réplica mais antiga é substituído pela nova • Uma réplica apagada guarda apenas o seu timestamp (e não o conteúdo) – “tombstone” ou “death certificates” • Não detecta conflitos

Two-timestamp algorithm • Extensão do Thomas Write Rule • Guarda adicionalmente o timestamp da última sincronização entre réplicas (é actualizado sempre que as réplicas se

sincronizam) • Se o timestamp de sincronização for diferente, existe conflito • Pode detectar falsos conflitos com mais que duas réplicas

Modified bit Algorithm • Utilizado para sincronização dos PDAs com o PC (ex: Activesync) • Guarda um conjunto de bits associado a cada registo para indicar se o registo foi criado, apagado, modificado • Se o registo do PC e do PDA estiverem ambos com o estado alterado, existe conflito • Quando é feita a sincronização os bits são desactivados (por esta razão não se consegue sincronizar com mais do que uma

fonte)

Detecção e resolução de conflitos • Conflito – quando uma pré-condição não é satisfeita • Divisão do objecto em sub objectos

o Compara o timestamp de cada sub objecto o Compara a hash de cada sub objecto (chunks)

• Lista de objectos modificados (log) • Resolução de conflitos:

o Manual (remover as operações ofensivas do Schedule, decisão do utilizador) o Automática (a aplicação pega nas duas versões do objecto e cria um novo)

Propagação de alterações • Algoritmos:

o Baseados em VV (sistemas de transferência de ficheiros) o Técnicas para sistemas state-transfer (identificam o objecto propagando apenas a parte do objecto que foi modificada) o Controlling Comunication Topology (propagação push-based)

• Técnicas Push-transfer: o Blind flooding

o Link-state monitoring (heurísticas) Rumor mongering – cada site determina o número de duplicados ocorridos para cada operação, e a

propagação de alterações não continua quando esse número excede um limite Directional gossiping – cada site monitoriza o nº dif. de “paths” pelos quais a operação passou)

o Multicast-based (constroem spanning-trees dos sites, sobre as quais distribuem os dados) o Timestamp Matrices (estimar o progresso de outros sites, e fazer “push” apenas das operações que estão em falta)

Garantias de sessão

• Read your writes – assegura que o conteúdo lido de uma replica contem todas as inscritas pelo mesmo utilizador até ao momento.

• Monotonic reads – assegura que as operações de leitura reflectem as alterações (escritas) que foram já lidas em leituras anteriores na mesma sessão

• Writes follow reads – as escritas feita por um utilizador numa réplica são aceites só depois das escritas lidas pelo mesmo utilizador terem sido aplicadas nessa réplica

• Monotnic writes – respeita a ordem das operações de escrita

Gossip

• O objectivo é ter serviços com alta disponibilidade em que os dados estão localizados próximos dos seus utilizadores – o

cliente utiliza o Front-End mais próximo de si • Existem dois tipos de operações:

o Query – só de leitura o Update – só escrita

• Cada FE guarda um vector timestamp (com uma entrada por cada RM da rede) que reflecte a última versão consultada pelo cliente, assim as queries feitas pelo cliente reflecte pelo menos as actualizações que já observou anteriormente

o Em cada operação este vector é enviado ao RM o Em cada resposta um novo vector é “merged” com o vector do FE

• Cada RM guarda vector timestamps (com uma entrada por cada RM da rede) e um log de operações • Os RMs enviam mensagens de update periodicamente (para se manterem actualizadas) – consistência fraca (lazy)

o Quando recebem essas mensagens aplicam os updates estáveis e eliminam os logs antigos • Os clientes podem comunicar entre si (trocando os seus vector timestamps) • Cada cliente tem um serviço consistente a tempo inteiro • Consistência relaxada entre replicas (lazy)

Bayou – replicação optimista • Sistema de base de dados replicável em ambientes móveis • Permite alterações offline e sincronização com outras réplicas • Os updates são “tentative”, ou seja, o sistema pode fazer undo (até certo ponto) e refazer as operações por outra ordem de

modo a chegar a um estado consistente • Cada “update” contem adicionalmente:

o Dependency check o Merge procedure

Sistemas de ficheiros replicados

NFS (Network File System)

• Arquitectura cliente servidor • Servidor é stateless • O paradigma NFS trata as workstations como peers sem distinção entre clientes e servidores. Mas é comum na prática correr

alguns nós como servidores dedicados. • Os clientes fazem cache de páginas dos ficheiros remotos na sua memória (RAM)

o Cada página tem um timestamp que é utilizado para comparar com o do servidor e validar o A validação ocorre quando o ficheiro é aberto ou quando há um cache miss o Os blocos têm um tempo de validade definido pelo cliente, após o qual um acesso ao bloco implica nova validação

perante o servidor o Se uma página é modificada é marcada como “dirty” para ser depois (após t segundos) enviada para o servidor o Não é garantido que as páginas sejam todas “flushed” antes do close do ficheiro

AFS (Andrew File System)

• Quando um ficheiro é aberto o Venus verifica se existe uma cópia válida em cache (em disco)

o Se sim, o ficheiro é tratado como um ficheiro local o Se não, o ficheiro é carregado do servidor para o cliente

• Quando um ficheiro é fechado as (eventuais) alterações são copiadas para o servidor • O cliente é avisado pelo servidor através de um mecanismo de callbacks se um ficheiro (que tem em cache) foi modificado

Coda • Extensão ao AFS; suporta modificação offline dos ficheiros • Os ficheiros são replicados por conjunto de réplicas – VSG (volume storage group)

o Available VSG – conjunto de réplicas acessíveis num determinado instante • Utiliza CVV (vector de timestamp) para detecção e resolução de conflictos

o Cada elemento i do vector indica o número de updates de um ficheiro para o servidor i • Quando um cliente acede (open) a um ficheiro

1. Contacta o “servidor preferido” (escolhido do conjunto do AVSG) 2. Verifica, junto dos restantes servidores do AVSG, se o ficheiro é o mais actual

Se não for, então o “servidor preferido” passa a ser aquele com o ficheiro mais actual e os restantes servidores são notificados e actualizados com a nova versão

3. O compromisso de callback (quando existem alterações) é estabelecido com o “preferido” • Quando um ficheiro é fechado as (eventuais) alterações são copiadas para o AVSG (usando multicast) ou marcado como

modificado para depois ser copiado mais tarde quando o sistema estiver online

• A detecção de alterações no AVSG é feita através de mensagens de “probe” enviadas pelo cliente para todos os servidores de ficheiros que tem em cache (a cada T segundos)

o Alterações no AVSG podem levar à quebra de compromisso de callback

Clustering

Grupo de aplication servers que fornecem um conjunto de serviços partilhados.

Vantagens do Cluster: Escalabilidade através do load balancing Grande disponibilidade Failover (recuperar de falhas)

Basic

• Usa um load manager ( normalmente duas abordagens ao load-management é a utilização de layer-4 ou layer-7 switches) • Os dados são guardados de uma maneira persistente, podem ser replicados ou particionados. • Muitos serviços usam um backplane (trata de trafego interserver como redirecionar queries de clientes).

Simple Web Farm

• Usa round-robin DNS para o load management • A data é guardada de uma forma persistente e replicada para todos os nós • Todos os servidores conseguem lidar com as queries logo não existe necessidade para “coherence traffic” e sem necessidade

de um backplane • Nesta versão as falhas de nós reduzem a capacidade do sistema mas não os dados disponiveis

Availability • Uptime (fracção de tempo em que o site está a lidar com o tráfego) = (MTBF – MTTR) / MTBF • Yield = queries completed / queries offered • Harvest – completude das queries, ou seja, quantidade de features disponíveis

o Harvest = data available / all data

DQ Principle

• Rolling upgrade

o versões antiga e nova devem ser compatíveis o Mais utilizado

• DQ Principle - A capacidade máxima de um sistema tende a ter um particular bottleneck físico, tal como o total máximo de banda em I/O ou total máximo de procuras por segundo, o qual está fortemente ligado ao movimento de dados.

Replicação vs Partição Replicação – consiste em copiar os dados de um sistema para um outro espaço (e.g noutros servidores) Partição – consiste em particionar por blocos um determinado conjunto de dados e espalhar esses blocos por vários espaços (e.g noutros servidores) Se ambas tiverem com o DQ (Data per query x Queries per second) inicial igual podemos dizer que o yield na replicada decai para 50% e o harvest mantém-se a 100% (replicada mantêm D constante mas decaem Q) . Enquanto que na particionada o yield mantém-se a 100% e o harvest decai para 50% (partições mantêm Q constante mas reduzem D).

Routing de pedidos • Routing em sistema distribuído (baseado em DNS)

o Server based Triangulação – baseado em tunneling

• O primeiro servidor coloca o pacote num outro pacote (criando um túnel) o servidor destino ao detectar isso responde directamente ao cliente

HTTP redirection – o servidor responde ao cliente com um código HTTP especial que indica que o recurso foi movido

URL rewriting – reescrita dos links das páginas • Routing em web cluster (baseado em switch)

o Nivel 4 – TCP/IP (mais rápido mas menos eficiente) Two-way – pedido e resposta passam pelo mesmo switch One-way – pedido passa pelo switch mas a resposta é directa

o Nivel 7 – aplicação (mais eficiente mas mais lento) Two-way One-way

• Routing em web cluster virtual (os clusters têm o mesmo IP) o Baseado em MAC

• Algoritmos “Dispatching” o Content-Blind (Estáticos, Dinâmicos) o Content-Aware:

Client Aware (Cache affinity, service partitioning, SITA-E e CAP, client affinity) Client and Server Aware (LARD, cache manager)

Graceful Degradation ( acetatos por causa dos exemplos, resposta a perg. 12 do 1º exame de 2006/07)

P2P • Sistema distribuído • Vários nós interligados • Partilham recursos (processador, memória, ficheiros, etc) • Não requerem a mediação de um servidor central • Aplicações P2P:

o Comunication and colaboration (IRC, MSN, Yahoo) o Distributed Computation (Seti@home) o Internet Service Support o Content Distribution (Kazaa, Napster)

• Analysis Framework (análise de aplicações baseadas em arquitecturas p2p) o Propriedades não funcionais:

Segurança, Escalabilidade, Performance, Fiabilidade, Capacidade de Gestão de Recuros (editar, remover docs,…), Informação Semântica do Grupo (localização geográfica, …)

Network centralization • Purely decentralized – p2p puro (todos os nós são equivalents em termos de funcionalidades e tarefas (ex. gnutella) • Partialy centralized – existem nós simples e super-nós que executam tarefas especiais • Hybrid decentralized – existe um servidor central para facilitar a interacção entre os peers (ex: emule)

Network structure • Structured – os ficheiros ou ponteiros para eles são colocados em locais específicos (ex: Chord) e a topologia overlay é

controlada • Unstructured – os locais dos ficheiros ou dos ponteiros para eles não estão de forma algum relacionados com a topologia

overlay

Network structure : Freenet

• É um típico sistema de conteúdo distribuído de rede descentralizada (decentralized loosely-structured) . • Opera auto-organizando a rede p2p procurando espaço de disco livre nos peer para criar um ficheiro de sistema colaborativo e

virtual • As importante features da Freenet são:

o Segurança, publicação anónima, anonimato, replicação de dados para gerar disponibilidade e performance

Network structure : Chord

• É uma estrutura p2p que serve de routing e de infra-estrutura de localização que realiza um mapeamento de identificadores de ficheiros em identificadores de nós.

• Localização de dados pode ser implementada por cima do Chord utilizando identificadores items de dados (ficheiros) com chaves e guardando a chave e os item de dados em pares no nó que a chave mapeia

• Para acelerar o processo de procura das chaves nos nós utiliza-se a tabela finger • Cada entrada da tabela i aponta para o sucessor do nó dá por (n + 2i-1)mod 2m • Para um nó n1 procurar uma chave k, a tabela finger é consultada para identificar o nó mais alto n2 cujo o id esteja entre

n1 e k. • Se tal nó n2 existir então o lookup é repetido começando em n2. • Caso contrario o sucessor de n2 é retornado • O finger é eficiente e escalável com uma ordem de grandeza O(log n), robusto e simples.

Network structure : CAN

• A estrutura CAN (Content Addressable Network) é essencial para: o Uma tabela hash distribuída escalável na internet que mapeie os nomes dos ficheiros com a sua localização na rede o Suportar inserção, lookup e remoção de pares (chave,valor) na tabela hash

• Cada nó da rede CAN: o Guarda uma parte (referida como zona) da hash table o Informação sobre um numero pequeno de zonas adjacentes na tabela

• Um novo nó que entre no sistema CAN é lhe alocado uma porção do espaço de coordenadas, faz-se isto separando a zona alocada de um nó existente em metade.

• Se um nó abandonar o sistema CAN as zonas ocupadas e entradas associadas por este na tabela são explicitamente entregues a um dos nós vizinhos

Network structure : Tapestry

É baseado em mecanismos de localização e routing introduzidos pela Plaxton A malha Plaxton:

É ma estrutura de dados distribuída Permite os nós localizarem objectos e fazer o route das mensagens sobre uma arbitrarily-sized overlay network Usa routing maps de tamanho constante e reduzido

Cada nó mantém um mapa da vizinhança A malha Plaxton usa um nó raiz por cada objecto (garantindo a localização do objecto) A malha assume uma população estática de nós Quando um objecto (o) é inserido na rede e guardado no nó (ns):

É associado a um nó raiz (nr) Uma mensagem é encaminhada de ns para nr (armazenando os dados na forma (id o, id ns) em todos os nós por que passou)

Quando é feito uma “query”: o As mensagens são encaminhadas pelo nr, até que um nó tenha a localização (o,ns)

O tapestry extende a malha plaxton adaptando-se redes p2p, e fornece disponibilidade, tolerância a faltas, bem como outras optimizações.

Optimizações:

o Cada nó mantêm uma lista de back-pointers (que apontam para os nós que o referem como vizinhos) o Introduz o conceito de distância entre nós o Usam um soft-state, para manter os conteúdos em cache (para recuperar de falhas na localizações e encaminhamentos

de objectos) o Para evitar um ponto único de falha do nó raiz , o Tapestry tem múltiplos nós raiz para cada objecto