Arquitectura VM-* y Familia de Sistemas Operativos

La plataforma PointSav organiza sus implementaciones en tiempo de ejecución en cinco tipos de máquinas virtuales (VM): VM-Totebox, VM-MediaKit, VM-Orchestration, VM-PrivateGit e VM-Infrastructure. Cada tipo de VM corresponde exactamente a un binario fuente os-*. El nombre en tiempo de ejecución y el nombre fuente son dos identidades para lo mismo: lo que se compila como os-totebox se ejecuta como VM-Totebox.

Esta correspondencia no es casual. La plataforma está diseñada para que un entorno de desarrollo y un sistema de producción de un cliente se implementen de la misma manera. Los cinco tipos de VM reflejan directamente las cinco formas en que clientes y miembros de la comunidad interactúan con la plataforma.

Tipos de VM y sus propósitos

VM-Totebox

Binario fuente: os-totebox Propósito: Bóveda de datos soberana por entidad. La unidad de cómputo principal de la plataforma.

Una instancia de VM-Totebox contiene todos los datos estructurados que pertenecen a una entidad: registros corporativos, personal, bienes inmuebles, correo electrónico, documentos y los libros de contabilidad derivados de ellos. Los datos ingresan a través de los servicios de ingestión del Anillo 1 y son procesados por los servicios de conocimiento del Anillo 2. La bóveda tiene disciplina WORM: los datos pueden adjuntarse y reemplazarse, pero no eliminarse de manera silenciosa.

Cada VM-Totebox es implementable de forma independiente: en un servidor físico, un servidor en alquiler o una máquina virtual en la nube. La imagen de disco constituye el archivo. Migrar un Totebox equivale a mover esa imagen.

Servicios: service-fs (almacenamiento de bloques WORM), service-people, service-email, service-extraction, service-content e inteligencia opcional del Anillo 3 mediante service-slm.

VM-MediaKit

Binario fuente: os-mediakit Propósito: Dispositivo web de cara al público. Funciona de forma independiente de un Totebox.

VM-MediaKit aloja los sitios web y portales de conocimiento que un emisor de información regulada o una pequeña empresa presenta al público. Ejecuta portales de conocimiento tipo wiki, sitios de marketing estáticos y una sala de noticias. Cada aplicación alojada es un servicio sin estado: lee de un directorio de contenido pero no mantiene estado de libro mayor por entidad.

Servicios: app-mediakit-knowledge (wikis de documentación, corporativa y de proyectos), app-mediakit-marketing. La corrección ortográfica (proofreader) no es un servicio de VM-MediaKit — se ejecuta como un módulo dentro del cartucho de contenido de os-console, no como un despliegue independiente.

VM-Orchestration

Binario fuente: os-orchestration Propósito: Agregador multi-archivo sin estado. Nivel comercial de pago.

VM-Orchestration consulta múltiples instancias de VM-Totebox y presenta vistas a nivel de flota o portafolio. No retiene datos propios: está diseñado para agregar mediante un protocolo de consulta basado en capacidades, sin un nombre de protocolo específico incorporado al código hoy. Una instancia de VM-Orchestration sirve el terminal de coordinación BIM, el mapa de flota GIS y el corredor de SLM.

Servicios: app-orchestration-bim, app-orchestration-gis, app-orchestration-slm (:9180).

VM-PrivateGit

Binario fuente: os-privategit Propósito: Control de fuentes soberano y alojamiento del sistema de diseño.

VM-PrivateGit ejecuta Gitea como espejo bidireccional de los repositorios canónicos en GitHub y, opcionalmente, un servidor de previsualización del sistema de diseño. Proporciona independencia de control de fuentes respecto a proveedores externos para la propiedad intelectual y los activos de marca. El espacio de trabajo Foundry (vault-privategit-source-1) es la primera implementación de este tipo.

Servicios: app-privategit-source-control, app-privategit-design.

VM-Infrastructure

Binario fuente: os-infrastructure Propósito: La flota de hosts en sí: tejido WireGuard PPN, hipervisor y ubicación de VM.

VM-Infrastructure no es una VM en el sentido convencional. Es el binario os-infrastructure ejecutándose en hardware físico, proporcionando la capa de hipervisor que aloja todos los demás tipos de VM. Tres nodos forman la flota de producción mínima:

• Nodo en la nube de GCP (semilla génesis): La semilla canónica del concentrador orientado a internet. Aloja VM-MediaKit, VM-Orchestration, VM-PrivateGit.
• Laptop A (par local): Configura WireGuard como par del concentrador de GCP. Aloja VM-Totebox-1.
• Laptop B (concentrador LAN local): Actúa como concentrador WireGuard para la red local, un rol distinto al de Laptop A.

Los nodos locales adicionales se unen a una malla ya sembrada mediante una ceremonia de emparejamiento por código corto (CPace PAKE + confirmación SAS).

VM-Infrastructure es una flota de hosts con confianza en malla, no un planificador de recursos en clúster. Cada nodo se aprovisiona de forma independiente. Las decisiones de ubicación — qué VM se ejecuta en qué nodo — son política del operador. La malla WireGuard proporciona la vinculación nombre-a-endpoint.

Principio de ubicación

Un servicio pertenece a la VM cuyo espacio de nombres os-* posee el ciclo de vida de sus datos y la frontera de confianza, no a la VM donde se ejecutó su binario por primera vez.

Derivaciones de esta regla:

