GRID de computación y metacomputadoras

Autorizar a un piloto de 90 días en tres contornos autónomos

Verificar si la metacomputadora temporal se puede reunir, calcular cerca de los datos y producir el resultado reproductivo de las matrices primarias sin centralizarlas.

El mensaje principal
No construir otra supercomputadora. Crear una capa de confianza que, en el momento de una tarea determinada, combine las capacidades, los datos y las normas desconectados en una metacomputadora controlada.

Decisión recomendada
Aprobar el piloto de diseño; la escala industrial, los datos sensibles reales y los registros interurbanos sólo se permiten mediante decisiones individuales.

03 / Problema y EFECTO TIPO

Hay poderes, pero no forman un recurso manejable común.

Los clasers, las nubes, los aceleradores y las bases pertenecen a distintas organizaciones, utilizan diferentes opciones, políticas, identificadores y formatos de resultados.

• Rotura 1. Es difícil entender dónde hay CPU, GPU, memoria, red, licencias y datos locales.
• Rotura 2. Los planificadores gestionan bien el terreno, pero no ven el poder ni la capacidad de los dominios vecinos.
• Rotura 3. La copia de grandes masas en el centro crea retrasos, duplicaciones, riesgo de fuga y un debate sobre el propietario.
• Rotura 4. Las tareas estrechamente relacionadas con HPC, los conjuntos de masas y las cargas AI requieren distintos marcos de ejecución.
• Rotura 5. El resultado no puede reproducirse independientemente sin la versión del código, las entradas, la política y el entorno.
• Rotura 6. El costo, la energía, la espera y el egress a menudo se consideran separados.

Efectos específicos
Reducir la ruta de la consulta electrónica a un resultado verificable, preservando la soberanía local de los emplazamientos y los propietarios de datos.

04 / CARTA DE TERMINOS

Cuatro definiciones establecen los límites del sistema

Los criterios GRID se basan en la labor de Ian Foster: coordinación de los recursos de los distintos dominios administrativos, protocolos universales abiertos y servicios no tribólicos [1–2].

Fórmula
GRID = CONFIANZA + CATALOG + POLITICA + MARCHUTIZACIÓN + EJECUCIÓN + ENSEÑANZA + DOCUMENTACIÓN

05 /Principios e instrumentos

La Federación es fuerte sólo con restricciones preestablecidas

1. Soberanía local: El emplazamiento conserva el propietario, el planificador local, las cuotas, las normas de acceso y el derecho de denegación.

2. Calcula los datos. En la medida de lo posible, se mueven el código, el plan y la proyección autorizada, en lugar de toda la matriz original.

3. Desactivación mínima. La capa común sólo puede ver la tarjeta de recurso, la política, el estado y el resultado convenido.

4. Contratos abiertos. Las descripciones canónicas de la tarea, el recurso, los datos y los resultados están separados de un producto determinado.

5. MPI/HPC, HTC, AI/GPU, SQL Federación y tareas de tráfico no se limitan a una sola etapa.

6. La política es un código. La admisión, la zona de datos, la duración, el objetivo, el límite de egress y la autoridad se verifican antes y durante el lanzamiento.

7. Reproductividad. El resultado contiene versiones del código, el entorno, las entradas, los parámetros, las políticas y los valores de referencia.

8. Comprobación independiente: El operador no confirma su propia seguridad y corrección.

Sujeto
El contorno local puede rechazar la tarea; la capa común no pasa por alto la política local ni requiere un único acceso root.

06 / LUGAR EN EL EXISTEM

GRID transforma la solicitud analítica en una ejecución electrónica verificada

Fórmula
CUESTION DE LA DECLARACION DE METACOMPUESTO

07 / ARQUITECTURA OBJETIVO

Cinco planos comparten el poder y las corrientes

1. Confianza. Identificación federal, atributos, papeles, certificados, cuentas de servicio, revocación y registro de decisiones.

2. Gestión del catálogo de recursos, corretaje de tareas, política engine, orquestador, cupos, SLA y adaptadores a los sistemas locales.

3. Calculaciones. Slurm/MPI, HTCondor/workflow, Kubernetes Jobs, GPU/FPGA y otros marcos ejecutivos especializados.

4. Datos. Bases de dominio, depósitos de objetos y archivos, catálogos, conectores, pushdown, staging y producción de proyecciones.

5. Prueba: Telemetry, accounting, lineage, valores de referencia, manifiestos, verificación independiente y archivo del patrimonio.

Separación de las corrientes
El administrador de la capa transmite las tareas y el estado; los datos en masa se llevan directamente entre los emplazamientos o se procesan in situ.

Las interfaces abiertas reducen la conexión con el proveedor; los productos locales se conectan con los adaptadores [3–4].

08 /Contrucción y gestión de la confianza

Antes del lanzamiento, el sistema debe responder siete preguntas.

Principio Zero Trust
La ubicación de la red no es motivo suficiente de confianza. El acceso se evalúa para una entidad, un recurso y un contexto concretos, y la solución se ejecuta en el punto de aplicación de la política [24].

