SD09 - Sistemas de Arquivos Distribuídos.ppt

8/16/2019 SD09 - Sistemas de Arquivos Distribuídos.ppt

1/36

SistemasDistribuídos

Parte 09

Sistemas de ArquivosDistribuídos

Conteúdo adaptado a partir do material dos professores

Luís Fernando Friedrich (Universidade Federal de Santa Catarina) eFrederico Madeira (Faculdade Maurício de assau ! "#)


2/36

Sistema de $r%uivo

• "arte importante dos sistemasoperacionais& pois ele fornece'

– iso abstrata dos dados persistentes

– Controle sobre o servi*o de nomes

– $cesso + ar%uivos e sua or,ani-a*o,eral.

– 2 –


3/36

Sistema de $r%uivo

• Conceitos – $r%uivo

• Uma se%uencia de b/tes.

• Um sistema especi0co de uma estruturainterna.

• $tributos 1amanho& acesso& datas& dono.

–

Diret2rio (ar%uivo especial)• Mapeia os nomes para os identi0cadores.

• "ode conter subdiret2rios (arvore).

– 3 –


4/36

Sistema de $r%uivos

Distribuído• 3"ermite aos pro,ramas arma-enarem eacessarem ar%uivos remotos e4atamente

como se fossem locais& possibilitando

%ue os usu5rios acessem ar%uivos apartir de %ual%uer computador em umarede. 6 desempenho e a se,uran*a noacesso aos ar%uivos arma-enados em

um servidor devem ser compar5veis aosar%uivos arma-enados em discos locais.7 – 8Coulourus& 9.: Dollimore& ;.:


5/36

S$D @ Sistemas de $r%uivosDistribuídos• 6ferecem'

– $cesso remoto aos ar%uivos arma-enados em umservidor

– $cesso aos dispositivos de #AS de outras m5%uinas

– Controle de verso e restaura*o de c2pias dese,uran*a

• 6s sistemas de ar%uivos distribuídos devemprover' – Con0abilidade

– Bedundncia

– Disponibilidade

– #scalabilidade

– 5 –


6/36

"or %ue adotar S$D

• Compartilhamento de recursos E sempre umdesa0o.

– Clientes dispersos

–

"onto de vista centrali-ado – Mobilidade e e4ibilidade

• S$D oferece um es%uema decompartilhamento bem estruturado.

–

#spa*o em disco. – $dministra*o compartilhada.

– Cada ma%uina no tem %ue arma-enar ar%uivos %ueir5 acessar.

– 6 –


7/36

S$D ! 6 %ue se busca

• Tolerância a Falhas – Se um servidor cair ou 0car fora do ar ou da rede&

o sistema de ar%uivos no pode perder informa*Gese nem 0car indisponível total ou parcialmente

• Acesso Concorrente – 5rios usu5rios podem acessar v5rios ar%uivos& ou os

mesmos ar%uivos& sem sofrer danos& perda deperformance ou %uais%uer outras restri*Ges

•

Replicação de Arquivos – Com esta funcionalidade& a con0an*a e a

e0ciHncia do servi*o de ar%uivos E aumentadasi,ni0cativamente

– 7 –


8/36

S$D @ Be%uisitos

• 1ransparHncia de... – Acesso' clientes tratam ar%uivos como locais

– Localização' espa*o de nomes uniforme e

sem mudan*a %uando ar%uivos mudarem – Concorrência' opera*Ges dos clientes no

devem interferir umas com as outras

– Falha' servidores devem operar normalmente

na falha dos clientes& e vice@versa – Desempenho' no deve variar com a car,a

– 8 –


9/36

S$D @ Be%uisitos

• Usabilidade depende de... – Heteroeneidade de H! e "!

• Interfaces de0nidas de forma %ue possam ser implementadaspor v5rios JK e SK

– #scala$ilidade• Servi*o deve ser e4tensível para acomodar mudan*as de escala do SD

• Se escalabilidade envolver muitos hosts... – Transparência de replicação

• $r%uivos podem estar 0sicamente replicados e cliente i,noraesse fato

– Transparência de miração• $r%uivos podem mudar de lu,ar e isso no deve alterar os

clientes

– 9 –


10/36

S$D @ Be%uisitos

– # ainda...• Compartilhamento

– 1oda opera*o em um ar%uivo deve ser visível a todosprocessos

– Semntica de sesso' nenhuma modi0ca*o E visível aosoutros processos atE %ue o ar%uivo se=a fechado.

• Arquivos imut%veis& – Modi0ca*Ges no so possíveis:

– Simpli0ca compartilhamento e replica*o:

– Modi0ca*Ges ocorrem apenas em diret2rios

• Transaç'es& – 1odas as modi0ca*Ges tHm a propriedade do tudo@ou@nada

(atomicidade):

– Seriali-a*o

– 10 –


11/36

S$D ! Servi*os 5sicos

• "erviço de (omes Distri$u)do – 6 servi*o de nomes cuida de indicar a locali-a*o de

um determinado ar%uivo dado o seu nome ou caminho.

• "erviço de Arquivos Distri$u)do –

Bespons5vel por fornecer opera*Ges sobre os ar%uivos %uecompGe o sistema.

– 6s ar%uivos podem ser arma-enados de diferentesformas& dependendo do seu tipo e uso.

• "erviço de Diret*rios Distri$u)do –

Bespons5vel por manter a or,ani-a*o dos ar%uivosarma-enados no sistema.

– #le fornece uma interface para %ue os usu5rios possam arran=arseus ar%uivos num formato hier5r%uico& %ue E estruturadoem diret2rios e subdiret2rios.

– 11 –


12/36

S$D ! $spectos de

Implementa*o• Componentes – "ara preencher os

re%uisitos e implementar

servi*os& a=uda bastantese o S$ for implementadocom trHs componentes'

• Servi*o de ar%uivob5sico

• Servi*o de diret2rio

• M2dulo de cliente

– uem fa- o %ue

– 12 –


13/36

S$D ! $spectos de

Implementa*o• Servi*o de ar%uivos b5sico – Implementa opera*Ges nos ar%uivos

– $r%uivos so referenciados por seus FIDs (File

Ids)• FIDs devem ser únicos no SD

– Cria*o de um novo ar%uivo

• 9era um FID e devolve ao re%uisitante

– 13 –


14/36

S$D ! $spectos de

Implementa*o• Servi*o de Diretorio – Bespons5vel por converter nomes te4tuais em

FIDs

– Diret2rio• Con=unto de FIDs e nomes te4tuais

– Cliente do servi*o de ar%uivo b5sico

• $r%uivos de diret2rio so ar%uivos& e

,erenciados pelo S$• Jierar%uia de diret2rios

– 14 –


15/36

S$D ! $spectos de

Implementa*o• Modulo Cliente – Chamadas de sistema para manipula*o de

ar%uivos

•

Criar& ler& escrever... – $rma-ena locali-a*o na rede do servi*o de

diret2rio e de ar%uivo b5sico

– "ode ,erenciar cache local

– 15 –


16/36

S$D ! $spectos de

Implementa*o• Interface do Servi*o de $r%uivo asico(S$) – $spectos dessa interface

• o tem openAclose: manipula usando I$(identi0cador de ar%uivo)

• Servidor sem estado (stateless)

– Clientes so respons5veis por saber onde

esto lendoAescrevendo – o caso de falha& depois do retorno no h5

procedimento especial

– 16 –


17/36

S$D ! $spectos de

Implementa*o• $penas relembrando... – Stateless

• Servidor no ,uarda informa*o sobre clientes

nem sobre ar%uivos (I$s) – Besponsabilidade do cliente em manter o

estado

– Stateful•

MantEm informa*o de %ual cliente abriu %ualar%uivo& e em %ue bloco est5

• Be%uisi*Ges so atendidas mais r5pido& pois noprecisa locali-ar o I$ do ar%uivo

– 17 –


18/36

S$D ! $spectos de

Implementa*o• 9era*ao de I$s – Devem ser ,erados de forma única no

espa*oAtempo e difícil de for=ar• $r%uivo removido& I$ descartado

– I$ no E endere*o• o contEm informa*Ges sobre locali-a*o

do ar%uivo

– 18 –


19/36

S$D ! $spectos de

Implementa*o• 9era*ao de I$s – Como ,arantir unicidade e inte,ridade

• Usar um espa*o de números pouco

populoso• Unicidade

– I$ N ID do ,rupo O inteiro (no reutili-5vel)

• ! Inte,ridade – $crescentar uma parte aleat2ria ao inteiro

– 1ornar a distribui*o de I$s v5lidos esparsa

– "arte aleat2ria inacessível aos clientes

– 19 –


20/36

S$D ! $spectos de

Implementa*o• Modos de $cesso – Controle de acesso tem por base o I$

• Uma chave ou 3capacidade7 (capabilit/)

• S2 fornecer I$ a %uem tem direito de acesso

– # ar%uivo compartilhado• Dono precisa de direitos especiais

–

Incorporar seletividade na capacidadedo I$• Incluir campo de permisso no I$ proposto

– 20 –


21/36

S$D ! $spectos de

Implementa*o• Modos de $cesso – its adicionais indicando permisso

• Leitura

• #scritaAtruncamento• Bemover

• 6bterAde0nir permissGes

– a cria*o& usu5rio pode tudo

– Durante LooPup (busca)& I$ retorna apenascom permissGes concedidas ao usu5rio

– 21 –


22/36

S$D ! $spectos de

Implementa*o• Modelos de $r%uivos – $r%uivos estruturados e no@estruturados

• $r%uivos estruturados (se%uHncia ordenada de

re,istros) so raramente utili-ados& podendo serinde4ado ou no@inde4ado. $ maioria dos S6Qsmodernos utili-am ar%uivos no@estruturados.

– $r%uivos modi0c5veis e no@modi0c5veis•

6 modelo mais usado E o modi0c5vel. $l,unssistemas atuais utili-am o modelo no@modi0c5vel %ue permite um compartilhamentoconsistente e assim facilita cachin, e rEplicas.

– 22 –


23/36

S$D ! $spectos de

Implementa*o• Semntica de Compartilhamento – uando h5 mais de um processo lendo

eAou escrevendo em um ar%uivo

• Controle de concorrHncia (oPR)• Semntica de compartilhamento

– uatro tipos b5sicos de semntica• Semntica UI

• Semntica de sesso

• $r%uivos imut5veis

• 1ransa*Ges

– 23 –


24/36

S$D ! $spectos de

Implementa*o• Semntica UI – Um read %ue se,ue um Trite vH o valor

escrito pelo Trite• 6bri,atoriedade de ordena*o total

• Sempre retorna o valor mais atual

– Implementa*o f5cil•

Servidor central %ue processa re%uisi*Ges naordem (l2,ica)

– 24 –


25/36

S$D ! $spectos de

Implementa*o• Semntica de sesso – Bela4amento na semntica UI

– Mudan*as em um ar%uivo aberto so visíveis

apenas ao processo %ue modi0ca o ar%uivo – uando o ar%uivo E fechado& as mudan*as so

visíveis para outros processos. 6 ar%uivofechado E enviado de volta para o servidor

– #st5 errado• o

• $mplamente implementado

– 25 –


26/36

S$D ! $spectos de

Implementa*o• Semntica de sesso (continua*o)• Servidor centrali-ado tra- problemas de ,ar,alo e

ponto central de falha

• 9ar,alo pode ser aliviado com uso de caches nosclientes

– Cliente@ lH o ar%uivo (coloca no cache) e altera

– Cliente@V lH o ar%uivo verso anti,a do ar%uivo

• 6 %ue acontece se dois ou mais clientes esto

modi0cando um mesmo ar%uivo em suas caches

– 6 resultado 0nal depende do último close

– "ode@se usar uma re,ra arbitr5ria para decidir

– 26 –


27/36

S$D ! $spectos de

Implementa*o• Semntica de ar%uivos no modi0cados• "or %ue se preocupar

• $r%uivos no podem ser alterados – $penas B#$D e CB#$1#

• # para alterar um ar%uivo – enhum ar%uivo pode& ser alterado& mas pode@se criar um

novo de forma atWmica

– $r%uivos so imut5veis& mas diret2rios no

• "roblema ' se dois clientes dese=am trocar umar%uivo no mesmo tempo – Usa@se o último ou adota@se %ual%uer re,ra no

determinística

– 27 –


28/36

S$D ! $spectos de

Implementa*o• Semntica de transa*o• 1ratar opera*Ges de forma atWmica

– Uma transa*o

– 1odas modi0ca*Ges nos ar%uivos sodelimitados por um e,in e um #ndtransaction

• Dois processos ao mesmo tempo

– 1ransa*Ges permitem concorrHncia – Sistema fa- seriali-a*o

– 28 –


29/36

S$D ! $spectos de

Implementa*o

– 29 –


30/36

S$D ! Uso de Mem2ria

Cache• a mem2ria do servidor – #limina transferHncia deApara disco em cada acesso

– Unidade de cache' ar%uivos inteiros: blocos

– uando a cache est5 cheia Descartar informa*o mais

anti,a – 1ransparente para clientes Sem problemas com

consistHncia ante suas re%uisi*Ges

• a mem2ria do cliente – Bedu- volume de acesso via rede

– #s%uemas'

• Cache direto no processo do usu5rio

• Cache no núcleo do S.6.

• Cache em um processo separada a nível de usu5rio

– 30 –


31/36

S$D ! Uso de Mem2ria

Cache• MEtodos de consistHncia de cache – !rite throuh

• 6pera*o de escrita E propa,ada instantaneamente

– Dela+ed ,rite• 6pera*Ges de escrita so propa,adas em bloco (ap2s tempo 4).• Melhor desempenho& mas risco de ambi,uidade na semntica

(depende de timin,84>)

– !rite on close&• Semntica de sesso e%uivalente a sistemas centrali-ados

– Centralized control• Semntica UI 1oda opera*o pode ser vista instantaneamente

• "erformance e escalabilidade comprometidas:

– 31 –


32/36

S$D @ Beplica*o

• SDs ,eralmente oferecem al,uma forma dereplica*o de dados – Múltiplas c2pias do mesmo ob=eto

• "or %ue – $umentar con0abilidade @ a %uebra de um servidor no

implica na perda de dados

– "ermitir acesso mesmo na caso de falha mesmo %ueum servidor no este=a disponível o acesso continua

–

Diviso de car,a entre servidores espalhar a car,ade trabalho em v5rios servidores

• "rincipal problema' transparHncia

– 32 –


33/36

S$D @ Beplica*o

• Beplica*o e4plícita – "ro,ramador fa- todo o

3trabalho su=o7

– Servi*o de diret2rio pode

permitir múltiplos I$s porar%uivo

• Becupera todos no looPup

• uando for manipular& tenta

se%uencialmente um por umdos I$s& atE conse,uir

– Funciona& mas E muitotrabalhoso& e nada transparente

– 33 –


34/36

S$D @ Beplica*o

• Beplica*o atrasada – $penas uma c2pia E feita

em um servidor

–

6 servidor E respons5velpor...

• "ropa,ar atuali-a*Ges

• Selecionar outro servidor

para atender& se ele nopuder

– 34 –


35/36

S$D @ Beplica*o

• Beplica*o em ,rupos – 6pera*o de escrita E

feita ao mesmo tempo em

todos os n2s• Multicast atWmico (tudo@ou@

nada)

– $trasada 4 ,rupo• Um servidor 4 ,rupo

• Se,undo plano 4 atWmica

– 35 –


36/36

S$D ! #4emplos

• FS

• 9FS(9lobal FileS/stem)

•

"FS (parallel virutal 0le s/stem)• $FS ($ndreT FileS/stem)

• 9M$ILFS

• DFS• C6D$ (Constant Data $vailabilit/)

36

SD09 - Sistemas de Arquivos Distribuídos.ppt

Documents

Transcript of SD09 - Sistemas de Arquivos Distribuídos.ppt