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 1
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 Users Spell Checkers Spell Checkers Google Google Web Web Google Web Ad Ad Ad Front-end Processing Index Index Index Index Index Index Index Index D D D Dndex Document Core Processing BigTable Google File System Logical Dada View Physical Dada View 2
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) 3
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 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 8 4
Principais elementos: Clientes Master Chunkservers Arquitetura do GFS Os Masters mantém os meta-dados, incluindo o mapeamento da árvore de diretórios para os chunks 9 Arquitetura do GFS Duas etapas: 1. obter o chunk handle e locations; 2. obter dados contidos em um chunk 10 5
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. 11 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ó 12 6
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 7
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" 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) 8
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 9
Exemplo de Operação de escrita Fonte: S.Ghemawat, The Google File System 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 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) 10
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 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) 11
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 bemsucedida 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 Cliente B Secondary Replica 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) 12
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 Início do próximo append Cliente2 Estado indefinido Estado definido 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 13
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 Snapshot durante os testes: Testes de Desempenho Resultados: 14
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 15
Perguntas? Bibliografia: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung, The Google File System, OSDI 2004. 16