Em 1998, Sergey Brin e Lawrence Page publicaram o artigo “The Anatomy of a Large-Scale Hypertextual Web Search Engine” (A Anatomia de um Sistema de Busca Hipertextual de Larga Escala) e iniciaram a empresa que algum tempo depois se tornou um dos maiores casos de sucesso na história da Internet até aqui.

O Google, atualmente, detém mais de 65% do mercado de buscas nos Estados Unidos e em alguns países este número ultrapassa os 90%. Grande parte deste sucesso é atribuído ao inovador algoritmo de busca da empresa. O que permitiu que este sucesso acompanhasse a demanda por recursos de hardware, no entanto, foi o também inovador sistema de arquivos desenvolvido por ela: O Google File System ou simplesmente GFS.

Criado especificamente para o processamento de dados dentre os seus sistemas (busca, e-mail, documentos, etc.), o algoritmo garante a performance e a flexibilidade necessária para que a resposta ao usuário seja o mais próximo possível do instante e para que não haja interrupção dos serviços numa eventual falha em algum componente do sistema.

Embora publicamente disponível, o artigo publicado em 2003 que explica em detalhes o funcionamento do GFS está em inglês e possui muitas especificidades de implementação. Por este motivo resumo aqui os principais fatores que motivaram o seu desenvolvimento e exponho uma breve explicação sobre seu funcionamento.

Falhas são a regra

Bugs em aplicações e no Sistema Operacional, erros humanos e falhas de hardware (memória, disco, fonte de energia, etc.) são comuns principalmente em computadores desktop mas podem ocorrer em qualquer sistema. Entretanto estas falhas são muitas vezes tratadas como exceção e exigem ações de contingência quando ocorrem.

No caso do Google, os criadores do GFS foram muito cuidadosos ao admitirem que falhas no sistema ocorrem com freqüência suficiente para serem tratadas como regra. Isto porque o meio físico de armazenamento de dados da empresa é composto por centenas e as vezes milhares de computadores de baixo custo (Para dar uma idéia, máquinas com dois processadores PIII 1.4 GHz, 2GB RAM, 2 discos de 80GB e 5400 rpm, e uma placa Ethernet 100 Mbps full-duplex foram usadas num ambiente de teste para medição de performance pelo próprio Google). Esta enorme quantidade e a baixa qualidade dos equipamentos são o suficiente para garantir que alguma falha ocorrerá em algum momento.

Por este motivo, monitoramento constante, detecção de erros, tolerância a falhas, e recuperação automática são (e precisam ser) parte integrante do sistema.

Os arquivos só crescem

Para padrões tradicionais, os arquivos no GFS são gigantes e podem facilmente atingir a casa dos terabytes (mil gigabytes). Como resultado, operações de entrada e saída e o tamanho dos blocos em disco precisam ser revistos para lidar com eficiência com estes arquivos, mesmo que arquivos bem pequenos (de alguns kilobytes) sejam suportados.

Além disto, pouca informação é reescrita nestes arquivos. Na maioria dos casos, dados são acrescentados a eles. Escrita aleatória, portanto, praticamente não existe. Ou seja, uma vez escrito, o arquivo é acessado somente para leitura e sequencialmente.

É meu e eu mudo o que quiser, quando quiser

Um motivo mais estratégico do que técnico que levou o Google a escrever seu próprio algoritmo refere-se à flexibilidade de customizar a API. Isto permitiu à empresa elaborar o algoritmo desde o princípio pensando em suas próprias necessidades.

Um exemplo foi a introdução de uma operação atômica de adição de dados a um arquivo que garante que múltiplos clientes possam adicionar dados a um mesmo arquivo simultaneamente, sem a necessidade de sincronizações extras entre eles.

Interface Simples

A interface para utilização do GFS é bem simples e mantém a organização dos arquivos numa estrutura hierárquica de diretórios identificados por nomes. Os comandos típicos para criar, excluir, abrir, fechar, ler e escrever arquivos também estão lá.

Além destes, no entanto, o GFS introduziu os comandos snapshot e record append. O primeiro cria uma cópia de um arquivo ou diretório a um baixo custo de performance. O segundo, como dito anteriormente, permite que múltiplos clientes acessem simultaneamente o arquivo para adição de dados, garantindo a atomicidade de cada adição de cada cliente.

