2.3 Sistemas de Ficheiros para Clouds
2.3.5 Cumulus
O Cumulus [44] ´e um sistema que permite aos utilizador fazerem backup dos seus sistemas de ficheiros atrav´es de snapshots. Apesar de este sistema n˜ao ser um sistema de ficheiros, est´a inserido nesta secc¸˜ao porque os backups que este permite efectuar so- bre os sistemas de ficheiros s˜ao armazenados na cloud. A interface fornecida para os clientes comunicarem com o servidor consiste em somente 4 operac¸˜oes: get, put, list e delete. Estas operac¸˜oes operam em ficheiros inteiros. Como os sistemas de ficheiros tˆem muitos ficheiros pequenos, e armazen´a-los individualmente nas clouds tr´as alguns problemas como maiores tempos de latˆencia e custos monet´arios mais elevados devido aos modelos de custos apresentados pelas clouds, o Cumulus agrupa v´arios ficheiros pe- quenos e coloca-os dentro de uma unidade denominada segmentos. Estas unidades s˜ao armazenadas da mesma forma que os ficheiros possuindo tamb´em um identificador ´unico.
Cap´ıtulo 2. Trabalho relacionado 23
Cada snapshot inclui um log de metadados e os pr´oprios dados. O log de metadados cont´em entradas para cada ficheiro, onde s˜ao guardadas informac¸˜oes sobre as permiss˜oes e cust´odia do ficheiros, um resumo criptogr´afico para garantir a integridade dos dados, e os apontadores para a localizac¸˜ao dos dados. Cada snapshot ´e transformada num segmento, comprimida e encriptada antes de ser enviada para a cloud.
Os clientes podem fazer uma recuperac¸˜ao completa extraindo todos os ficheiros ou uma recuperac¸˜ao parcial recuperando s´o parte deles.
2.3.6
Considerac¸˜oes Finais
Ap´os o estudo destes sistemas de ficheiros para cloud, ´e importante dar relevˆancia a trˆes importantes limitac¸˜oes que estes apresentam. A primeira limitac¸˜ao refere-se ao caso dos sistema que adoptam uma arquitectura baseada em proxy, pois esta ´e um ponto ´unico de falha. A segunda relata com o facto de nenhum deles permitir a partilha de ficheiros controlada por diferentes utilizadores em diferentes localizac¸˜oes (note-se que no caso de uma arquitectura com proxy ´e permitida a partilhar de ficheiros entre os clientes que a estejam conectados `a mesma proxy). Por ´ultimo, estes s´o confiam unicamente num provedor de armazenamento dependendo assim deste, n˜ao efectuando assim nenhuma replicac¸˜ao de dados.
Apesar destas limitac¸˜oes, ´e de notar o mecanismo de validac¸˜ao de cache que alguns descrevem, em que s˜ao comparados resumos criptogr´aficos efectuados para cada vers˜ao.
2.4
Considerac¸˜oes Finais
Neste cap´ıtulo foram introduzidos e descritos alguns dos servic¸o de armazenamento, sistemas de ficheiros distribu´ıdos e sistemas de ficheiros para clouds estudados que nos ajudaram a desenhar e concretizar o C2FS. No pr´oximo cap´ıtulo ´e introduzida a arquitec- tura e modelo de sistema do C2FS, e ´e descrito em pormenor o servic¸o de armazenamento concretizado para este.
Cap´ıtulo 3
Armazenamento de Dados do C2FS
3.1
C2FS
Conforme j´a mencionado, o trabalho desenvolvido neste PEI enquadra-se num pro- jecto maior que ´e um sistema de ficheiros que armazena os seus dados na cloud-of-clouds chamado C2FS (cloud-of-clouds file system). Assim nesta secc¸˜ao ´e introduzida a arquitec- tura e o modelo de sistema do C2FS para melhor se perceber a descric¸˜ao dos componentes realizados por este projecto nas secc¸˜oes seguintes.
3.1.1
Arquitectura
A figura 3.1 apresenta a arquitectura do C2FS. Na base na arquitectura est´a o FUSE-J [8]. Este ´e o componente respons´avel por interceptar as chamadas de sistema para recur- sos pertencentes ao C2FS. ´E tamb´em devido ao uso deste m´odulo que o C2FS fornece aos seus clientes uma interface do estilo POSIX [13]. As chamadas de sistemas interceptadas s˜ao passadas ao agente C2FS pois este implementa uma interface fornecida pelo FUSE- J. O agente C2FS concretiza assim uma lista de operac¸˜oes de sistemas de ficheiros (i.e., open, write, etc) onde integra os outros componentes do sistema: o servic¸o de directorias, o servic¸o de locks e o servic¸o de armazenamento. Note-se que a interacc¸˜ao com estes sistemas depende da operac¸˜ao recebida pelo agente C2FS, tendo cada operac¸˜ao um com- portamento espec´ıfico. Al´em desta integrac¸˜ao, o agente C2FS ´e tamb´em respons´avel por gerar a chave de encriptac¸˜ao para cada ficheiro. Na secc¸˜ao 3.2 ´e explicado em pormenor o funcionamento do FUSE-J e as operac¸˜oes de sistemas de ficheiros que este permite implementar.
O servic¸o de directorias [32] ´e o componente respons´avel por armazenar os metadados dos recursos do C2FS. Juntamente com os metadados, ´e tamb´em armazenada a chave de encriptac¸˜ao. Este mecanismo faz tamb´em controlo de acesso a ficheiros partilhados. Estas func¸˜oes s˜ao concretizadas tendo por base um servic¸o de coordenac¸˜ao distribu´ıdo chamado DepSpace [20] que ´e executado em diferentes provedores de computac¸˜ao, fazendo uso do conceito cloud-of-clouds, assim como o DepSky. Este componente faz uso de um sistema
Cap´ıtulo 3. Armazenamento de Dados do C2FS 26
de cache para diminuir o n´umero de chamadas ao DepSpace, diminuindo assim tamb´em os custos associados a estas chamadas, e aumentando a performance do sistema.
O servic¸o de locks [32] tem a tarefa de manter a consistˆencia dos ficheiros controlando o acesso em simultˆaneo aos mesmos. Assim, o C2FS garante que enquanto um utilizador est´a a escrever num determinado ficheiro, mais nenhum outro pode efectuar esta mesma operac¸˜ao. Como o servic¸o de directorias, este servic¸o tamb´em ´e cliente do DepSpace.
O servic¸o de armazenamento tem o objectivo de gerir os dados na cloud-of-clouds atrav´es do DepSky. Este componente fornece dois n´ıveis distintos de cache. No primeiro os dados s˜ao mantidos no disco local para evitar chamadas `as clouds, enquanto que no segundo, os dados s˜ao mantidos em mem´oria de forma a diminuir o tempo de resposta, aumentando assim o desempenho do sistema. Este servic¸o permite tamb´em duas formas distintas de escrever os dados nas clouds. No primeiro as escritas s˜ao efectuadas de forma s´ıncrona enquanto que no segundo s˜ao efectuadas de forma ass´ıncrona. Neste caso ´e mantida uma fila de tarefas a correr em background para gerir estas mesmas escritas. Os dados s˜ao encriptados antes do envio para as clouds, ou seja, os dados em cache est˜ao em claro. Este servic¸o ´e descrito em detalhe na secc¸˜ao 3.4.
Figura 3.1: Arquitectura do C2FS.
3.1.2
Modelo do Sistema
Antes de descrevermos o servic¸o de armazenamento do C2FS em detalhe, explicamos as hip´oteses que o sistema requer para um correcto funcionamento.
Cap´ıtulo 3. Armazenamento de Dados do C2FS 27
Em primeiro lugar o C2FS tolera um n´umero ilimitado de clientes assumindo que cada um destes tem um identificador ´unico, e assume que a m´edia do tamanho m´aximo por ficheiro ´e de 50MBs para garantir bom desempenhos.
Em segundo lugar, o modelo de sistema do C2FS herda as propriedades dos modelos de sistema do DepSky e do DepSpace uma vez que o servic¸o de armazenamento do C2FS recorre ao DepSky para armazenar os dados na nuvem composta por uma cloud-of-clouds enquanto que os servic¸os de directorias e locks utilizam o DepSpace para armazenar os metadados.
Cada cloud utilizada pelo DepSky representa um servidor passivo ou seja, que n˜ao ´e capaz de executar c´odigo nenhum da aplicac¸˜ao, fornecendo s´o uma interface para pro- ceder a operac¸˜oes de escrita ou leitura de dados. Estas operac¸˜oes tˆem uma semˆantica de consistˆencia regular onde uma operac¸˜ao de leitura que seja executada concorrentemente com uma operac¸˜ao de escrita ir´a retornar ou os dados que j´a l´a estavam, ou os dados resul- tante da escrita em processo. Embora, como referido acima, o C2FS tenha a preocupac¸˜ao de n˜ao permitir mais que um escritor para o mesmo ficheiro no mesmo instante, o sistema n˜ao considera escritores maliciosos, pois estes ao terem acesso aos ficheiros, poderiam es- crever dados sem sentido do ponto de vista da aplicac¸˜ao. A comunicac¸˜ao existente entre o DepSky e as clouds ´e efectuada via o modelo cl´assico de chamada remota a procedi- mentos (RPC). Cada operac¸˜ao continua a ser invocada at´e obter uma resposta da cloud ou at´e ser cancelada.
J´a a comunicac¸˜ao existente entre os servic¸o de directorias e locks com os servidores DepSpace ´e efectuada atrav´es de canais fi´aveis autenticados ponto-a-ponto atrav´es do uso de sockets TCP e c´odigos de autenticac¸˜ao de mensagens (MAC) com chaves de sess˜ao sobre a assunc¸˜ao que a rede pode perder, corromper ou atrasar mensagens, mas n˜ao o pode fazer infinitamente entre processos correctos. Para garantir que todas os servidores executam as mesmas operac¸˜oes por ordem, ´e usada uma primitiva de multicast com ordem total, baseada no protocolo de consenso Paxos Bizantino [42]. Tal protocolo requer um modelo de sistema eventualmente s´ıncrono.
Tanto as clouds que s˜ao os servidores de armazenamento, como os servidores do DepSpace que mantem os metadados online, toleram faltas bizantinas [30] utilizando sis- temas de qu´oruns bizantinos onde s˜ao requeridos n ≥ 3f + 1 para suportar f servidores faltosos. Contudo, o sistema tolera um n´umero ilimitado de clientes faltosos.
3.2
FUSE
O FUSE (File system in USEr space) [7] ´e um m´odulo para Linux que permite a construc¸˜ao de sistemas de ficheiros no espac¸o do utilizador, eliminando assim a neces- sidade de efectuar modificac¸˜oes a n´ıvel do kernel. Isto significa que com a utilizac¸˜ao deste m´odulo, o sistema de ficheiros n˜ao necessita ser executado no kernel pois ´e ex-
Cap´ıtulo 3. Armazenamento de Dados do C2FS 28
ecutado a n´ıvel do utilizador. Outra vantagem inerente `a utilizac¸˜ao deste m´odulo para a implementac¸˜ao do sistemas de ficheiros ´e a interface ao estilo POSIX [13] que ´e oferecida aos clientes, facilitando assim a gerˆencia de ficheiros na cloud-of-clouds.
A figura 3.2 ilustra como o FUSE interage com a arquitectura dos sistemas de ficheiros Unix. Quando o VFS (Virtual File System) intercepta uma chamada de sistema a um re- curso pertencente ao sistema de ficheiros C2FS, automaticamente chama o m´odulo FUSE (FUSE). Este m´odulo ´e instalado no Kernel aquando da instalac¸˜ao do FUSE. Este por sua vez, envia a chamada para a biblioteca do FUSE (libfuse) atrav´es de um descritor de ficheiro especial. Por fim, o processo que concretiza o sistema de ficheiros recebe a chamada, processa-a, e envia a resposta pelo caminho inverso.
Figura 3.2: Caminho percorrido por cada chamada ao sistema.
Contudo, o FUSE ´e implementado em C enquanto que os sistemas a integrar no C2FS, o DepSky e o DepSpace, s˜ao implementados em Java, o que dificulta tal integrac¸˜ao. ´E usado ent˜ao uma concretizac¸˜ao do FUSE em Java chamado FUSE-J [8] para facilitar a integrac¸˜ao dos sistemas existentes. Este fornece uma API Java que usa ligac¸˜oes JNI (Java Native Interface) para comunicar com a biblioteca do FUSE. O FUSE-J fornece uma interface para implementar as operac¸˜oes de sistema de ficheiros chamada FileSystem3.
A tabela 3.1 apresenta a lista das operac¸˜oes que esta interface permite implementar e a func¸˜ao de cada uma delas no sistemas de ficheiros FUSE-J.
3.3
DepSky
Nesta secc¸˜ao s˜ao apresentadas as alterac¸˜oes que foram feitas no DepSky de modo a este responder de uma melhor forma `as necessidades do C2FS. Em sum´ario foram feitas duas melhorias significativas, sendo elas a adic¸˜ao de um novo protocolo de uso e a adic¸˜ao de uma nova operac¸˜ao que permite ler vers˜oes antigas de uma determinada Data Unit. Em baixo s˜ao descritas estas duas alterac¸˜oes no DepSky.
Cap´ıtulo 3. Armazenamento de Dados do C2FS 29
Operac¸˜oes Func¸˜ao
getattr(path, getattrSetter) retorna os metadados para um determinado re-
curso.
getdir(path, dirFiller) lista os recursos filhos de uma determinada direc-
toria.
mkdir(path, mode) criar uma directoria com as permiss˜oes forneci-
das.
mknod(path, mode, rdev) criar um ficheiro com as permiss˜oes fornecidas.
open(path, flags, openSetter) abre o descritor do ficheiro de acordo com o modo
pretendido (e.g., O WRONLY, O RDWR). read(path, fh, buf, offset) lˆe o n´umero de bytes pedidos a partir do offset pre-
tendido de um ficheiro aberto.
write(path, fh, isWritepage, buf, offset) escreve para um ficheiro aberto a partir do offset fornecido.
rename(from, to) renomeia um determinado recurso.
chmod(path, mode) muda as permiss˜oes de um determinado recurso.
flush(path, fh) fecha o descritor de ficheiro assegurando que os
dados em cache est˜ao devidamente armazenados no disco. Note-se que se um ficheiro tiver mais que um descriptor associado (e.g., no caso de um fork), haver´a mais que um flush por open.
fsync(path, fh, isDatasync) sincroniza os dados em cache de um determinado
ficheiro aberto com o disco.
link(from, to) cria uma ligac¸˜ao forte (hard link) entre os dois
ficheiros.
release(path, fh, flags) liberta um determinado ficheiro quando todos os
descriptores desse ficheiro tiverem sido devida- mente fechados (flush).
truncate(path, size) altera o tamanho de um ficheiro. Pode ser invo-
cada sobre ficheiro abertos ou ficheiros fechados
rmdir(path) elimina uma directoria.
statfs(statfsSetter) obt´em informac¸˜ao estat´ısticas sobre o sistema de
ficheiros.
symlink(from, to) cria uma ligac¸˜ao simb´olica para um dado recurso.
readlink(path, link) lˆe uma ligac¸˜ao simb´olica.
unlink(path) elimina um ficheiro.
utime(path, atime, mtime) muda o tempo de acesso e/ou o tempo de
modificac¸˜ao de um ficheiro.
chown(path, uid, gid) muda o dono e o grupo do ficheiro.
Cap´ıtulo 3. Armazenamento de Dados do C2FS 30
Modificac¸˜ao 1. Por motivos relacionados com o controlo de acesso sobre ficheiros partilhados, o servic¸o de armazenamento (um componente do C2FS descrito na secc¸˜ao seguinte) cifra os dados antes de os guardar nas clouds (usando o DepSky), sendo a chave sim´etrica usada para cifrar/decifrar os dados armazenada no servic¸o de directorias. As- sim, os dados ir˜ao ser armazenados no DepSky j´a previamente cifrados. Como j´a descrito anteriormente, o DepSky fornece dois protocolos distintos para os clientes gerirem os seus dados na cloud-of-clouds: o DepSky-A e o DepSky-CA [19]. Contudo, nenhum destes protocolos responde devidamente `a necessidade do C2FS. O DepSky-A n˜ao nos ´e ´util porque, apesar de garantirmos a confidencialidade dos dados devido `a sua cifrac¸˜ao no servic¸o de armazenamento, se um bloco de dados de tamanho T for replicado em n clouds, ir´a ser consumido n × T espac¸o de armazenamento e os custos ir˜ao ser, em m´edia, n vezes maiores do que se for usado s´o uma cloud. O DepSky-CA tamb´em n˜ao se revela ´optimo para o C2FS porque, embora solucione o problema descrito anteriormente atrav´es do uso de c´odigos de apagamento, cifra tamb´em os dados e usa partilha de segredo para garantir confidencialidade das chaves, o que penaliza a performance uma vez que os dados s˜ao encriptados duas vezes, uma a n´ıvel do C2FS, e outra no DepSky.
Foi concretizado ent˜ao um novo protocolo que n˜ao ´e mais que uma variante do DepSky- CA. A diferenc¸a ´e que n˜ao faz uso de t´ecnicas criptogr´aficas nem de partilha de segredos, mas mant´em a disponibilidade e integridade dos dados ao mesmo tempo que reduz os custos monet´arios de armazenamento devido `a utilizac¸˜ao de c´odigos de apagamento na replicac¸˜ao dos dados. Assim, em cada operac¸˜ao de escrita, ´e armazenado em cada cloud um fragmento codificado (s˜ao gerados tantos fragmentos quanto o n´umero de clouds uti- lizado). Na operac¸˜ao de leitura s˜ao necess´arios f + 1 fragmentos (em que f ´e o n´umero de provedores que podem ser faltosos) para obter o bloco de dados inicial1. Note-se que mesmo na eventualidade de algu´em escutar a rede e obter f +1 fragmentos (isto ´e, o bloco inicial), n˜ao conseguir´a obter os dados em claro pois estes s˜ao previamente cifrados pelo servic¸o de armazenamento do C2FS.
Modificac¸˜ao 2. O DepSky mant´em todas as vers˜oes de todas as escritas efectuadas em cada cloud. Neste cen´ario foi concretizada uma operac¸˜ao de leitura que permite ler uma vers˜ao antiga de uma unidade de dados do DepSky. A esta nova operac¸˜ao demos o nome readMatching(Du, h), onde o primeiro argumento ´e a unidades de dados do DepSky e o segundo ´e um resumo criptogr´afico. Assim o objectivo ´e ler a primeira vers˜ao em que o seu resumo ´e igual ao resumo fornecido.
Para a concretizac¸˜ao desta operac¸˜ao foram necess´arias algumas alterac¸˜oes na operac¸˜ao de escrita do Depsky. Primeiro tˆem que ser armazenados todos os metadados referentes a cada vers˜ao escrita, ao inv´es de armazenar somente os metadados da ´ultima vers˜ao. Esta alterac¸˜ao foi efectuada de modo a garantirmos a integridade de todos os blocos de dados
Cap´ıtulo 3. Armazenamento de Dados do C2FS 31
escritos em cada cloud. Outra alterac¸˜ao feita foi a introduc¸˜ao de um novo campo nos metadados chamado datahash. Este campo armazena um resumo criptogr´afico efectuado pelo DepSky sobre cada bloco de dados completo a ser escrito (i.e., antes de passar por qualquer processo de codificac¸˜ao ou cifrac¸˜ao). Por fim, a operac¸˜ao de escrita do DepSky passa a retornar ao cliente este resumo.
O algoritmo desta nova alterac¸˜ao ´e bastante simples.
• Primeiro ´e obtido o ficheiro de metadados referente `a unidade de dados fornecida Du. Neste caso basta obter o ficheiro de metadados de n − f cloud (uma vez que neste conjunto de clouds existe pelo menos uma com a vers˜ao do campo datahash mais actual).
• Depois s˜ao comparados os resumos presentes nos campos datahash com o resumo fornecido h, iniciando a procura na vers˜ao mais recente, at´e `a mais antiga.
• Quando encontrado um resumo igual ao resumo h, ´e lida das clouds a vers˜ao refer- ente a esse resumo encontrado. Esta leitura ´e realizada seguindo o protocolo normal de leitura, ou seja, ´e efectuada num qu´orum de n − f clouds. Caso nenhum resumo presente no ficheiro de metadados seja igual ao resumo fornecido, ´e retornado erro na operac¸˜ao.
Esta operac¸˜ao foi introduzida para satisfazer um mecanismo explicado na tese [32], que tem por finalidade minimizar uma importante limitac¸˜ao presente na maioria das clouds, que ´e a consistˆencia eventual, fornecendo assim uma consistˆencia regular forte para os ficheiros armazenados no C2FS.
3.4
Servic¸o de Armazenamento
Nesta secc¸˜ao ´e apresentado o servic¸o de armazenamento concretizado para o C2FS. Como j´a referido anteriormente, este servic¸o utiliza o DepSky modificado descrito na primeira modificac¸˜ao da secc¸˜ao 3.3 que mant´em a integridade e a disponibilidade dos dados armazenados na cloud-of-clouds. A confidencialidade ´e fornecidada pelo pr´oprio servic¸o de armazenamento que cifra os dados antes do seu envio para as clouds. Cada ficheiro neste servic¸o est´a directamente relacionado com uma unidade de dados do Dep- Sky (Data Unit).
Este servic¸o disp˜oe de uma cache local que aumenta o desempenho do sistema de ficheiros e diminui os custos monet´arios associados a downloads que, desta forma, s˜ao evitados. Note-se que apesar de este servic¸o armazenar os dados nas clouds atrav´es do DepSky, ´e importante referir que s´o opera em dados que estejam em cache, sendo s´o necess´ario fazer o download dos dados das clouds caso exista uma vers˜ao mais recente destes nas clouds. Isto acontece se o ficheiro for partilhado por diferentes utilizadores
Cap´ıtulo 3. Armazenamento de Dados do C2FS 32
ou se o mesmo utilizador mantiver o C2FS em diferentes estac¸˜oes de trabalho. Para dados que n˜ao sejam partilhados nunca ´e necess´ario efectuar uma leitura das clouds (a n˜ao ser que o mesmo utilizador monte o mesmo o sistema numa m´aquina diferente onde a cache n˜ao est´a actualizada), servindo estas s´o para backup. Isto ´e muito importante pois conseguimos poupar dinheiro uma vez que a transferˆencia de dados para dentro da maioria das clouds n˜ao tem nenhum, ou quase nenhum prec¸o associado, sendo apenas as operac¸˜oes de transferˆencia de dados para fora cobradas.
Por omiss˜ao, a cache dos dados ´e feita no disco local, mas, os utilizadores deste servic¸o podem tamb´em manter a cache dos dados em mem´oria vol´atil de forma a diminuir o tempo de resposta para cada operac¸˜ao de leitura ou escrita. Este servic¸o disponibiliza tamb´em duas formas de enviar os dados para as clouds, s´ıncrona e ass´ıncrona, em que na s´ıncrona os clientes esperam pela confirmac¸˜ao de que os dados est˜ao devidamente