Вычислительная сетка, которая сама себя чинит
SYSTEMGRID собирает разрозненные машины — от одиночной стойки до арендованных мощностей в шести странах — в одну управляемую вычислительную ткань. Планировщик видит реальную загрузку, а не заявленную, и переносит задачи до того, как узел начнёт отказывать.
Четыре слоя, которые не мешают друг другу
Мы намеренно развели ответственность: слой ниже ничего не знает о слое выше. Это скучно на схеме, но именно поэтому отказ одного слоя не роняет остальные.
Реестр мощностей
Каждая машина раз в три секунды сообщает о себе сама: ядра, память, температура, реальная пропускная способность диска. Реестр хранит не то, что обещал поставщик, а то, что машина показала на прошлой сотне задач.
Планировщик Torsion
Размещает задачу по фактической загрузке, а не по счётчику свободных слотов. Учитывает стоимость переноса: иногда дешевле подождать 200 мс на своём узле, чем гнать данные через полконтинента.
Транспорт задач
Сжатие на лету, дедупликация одинаковых наборов данных между задачами, докачка с места обрыва. Разрыв канала на 40 секунд не означает, что трёхчасовой расчёт начнётся заново.
Наблюдаемость
Один журнал на всю сетку с честными временными метками. Мы синхронизируем часы узлов принудительно: расследовать инцидент по логам с расхождением в полторы секунды невозможно.
Бюджеты и квоты
Команда получает не «доступ к кластеру», а измеримый бюджет в ядро-часах. Превышение не блокирует работу молча — приходит предупреждение на 80% и мягкое понижение приоритета на 100%.
Изоляция арендаторов
Отдельные пространства имён, отдельные ключи шифрования на арендатора, раздельные тома. Соседняя команда не видит ни ваших задач, ни имён ваших наборов данных.
Описание вместо администрирования
Сетка описывается одним файлом. Всё остальное — реестр, транспорт, квоты — выводится из него автоматически.
# Ткань «norther» — четыре региона, общий планировщик. # Веса пересчитываются каждые 30 секунд по реальным замерам. [fabric] name = "norther" scheduler = "torsion" clock_sync = "strict" # расхождение > 50 мс = узел выводится heartbeat_ms = 3000 [placement] strategy = "observed-load" migration_cost = "measured" # не угадываем, а меряем перенос drain_grace_s = 120 rebalance_every = "30s" [[region]] code = "eu-north" capacity = { cores = 1280, memory_gb = 5120 } tier = "primary" [[region]] code = "eu-west" capacity = { cores = 896, memory_gb = 3584 } tier = "primary" [[region]] code = "eu-central" capacity = { cores = 640, memory_gb = 2560 } tier = "burst" # включается только под пик [budget] alert_at_pct = 80 soft_limit_pct = 100 hard_stop = false # задачу не убиваем, понижаем приоритет
Состояние ткани в реальном времени
Снимок публичной демонстрационной сетки. Обновляется раз в минуту, значения усреднены по пятиминутному окну.
| Узел | Регион | Ядра | Загрузка | Очередь | Состояние |
|---|---|---|---|---|---|
| grid-nn-01 | eu-north | 128 | 74% | 12 | в работе |
| grid-nn-02 | eu-north | 128 | 81% | 19 | в работе |
| grid-nn-03 | eu-north | 96 | 93% | 41 | под нагрузкой |
| grid-nw-01 | eu-west | 112 | 62% | 7 | в работе |
| grid-nw-02 | eu-west | 112 | 58% | 4 | в работе |
| grid-nc-01 | eu-central | 80 | 0% | 0 | резерв |
| grid-nc-02 | eu-central | 80 | 0% | 0 | резерв |
Четыре шага до первой задачи
Обычный срок от первого звонка до продуктивной нагрузки — девять рабочих дней.
Инвентаризация
Мы снимаем реальные характеристики ваших машин своим замерщиком. Почти всегда выясняется, что часть парка работает медленнее паспорта — и лучше узнать это до планирования, а не после.
Описание ткани
Составляем fabric.toml вместе с вашей командой. Файл кладётся в ваш репозиторий и дальше живёт как обычный код: ревью, история, откат.
Теневой прогон
Неделю планировщик работает вхолостую: считает, куда бы он поставил задачи, но ничего не двигает. Вы сравниваете его решения со своими и решаете, доверять ли.
Передача управления
Переключение по регионам, а не разом. Откат к прежней схеме — одна команда, состояние задач при этом сохраняется.
«Мы три года держали расписание расчётов в общей таблице. Переход на описание ткани убрал не столько ручную работу, сколько споры о том, чья задача важнее: теперь это видно из бюджета, а не из голоса в чате.»
Платите за ядро-часы, а не за обещания
Все планы включают планировщик, реестр и наблюдаемость целиком. Разница — в объёме, поддержке и сроке хранения журналов.
- Один регион
- Журналы 7 дней
- Поддержка сообществом
- Теневой прогон включён
- До шести регионов
- Журналы 90 дней
- Ответ инженера за 2 часа
- Бюджеты и квоты команд
- Изоляция арендаторов
- Установка в вашем контуре
- Журналы без ограничения срока
- Выделенный инженер
- Свои ключи шифрования
- Аудит исходного кода
Что спрашивают чаще всего
Нужно ли переписывать наши задачи?
Нет. SYSTEMGRID запускает то, что уже есть: контейнер, скрипт, бинарь. Требование одно — задача должна корректно переживать собственную остановку и повторный запуск. Если она этого не умеет, мы честно скажем об этом на этапе инвентаризации, а не после первого переноса.
Что происходит при потере связи между регионами?
Каждый регион продолжает выполнять уже принятые задачи автономно. Новые размещения в отрезанный регион не идут. Когда связь возвращается, состояния сверяются, и расхождения разрешаются в пользу региона, который фактически выполнял работу.
Можно ли смешивать своё железо и арендованное?
Именно для этого платформа и делалась. Своим машинам обычно назначают ярус primary, арендованным — burst. Тогда аренда включается только под пик и не тратит бюджет в спокойные часы.
Как вы считаете ядро-часы?
По фактически занятым ядрам с шагом в одну минуту. Зарезервированные, но не использованные ядра не тарифицируются: платформа сама вернёт их в общий пул через две минуты простоя.
Есть ли установка внутри закрытого контура?
Да, тариф «Периметр». Платформа не требует исходящего доступа в интернет, обновления поставляются подписанным образом. Телеметрия наружу в этом режиме отключена полностью.