Resumen

  • Un slice de PlanetLab era una colección de máquinas virtuales que recibían fracciones de recursos en muchos nodos. Daba una identidad operativa mundial al servicio, no la propiedad del hardware.
  • La intención central se convertía en ejecución sólo cuando el gestor de cada nodo, la capacidad local, el planificador y las reglas del sitio aceptaban la parte correspondiente.
  • La experimentación abierta exigía aislamiento, contabilidad de recursos y una cadena de responsabilidad capaz de atribuir una acción externa al principal que la originó.

Una cuenta global no convertía los servidores en una propiedad global

Antes de PlanetLab, probar un servicio distribuido a gran escala dependía a menudo de una red de favores. Un investigador pedía cuentas en máquinas de colegas y obtenía unos pocos puntos de presencia. Era difícil repetir la prueba, comparar resultados o descubrir cómo se comportaría el software bajo largas distancias, cargas desiguales y políticas institucionales distintas.

PlanetLab convirtió esa cooperación informal en una instalación compartida. Un grupo podía desplegar un servicio en numerosos sitios y manejar el conjunto bajo una misma identidad. Ese conjunto era el slice.

El artículo de sistemas operativos de 2004 lo define con cuidado: en cada nodo, el servicio recibía una fracción de recursos en forma de máquina virtual. El conjunto distribuido de VM se trataba como una sola entidad compuesta. Para el usuario parecía un grupo privado de máquinas repartidas por el mundo. Pero aquella privacidad era una ilusión sostenida por mecanismos de aislamiento. El nombre común no transfería el servidor, la red local ni la responsabilidad jurídica del sitio que los aportaba.

La abstracción era poderosa precisamente porque no necesitaba fingir una compra. Componía permisos parciales y renovables. No creaba un dueño nuevo.

El hecho local se llamaba sliver

La arquitectura distinguía el objeto global de su materialización. La parte de CPU, memoria, almacenamiento y red vinculada a una VM en un nodo era un sliver. El slice era la red formada por esos slivers y sus máquinas virtuales.

El servicio mantenía amplio margen para decidir. PlanetLab no imponía un único túnel entre sus componentes ni un solo lenguaje de programación. Cada experimento podía construir su propia topología superpuesta y cargar el entorno que necesitara.

Esa libertad no atravesaba la frontera física. Un servicio podía diseñar su overlay, pero no inventar ciclos de CPU en una máquina saturada. Podía solicitar presencia en un país, pero no obligar a responder a un nodo fuera de línea. Podía tener un espacio aislado, pero no apropiarse de los privilegios del sistema compartido.

Una nota de diseño de 2002 expresaba el límite mediante tickets y arrendamientos. El ticket describía un nodo, una cantidad de recursos y un intervalo. Canjearlo podía producir un lease, siempre sometido al control de admisión del nodo. La nota era un borrador en evolución, no un contrato eterno de todas las versiones de PlanetLab. Sin embargo, su reparto de autoridad era explícito: el agente global podía presentar una pretensión; la máquina local decidía si existía capacidad real para honrarla.

El centro coordinaba; cada sitio conservaba una decisión

PlanetLab no fue una red sin centro. El diseño inicial incluía PlanetLab Central, encargado de contactar al gestor de cada nodo para crear la VM local. El gestor y el monitor de máquinas virtuales ejecutaban operaciones privilegiadas. Además, alguna pieza única tenía que arrancar los primeros servicios y hacer cumplir los límites.

Al mismo tiempo, los nodos pertenecían a organizaciones autónomas. El informe de experiencia de 2006 lo convirtió en requisito: cada organización debía retener control sobre el uso de sus recursos, y mantener el crecimiento exigía minimizar el control central.

Por eso un slice cruzaba una frontera de autoridad en cada nodo. La vista central podía listar la máquina como parte prevista del despliegue. Sólo el estado local, el gestor, el planificador y la política del anfitrión podían confirmar la VM en ejecución. Una base de datos desactualizada describía el plan; el código vivo describía el slice real.

Esta diferencia también protegía la interpretación de los resultados. Cien nodos inscritos no equivalían a cien nodos disponibles, y cien VM vivas no equivalían a cien recursos de la misma clase.

Aislamiento no significaba dedicación

La palabra aislamiento reunía varias obligaciones. El aislamiento de recursos debía reducir la interferencia en CPU, memoria, disco y ancho de banda. El aislamiento de seguridad debía separar espacios de nombres y datos. Una base estable debía impedir que una VM modificara el sistema del que dependían las demás.

Una obligación no demostraba las otras. Un slice podía estar bien separado desde el punto de vista de seguridad y sufrir latencia variable. Podía recibir reparto justo de CPU sin una reserva. Podía ejecutar código correcto mientras un límite local alteraba el rendimiento observado.

La operación real obligó a abandonar la confianza inicial en el simple best effort. La carga elevada y la volatilidad hicieron necesarios el reparto justo, reservas expresas y planificación basada en fichas. Bajo presión de memoria, un vigilante podía reiniciar la VM que más consumía. Los sitios podían limitar el tráfico saliente.

