Google File System

O Google File System (GFS ou GoogleFS) é um sistema de arquivos distribuído proprietário desenvolvido pelo Google para fornecer acesso eficiente e confiável aos dados usando grandes clusters de hardware comum. O GFS foi substituído pelo Colossus em 2010.[1][2]

O Google File System (GFS) é uma solução que permite a comunicação eficiente entre diferentes sistemas computacionais, sem a necessidade de intervenção do usuário final. Além disso, o GFS garante a redundância dos dados por meio da replicação automática dos fragmentos em vários servidores

O GFS é projetado para interação de sistema a sistema, e não para interação de usuário a sistema. Os servidores de fragmentos replicam os dados automaticamente. O GFS é otimizado para as necessidades principais de armazenamento e uso de dados do Google (principalmente o mecanismo de pesquisa), que podem gerar enormes quantidades de dados que devem ser retidos.

Os arquivos são divididos em fragmentos de tamanho fixo de 64 megabytes, semelhantes a clusters ou setores em sistemas de arquivos regulares, que são raramente sobrescritos ou reduzidos; os arquivos geralmente são anexados ou lidos. Ele também é projetado e otimizado para rodar nos clusters de computação do Google, nós densos que consistem em computadores baratos "commodities", o que significa que precauções devem ser tomadas contra a alta taxa de falha de nós individuais e a subsequente perda de dados. Outras decisões de design selecionam altas taxas de transferência de dados, mesmo quando isso custa latência.

Um cluster GFS consiste em vários nós. Esses nós são divididos em dois tipos: um nó mestre e vários servidores de fragmentos. Cada arquivo é dividido em fragmentos. Os servidores de fragmentos armazenam esses fragmentos. Cada fragmento recebe um rótulo globalmente exclusivo de 64 bits pelo nó mestre no momento da criação, e mapeamentos lógicos de arquivos para fragmentos constituintes são mantidos. Cada fragmento é replicado várias vezes em toda a rede. Por padrão, ele é replicado três vezes, mas isso é configurável.[3]

O servidor mestre geralmente não armazena os fragmentos reais, mas sim todos os metadados associados aos fragmentos, como as tabelas que mapeiam os rótulos de 64 bits para locais de fragmentos e os arquivos que eles compõem (mapeamento de arquivos para fragmentos), os locais das cópias dos fragmentos, quais processos estão lendo ou escrevendo em um determinado fragmento ou tirando uma "instantâneo" do fragmento para replicá-lo (geralmente por instigação do servidor mestre, quando, devido a falhas nos nós, o número de cópias de um fragmento caiu abaixo do número definido). Todos esses metadados são mantidos atualizados pelo servidor mestre periodicamente recebendo atualizações de cada servidor de fragmento ("Mensagens de batimento cardíaco"). As permissões para modificações são tratadas por um sistema de "locações" limitadas no tempo e expirantes, onde o servidor mestre concede permissão a um processo por um período finito durante o qual nenhum outro processo receberá permissão do servidor mestre para modificar o fragmento.[4]

Referências

  1. Hoff, Todd (11 de setembro de 2010). «Google's Colossus Makes Search Real-Time by Dumping MapReduce». High Scalability. Cópia arquivada em 4 de abril de 2019 
  2. Ma, Eric (29 de novembro de 2012). «Colossus: Successor to the Google File System (GFS)». SysTutorials. Consultado em 10 de maio de 2016. Cópia arquivada em 12 de abril de 2019 
  3. Ghemawat, Gobioff & Leung 2003.
  4. Kyriazis, Dimosthenis (2013). Data Intensive Storage Services for Cloud Environments. [S.l.]: IGI Global. 13 páginas. ISBN 9781466639355 

Ligações externas

[editar | editar código-fonte]
  • «GFS: Evolution on Fast-forward», Queue, ACM .
  • «Google File System Eval, Part I», Storage mojo .