CMG Brasil

Pomegranate é um novo sistema de arquivo distribuído construído sobre armazenamento tabular distribuído que age muito como um sistema NoSQL. Ele tem como objetivo aumentar a performance do acesso a pequenos objetos para suportar aplicações como serviços de foto e microblog online, que requerem alta concorrência, alta taxa de transferência e baixa latência. Seus testes parecem indicar que funciona:

Demonstramos que o sistema de arquivos sobre armazenamento tabular funciona bem para acessos altamente simultâneos. Em nosso cluster de testes, observamos um aumento linear de mais de 100.000 pedidos agregados de leitura e escrita atendidos por segundo (RPS).

Sentado no topo do sistema de arquivo como quase todas as outras lojas K-V, a romã é cozida no sistema de arquivo. A ideia é que a API do sistema de ficheiros é comum a todas as plataformas, pelo que não necessitaria de uma API separada para utilizar. Cada aplicação poderia usá-la fora da caixa.

As características da Pomegranate são:

• Lida com bilhões de pequenos arquivos de forma eficiente, mesmo em um diretório;
• Proporciona uma camada de cache separada e escalonável, que pode ser capaz de ser capturada em instantâneos;
• A camada de armazenamento usa armazenamento estruturado em log para absorver a gravação de pequenos arquivos para utilizar a largura de banda do disco;
• Build um namespace global tanto para arquivos pequenos quanto para arquivos grandes;
• Armazenamento de colunas para explorar a localidade temporal e espacial;
• Distribuir hash extensível para indexar metadados;
• Cache reconfigurável e com capacidade de instantâneos para aumentar o paralelismo e falhas tolerantes;
• Pomegranate deve ser o primeiro sistema de arquivos que é construído sobre armazenamento tabular, e a experiência de construção deve ser digna para a comunidade de sistemas de arquivos.

Can Ma, que lidera a pesquisa sobre o Pomegranate, foi gentil o suficiente para concordar com uma pequena entrevista.

Pode por favor dar uma visão geral da arquitectura e do que está a fazer que é fixe e diferente?

Basicamente, não existe um sistema de ficheiros distribuído ou paralelo que consiga lidar com milhares de milhões de pequenos ficheiros de forma eficiente. No entanto, podemos prever que aplicações web (como e-mail, foto e até vídeo), e bio-computing (sequenciamento de genes) necessitam de acessos massivos a pequenos ficheiros. Enquanto isso, a API do sistema de arquivos é suficientemente geral e bem compreendida pela maioria dos programadores.

Assim, queremos construir um sistema de arquivos para gerenciar bilhões de pequenos arquivos, e fornecer alta taxa de transferência de acessos simultâneos. Embora o Pomegranate seja projetado para acessos a arquivos pequenos, ele também suporta arquivos grandes. Ele é construído sobre outros sistemas de arquivos distribuídos, como o Lustre, e só gerencia o namespace e os arquivos pequenos. Queremos apenas ficar em “Os Ombros dos Gigantes”. Veja a figura abaixo:

Pomegranate tem muitos Servidores de Metadados e Servidores de Armazenamento de Metadados para servir pedidos de metadados e pedidos de leitura/gravação de pequenos arquivos. Os MDSs são apenas uma camada de cache, que carregam metadados do armazenamento e enviam instantâneos da memória para o armazenamento. O núcleo do Pomegranate é um sistema de armazenamento tabular distribuído chamado xTable. Suporta pesquisas chave indexadas de várias colunas. Usamos hash extensível distribuído para localizar o servidor a partir da chave, porque o hash extensível é mais adaptável à escala para cima e para baixo.

Em sistemas de arquivo, tabela de diretório e tabela inode são sempre separados para suportar dois tipos diferentes de busca. Pesquisas por nome de caminho são tratadas por tabela de diretório, enquanto pesquisas por número de inode são tratadas por tabela inode. É não trivial atualizar consistentemente estes dois índices, especialmente em um sistema de arquivo distribuído. Enquanto isso, usar dois índices aumentou a latência da pesquisa, o que é inaceitável para acessar pequenos arquivos. Tipicamente, existem em caches de memória para dentry e inode, no entanto, os caches não podem se estender facilmente. A modificação de metadados tem de actualizar múltiplas localizações. Para manter a consistência, é introduzido o registo de operações. Enquanto, o log de operações é sempre um ponto serial para fluxos de requisição.

Pomegranate usa uma estrutura de diretório semelhante a uma tabela para fundir tabela de diretório e tabela inode. Dois tipos diferentes de buscas são unificados para buscas por chave. Para o sistema de arquivo, a chave é o valor de hash do nome de dentry. Os conflitos de hash são resolvidos por uma identificação global única para cada arquivo. Para cada actualização, só precisamos de pesquisar e actualizar uma tabela. Para eliminar o registro de operações, nós projetamos e suportamos o snapshot de memória para obter uma imagem consistente. As regiões sujas de cada snapshot podem ser escritas com segurança no armazenamento sem considerar modificações simultâneas.(As atualizações simultâneas são COWed.)