09/Formación de instrumentos

La computadora se reúne durante el tiempo de la misión y luego se desactiva.

1. El pasaporte de asignación muestra el objetivo, el código, los datos, SLA, los límites, el precio del error y los criterios de resultado.
2. El catálogo devuelve los emplazamientos compatibles, las versiones de software, los aceleradores, las condiciones de la red y la ubicación de los datos.
3. El rockero está construyendo varios planes de ejecución y evaluando la hora de la cola, la transferencia de datos, el costo y el riesgo.
4. Policy engine examina cada emplazamiento, conjunto de datos, imagen, autoridad y resultado aceptable.
5. La orquesta reserva recursos y transfiere la misión canónica a Slurm, HTCondor o Kubernetes.
6. Durante la ejecución, se reúnen telemetry, checkpoints, acontecimientos de política, contabilidad de recursos y lineage.
7. Después de la verificación, se produce un resultado; se retiran las credenciales provisionales y se limpian las staging por política.

Limitación
WAN no se convierte en una rueda local. Las tareas estrechamente relacionadas MPI se suelen colocar en un solo contorno de baja latencia HPC; las tareas, los datos y los resultados se federan entre los emplazamientos [10].

10 /Clases de la droga y la pesca

El backend correcto es más importante que la cola universal única.

Slurm gestiona los recursos y la cola dentro del grupo [5–7]; HTCondor optimizará los cálculos de tiempo acumulados [8–9]; Kubernetes Jobs ○ uno de los backends para las tareas de contenedores terminadas [11–13].

11 /LOS FEDERATIVOS

Pedido entre contorno, los datos primarios permanecen en el propietario.

Catálogo: Publica Dataset ID, propietario, esquema, versión, calidad, clasificación, estadísticas y endpoint sin necesidad de publicar los datos propiamente dichos.

Semántica. Los diccionarios de dominio y las mappings replicadas vinculan los términos; no se necesita un esquema único y gigante.

El plan de consulta. El filtro, la proyección, la agregación y el join permitido se transfieren a la fuente; el plan y la evaluación de la transferencia se verifican antes del lanzamiento.

Data path. Arrow Flight/Flight SQL u otras esclusas transmiten grandes flujos autorizados; el transporte no sustituye a la autorización.

Materialización. Los derivados y resultados acordados se registran como snapshots; los originales siguen siendo de dominio.

Grabación interinstitucional OLTP no se considera atómico si no se ha demostrado la existencia de un compromiso; la grabación local es preferible, las asignaciones y las sagas.

Regla de admisión
Full scan, cross-source cross join and ilimitado egress están prohibidos por defecto. Primero se demuestra pushdown, selectividad, límite de resultado y valor aceptable [15–19].

12 /Contrato de datos y producción

Cada entrada y resultado obtiene un pasaporte, no solo un nombre de archivo.

Archivo del patrimonio
Guarda el manifiesto, las versiones, las decisiones de acceso, las pruebas y los resultados autorizados. Las fuentes sensibles pueden permanecer en posesión del propietario; el archivo mantiene la referencia y el origen [20–22].

13 / CICLLO DE VIDA

Ocho esclusas hacen que el lanzamiento sea controlado y controvertido.

Fail closed
Si no existe un elemento obligatorio, política, estadística, firma, un indicador o un límite de salida, la tarea no pasará a la siguiente esclusa.

14 / Soberanía y seguridad

La protección se basa en el recurso, los datos y la producción de resultados

Identidad. Cuentas de servicio de corta vida, MTLS, Federación de la Confianza, atributos y respuesta rápida.

Autorización. policy decision para cada llamada y tarea; el punto de aplicación local no confía en la solución central sin verificación.

Aislamiento. Separación tenant/job, sandbox, network policy, secretos protegidos, imágenes firmadas y artefactos allowlist.

Datos. Clasificación, minimización, ocultación, encryption, llaves de contorno local y control de egress.

Resultado. Comprobación de apertura, agregación, límites de línea/volumen, etiquetado, aprobación del propietario.

Supply chain, versión del código fuente, SBOM, firma del ensamblaje, escaneo, provenance e imagen reproducida.

Incidente: aislamiento de la misión, retiro de los créditos, conservación de pruebas, notificación a los propietarios y examen independiente.

Contorno ruso
El piloto necesita una clasificación jurídica de los datos y sistemas, que incluya 149-FZ, 152-FF, 187-FZ y requisitos reglamentarios. Este documento no constituye una opinión jurídica [25–27].

15

La renuncia a un solo dominio no debe convertirse en renuncia a toda la federación.

Fórmula
POSIBLES = IDEMPOTENCIA + CHECKPOINT + LOKALIZIZACIÓN + OBSERVACIÓN + VERIFICACIÓN

16 / OBSERVACIÓN Y ENSEÑANZA DE RECURSOS

Un solo movimiento vincula la cuestión, el plan, el lanzamiento, los datos y el resultado.

Unidad de cálculo
La cuenta se refiere a un job/run determinado y está confirmada por un emplazamiento local. Se propone que las discrepancias en la contabilidad unificada y local no sean superiores a 5%.

