virtual de um CDRM pode mudar sem que seja necessário mover FFIs entre CDRMs. Esta migração só precisará ocorrer quando CDRMs entram ou deixam o sistema, o que não deve ocorrer com freqüência. Finalmente, fragmentos nunca precisam ser migrados, uma vez que estes são localizados pelos endereços de ADRs contidos nos FFIs.
Conseqüentemente, CDRMs podem alterar seus identificadores virtuais sem que seja necessário mi- grar dados armazenados no CDRM e em outras máquinas de seu aglomerado. CDRMs alteram seus identificadores virtuais quando, por exemplo, ADRs entram ou saem de seu aglomerado. Além disso, CDRMs podem entrar e sair do sistema com um baixo custo, uma vez que apenas parte dos FFIs dos vizinhos imediatos do CDRM que saiu ou entrou precisam ser migrados. Deste modo, a sobrecarga para que o OppStore se adapte dinamicamente a mudanças no ambiente é reduzida consideravelmente.
7.3
Principais componentes
Os três principais componentes do OppStore são: (1) o gerenciador de repositórios de dados do aglo- merado (CDRM), (2) o repositório autônomo de dados (ADR) e (3) o intermediador de acesso (access
broker). Nesta seção, descrevemos o projeto destes componentes em mais detalhes. Apresentaremos, na
Seção 7.6, quais dessas funcionalidades já foram implementadas e os detalhes desta implementação.
7.3.1 Gerenciador de repositórios de dados do aglomerado (CDRM)
Os CDRMs são responsáveis pelo gerenciamento dos ADRs presentes em seu aglomerado. Para realizar este gerenciamento, CDRMs mantêm informações sobre todos os ADRs em seu aglomerado, incluindo sua capacidade, endereço de rede, estado, espaço livre em disco e lista de fragmentos armaze- nados.
Quando um CDRM recebe uma requisição para armazenamento de um fragmento durante o processo de armazenamento perene de um arquivo, ele escolhe um ADR para armazenar este fragmento e devolve seu endereço de rede. As restrições na escolha do ADR são que ele esteja disponível naquele momento e que tenha espaço em disco suficiente para armazenar o fragmento. A lista dos fragmentos armazenados nos ADRs é utilizada para reconstruir fragmentos que são perdidos no caso em que ADRs deixam o sistema. Para tal, esta lista deve incluir os identificadores dos FFIs (File Fragment Indexes) que contêm cada fragmento.
A lista de ADRs também é utilizada quando o CDRM recebe uma requisição para armazenamento efêmero de um arquivo. Neste caso, o CDRM retorna uma lista de ADRs que armazenarão as réplicas do arquivo. Estas réplicas são tratadas pelo CDRM do mesmo modo que fragmentos.
CDRMs são também responsáveis pelo armazenamento de FFIs. Como FFIs são pequenos, contendo apenas alguns endereços de ADRs e identificadores de fragmentos, os FFIs são armazenados diretamente
na máquina executando o CDRM.
Para prover tolerância a falhas, informações contidas em um CDRM são replicadas em outros r CDRMs vizinhos, onde r é um parâmetro configurável. Quando um CDRM falha, ele é reiniciado em outro nó do aglomerado utilizando a informação replicada nos vizinhos. Este processo é iniciado por um dos ADRs do aglomerado, quando este não consegue mais se comunicar com o CDRM de seu aglomerado. Este ADR contata um dos CDRMs vizinhos, obtém as informações sobre o CDRM que deixou o sistema e inicia um novo CDRM.
Poderíamos evitar esta comunicação do ADR com o CDRM de um aglomerado vizinho se, ao invés de replicar os dados de cada CDRM em seus CDRMs vizinhos, replicássemos estes dados nos ADRs de seus aglomerado. Mas, nesse caso, quando um aglomerado deixasse o sistema, os demais aglomerados não seriam mais capazes de recuperar os dados do CDRM daquele aglomerado. Trataremos da saída de aglomerados do sistema na Seção 7.4.3.
7.3.2 Repositório autônomo de dados (ADR)
ADRs são responsáveis por armazenar fragmentos codificados de arquivos. Para tal, ADRs pos- suem uma interface com métodos para o armazenamento de fragmentos e recuperação de fragmentos armazenados, permitindo que dados sejam transferidos entre ADRs e access brokers.
Quando um ADR entra no aglomerado, ele se registra com o CDRM daquele aglomerado, infor- mando o seu endereço de rede e a quantidade de espaço livre em disco. Este endereço de rede é fornecido pelo CDRM a access brokers para que estes possam se conectar ao ADR. Diferentes protocolos podem ser utilizados para a conexão entre access brokers e ADRs. No caso de conexões TCP, o endereço pode ser um par (endereço IP, porta). Para ADRs localizados em máquinas atrás de NATs1, este endereço
poderia conter o endereço IP de uma máquina proxy, que seria então utilizado para estabelecer uma conexão TCP. Já o espaço livre em disco é utilizado pelo CDRM, em conjunto com a disponibilidade do ADR, para definir a capacidade da máquina. O CDRM inicialmente atribui ao ADR o valor médio da disponibilidade dos demais ADRs do aglomerado. Após coletar informações sobre a disponibilidade média da máquina por um determinado período, uma semana, por exemplo, o CDRM passa a atualizar a capacidade do ADR dinamicamente, utilizando a disponibilidade média da máquina.
ADRs podem estar em três estados diferentes: ocioso, ocupado e indisponível. ADRs são responsá- veis por notificar o CDRM de seu aglomerado sobre seu estado, além do envio periódico de mensagens do tipo keep alive, que permitem que o CDRM detecte falhas nos ADRs. As máquinas contendo ADRs podem ser tanto compartilhadas como dedicadas. No caso de uma máquina compartilhada, seu dono pode configurá-la para transferir dados apenas quando ela está ociosa ou a qualquer momento. Neste último caso, o dono da máquina pode, visando manter sua qualidade de serviço, limitar a velocidade do
1Máquinas atrás de NATs (Network Address Translation) recebem um endereço IP válido apenas na rede local onde estão localizadas. Deste modo, estas máquinas não podem receber conexões provenientes de máquinas de fora desta rede local.
7.3 Principais componentes 111 envio de dados quando a máquina está ocupada. Máquinas dedicadas são sempre consideradas como ociosas e, conseqüentemente, possuem uma capacidade maior.
7.3.3 Intermediador de acesso (Access Broker)
O access broker é uma biblioteca que permite que aplicações e usuários da grade acessem os serviços de armazenamento de dados do OppStore. Esta biblioteca provê uma API em C contendo funções para realizar o armazenamento e recuperação de dados.
Como descrevemos na Seção 7.2.1, dados armazenados no OppStore são codificados em fragmentos redundantes utilizando o algoritmo de dispersão de informação (IDA) [37, 101]. IDA é um código de rasura (erasure coding) que permite codificar um arquivo U de tamanho n em m + k fragmentos codi- ficados de tamanho n/m, com a propriedade de que podemos recuperar U com apenas m dos m + k fragmentos codificados. Outra propriedade útil de IDA é que a codificação é linear, permitindo a co- dificação e decodificação incremental dos fragmentos. Portanto, durante o armazenamento, podemos transferir os fragmentos paralelamente à sua codificação. Do mesmo modo, durante a recuperação, o arquivo pode ser reconstruído incrementalmente, à medida em que o access broker obtém o conteúdo dos fragmentos dos repositórios.
Para reconstruir um arquivo, o access broker precisa obter apenas um subconjunto dos fragmentos armazenados, de modo que ele pode escolher os repositórios mais rápidos para transferir os fragmentos. Para estimar a taxa média de transferência de dados a partir de um aglomerado, o access broker aplica um algoritmo de envelhecimento (aging) sobre as taxas de transferências obtidas na recuperação de frag- mentos anteriores. Finalmente, o access broker aplica alguma aleatoriedade no momento de escolher os ADRs dos quais fragmentos serão obtidos, de modo a prevenir que apenas aglomerados de um pequeno grupo sejam selecionados.
Armazenamento e recuperação de arquivos
O armazenamento remoto de um arquivo pode ser realizado de modo síncrono, assíncrono e quasi- síncrono. No modo síncrono, a thread que realizou a chamada ao access broker permanece bloqueada até o término do processo completo de armazenamento. Deste modo, é garantido que quando a chamada ao método de armazenamento retorna, o arquivo já está armazenado no sistema. No modo quasi-síncrono, a thread que realizou a chamada permanece bloqueada até o término do processo de codificação dos fragmentos. Este modo garante que quando a chamada do método retorna, o processo de armazena- mento não depende mais dos dados fornecidos pela aplicação para armazenamento, permitindo que a aplicação continue sua execução e modifique estes dados. A aplicação pode ainda fornecer uma função de callback para que o access broker notifique a aplicação quando o processo de armazenamento ter- minar. Já no modo assíncrono, a chamada ao método retorna imediatamente. Neste caso, a aplicação pode fornecer duas funções de callback, uma para o término da codificação e outra para o término do
armazenamento. Neste modo, a aplicação não deve modificar os dados fornecidos para armazenamento enquanto o processo de codificação não for finalizado.
A recuperação de um arquivo pode ser realizada de modo síncrono ou assíncrono. No primeiro modo, a chamada ao método de recuperação só retorna quando o arquivo solicitado tiver sido integralmente recuperado. No segundo modo a chamada retorna imediatamente e a aplicação pode fornecer uma função de callback para ser notificada quando o arquivo tiver sido totalmente recuperado.
Integridade e segurança dos dados
A verificação de integridade dos dados é realizada aplicando o algoritmo de espalhamento seguro SHA-1 sobre o conteúdo do arquivo e dos fragmentos, armazenando-os no FFI. O sistema também permite que o conteúdo dos fragmentos seja criptografado, mas neste caso a aplicação ou usuário do sistema precisa fornecer uma chave que o access broker utiliza para criptografar os dados.
O OppStore não provê uma infra-estrutura para gerenciamento de chaves para a criptografia de dados e o cliente é responsável por fornecer as chaves criptográficas. Utilizamos esta abordagem porque os ambientes de grades computacionais normalmente já possuem uma infra-estrutura de segurança, que pode ser utilizada para gerenciar estas chaves.