No entanto, existem algumas operações complexas de sistema de arquivos como mkdir, rmdir, hard link, e renomear que devem ser consideradas. Estas operações têm de actualizar pelo menos duas tabelas. Nós implementamos um serviço confiável de atualização multisite para propagar deltas de uma tabela para outra. Por exemplo, em mkdir, propagamos o delta(“nlink +1”) para a tabela pai.

Existe algum ponto de falha?

Não há SPOF no design. Usamos cluster de MDSs para atender a solicitação de metadados. Se um MDS falhar, as solicitações são redirecionadas para outros MDSs (são usados hash e batimentos cardíacos consistentes). Metadados e pequenos arquivos são replicados para múltiplos nós também. No entanto, esta replicação é acionada por ferramentas externas de sincronização que são assíncronas com as escritas.

Os pequenos arquivos geralmente têm sido a morte dos sistemas de arquivos por causa da manutenção da estrutura de diretórios. Como contornar isso?

Yep, é mortalmente lento para o acesso a pequenos arquivos em sistemas de arquivos tradicionais. Nós substituímos a tabela de diretórios tradicionais (árvore B+ ou árvore hash) para distribuir a tabela de hash extensível. O nome dentry e os metadados inode são tratados como colunas da tabela. Pesquisas de clientes são enviadas (ou roteadas, se necessário) para o MDS correto. Assim, para acessar um pequeno arquivo, precisamos apenas acessar uma linha da tabela para encontrar a localização do arquivo. Nós mantemos cada pequeno arquivo armazenado sequencialmente no sistema de arquivos nativo. Como resultado, um acesso I/O pode servir um pequeno arquivo lido.

Que posix apis são suportados? Os ficheiros podem ser bloqueados, mapeados, links simbólicos, etc?

No momento, o suporte POSIX está a progredir. Nós suportamos symlinks, acesso mmap. Enquanto isso, não há suporte a flocos.

Porquê fazer um sistema de ficheiros ao nível do kernel em vez de uma loja K-V no topo?

O nosso objectivo inicial é implementar um sistema de ficheiros para suportar mais aplicações existentes. Enquanto isso, nós suportamos a interface K/V no topo da xTable agora. Veja a figura da arquitetura, o cliente AMC é o cliente chave/valor para o Pomegranate. Nós suportamos previsões simples sobre chave ou valor, por exemplo, suportamos “select * from table where key < 10 and ‘xyz’ in value” para obter os pares k/v que contém “xyz” e chave < 10.

How does it compare to other distributed filesystems?

We want to compare the small file performance with other file systems. No entanto, nós ainda não o testamos. Fá-lo-emos no próximo mês. Embora, acreditamos que a maioria dos sistemas de ficheiros distribuídos não consegue lidar com acessos massivos a pequenos ficheiros de forma eficiente.

Indices de ficheiros e qualquer tipo de consultas suportadas?

Por enquanto, estes suportes ainda não foram devidamente considerados. Pretendemos considerar a consulta de intervalo a seguir.

Faz funcionar através de datacenters, ou seja, como lida com a latência?

Pomegranate só funciona em um datacenter. O suporte a WAN ainda não foi considerado.

Parece que você usa uma arquitetura in-memory para velocidade. Você pode falar sobre isso?

Usamos uma camada de cache de memória dedicada para velocidade. As linhas da tabela são agrupadas em fatias de tabela. Na memória, a tabela sl
ices são agrupadas em uma tabela de hash extensível local tanto para performance quanto para consumo de espaço. Mostrado pela figura abaixo,

Clientes emitem pedido por hash o nome do arquivo e busca no bitmap. Então, usando um anel de hash consistente para localizar o servidor cache (MDS) ou servidor de armazenamento (MDSL). Cada atualização primeiro recebe o grupo de transação *aberta*, e pode ser aplicada apenas à linha da tabela na memória. Cada mudança de grupo de transação é atômica. Após todas as atualizações pendentes serem concluídas, o grupo de transações pode ser comprometido com o armazenamento em segurança. Esta abordagem é similar à do ZFS.

Como é tratada a alta disponibilidade?

Bem, o servidor central para gerenciamento consistente de hash ring e coordenador de falhas deve ser replicado pelo algoritmo Paxos. Nós planejamos usar o ZooKeeper para serviço central de alta disponibilidade.
Outros componentes são projetados para serem tolerantes a falhas. Crashes do MDS e MDSL podem ser configurados como recuperados imediatamente ao rotear pedidos para novos servidores (selecionando o próximo ponto em hash ring consistente).

Operacionalmente, como funciona? Como os nós são adicionados ao sistema?

Adicionar nós para a camada de cache é simples. O servidor central (R2) adiciona o novo nó ao anel de hash consistente. Todos os servidores de cache devem agir sobre esta alteração e apenas invalidar suas fatias de tabela em cache se elas serão gerenciadas pelo novo nó. Pedidos de clientes são roteados para o novo servidor, e uma notificação de mudança de anel CH irá piggyback para o cliente para puxar o novo anel do servidor central.

Como você lida com arquivos grandes? É adequado para streaming de vídeo?

Como descrito anteriormente, arquivos grandes são retransmitidos para outros sistemas de arquivos distribuídos. Nossa camada de cache não será poluída pelos dados do streaming de vídeo.

Qual outra coisa você gostaria de adicionar?

Outra figura para interação dos componentes do Pomegranate.