Armazenamento Distribuído Explicado: Como Funciona

O armazenamento distribuído de ficheiros distribui dados por muitos nós de forma a que nenhuma máquina seja um bottleneck ou um ponto único de falha. As escolhas de design — como colocar os dados, como replicá-los, como tratar falhas de nós, como manter consistência — distinguem sistemas como o Ceph (objeto/bloco/ficheiro), o GlusterFS (POSIX), o HDFS (batch de big data), o MinIO (compatível com S3) e sistemas com endereçamento por conteúdo como IPFS e Filecoin. Cada um tem como alvo cargas de trabalho diferentes, e os trade-offs são reais. Eis uma análise concreta de como estes sistemas funcionam efetivamente.

Replicação vs. Erasure Coding

Duas estratégias protegem contra falha de nó. A replicação armazena múltiplas cópias completas: o padrão do Ceph é replicação 3x, o que significa que um objeto de 1 GB usa 3 GB de armazenamento bruto. Simples de raciocinar, rápido de ler, dispendioso em armazenamento. O erasure coding divide os dados em k chunks de dados mais m chunks de paridade usando códigos Reed-Solomon, de modo que um esquema (10,4) armazena 14 chunks e tolera 4 falhas com apenas 40 por cento de overhead em vez de 200 por cento. O MinIO usa erasure coding por padrão; os Backblaze Vaults usam Reed-Solomon 17+3. As leituras com erasure coding são mais lentas porque a reconstrução pode precisar de múltiplos chunks, pelo que os dados quentes frequentemente usam replicação e os dados frios usam erasure coding.

Consistent Hashing e Colocação de Dados

Como decide um sistema qual o nó que armazena cada objeto? O consistent hashing, introduzido academicamente por Karger et al. (1997) e popularizado pelo DynamoDB e Cassandra, faz hash das chaves para um anel e mapeia cada intervalo para um nó. Adicionar ou remover um nó apenas redistribui uma fração das chaves, não o conjunto completo. O Ceph usa CRUSH (Controlled Replication Under Scalable Hashing), um algoritmo determinístico que coloca objetos com base num mapa de topologia (rack, fila, datacenter) para que as réplicas fiquem em domínios de falha diversos. Os nós virtuais (vnodes) por nó físico suavizam o desequilíbrio de carga.

Modelos de Consistência: Forte, Eventual e Causal

O teorema CAP diz que não se pode ter simultaneamente consistência, disponibilidade e tolerância a partições — escolhem-se dois. A consistência forte (linearizabilidade) significa que as leituras veem a escrita mais recente; sistemas como Spanner e etcd fornecem isto via protocolos de consenso como Paxos ou Raft. A consistência eventual (DynamoDB, Cassandra, S3 para algumas operações historicamente) significa que as réplicas convergem dado o tempo, com leituras obsoletas possíveis durante a propagação. A consistência causal preserva a ordem causa-efeito sem linearizabilidade completa. O armazenamento de ficheiros frequentemente aceita consistência eventual para metadados (listagem, tamanho) com consistência forte para leituras após escritas do mesmo objeto.

Arquitetura Ceph: OSDs, Monitores, Gestores e MDSes

O Ceph corre quatro tipos de daemon. Os OSDs (Object Storage Daemons) armazenam objetos e replicam-nos; um cluster tipicamente tem 10 a 1.000 OSDs em discos giratórios ou NVMe. Os Monitors (MONs) mantêm o estado do cluster via Paxos; 3 ou 5 MONs fornecem quórum. Os Managers (MGRs) expõem métricas e hospedam dashboards. Os MDSes (Metadata Servers) servem a camada de sistema de ficheiros POSIX do CephFS. O armazenamento de objetos via RADOS Gateway (RGW) apresenta APIs S3 e Swift. O armazenamento em bloco via RBD suporta volumes OpenStack e discos de VM. Uma base de código, três personalidades, afinadas com /etc/ceph/ceph.conf e edições do mapa CRUSH.

HDFS e o Seu Legado Hadoop

O HDFS (Hadoop Distributed File System) tem como alvo leituras sequenciais grandes para tarefas MapReduce e Spark. Os ficheiros dividem-se em blocos de 128 MB ou 256 MB; cada bloco replica 3x por padrão pelos DataNodes. Um NameNode mantém todos os metadados em memória, limitando a escala a aproximadamente 500 milhões de ficheiros por NameNode. O HDFS Federation e o HDFS Router adicionam suporte multi-namespace. O HDFS não é ótimo para ficheiros pequenos (os metadados dominam) ou compatibilidade POSIX, mas é excelente para análise de conjuntos de dados à escala de TB. Está também a ser substituído por armazenamento de objetos (S3, GCS) à medida que o cálculo se separa do armazenamento na era da nuvem.

