Краткая аннотация
О документе
Концепция федеративных баз, распределённых вычислений и метакомпьютерной инфраструктуры.
Vychislitelnyi_GRID_Metakompyutery_Federativnye_bazy_Bolshie_vychisleniya.pptx
Загружаем документ…
ЭКВИЛИБРИУМ · СФЕРА · СПЕЦЗАЩИТА · АРХИВ НАСЛЕДИЯ
Автор: Соколов Сергей Леонидович · 29 августа 2026 г.
Статус: архитектурная гипотеза для технической, правовой и независимой экспертной проверки
02 / РЕШЕНИЕ ДЛЯ РУКОВОДИТЕЛЯ
Разрешить 90-дневный пилот на трёх автономных контурах
Проверить, можно ли собрать под задачу временный метакомпьютер, выполнить вычисление рядом с данными и выпустить воспроизводимый результат — без централизации первичных массивов.
Главный тезис
Не строить ещё один суперкомпьютер. Создать доверенный слой, который на время конкретной задачи объединяет разрозненные мощности, данные и правила в управляемый метакомпьютер.
| Параметр | Предложение |
|---|---|
| Периметр | Три независимых административных домена: HPC/CPU, GPU/контейнерный контур и доменный узел данных. |
| Сценарии | Тесно связанный расчёт; массовый ансамбль; федеративная аналитика с переносом вычисления к данным. |
| Режим | Синтетические, обезличенные или специально разрешённые данные; без автоматического включения критических производственных наборов. |
| Результат | Рабочий прототип, журнал политик, манифесты происхождения, измерения времени/стоимости/сетевого обмена и независимый протокол. |
| Решение на 90-й день | GO, CONDITIONAL GO или STOP по заранее утверждённым критериям. |
Рекомендуемое решение
Утвердить проектировочный пилот; промышленное масштабирование, реальные чувствительные данные и межконтурные записи разрешать только отдельными решениями.
03 / ПРОБЛЕМА И ЦЕЛЕВОЙ ЭФФЕКТ
Мощности есть, но они не образуют общий управляемый ресурс
Кластеры, облака, ускорители и базы принадлежат разным организациям, используют разные очереди, политики, идентификаторы и форматы результата.
- Разрыв 1. Трудно понять, где есть подходящие CPU, GPU, память, сеть, лицензии и локальные данные.
- Разрыв 2. Планировщики хорошо управляют площадкой, но не видят полномочия и возможности соседних доменов.
- Разрыв 3. Копирование больших массивов в центр создаёт задержки, дубли, риск утечки и спор о владельце.
- Разрыв 4. Тесно связанные HPC-задачи, массовые ансамбли и AI-нагрузки требуют разных исполнительных контуров.
- Разрыв 5. Результат без версии кода, входов, политики и среды нельзя независимо воспроизвести.
- Разрыв 6. Стоимость, энергия, ожидание в очереди и сетевой egress часто считаются раздельно.
Целевой эффект
Сократить путь от вычислительного запроса до проверяемого результата, сохранив локальный суверенитет площадок и владельцев данных.
04 / КАРТА ТЕРМИНОВ
Четыре определения задают границы системы
| Понятие | Рабочее определение | Жёсткая граница |
|---|---|---|
| Вычислительный ГРИД | Федерация ресурсов разных контуров управления с общими правилами идентификации, обнаружения, маршрутизации, запуска и учёта. | Не единый кластер и не глобальный администратор. |
| Метакомпьютер | Временная логическая машина, собираемая под задачу из подходящих CPU, GPU, HPC, облачных и edge-ресурсов. | Не обещает общей памяти и низкой задержки между всеми узлами. |
| Федеративный слой данных | Каталог, семантика, политика и исполнение разрешённых запросов над автономными источниками. | Не единая мировая база и не автоматическая репликация исходников. |
| Большие вычисления | Задачи, превышающие возможности одного узла или контура по данным, операциям, памяти, ускорителям либо сроку ответа. | Размер определяется профилем задачи, а не рекламным ярлыком. |
Критерии GRID основаны на работах Иэна Фостера: координация ресурсов разных административных доменов, открытые универсальные протоколы и нетривиальное качество сервиса [1–2].
Формула
ГРИД = ДОВЕРИЕ + КАТАЛОГ + ПОЛИТИКА + МАРШРУТИЗАЦИЯ + ИСПОЛНЕНИЕ + УЧЁТ + ДОКАЗАТЕЛЬСТВО
05 / ПРИНЦИПЫ И ИНВАРИАНТЫ
Федерация сильна только при заранее заданных ограничениях
1. Локальный суверенитет. площадка сохраняет владельца, локальный планировщик, квоты, правила доступа и право отказа.
2. Вычисление к данным. по возможности перемещаются код, план и разрешённая проекция, а не весь исходный массив.
3. Минимальное раскрытие. общий слой видит только необходимую карточку ресурса, политику, состояние и согласованный результат.
4. Открытые контракты. канонические описания задания, ресурса, данных и результата отделены от конкретного продукта.
5. Разные маршруты нагрузок. MPI/HPC, HTC, AI/GPU, SQL-федерация и потоковые задачи не сводятся к одной очереди.
6. Политика как код. допуск, зона данных, срок, цель, лимит egress и полномочия проверяются до запуска и во время него.
7. Воспроизводимость. результат содержит версии кода, среды, входов, параметров, политики и контрольные суммы.
8. Независимая проверка. оператор не подтверждает собственную безопасность и корректность единолично.
Инвариант
Локальный контур может отклонить задание; общий слой не обходит локальную политику и не требует единого root-доступа.
06 / МЕСТО В ЭКОСИСТЕМЕ
ГРИД превращает аналитический запрос в проверяемое вычислительное исполнение
| Контур | Роль | Граница ответственности |
|---|---|---|
| ЭКВИЛИБРИУМ | Формирует вопрос, сценарий, риск-модель и требования к результату. | Не владеет исходными данными и не администрирует площадки. |
| Вычислительный ГРИД | Подбирает ресурсы, строит план, получает допуски, запускает и контролирует задание. | Не заменяет локальные планировщики и владельцев. |
| Система фондов / ECO-PPA | Закрепляет мандат, бюджет, контракт, данные и ожидаемый результат проекта. | Не является вычислительным backend. |
| СПЕЦЗАЩИТА | Развёртывание, укрепление, эксплуатация, реагирование и кооперация. | Не валидирует собственную работу единолично. |
| СФЕРА | Участники, компетенции, случаи применения, знания и обратная связь. | Не подменяет орган допуска и планировщик. |
| Архив наследия | Версии, происхождение, решения о доступе, манифесты и разрешённые результаты. | Не обязан централизовать чувствительные исходники. |
Формула
ВОПРОС → ПАСПОРТ ЗАДАНИЯ → МЕТАКОМПЬЮТЕР → ВЫЧИСЛЕНИЕ → ПРОВЕРКА → АРХИВ → НОВЫЙ ЦИКЛ
07 / ЦЕЛЕВАЯ АРХИТЕКТУРА
Пять плоскостей разделяют полномочия и потоки
1. Доверие. федеративная идентификация, атрибуты, роли, сертификаты, сервисные учётные записи, отзыв и журнал решений.
2. Управление. каталог ресурсов, брокер заданий, policy engine, оркестратор, квоты, SLA и адаптеры к локальным системам.
3. Вычисления. Slurm/MPI, HTCondor/workflow, Kubernetes Jobs, GPU/FPGA и иные специализированные исполнительные контуры.
4. Данные. доменные базы, объектные и файловые хранилища, каталоги, коннекторы, pushdown, staging и выпуск проекций.
5. Доказательность. telemetry, accounting, lineage, контрольные суммы, манифесты, независимая проверка и Архив наследия.
Разделение потоков
Управляющий слой передаёт задания и состояние; массовые данные идут по разрешённому data path напрямую между площадками или обрабатываются на месте.
Открытые интерфейсы снижают привязку к поставщику; локальные продукты подключаются адаптерами [3–4].
08 / КОНТУР ДОВЕРИЯ И УПРАВЛЕНИЯ
До запуска система должна ответить на семь вопросов
| Вопрос | Проверяемый объект | Результат шлюза |
|---|---|---|
| Кто? | Пользователь, сервис, организация, роль, атрибуты. | Подтверждённая идентичность. |
| Зачем? | Цель обработки, проект, правовое и договорное основание. | Разрешённое назначение. |
| Что? | Код, контейнер, модель, версия, зависимости, SBOM. | Допущенный артефакт. |
| Над чем? | Dataset ID, класс данных, владелец, разрешённая проекция. | Разрешённые входы. |
| Где? | Контур, регион, аппаратный профиль, доверенная зона. | Допустимое размещение. |
| Сколько? | CPU/GPU, память, время, egress, бюджет, энергия. | Квота и пределы. |
| Что можно выпустить? | Агрегаты, модель, отчёт, артефакт, чувствительность. | Политика выхода результата. |
Принцип Zero Trust
Сетевое расположение не является достаточным основанием доверия. Доступ оценивается для конкретного субъекта, ресурса и контекста, а решение исполняется в точке применения политики [24].
09 / ФОРМИРОВАНИЕ МЕТАКОМПЬЮТЕРА
Метакомпьютер собирается на время задачи и затем демонтируется
- Паспорт задания фиксирует цель, код, данные, SLA, ограничения, цену ошибки и критерии результата.
- Каталог возвращает совместимые площадки, версии ПО, ускорители, сетевые условия и локальность данных.
- Брокер строит несколько планов исполнения и оценивает время очереди, перенос данных, стоимость и риск.
- Policy engine проверяет каждую площадку, набор данных, образ, полномочия и допустимый результат.
- Оркестратор резервирует ресурсы и переводит каноническое задание в Slurm, HTCondor или Kubernetes.
- Во время исполнения собираются telemetry, checkpoints, события политики, учёт ресурсов и lineage.
- После проверки выпускается результат; временные полномочия отзываются, staging очищается по политике.
Ограничение
WAN не превращается в локальную шину. Тесно связанную MPI-задачу обычно размещают целиком в одном низколатентном HPC-контуре; между площадками федерализуются задания, данные и результаты [10].
10 / КЛАССЫ НАГРУЗКИ И МАРШРУТИЗАЦИЯ
Правильный backend важнее единой универсальной очереди
| Класс | Признак | Предпочтительный маршрут | Ключевая метрика |
|---|---|---|---|
| HPC / MPI | Тесная связь, низкая задержка, коллективные обмены. | Slurm + MPI в одной площадке. | Time-to-solution, масштабирование. |
| HTC / ансамбли | Много независимых или слабосвязанных запусков. | HTCondor + DAG/workflow. | Заданий/сутки, success rate. |
| AI / GPU | Ускорители, большие модели, контейнеры, данные рядом. | Kubernetes Jobs или GPU-раздел Slurm. | GPU utilization, время/эпоха. |
| Большие данные | Scan/join/aggregation над доменными источниками. | Federated query + pushdown/materialization. | Bytes moved, query latency. |
| Edge / поток | Реальное время, ограниченный канал, локальный контекст. | Локальное выполнение + агрегаты. | Задержка, потеря событий. |
| Workflow | Цепочка разных этапов и площадок. | Оркестратор + checkpoints + lineage. | Critical path, повторяемость. |
Slurm управляет ресурсами и очередью внутри кластера [5–7]; HTCondor оптимизирует накопленный объём вычислений во времени [8–9]; Kubernetes Jobs — один из backend для завершаемых контейнерных задач [11–13].
11 / ФЕДЕРАТИВНЫЙ СЛОЙ ДАННЫХ
Запрос проходит между контурами, первичные данные остаются у владельца
Каталог. публикует Dataset ID, владельца, схему, версию, качество, классификацию, статистику и endpoint без обязательной публикации самих данных.
Семантика. доменные словари и версионированные mappings связывают термины; единая гигантская схема не требуется.
План запроса. фильтр, проекция, агрегация и допустимый join переносятся к источнику; план и оценка transfer проверяются до запуска.
Data path. Arrow Flight/Flight SQL или иные шлюзы передают разрешённые большие потоки; транспорт не заменяет авторизацию.
Материализация. согласованные производные наборы и результаты фиксируются как версионированные snapshots; исходники остаются доменными.
Запись. междоменный OLTP не считается атомарным без доказанного distributed commit; предпочтительны локальная запись, идемпотентные задания и саги.
Правило допуска
Full scan, cross-source cross join и неограниченный egress запрещены по умолчанию. Сначала доказываются pushdown, селективность, лимит результата и допустимая стоимость [15–19].
12 / КОНТРАКТ ДАННЫХ И ПРОИСХОЖДЕНИЕ
Каждый вход и результат получает паспорт, а не только имя файла
| Поле контракта | Минимальное содержание |
|---|---|
| Идентичность | Canonical dataset_id / result_id, владелец, домен, контакт, назначение. |
| Версия | Схема, snapshot, временной срез, контрольная сумма, дата актуальности. |
| Семантика | Термины словаря, единицы, кодировки, часовой пояс, null/collation semantics. |
| Качество | Полнота, точность, допустимые пропуски, статистика и дата её обновления. |
| Политика | Класс, цель, субъекты, зоны, срок, egress, маскирование, retention. |
| Интерфейс | Endpoint, protocol, query capabilities, pushdown, rate/size limits. |
| Lineage | job_id/run_id, код, образ, параметры, входы, выходы, преобразования. |
| Выпуск | Валидатор, допуск, ограничения интерпретации, срок действия результата. |
Архив наследия
Хранит манифест, версии, решения о доступе, доказательства и разрешённые результаты. Чувствительные исходники могут оставаться у владельца; архив сохраняет ссылку и происхождение [20–22].
13 / ЖИЗНЕННЫЙ ЦИКЛ ЗАДАНИЯ
Восемь шлюзов делают запуск управляемым и оспоримым
| Шлюз | Решение | Обязательный след |
|---|---|---|
| J0 · Запрос | Есть владелец вопроса и измеримый результат. | Паспорт запроса. |
| J1 · Классификация | Определены нагрузка, данные и зона. | Класс задания и данных. |
| J2 · Полномочия | Субъект и цель допущены. | Policy decision + основание. |
| J3 · План | Выбран допустимый маршрут и backend. | План, оценки времени/цены/egress. |
| J4 · Резерв | Выделены квоты, устройства, данные и окно. | Reservation / allocation IDs. |
| J5 · Выполнение | Задание в пределах политики и SLA. | Telemetry, events, checkpoints. |
| J6 · Проверка | Результат корректен и безопасен к выпуску. | Тесты, validator, checksum. |
| J7 · Архив | Цепочка воспроизводима; доступы отозваны. | Manifest, lineage, release record. |
Fail closed
Если отсутствует обязательный атрибут, политика, статистика, подпись, валидатор или лимит выхода, задание не переходит к следующему шлюзу.
14 / СУВЕРЕНИТЕТ И БЕЗОПАСНОСТЬ
Защита строится вокруг ресурса, данных и выпуска результата
Идентичность. короткоживущие сервисные учётные данные, mTLS, федерация доверия, атрибуты и быстрый отзыв.
Авторизация. policy decision для каждого вызова и задания; локальная точка применения не доверяет центральному решению без проверки.
Изоляция. разделение tenant/job, sandbox, network policy, защищённые секреты, подписанные образы и allowlist артефактов.
Данные. классификация, минимизация, маскирование, encryption, ключи в локальном контуре и контроль egress.
Результат. проверка на раскрытие, агрегирование, лимиты строк/объёма, маркировка, утверждение владельца.
Supply chain. версия исходного кода, SBOM, подпись сборки, сканирование, provenance и воспроизводимый образ.
Инцидент. изоляция задания, отзыв credentials, сохранение доказательств, уведомление владельцев и независимый разбор.
Российский контур
До пилота требуется правовая классификация данных и систем с учётом 149-ФЗ, 152-ФЗ, 187-ФЗ и подзаконных требований. Этот документ не является юридическим заключением [25–27].
15 / НАДЁЖНОСТЬ И ОТКАЗОУСТОЙЧИВОСТЬ
Отказ одного домена не должен превращаться в отказ всей федерации
| Сбой | Реакция | Проверка пилота |
|---|---|---|
| Недоступна площадка | Перепланирование только на совместимый и разрешённый ресурс. | Искусственное отключение домена. |
| Разрыв сети | Локальное продолжение, буфер событий, checkpoint или безопасная остановка. | Ограничение канала/потеря связи. |
| Сбой узла | Повтор шага, восстановление из checkpoint, идемпотентность. | Kill node / pod / task. |
| Истёк допуск | Новый policy decision; без него — остановка и отзыв. | Отзыв роли во время задания. |
| Изменилась схема | Fail fast или версионированный adapter; запись факта несовместимости. | Контролируемый schema drift. |
| Недостоверный результат | Карантин, повтор, независимая проверка и запрет выпуска. | Fault injection / corrupted output. |
| Сбой control plane | Резервирование состояния; локальные задания не получают новых привилегий. | Перезапуск оркестратора. |
Формула
НАДЁЖНОСТЬ = ИДЕМПОТЕНТНОСТЬ + CHECKPOINT + ЛОКАЛИЗАЦИЯ ОТКАЗА + НАБЛЮДАЕМОСТЬ + ПРОВЕРКА
16 / НАБЛЮДАЕМОСТЬ И РЕСУРСНЫЙ УЧЁТ
Единый trace связывает вопрос, план, запуск, данные и результат
| Сигнал | Что измерять | Управленческий смысл |
|---|---|---|
| Trace | job_id/run_id, шлюзы, адаптеры, backend, data endpoints. | Где возникла задержка или отказ. |
| Metrics | queue time, wall time, CPU/GPU/memory, bytes moved, retries. | Эффективность и узкие места. |
| Logs | решения политики, события планировщиков, ошибки, ручные действия. | Расследование и ответственность. |
| Profiles | ресурсное потребление кода и горячие участки. | Оптимизация приложения. |
| Accounting | ресурс-время, лицензии, egress, энергия, ставка площадки. | Стоимость задания и квоты. |
| Lineage | версии входов, кода, образа, параметров и выходов. | Воспроизводимость результата. |
Единица расчёта
Учётная запись относится к конкретному job/run и подтверждается локальной площадкой. Предлагаемый пилотный допуск расхождения сводного и локального учёта — не более ±5%.
OpenTelemetry связывает traces, metrics и logs через общий контекст [23]; Slurm поддерживает учёт ресурсов заданий и шагов [7].
17 / ТОПОЛОГИЯ ПИЛОТА
Три домена достаточно, чтобы проверить сам принцип федерации
| Домен | Ресурс и локальный контроль | Адаптер | Проверяемая гипотеза |
|---|---|---|---|
| A · HPC/CPU | Slurm, MPI, параллельная ФС, локальная IAM/QoS. | Grid→Slurm. | Тесно связанная задача остаётся на одной площадке. |
| B · GPU/контейнеры | Kubernetes Jobs или GPU-раздел Slurm, registry, device plugins. | Grid→K8s/Slurm. | Подбор ускорителя и воспроизводимого образа. |
| C · Данные/edge | Доменная БД/объектное хранилище, собственная политика и шлюз. | Federated query/Flight. | Вычисление к данным и выпуск проекции. |
- Общий слой. Федеративная идентичность, каталоги, policy engine, брокер, оркестратор, telemetry и lineage.
- Локальный слой. Владельцы сохраняют планировщики, данные, ключи, квоты, журналы и право STOP.
- Независимый контроль. Отдельно проверяет безопасность, измерения, воспроизводимость и критерии GO.
Не входит автоматически
Критическая КИИ, боевые персональные данные, межконтурный OLTP и обещание производственного SLA. Их подключение требует отдельного допуска.
18 / ТРИ СКВОЗНЫХ СЦЕНАРИЯ
Пилот проверяет разные вычислительные режимы одной системой правил
| Сценарий | Маршрут | Проверяемый результат |
|---|---|---|
| 1. Ансамблевое моделирование биосферного риска | Сотни независимых вариантов → HTC; агрегирование → HPC/аналитический узел. | Сокращение time-to-first-result, успешность повторов, lineage каждого варианта. |
| 2. GPU-анализ пространственных данных | Контейнер и модель к разрешённому GPU/данным; выпуск маски/агрегата. | Подбор устройства, контроль образа, отсутствие неразрешённого вывода исходников. |
| 3. Федеративная аналитика воды, почв и биоразнообразия | Каталог → pushdown к доменным источникам → согласованный результат. | Объём перемещения, корректность семантики, план запроса и воспроизводимость. |
Baseline
До интеграции каждый сценарий выполняется существующим способом. Сравнение строится с зафиксированной базой по времени, ручному труду, bytes moved, стоимости и качеству результата.
Сценарии являются предложением для апробации, а не заявлением о достигнутой производительности.
19 / ПЛАН НА 90 ДНЕЙ
Пять контрольных этапов ведут от паспорта к независимому решению
| Период | Работы | Контрольный выход |
|---|---|---|
| Дни 1–15 | Три задачи, baseline, владельцы, классификация данных, границы, SLA и STOP-критерии. | Паспорт пилота и архитектурные решения. |
| Дни 16–30 | Подключение доменов, федеративная идентичность, каталоги ресурсов/данных, policy model. | Три зарегистрированных узла и сухие допуски. |
| Дни 31–55 | Брокер, адаптеры, workflow, telemetry, accounting, lineage и первый сквозной запуск. | Рабочий прототип и манифест результата. |
| Дни 56–75 | Повторные прогоны, нагрузка, отказ узла, разрыв сети, отзыв полномочий, контроль egress. | Протокол устойчивости и безопасности. |
| Дни 76–90 | Независимая проверка, воспроизводимость, стоимость, runbooks, модель ответственности. | Заключение GO / CONDITIONAL GO / STOP. |
Управление изменениями
Любое расширение данных, площадок, полномочий или публичных обещаний оформляется как новая версия периметра и проходит повторный допуск.
20 / KPI И КРИТЕРИИ ПРИЁМКИ
GO требует одновременно функционального, безопасного и экономического результата
| Критерий | Предлагаемый порог пилота |
|---|---|
| Федерация | Подключены ≥3 независимых административных домена; локальные политики сохраняются. |
| Сценарии | Выполнены 3 сквозных сценария разных классов нагрузки. |
| Надёжность | После стабилизации ≥95% запусков завершаются без ручного восстановления. |
| Скорость | Для 2 из 3 сценариев time-to-first-result лучше baseline минимум на 30%. |
| Суверенитет | 0 неразрешённых перемещений первичных данных между контурами. |
| Политика | 100% межконтурных операций проверены и журналированы. |
| Lineage | 100% выпущенных результатов имеют владельца, входы, код, параметры и версии. |
| Воспроизводимость | ≥90% контрольных результатов повторяются в установленном допуске. |
| Подключаемость | Новый совместимый узел подключается ≤5 рабочих дней по инструкции. |
| Учёт | Расхождение сводного и локального учёта ресурса/стоимости ≤±5%. |
| Безопасность | Нет незакрытых критических замечаний; есть независимый протокол. |
Все численные пороги — проектные критерии пилота. Они не являются отраслевым стандартом и корректируются до старта вместе с baseline.
21 / РИСКИ И МОДЕЛЬ УПРАВЛЕНИЯ
Главный риск — создать видимость единства там, где нужны явные границы
| Риск | Ранний сигнал | Мера управления |
|---|---|---|
| Глобальный root | Центр требует постоянных привилегий на всех узлах. | Короткоживущие права, локальные PEP, разделение ролей. |
| Централизация данных | Пилот начинается с копирования всех наборов. | Каталог и pushdown; egress budget; локальные snapshots. |
| Универсальный планировщик | Одинаковая политика для MPI, HTC, AI и SQL. | Классификация нагрузки и адаптеры к backend. |
| Семантическая ошибка | Совпадают имена полей, но различаются смысл/единицы. | Глоссарий, mappings, проверки качества и версии. |
| Vendor lock-in | Каноническая модель повторяет API одного продукта. | Открытые контракты и тест замены адаптера. |
| Скрытая стоимость | Не учитываются очередь, egress, лицензии, энергия. | Единый job accounting и сверка площадок. |
| Невоспроизводимость | Результат выпущен без входного snapshot или версии кода. | J6/J7 fail closed; манифест обязателен. |
| Самопроверка | Оператор единолично подтверждает безопасность и KPI. | Независимый валидатор и протокол приёмки. |
STOP-критерии
Неразрешённый egress, обход локальной политики, утрата происхождения, критическая уязвимость без компенсации или невозможность независимой проверки останавливают пилот.
22 / РЕШЕНИЕ И СЛЕДУЮЩАЯ ОЧЕРЕДЬ
ГРИД создаёт общий порядок доверенного вычисления, а не общий склад ресурсов
Финальный тезис
Площадка сохраняет ресурсы, данные и правила. ГРИД добавляет общую идентичность, каталог, планирование, доказательность и безопасный выпуск результата.
GO. все критические критерии выполнены; разрешается следующая очередь с новыми узлами и нагрузками.
CONDITIONAL GO. ценность подтверждена, но есть ограниченный перечень закрываемых разрывов и срок повторной проверки.
STOP. суверенитет, безопасность, воспроизводимость или экономика не подтверждены; прототип архивируется без промышленного расширения.
| Следующая очередь после GO | Предмет |
|---|---|
| Интероперабельность | Тест второго продукта в каждом классе: scheduler, catalog, data transport, observability. |
| Масштаб | Подключение новых организаций, квоты, многоуровневые политики и нагрузочное моделирование. |
| Экономика | Тарифные единицы, резервирование, cost allocation, энергия и механизм споров. |
| Право и доверие | Договор федерации, ответственность, сертификаты, аудит, реагирование и порядок выхода. |
Запрашиваемое действие
Назначить владельца пилота, владельцев трёх доменов и независимого валидатора; в течение 15 дней утвердить паспорт и baseline.
23 / ОФИЦИАЛЬНЫЕ И ПЕРВИЧНЫЕ ИСТОЧНИКИ · 1
GRID, планирование и исполнительные контуры
[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
Дата обращения: 29 августа 2026 г. Версии программных продуктов и документов следует повторно проверить перед проектированием пилота.
24 / ОФИЦИАЛЬНЫЕ И ПЕРВИЧНЫЕ ИСТОЧНИКИ · 2
Федеративные данные, происхождение, наблюдаемость и безопасность
[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] Федеральный закон № 149-ФЗ «Об информации, информационных технологиях и о защите информации»
[26] Федеральный закон № 152-ФЗ «О персональных данных»
[27] Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры РФ»
Правовые ссылки приведены для ориентира. Применимость норм, редакции и подзаконных требований подтверждаются профильными юристами и владельцами информационных систем до допуска данных.
Исходные материалы
Оригиналы и версии документа
- Vychislitelnyi_GRID_Metakompyutery_Federativnye_bazy_Bolshie_vychisleniya.docxDOCX · основной документ
- Vychislitelnyi_GRID_Metakompyutery_Federativnye_bazy_Bolshie_vychisleniya.pptxPPTX · связанная версия
Другие редакции в веб-формате
Каждая версия раскрывается отдельно; последовательность исходного документа сохранена.
Вычислительный ГРИДVychislitelnyi_GRID_Metakompyutery_Federativnye_bazy_Bolshie_vychisleniya.pptx · веб-текст+
Метакомпьютеры, федеративные базы и работа с большими вычислениями
Общий порядок доверенного вычисления
при локальном владении ресурсами и данными
Соколов Сергей Леонидович
Решение сейчас — ограниченный 90-дневный пилот
ЗАПРОС НА РЕШЕНИЕ
Периметр
задачи, baseline, данные, владельцы, STOP-критерии
Подключение
идентичность, каталоги, политики и адаптеры
ДНЕЙ
Сквозной запуск
HPC, GPU/AI и федеративная аналитика
3 автономных домена
3 класса нагрузки
1 независимый протокол
Испытания
отказ узла, отзыв прав, egress и воспроизводимость
Решение
GO, CONDITIONAL GO или STOP по измеримым KPI
Промышленное масштабирование — только отдельным решением
Соколов Сергей Леонидович
Изолированные мощности не образуют общий ресурс
ПРОБЛЕМА
Что ломает сквозной расчёт
HPC
MPI / CPU / низкая задержка
разные идентичности, очереди, квоты и форматы задания
копирование больших массивов вместо вычисления рядом с данными
GPU
AI / ускорители / контейнеры
одна универсальная политика для MPI, HTC, AI и SQL
DATA
результат без версии входов, кода, среды и решения о доступе
доменные БД / объекты / edge
раздельный учёт очереди, egress, ускорителей, энергии и стоимости
Централизация всего в одном месте переносит проблему — но не решает её
Соколов Сергей Леонидович
Четыре определения задают границы системы
ТЕРМИНЫ
федерация ресурсов разных контуров управления
ВЫЧИСЛИТЕЛЬНЫЙ ГРИД
не единый кластер
временная логическая машина, собранная под задачу
МЕТАКОМПЬЮТЕР
не общая WAN-память
каталог, политика и разрешённый запрос над автономными источниками
ФЕДЕРАТИВНЫЙ СЛОЙ ДАННЫХ
не мировая БД
задача вне возможностей одного узла или контура
БОЛЬШИЕ ВЫЧИСЛЕНИЯ
не рекламный ярлык
ГРИД = доверие + каталог + политика + маршрут + исполнение + учёт + доказательство
Соколов Сергей Леонидович
Три инварианта удерживают федерацию от централизации
АРХИТЕКТУРНЫЕ ПРИНЦИПЫ
Локальный суверенитет
Вычисление к данным
Проверяемый результат
Площадка сохраняет планировщик, квоты, ключи, данные и право STOP.
Перемещаются код, план и разрешённая проекция; исходники остаются у владельца.
Версии входов, кода, среды, политики и lineage обязательны для выпуска.
default deny
policy-as-code
открытые контракты
разные backend
независимая проверка
Соколов Сергей Леонидович
ГРИД связывает вопрос, вычисление и доказательство
МЕСТО В ЭКОСИСТЕМЕ
ЭКВИЛИБРИУМ
ГРИД
ПРОВЕРКА
АРХИВ
вопрос, сценарий, риск и требования
план, ресурсы, допуски и исполнение
корректность, безопасность и выпуск
версии, lineage и разрешённый результат
СФЕРА
СПЕЦЗАЩИТА
ECO-PPA / ФОНДЫ
участники, компетенции, кейсы и знания
развёртывание, эксплуатация и реагирование
мандат, контракт, бюджет и ожидаемый результат
Ни один контур не совмещает владение данными, исполнение и окончательную самопроверку
Соколов Сергей Леонидович
Пять плоскостей разделяют полномочия и потоки
ЦЕЛЕВАЯ АРХИТЕКТУРА
telemetry · accounting · lineage · контрольные суммы · Архив
5 · ДОКАЗАТЕЛЬНОСТЬ
каталог · семантика · pushdown · staging · разрешённые проекции
4 · ДАННЫЕ
Slurm/MPI · HTCondor/workflow · Kubernetes Jobs · GPU/edge
3 · ВЫЧИСЛЕНИЯ
каталог ресурсов · broker · orchestrator · policy engine · квоты
2 · УПРАВЛЕНИЕ
identity · роли · атрибуты · сертификаты · отзыв · аудит
1 · ДОВЕРИЕ
CONTROL PLANE
DATA PLANE
Соколов Сергей Леонидович
Метакомпьютер собирается под задачу — и затем исчезает
ДИНАМИЧЕСКАЯ СБОРКА
ПАСПОРТ
КАТАЛОГ
ПЛАН
ДОПУСК
ЗАПУСК
цель · код · данные · SLA
CPU/GPU · ПО · зона · очередь
время · egress · цена · риск
identity · policy · квота
Slurm · Condor · K8s
ВО ВРЕМЯ
telemetry · checkpoints · policy events · resource accounting
ПОСЛЕ
проверка результата · манифест · отзыв прав · очистка staging
WAN не становится локальной шиной: тесно связанную MPI-задачу размещают в одном низколатентном HPC-контуре
Соколов Сергей Леонидович
Запрос проходит между контурами — исходники остаются
ФЕДЕРАТИВНЫЙ СЛОЙ ДАННЫХ
ДОМЕН A
QUERY + POLICY
ДОМЕН B
БД / объектное хранилище
владелец · политика · ключи
каталог · семантика · план
pushdown · egress budget
разрешённая проекция
агрегат · snapshot · результат
Обязательные проверки
ЗАПРЕЩЕНО ПО УМОЛЧАНИЮ
- статистика и план запроса актуальны
- filter / projection / aggregation выполняются у источника
- объём transfer и размер результата ограничены
- семантика единиц, времени, null и типов согласована
- междоменная запись не предполагается атомарной без доказательства
full scan
cross-source cross join
неограниченный egress
«единая мировая БД»
Соколов Сергей Леонидович
Восемь шлюзов делают задание управляемым
ЖИЗНЕННЫЙ ЦИКЛ
Запрос
Класс
Права
План
кто + зачем + над чем + где + сколько + что можно выпустить
Архив
Проверка
Запуск
Резерв
Нет обязательного атрибута, подписи, лимита или валидатора — следующий шлюз закрыт
Соколов Сергей Леонидович
Безопасность, наблюдаемость и воспроизводимость едины
ДОВЕРИЕ К РЕЗУЛЬТАТУ
ЗАЩИТА
НАБЛЮДАЕМОСТЬ
ВОСПРОИЗВОДИМОСТЬ
identity
короткие credentials
локальные ключи
изоляция
контроль egress
trace
metrics
logs
profiles
accounting
входной snapshot
версия кода
образ и параметры
policy decision
lineage
Российский контур: применимость 149-ФЗ, 152-ФЗ, 187-ФЗ и подзаконных мер квалифицируется владельцами систем до допуска данных
Соколов Сергей Леонидович
Три автономных домена проверяют сам принцип GRID
ТОПОЛОГИЯ ПИЛОТА
A · HPC / CPU
GRID CONTROL
B · GPU / AI
Slurm · MPI · локальная IAM/QoS
catalog · broker · policy · orchestrator
Kubernetes Jobs или GPU-раздел Slurm
Локальные владельцы сохраняют ключи, данные, квоты и право аварийной остановки
C · DATA / EDGE
доменная БД · объектное хранилище · шлюз
Независимый контроль: безопасность · воспроизводимость · KPI · протокол GO/STOP
Соколов Сергей Леонидович
Три сценария проходят пять этапов за 90 дней
ПИЛОТНЫЙ ПЛАН
Биосферный ансамбль
GPU-анализ пространства
Вода · почвы · биоразнообразие
HTC + агрегирование
контейнер к данным
federated query + pushdown
1–15
16–30
31–55
56–75
76–90
паспорт
и baseline
домены
и политики
прототип
и первый run
нагрузка
и отказы
проверка
и решение
До интеграции каждый сценарий фиксирует существующий baseline: время · ручной труд · bytes moved · стоимость · качество
Соколов Сергей Леонидович
STOP
КРИТЕРИИ ПРИЁМКИ
GO требует одновременно пользы, контроля и воспроизводимости
- 3 домена · 3 сценария
- ≥95% успешных запусков после стабилизации
- −30% time-to-first-result для 2 из 3 сценариев
- 0 неразрешённых перемещений первичных данных
- 100% операций с policy log и 100% результатов с lineage
- расхождение resource accounting ≤ ±5%
обход локальной политики
неразрешённый egress
утрата происхождения результата
критическая уязвимость без компенсации
невозможность независимой проверки
Пороги — проектные критерии пилота, а не отраслевой стандарт
Соколов Сергей Леонидович
Следующий шаг — утвердить паспорт пилота за 15 дней
РЕШЕНИЕ
ГРИД создаёт не общий склад ресурсов,
а общий порядок доверенного вычисления
Назначить владельца пилота
Определить владельцев трёх доменов
Назначить независимого валидатора
Утвердить задачи, baseline и STOP-критерии
Предлагаемое решение: разрешить проектировочный пилот без промышленного допуска
Соколов Сергей Леонидович
Источники, указанные в презентации 22
- https://www.mcs.anl.gov/~itf/Articles/WhatIsTheGrid.pdf
- https://arxiv.org/abs/cs/0103025
- https://csrc.nist.gov/pubs/sp/800/207/final
- https://slurm.schedmd.com/overview.html
- https://htcondor.readthedocs.io/en/latest/overview/high-throughput-computing-requirements.html
- https://kubernetes.io/docs/concepts/workloads/controllers/job/
- https://ogf.org/ogf/doku.php/standards/standards.html
- https://docs.globus.org/guides/overviews/collections-and-endpoints/
- https://www.w3.org/TR/prov-o/
- https://openlineage.io/docs/spec/object-model/
- https://www.mpi-forum.org/docs/mpi-5.0/mpi50-report.pdf
- https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
- https://trino.io/docs/current/overview/concepts.html
- https://trino.io/docs/current/connector/postgresql.html#pushdown
- https://www.postgresql.org/docs/current/postgres-fdw.html#POSTGRES-FDW-REMOTE-QUERY-OPTIMIZATION
- https://arrow.apache.org/docs/format/Flight.html
- https://iceberg.apache.org/spec/
- https://opentelemetry.io/docs/concepts/signals/
- https://pravo.gov.ru/proxy/ips/?docbody=&nd=102108264
- https://pravo.gov.ru/proxy/ips/?docbody=&nd=102108261
- https://publication.pravo.gov.ru/document/view/0001201707260023
- https://slurm.schedmd.com/accounting.html
