Apresentação sobre Google File System para a disciplina de Sistemas Distribuídos da UNIFESP SJC.

1. Google File
System
Aline Sonnewend Adriano
Thiago Gibin Franceschinelli
Instituto de Ciência e Tecnologia - ICT
UNIFESP - Universidade Federal de São Paulo
Professor: Dr. Arlindo Flavio da Conceição

2. Roteiro
● Sistemas de arquivos
● Google File System
● Princípio
● Arquitetura
● Funcionamento
● Consistência
● Escrita
● Operações do Master
● Tolerância a falhas

3. Sistemas de Arquivos
● Sistemas de Arquivos Convencional
○ Conjunto de rotinas e estruturas lógicas que
permitem ao sistema operacional gerenciar
arquivos. Fornece uma interface ao cliente através
da qual os dados são manipulados sem conhecer a
implementação.
■ JFS, EXT1, EXR2, FAT16, FAT32, NTSF

4. Sistemas de Arquivos
Distribuídos
● Sistemas de Arquivos Distribuídos
○ Fornece os mesmos recursos que o sistema de
arquivos convencional, porém, o acesso a
informação remota ou local é realizada de forma
transparente ao usuário
■ CODA, NFS, AFS, GFS (Google File System)

5. Google File System
● Sistema de arquivos desenvolvido e utilizado pela
Google;
● Escalável para aplicações de distribuição intensiva de
dados;
● A Google utiliza o GFS para organizar e manipular
grandes arquivos, além de permitir que aplicações
consigam usar os recursos necessários.
○ YouTube, Gmail, Google Maps . . .
● Atende milhões de usuários, tem petabytes de espaço
de armazenamento e tempo de resposta mínimo

6. Google File System
● Suporta enorme volume de dados
processados diariamente;
● Uso de muitas máquinas de baixo custo com
capacidade de armazenamento alta e suporte
a muitos acessos

7. Princípio
● Monitoramento constante para detecção de erros,
tolerância a falhas e recuperação automática de dados;
● O sistema armazena um modesto número de
arquivos grandes, tipicamente maiores que 100MB.
Alguns da ordem de GB e outros arquivos pequenos
são suportados, apesar de não serem otimizados.

8. Princípio
● Utiliza append em vez de reescrever dados existentes.
● Escritas seqüenciais
○ Garante leituras rápidas, já que os dados estão próximos
entre si.
● Implementa semântica para execução de comandos append
concorrentes.
● O acesso e a manipulação de dados tão grandes requer uma
rede que tenha uma alta largura de banda, favorecendo--a
em relação à baixa latência.

9. Arquitetura
Um cluster do GFS consiste de um único master e múltiplos
chunkservers que são acessados por múltiplos clientes

10. Funcionamento
● O GFS master tem como principal função
coordenar o cluster.
○ Informa o cliente onde está a localização de um
chunk nos chunkservers.
○ Os arquivos são divididos em chunks de 64MB,
bem maiores que o tamanho de bloco de um
sistema de arquivo usual.
■ Evita desperdício de espaço por causa da fragmentação
interna usando “lazy space allocation”.

11. Funcionamento
● O tamanho grande dos chunks:
○ Reduz comunicação com o mestre
■ Escritas e leituras no mesmo chunk requerem apenas um
pedido inicial da localização do chunk ao mestre.
○ Cliente realiza muitas operações num mesmo
chunk, o que reduz o overhead da rede.
○ Também reduz o tamanho do metadata armazenado
pelo master, possibilitando deixá-la em memória.

12. Funcionamento
● Mesmo com a lazy space allocation existem
desvantagens, como um hot spot
○ Chunks que são acessados por muitos clientes, por
causa de um mesmo arquivo.
■ Sobrecarrega os chunkservers que o possui
Solução: aumentar a replicação destes dados.
● O master armazena três tipos de metadata:
○ os namespaces de arquivos e chunks;
○ o mapeamento de arquivos em chunks;
○ a localização de cada réplica dos chunks.

13. Funcionamento
● Todo metadata é mantido na memória do master, garantindo
rapidez.
○ Ele não guarda um record persistente de quais chunkservers
possuem uma réplica de um chunk
■ Apenas pede aos chunkservers por informações quando
iniciado e se atualiza através de mensagens “Heartbeat”.
■ Assim elimina-se o problema de manter a
sincronização do master e chunkservers por causa de
eventos, como a entrada ou a saída de um chunkserver do
cluster.
● O log de operação é armazenado no disco local do master e
replicado em máquinas remotas.