OpenTelemetry conecta traces, metrics and logs a través del contexto general [23]; Slurm mantiene los recursos de tareas y pasos [7].

17 / TOLOGÍA PILOTA

Tres dominios son suficientes para probar el propio principio de la federación.

• La capa común. Identidad federal, catálogos, política engine, corredor, orquestador, telémetry y lineage.
• La capa local. Los propietarios conservan los planificadores, los datos, las llaves, las cuotas, las revistas y el derecho STOP.
• Vigilancia independiente. Comprueba por separado la seguridad, la medición, la reproducción y los criterios GO.

No entra automáticamente
CRI crítico, datos personales de combate, OLTP y promesa de producción SLA. Su conexión requiere una autorización separada.

18 / TRES SCENARIAS SECRETARIAS

El piloto verifica los diferentes regímenes de computación de un sistema de reglas

Baseline
Antes de la integración, cada escenario se ejecuta de la manera existente. La comparación se basa en el tiempo registrado, el trabajo manual, portes moved, el costo y la calidad del resultado.

Los escenarios son una propuesta de ensayo y no una declaración de productividad.

19 / Plan para 90 días

Cinco etapas de control llevan del pasaporte a una solución independiente

Gestión del cambio
Toda ampliación de datos, emplazamientos, facultades o promesas públicas se presenta como una nueva versión del perímetro y se vuelve a permitir.

20 / KPI Y CRITERIOS

GO requiere un resultado funcional, seguro y económico a la vez

Todos los umbrales numéricos son los criterios del piloto. No son la norma de la industria y se ajustan antes de comenzar con la baseline.

21/RISKI Y MODEL DE GESTIÓN

El principal riesgo es crear una imagen de unidad donde se necesiten límites claros

Criterios STOP
El egreso no autorizado, el abandono de la política local, la pérdida de origen, la vulnerabilidad crítica sin compensación o la imposibilidad de realizar una verificación independiente, detienen al piloto.

22 / DECISIÓN Y PRÓXIMO PERÍODO DE SESIONES

GRID crea un sistema general de cálculo por poder, no un depósito común de recursos

Observaciones finales
La superficie conserva recursos, datos y normas. GRID añade la identidad general, el catálogo, la planificación, la prueba y la producción segura de los resultados.

GO. Se han cumplido todos los criterios críticos; se permite la siguiente fila con nuevos nudos y cargas.

CONDITIONAL GO. Se ha confirmado el valor, pero hay una lista limitada de espacios cerrados y un plazo para la reverificación.

STOP. La soberanía, la seguridad, la reproducción o la economía no están confirmadas; el prototipo se archiva sin expansión industrial.

Medida solicitada
Nombrar al propietario del piloto, a los propietarios de tres dominios y a un paladín independiente; aprobar el pasaporte y la base de datos en un plazo de 15 días.

23 / FUENTES OFICIALES Y PRIVAS · 1

GRID, Planificación y ejecución

[1] Ian Foster: What Is the Grid? A Three Point Checklist

[2] Foster, Kesselman, Tuecke: The Anatomy of the Grid

[3] Open Grid Forum: Standards and interoperability

[4] Open Grid Forum: Authorization Framework (GFD.38)

[5] Slurm Workload Manager: Overview

[6] Slurm Workload Manager: Federation Guide

[7] Slurm Workload Manager: Accounting and Resource Limits

[8] HTCondor: High-Throughput Computing and its Requirements

[9] HTCondor Manual: Job Scheduling

[10] MPI Forum: MPI 5.0 Standard

[11] Kubernetes: Jobs

[12] Kubernetes: Scheduling Framework

[13] Kubernetes: Device Plugins

[14] Globus: Collections and Endpoints

Fecha de presentación: 29 agosto de 2026 Las versiones de los programas y documentos deben revisarse antes del diseño del piloto.

24 / FUENTES OFICIALES Y PRIVAS · 2

Datos federales, origen, vigilancia y seguridad

[15] Trino: Concepts and federated catalogs

[16] Trino PostgreSQL connector: Pushdown

[17] PostgreSQL: postgres_fdw Remote Query Optimization

[18] Apache Iceberg: Table Specification

[19] Apache Arrow: Flight RPC and Flight SQL

[20] W3C: Data Catalog Vocabulary DCAT 3

[21] W3C: PROV-O — provenance ontology

[22] OpenLineage: Object Model

[23] OpenTelemetry: Signals and context propagation

[24] NIST SP 800-207: Zero Trust Architecture

[25] Ley federal No. 149-FZ sobre la información, la tecnología de la información y la protección de la información

[26] Ley federal No. 152-FZ sobre datos personales

[27] Ley federal No 187-FZ sobre la seguridad de la infraestructura crítica de información de la Federación de Rusia

Las referencias jurídicas son de orientación. La aplicabilidad de las normas, la redacción y los requisitos reglamentarios está confirmada por los abogados competentes y los propietarios de los sistemas de información antes de la admisión de datos.