• service-fs (libro mayor WORM) pertenece a VM-Totebox. Es el sustrato de almacenamiento del Totebox.
• app-orchestration-bim pertenece a VM-Orchestration. Su nombre declara su clase.
• WireGuard y la ceremonia de emparejamiento pertenecen a VM-Infrastructure. Son preocupaciones del tejido.

Si un servicio requiere co-ubicación de loopback con un servicio en una VM diferente, eso es una señal de diseño. La frontera PPN es donde los servicios de diferentes tipos se comunican.

Rutas de implementación para clientes

Los tipos de VM se corresponden directamente con las formas en que clientes y miembros de la comunidad se relacionan con la plataforma.

Usuarios de la Red Privada PointSav implementan VM-Infrastructure en su propio hardware: como mínimo un nodo local y el nodo semilla génesis de GCP. El Protocolo Génesis inicia la malla desde un único nodo. No se requiere ninguna autoridad de certificación externa.

Usuarios de Totebox Orchestration implementan VM-Totebox (bóveda de datos) y VM-Orchestration (vista de flota). Una sola instancia de VM-Totebox es suficiente para una pequeña empresa. Las organizaciones más grandes añaden VM-Orchestration para agregar a través de múltiples archivos.

Usuarios de sistemas independientes implementan VM-MediaKit (sitios web y portales de conocimiento) o VM-PrivateGit (control de fuentes) sin dependencia de un Totebox. Estos son dispositivos independientes: no requieren una malla WireGuard para funcionar, aunque opcionalmente pueden unirse a una.

Hoja de ruta de unikernels

La Fase 1 para todos los tipos de VM utiliza Ubuntu 24.04 bajo QEMU (acelerado por KVM donde esté disponible, TCG como alternativa). Esta es la línea de base operativa actual.

La Fase 2 prevé alojar cada VM de forma más ligera: jails de FreeBSD para el aislamiento por carga de trabajo de MediaKit, Alpine Linux con binarios estáticos enlazados a musl para Totebox, y sandboxing gVisor para los agregadores de Orchestration.

La Fase 3 es el objetivo previsto de unikernel. Se prevé que VM-Totebox y VM-MediaKit se ejecuten como dominios de protección seL4 Microkit en hardware AArch64 (condicionado a la adquisición de hardware). Se prevé que los procesos del agregador de VM-Orchestration apunten a NanoVMs/OPS; las cargas de trabajo de inferencia SLM y GPU se prevé que permanezcan en un host Linux completo. Se prevé que la propia flota de hosts (VM-Infrastructure) ejecute el binario os-infrastructure en NetBSD/NVMM (capa de compatibilidad x86-64, Fase 2) o seL4+Microkit (capa nativa AArch64, Fase 3).

Microkit 2.2.0 incluye un objetivo x86_64_generic_vtx, pero la Microkit x86-64 está limitada a un vCPU por máquina virtual y requiere Intel VT-x. La ruta de producción prevista para la Fase 3 es AArch64. La Fase 2 en x86-64 utiliza NetBSD/NVMM — el hipervisor nativo de NetBSD disponible desde NetBSD 9.0, mediante QEMU con el indicador -accel nvmm. Ambas rutas comparten el mismo libro mayor de capacidades (system-core).

Agrupación de recursos

La malla WireGuard de tres nodos (un nodo en la nube y hasta dos nodos locales) forma un grupo unificado de recursos de máquinas virtuales. Esta agrupación es una primitiva PPN de nivel gratuito: los operadores no pagan por cada nodo unido al grupo.

Dos servicios implementan el grupo. service-vm-host se ejecuta en cada nodo de infraestructura: sondea la utilización local de CPU y RAM cada diez segundos y envía un latido al controlador de la flota. service-vm-fleet se ejecuta en el nodo en la nube y recibe esos latidos, expulsando cualquier nodo que permanezca silencioso durante más de treinta segundos. Cuando un operador solicita una nueva máquina virtual, el controlador de la flota aplica una ubicación orientativa — seleccionando el nodo con más RAM disponible por encima de un margen de seguridad — y envía la solicitud de creación.

La migración en vivo de máquinas virtuales está excluida de forma permanente. El ancho de banda de WireGuard a través de enlaces de internet típicos haría que migrar una VM activa fuera inviable; las máquinas virtuales se colocan una vez y permanecen en el nodo asignado. Esta es una invariante arquitectónica, no una opción de configuración.

Crear una VM es una acción del operador y requiere confirmación explícita en el panel F9 de app-network-admin. La selección de nodo por parte del controlador de la flota es infraestructura orientativa y no requiere confirmación. Las instancias de VM-Totebox siempre deben asignarse a un nodo específico, ya que los datos del archivo WORM no son transferibles a través de la red.

Temas relacionados

• os-infrastructure — Sistema Operativo de Nodo PPN — el SO de hipervisor Tipo I que aloja todos los demás tipos de VM
• OS Network Admin — capa Foundation OS; plano de control para la malla PPN
• Totebox Archive — la bóveda de datos WORM soberana que se ejecuta dentro de VM-Totebox
• Descripción General de la Arquitectura PPN — descripción general de PPN en cuatro capas: operador, PPN, hipervisor, orquestación
• Tejido VM Distribuido PPN — extensión entre nodos planificada: préstamo virtio-mem, ledger de capacidades, planificador entre nodos
• Protocolo Génesis — la ceremonia de unión de nodos que inicia la malla desde un único nodo