Resumo

  • Um slice do PlanetLab era uma rede de máquinas virtuais, cada qual limitada a uma fração dos recursos de um nó local. A identidade era global; a propriedade do hardware não era.
  • O coordenador podia montar a solicitação, mas a execução dependia do gerenciador do nó, da capacidade disponível, do escalonador e das regras da organização anfitriã.
  • A liberdade de experimentar só era sustentável com isolamento, contabilização de recursos e uma cadeia de responsabilidade que ligasse a atividade externa ao principal correto.

O slice era uma composição, não uma aquisição

No início dos anos 2000, quem quisesse testar um serviço distribuído em escala ampla dependia de favores. Pedia uma conta a colegas, instalava o programa em algumas máquinas e tentava extrair uma conclusão de ambientes pouco comparáveis. Faltava uma forma comum de observar o que acontecia sob distâncias reais, cargas diferentes e administrações autônomas.

O PlanetLab transformou essa rede informal de contas numa instalação compartilhada. Um grupo de pesquisa podia implantar seu serviço em vários locais e tratar o conjunto como uma unidade. Essa unidade recebeu o nome de slice.

O artigo de 2004 sobre o sistema operacional define a base material: em cada nó, o serviço recebe uma fração de CPU, memória, armazenamento e rede por meio de uma máquina virtual. O conjunto distribuído dessas VMs é tratado como uma entidade composta. Para o usuário, ele cria a ilusão de uma coleção privada de máquinas.

Ilusão não significava fraude. Era uma abstração técnica protegida por isolamento. O servidor físico ainda pertencia ao local que o hospedava. A rede do campus continuava sob regras locais. A conta global não dava ao pesquisador os direitos do proprietário.

Assim, o slice não era um computador planetário escondido. Era um acordo operacional construído sobre concessões locais e limitadas.

O sliver revelava o que realmente havia em cada local

A terminologia do projeto distinguia a visão global de sua execução. A parcela de recursos ligada a uma VM em um nó era o sliver. O slice era a rede formada pelos slivers espalhados.

Acima dessa base, o serviço dispunha de liberdade considerável. O PlanetLab não entregava uma topologia obrigatória de túneis nem escolhia uma linguagem única. Cada grupo podia desenhar o próprio overlay e instalar o ambiente necessário.

Essa autonomia não atravessava o limite do nó. O serviço podia decidir como as VMs se comunicavam, mas não criar capacidade numa máquina sobrecarregada. Podia solicitar presença num local, mas não fazer um nó desligado responder. Podia carregar software, mas não assumir privilégios de sistema sobre os vizinhos.

Uma nota de arquitetura de 2002 descrevia tickets e leases. O ticket especificava um nó, uma quantidade de recursos e um período. Apresentá-lo podia resultar num lease, condicionado à política de admissão do nó. A nota era um rascunho em andamento e não deve ser transformada em regra eterna de todas as versões implantadas. Mesmo assim, ela registra uma divisão essencial: o agente global distribuía uma pretensão; o componente local confirmava ou recusava a realidade.

Havia um centro, mas não um dono único

O PlanetLab não foi uma descentralização absoluta. A arquitetura inicial tinha o PlanetLab Central, que acionava os gerenciadores dos nós para criar as VMs. Mecanismos privilegiados precisavam inicializar o sistema, aplicar limites e controlar as máquinas virtuais locais.

Ao mesmo tempo, os nós eram fornecidos por organizações autônomas. O relato de 2006 diz que cada organização precisava conservar algum controle sobre o uso dos próprios recursos e que a expansão da plataforma dependia de minimizar o controle central.

Cada VM de um slice, portanto, atravessava uma fronteira de autoridade. O plano central podia incluir um nó. Só o estado local, o gerenciador, o escalonador e a política do anfitrião determinavam se o sliver existia de fato. Uma visão central desatualizada descrevia uma intenção, não uma capacidade disponível.

Essa diferença era importante para a ciência. Uma lista com cem nós não provava cem execuções vivas; cem VMs vivas não provavam cem condições equivalentes.

Isolamento não era sinônimo de desempenho garantido

O projeto separava diferentes obrigações. O isolamento de recursos tentava limitar a interferência em CPU, memória, disco e banda. O isolamento de segurança separava namespaces e dados. Uma base estável impedia que uma VM alterasse o sistema do qual as outras dependiam.

Essas propriedades não eram intercambiáveis. Um serviço podia estar seguro e ainda sofrer jitter. Podia receber uma fração justa sem obter reserva. Podia funcionar corretamente dentro da VM enquanto um limite de rede do campus alterava a medição.

A operação mostrou cedo que o simples best effort não bastava. Cargas intensas e desempenho volátil exigiram compartilhamento justo, reservas explícitas e escalonamento por tokens. Sob pressão de memória, um processo de vigilância podia reiniciar a VM que mais consumia. Locais anfitriões podiam limitar tráfego de saída.

