The Google File System Mycke Richard Guntijo 1, Renato G. Borges Júnior 1, Tauan Nascimento de Almeida 1 1 Instituto de Informática Universidade Federal de Goiás (UFG) Caixa Postal 131 CEP 74001 970 Goiânia GO Brazil {myckeguntijo,renatojunior,tauanalmeida}@inf.ufg.br Abstract. With the growing wave of cloud storage is now a need to create good file systems capable of organizing huge clusters (lot of computers working together as one). The Google File System is a file system meant to organize files in this kind of network. With help of systems like Linux (controlling machines individually) the GFS organize files in clusters of Google simulating only one machine. Resumo. Com a crescente onda de armazenamento em nuvens é preciso criar bons sistemas de arquivos capazes de organizar enormes clusters (aglomerados de computadores que trabalham como um). O Google File System é um sistema de arquivos voltado para organização de arquivos neste tipo de rede. Com a ajuda de sistemas Linux (controlam máquinas individualmente) o GFS organiza arquivos nos clusters do Google simulando apenas um máquina. 1. Introdução No Google nada é pequeno: petabytes de dados, milhões de usuários, clusters espalhados por todo o mundo, milhares de buscas por segundo, na qual cada uma pode ler centenas de MB ou mais de informações. Com tantas informações, falhas são comuns e a manutenção de todo o sistema torna-se bastante complexa e difícil. Para garantir que seus serviços e aplicações conseguissem atender a crescente demanda, viu-se necessário desenvolver um sistema de arquivos capaz de armazenar e gerenciar todas estas informações e, ao mesmo tempo, garantir requisitos de alta performance, tolerância a falhas e escalabilidade. O Google File System (GFS) foi projetado com este intuito e atendeu claramente aos objetivos. O GFS é um sistema de arquivos distribuído que roda em maquinas comuns, mas que consegue suprir várias necessidades de hardware. Ele é propriedade exclusiva da empresa Google e não está a venda, de fato nem todos os detalhes sobre a sua arquitetura são conhecidos pelo público fora da Google, porém eles próprios se dispuseram a escrever um documento sobre o seu projeto [1] e que serviu de enorme base para este trabalho. Na seção 2 explicamos os principais aspectos da arquitetura necessária para armazenar e gerir as informações. Na seção 3 serão vistas as operações que o sistema de arquivos deve fornecer e como suas implementações refletem no desempenho. Por fim na seção 4 descrevemos como é garantida um dos principais requisitos do sistema, a tolerância a falhas.
2. Arquitetura O GFS cluster é um sistema distribuído com um servidor master com informações sobre os arquivos e chunkservers que armazenam os arquivos em si. Cada chunkserver possui vários chunks. A figura 1 mostra uma visão geral da arquitetura do GFS, nesta seção discutiremos os seus principais componentes: como é encontrado o caminho do cliente até o arquivo solicitado, tamanhos de chunk e motivação, metadados e funcionamento dos masters servers. Figure 1. principais componentes da arquitetura do GFS. Retirado de [1]. 2.1. Chunk e chunkservers No GFS os arquivos são divididos em chunks, que funcionam como blocos de um sistema de arquivos convencional. O master atribui ao chunk um cabeçalho de exatos 64 bits que serve para a identificação única e global do chunk. Cada chunk tem exatamente 64 MB (chunk size), ou seja, são bem maiores que um bloco comum. Definir um tamanho maior trás algumas vantagens, como a diminuição da comunicação cliente/servidor, pois será feita apenas uma requisição por parte do cliente para se fazer leitura e escrita, um cliente poderá fazer várias operações em apenas um chunk possibilitando assim que seja estabelecida um conexão TCP persistente e, como com tamanho maior temos menos chunks teremos também menos metadados, possibilitando que toda as informações guardadas no servidor acima seja colocada em memória. Um possível problema pode ocorrer se vários clientes usarem os arquivos de um mesmo chunk, sobrecarregando o chunkserver que o armazena. A solução para este problema é a replicação dos dados em chunksevers distintos para que o acesso seja distribuído. Os chunksevers armazenam os chunks. Cada chunkserver é implementado em uma plataforma Linux e os arquivos são salvos como arquivos Linux comuns, logo fica a cargo do sistema Linux as operações de sistemas de arquivos na máquina (como leitura e escrita em disco) possibilitando que o chunk server abstraia estas tarefas.
2.2. Metadata Nos chunks ficam guardados os arquivos em si, mas todas suas informações ficam nos masters em arquivos conhecidos como metadados. Os principais metadados guardados no masters são o nome do arquivo e do chunk onde se encontra esse arquivo, um arquivo com mapeamento de arquivos para chunks e a localização de cada chunk e suas réplicas. Os metadados são guardados em memória nos masters para que as operações implementadas sejam executadas de forma mais rápida possível. Para evitar falta de memória o garbage collection (funcionamento detalhado na seção3.5) faz verificações de tempos em tempos, é feita uma replicação de erros no chunkserver e a alguns chunk podem ser mudados de local para evitar desfragmentação. Como dito na seção 2.1 o cabeçalho do chunk é relativamente pequeno (64 bytes), e como os masters armazenam somente essa informação sobre cada chunk, logo mesmo com todas as informações em memória dificilmente se terá falta de memória em um master. 2.3. Master servers Como já dito, os chunk e os chunkservers só armazenam dados dos clientes e localização de chunk dentro das máquinas, e não dados de controle, como caminho até ele ou falhas que possam ter ocorrido no chunkserver. Essas informações, conhecidas como metadados, ficam armazenadas em servidores chamados masters, onde cada um deles aponta para vários chunkservers distintos. Como todas as informações sobre os chunk estão no master é com ele que a aplicação se comunica primeiramente para obter endereço, nome e outras informações sobre chunks. Essas informações são devolvidas a aplicação e assim ela se comunica com o chunkserver para obter o que deseja. Não há armazenamento persistente de endereços de chunk, sendo que o master só requisita essa informação do chunkserver quando necessário, evitando a necessidade de sincronização entre chunksevers e o master em caso de atualizações ou na inicialização da máquina. Os masters também definem onde um chunk será alocado, exclui chunks que não são mais usados e armazena estados sobre cada chunksever, por exemplo se há falha em algum disco do chunksever, se alguma réplica está corrompida e outros. Um arquivo de log é armazenado no disco do master que contém informações sobre todas as mudanças críticas ocorridas nos metadados. Tal log é utilizado para atualizar o estado do master de forma mais simples e segura. A operação de alterar o log é uma operação de alto risco, pois em caso de erro o master terá informações erradas sobre os chunkserver, logo essa é uma operação de prioridade alta e sempre é feita antes de operações de usuários e sem pausas. 3. Operações O GoogleFS suporta operações como criar, deletar, fechar, ler e escrever arquivos. Além disso possui operações de captura instantânea (snapshots) e gravação anexa (record append). Chamamos de mutação as operações de escrita e record append que mudam o conteúdo do metadata de um chunk.
Nas operações de escrita, o Master pega uma réplica como primária e permute as mutações nela. E depois a ordem das mutações são seguidas posteriormente pelas secundárias. 3.1. Leitura As figuras 2 e 3 explicam os passos realizados em uma solicitação de leitura: 1 - Aplicação informa (file name, byte range) para o Cliente GFS. 2 - Cliente GFS traduz o pedido da aplicação para (file name, chunk index). 3 - Master responde para o Cliente GFS com (chunk handle, replica locations). Figure 2. Passos da leitura. Retirado de [2]. 4 - Cliente GFS manda para os Chunk Servers (chunk handle, byte range). 5 - Chunk Servers respondem com o dado do arquivo. 6 - Enfim, o Cliente GFS manda para aplicação o dado solicitado. Figure 3. Passos da leitura. Retirado de [2].
3.2. Gravação As figuras 4, 5, 6 e 7 explicam os passos realizados em uma operação de escrita: Na figura 4: 1 - Aplicação faz 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, primary and secondary replica locations), localizações das réplicas. Figure 4. Passos da gravação. Retirado de [5]. Na figura 5: 4 - O cliente envia dados de escrita para todas as localidades. Os dados são armazenados em buffers internos dos chunkservers. Figure 5. Passos da gravação. Retirado de [2]. 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. Figure 6. Passos da gravação. Retirado de [2]. Na figura 7: 8 - As secundárias respondem à primária. 9 - A primária responde ao cliente. Figure 7. Passos da gravação. Retirado de [2]. No caso de falha da escrita em um dos chunkservers o cliente recebe uma notificação e tenta novamente. 3.3. Snapshot Cria cópias de um arquivo ou uma árvore de diretório com baixo custo, ou seja, quase que em tempo real para minimizar interrupções de mudanças. É uma operação de alta prioridade, logo se um master recebe uma solicitação para executar um snapshot ele para as gravações pendentes e o executa.
3.4. Record append Permite que vários clientes gravem no mesmo local ao mesmo tempo garantido atomicidade, ou seja, os arquivos não ficarão fragmentados. Isso é possível, pois diferentemente de escritas comuns o cliente informa somente os arquivos a serem gravados e fica a cargo do GFS escolher o espaço para gravação do arquivo. Fortemente utilizado em aplicações distribuídas onde clientes adicionam o mesmo arquivo de forma concorrente. 3.5. Garbage collector No GFS quando a exclusão física não é feita imediatamente depois da exclusão lógica. Assim, de tempos em tempos (quando é feita uma operação log) o garbage collector faz uma varredura nos níveis de chunks afim de procurar dados já excluídos a mais de três dias (padrão, mas que pode ser alterado) e depois efetivamente liberar o local, até lá o arquivo pode ser lido com um novo nome ou até ser restaurado. Mesmo sendo uma operação demorada este método torna a exclusão mais simples e mais confiável. 4. Tolerância a falhas Uma das maiores dificuldades de implementar um sistema de arquivos distribuído é fazê-lo tolerante a falhas. A possibilidade de erros aumenta já que o sistema fica sujeito não apenas a falhas na própria máquina, mas também a problemas de comunicação e transmissão. A tolerância a falhas foi implementada no GFS com base em dois princípios: alta disponibilidade e integridade de dados. Quando ambos satisfeitos, pelo menos em teoria, o sistema é capaz de fornecer um serviço continuo e sem erros. 4.1. Alta disponibilidade Manter centenas de servidores disponíveis o tempo todo é quase impossível, por isso duas estratégias são usadas para manter o sistema disponível o máximo possível. 4.1.1 Recuperação rápida Em caso de erros ou terminações incorretas os servidores devem ser capazes de recuperar o seu estado e reiniciar em questão de segundos. De fato não há diferenciação entre uma terminação normal e anormal. 4.1.2 Replicação Nessa estratégia replicas dos servidores são usadas para recuperar dados de chunk server que podem ficar offlines ou no caso de detecção (através de verificação de checksum) de dados corrompidos. Até mesmo os master servers também possuem os logs. A replicação não apenas garante uma maior confiabilidade ao sistema, mas também permite que os servidores enviam os dados para os clientes em paralelo já que a mesma informação pode estar armazenada em várias máquinas diferentes. 4.2. Integridade de dados Para verificara a corretude dos dados armazenados é usado a técnica de soma de verificação para determinar se o que foi armazenado está correto.
Como as operações de append são intensamente usadas, as replicas geralmente não estão exatamente iguais ao chunkserver principal, por isso comparar os dois não é o ideal para manter a integridade dos dados. Cada bloco de 64 KB em um chunkserver possuem uma soma de verificação de 32 bits que são mantidas na memória. Em operações de leitura a integridade é mantida da seguinte forma: quando uma requisição de leitura é feita para um chunkserver, ele verifica o checksum sobre os dados lidos, se um erro é encontrado o chunkserver avisa ao master e ao cliente do erro. O cliente agora requisita os dados de uma replica enquanto o master corrige os dados incorretos do chunkserver com a replica correta dos dados. Operações de append apenas é necessário atualizar a antiga soma de verificação incrementando a nova soma. Quando o bloco termina e é necessário utilizar um novo a soma é calculada para os bytes restantes dos dados. 4.3. Ferramentas de diagnóstico Detalhados logs de problemas e bugs ajudam a identificar e corrigir uma enorme gama de problemas. Também permitem isolar o problema, fazer análise de desempenho e debugging. Para este intuito ferramentas de diagnóstico são muito usadas no GFS principalmente pelo fato de que logs podem ser gerados com baixo custo e impacto na performance, além de poderem ser removidos sempre que necessário sem danificar o sistema. 5. Conclusão Como dissemos no inicio, o GFS atendeu as principais propostas que motivaram a sua criação: desempenho, tolerância a falhas e escalabilidade. Como um sistema distribuído bem projetado, atender aos requisitos de performance e escalabilidade se torna mais fácil, porém é o principal ponto na arquitetura, já que a complexidade do projeto aumenta. A performance também é garantida pelas observações de que as principais operações feitas sobre os arquivos são de read e append, o que permite desenvolvê-las com maior eficiência do que operações pouco usadas, além de permitir às aplicações ler e escrever em paralelo. Por ser muito utilizado, o GFS é tolerante a falhas já que isso afeta diretamente a performance, confiabilidade e segurança do sistema. Vimos que as falhas são evitadas ao atender dois pontos importantes, alta disponibilidade e integridade de dados, além de fornecer ferramentas de diagnóstico que permitem isolar e encontrar problemas rapidamente. No geral o GFS é de fácil manutenção e barata, além de ser uma ferramenta que permite ao Google construir aplicações de grande porte, como eles próprios mencionaram em [1] ele (Google File System) é uma ferramenta importante que permite-nos continuar a inovar e atacar problemas na escala de toda a internet. References [1] http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com /pt-br//papers/gfs-sosp2003.pdf
[2] http://www.uio.no/studier/emner/matnat/ifi/inf5100/h10/undervisningsmateriale/gfs.pdf