Almacenamiento distribuido explicado: cómo funciona
Comprende los sistemas de almacenamiento distribuido como IPFS y Ceph: replicación, consistencia y tolerancia a fallos en el almacenamiento moderno.
El almacenamiento distribuido de archivos reparte los datos entre muchos nodos para que ninguna máquina sea un cuello de botella ni un único punto de fallo. Las decisiones de diseño —cómo colocar los datos, cómo replicarlos, cómo gestionar los fallos de nodos, cómo mantener la consistencia— distinguen sistemas como Ceph (objeto/bloque/archivo), GlusterFS (POSIX), HDFS (procesamiento masivo de datos), MinIO (compatible con S3) y sistemas de contenido direccionado como IPFS y Filecoin. Cada uno apunta a cargas de trabajo diferentes, y los compromisos son reales. Aquí hay un recorrido concreto por cómo funcionan realmente estos sistemas.
Replicación frente a codificación de borrado
Dos estrategias protegen contra los fallos de nodos. La replicación almacena múltiples copias completas: el valor predeterminado de Ceph es la replicación 3x, lo que significa que un objeto de 1 GB usa 3 GB de almacenamiento sin procesar. Sencillo de entender, rápido de leer, caro en almacenamiento. La codificación de borrado divide los datos en k fragmentos de datos más m fragmentos de paridad usando códigos Reed-Solomon, de modo que un esquema (10,4) almacena 14 fragmentos y tolera 4 fallos con solo un 40 por ciento de sobrecarga en lugar del 200 por ciento. MinIO usa codificación de borrado por defecto; Backblaze Vaults usa Reed-Solomon 17+3. Las lecturas de codificación de borrado son más lentas porque la reconstrucción puede necesitar múltiples fragmentos, por lo que los datos calientes suelen usar replicación y los datos fríos usan codificación de borrado.
Hash consistente y colocación de datos
¿Cómo decide un sistema qué nodo almacena qué objeto? El hash consistente, introducido en el trabajo académico de Karger et al. (1997) y popularizado por DynamoDB y Cassandra, hashea las claves en un anillo y mapea cada rango a un nodo. Añadir o eliminar un nodo solo redistribuye una fracción de las claves, no todo el conjunto de datos. Ceph usa CRUSH (Controlled Replication Under Scalable Hashing), un algoritmo determinista que coloca objetos basándose en un mapa de topología (rack, fila, datacenter) para que las réplicas terminen en dominios de fallo diversos. Los nodos virtuales (vnodes) por nodo físico suavizan el desequilibrio de carga.
Modelos de consistencia: fuerte, eventual y causal
El teorema CAP dice que no puedes tener consistencia, disponibilidad y tolerancia a particiones simultáneamente: eliges dos. La consistencia fuerte (linearizabilidad) significa que las lecturas ven la última escritura; sistemas como Spanner y etcd la ofrecen mediante protocolos de consenso como Paxos o Raft. La consistencia eventual (DynamoDB, Cassandra, S3 para algunas operaciones históricamente) significa que las réplicas convergen dado el tiempo, con lecturas obsoletas posibles durante la propagación. La consistencia causal preserva el orden causa-efecto sin linearizabilidad completa. El almacenamiento de archivos a menudo acepta la consistencia eventual para los metadatos (listado, tamaño) con consistencia fuerte para las lecturas posteriores a escrituras del mismo objeto.
Arquitectura de Ceph: OSDs, Monitores, Managers y MDSes
Ceph ejecuta cuatro tipos de daemons. Los OSDs (Object Storage Daemons) almacenan objetos y los replican; un clúster normalmente tiene 10 a 1.000 OSDs en discos spinning o NVMe. Los Monitores (MONs) mantienen el estado del clúster mediante Paxos; 3 o 5 MONs proporcionan quórum. Los Managers (MGRs) exponen métricas y alojan paneles de control. Los MDSes (Metadata Servers) sirven la capa de sistema de archivos POSIX CephFS. El almacenamiento de objetos mediante RADOS Gateway (RGW) presenta las APIs S3 y Swift. El almacenamiento en bloque mediante RBD respalda los volúmenes de OpenStack y los discos de VM. Una base de código, tres personalidades, ajustadas con /etc/ceph/ceph.conf y ediciones del mapa CRUSH.
HDFS y su legado de Hadoop
HDFS (Hadoop Distributed File System) apunta a las lecturas secuenciales grandes para trabajos de MapReduce y Spark. Los archivos se dividen en bloques de 128 MB o 256 MB; cada bloque se replica 3x por defecto entre los DataNodes. Un NameNode mantiene todos los metadatos en memoria, limitando la escala a aproximadamente 500 millones de archivos por NameNode. La Federación HDFS y el Router HDFS añaden soporte multi-namespace. HDFS no es bueno para archivos pequeños (los metadatos dominan) ni para la compatibilidad POSIX, pero es excelente para el análisis de conjuntos de datos a escala de TB. También está siendo desplazado por el almacenamiento de objetos (S3, GCS) a medida que el cómputo se separa del almacenamiento en la era cloud.
Almacenamiento con dirección de contenido: IPFS y Filecoin
IPFS (InterPlanetary File System) identifica el contenido por su hash (CID, Content IDentifier) en lugar de por su ubicación. Cualquiera que almacene un archivo con el mismo contenido produce el mismo CID. La recuperación usa una DHT (Distributed Hash Table, basada en Kademlia) para encontrar los nodos que tienen el contenido. Filecoin añade incentivos económicos —los mineros prueban que almacenan el contenido mediante PoRep (Proof-of-Replication) y PoSt (Proof-of-Spacetime) y ganan tokens FIL. IPFS encaja para el archivo y la publicación descentralizada (metadatos NFT, sitios web3); es lento para cargas de trabajo interactivas debido a la latencia de búsqueda DHT (cientos de milisegundos a segundos).
Almacenamiento de objetos: S3, R2, B2 y MinIO
El almacenamiento de objetos presenta una API de clave-valor plana: PUT un objeto con una clave, GET de vuelta. Sin directorios, sin semántica POSIX. Esta simplicidad permite una escala masiva: AWS S3 almacena billones de objetos con una durabilidad de 11 nueves. Los clones como Cloudflare R2, Backblaze B2, Wasabi y DigitalOcean Spaces implementan la API S3 en diferentes backends. MinIO se ejecuta en las instalaciones como código abierto AGPL v3, a menudo en Kubernetes como un StatefulSet, proporcionando almacenamiento compatible con S3 en hardware estándar. El almacenamiento de objetos ha ganado en gran medida el mercado de almacenamiento cloud porque la API es simple, los precios son claros y la durabilidad es confiable.
Codificación de borrado en la práctica: cómo funciona la reconstrucción
Cuando un nodo muere en un sistema con codificación de borrado, los nodos restantes reconstruyen los fragmentos perdidos. Para un código Reed-Solomon (10,4), cualquier 10 de los 14 fragmentos reconstruyen los 10 fragmentos de datos originales mediante álgebra de matrices sobre un campo finito. La carga de reconstrucción recae en los nodos supervivientes, por lo que perder 1 nodo en un clúster de 100 desencadena lecturas de otros 10 nodos por fragmento perdido. El ancho de banda durante la reconstrucción es una preocupación operativa importante. Los sistemas como Ceph limitan la velocidad de reconstrucción para evitar impactar en la I/O de producción. Los códigos más nuevos como los Códigos de Reconstrucción Local (LRC, usados por Azure) y los códigos Hitchhiker reducen el ancho de banda de reconstrucción permitiendo lecturas parciales.
Latencia de cola y peticiones con cobertura
Los sistemas distribuidos tienen largas colas. Una petición que llega a un disco lento o una red congestionada podría tardar 10 veces la mediana. El artículo "The Tail at Scale" de Google (Dean y Barroso, 2013) formalizó técnicas: las peticiones con cobertura envían lecturas duplicadas a dos nodos, cancelando la que pierde; las peticiones coordinadas garantizan que solo una se ejecute realmente. Ceph, DynamoDB y Spanner usan variaciones. Para los sistemas de transferencia de archivos, leer un objeto en paralelo desde múltiples réplicas y tomar la primera respuesta reduce drásticamente la latencia p99 al coste de algo más de ancho de banda.
Dominios de fallo y diversidad de datos
Colocar tres réplicas no ayuda si las tres están en el mismo rack y falla el switch top-of-rack del rack. La conciencia del dominio de fallo significa que las réplicas aterrizan en diferentes racks, filas o datacenters. Las reglas CRUSH de Ceph codifican "al menos 2 copias en diferentes racks, 1 copia en un datacenter diferente". El almacenamiento de objetos cloud gestiona esto de forma transparente: S3 Standard almacena en 3 o más zonas de disponibilidad. Para la replicación entre regiones, S3 Cross-Region Replication (CRR) replica objetos de forma asíncrona a otra región, útil para la recuperación ante desastres y el cumplimiento de la residencia de datos regional.
Implicaciones prácticas para los servicios de transferencia
Un servicio de transferencia de archivos normalmente se construye sobre almacenamiento de objetos en lugar de un sistema de archivos POSIX. Los backends compatibles con S3 (AWS S3, Cloudflare R2, MinIO) gestionan la durabilidad y la escala sin que el equipo ejecute Ceph o GlusterFS. El servicio añade autenticación, URLs prefirmadas, metadatos y funcionalidades orientadas al usuario. HexaTransfer usa un backend compatible con S3 con cifrado de extremo a extremo con AES-256-GCM del lado del cliente, de modo que la capa de almacenamiento distribuido gestiona la durabilidad mientras la capa de aplicación mantiene el contenido del archivo privado en cada nivel.
Pruébalo en https://hexatransfer.com — gratuito, sin cuenta, hasta 10 GB.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo