28 сентября 2026 года 3Logic Group сообщила о кластере Crusader Squire на двух географически разнесённых площадках. Между ними — интерконнект 100 Гбит/с. Цифры выглядят убедительно, но сами по себе не отвечают на главный вопрос: переживёт ли инфраструктура потерю одной площадки.

Из этого кейса можно взять архитектурный принцип. Готовую конфигурацию — нельзя. 3Logic Group не раскрыла число узлов, процессоры, объём памяти, устройство хранилищ, задержку канала, RPO и RTO. Если ты проектируешь похожую систему, эти параметры придётся определить под свою нагрузку.

Две площадки защищают от потери локации

По сообщению 3Logic Group, компания произвела и поставила кластер для крупной российской нефтедобывающей компании. Вычислительную часть построили на серверах Crusader Squire, а узлы разместили на двух географически разнесённых площадках.

Такая схема убирает зависимость от одного здания. Авария электропитания, пожар или повреждение инженерных систем на основной площадке не должны остановить критичные сервисы: вычислительную нагрузку можно перенести на резервную сторону.

Именно география отличает этот проект от нескольких серверов в одном помещении. Два узла под общей системой электропитания и охлаждения переживут отказ одного сервера, но не аварию всей серверной. Подробнее состав вычислительного контура разобран в материале про узлы, сеть и хранилища серверной фермы.

Однако сообщение 3Logic Group не раскрывает, какие компоненты дублируются кроме вычислительных узлов. Если между серверами осталось общее хранилище, один сетевой маршрут или единая система управления, схема сохраняет общую точку отказа.

Канал 100 Гбит/с не определяет время переключения

Интерконнект между площадками поддерживает 100 Гбит/с. Переведём эту скорость в привычные единицы:

100 Гбит/с ÷ 8 = 12,5 ГБ/с.

Принимаем десятичный терабайт, то есть 1000 ГБ. Передача такого объёма займёт не меньше:

1000 ГБ ÷ 12,5 ГБ/с = 80 секунд.

Это теоретический предел. Расчёт не учитывает накладные расходы протоколов, задержку, повторную передачу пакетов и трафик других систем. Он показывает только одно: сколько данных способен пропустить канал при идеальных условиях.

Для синхронной репликации важна ещё и задержка между площадками. Каждая операция записи ждёт подтверждения второй стороны, поэтому широкого канала недостаточно, если ответ идёт слишком долго. Для асинхронной репликации нужно определить допустимое отставание копии.

Отсюда появляются две величины:

RPO — сколько данных допустимо потерять при аварии;
RTO — сколько времени сервис может оставаться недоступным.

В публикации 3Logic Group этих значений нет. По скорости 100 Гбит/с нельзя вычислить ни одно из них.

Резерв считают по критичным сервисам

Резервной площадке необязательно принимать весь парк виртуальных машин. Она должна выдержать сервисы, без которых компания не может работать до восстановления основной стороны.

Возьмём расчётный пример, не связанный с конфигурацией нефтедобывающей компании. Допустим, критичные системы на пике потребляют 48 физических ядер и 384 ГБ памяти. Добавим 25% на гипервизор, служебные машины и рост нагрузки:

48 × 1,25 = 60 физических ядер;
384 × 1,25 = 480 ГБ памяти.

Практический ориентир резервной площадки — 64 физических ядра и 512 ГБ ECC RDIMM. Мы округлили расчёт вверх до конфигурации, которую можно собрать из одинаковых процессоров и модулей памяти.

Если обе площадки постоянно загружены, свободная ёмкость должна появиться к моменту аварии. Например, сторона с 64 ядрами не примет ещё 48, когда собственные машины уже занимают 40. До переключения придётся остановить второстепенные системы либо держать минимум 48 ядер свободными.

Тот же принцип работает для отдельного кластера 1С: сначала задают допустимый простой и критичную нагрузку, затем выбирают число узлов. Пример такого расчёта есть в сравнении резервной схемы и одиночного узла по времени простоя.

Спецификация под расчётную нагрузку

Для примера с пиком 48 ядер и 384 ГБ памяти резервную площадку можно заложить так:

Компонент	Конфигурация	Почему столько
Вычислительные узлы	2 сервера по 32 физических ядра	Вместе дают 64 ядра против расчётных 60. Потеря одного узла после потери площадки в этот запас не входит
Память	по 256 ГБ ECC RDIMM на узел	Суммарно 512 ГБ против расчётных 480 ГБ
Системные диски	по 2 SSD в RAID1 на узел	Отказ одного системного накопителя не останавливает узел
Рабочее хранилище	отдельный реплицируемый контур на каждой площадке	Объём и число дисков рассчитывают по рабочему набору данных, IOPS и выбранному RPO; этих исходных данных в примере нет
Сеть между площадками	100 Гбит/с с двумя независимыми маршрутами	Один маршрут оставит канал общей точкой отказа
Локальная сеть	минимум 2 порта на узел для рабочего трафика и отдельный порт управления	Разделяет передачу данных и доступ к управлению
Питание	2 блока питания на сервер, каждый подключён к своей линии	Один блок или одна линия не должны выключать узел
Корпус	2U с резервом слотов памяти и накопителей	Оставляет место для расширения без замены платформы

Это спецификация ёмкости, а не готовая ведомость оборудования. Конкретную модель процессора выбирают после проверки производительности одного ядра и требований лицензирования. Дисковую часть нельзя посчитать без объёма данных, доли записи и замера IOPS.

Если критичный пик вырастет с 48 до 72 ядер, тот же запас даст 72 × 1,25 = 90 ядер. Конфигурации на 64 ядра уже не хватит. Если допустима работа с пониженной производительностью, коэффициент можно уменьшить, но это ограничение нужно записать в проекте: какие системы остановятся и какая нагрузка останется.

Компромисс у схемы прямой. Резерв, который простаивает, проще освободить при аварии, но компания платит за неиспользуемую ёмкость. Активная работа обеих площадок повышает загрузку оборудования, зато усложняет переключение: перед переносом критичных машин приходится освобождать ресурсы.

Что запросить до утверждения проекта

Поставщик должен описать не только серверы, но и поведение системы при отказе. Запроси:

состав узлов и доступную вычислительную ёмкость каждой площадки;
устройство хранилищ и способ репликации данных;
измеренную задержку канала под рабочей нагрузкой;
RPO и RTO для каждого критичного сервиса;
сценарий потери площадки и отдельный сценарий разрыва связи;
загрузку резервной стороны до аварии и после переноса машин;
протокол испытания с отключением площадки.

Отдельно проверь совместимость компонентов. Партнёрский конфигуратор Crusader, по данным 3Logic Group, подбирает совместимые комплектующие, показывает складские остатки и рассчитывает стоимость. Он помогает собрать сервер и подготовить обоснование для тендера, но не рассчитывает требуемую ёмкость резервной площадки и не подтверждает время переключения.

Двухплощадочный кластер можно защищать перед директором, когда в проекте записаны четыре величины: пик критичной нагрузки, свободная ёмкость резерва после отказа, допустимая потеря данных и время восстановления. Нет хотя бы одной — перед тобой перечень оборудования, а не проверенная схема отказоустойчивости.