¿Qué es un sistema operativo distribuido y cuándo conviene usarlo?

Veredicto rápido: cuándo conviene y cuándo sobra

Un sistema operativo distribuido (DOS, por Distributed Operating System) convierte un conjunto de máquinas en una sola a ojos del software. Conviene cuando la disponibilidad pesa más que el dinero, y sobra casi siempre que un único servidor bien dimensionado aguante la carga.

• Si montas un servicio con SLA alto (comercio electrónico, banca, reservas), un DOS te da redundancia real y migración de procesos entre nodos: poca gente monta esto en casa, pero todo el mundo lo usa sin saberlo cada vez que entra en AWS, Azure o Google Cloud.
• Si tu carga cabe en un solo servidor (base de datos pequeña, intranet, few‑hundreds de usuarios concurrentes) y toleras una parada de mantenimiento, quédate con Linux (Debian/Ubuntu LTS) o Windows Server y ahórrate la complejidad.
• Si necesitas picos impredecibles (eventos en streaming, matrículas, Black Friday,始于 10x de tráfico normal) o sedes repartidas geográficamente, un DOS (o un clúster gestionado sobre Kubernetes) rinde más que escalar un servidor cada pocas semanas.

Qué es un sistema operativo distribuido (y qué no lo es)

Un DOS gestiona un conjunto de nodos como si fueran un único sistema: presenta una sola imagen coherente del sistema de archivos, reparte procesos entre máquinas y oculta al usuario dónde corre cada cosa. La diferencia con los sistemas que se le parecen no está en el marketing, está en lo que el usuario ve y en qué recursos controla el propio sistema.

Sistema	Recursos gestionados	Visibilidad para el usuario	Ejemplo
Sistema operativo de un solo nodo	CPU, memoria, disco y red de un servidor	Todo se ve como una máquina local	Linux sobre un servidor físico o una VM aislada
Sistema operativo de red	Varios nodos visibles de forma separada; cada usuario elige con cuál trabaja	Cada máquina es accesible individualmente, sin imagen única	Windows Server con Active Directory, Linux con NFS y SSH entre hosts
Sistema operativo distribuido	CPUs, memorias y discos de muchos nodos como un único pool	Una sola imagen de sistema: el usuario no necesita saber en qué nodo corre su proceso	Amoeba, Mach, Sprite, MOSIX, Plan 9

La clave está en la columna central: mientras un sistema operativo de red da herramientas para hablar entre máquinas (carpetas compartidas, login centralizado, colas de impresión), un DOS reparte el trabajo sin que la aplicación lo sepa.

Cómo se consigue esa "imagen de sistema único"

La pieza central es la transparencia, es decir, que el software vea el conjunto de nodos como si fuera uno solo. Engloba varios mecanismos: transparencia de ubicación (el usuario no sabe dónde está el archivo), de migración (un proceso se puede mover de nodo en caliente), de réplica (un dato vive en varios nodos a la vez) y de acceso (mismas operaciones sobre recurso local y remoto).

Hay dos caminos históricos para conseguirla. El primero, más ambicioso, es el micronúcleo: el núcleo delega casi todo (gestión de memoria, sistema de archivos, red) en servidores que pueden correr en nodos distintos. Amoeba y Mach son los referentes; el resultado es una imagen global real, con migración de procesos entre máquinas. El segundo camino es el de los sistemas operativos de red clásicos tipo Windows Server o Linux con NFS: se mantiene un núcleo monolítico por nodo, y se construye la imagen global “por encima” con servicios compartidos (DNS, LDAP, NFS, SMB). Es más fácil de desplegar y depurar, pero la transparencia es parcial: el programador sigue viendo varios nodos.

Amoeba demostró en los años 90 algo que hoy parece obvio: que un usuario podía hacer ls sobre un directorio repartido en cinco máquinas sin saber en cuál estaba cada archivo.

Tipos según el acoplamiento

El coste real de un DOS depende mucho de lo rápido que se hablan sus nodos. Esta tabla resume los tres grandes modelos:

Acoplamiento	Memoria	Comunicación	Escalabilidad	Ejemplo
Fuertemente acoplado	Memoria compartida distribuida (varios nodos ven el mismo espacio de direcciones)	Latencia del orden de microsegundos con redes de alta velocidad (10–100 Gbps)	Limitada a decenas de nodos; al crecer, la coherencia de caché se vuelve cuello de botella	MOSIX sobre Linux, clusters HPC clásicos
Débilmente acoplado	Memoria local por nodo	Mensajes por red IP, latencias de milisegundos	Buena, hasta cientos o miles de nodos	Amoeba, Sprite, Plan 9; también el modelo de Kubernetes/Docker sobre Linux
Peer‑to‑peer	Memoria local por nodo, sin jerarquía fija	Mensajes punto a punto, a menudo sobre Internet	Muy alta, miles de nodos heterogéneos	Plan 9 con 9P en red amplia, sistemas P2P de compartición de archivos

En la práctica, lo que se monta hoy en producción (Kubernetes, Mesos, los servicios gestionados de AWS o GCP) se parece más al modelo débilmente acoplado: nodos independientes hablando por TCP, sin memoria compartida.