Armazenamento com Endereçamento por Conteúdo: IPFS e Filecoin

O IPFS (InterPlanetary File System) identifica o conteúdo pelo seu hash (CID, Content IDentifier) em vez de pela localização. Qualquer pessoa que armazene um ficheiro com o mesmo conteúdo produz o mesmo CID. A recuperação usa uma DHT (Distributed Hash Table, baseada em Kademlia) para encontrar nós que detêm o conteúdo. O Filecoin adiciona incentivos económicos — os mineiros provam que estão a armazenar conteúdo via PoRep (Proof-of-Replication) e PoSt (Proof-of-Spacetime) e ganham tokens FIL. O IPFS é adequado para arquivo e publicação descentralizada (metadados NFT, sites web3); é lento para cargas de trabalho interativas devido à latência de pesquisa DHT (centenas de milissegundos a segundos).

Armazenamento de Objetos: S3, R2, B2 e MinIO

O armazenamento de objetos apresenta uma API chave-valor plana: faça PUT de um objeto com uma chave, GET para o recuperar. Sem diretórios, sem semântica POSIX. Esta simplicidade permite escala massiva — o AWS S3 armazena biliões de objetos com durabilidade de 11 noves. Clones como Cloudflare R2, Backblaze B2, Wasabi e DigitalOcean Spaces implementam a API S3 em backends diferentes. O MinIO corre on-premises como código aberto AGPL v3, frequentemente no Kubernetes como StatefulSet, fornecendo armazenamento compatível com S3 em hardware de commodity. O armazenamento de objetos ganhou em grande medida o mercado de armazenamento cloud porque a API é simples, os preços são claros e a durabilidade é fiável.

Erasure Coding na Prática: Como Funciona a Reconstrução

Quando um nó morre num sistema com erasure coding, os nós restantes reconstroem os chunks perdidos. Para um código Reed-Solomon (10,4), qualquer 10 dos 14 chunks reconstituem os 10 chunks de dados originais via álgebra matricial sobre um corpo finito. A carga de reconstrução recai sobre os nós sobreviventes, pelo que perder 1 nó num cluster de 100 desencadeia leituras de 10 outros nós por chunk perdido. A largura de banda durante a reconstrução é uma grande preocupação operacional. Sistemas como o Ceph limitam a taxa de reconstrução para evitar impactar o I/O de produção. Códigos mais recentes como os Local Reconstruction Codes (LRC, usados pelo Azure) e os códigos Hitchhiker reduzem a largura de banda de reconstrução ao permitir leituras parciais.

Latência de Cauda e Pedidos com Hedge

Os sistemas distribuídos têm caudas longas. Um pedido que atinge um disco lento ou rede congestionada pode demorar 10x a mediana. O artigo da Google "The Tail at Scale" (Dean & Barroso, 2013) formalizou técnicas: os hedged requests enviam leituras duplicadas para dois nós, cancelam o que perde; os tied requests coordenam de forma a que apenas um execute efetivamente. O Ceph, o DynamoDB e o Spanner usam variações. Para sistemas de transferência de ficheiros, ler um objeto via múltiplas réplicas em paralelo e tomar a primeira resposta reduz dramaticamente a latência p99 ao custo de ligeiramente mais largura de banda.

Domínios de Falha e Diversidade de Dados

Colocar três réplicas não ajuda se todas estiverem no mesmo rack e o switch top-of-rack do rack falhar. A consciência de domínios de falha significa que as réplicas ficam em racks, filas ou datacenters diferentes. As regras CRUSH do Ceph codificam "pelo menos 2 cópias em racks diferentes, 1 cópia noutro datacenter." O armazenamento de objetos cloud trata disto de forma transparente — o S3 Standard armazena em 3+ Availability Zones. Para replicação entre regiões, o S3 Cross-Region Replication (CRR) replica assincronamente objetos para outra região, útil para recuperação de desastres e conformidade com residência de dados regional.

Implicações Práticas para Serviços de Transferência de Ficheiros

Um serviço de transferência de ficheiros tipicamente assenta em armazenamento de objetos em vez de um sistema de ficheiros POSIX. Os backends compatíveis com S3 (AWS S3, Cloudflare R2, MinIO) tratam da durabilidade e escala sem que a equipa gira Ceph ou GlusterFS. O serviço adiciona autenticação, URLs pré-assinadas, metadados e funcionalidades voltadas para o utilizador. O HexaTransfer usa um backend compatível com S3 com encriptação AES-256-GCM do lado do cliente, de modo que a camada de armazenamento distribuído trata da durabilidade enquanto a camada da aplicação mantém o conteúdo dos ficheiros privado em cada nível.

Experimente em https://hexatransfer.com — gratuito, sem conta, máximo de 10 GB.