14. Consistência
● Possui modelo de consistência relaxada
Write Record Append
Serial success defined defined interspersed
with inconsistent
Concurrent success consistent but undefined
Failure inconsistent
Consistência

15. Consistência
● Uma região de arquivo é consistente:
○ Se todos os clientes virem os mesmos dados,
independente de quais réplicas lidas.
○ Escritas que sofreram falhas deixam a região
inconsistente.
● Uma região é defined depois que uma
mutação de um arquivo for consistente e
os clientes virem que a mutação escreveu
no arquivo integralmente.

16. Consistência
● Uma mutação é uma operação que muda o conteúdo
de um chunk
○ Uma escrita ou record append
● Utiliza--se um sistema de leases para manter a
consistência das mutações entre as réplicas
○ Minimiza o overhead sobre o mestre.
● Basicamente, o mestre pega uma réplica como primária
e permite as mutações nela. Esta cópia define a
ordem das mutações que posteriormente são
seguidas pelas réplicas secundárias.

17. Escrita - parte 1
1. A aplicação origina um pedido de escrita;
2. O cliente GFS traduz o pedido (file name, data) para (file name,
chunk index) e manda ao master;
3. O mestre responde com o chunk handle e as localizações das
réplicas (primária e secundárias);

18. Escrita - parte 2
4. O cliente envia dados de escrita para todas as localidades. Os
dados são armazenados em buffers internos dos chunkservers;

19. Escrita - parte 3
5. O cliente manda o comando de escrita a réplica primária;
6. Esta réplica determina a ordem em série das instâncias dos dados
armazenados no buffer e escreve nesta ordem no chunk;
7. A primária manda a ordem aos secundários requisitando a escrita;

20. Escrita - parte 4
8. As secundárias respondem à primária;
9. A primária responde ao cliente:
a. Se uma escrita falhar num dos chunkservers, o cliente é
informado e a escrita é tentada novamente.

21. Operações do Master
● Armazenamento de metadata;
● Administração do namespace (locking);
● Comunicação periódica com os
chunkservers:
○ Dar instruções, coletar estados, verificar a saúde do
cluster
● Criar chunks;
● Re-replicar dados caso necessário;

22. Operações do Master
● Rebalanceamento de réplicas:
○ Feito periodicamente para melhorar a distribuição de
informações nos discos;
● Garbage collection:
○ Depois que um arquivo é deletado, o GFS não libera o espaço
físico imediatamente. O master escreve no log a operação e
renomeia o arquivo como um arquivo escondido, mantendo--o
por 3 dias. Até lá, o arquivo pode ser lido com o novo nome
ou até ser restaurado;
● Stale replica detection:
○ São garantidas versões dos chunks para distinguir quais estão
atualizadas e quais não.

23. Tolerância a falhas
● Falhas são frequentes e podem resultar em arquivos
corrompidos ou queda do sistema
○ Estratégias adotadas:
■ Restauração rápida
■ Replicação
● Masters e chunkservers reiniciam e a restauram em
segundos
● Replicação de chunks em servers de diferentes racks
garantem segurança

24. Tolerância a falhas
● Shadow masters podem ser acessados por leitura caso
o master caia
● Garante integridade de dados
○ Checksumming de chunk dividido em vários de 64KB
● Chunkservers podem escanear chunks inativos (pouco
usados)
● Em caso de arquivo corrompido, cria réplica não antiga
e deleta antiga

25. Curiosidades
● Mais de 15.000 computadores simples;
● São múltiplos clusteres distribuídos por todo o
mundo;
● Milhares de consultas executadas por segundo;
● Cada consulta lê centenas de MB’s de dados e
consome dezenas de bilhões de ciclos de CPU;
● Google tem dúzias de cópias de toda a Web!

26. Referências Bibliográficas
● GHEMAWAT, Sanjay, GOBIOFF, Howard, LEUNG, Shun-Tak.
The Google File System, http://research.google.com/archive/gfs.
html. Acessado em 04 de agosto de 2013
● KUMAR, Avinashi, GFS - The Google File System, http://www.
slideshare.net/guest2cb4689/google-file-system. Acessado em 04
de agosto de 2013