O Google File System

1

Armazenamento de Dados na Nuvem Google:

O Google File System

Markus Endler PUC-Rio

Agenda

Características da Infra-estrutura Google Novos Requisitos Arquitetura Interação entre os componentes Operações de leitura e escrita Operação de anexação Modelo de Consistência Anexação concorrente Operação de log Testes de Desempenho

2

Características da Intra-estrutura Google Milhares de PCs em um cluster

>1000 PCs com disco, >300 TB total de espaço Distribuição massiva de processamento

Cada PC é montado a partir de componentes comuns e baratos

Acesso contínuo a dados por centenas de clientes Vários tipos de falha em cada nó:

Bugs da aplicação, bugs do sistemas operacional Falha humana Falhas de disco, de memória, de rede, de fornecimento de

energia Falhas em conectores

Falhas ocorrem sempre! Por isso, monitoramento, tolerância a falhas e

recuperação automática são elementos essenciais de um FS

Visão Geral

© Markus Endler

Google Web Servers

Ad Servers

Google Web Servers Google Web Servers

Ad Servers Ad Servers Spell Checkers Spell Checkers

Index Servers Index Servers Index Servers Index Servers Index Servers Index Servers Index Servers Index Servers

D DServers DServers Dndex Servers Document Servers

BigTable

Google File System

Logical Dada View

Physical Dada View

Core Processing

Front-end Processing

Users

3

Tipos de Arquivos e Padrões de Acesso

Projeto do GFS foi guiado por observações sobre padrões de acesso a dados que diferem dos princípios tradicionais de sistemas de arquivos distribuídos (DFSs)

Maioria dos arquivos são enormes (multi-GB); cada um com milhares de objetos de aplicação (p.ex. páginas web)

Trabalha-se com conjuntos de dados que crescem rapida- e continuamente

Maioria dos arquivos sofre modificacões apenas na forma de anexações concorrentes

Escritas em pontos aleatórios (random write) praticamente não ocorrem

Arquivos são lidos de forma sequencial Isso vale para:

Dados de entrada, intermediários e resultados dados de arquivos, dados estatísticos, fluxos (streams) de dados

Foco do GFS: Operação de anexação e garantias de atomicidade com o mínimo de custo de sincronização

Evitando caches, pode-se relaxar os requisitos de consistência

Principais Requisitos do Projeto

Devido alta taxa de falhas, é necessário monitorar, detectar e se recuperar de falhas de forma extremamente eficiente

O sistema hospeda um número modesto de arquivos de multiplos GBs

Workload de leitura: leituras de grandes blocos de dados de streams, e.g cada

read envolve >1 MB reads de um mesmo cliente geralmente são sequenciais Seek pra frente e pra trás são raríssimos

Workload de escrita: Writes sequenciais de grandes blocos de dado Writes, em sua grande maioria, são simples anexações

(escritas no final)

4

Principais Requisitos de Projeto

Sistema precisa tratar acessos massivamente concorrentes Garantir atomicidade com o mínimo de overhead de

sincronização Grande largura de banda (taxa de acesso) sustentada

é mais importante do que baixa latência de acesso Usar abstrações convencionais (hierarquia de diretórios

e path names) Prover uma API simples do tipo UNIX (create, delete,

open, close, read, write) e Mais 2 operações super-otimizadas:

log snapshot e record append

8

Arquitetura do GFS

Um master server (seu estado é replicado em backups)

Centenas/milhares de chunk servers Espalhados por vários racks; São processos de usuário Linux; Chunk = bloco de 64 MB, identificado por um ID global de

64-bits; Arquivo = formado por 1+ chunks Cada chunk é replicado em 3 chunk servers (default), mas

usuário pode definir número de réplicas; Milhares de clientes acessam arquivos hospedados

em diferentes nós

5

9

Arquitetura do GFS

Os Masters mantém os meta-dados, incluindo o mapeamento da árvore de diretórios para os chunks

Principais elementos: • Clientes • Master • Chunkservers

10

Arquitetura do GFS

Duas etapas: 1. obter o chunk handle e locations; 2. obter dados contidos em um chunk

6

11

Master Server Armazena todos os metadados em memória, incluindo:

Hierarquia de diretórios Informações para controle de acesso (por arquivo) Mapeamento de arquivo → conjunto de chunks Localização de cada chunk nos chunkservers

