o google file system
Post on 12-Feb-2017
260 Views
Preview:
TRANSCRIPT
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
Fonte: S.Ghemawat, The Google File System
Exemplo de Operação de escrita
Fonte: S.Ghemawat, The Google File System
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
Fonte: S.Ghemawat, The Google File System
Fluxo de controle vs fluxo de dados
Fonte: S.Ghemawat, The Google File System
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?
top related