En un experimento descrito en 2006, una ruta física estable en 74 milisegundos producía en el overlay tiempos de ida y vuelta de 76 a 135 milisegundos antes de aplicar un tratamiento especial de CPU. Una reserva y planificación en tiempo real acercaron la mayoría de las observaciones, sin eliminar todo el jitter. No es una puntuación universal de PlanetLab; es la prueba de que un slice global no equivalía a hardware dedicado.

La cadena de responsabilidad hacía posible la confianza

Los experimentos salían al Internet real. Una medición podía activar los sistemas de detección de un tercero. Una prueba de caudal podía ocupar el enlace de una universidad. La buena intención del investigador no pagaba por sí sola ese coste externo.

El artículo de 2004 exigía contabilidad exhaustiva y capacidad para atribuir acciones, no sólo cantidades, a un slice después de los hechos. El documento posterior sobre principios de diseño lo formuló como una cadena de responsabilidad: cualquier actividad visible fuera de PlanetLab debía volver al usuario responsable.

Esa cadena reducía una carga social imposible. Cada anfitrión no necesitaba negociar por separado con cada grupo de investigación si podía aplicar sus límites, saber quién había generado un paquete y escalar el incidente a una parte identificable.

El slice, entonces, no era únicamente el lugar donde corría el programa. Era también el recibo que ligaba libertad y responsabilidad. Si la atribución desaparecía, la virtualización seguía ocultando procesos entre sí pero dejaba al anfitrión sin defensa ante el mundo exterior.

La gestión desacoplada tenía un núcleo irreductible

PlanetLab intentó sacar del núcleo local las funciones de alcance mundial. La creación de slices, el descubrimiento de recursos, la monitorización y la distribución de software podían existir como servicios superiores, incluso en slices propios. Interfaces compartibles permitirían que varias soluciones evolucionaran en paralelo en vez de conferir privilegio eterno a una sola.

El principio consistía en soportar directamente en el sistema operativo únicamente abstracciones locales. Los servicios componían las abstracciones de red. De ese modo, el gestor global podía reemplazarse sin sustituir el mecanismo de todos los nodos.

El desacoplamiento no abolía toda autoridad única. Alguien tenía que crear la VM local, aplicar el aislamiento y arrancar los primeros servicios. Los autores señalaron ese pequeño núcleo. La disciplina residía en hacerlo reducido y visible, no en negarlo.

Las ideas posteriores de Heng Lu sobre especificación inicial mínima y primacía del código permiten leer esta frontera con claridad: el componente común debería imponer sólo lo necesario para una composición segura; una afirmación central no puede crear capacidad ni derechos que los nodos no ejecutan. Es una lente editorial contemporánea, no una influencia histórica atribuida a Peterson o a sus coautores.

Anticipar la nube no es inventarla

La retrospectiva de Princeton de 2026 sitúa el máximo de PlanetLab en 1.353 nodos, 717 sitios y 48 países, y registra su cierre oficial en 2020. Peterson resume su alcance sin grandilocuencia: PlanetLab no creó la nube, pero la anticipó.

Anticipó la costumbre de pedir un recurso abstracto, desplegar software a distancia y compartir capacidad física entre usuarios que ven un contrato lógico. También anticipó las preguntas incómodas que una consola moderna puede ocultar: ¿qué sitio otorgó el recurso?, ¿en qué clase?, ¿quién puede rechazarlo o reiniciarlo?, ¿quién responde por el tráfico?

No inventó por sí solo la máquina virtual, el contenedor, la CDN ni la orquestación. Tampoco toda nube moderna desciende de PlanetLab. Su contribución particular fue hacer funcionar la abstracción en una infraestructura mundial, heterogénea, escasa y sometida a terceros reales.

El cierre del proyecto no elimina el resultado. La continuidad que importa es la de una función componible y auditable, no la inmortalidad de su operador.

Larry Peterson dentro de una obra compartida

Larry Peterson fue organizador, arquitecto y operador central de PlanetLab; Princeton lo presenta como Robert E. Kahn Professor, Emeritus and Senior Research Scholar. Pero el diseño acumuló trabajo de muchas personas e instituciones.

El plano de 2002 fue escrito por Peterson, Tom Anderson, David Culler y Timothy Roscoe. El artículo de 2004 acredita a Andy Bavier, Mic Bowman, Brent Chun, Culler, Scott Karlin, Steve Muir, Peterson, Roscoe, Tammo Spalink y Mike Wawrzoniak. El balance de 2006 es de Peterson, Bavier, Marc E. Fiuczynski y Muir. La nota de creación de slices pertenecía al PlanetLab Architecture Team y fue editada por Peterson y Amin Vahdat con otros colaboradores nombrados.

La atribución colectiva forma parte del argumento. Un sistema construido para compartir recursos sin fingir un único propietario tampoco debería recibir una historia de autor único.

Fuentes