Metadados em memória garantem acesso rápido, Faz a coleta de lixo de chunks órfãos (com < # de réplicas) Controla a migração de chunks entre chunkservers Comunica-se periodicamente com os chunkservers (Heartbeat)

para atualizar metadados, enviar comandos e receber status

Master logicamente centralizado simplifica muito as estratégias de alocação e replicação de chunks, baseadas em conhecimento global do sistema.

12

Cliente GFS

Código que implementa a API do GFS e é ligado à aplicação Faz a comunicação inicial com o master para consultar meta-dados,

i.e. conhecer os chunkservers responsável pelo chunk Interage com o(s) chunkserver(s) diretamente para as escritas e

leituras Clientes não fazem o cache de chunks

overhead de manter a consistência não vale a pena para o padrão de acesso predominante

Clientes fazem o cache de meta-dados (por tempo limitado) Em especial, a localização dos chunks nos chunk servers

Geralmente, cliente consulta master server por vários chunks de uma vez só

7

Exemplo Interação Cliente-Master

Fonte: S.Ghemawat, The Google File System

Cliente traduz (FileName,offset) → chunkIndex do arquivo envia (fileName,chunkIndex) p/ master e recebe chunkHandle cacheia esse handle, indexado por (fileName,chunkIndex) Interage com chunkserver mais próximo indicando (chunkhandle, faixa de bytes)

Chunk server Armazena chunks de 64MB no disco local como

arquivo convencional do FS Linux (+ número de versão e checksum)

Chunk server não faz cache dos dados lidos, exceto pelo buffer cache padrão do Linux

Atende requisições do Master para: Informar...

quais são os chunks que hospeda seu status (de acesso ao seu disco)

criar novos chunks remover alguns de seus chunks

8

Interação Master-Chunk server O Master não persiste a informação sobre qual

chunkserver hospeda uma réplica de um chunk. "Em vez disso, faz uma consulta regular (Heartbeat)" para obter estado dos chunk servers:"

Chunkserver está operacional? " Houve falhas de disco no chunkserver? " Existem réplicas de chunks corrompidas?" Quais réplicas de chunk o chunkserver hospeda?"

para enviar comandos:" Remover determinado chunk" Criar determinado chunk"

Isso facilita gerenciar o dinamismo do conjunto de chunkservers"

© Markus Endler

Determinação de Chunk Server Primário/Secundário

Gerenciamento é feito através de leases, dados pelo Master

O primário define uma ordem serial, e todos os secundários adotam essa ordem

Um Lease: • expira a cada 1 minuto, mas pode ser aumentado • pode ser revogado (quando Master desconfia de

falha do primário)

9

Exemplo de Operação de leitura


Exemplo de Operação de escrita


1. Cliente envia bloco de dados para todos os chunk servers 2. Dados são armazenados em buffer local de cada chunk server

10

Exemplo de Operação de escrita

5. cliente envia uma requisição de escrita (write request – wr) para servidor primário.

6. chunkserver primário atribui número serial ao wr, e encaminha o wr com esse número serial para os chunk servers secundários;

7. Todos chunkservers secundários confirmam escrita ao primário; 8. chunkserver primário responde ao cliente; 9. se escrita falha em um chunkserver, cliente é notificado e tenta

novamente


Fluxo de controle vs fluxo de dados


Fluxo de Controle: Mestre Primário Secundários Fluxo de dados: Envio para o mais próximo de uma cadeia de chunk

servers, e em sequência linear para os demais (otimizando a largura de banda inter- e intra-cluster)

11

© Markus Endler

Operação de Anexação Record Append é uma operação muito comum e

importante: Para combiar/mesclar resultados de vários

processamentos (de vários nós) Uso de Arquivos como se fosse uma fila entre

produtores e consumidores Centenas de produtores “anexadores” concorrentes Bloco de dados do cliente é copiado como um todo

(atomicamente), e não como vários writes menores Cliente1

Cliente2

© Markus Endler

Operação de Anexação Algoritmo: 1. Aplicação gera uma requisição de anexação. 2. Cliente GFS traduz requsição e envia para o master server, que

responde com o chunk handle e localização dos ch-servers primário e secundários)

3. Cliente envia dados para todos ch-servers (como no wr). 4. Primário verifica se dados cabem no chunk 5. Se couber, adiciona no final, manda secundários fazerem o

mesmo, espera confirmação e informa cliente 6. Se não couber, faz padding no final do chunk, manda

secundários fazerem o mesmo, espera confirmação, e notifica cliente que não coube.

7. Nesse caso, cliente refaz o record append no próximo chunk (possivelmente criando um novo chunk)

12

© Markus Endler

Modelo de Consistência Mutações do espaço de arquivos são tratadas pelo Master, que

garante a sua atomicidade (veremos mais adiante) Estado das atualizações em chunks dependem da execução bem-