Num ensaio relatado em 2006, o caminho de rede de 74 milissegundos apareceu no overlay com tempos entre 76 e 135 milissegundos antes de tratamento especial da CPU. Reserva e prioridade em tempo real reduziram a maior parte da variação, sem eliminar toda atividade do kernel. O número não classifica o PlanetLab inteiro. Ele demonstra que a identidade mundial do slice não equivalia a hardware dedicado.

Prestação de contas era parte da licença para experimentar

Os pacotes saíam para a Internet real. Um experimento de mapeamento podia acionar um detector de intrusão. Um teste de vazão podia ocupar o gateway de uma universidade. O objetivo científico não eliminava o impacto sobre terceiros.

Por isso, o artigo de 2004 exige contabilização de recursos e atribuição posterior de ações — e não apenas volumes — ao slice correto. O texto sobre princípios de projeto chama isso de cadeia de responsabilidade: uma atividade visível fora da plataforma precisava chegar ao usuário que a originou.

Essa cadeia substituía milhares de acordos individuais de confiança. O anfitrião não precisava conhecer cada pesquisador se pudesse impor limites, identificar o principal por trás de um pacote e obter resposta a um incidente.

O slice era, então, duas coisas ao mesmo tempo: um espaço de execução e um recibo de responsabilidade. Sem o recibo, o isolamento ainda separaria processos, mas deixaria a instituição que forneceu a máquina sozinha diante da reclamação.

Desacoplar a gestão tornava parte do controle substituível

O PlanetLab procurou manter no sistema operacional apenas abstrações locais. Funções de alcance global — criação de slices, descoberta de recursos, monitoramento e distribuição de software — podiam ser serviços acima da base, inclusive executados em slices próprios. Interfaces explícitas e compartilháveis permitiam soluções paralelas, em vez de uma aplicação privilegiada permanente.

O princípio reduzia o núcleo de autoridade, mas não o fazia desaparecer. Algum componente ainda precisava criar a VM local, aplicar as restrições e iniciar o primeiro serviço. Os autores reconheceram esse núcleo único. O ganho estava em mantê-lo pequeno e observável.

As formulações posteriores de Heng Lu sobre Especificação Inicial Mínima e Primazia do Código em Execução ajudam a ler esse limite hoje. A camada comum deve garantir apenas os invariantes necessários à composição segura; serviços globais podem evoluir sem transformar seu registro em título sobre as máquinas. Essa é uma lente editorial atual, não uma alegação de influência histórica sobre Peterson ou seus colegas.

Antecipar a nuvem não significa inventá-la

A retrospectiva publicada por Princeton em 2026 registra que o PlanetLab chegou a 1.353 nós em 717 locais e 48 países e encerrou oficialmente as operações em 2020. A frase de Peterson preserva a proporção: o PlanetLab não criou a nuvem, mas a antecipou.

Ele antecipou a experiência de solicitar um recurso abstrato, implantar remotamente e compartilhar hardware sob uma identidade lógica. Também expôs perguntas que interfaces modernas podem esconder: qual anfitrião concedeu o recurso, em que classe, quem pode recusá-lo ou reiniciá-lo, e quem responde pelo tráfego?

O PlanetLab não inventou sozinho máquinas virtuais, contêineres, CDNs ou orquestração. Também não há uma linhagem única ligando toda nuvem atual ao projeto. Sua contribuição particular foi testar a abstração global em infraestrutura heterogênea, escassa, administrada por várias instituições e conectada a terceiros reais.

O fim do consórcio não apaga a função aprendida. O que merece continuidade é a capacidade de compor permissões locais com evidência, não a imortalidade de um operador.

Larry Peterson em uma autoria coletiva

Larry Peterson foi organizador, arquiteto e operador central do PlanetLab. Princeton o identifica hoje como Robert E. Kahn Professor, Emeritus and Senior Research Scholar. Esse papel não reduz o projeto a uma invenção individual.

O blueprint de 2002 foi escrito por Peterson, Tom Anderson, David Culler e Timothy Roscoe. O artigo de 2004 reúne Andy Bavier, Mic Bowman, Brent Chun, Culler, Scott Karlin, Steve Muir, Peterson, Roscoe, Tammo Spalink e Mike Wawrzoniak. O relato de 2006 é de Peterson, Bavier, Marc E. Fiuczynski e Muir. A nota de criação de slices pertence à equipe de arquitetura, editada por Peterson e Amin Vahdat com outros colaboradores nomeados.

Preservar essa autoria múltipla combina com a própria arquitetura: uma infraestrutura compartilhada não precisa inventar um proprietário único para funcionar.

Fontes