MogileFS es una de las primeras respuestas de código abierto a un problema que toda gran plataforma web acaba encontrando: ¿cómo almacenar decenas de millones de archivos de usuarios de forma fiable y económica, sin comprar una SAN ni confiar en un solo disco? Esta guía explica qué es MogileFS, cómo funciona su arquitectura, en qué se diferencia de alternativas modernas como Ceph y los almacenes compatibles con S3, y cómo dimensionar un clúster real en servidores dedicados.
En una frase: MogileFS es un sistema de archivos distribuido de código abierto y a nivel de aplicación que guarda cada archivo como varias réplicas completas repartidas en nodos independientes, usando una base MySQL para rastrear dónde vive cada copia, ofreciendo tolerancia a fallos sin RAID ni almacenamiento compartido.
MogileFS de un vistazo
| Propiedad | Detalle |
|---|---|
| Tipo | Sistema de archivos distribuido a nivel de aplicación / almacén de objetos |
| Autor original | Brad Fitzpatrick — Danga Interactive (el equipo de LiveJournal) |
| Primera versión | Mediados de los 2000 (desarrollado ~2004 para LiveJournal) |
| Escrito en | Perl (lado servidor) |
| Licencia | Software libre — los mismos términos GPL / Artistic que Perl |
| Metadatos | MySQL (la única fuente de verdad de las ubicaciones) |
| Demonio de almacenamiento | mogstored — sirve datos por HTTP / WebDAV |
| Demonio coordinador | mogilefsd (el tracker) |
| Modelo de acceso | Por clave opaca mediante biblioteca cliente — no es un montaje POSIX |
| Redundancia | Replicación de archivos completos (copias configurables), sin RAID |
| Carga ideal | Blobs write-once / read-many servidos por HTTP |
La idea central: sin RAID, sin punto único de fallo
El almacenamiento tradicional compra fiabilidad con hardware — matrices RAID, controladoras duales, filers compartidos caros. MogileFS toma el camino opuesto: asumir que el hardware es barato y fallará, y obtener la fiabilidad del software. Cada archivo se guarda como una o varias réplicas completas en nodos independientes. No hay striping ni paridad que reconstruir. Si un disco muere, las copias en otros nodos siguen completas y un proceso en segundo plano simplemente vuelve a replicar hasta restaurar el número de copias deseado.
Como opera a nivel de aplicación y no como sistema de archivos del kernel, MogileFS no se monta como NFS ni ofrece semántica POSIX. Las aplicaciones se comunican con él a través de una biblioteca cliente y direccionan los archivos por una clave opaca, no por una ruta. Ese compromiso es lo que le permite escalar horizontalmente en discos corrientes de servidores dedicados económicos.
Los cuatro componentes
| Componente | Demonio / tecnología | Rol | ¿Guarda estado? |
|---|---|---|---|
| Tracker | mogilefsd | Coordinador sin estado: responde "¿dónde está la clave X?", asigna ubicaciones de escritura, programa la replicación | No |
| BD de metadatos | MySQL | Única fuente de verdad: archivo → dispositivos, dominio, clase, estado de replicación | Sí — respáldala |
| Nodo de almacenamiento | mogstored | Demonio HTTP/WebDAV ligero con los datos en sistemas de archivos locales normales | Solo datos |
| Cliente | biblioteca (Perl, PHP, Python, Ruby, Java, Go) | Guarda/lee/borra por clave; lee y escribe directamente en los nodos | No |
Como todo el estado compartido vive en MySQL, los trackers son sin estado e intercambiables: se ejecutan varios para alta disponibilidad y cualquiera atiende cualquier petición. La CLI administrativa, mogadm, registra hosts, dispositivos, dominios y clases. La base de metadatos es el único componente que debes proteger: ponla en almacenamiento fiable y replícala (normalmente MySQL primario/réplica).
¿Buscas un servidor que simplemente funcione?
Valebyte VPS — NVMe, soporte 24/7, despliegue en 60 segundos.
Dominios, clases y replicación
MogileFS organiza los archivos en dominios (espacios de nombres, p. ej. uno por aplicación) y clases dentro de un dominio. Una clase lleva una política de replicación — sobre todo su mindevcount, el número mínimo de dispositivos distintos en los que debe copiarse un archivo de esa clase. Un replicador en segundo plano compara constantemente la realidad con los metadatos y crea o mueve copias hasta que cada archivo cumple su política de clase. Ese mismo mecanismo autorrepara el clúster tras el fallo de un nodo o disco.
| Clase de ejemplo | mindevcount | Uso típico | Sobrecoste de almacenamiento |
|---|---|---|---|
| thumbnails | 2 | Derivados regenerables baratos | 2× |
| user_uploads | 3 | Originales irreemplazables | 3× |
| cache | 1 | Datos transitorios y regenerables | 1× |
El objetivo de durabilidad tiene un coste directo: una clase con mindevcount=3 triplica la capacidad bruta que debes aprovisionar. Ese número es el mayor determinante del disco que necesitará tu clúster — planifícalo antes de comprar nodos.
Cómo se escribe un archivo
- El cliente pide al tracker crear un archivo nuevo en un dominio/clase dado.
- El tracker elige dispositivos adecuados y devuelve URLs temporales de escritura.
- El cliente hace
PUTde los datos directamente a uno o varios nodos por HTTP. - El cliente indica al tracker que la escritura terminó; el tracker registra la ubicación y la clave del archivo en MySQL.
- De forma asíncrona, el replicador asegura que el archivo alcance el número completo de réplicas de su clase en dispositivos separados.
«MogileFS es nuestro sistema de archivos distribuido de código abierto. Sus propiedades incluyen: a nivel de aplicación — sin módulos de kernel especiales; sin punto único de fallo; replicación automática de archivos; mejor que RAID; espacio de nombres plano.»
— Danga Interactive, descripción original del proyecto MogileFS
MogileFS frente a Ceph, GlusterFS y S3/MinIO
MogileFS es anterior a la mayor parte del stack actual de almacenamiento distribuido y ocupa un nicho deliberadamente estrecho. Así se compara con las herramientas con las que más se le enfrenta:
| Sistema | Tipo | Acceso | ¿Montaje POSIX? | Redundancia | Mejor para |
|---|---|---|---|---|---|
| MogileFS | FS a nivel de app | Clave vía cliente / HTTP | No | Réplicas completas | Blobs write-once/read-many a escala |
| Ceph (RADOS/RGW) | Objeto + bloque + FS | S3/Swift, RBD, CephFS | Sí (CephFS) | Replicación o erasure coding | Propósito general, escala exabyte |
| GlusterFS | FS distribuido POSIX | Montaje (FUSE/NFS) | Sí | Volúmenes replicados / dispersos | Sistema de archivos POSIX compartido |
| MinIO / S3 | Almacén de objetos | API S3 | No | Erasure coding | Apps modernas compatibles con S3 |
Si necesitas un sistema de archivos POSIX montable, lecturas/escrituras aleatorias de baja latencia o una API S3 estándar, otra opción es mejor. Si quieres específicamente almacenamiento de blobs por réplicas completas, simple, que tolere la pérdida de nodos sin RAID y escale añadiendo discos baratos, MogileFS sigue haciéndolo con limpieza.
¿Buscas un servidor que simplemente funcione?
Valebyte VPS — NVMe, soporte 24/7, despliegue en 60 segundos.
Dónde encaja MogileFS — y dónde no
Encaja muy bien: subidas de usuarios, galerías de imágenes, adjuntos de correo, activos estáticos — todo lo que se direcciona por un ID y se sirve por HTTP, escrito una vez y leído muchas. Sus fortalezas son el escalado horizontal barato, la tolerancia al fallo de nodos sin RAID y la simplicidad operativa para esa carga.
Encaja mal: un sistema de archivos POSIX montable, lecturas/escrituras aleatorias de baja latencia, modificación frecuente in situ o semántica transaccional fuerte. Usa CephFS, GlusterFS o un almacén compatible con S3.
Ejecutar MogileFS en servidores dedicados
Un despliegue de producción mínimo quiere al menos dos nodos de almacenamiento en máquinas físicas separadas (para que una clase con dos réplicas sobreviva a la pérdida de un host completo), más dos trackers y un par MySQL replicado para los metadatos. Cada nodo de almacenamiento es solo discos baratos y un mogstored en marcha; escalas añadiendo más. Es exactamente la carga que encaja con varios servidores dedicados independientes en dominios de fallo separados, no con una sola máquina grande — quieres aislamiento de disco y red, no un chasis compartido.
Para la capa de almacenamiento importa más la capacidad por dólar que la velocidad bruta, así que los servidores dedicados HDD de gran capacidad o los servidores de almacenamiento dedicados son el hogar natural de las réplicas. Coloca el nodo MySQL de metadatos y los trackers en servidores dedicados NVMe más rápidos, y si las réplicas abarcan varios sitios, aprovisiona servidores dedicados de 10 Gbps para que la re-replicación tras un fallo no sature los enlaces. Estos son servidores dedicados actuales sobre los que podrías montar nodos de almacenamiento:
| CPU | RAM | Almacenamiento | Ancho de banda | Precio | Acción |
|---|---|---|---|---|---|
| Intel Xeon-E 2136 3.3GHz 6 cores | 32 GB DDR4 ECC | 2x 512 GB (NVME SoftRAID) | Unmetered @ 1 Gbps | $59.00/mo | Configurar |
| Intel Xeon-D 2141I 2.2GHz 8 cores | 128 GB DDR4 ECC | 2x 512 GB (NVME SoftRAID) | Unmetered @ 1 Gbps | $74.00/mo | Configurar |
| AMD Ryzen 5 3600X 3.8GHz 6 cores | 64 GB DDR4 ECC | 2x 512 GB (NVME SoftRAID) | Unmetered @ 500 Mbps | $97.00/mo | Configurar |
| Intel Xeon-E 2386G 3.5GHz 6 cores | 32 GB DDR4 ECC | 2x 512 GB (NVME SoftRAID) | Unmetered @ 1 Gbps | $111.00/mo | Configurar |
| AMD Ryzen 7 3800X 3.9GHz 8 cores | 64 GB DDR4 ECC | 2x 960 GB (NVME SoftRAID) | Unmetered @ 500 Mbps | $127.00/mo | Configurar |
| AMD Ryzen 5 5600X 3.7GHz 6 cores | 64 GB DDR4 ECC | 2x 512 GB (NVME SoftRAID) | Unmetered @ 1 Gbps | $127.00/mo | Configurar |
| Intel Xeon-E 2388G 3.2GHz 8 cores | 32 GB DDR4 ECC | 2x 6 TB + 2x 512 GB (SATA Hybrid SoftRAID) | Unmetered @ 3 Gbps | $127.00/mo | Configurar |
| AMD Epyc 7371 3.1GHz 16 cores | 128 GB DDR4 ECC | 2x 6 TB + 2x 960 GB (SATA Hybrid SoftRAID) | Unmetered @ 1 Gbps | $161.00/mo | Configurar |
| AMD Ryzen 7 5800X 3.8GHz 8 cores | 64 GB DDR4 ECC | 2x 960 GB (NVME SoftRAID) | Unmetered @ 1 Gbps | $161.00/mo | Configurar |
| AMD Ryzen 9 5900X 3.7GHz 12 cores | 32 GB DDR4 ECC | 2x 4 TB (SATA SoftRAID) | Unmetered @ 1 Gbps | $165.00/mo | Configurar |
| Intel Xeon Silver 4214R 2.4GHz 12 cores | 96 GB DDR4 ECC | 2x 6 TB + 2x 960 GB (SATA Hybrid SoftRAID) | Unmetered @ 2 Gbps | $180.00/mo | Configurar |
| AMD Ryzen 7700X | 64GB ECC DDR5 | 2x 1 TB (NVMe) | 100TB @ 3Gbps | $207.00/mo | Configurar |
| AMD Epyc 7313 3.0GHz 16 cores | 1 TB DDR4 ECC | 2x 6 TB + 2x 960 GB (SATA Hybrid SoftRAID) | Unmetered @ 1 Gbps | $286.00/mo | Configurar |
| AMD Ryzen 7 Pro 3700 3.6GHz 8 cores | 32 GB DDR4 ECC | 6x 14 TB (SAS SoftRAID) | Unmetered @ 1 Gbps | $295.00/mo | Configurar |
| AMD EPYC 4464P 3.7GHz 16 cores | 128 GB DDR4 ECC | 4x 7.68 TB (NVME SoftRAID) | Unmetered @ 5 Gbps | $304.00/mo | Configurar |
Dimensionamiento sugerido de nodos
| Rol | CPU | RAM | Disco | Red |
|---|---|---|---|---|
| Nodo de almacenamiento (mogstored) | Modesto (2–4 núcleos) | 8–16 GB | HDD/SSD grande, JBOD — sin RAID | 1–10 Gbps |
| Tracker (mogilefsd) | 2–4 núcleos | 4–8 GB | SSD/NVMe pequeño | 1 Gbps+ |
| MySQL de metadatos | 4+ núcleos | 16 GB+ | NVMe (fiable, replicado) | 1 Gbps+ |
Preguntas frecuentes
¿Sigue MogileFS mantenido y en uso en 2025?
MogileFS es maduro y estable más que en evolución activa. Sigue siendo una opción sólida y probada para su nicho — almacenamiento de blobs de gran volumen sobre hardware común — aunque los almacenes de objetos y los sistemas de archivos en clúster más nuevos han asumido la mayoría de los casos de uso generales.
¿Usa MogileFS RAID?
No. MogileFS evita deliberadamente el RAID y en su lugar mantiene varias copias completas de cada archivo en dispositivos y hosts separados. El proyecto lo describía históricamente como «mejor que RAID», porque un disco o nodo perdido se repara re-replicando desde las copias supervivientes en lugar de reconstruir una matriz.
¿Puedo montar MogileFS como un sistema de archivos normal?
No en el sentido habitual. Es un almacén a nivel de aplicación al que se accede por clave mediante una biblioteca cliente o por HTTP; no ofrece semántica POSIX ni montaje del kernel. Si necesitas un sistema de archivos montable, usa GlusterFS o CephFS.
¿Qué base de datos requiere MogileFS?
Una base MySQL guarda todos los metadatos — qué archivos existen y en qué dispositivos viven sus réplicas. Los trackers no tienen estado; la instancia MySQL es el componente que debes respaldar y hacer altamente disponible.
¿Cuántos servidores necesito para empezar?
Para redundancia real, al menos dos nodos de almacenamiento en hosts físicos separados, más al menos un tracker y una instancia MySQL (dos de cada para alta disponibilidad). Dos servidores dedicados independientes bastan para sobrevivir al fallo de un host completo con una clase de dos réplicas.
¿Buscas un servidor que simplemente funcione?
Valebyte VPS — NVMe, soporte 24/7, despliegue en 60 segundos.
Nota histórica y referencias
MogileFS surgió del stack de ingeniería de LiveJournal de mediados de los 2000 y, junto con memcached, Perlbal y Gearman, se convirtió en un bloque de construcción conocido para escalar grandes propiedades web sobre hardware común. Hoy sigue siendo una opción fiable para su nicho. Fuentes primarias recomendadas: la página y el código del proyecto MogileFS (originalmente en danga.com/mogilefs y ahora en GitHub), el cliente Perl en MetaCPAN y los artículos de arquitectura de Danga Interactive de la era LiveJournal.