sucedida de possíveis anexações concorrentes. Como os chunk servers de um chunk específico são atualizados em

ordem diferente por diferentes clientes, a depender da proximidade do cliente (vide fluxo de dados), durante certo tempo, os chunks podem apresentar regiões com conteúdo indefinido.

Cliente A

Secondary Replica

Primary Replica

Secondary Replica

Cliente B

© Markus Endler

Modelo de Consistência Uma região de um arquivo está:

Consistente ⇔ todos clientes enxergam dados idênticos independente de qual réplica acessam

Definida ⇔ é consistente e todos conseguem ver o resultado de todas as escritas em sua totalidade

Indefinida ⇔ é consistente, todos clientes veem os mesmos dados, mas visão (ainda) não reflete uma sequência coerente das escritas (e.g. fragmentos mesclados de diferentes escritas)

Em caso de falhas, uma modificação pode deixar uma região temporariamente inconsistente (clientes podem ver dados diferentes em momentos diferentes)

O GFS permite que as aplicações diferenciem regiões definidas e indefinidas (regiões ainda não estáveis pelos anexações concorrentes)

13

© Markus Endler

Anexações Concorrentes Cada anexação (possivelmente, uma de várias concorrentes) é

garantidamente uma adição atômica, pelo menos uma vez, de um bloco de dados ao chunk;

Porém, o offset (local exato) da escrita é definido pelo GFS (pode ser diferente do esperado pelo cliente)

O offset retornado para o cliente () determina o fim de uma região indefinida que contém o bloco de dados escrito, mas o GFS poderá ter intercalado paddings, frações de blocos, ou blocos replicados.

No final de uma sequência de k anexações com sucesso, a região modificada do arquivo garantidamente torna-se definida e contendo os dados adicionados pelas k anexações.

Cliente1

Cliente2

Início do próximo append

Estado indefinido Estado definido

© Markus Endler

Operação de Log Master e chunkservers são projetados para reiniciar e restaurar

estado em poucos segundos Chunks estão replicados e Master determina a realocação de

chunks Mas os metadados?

O log de operação mantém um registro histórico de todas as mudanças em metadados

O log também define uma ordem total das operações concorrentes

Faz-se um checkoint periódico do log O log e os checkpoints são replicados em múltiplos nós O Estado do Master (seus metadados) é replicado em vários

masters de backup distribuídos em vários racks, que entram em ação se o Master principal falhar

Requisições de clientes só são respondidas quando o log tiver sido atualizado em todos Masters backup

14

© Markus Endler

Testes de Desempenho Em dois clusters: Cluster A: Para pesquisa e desenvolvimento Usuários: >100 engenheiros Tarefas inciadas por usuários, e executam algumas horas; Cada tarefa tipicamente lê MB’s-TB’s de dados, transforma os

mesmos, e escreve resultados de volta no GFS Cluster B: Uso em produção Tarefas típicas exeutam dias/semanas. Continuamente geram e processam conjuntos de dados de

múltiplos TBs Nenhuma interferência humana Obs: os clusters estavam executando aproximadamente uma

semana quando os dados foram coletados

© Markus Endler

Testes de Desempenho Snapshot durante

os testes:

Resultados:

15

© Markus Endler

Testes de Desempenho Durante os testes: Ambos clusters estavam com alta atividade de leitura Cluster B também estava no meio de uma rajada de

escritas. Em ambos, o Master recebia 200-500 requisições por

segundo e não mostrou ser o gargalo.

Testes com falhas: Um chunkserver do cluster B foi parado (kill), e continha

15.000 chunks totalizando 600 GB de dados. O Cluster apresentou uma limitação:

só foi capaz de clonar ≈ 90 clones em paralelo Cada operação de clonagem consome ≅ 6.25 MB/s. Demorou 23 minutos para recompor todos os 15000 chunks Note que isso equivale a 440 MB/s

Conclusão O GFS suporta processamento de dados em larga escala usando

hardware coum (commodity hardware) Trata falhas de componentes como normais, e não como excessão. Otimizado para grandes arquivos, e operação de anexação (por

escritores concorrentes) Define vários estágios de consistência dos dados anexados Tolerância a falhas:

Monitoramento continuo Replicação de dados cruciais (p.ex. Metadados) Checksums de partes do chunk para detectar corrupção dos dados

em nível de disco Garantir alta vazão, desacoplando o fluxo de controle do fluxo de

dados

© Markus Endler

16

Bibliografia:

Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung, The Google File System, OSDI 2004.

Perguntas?

Documents

O Google File System