Cuándo conviene de verdad usarlo

• Servicio con SLA alto (99,9% o más). Si cada minuto caído se traduce en pérdida directa de dinero o de reputación, necesitas que procesos y datos sobrevivan al fallo de un nodo. La métrica que lo hace rentable es disponibilidad anual: un SLA del 99,9% permite unas 8,7 horas de caída al año; un 99,99%, 52 minutos. Para conseguir 99,99% sin DOS hace falta redundancia manual cara y, aun así, el failover de un servidor central deja unos minutos sin servicio.
• Picos impredecibles de carga. Cuando el tráfico normal puede multiplicarse por 10x en minutos (lanzamientos, matrículas, campañas de marketing, eventos deportivos), un DOS bien dimensionado absorbe el pico rebalanceando procesos entre nodos. La métrica que lo justifica es tiempo de provisionado: si levantar un servidor nuevo te lleva más de 15–30 minutos, no llegas.
• Datos o sedes repartidas geográficamente. Si parte de tus usuarios está en Europa y parte en Latinoamérica, tener nodos en cada región baja latencia por debajo de 100 ms y reduce la dependencia de un único datacenter. La métrica a vigilar es la latencia de red entre nodos: por debajo de 5 ms en LAN, por debajo de 50 ms inter‑datacenter.
• Cómputo paralelo masivo. Simulaciones, render, entrenamiento de modelos, genómica: tareas que se parten en cientos de hilos. Aquí el DOS o el middleware (MPI, scheduler tipo Slurm) reparte el trabajo entre nodos con CPU+GPU. La métrica rentable es GFLOPS por hora frente a coste, no GB de RAM.

Cuándo NO conviene y mejor quedarse en un servidor central

Ventajas de quedarse en un servidor único:

• Despliegue y operación más simples: un solo kernel, un solo dmesg, una sola máquina que parchear.
• Latencia real entre componentes medida en nanosegundos, no en milisegundos.
• Coste total mucho menor cuando el hardware ya está amortizado: sin licencias de middleware, sin formación del equipo.
• Depuración más fácil: logs en un único sitio, sin relojes que sincronizar.

Inconvenientes de irse a un DOS sin necesitarlo:

• Tienes que mantener coherencia de estado entre nodos: dos réplicas desincronizadas pueden dar resultados inconsistentes.
• La latencia de red añade entre 0,1 ms (datacenter, 10 Gbps) y 50–100 ms (inter‑continental) a cada operación lógica que cruza nodos.
• El coste operativo mínimo (al menos un nodo extra para redundancia, software de orquestación, monitorización distribuida) se vuelve difícil de amortizar con cargas pequeñas.

Como regla de dedo, por debajo de ~500 usuarios concurrentes, ~100 GB de datos activos y SLA por debajo del 99,9%, un servidor bien dimensionado (o una VM dedicada en la nube) rinde mejor por euro gastado que un DOS.

Ejemplos reales que sí son sistemas operativos distribuidos

Amoeba, desarrollado por Andrew Tanenbaum y su equipo en la Vrije Universiteit desde 1981, fue uno de los primeros micronúcleos pensados desde cero como DOS. Presentaba una sola imagen sobre nodos conectados por LAN, replicación de objetos transparente y delegación de hilos entre máquinas. Puedes ver la descripción original del sistema en la página del grupo Distributed and Embedded Systems de la VU Amsterdam: www.cs.vu.nl/~ast/amosfera.html.

Mach (Carnegie Mellon, 1985) acercó el micronúcleo al mundo Unix y sirvió de base a NeXTSTEP y, por herencia, a macOS y a iOS. La idea de Mach se mantiene viva en el micronúcleo L4 y en seL4, que se usan en sistemas embebidos con fuertes requisitos de seguridad. Detalle histórico y enlaces en la página retrospectiva de la CMU School of Computer Science: www.cs.cmu.edu/~music/mach.html.

Sprite, de UC Berkeley entre 1984 y 1992, introdujo migración de procesos y una caché global de archivos coherente entre nodos. Sentó las bases de lo que luego serían NFS y muchas técnicas de clustering usadas en Linux.

MOSIX (Hebrew University, 1977 y en evolución desde entonces) sigue vivo como proyecto para clusters Linux, con migración preemptiva de procesos: carga un nodo lleno y MOSIX desplaza procesos al siguiente sin reiniciar. Tiene versión comunitaria y comercial; documentación en www.mosix.org.

Plan 9 from Bell Labs (1985–2002, luego mantenido como 9front) generalizó el protocolo 9P para que cualquier recurso, en cualquier nodo, se viera como archivo. La idea (todo es archivo, todo es red) sigue siendo citada en documentación de sistemas modernos (p. ej. en 9p.io).

Si vas a montarlo: qué mirar antes de elegir

Antes de firmar un contrato o dedicar una semana a montar un clúster, revisa estos cinco puntos con cifras y pruebas reales, no con demos de proveedor:

1. Coherencia del sistema de archivos. Comprueba qué se replica y qué no. Sistemas tipo Sprite y Plan 9 mantienen caché global; montajes NFS sobre Linux no garantizan coherencia estricta entre escrituras concurrentes. Mide con fsync lo que tarda una escritura replicada en dos nodos.
2. Soporte de migración de procesos. No basta con mover binarios: el sistema tiene que migrar el espacio de direcciones y los sockets abiertos sin que la aplicación lo note. MOSIX lo hace, Kubernetes solo si diseñas los pods para ello (con ReplicationController y servicios ClusterIP).
3. Gestión global de procesos. Tiene que haber un planificador único (o coordinado) que vea la carga de todos los nodos. Pide ver las métricas de CPU y memoria agregadas de todo el clúster antes de elegir herramienta.
4. Modelo de fallos asumido. Documenta qué pasa si cae un nodo, una red o un datacenter entero. Si el proveedor no te lo explica con cifras (RTO, RPO), no es un DOS: es marketing.
5. Comunidad y mantenimiento. Mira fecha del último commit, nº de issues abiertas y versión de mantenimiento LTS. Un micronúcleo experimental sin commits en más de 12 meses es riesgo, no innovación.

Un DOS bien elegido se nota en el primer fallo de un nodo: el servicio sigue vivo y nadie del equipo tiene que levantarse de noche.

Datos comprobados en octubre de 2026.

Preguntas frecuentes sobre sistemas operativos distribuidos

1. Ejemplos reales de sistemas distribuidos que se usan a diario

Una red de cajeros automáticos, el servicio de correo electrónico como Gmail, una CDN como Cloudflare, una base de datos MongoDB replicada en varios centros de datos o una blockchain como Bitcoin son ejemplos cotidianos. En cada caso, varios nodos cooperan para dar un servicio único; cuando uno cae, los demás siguen atendiendo peticiones sin que el usuario lo note.

2. Qué tipos de sistemas distribuidos existen y en qué se diferencian

Se clasifican por acoplamiento: los débilmente acoplados son redes LAN/WAN y la World Wide Web, donde los nodos se comunican por mensajes. Los fuertemente acoplados abarcan multiprocesadores con memoria compartida, multicomputadores con memoria privada y sistemas distribuidos como Linux clusters o Hadoop, donde los nodos cooperan de forma más estrecha pero sin compartir memoria.

3. Características que definen a un sistema operativo distribuido

Un sistema distribuido comparte recursos (archivos, CPU, dispositivos) entre nodos, permite acceso concurrente sin conflictos, oculta la distribución al usuario y es capaz de seguir funcionando aunque fallen partes del conjunto. Sobre esa base añade transparencia: el usuario ve un único sistema lógico aunque por debajo trabajen decenas o miles de máquinas cooperando.

4. Objetivos principales de un sistema distribuido

Los dos objetivos clásicos son conectar usuarios y recursos (personas y dispositivos geográficamente separados) y aumentar la fiabilidad y disponibilidad: si un nodo falla, otro asume su carga sin interrumpir el servicio. Hoy se añade un tercero muy buscado: la escalabilidad, crecer añadiendo nodos para absorber más carga manteniendo el rendimiento por usuario.

5. Sistemas operativos distribuidos en formato PDF o apuntes

Para estudiar el tema, busca por "sistema operativo distribuido" en repositorios académicos abiertos como Dialnet, ResearchGate o el DOAJ; ahí encontrarás artículos y tesis descargables sin coste. También hay libros de referencia completos en PDF, como "Distributed Systems: Concepts and Design" de Coulouris, y apuntes publicados por universidades como la UPC o la UNED, ambos verificables en sus bibliotecas digitales.

6. Qué es y cómo funciona un sistema operativo de red

Un sistema operativo de red, como Windows Server 2019 o Linux con Samba, gestiona los recursos compartidos entre los equipos conectados, principalmente ofreciendo servicios de archivos e impresión centralizados. Cada usuario conserva su propio equipo con su sistema operativo local, por lo que la integración con el hardware se gestiona por capas: cliente ligero, servidor de red y nodos servidores de aplicaciones.

7. Sistemas operativos en tiempo real y cuándo se usan

Un sistema operativo de tiempo real (RTOS) garantiza plazos de respuesta estrictos en el orden de microsegundos o milisegundos, no solo rápidos «de media». Se emplea en control industrial, robótica, automoción (ESP en coches, AUTOSAR en aviónica) y dispositivos médicos, donde un retraso de 10 ms en la respuesta del airbag puede tener consecuencias graves.

Fuentes

1. Unirioja[PDF] SISTEMAS DISTRIBUIDOS GUÍA DOCENTE CURSO 2026-27consultado el 19/10/2026
2. PreziSISTEMAS DISTRIBUIDOS EN 2026 – Preziconsultado el 19/10/2026
3. Lovelytics¿Qué son y cómo funcionan los sistemas distribuidos? – Lovelyticsconsultado el 19/10/2026
4. YoustableLos 10 mejores sistemas operativos de servidor en 2026 – YouStableconsultado el 19/10/2026