Arquitetura Robusta

O GFS trabalha com clusters, conjuntos de computadores interligados através de um sistema distribuído. Cada cluster possui um único master e vários chunkservers, tipicamente computadores desktop com Linux instalado.

O master é responsável pelo gerenciamento do cluster. Para isto, ele armazena meta dados sobre as informações armazenadas nos chunkservers. Isto inclui espaço de nomes (namespace), informações para controle de acesso, o mapeamento de arquivos em chunks (blocos de dados que podem conter um ou mais arquivos ou parte de um arquivo), e a localização atual destes blocos nos chunkservers – para garantir a consistência, cada bloco é replicado em múltiplos chunkservers.

As atividades desempenhadas pelo master incluem o gerenciamento da concessão de blocos para acesso pelo(s) cliente(s); um coletor de lixo para blocos órfãos; e a migração de blocos entre chunkservers.

A comunicação dos clientes com o master é minimizada às operações com os meta dados. Uma vez que um cliente tenha todas as informações necessárias para acesso aos dados, toda a comunicação passa a ser realizada diretamente com o(s) chunkserver(s).

Não há cache de dados devido ao imenso tamanho dos arquivos e porque cada bloco é armazenado como se fosse um arquivo local. Assim eles se beneficiam do buffer gerenciado pelo próprio Linux que mantém os arquivos acessados com freqüência na memória.

Os meta dados são armazenados na memória do master, tornando obviamente suas operações muito mais rápidas. Isto também permite que múltiplos threads executem com eficiência e ao mesmo tempo diferentes tarefas requeridas pelo sistema: Coletor de lixo, re-replicação na presença de falhas em um ou mais chunkservers, e migração de blocos entre os chunkservers para balancear a carga e o espaço em disco.

Tolerância a falhas

Assim como os blocos, o estado do master (isto é, seu log de operação e checkpoints) também é replicado em diferentes computadores. Por simplicidade, apenas um processo master fica responsável por todas as operações nos meta dados além das operações que mudam o sistema internamente, por exemplo o coletor de lixo.

Assim, numa eventual falha no próprio processo, ele pode simples ser reiniciado. Não há complexos processos em cadeia que precisam seguir uma ordem lógica de criação. Se a falha for física, uma infra-estrutura de monitoramento externa ao GFS inicia um novo processo master em algum outro computador com o log de operação replicado.

A integridade dos dados é verificada através de checksums nos próprios blocos. Por diversos motivos (grande quantidade de operações de escrita nos arquivos, seus tamanhos, etc.) as réplicas dos blocos não são idênticas. Por isto, cada chunkserver deve verificar a sua própria cópia de maneira independente, mantendo checksums.

Com milhares de discos e centenas de máquinas, é esperado que os dados se corrompam até com certa freqüência. Por este motivo, sempre que um chunkserver detecta um bloco corrompido, o mesmo é atualmente substituído pelo master por uma réplica válida disponível em outro chunkserver.

Conclusões

O que é interessante notar no GFS são suas premissas de design, completamente diferentes um sistema de arquivos tradicionais. O tratamento a falhas como regra, o foco do desempenho no controle e manuseio de grandes arquivos, e a extensão da interface indicam esta radical mudança de foco na implementação. Isto o torna uma importante ferramenta para entendimento dos requisitos necessários para a construção de um cluster de larga escala utilizando máquinas de baixo custo.

Embora publicado em 2003, é claro que o GFS está em constante evolução. O sistema foi tão bem recebido no Google que passou a ser utilizado em ambientes de produção, desenvolvimento, e pesquisa. Entre os novos recursos que foram incorporados ao sistema mais tarde estão um controle de permissões e um sistema de quotas.

No fim das contas, segundo os próprios autores do artigo original, o GFS acabou se tornando uma peça importante na manutenção da capacidade do Google de inovar e atacar problemas na escala de toda a web.

Este é um resumo e uma releitura do artigo The Google File System, escrito por Sanjay Ghemawat, Howard Gobioff, e Shun-Tak Leung, publicado em 2003 e disponível em http://labs.google.com/papers/gfs.html.