Блог

Главный принцип расчета – кластер должен выдержать отказ хоста

 

Кластер виртуализации нельзя рассчитывать только по сумме vCPU, оперативной памяти и терабайт виртуальных дисков.

 

Главная проверка начинается после расчета ресурсов: что произойдет, если один из хостов станет недоступен?

 

При N+1 оставшиеся узлы должны вместить необходимые виртуальные машины и обеспечить им требуемые процессорные ресурсы, оперативную память и производительность дисковой подсистемы.

 

Поэтому расчет строится последовательно:

 

нагрузка → процессор → оперативная память → хранилище → отказ одного хоста → проверка N+1

 

---

 

Какие данные нужны перед расчетом

 

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

 

Ресурс	Что собрать
Процессор	vCPU, фактическую загрузку и пики
Оперативная память	Выделенную и реально используемую память
Хранилище	Занятое место и темп роста
Дисковая нагрузка	IOPS, пропускную способность и задержки
Виртуальные машины	Количество, критичность и ограничения размещения
Развитие	Новые ВМ и увеличение существующих ресурсов
Отказоустойчивость	Сколько отказов должен выдерживать кластер

 

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

 

Если проект новый и статистики еще нет, используют требования приложений, планируемое количество ВМ и пользователей, рекомендации производителей ПО и расчетный профиль нагрузки.

 

---

 

 

---

 

Процессор: считать нагрузку, а не количество vCPU

 

Количество выделенных виртуальных процессоров vCPU само по себе не показывает, сколько физических процессорных ресурсов требуется кластеру.

 

Если виртуальным машинам суммарно назначено 160 vCPU, это не означает ни необходимость 160 физических ядер, ни возможность автоматически поделить это число на 2, 4 или 8.

 

Гипервизор распределяет физическое процессорное время между виртуальными машинами, поэтому количество выделенных vCPU может превышать количество физических ядер. Но универсального безопасного соотношения для любого кластера нет.

 

Для действующей инфраструктуры нужно анализировать:

 

• фактическую загрузку процессоров;
• пиковые периоды;
• конкуренцию ВМ за процессорное время;
• наиболее нагруженные ВМ;
• ограничения NUMA.

 

Практический принцип: отношение vCPU к физическим ядрам должно определяться профилем нагрузки, а не задаваться заранее ради уменьшения количества серверов.

 

Если новые серверы используют другое поколение процессоров, одного сравнения количества ядер тоже недостаточно. Нужно учитывать разницу в производительности по результатам тестов, измерений или испытаний на характерной нагрузке.

 

---

 

Почему важен NUMA

 

Для крупных виртуальных машин отдельно проверяют, как их процессорные ресурсы и память соотносятся с NUMA-топологией физического сервера.

 

Если ВМ выходит за пределы одного NUMA-узла, ей может потребоваться обращаться к памяти другого узла. Для чувствительных к задержкам приложений это способно снизить производительность.

 

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

 

---

 

 

---

 

Оперативная память: считать состояние после отказа

 

Базовая потребность определяется как:

 

память ВМ + рост нагрузки + ресурсы самой платформы виртуализации

 

Универсального правила вроде «оставлять 32 ГБ на каждом хосте» нет.

 

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

 

Для N+1 выполняется проверка:

 

доступная память оставшихся хостов ≥ расчетная потребность ВМ

 

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

 

Механизмы динамического распределения памяти могут повышать эффективность ее использования, но для критичной инфраструктуры их не стоит рассматривать как замену достаточному объему физической RAM.

 

---

 

Как рассчитать количество хостов N+1

 

Для одинаковых серверов отдельно определяют ограничение по процессору и памяти.

 

После приведения процессорной нагрузки к производительности целевых серверов:

 

NCPU = ceil(CPUрасч / CPU одного хоста)

 

По памяти:

 

NRAM = ceil(RAMрасч / RAM, доступная ВМ на одном хосте)

 

Для рабочей нагрузки принимается большее значение:

 

Nраб = max(NCPU, NRAM)

 

Для отказа одного вычислительного узла:

 

Nитого = Nраб + 1

 

Это расчет вычислительной емкости N+1, а не универсальная формула построения отказоустойчивого кластера. Требования к минимальному количеству узлов, кворуму и дополнительным компонентам зависят от конкретной платформы виртуализации.

 

Пример:

 

Параметр	Значение
Расчетная CPU-нагрузка	50 условных ядер целевого CPU
Расчетная RAM	820 ГБ
CPU одного хоста	32 ядра
RAM, доступная ВМ на одном хосте	480 ГБ

 

По процессору: ceil(50 / 32) = 2 хоста

 

По памяти: ceil(820 / 480) = 2 хоста

 

Для рабочей нагрузки достаточно двух серверов. Для N+1 требуется 3 хоста.

 

После отказа одного узла остаются 64 ядра и 960 ГБ памяти при расчетной потребности 50 ядер и 820 ГБ.

 

Но необходимо дополнительно проверить, смогут ли крупные ВМ разместиться на двух оставшихся серверах с учетом NUMA, зарезервированных ресурсов и правил размещения.

 

Комментарий инженеров СИНТО. N+1 нужно проверять моделированием потери хоста. Если после его исключения хотя бы одна критичная ВМ не может запуститься или получает недостаточно ресурсов, расчет N+1 не выполнен.

 

Для кластера из неодинаковых серверов простое правило «добавить один хост» применять нельзя. Нужно моделировать потерю наиболее значимого по ресурсам узла.

 

---

 

Хранилище: емкость и производительность считаются отдельно

 

Для дисковой подсистемы одного показателя в терабайтах недостаточно.

 

Нужно ответить на два вопроса:

 

Хватит ли полезной емкости?

Хватит ли производительности?

 

Расчет емкости

 

Учитываются:

 

• фактически занятые данные;
• прогноз роста;
• снимки виртуальных машин;
• служебные данные платформы;
• схема RAID, репликации или кодирования с избыточностью;
• технологический запас.

 

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

 

Например, 40 ТБ SSD не означают 40 ТБ пространства для виртуальных машин. Итоговая полезная емкость зависит от схемы защиты данных и архитектуры хранилища.

 

Тонкое выделение дискового пространства не увеличивает физическую емкость

 

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

 

Но реальная емкость хранилища от этого не увеличивается.

 

Поэтому необходимо контролировать:

 

фактически занято → скорость роста → реально свободно

 

Если физическое пространство закончится, виртуальные машины могут столкнуться с ошибками ввода-вывода.

 

---

 

Производительность хранилища

 

Для расчета недостаточно знать только IOPS.

 

Следует анализировать:

 

• IOPS;
• пропускную способность, МБ/с или ГБ/с;
• задержку;
• соотношение чтения и записи;
• пиковые периоды.

 

Желательно анализировать общую нагрузку на хранилище, а не просто складывать максимальные значения отдельных ВМ: пики у них могут происходить в разное время.

 

Особое внимание стоит уделить совместным нагрузкам, например когда одновременно работают базы данных, резервное копирование, антивирусное сканирование и фоновые задания.

 

---

 

Что происходит с хранилищем при отказе хоста

 

Здесь расчет зависит от архитектуры.

 

Общая внешняя СХД

 

При отказе вычислительного сервера физическая емкость внешней СХД обычно не уменьшается.

 

Но отдельно проверяется отказоустойчивость самой системы хранения:

 

• контроллеров;
• путей доступа;
• сети хранения;
• дисков;
• коммутаторов.

 

Гиперконвергентная инфраструктура

 

Если вычислительные ресурсы и хранилище находятся на одних и тех же узлах, отказ сервера одновременно уменьшает:

 

• вычислительную мощность;
• доступную емкость хранения;
• суммарную производительность дисковой подсистемы.

 

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

 

Поэтому для гиперконвергентной инфраструктуры N+1 нельзя рассчитывать только по процессору и памяти. Нужно дополнительно проверить емкость и производительность хранилища после отказа узла и во время восстановления данных.

 

---

 

Что еще может нарушить N+1

 

Достаточный запас CPU и RAM еще не гарантирует, что все ВМ смогут автоматически запуститься после отказа.

 

Нужно проверить:

 

• reservations CPU и RAM;
• affinity и anti-affinity;
• NUMA;
• локальные диски;
• PCI passthrough;
• SR-IOV;
• vGPU;
• доступность сетей и storage;
• лицензионные ограничения;
• правила самой HA-платформы.

 

Например, в актуальной документации РЕД ВИРТ для миграции ВМ прямо указано требование достаточных CPU и RAM на целевом хосте. То есть наличие хоста в кластере само по себе не означает возможность принять конкретную виртуальную машину.

 

---

 

Что еще может нарушить N+1

 

Достаточного количества процессорных ресурсов и памяти недостаточно, если отдельную ВМ нельзя разместить на оставшихся серверах.

 

Проверяют:

 

• зарезервированные процессорные ресурсы и память;
• правила совместного и раздельного размещения ВМ;
• NUMA;
• локальные диски;
• прямой проброс устройств;
• SR-IOV;
• vGPU;
• доступность сетей и хранилищ;
• лицензионные ограничения;
• правила отказоустойчивости конкретной платформы.

 

То есть:

 

«суммарных ресурсов достаточно» и «все необходимые ВМ смогут запуститься» – не всегда одно и то же.

 

---

 

Что проверить перед закупкой серверов

 

Проверка	Что должно быть известно
Процессор	Фактическая и пиковая потребность
Оперативная память	Потребность ВМ и доступная память после отказа
Крупные ВМ	Возможность размещения на оставшихся хостах
Емкость хранилища	Полезная ёмкость и прогноз роста
Производительность хранилища	IOPS, пропускная способность и задержки
N+1	Ресурсы после отказа хоста
Отказоустойчивость	Кворум и требования платформы
Сеть	Пропускная способность и резервирование
Рост	Ресурсы для будущих ВМ

 

Такой расчет стоит выполнять до выбора конкретной модели сервера и платформы, особенно при консолидации инфраструктуры, обновлении оборудования или проектировании виртуализации серверов.

Часто задаваемые вопросы

Какое отношение vCPU к физическим ядрам использовать?

Универсального значения нет. Для существующей инфраструктуры соотношение определяют по фактической нагрузке. Для нового проекта – по профилю приложений и результатам испытаний.

Значения 2:1, 4:1 или 8:1 нельзя использовать как универсальное правило.

Сколько vCPU можно выделить на одно физическое ядро?

Это зависит от нагрузки и гипервизора. Если виртуальные машины большую часть времени используют небольшую долю выделенных процессорных ресурсов, отношение vCPU к физическим ядрам может быть выше. Для постоянно нагруженных баз данных и вычислительных систем допустимое значение обычно будет ниже.

Как рассчитать N+1?

Для одинаковых хостов сначала определяют количество серверов, необходимое для рабочей нагрузки по процессору и памяти. Затем добавляют ресурс одного узла и проверяют состояние после его отказа.

Для неодинаковых серверов моделируют потерю конкретного хоста, в том числе наиболее мощного.

Нужно ли держать один сервер полностью свободным?

Нет. Нагрузка может быть распределена между всеми хостами. Главное – чтобы после отказа одного узла ресурсов оставшихся серверов хватало для необходимых ВМ.

Можно ли выделять виртуальным машинам больше памяти, чем физически установлено?

Некоторые гипервизоры поддерживают динамическое распределение и переподписку памяти.

Но для критичных систем такую память нельзя автоматически считать равноценной установленной физической RAM. Нужно учитывать поведение платформы при ее дефиците.

Какой запас ресурсов оставлять?

Универсального процента нет. Запас определяется ростом количества ВМ, увеличением существующих нагрузок, требованиями N+1/N+2 и возможностями выбранных серверов.

Как рассчитать хранилище для кластера виртуализации?

Нужно проверить две независимые характеристики:

• полезную емкость – сколько данных реально можно разместить;
• производительность – какие IOPS, пропускную способность и задержки обеспечивает хранилище.

Для гиперконвергентной инфраструктуры обе характеристики дополнительно проверяют после отказа узла и при восстановлении данных.

Достаточно ли трех хостов для N+1?

Не всегда. Три одинаковых сервера могут обеспечить N+1 по вычислительным ресурсам, если двух оставшихся достаточно для всей расчетной нагрузки. Но требования к кворуму, хранилищу, сети и отказоустойчивости зависят от конкретной платформы.

Вывод

Для расчета кластера виртуализации недостаточно сложить vCPU, оперативную память и объем виртуальных дисков.

Нужно последовательно проверить:

процессор → оперативная память → полезная емкость хранилища → производительность хранилища → отказ хоста

Главный критерий N+1: после потери одного расчетного узла оставшаяся инфраструктура должна обеспечивать необходимую нагрузку с требуемой производительностью.

Только после такой проверки имеет смысл выбирать количество и конфигурацию физических серверов.

1. Определить расчетную нагрузку

В расчет включают оборудование, которое должно сохранять питание при нарушении внешнего электроснабжения:

• серверы и СХД;
• сетевое и телекоммуникационное оборудование;
• автоматику;
• критичные системы мониторинга;
• другие защищаемые потребители, предусмотренные проектом.

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

Номиналы резервированных блоков питания серверов нельзя автоматически суммировать. Два PSU по 1600 Вт не означают, что сервер постоянно потребляет 3200 Вт – расчет ведут по фактическому или проектному потреблению оборудования.

СП 541.1325800.2024 предусматривает подключение к системе бесперебойного питания критичных нагрузок ИТ-оборудования, автоматики и слаботочных систем. Дополнительные нагрузки определяются заданием на проектирование.

2. Перевести кВт в кВА

Полная мощность рассчитывается через PF:

S = P / PF

Если расчетная нагрузка составляет 240 кВт, а PF = 0,95:

S = 240 / 0,95 = 252,6 кВА

Следовательно, ИБП должен обеспечивать не менее 240 кВт / 252,6 кВА.

Значение PF не следует брать автоматически равным 1. Для действующего ЦОД его лучше подтверждать измерениями, для проектируемого – определять по характеристикам нагрузки и исходным данным проекта.

СП 541.1325800.2024 не устанавливает единый PF для всех ЦОД – коэффициент мощности задается в исходных данных на проектирование.

Для нелинейной ИТ-нагрузки также не следует автоматически подменять PF значением cos φ: общий коэффициент мощности учитывает не только фазовый сдвиг, но и искажения формы тока.

3. Учесть запас на развитие

Если текущая нагрузка составляет 200 кВт, а проект предусматривает рост на 20%, расчетная перспективная нагрузка будет:

200 × 1,20 = 240 кВт

Но 20% здесь – только пример.

Универсального нормативного требования всегда добавлять к мощности ИБП 20%, 25% или 30% нет.

Запас лучше определять через реальный сценарий развития:

• сколько стоек планируется добавить;
• как изменится их мощность;
• какой будет нагрузка через несколько лет;
• можно ли расширять ИБП силовыми модулями.

Для модульного ИБП часто рациональнее предусмотреть возможность расширения, чем сразу устанавливать всю перспективную мощность.

4. Рассчитать резервирование

Запас на развитие и резервирование рассчитываются отдельно.

Для параллельной конфигурации ГОСТ IEC 62040-3-2024 использует обозначение n + r, где n – количество блоков, необходимых для питания нагрузки, а r – количество избыточных блоков.

Для N+1 сначала определяют N, затем добавляют один резервный модуль.

Пример N+1

По кВт требуется: 240 / 50 = 4,8 → 5 модулей.

По кВА: 252,6 / 50 = 5,05 → 6 модулей.

Принимаем большее значение: N = 6.

Для N+1 требуется 7 модулей. После отказа одного останется 300 кВт / 300 кВА, что выше расчетных 240 кВт / 252,6 кВА.

Если считать только по кВт, получилось бы 5+1 модулей. После отказа одного осталось бы 250 кВт / 250 кВА – по кВт достаточно, а по кВА уже нет.

Комментарий инженеров СИНТО. N+1 нужно проверять именно после исключения резервируемого элемента. Установленная мощность системы в нормальном режиме сама по себе не подтверждает, что резервирование сохранится при отказе.

Что меняется при 2N

При 2N каждый из двух независимых трактов должен самостоятельно обеспечивать всю расчетную нагрузку.

Для примера выше каждый тракт должен выдерживать минимум:

240 кВт / 252,6 кВА

При этом два ИБП еще не означают полноценные 2N. Независимость проверяют по всей цепочке:

источник → распределение → ИБП → байпас → PDU → ИТ-оборудование

Если отказ общего элемента нарушает оба тракта, он остается единой точкой отказа.

Нужно ли оставлять 20% мощности ИБП свободными

Фиксированного нормативного требования загружать ИБП максимум на 70%, 80% или другое универсальное значение нет.

Свободная мощность должна появляться как результат расчета:

• развития нагрузки;
• резервирования;
• шага мощности модулей;
• требований аварийного режима;
• характеристик выбранного оборудования.

Поэтому правильнее контролировать не условный процент загрузки, а три значения:

текущая нагрузка → перспективная нагрузка → нагрузка после отказа резервируемого элемента

Что проверить после расчета мощности

Расчетный номинал, например 300 кВт / 300 кВА, еще не означает, что подойдет любой ИБП с такими характеристиками.

Отдельно нужно учитывать, что номинал ДГУ нельзя выбирать по простому правилу «ИБП 500 кВА = ДГУ 500 кВА». Для генератора важны входные характеристики ИБП, заряд АКБ после разряда, переходные процессы и другие нагрузки на генераторной шине.

Комментарий инженеров СИНТО. При согласовании ИБП и ДГУ важно проверить не только установившийся режим, но и принятие нагрузки генератором, переключения между источниками и восстановление заряда АКБ.

Если требуется рассчитать весь энергетический тракт – ИБП, АКБ, ДГУ, АВР, PDU, шинопроводы и схему резервирования – это входит в проектирование систем бесперебойного электроснабжения для ЦОД.

АКБ рассчитывается отдельно

Мощность ИБП определяет, какую нагрузку система способна поддерживать. Емкость АКБ – как долго она сможет это делать без внешнего питания.

СП 541.1325800.2024 предусматривает для ИБП с АКБ не менее 5 минут работы при 100% нагрузке в аварийном режиме.

Фактическая автономия может быть больше – в зависимости от времени запуска ДГУ, алгоритма переключений и требований проекта.

Поэтому расчет мощности ИБП и расчет батарейной системы нельзя объединять в одну формулу.

Нормативная база

При расчете ИБП для ЦОД используются, в частности:

СП 541.1325800.2024 «Здания и сооружения центров обработки данных. Правила проектирования» – расчет нагрузок, резервирование, АКБ и внешний байпас.

ГОСТ IEC 62040-3-2024 – активная и полная мощность ИБП, PF, параллельные конфигурации, входные и выходные характеристики, методы испытаний.

ГОСТ IEC 62040-1-2024 – требования безопасности к системам бесперебойного энергоснабжения.

Часто задаваемые вопросы

Считать мощность ИБП в кВт или кВА?

В обеих величинах. ИБП должен одновременно обеспечивать расчетную активную мощность в кВт и полную мощность в кВА.

Как перевести кВт в кВА для ИБП?

По формуле:

S = P / PF

Например, 240 кВт при PF = 0,95 соответствуют 252,6 кВА.

Какой PF использовать для расчета ИБП?

PF определяется по характеристикам нагрузки, исходным данным проекта или измерениям на действующем объекте. Универсального значения PF для всех ЦОД нет.

Какой запас мощности закладывать в ИБП?

Фиксированного нормативного процента нет. Запас должен соответствовать прогнозируемому росту нагрузки и архитектуре конкретного ЦОД.

20% запаса – это N+1?

Нет. Запас учитывает рост нагрузки. N+1 означает, что после отказа одного резервируемого блока оставшаяся система способна обеспечить всю расчетную нагрузку.

Как проверить N+1?

Нужно исключить один резервируемый модуль и проверить, что оставшиеся блоки обеспечивают расчетную нагрузку одновременно по кВт и кВА.

Нужно ли учитывать КПД при выборе мощности ИБП?

КПД не прибавляется к требуемой выходной мощности. Он учитывается при анализе входного потребления и тепловых потерь.

Можно ли подобрать ДГУ по номиналу ИБП?

Нет. Нужно учитывать входные характеристики ИБП, заряд АКБ, переходные процессы и другие нагрузки генераторной системы.

Какое минимальное время работы от АКБ предусматривает СП 541?

Для ИБП с АКБ – не менее 5 минут при 100% нагрузке в аварийном режиме.

Главное в расчете мощности ИБП

Расчет мощности ИБП для ЦОД сводится к последовательности:

нагрузка в кВт → PF → нагрузка в кВА → запас на развитие → N → резервирование

ИБП проверяется одновременно по кВт и кВА. Запас на развитие не заменяет N+1, а N+1 считается выполненным только тогда, когда после отказа одного резервируемого элемента оставшейся мощности достаточно для всей расчетной нагрузки.

Для таких задач применяются системы контроля и управления доступом (СКУД).

Видеонаблюдение

При проверке системы видеонаблюдения важно оценивать не количество камер, а возможность получить нужную информацию при инциденте.

Стоит проверить:

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

Подробнее – проектирование и монтаж систем видеонаблюдения.

Информационная безопасность

Работа промышленных и инфраструктурных объектов все чаще зависит от серверов, сетей связи, информационных систем и автоматизированного управления.

С технической точки зрения стоит проверить:

• сетевую инфраструктуру;
• удаленный доступ;
• учетные записи и привилегии;
• защищенность серверов и рабочих станций;
• разделение корпоративных и технологических сегментов;
• средства обнаружения инцидентов;
• защищенность промышленных сетей и АСУ;
• актуальность резервных копий.

Эти задачи относятся к отдельному направлению сетевой безопасности предприятия.

Готовность к восстановлению после отказа или инцидента

Указ отдельно называет невосстановление или несвоевременное восстановление функционирования объекта среди обстоятельств, при которых может быть введено временное управление.

При технической проверке стоит заранее определить:

• какие системы критичны для работы объекта;
• что произойдет при отказе каждой из них;
• есть ли резервирование каналов связи;
• работает ли резервное электропитание;
• проводятся ли испытания ИБП и ДГУ;
• выполняется ли резервное копирование;
• проводилось ли тестовое восстановление данных;
• сохранены ли конфигурации критичного оборудования и ПО;
• можно ли оперативно заменить отказавшее оборудование;
• доступны ли необходимые запасные части;
• актуальны ли исполнительная документация и схемы;
• проверялись ли сценарии восстановления на практике.

Такая проверка позволяет выявить единичные точки отказа и определить, какие компоненты необходимо резервировать для сохранения работы критичных сервисов.

Если требуется модернизация вычислительного контура, СИНТО проектирует отказоустойчивую ИТ-инфраструктуру для КИИ и критичных сервисов: серверный кластер, отказоустойчивое хранение, резервирование сети, проверку совместимости компонентов и испытания согласованных сценариев отказа.

Объект критической инфраструктуры и объект КИИ – не одно и то же

Эти понятия важно разделять.

187-ФЗ определяет объектами КИИ информационные системы, информационно-телекоммуникационные сети и автоматизированные системы управления субъектов критической информационной инфраструктуры.

Одна организация может иметь отношение к обоим режимам, но требования одного документа нельзя автоматически переносить на другой.

Чего Указ №604 не требует

Из текста Указа не следует, что после его вступления в силу каждая организация обязана:

• установить определенное количество камер;
• заменить действующую СКУД;
• внедрить конкретную систему информационной безопасности;
• полностью перестроить существующую систему безопасности;
• применить одинаковую схему резервирования ИТ- и инженерных систем.

Указ устанавливает обстоятельства, при которых может применяться механизм временного управления. Конкретные меры безопасности определяются требованиями, действующими для конкретного объекта.

С чего начать проверку

До закупки нового оборудования стоит оценить фактическое состояние объекта:

1. Определить применимость Указа к объекту.
2. Собрать действующие требования безопасности.
3. Сопоставить их с фактически реализованными мерами.
4. Проверить работоспособность установленных систем.
5. Выявить зоны и процессы, которые остаются без необходимого контроля.
6. Проверить сценарии реагирования.
7. Проверить возможность восстановления критичных систем.
8. Зафиксировать недостатки и определить приоритетность работ.

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

Опыт СИНТО на промышленных и инфраструктурных объектах

СИНТО выполняет проекты на действующих промышленных и инфраструктурных объектах, где необходимо учитывать режим предприятия, требования к допускам и ограничения на остановку технологических процессов.

Среди реализованных проектов:

• модернизация ИТ-инфраструктуры для «Зарубежнефти» и «Славнефть-ЯНОС»;
• модернизация электропитания двух ЦОД для ПАО «ОДК-Сатурн»;
• работы по СКС, СКУД, охранному телевидению, пожарной сигнализации и оповещению на производственных объектах.

Частые вопросы

Когда вступил в силу Указ №604?

Указ вступил в силу со дня его официального опубликования – в августе 2026 года.

Могут ли предприятие сразу передать во временное управление?

Нет. Решение принимает Правительство РФ на основании поручения Президента РФ при наличии предусмотренных Указом обстоятельств. Автоматического применения этой меры при любом нарушении документ не устанавливает.

Обязывает ли Указ установить СКУД и видеонаблюдение?

Нет. Конкретного перечня технического оборудования в Указе №604 нет.

Указ №604 – это закон о КИИ?

Нет. Безопасность критической информационной инфраструктуры регулируется отдельным Федеральным законом №187-ФЗ.

Что проверить в первую очередь?

Сначала определить требования, применимые к объекту, затем сопоставить их с фактическим состоянием систем и проверить работоспособность критичных сценариев, включая восстановление после отказа или инцидента.

Источники

• Указ Президента РФ от 24.08.2026 №604 «О мерах по обеспечению безопасности объектов критической инфраструктуры Российской Федерации».
• Федеральный закон от 26.07.2017 №187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».

Материал носит информационный характер и не является юридической консультацией. Применимость Указа №604 и конкретных требований к отдельному объекту необходимо определять с учетом действующих нормативных правовых актов и решений уполномоченных органов.

Зонирование задается не только соображениями безопасности. СП 541.1325800.2024 устанавливает состав обязательных технологических зон ЦОД и требования к их взаимному расположению – это база, поверх которой строятся рубежи доступа. Поэтому схему разграничения доступа закладывают на этапе проектирования и строительства ЦОД: менять расположение зон на действующем объекте дороже, чем предусмотреть их сразу.

Защита периметра дата-центра

Первый рубеж отдельно стоящего дата-центра – граница контролируемой территории. Ее задача не остановить нарушителя, а обнаружить попытку проникновения достаточно рано, чтобы событие успели проверить до подхода к зданию.

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

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

Как связать обнаружение и верификацию

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

тревожное событие → определение зоны → вывод изображения нужных камер оператору → проверка → действие по регламенту.

В такой архитектуре камера служит не только источником записи, но и инструментом верификации события.

Контроль входа и въезда на территорию ЦОД

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

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

Ключевой принцип: доступ на территорию не равен доступу ко всем помещениям внутри.

Разграничение доступа по зонам

Полный доступ ко всем помещениям дата-центра редко нужен даже тем, кто находится внутри легально. В ЦОД работают специалисты по электроснабжению, инженеры систем охлаждения, сетевые специалисты, ИТ-персонал, эксплуатационные и монтажные службы, представители владельцев оборудования.

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

Права строятся по формуле: кто → куда → когда → для какой задачи. Реализуются через СКУД – систему контроля и управления доступом, объединяющую считыватели, контроллеры и правила предоставления прав.

Доступ в машинный зал

Машинный зал требует более строгих правил, чем вход в здание: отдельные права, несколько факторов идентификации, контроль прохода, временные разрешения, сопровождение посетителей, регистрация входа и выхода, видеоконтроль и журналирование.

Особого внимания требуют подрядчики: доступ выдается на конкретный период и только в нужную зону. Это уменьшает количество пользователей с постоянными избыточными правами – один из источников накопленного риска в эксплуатируемых ЦОД.

Доступ к серверной стойке

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

Это позволяет при расследовании ответить не только на вопрос «кто был в машинном зале», но и «кто получил физический доступ к конкретному оборудованию и когда».

Контроль действий подрядчиков в дата-центре

Риск для ЦОД связан не только с внешним проникновением, но и с действиями человека, который законно находится на объекте.

Типичные сценарии:

• сотруднику выданы избыточные права;
• подрядчик попал не в ту зону;
• временный пропуск остался активным после окончания работ;
• невозможно установить, кто находился возле оборудования в момент инцидента.

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

Физическая безопасность в этом смысле – не набор устройств, а система управления доступом к критической инфраструктуре.

Единая картина событий: СКУД, видеоконтроль и сигнализация

Когда СКУД, камеры, охранная сигнализация и периметральные датчики работают независимо друг от друга, при инциденте оператор вручную сопоставляет время и ищет запись.

Связанная архитектура формирует единое событие:

тревожная зона → тип события → камера → время → действия оператора;
дверь машинного зала → идентификатор → время прохода → видеозапись → журнал.

Отдельное требование – синхронизация времени между системами. Если часы камер, СКУД и сигнализации расходятся, восстановить точную последовательность становится сложно. Часть событий при необходимости передается в DCIM- или SCADA-систему диспетчеризации, которая сводит инженерные и охранные параметры объекта в один интерфейс.

Глубину архива и состав зон видеоконтроля определяют в задании на проектирование: от них напрямую зависит объем СХД. Расчет камер, архива и аналитики выполняется в рамках отдельной задачи – проектирования и монтажа систем видеонаблюдения.

От чего зависит архитектура защиты

Количество рубежей в дата-центре определяется не только размером объекта. Учитываются расположение и границы территории, число входов и транспортных въездов, наличие внешней инженерной инфраструктуры, количество критических помещений и машинных залов, численность персонала, работа подрядчиков, режим эксплуатации, число независимых групп пользователей, необходимость контроля отдельных стоек и модель физических угроз.

Чем больше независимых групп пользователей и критичных зон, тем важнее точное разграничение прав и фиксация переходов между уровнями.

Что определить до выбора оборудования

Ошибка последовательности при проектировании физической безопасности – самая дорогая: сначала архитектура и сценарии, потом камеры и считыватели.

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

Пользователи: постоянный персонал, посетители, подрядчики, сервисные инженеры, охрана, аварийные службы.

Зоны доступа: общедоступные помещения, административные зоны, технические и телекоммуникационные помещения, инженерная инфраструктура, машинные залы, участки с ограниченным доступом, оборудование с индивидуальным контролем.

Сценарии: обычный проход, временный доступ, ночные работы, доставка оборудования, аварийный приезд подрядчика, потеря идентификатора, попытка проникновения, принудительное открытие двери, эвакуация.

Семь типичных ошибок

1. Защищать только внешний периметр. Надежный забор не решает проблему избыточных прав внутри здания.
2. Давать персоналу доступ ко всем помещениям. Права должны соответствовать реальным обязанностям.
3. Не ограничивать временный доступ. Разрешение подрядчика не должно оставаться активным после окончания работ.
4. Использовать видеоконтроль отдельно от других событий. Связь тревоги или прохода с камерой кратно ускоряет проверку.
5. Не учитывать защиту конкретного оборудования. Для части систем уровня машинного зала недостаточно.
6. Не синхронизировать системное время. Расхождение часов осложняет расследование.
7. Выбирать оборудование до сценариев. Сначала – кого, от чего и на каком рубеже контролируем.

Нормативная база

Требования к физической безопасности российского ЦОД рассматриваются вместе с требованиями к объекту и его инженерной инфраструктуре.

Дополнительно учитываются требования к инженерно-технической укрепленности объекта и техническим средствам охраны.

Отдельный случай – дата-центры, где размещаются значимые объекты критической информационной инфраструктуры (ЗОКИИ). Для них предусмотрен контроль физического доступа к программно-аппаратным средствам, а конкретный набор мер зависит от категории значимости и модели угроз. Практический вывод: архитектуру физической защиты в таком ЦОД согласуют с проектом системы безопасности значимого объекта, а не проектируют изолированно.

Состав систем нельзя выбирать по названию стандарта или предполагаемому классу объекта: решения зависят от архитектуры, назначения ЦОД, требований заказчика и применимых норм.

Экспресс-проверка: где слабые места

Шесть вопросов для первичной оценки физической безопасности объекта. Каждое «да» на вопросы 1 и 6 и каждое «нет» на остальные – зона для доработки.

1. Можно ли после одного контрольного пункта попасть сразу в критическую зону?
2. Разделены ли права инженеров, ИТ-специалистов и подрядчиков?
3. Можно ли установить, кто находился возле конкретного оборудования в момент события?
4. Ограничиваются ли временные права по сроку автоматически?
5. Получает ли оператор нужную камеру при тревоге без ручного поиска?
6. Есть ли участки вне контроля – внешние инженерные зоны, служебные входы, технические ворота?

Главное

Физическая безопасность дата-центра строится не вокруг турникета, камеры или считывателя, а вокруг логики:

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

Наиболее понятная модель – последовательные рубежи: 

периметр → КПП → здание → критические помещения → машинный зал → серверная стойка. Количество уровней и состав технических средств определяются конкретным объектом.

Часто задаваемые вопросы

Сколько уровней физической безопасности должно быть в ЦОД?

Единого числа рубежей для всех дата-центров нет. Количество зависит от архитектуры объекта, критичности оборудования, состава пользователей и модели угроз. Обычно отдельно рассматриваются периметр, вход в здание, внутренние зоны, машинный зал и при необходимости уровень серверной стойки.

Чем физическая безопасность ЦОД отличается от офисной?

Плотностью рубежей и глубиной журналирования. В офисе достаточно контроля входа в здание, в дата-центре доступ разграничивают внутри объекта вплоть до отдельной серверной стойки и фиксируют каждый переход между зонами. Причина – необходимость восстановить последовательность действий при расследовании инцидента.

Достаточно ли камер для защиты периметра дата-центра?

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

Обязательно ли использовать биометрию для входа в машинный зал?

Нет. Способ идентификации определяется требованиями конкретного объекта: применяются карты, ПИН-коды, биометрия или сочетание нескольких факторов. Выбор фиксируется в задании на проектирование вместе с правилами выдачи и отзыва прав.

Нужно ли контролировать доступ к каждой серверной стойке?

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

Зачем связывать СКУД и видеоконтроль?

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

Когда пересматривать схему физической безопасности?

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

Об авторах

Статью подготовили инженеры СИНТО. Компания проектирует и строит центры обработки данных, включая инженерную инфраструктуру, системы контроля доступа, видеонаблюдения и охранной сигнализации, и передает объекты с исполнительной документацией и регламентами эксплуатации.

Почему модернизацию ЦОД нужно начинать с приоритетов

 

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

 

Для российского рынка такая задача актуальна уже сегодня. В исследовании CHINT и Аналитического центра ИКС среди представителей более 50 российских компаний 49% участников назвали проблемой высокую стоимость и сложность обслуживания систем распределения электроэнергии, 47% – трудности модернизации, 41% – дефицит места для нового оборудования. При этом 61% опрошенных планируют менять архитектуру распределения электропитания и столько же – повышать резервирование. Эти показатели относятся к участникам исследования и не должны автоматически переноситься на весь российский рынок.

 

Финансовые ограничения также влияют на развитие отрасли: в исследовании российского рынка коммерческих ЦОД 2025 года значительная часть планировавшихся запусков была перенесена на 2026–2027 годы, а среди основных причин участники рынка называли недостаток финансирования на фоне высокой капиталоемкости проектов.

 

Поэтому модернизацию действующего ЦОД стоит начинать не с вопроса «что здесь самое старое?», а с другого:

 

"Какое вложение сильнее всего снизит риск простоя или снимет критическое ограничение площадки?"

 

---

 

Что модернизировать в первую очередь

 

Для распределения ограниченного бюджета задачи удобно разделить на четыре группы.

 

Приоритет	Что оцениваем	Примеры
1. Риск остановки	Что способно привести к потере критичной нагрузки	Единая точка отказа, потеря резервирования, критический дефект
2. Риск длительного восстановления	Что невозможно быстро вернуть в работу	Отсутствие ЗИП, прекращение поддержки, длительный срок поставки компонента
3. Ограничения развития	Что мешает подключить уже запланированную нагрузку	Недостаток мощности, распределения, охлаждения или места
4. Эксплуатационная эффективность	Что увеличивает стоимость эксплуатации, но не создает непосредственной угрозы простоя	Неоптимальные режимы, устаревшие средства управления, повышенные эксплуатационные затраты

 

Это рабочая классификация для расстановки приоритетов, а не нормативная шкала.

 

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

 

 

---

 

Возраст оборудования не определяет приоритет

 

Предположим, на площадке есть:

 

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

 

Если строить программу только по возрасту, первым под замену попадет кондиционер. Но для надежности объекта более важными могут оказаться ИБП и контроллер.

 

Поэтому каждый критичный узел стоит оценивать минимум по пяти критериям:

 

1. Последствия отказа – что именно перестанет работать.
2. Фактическое состояние – есть ли повторяющиеся ошибки, отклонения и признаки деградации.
3. Резервирование – способен ли резерв принять сегодняшнюю нагрузку.
4. Ремонтопригодность – насколько быстро можно восстановить систему.
5. Влияние на развитие – блокирует ли узел утвержденное увеличение нагрузки.

 

Таким образом, старое оборудование и критичный технический риск – не одно и то же.

 

Проверять нужно реальное резервирование

 

Проектная схема могла предусматривать резерв, который со временем фактически исчез.

 

Например, четыре агрегата охлаждения изначально работали так, что для расчетной нагрузки требовались три, а четвертый оставался резервным. После увеличения ИТ-нагрузки для нормальной работы стали необходимы почти все четыре агрегата.

 

Физически система не изменилась, но прежнего запаса уже нет.

 

Такая ситуация возможна не только с охлаждением, но и с ИБП, генераторами, трансформаторами, насосами и распределением питания.

 

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

 

Именно потеря функционального резерва может оказаться более важной причиной модернизации, чем возраст оборудования.

 

Ремонтопригодность – отдельный фактор риска

 

Исправное сегодня оборудование может оказаться проблемным после первого серьезного отказа.

 

Перед решением о его сохранении необходимо выяснить:

 

• есть ли доступные запасные части;
• можно ли отремонтировать оборудование на объекте или в приемлемые сроки;
• существует ли совместимая замена;
• есть ли собственный или доступный ЗИП;
• зависит ли восстановление от уникального ПО, контроллера или специализированного сервиса.

 

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

 

Но отсюда не следует, что все зарубежное или снятое с официальной поддержки оборудование нужно немедленно менять.

 

Приоритет замены становится высоким, когда одновременно совпадают несколько условий:

 

критичный узел + нет полноценного резерва + сложно получить ЗИП + восстановление нельзя гарантировать в приемлемый срок.

 

---

 

Как сократить бюджет без увеличения риска

 

Главный резерв экономии при модернизации – не покупка максимально дешевого оборудования, а сохранение той части инфраструктуры, которая еще соответствует задаче.

 

Рациональное решение	Рискованная экономия
Сохранить исправную систему после проверки состояния и нагрузки	Оставить её только потому, что она пока работает
Модернизировать ограничивающий участок	Менять всё оборудование подсистемы без необходимости
Разбить проект на законченные очереди	Оставить между этапами ненадёжную временную конфигурацию
Сформировать ЗИП для действительно критичных компонентов	Рассчитывать получить редкую деталь только после аварии
Предусмотреть возможность дальнейшего расширения	Сразу закупать максимальную гипотетическую мощность
Использовать существующие трассы и элементы, если они подходят	Сохранять их без проверки состояния и расчётных параметров

 

---

 

Не обязательно модернизировать весь машинный зал

 

Если новая нагрузка требуется только в одной части ЦОД, сначала нужно определить, можно ли усилить конкретную зону.

 

Например, ограничением могут быть:

 

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

 

В этом случае точечная модернизация может оказаться экономичнее полной перестройки объекта.

 

Но локальное решение оправдано только тогда, когда соседние инженерные системы способны принять изменение. ЦОД – взаимосвязанный комплекс: дополнительная электрическая мощность неизбежно влияет на распределение, тепловыделение, охлаждение и режимы резервирования.

 

---

 

ЗИП вместо преждевременной замены

 

Иногда главным риском является не состояние всей установки, а отсутствие одного критичного компонента.

 

Если оборудование исправно, соответствует нагрузке и имеет приемлемый остаточный ресурс, формирование ЗИП может оказаться рациональнее полной замены.

 

При этом имеет смысл учитывать:

 

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

 

ЗИП должен закрывать конкретный риск восстановления, а не превращаться в склад оборудования «на всякий случай».

 

---

 

Не путать экономию с отсрочкой расходов

 

Сокращение текущего CAPEX само по себе еще не означает снижение стоимости модернизации.

 

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

 

Это не экономия, а перенос части расходов на следующий этап.

 

Для значимых решений поэтому имеет смысл сравнивать не только цену закупки, но и:

 

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

 

ГОСТ Р 70627-2023 действует с 1 марта 2023 года и устанавливает требования к составу и содержанию технической концепции инженерной инфраструктуры ЦОД. Сам подход технической концепции предполагает обоснование выбранного решения, а не только формирование перечня оборудования.

 

---

 

 

---

 

На чем экономить нельзя

✔ Резервирование

Если отказ элемента приводит к остановке критичной нагрузки, исключение резерва ради сокращения сметы просто переносит финансовый риск из CAPEX в эксплуатацию.

 

При этом резервирование должно соответствовать реальным требованиям конкретного объекта – максимальный уровень не является самоцелью.

 

✔ Подготовка переключений

Для работающего ЦОД важен не только результат модернизации, но и переход от существующей схемы к новой.

 

До критичных переключений должны быть определены:

 

• исходное состояние;
• последовательность действий;
• контрольные параметры;
• условия прекращения операции;
• порядок возврата к исходной конфигурации.

✔ Испытания

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

 

ГОСТ Р 58811-2020 распространяется на инженерную инфраструктуру ЦОД в России и устанавливает стадии ее создания, этапы внутри стадий и содержание выполняемых работ.

 

✔ Документация

Если фактическая конфигурация ЦОД отличается от схем, следующий ремонт или этап модернизации начинается с недостоверных исходных данных.

 

Поэтому актуальная рабочая и исполнительная документация – не формальность, а часть ремонтопригодности объекта.

 

---

 

Когда точечная модернизация перестает быть выгодной

 

Локальный подход работает, пока изменения можно разделить на относительно независимые задачи.

 

Например:

 

нужно добавить ИТ-мощность → требуется усилить ИБП → существующее распределение не рассчитано на новую нагрузку → увеличивается тепловыделение → нужно менять охлаждение → для инженерного оборудования не хватает места.

 

В такой ситуации набор небольших проектов фактически превращается в комплексную реконструкцию.

 

Ситуация	Возможный масштаб работ
Ограничивает отдельный компонент	Ремонт или локальная модернизация
Ограничивает одна подсистема	Модернизация подсистемы
Несколько инженерных систем требуют взаимосвязанных изменений	Комплексная реконструкция
Ограничения самой площадки остаются после модернизации	Сравнение реконструкции с альтернативным вариантом

 

Если изменения одновременно затрагивают электроснабжение, распределение мощности, охлаждение, автоматику и размещение оборудования, отдельные локальные работы уже целесообразно рассматривать как комплексную модернизацию и реконструкцию действующего ЦОД.

Универсального процента стоимости, после которого модернизация автоматически становится невыгодной, нет. Решение зависит от состояния объекта, требуемой мощности, взаимосвязи систем и того, насколько долго новая конфигурация сможет использоваться без следующей крупной переделки.

Что проверить перед утверждением бюджета

Перед формированием программы модернизации достаточно получить ответы на восемь ключевых вопросов:

1. Какие узлы могут привести к остановке критичной нагрузки?
2. Сохранилось ли резервирование при фактической нагрузке?
3. Какие повторяющиеся дефекты уже выявлены?
4. Какие критичные системы сложно быстро восстановить?
5. Для какого оборудования отсутствует необходимый ЗИП?
6. Какие узлы ограничивают утвержденное развитие?
7. Какую часть существующей инфраструктуры можно безопасно сохранить?
8. Можно ли разделить работы на законченные этапы без последующей переделки?

Если на эти вопросы нет достоверных ответов, сокращать смету преждевременно. Сначала нужно установить фактическое состояние и зависимости инженерных систем.

Главное

Модернизация ЦОД с ограниченным бюджетом – это не полная реконструкция, из которой просто убрали самые дорогие позиции.

Задача состоит в другом – получить максимальное снижение технического риска при доступном объеме инвестиций.

Оптимальная последовательность:

• устранить критичные точки отказа;
• восстановить необходимое резервирование;
• обеспечить ремонтопригодность;
• сохранить исправную инфраструктуру, которая не создает ограничений;
• снять узкие места подтвержденного роста;
• затем инвестировать в повышение эксплуатационной эффективности.

Если же изменения питания, распределения, охлаждения, автоматики и размещения начинают зависеть друг от друга, точечную модернизацию уже нужно сравнивать с комплексной реконструкцией действующего ЦОД.

Часто задаваемые вопросы

Что модернизировать в ЦОД в первую очередь?
То, отказ чего создает наибольший риск для критичной нагрузки: единые точки отказа, потерянное резервирование, выявленные критические дефекты и трудно восстанавливаемые узлы.

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

Нужно ли менять оборудование после прекращения поддержки производителя?
Не автоматически. Нужно оценивать критичность, наличие резерва, ЗИП, ремонтопригодность и последствия возможного отказа.

Можно ли модернизировать ЦОД поэтапно?
Да, если каждый этап заканчивается полноценным работоспособным состоянием и последующие работы не требуют переделывать уже выполненные решения.

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

Источники и нормативная база

• ГОСТ Р 58811-2020 «Центры обработки данных. Инженерная инфраструктура. Стадии создания» – действующий национальный стандарт, введен 1 августа 2020 года.
• ГОСТ Р 70627-2023 «Центры обработки данных. Инженерная инфраструктура. Документация. Техническая концепция. Требования к составу и содержанию» – действует с 1 марта 2023 года.
• Исследование CHINT и Аналитического центра ИКС, 2026 – опрос представителей более 50 российских компаний по состоянию и развитию систем электропитания ЦОД.
• «Российский рынок коммерческих ЦОД 2025» – исследование проведено в июле–сентябре 2025 года; использованы данные о сроках ввода площадок, финансировании и изменении цепочек поставок оборудования.

СИНТО выполняет ее в рамках направления строительства ЦОД для ИИ: от обследования и расчета нагрузок до пусконаладки и сервисной поддержки.

Частые вопросы

1. С какого числа действует закон об ИИ?

Федеральный закон № 243-ФЗ вступает в силу 1 сентября 2026 года. Критерии суверенных и национальных БФМ, обязанности разработчиков и ряд других прикладных положений начинают применяться с 1 марта 2027 года.

2. Обязательно ли размещать ИИ-инфраструктуру в России?

Не для любой ИИ-системы.

Для модели, претендующей на статус суверенной или национальной БФМ, подготовка ответов пользователям и хранение данных должны обеспечиваться в ЦОД на территории Российской Федерации, принадлежащем российскому юридическому лицу.

243-ФЗ не содержит общего требования размещать в России абсолютно всю вычислительную инфраструктуру любой компании, использующей ИИ.

3. Нужно ли обучать модель в России?

Прямого общего требования проводить обучение БФМ на территории России статья 6 не содержит.

Требование локализации в рассматриваемой норме относится к подготовке ответов пользователям и хранению данных.

4. Касается ли закон компании, которая использует готовые ИИ-сервисы?

Закон регулирует разработку, внедрение и применение БФМ, однако обязанности статьи 8 и критерии статусов суверенной и национальной модели относятся прежде всего к разработчикам и самим моделям.

Само использование готового сервиса не делает компанию разработчиком БФМ.

5. Обязательно ли строить собственный ЦОД?

Нет.

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

Поэтому возможны как собственная площадка, так и размещение в подходящем коммерческом ЦОД.

6. Какие штрафы предусмотрены 243-ФЗ?

Собственных штрафов закон не устанавливает. Статья 11 предусматривает ответственность в соответствии с действующим законодательством Российской Федерации.

Источники

• Федеральный закон от 26 июля 2026 года № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации».
• Федеральный закон от 31 июля 2020 года № 258-ФЗ «Об экспериментальных правовых режимах в сфере цифровых инноваций в Российской Федерации».

Программно-аппаратный комплекс (ПАК) - это оборудование и программное обеспечение, поставляемые как единое решение с заранее проверенной совместимостью компонентов, рассчитанной производительностью и зафиксированным поведением при отказах. Разработка ПАК включает шесть этапов: анализ требований, проектирование архитектуры, подбор компонентов, испытания, внедрение и передачу в эксплуатацию.

 

На базе ПАК строят платформы виртуализации, системы хранения и резервного копирования, комплексы информационной безопасности, видеоаналитики и инфраструктуру для искусственного интеллекта.

 

Ключевое отличие ПАК от обычной поставки в том, что компоненты рассматриваются не по отдельности, а как единая архитектура. Отсюда и практическое следствие: комплекс оценивают не по спецификации, а по измеренным показателям и документам, которые эту спецификацию подтверждают.

 

Ниже разберем состав комплекса, этапы разработки, три подхода к его созданию, архитектурные решения, актуальные в 2026 году, и типичные ошибки, которые дороже всего обходятся на внедрении.

 

Материал подготовлен инженерами СИНТО на основе практики проектирования и внедрения инфраструктурных решений.

 

---

 

 

Что такое программно-аппаратный комплекс

 

В состав ПАК могут входить:

 

• серверы или специализированные вычислительные устройства;
• системы хранения данных;
• сетевое оборудование;
• операционные системы и платформенное ПО;
• прикладные программы;
• средства резервного копирования, управления и мониторинга.

 

Например, ПАК виртуализации может включать несколько серверов, программно-определяемое хранилище, сетевую инфраструктуру, гипервизор и единую систему управления.

 

Главный признак комплекса - заранее определенная архитектура взаимодействия компонентов. Для нее фиксируются совместимые версии ПО, требования к ресурсам, схема резервирования и критерии приемки. Если те же характеристики достигаются, когда компоненты работают порознь, перед вами не комплекс, а просто совместимый набор оборудования и лицензий.

 

---

 

Основные типы ПАК и что критично в каждом

 

Требования к программно-аппаратному комплексу зависят от задач, которые он должен решать. Для виртуализации, хранения данных, резервного копирования, видеоаналитики и ИИ-инфраструктуры важны разные параметры. В таблице ниже показано, на что стоит обратить особое внимание при проектировании каждого типа ПАК.

 

Тип ПАК	Задача	Что определяет результат
Виртуализация	Консолидация серверов и сервисов	Плотность ВМ на узел, поведение кластера при отказе узла, лицензирование по ядрам
Хранение данных	Файловые и блочные хранилища, базы данных	Задержки, а не только объём; скорость перестроения массива после отказа диска
Резервное копирование	Защита данных, соблюдение RTO и RPO	Окно копирования и реальная скорость восстановления, а не скорость бэкапа
Информационная безопасность	Защита периметра, контроль трафика	Пропускная способность с включёнными проверками, а не в идеальных условиях
Видеоаналитика	Обработка потоков с камер	Число потоков на узел, глубина архива, нагрузка на сеть и хранилище
ИИ-инфраструктура	Обучение и инференс моделей	Пропускная способность межузловой сети, питание и охлаждение стойки, доступ к данным

 

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

 

---

 

Чем ПАК отличается от набора оборудования и ПО

 

Отдельно закупленные серверы, СХД и лицензии могут соответствовать техническому заданию, но не обеспечивать нужный результат при совместной работе.

 

На этапе внедрения могут обнаружиться ограничения:

 

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

 

При создании ПАК оборудование и ПО подбираются под общую нагрузку. Производительность серверов оценивается вместе со скоростью хранения, сетевыми задержками, резервированием и особенностями приложений.

 

---

 

 

---

 

Как разрабатывается ПАК

Анализ требований

 

Работа начинается с определения задачи и условий эксплуатации.

 

Недостаточно указать, что комплекс должен быть производительным или отказоустойчивым. Требования переводят в измеримые параметры:

 

• количество пользователей и сервисов;
• полезную емкость;
• число операций ввода-вывода;
• время отклика;
• пропускную способность;
• допустимое время простоя;
• сроки восстановления;
• планируемый рост нагрузки на 3-5 лет.

 

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

 

Если инфраструктура уже частично развернута, разумно начать с аудита текущего состояния: он дает точные исходные цифры вместо оценок на глаз.

 

Проектирование архитектуры

 

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

 

Отдельно проверяются единые точки отказа. Несколько серверов не обеспечат высокую доступность, если они зависят от одного коммутатора, контроллера хранения или ввода электропитания.

 

Полезное правило - считать не только штатный режим, но и режим деградации. Кластер, загруженный на 85% в норме, при выходе узла из строя должен куда-то разместить его нагрузку. Если запаса нет, отказ одного узла превращается в отказ сервиса.

 

Здесь же определяется порядок масштабирования: какие ресурсы можно добавить, потребуется ли остановка системы и как изменится стоимость лицензий.

 

Подбор оборудования и программного обеспечения

 

Компоненты выбираются по расчетному профилю нагрузки, а не по максимальным паспортным характеристикам.

 

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

 

На этом этапе фиксируется матрица совместимости: конкретные версии прошивок, драйверов, гипервизора и прикладного ПО, проверенные вместе. Без нее плановое обновление через год может сломать работающую конфигурацию.

 

Испытания

 

Для критичной инфраструктуры комплекс желательно проверить до переноса рабочих сервисов.

 

Вид испытаний	Что проверяется
Функциональные	Выполнение целевых задач
Нагрузочные	Производительность при расчетной и пиковой нагрузке
Отказоустойчивость	Работа при отказе узла, диска или линии связи
Восстановление	Соблюдение установленных RTO и RPO
Интеграционные	Обмен данными с системами заказчика
Масштабирование	Возможность расширения комплекса

 

Результаты фиксируются в протоколе. Формулировка «система работает стабильно» без методики, исходной нагрузки и измеренных показателей не позволяет объективно принять решение.

 

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

 

Внедрение и передача в эксплуатацию

 

После испытаний выполняются установка, настройка, интеграция и перенос данных.

 

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

 

---

 

Три подхода к созданию ПАК

 

Выбор подхода определяет и сроки, и стоимость, и то, насколько решение будет соответствовать задаче.

 

Подход	Как строится	Когда подходит	Ограничения
Платформенный	На базе готовой проверенной платформы вендора	Типовые задачи, сжатые сроки, важна предсказуемость	Меньше гибкости, привязка к линейке и лицензионной политике вендора
Модульный	Из блоков, которые добавляются по мере роста	Поэтапное развитие, неопределенный рост нагрузки	Требует дисциплины в версиях, иначе через пару расширений набор станет разнородным
Заказной	Конфигурация и интеграционные модули под конкретную задачу	Нестандартные требования, интеграция с унаследованными системами	Дольше и дороже, нужны собственные испытания

 

На практике подходы комбинируют: платформа как основа, модульное расширение по мере роста и небольшая заказная часть на стыке с системами заказчика. Полностью заказная разработка нужна реже, чем кажется, - обычно только там, где нет готовой функции или требуется собственный интеграционный слой.

 

---

 

Архитектурные решения, актуальные в 2026 году

 

Гиперконвергентные комплексы. Вычисление, хранение и сеть объединяются в одной платформе, масштабирование идет добавлением узлов. Это упрощает обслуживание и снимает зависимость от отдельного массива хранения. Обратная сторона - вычисление и хранение растут вместе, поэтому при перекосе нагрузки в одну сторону классическая схема с выделенной СХД может оказаться дешевле.

 

NVMe и NVMe over Fabrics. Перевод хранилища на NVMe и доступ к нему по NVMe-oF заметно снижает задержки по сравнению с iSCSI. Это важно для баз данных и нагрузок, чувствительных к времени отклика. Но выигрыш появляется только при соответствующей сетевой части: на перегруженной сети быстрые диски не помогут.

 

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

 

Российские платформы. Для большинства инфраструктурных задач - виртуализация, хранение, резервное копирование, сетевая часть - на рынке есть отечественные решения. Основная работа сместилась с вопроса «есть ли аналог» на проверку совместимости конкретных версий между собой.

 

---

 

Реестровый и доверенный статус: что проверить в проекте

 

Если проект попадает под требования к импортозамещению, к техническим требованиям добавляются формальные. Здесь важно различать два независимых режима - их часто путают.

 

Реестровый ПАК - комплекс, сведения о котором внесены в единый реестр российских программ. Отдельного реестра для ПАК нет: запись делается в том же реестре, но отдельного вида. Ключевой момент для заказчика: наличие в реестре отдельных компонентов не означает, что в реестре есть их сочетание. Проверять нужно запись о конкретной конфигурации в реестре Минцифры.

 

Доверенный ПАК - статус по постановлению № 1912 для субъектов критической информационной инфраструктуры в части принадлежащих им значимых объектов. Комплекс признается доверенным, если одновременно выполняются все три критерия приложения № 1:

 

• сведения о комплексе содержатся в едином реестре российской радиоэлектронной продукции;
• программное обеспечение в его составе отвечает требованиям
• постановления № 1478 к ПО для значимых объектов КИИ;
• если в комплексе реализована функция защиты информации - он
• соответствует требованиям ФСТЭК и (или) ФСБ, что подтверждается сертификатом.

 

Переход на значимых объектах должен быть завершен до 1 января 2030 года.

 

Здесь и кроется различие, которое чаще всего упускают: это два разных реестра. Реестровый ПАК - запись в реестре Минцифры (программное обеспечение), доверенный ПАК - запись в реестре Минпромторга (радиоэлектронная продукция) плюс два дополнительных условия. Один статус не подтверждает другой автоматически, и наличие каждого из них стоит зафиксировать в техническом задании: от этого зависят и выбор компонентов, и сроки, и бюджет.

 

---

 

Типичные ошибки при разработке и выборе ПАК

Сравнение по паспортным характеристикам. Ядра, гигабайты и терабайты сопоставимы у разных решений, а поведение под реальной нагрузкой - нет.
Отсутствие запаса на режим деградации. Конфигурация рассчитана на штатную работу, но не выдерживает нагрузку при отказе узла.

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

Лицензирование без учета роста. Расширение оказывается дороже самого оборудования из-за модели лицензий по ядрам, узлам или пользователям.
 

Проверка статуса по компонентам, а не по конфигурации. Все составляющие российские, но комплекс как единое решение требуемого статуса не имеет.
 

Приемка «по общему впечатлению». Критерии не согласованы заранее, и спорить о результате уже поздно.

 

---

Как выбрать программно-аппаратный комплекс

 

До закупки стоит получить ответы на восемь вопросов:

 

• Для какой нагрузки рассчитана конфигурация?
• Какие версии оборудования и ПО проверены совместно?
• Какие отказы комплекс переносит без остановки сервисов?
• Какие фактические показатели получены на испытаниях?
• Как выполняются обновление и восстановление?
• Где находятся пределы масштабирования и что происходит со стоимостью лицензий?
• Какие требования предъявляет площадка: мощность, охлаждение, место в стойке?
• Если требуется реестровый или доверенный статус - подтвержден ли он для этой конфигурации?

 

Критерии приемки согласовывают заранее. Это позволяет проверить результат по измеримым параметрам, а не по общему впечатлению от работы системы.

 

Сравнивать стоит не цену поставки, а совокупную стоимость владения: лицензии, резервирование, испытания, миграцию и сопровождение на весь срок эксплуатации.

 

---

 

Разработка и внедрение ПАК в СИНТО

 

Мы проводим обследование инфраструктуры, проектируем архитектуру, подбираем оборудование и программное обеспечение, организуем поставку, настройку и испытания комплекса.

 

При необходимости решение строится на российских серверах, системах хранения данных и сетевом оборудовании. Конкретный набор компонентов, их совместимость и требуемый статус проверяются под задачу заказчика, условия эксплуатации и планируемое развитие инфраструктуры.

 

Подробнее - об импортозамещении ИТ-оборудования, серверов, СХД и сетевых решений.

Частые вопросы

Сколько занимает разработка ПАК?

Зависит от подхода. Платформенное решение из проверенной линейки разворачивается заметно быстрее заказного. Основное время обычно уходит не на поставку, а на согласование требований, проверку совместимости версий и испытания.

Можно ли создать ПАК из готовых продуктов?

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

Все ли ПАК проходят предварительные испытания?

Нет. Объем испытаний зависит от конкретного решения. До закупки стоит запросить программу проверки, протоколы и перечень протестированных конфигураций.

Обязательно ли ПАК должен быть сертифицирован?

Нет. Необходимость сертификации определяется назначением решения, требованиями законодательства, объекта и технического задания. Наличие сертификата и область его действия проверяются отдельно.

Чем ПАК отличается от гиперконвергентной платформы?

Гиперконвергенция - это способ построения архитектуры, а ПАК - форма поставки проверенного решения. Гиперконвергентная платформа может быть основой ПАК, но сама по себе комплексом не является, пока не зафиксированы конфигурация, версии и результаты испытаний.

Чем реестровый ПАК отличается от доверенного?

Это записи в разных реестрах. Реестровый ПАК - комплекс, сведения о котором включены в единый реестр российских программ (реестр Минцифры). Доверенный ПАК - комплекс, который одновременно отвечает трем критериям приложения № 1 к постановлению № 1912: он есть в едином реестре российской радиоэлектронной продукции, его ПО соответствует требованиям постановления № 1478, а при наличии функций защиты информации есть сертификат ФСТЭК или ФСБ. Один статус не подтверждает автоматически другой.

Главное

ПАК - это не оборудование с установленной программой, а согласованная архитектура с определенным составом, проверенными версиями и измеримыми характеристиками.

Результат разработки - не спецификация, а конфигурация, для которой известно, какую нагрузку она держит, как ведет себя при отказе, до каких пределов масштабируется и во сколько обойдется расширение. Все остальное проверяется по документам: матрице совместимости, протоколам испытаний и записи о конкретной конфигурации, если проект требует подтвержденного статуса.

Температура в серверной влияет на стабильность серверов, систем хранения данных, сетевого оборудования и источников бесперебойного питания. Но оценивать микроклимат только по настенному датчику нельзя: в центре помещения может быть 22 °C, а перед верхними серверами – уже 27-30 °C из-за возврата нагретого воздуха.

 

Чтобы избежать локального перегрева, недостаточно подобрать кондиционер по площади комнаты. Необходимо определить фактическое тепловыделение оборудования, проверить распределение воздушных потоков, организовать контроль перед стойками и предусмотреть резерв охлаждения.

 

---

 

Какая температура должна быть в серверной

 

Для серверных комнат в российской практике одним из основных нормативных ориентиров является температура 18-24 °C и относительная влажность 30-55% по ГОСТ Р 58242-2018. Применимость этих требований к конкретному объекту уточняют по проектной документации, назначению помещения и характеристикам установленного оборудования.

 

Контрольное измерение по ГОСТ выполняют:

 

• при работающем активном оборудовании;
• на высоте 1,5 м от чистого пола;
• в центре прохода серверной.

 

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

 

Что контролируется	Рабочий ориентир
Температура в серверной по ГОСТ	18-24 °C
Относительная влажность	30-55%
Температура на входе в оборудование по ASHRAE	Рекомендуемый диапазон 18–27 °C
Основная зона риска	Верхняя часть нагруженной стойки

 

Эти диапазоны относятся к разным точкам контроля. ГОСТ Р 58242-2018 задает параметры воздуха в серверной комнате, а рекомендации ASHRAE оценивают условия непосредственно на входе в ИТ-оборудование. Поэтому соответствие температуры в центре прохода не исключает перегрева отдельных серверов.

 

Рекомендации ASHRAE применимы в России как дополнительная отраслевая практика. Они не заменяют российские нормативы, проектную документацию и требования производителей, но помогают оценить условия непосредственно на входе в серверы.

 

Практический вывод: нормальная температура в центре серверной еще не гарантирует отсутствие перегрева оборудования. Безопасный режим подтверждается только измерениями перед стойками и расчетом системы охлаждения под фактическую ИТ-нагрузку.

 

 

---

 

Где и как измерять температуру в серверной

 

Главная ошибка при контроле серверной – ориентация на один датчик возле двери, кондиционера или на возврате воздуха.

 

Такой датчик показывает условия только в своей точке. Он может находиться под холодной струей и фиксировать 20-22 °C, пока верхняя часть удаленной стойки перегревается.

 

Почему возникает локальный перегрев

 

Серверы обычно забирают холодный воздух спереди и выбрасывают нагретый сзади. Если потоки не разделены, горячий воздух возвращается на фронт стойки через:

 

• свободные юниты без заглушек;
• зазоры между стойками;
• негерметичные кабельные вводы;
• неправильно размещенные перфорированные плиты;
• пространство над стойками или под фальшполом.

 

Практическая схема контроля

 

Для небольшой серверной первичную картину можно получить с помощью трех датчиков на фронте наиболее нагруженной стойки:

 

• в нижней зоне – примерно 0,3 м от пола;
• в средней – около 1,1 м;
• в верхней – около 1,8 м.

 

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

 

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

 

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

 

 

---

 

Как рассчитать охлаждение серверной

 

Подбирать кондиционер только по площади помещения нельзя. Серверная площадью 20 м² может потреблять как 3, так и 30 кВт – размер комнаты не показывает реальное тепловыделение.

 

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

 

Упрощенная формула выглядит так:

 

Холодопроизводительность = ИТ-нагрузка + потери ИБП и распределения питания + внешние теплопритоки + вспомогательное оборудование + резерв на развитие.

 

СП 134.13330.2022 требует определять необходимость оснащения помещения системами отопления, вентиляции и кондиционирования на основании расчета – с учетом температуры и влажности, необходимых для нормальной работы размещенного оборудования. Характеристики самой климатической системы затем определяются проектным расчетом. По состоянию на 2026 год действует редакция СП с изменением № 1, введенным в действие 28 января 2025 года.

 

 

Пример расчета

 

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

 

Источник тепла	Расчетная мощность
Серверы, СХД и сетевое оборудование	9,0 кВт
Потери ИБП и распределения питания	0,7 кВт
Освещение и вспомогательное оборудование	0,3 кВт
Теплопритоки через стены, дверь и вентиляцию	1,0 кВт
Суммарное тепловыделение	11,0 кВт
Запас на подтвержденное развитие - 20%	2,2 кВт
Расчетная потребность в холоде	13,2 кВт

 

Запас 20% приведен для примера и не является универсальным нормативным значением. Его выбирают по планам развития ИТ-инфраструктуры, принятой схеме резервирования и диапазону регулирования климатического оборудования.

 

Значение потерь ИБП нельзя автоматически принимать равным 10%. Современный ИБП при высокой загрузке может иметь КПД выше 95%, но при малой нагрузке потери относительно полезной мощности нередко увеличиваются. Для расчета используют кривую КПД конкретной модели.

 

Фактическое потребление лучше получать с интеллектуальных PDU, счетчиков, ИБП или системы мониторинга. Складывать номинальную мощность блоков питания некорректно. Два блока по 1 200 Вт могут резервировать друг друга или совместно распределять нагрузку, но их суммарный номинал не равен фактическому потреблению сервера. Для расчета используют данные интеллектуальных PDU, ИБП, счетчиков или встроенного мониторинга.

Почему важна явная холодопроизводительность

В паспорте кондиционера часто указана полная холодопроизводительность. Но часть этой мощности может расходоваться на осушение воздуха.

Серверы выделяют преимущественно явное тепло, поэтому при подборе системы необходимо проверять:

• явную холодопроизводительность;
• коэффициент SHR;
• производительность при расчетной наружной температуре;
• расход воздуха;
• диапазон регулирования;
• возможность круглосуточной эксплуатации.

Если серверная выделяет 13 кВт явного тепла, кондиционер с полной паспортной мощностью 13 кВт может оказаться недостаточным.

Сплит-система или прецизионный кондиционер

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

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

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

Для стоек с GPU-серверами и другой высокоплотной нагрузкой может потребоваться межрядное или жидкостное охлаждение. В таких проектах оценивать систему только по общей температуре помещения уже недостаточно.

Как резервировать охлаждение

Один кондиционер – единая точка отказа. При его очистке, ремонте или аварии серверная остается без отвода тепла.

Для небольших критичных помещений часто используют схему 1+1: устанавливают два кондиционера, каждый из которых способен самостоятельно покрыть полную расчетную нагрузку. Блоки работают поочередно и автоматически меняют роли.

На более крупных объектах применяется схема N+1: расчетную мощность обеспечивают несколько устройств, к которым добавляется один резервный блок.

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

Что происходит при перегреве

Перегрев редко начинается с мгновенного отключения серверов. Сначала оборудование увеличивает обороты вентиляторов и снижает производительность компонентов.

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

Особенно чувствительны к температуре аккумуляторные батареи ИБП.

Температура и ресурс батарей ИБП

Для свинцово-кислотных VRLA-батарей оптимальной считается температура около 20-25 °C. Schneider Electric приводит практическое правило: повышение температуры примерно на 8 °C относительно 25 °C может сократить ожидаемый срок службы батареи вдвое.

Например, батарея с расчетным сроком службы четыре года при 25 °C может прослужить около двух лет при постоянных 33 °C. При недостаточной вентиляции температура внутри ИБП или батарейного шкафа может быть выше температуры воздуха в помещении.

Это не точная формула прогноза для каждой АКБ. На ресурс также влияют глубина разрядов, зарядное напряжение, состояние соединений, качество батарей и разброс параметров в цепи. Но высокая температура остается одним из основных факторов ускоренного старения.

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

СИНТО выполняет техническое обслуживание, ремонт и сервис систем бесперебойного питания: диагностику ИБП и аккумуляторных батарей, профилактические работы, замену АКБ, проверку силовых соединений, вентиляторов, байпаса и систем мониторинга.

Опасный сценарий при отключении электричества

Одна из типовых ошибок – подключить серверы к ИБП, а кондиционеры оставить на обычном вводе.

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

Нельзя заранее утверждать, что серверная перегреется за пять или десять минут. Скорость зависит от объема помещения, ИТ-мощности, теплоемкости конструкций и воздухообмена. Ее определяют расчетом или контролируемым испытанием.

Правильная схема должна согласовывать:

• время автономии ИБП;
• время запуска ДГУ;
• питание и перезапуск кондиционеров;
• работу АВР;
• алгоритм отключения неприоритетной нагрузки.

При модернизации двух ЦОД ПАО «ОДК-Сатурн» специалисты СИНТО увеличили мощность ИБП APC Symmetra с 10 до 16 кВА, нарастили батарейные емкости, разработали резервирование от одной ДГУ и внедрили удаленный мониторинг нагрузки и температуры батарей. Подробнее о проекте.

Как настроить мониторинг

Система мониторинга должна предупреждать о проблеме до достижения предельно допустимой температуры.

Контролировать стоит не только абсолютное значение, но и скорость роста. Температура 26 °C, которая сохраняется несколько часов, и рост с 22 до 26 °C за пять минут – разные ситуации.

Рабочие пороги устанавливают по требованиям наиболее чувствительного оборудования и проектному режиму объекта. Для серверной, которая штатно работает при 22-23 °C, возможна следующая логика:

Это не универсальная нормативная таблица. Конкретные значения утверждаются в эксплуатационном регламенте.

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

Что проверить, если серверная перегревается

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

Если верх стойки заметно горячее низа, следует искать рециркуляцию: установить заглушки, герметизировать кабельные вводы и разделить потоки холодного и горячего воздуха.

Если температура резко выросла одновременно во всем помещении, вероятна остановка кондиционера, потеря питания, отказ автоматики или отсутствие запуска резервного блока.

Для первичной самостоятельной проверки достаточно:

1. установить датчики в нижней, средней и верхней частях наиболее
2. нагруженной стойки;
3. вести запись не менее недели;
4. измерить фактическое потребление оборудования;
5. сравнить нагрузку с доступной холодопроизводительностью;
6. проверить питание основного и резервного кондиционеров.

Переключение ИБП, АВР, ДГУ и отключение климатического оборудования необходимо проводить только по согласованной программе. Неконтролируемый тест может привести к остановке инфраструктуры.

Когда требуется профессиональное обследование

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

Особенно важно выполнить расчет перед установкой новых СХД, GPU-серверов и другого высокоплотного оборудования. Даже одна стойка с нагрузкой 15-30 кВт может полностью изменить требования к охлаждению помещения.

По результатам обследования заказчик должен получить не общую рекомендацию «поставить еще один кондиционер», а измеримые данные:

• фактическую ИТ-нагрузку;
• карту температуры по стойкам;
• расчет тепловыделения;
• оценку воздушных потоков;
• проверку резервного питания;
• сценарий работы при отказе оборудования;
• перечень необходимых изменений.

Практический опыт обслуживания ИБП

В филиале федерального агентства информации и связи СИНТО организовала поддержку более 100 единиц оборудования разных производителей, включая APC, IBM и Eaton.

На объекте проводится ежеквартальное обслуживание ИБП, профилактические работы и превентивная замена батарейных комплексов. Регламент также предусматривает срочное реагирование, консультации специалистов заказчика и круглосуточную поддержку. Подробнее о сервисном проекте.

Этот подход важен для серверной не меньше, чем установка дополнительных датчиков. Температурный мониторинг показывает условия эксплуатации, но только диагностика ИБП и батарей позволяет определить, сохранилась ли реальная автономия.

Как обеспечить стабильный температурный режим серверной

Для серверной комнаты в России базовым нормативным ориентиром является температура 18-24 °C и относительная влажность 30-55%. Но главный эксплуатационный показатель – температура воздуха непосредственно на входе в серверное оборудование.

Чтобы температурный режим был действительно надежным, необходимо:

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

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

Частые вопросы

Какая температура считается нормальной для серверной?

Для серверной комнаты в России ГОСТ Р 58242-2018 устанавливает диапазон 18-24 °C. Рабочую уставку выбирают внутри этого диапазона с учетом характеристик оборудования и запаса на аварийные ситуации.

Можно ли поддерживать в серверной 25-27 °C?

Для воздуха на входе в часть ИТ-оборудования такой режим входит в рекомендуемый диапазон ASHRAE. Однако температура выше 24 °C выходит за диапазон, указанный ГОСТ Р 58242-2018 для серверной комнаты. Поэтому постоянную эксплуатацию при 25–27 °C необходимо обосновать требованиями оборудования, проектной документацией и нормативами, применимыми к конкретному объекту.

Где нужно измерять температуру?

Контрольное измерение по ГОСТ выполняют на высоте 1,5 м в центре прохода. Для эксплуатации дополнительно измеряют температуру перед стойками, особенно в верхней части.

Как рассчитать мощность кондиционера?

Основой служит фактическое потребление серверов, СХД и сетевого оборудования. К нему добавляют потери ИБП, внешние теплопритоки, вспомогательную нагрузку и обоснованный запас на развитие.

Нужен ли резервный кондиционер?

Для серверной, остановка которой недопустима, – да. В схеме 1+1 каждый из двух кондиционеров должен самостоятельно покрывать полную расчетную нагрузку.

Какая температура оптимальна для батарей ИБП?

Для большинства свинцово-кислотных VRLA-батарей оптимальным считается диапазон около 20-25 °C. Точные требования необходимо проверять в документации производителя.

Мы освобождаем склад под новые закупки и распродаем партии Lenovo, которые закупили ранее: серверы ThinkSystem, диски и SSD, компоненты СХД, рабочие станции, компьютеры ThinkCentre и ноутбуки ThinkPad. Для вас это возможность купить нужное оборудование дешевле, чем при заказе новой поставки, и получить его со склада за 1-3 рабочих дня вместо недель ожидания.

 

 

Что можно закрыть из складских остатков Lenovo

 

Сервер под 1С, виртуализацию или файловое хранилище

 

Если нужно быстро заменить старый сервер, запустить новый контур 1С, развернуть виртуализацию или усилить файловое хранилище, можно подобрать ThinkSystem из наличия – без ожидания поставки под заказ.

 

✔ На складе есть серверы Lenovo ThinkSystem 1U и 2U: SR250, SR630, SR650, SR635, SR850 V2, SR950, SR630 V3 и ThinkAgile HX. Цены начинаются от 82 004 ₽.

 

Подбор делаем по нагрузке: количество пользователей, базы, виртуальные машины, требования к дискам, памяти и отказоустойчивости. Если сервер нужно дооснастить – сразу проверим совместимые диски, SSD, память, RAID/HBA и сетевые карты из этого же складского списка.

 

Все конфигурации и подбор под задачу → складской список серверов ThinkSystem

Замена диска, расширение RAID или апгрейд на SSD

Если в сервере вышел из строя диск, массив почти заполнен или нужно ускорить систему за счет SSD, важна не только цена накопителя. Нужно попасть в совместимость: форм-фактор, интерфейс, салазки, RAID-контроллер, тип корзины и текущую конфигурацию массива.

✔ В наличии серверные HDD и SSD Lenovo ThinkSystem: SAS, SATA, NVMe, 2.5", 3.5", M.2, а также накопители для Lenovo DE Series. Цены начинаются от 3 600 ₽.

Для срочной замены достаточно прислать модель сервера или СХД и партномер старого диска. Мы проверим совместимость и предложим вариант из наличия – это быстрее, чем ждать поставку под заказ.

Все емкости и форм-факторы: → диски и SSD Lenovo

Расширение СХД без полной замены инфраструктуры

Когда действующей СХД уже не хватает, не всегда нужно менять всю систему хранения. Часто задачу можно закрыть полкой расширения, интерфейсным модулем или комплектом для подключения.

В наличии есть Lenovo Storage D1212, шасси Lenovo DE240S, HIC для FC / 10GbE, рельсы и монтажные аксессуары. Полка Lenovo Storage D1212 – от 392 434 ₽, компоненты для монтажа и подключения – от 5 200 ₽.

Такое решение подойдет для расширения емкости под резервные копии, файловые данные, архив, 1С, виртуальные машины и другие корпоративные данные. Перед КП проверим, подойдет ли оборудование к вашей СХД, серверам, SAN, RAID и схеме подключения.

Проверка совместимости и подключение → полки расширения СХД Lenovo

Рабочие станции для инженеров, САПР и 3D

Если AutoCAD, Revit, Компас 3D, Blender или 3ds Max тормозят на обычных офисных ПК, дешевле заменить рабочее место, чем каждый день терять время инженеров и дизайнеров на ожидание открытия моделей, пересчетов и рендера.

✔ В наличии готовые рабочие станции Lenovo ThinkStation P360 от 194 522 ₽. Есть конфигурация для САПР и инженерного проектирования с профессиональной графикой RTX A2000, а также конфигурация для 3D, визуализации и рендера на RTX 5060.

Станции поставляются с Windows 11 Pro и готовы к работе после подготовки. Можно доукомплектовать мониторами Lenovo ThinkVision под чертежи, 3D и визуальный контент.

Сравнение конфигураций → готовые станции Леново для САПР и 3D

Обновление офисных компьютеров

Если парк ПК устарел, сотрудники жалуются на медленную работу, а часть рабочих мест нужно развернуть быстро, можно подобрать компьютеры Lenovo ThinkCentre из наличия.

✔ В наличии компактные ThinkCentre M70q Tiny и системные блоки M70s / M90s SFF. Есть конфигурации с Intel Core i5 и Core i7, SSD 512 ГБ, 8 или 16 ГБ RAM, Windows 11 Pro или без ОС. Цены – от 59 504,90 ₽.

Можно собрать комплект под задачу: ПК, монитор, крепление, клавиатура, мышь, установка ОС, подключение к домену и базовая подготовка. Это удобно для бухгалтерии, отдела продаж, ресепшена, call-центра, учебного класса или массового обновления рабочих мест.

Модели и комплекты →  компьютеры ThinkCentre из наличия

Ноутбуки для сотрудников, руководителей и мобильных команд

Если нужно быстро выдать ноутбук новому сотруднику, заменить старое устройство или дооснастить мобильную команду, можно выбрать модель Lenovo из наличия – от практичного V17 до премиальных ThinkPad.

✔ В наличии Lenovo V17 G4 с большим экраном 17.3", ThinkPad L13, ThinkPad X1 Carbon G13 Aura Edition и ThinkPad X9 15 G1 Aura Edition. Есть модели с Windows 11 Pro и без ОС, новые позиции, Б/У и варианты с поврежденной упаковкой. Цены – от 58 230 ₽.

Поможем выбрать без переплаты: где достаточно большого экрана и Core i7, где нужен компактный ThinkPad, а где оправдан премиальный X1 Carbon или X9 для руководителя, презентаций и командировок.

Весь модельный ряд → бизнес-ноутбуки Lenovo

Консолидация серверной и blade-инфраструктура

Если нужно не просто заменить один сервер, а собрать плотную инфраструктуру под виртуализацию, VDI, базы данных или кластерные нагрузки, можно рассмотреть Lenovo Flex System и blade-серверы SN550 V2.

Это проектное направление: здесь нельзя выбирать только по цене или названию модели. Нужно понимать нагрузки, сеть, SAN, требования к отказоустойчивости, питанию, охлаждению и дальнейшему масштабированию.

Мы проверим состав шасси, доступные blade-узлы, коммутацию, FC/SAN, сетевые модули и подготовим расчет под вашу инфраструктуру.

Готовые решения и состав → серверный кластер Lenovo Flex System

Почему цены ниже

Оборудование закуплено в предыдущих партиях и находится на складе компании. Распродажа проводится для высвобождения складских площадей под новые поставки, поэтому цены на остатки установлены ниже стоимости аналогичных конфигураций под заказ. Снижение цены обусловлено происхождением партии и не связано с характеристиками или состоянием техники: это новое оборудование, которое проходит ту же проверку и оформляется теми же документами, что и обычные поставки.

Скачать полный прайс на оборудование Lenovo:

Проверка и условия поставки

Перед выставлением КП:

• инженер проверяет комплектность, работоспособность и совместимость с вашей инфраструктурой;
• в КП фиксируем цену, срок отгрузки, гарантию и НДС;

• если позиция не соответствует задаче, предлагаем альтернативу из складского списка или под заказ.

   

Поставка выполняется по договору с полным пакетом документов. По запросу организуем доставку, монтаж, настройку и миграцию, а также дооснащение серверов памятью, дисками, RAID/HBA и сетевыми картами из наличия.

Как проходит покупка

Вы оставляете заявку или запрашиваете полный список остатков – отвечаем в течение рабочего дня.
Уточняем задачу и требования: нагрузка, количество пользователей, текущая инфраструктура. Либо вы сразу присылаете список нужных позиций.

Направляем КП с зафиксированной ценой, гарантией, НДС и сроком отгрузки.
После согласования отгружаем со склада за 1-3 рабочих дня. По запросу выполняем доставку, монтаж, настройку и миграцию.

Частые вопросы покупателей

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

Что если оборудование не подойдет к моей инфраструктуре?
Перед КП инженер сверяет совместимость: для дисков – интерфейс, салазки и RAID-контроллер, для серверов – опции дооснащения, для СХД – модель массива и тип подключения. При несоответствии предложим альтернативу до сделки.

Можно получить весь список распродажи сразу?
Да, пришлем актуальный файл со всеми остатками и ценами – оставьте заявку или напишите нам на почту.

Собственный ЦОД для ИИ нужен, когда постоянная GPU-нагрузка делает аренду облака дороже владения. Второй триггер – данные, которые нельзя выносить за периметр компании. Разберем, по каким признакам понять, что промышленный искусственный интеллект перерос облачные вычисления.

 

Коротко: главные выводы

Средняя мощность стойки в ЦОД выросла примерно с 8 до 17 кВт за два года. ИИ-платформы требуют 30-120 кВт (данные Uptime Institute и документации NVIDIA).

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

По оценкам участников рынка, спрос на мощности ЦОД в России превышает доступное предложение, особенно в сегменте высокоплотных размещений. Обычная серверная GPU-кластер не выдержит: нужны жидкостное охлаждение и резервированное питание.

 

 

---

Почему промышленный искусственный интеллект перерастает облака

 

Облако – отличный старт для пилота. Но что происходит, когда модель уходит в промышленную эксплуатацию? Нагрузка становится постоянной, а счета за графические ускорители – регулярными и растущими.

 

Аренда GPU дорожает вместе с нагрузкой

 

Аренда GPU выгодна при коротких экспериментах и пиковых задачах. Однако обучение больших языковых моделей и круглосуточный инференс меняют экономику. В облачной модели капитальные затраты заменяются регулярными платежами. Это удобно для старта и пиковых задач, но при постоянной загрузке GPU нужно считать экономику на горизонте нескольких лет.

 

Посчитайте простую вещь: сколько часов в месяц ваши ускорители реально загружены? Если утилизация стабильно высокая, аренда превращается в переплату.

 

Дефицит мощностей в коммерческих ЦОД

 

Свободные стойко-места под высокие мощности – отдельная проблема. По оценкам участников рынка, спрос на мощности ЦОД в России превышает доступное предложение, особенно в сегменте высокоплотных размещений.

 

Под высокоплотные ИИ-нагрузки свободных залов еще меньше, чем под классические серверы. Поэтому крупные заказчики все чаще выбирают собственные объекты. На проектах СИНТО мы видим тот же запрос: выделенная зона на 30-100 кВт на стойку «под себя».

 

Задержки и объем данных

 

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

 

---

 

Чем ИИ-нагрузка отличается от классической ИТ-инфраструктуры

 

Дата-центр под нейросети – это не «серверная побольше». Отличается сама физика: энергия, тепло, сеть.

 

Плотность мощности стойки: с 5 до 120 кВт

 

Классическая стойка потребляет 5–10 кВт. По оценкам Uptime Institute, средняя плотность мощности выросла с 8 до 17 кВт за два года и движется к 30 кВт. Операторы российских ЦОД фиксируют запросы ИИ-сегмента на 30-50 кВт на стойку.

 

Обучение крупных моделей требует еще больше. NVIDIA в документации указывает для платформы GB200 NVL72 около 120 кВт на стойку. Uptime Institute оценивает ее энергопотребление в 132 кВт.

 

Тепло: жидкостное охлаждение вместо воздушного

 

Воздушное охлаждение через фальшпол эффективно примерно до 15 кВт на стойку. Дальше воздух физически не успевает отводить тепловыделение GPU-серверов. Нужен жидкостный контур: DLC-плиты на чипах, блоки CDU, насосные группы, датчики протечек.

 

Жидкостное охлаждение заодно улучшает PUE – энергоэффективность всего объекта. Мы в СИНТО внедряли водяное охлаждение в действующем дата-центре под стойки до 100 кВт – без демонтажа существующих инженерных систем.

Сеть и хранение для GPU-кластера

Узлы GPU-кластера при распределенном обучении обмениваются терабайтами данных. Нужны оптические трассы, СКС с запасом по пропускной способности и низкие задержки между стойками. Обычная офисная сеть здесь не работает.

Облако, колокация или собственный ЦОД для ИИ: что выбрать

Универсального ответа нет – есть профиль нагрузки и требования к данным. Сравним три модели размещения.

Совокупная стоимость владения (TCO)

Считайте TCO на горизонте 3-5 лет: капитальные затраты, энергия, эксплуатация, персонал. В расчетах для заказчиков мы дополнительно закладываем стоимость простоя и резерв под рост плотности стоек. При загрузке ускорителей близкой к постоянной владение обычно окупает себя.
 

Когда облака достаточно

Облачные вычисления оправданы для пилотов, сезонных пиков и редких дообучений. Гибридная инфраструктура тоже рабочий вариант: база – у себя, пики – в облаке. Так вы не замораживаете CAPEX раньше времени.

Когда нужна своя площадка

Признаки простые: постоянная нагрузка, чувствительные данные, требования регуляторов, горизонт от трех лет. Если совпали два и больше – пора считать проект собственного объекта.

Что требует закон: 152-ФЗ, КИИ и коммерческая тайна

Иногда вопрос выбора решает не экономика, а регуляторика. Проверьте три зоны риска.

Локализация персональных данных

152-ФЗ требует, чтобы базы с персональными данными граждан РФ находились на территории России. Это ограничивает использование зарубежных площадок, но не закрывает облачную модель: российские провайдеры подходят. Локализация снимает территориальный вопрос, а меры защиты, доступы и журналы событий оцениваются отдельно.

Критическая информационная инфраструктура

Если ваши системы попадают под 187-ФЗ «О безопасности КИИ», требования жестче. Промышленность, энергетика, финансы, транспорт обязаны обеспечивать защищенность значимых объектов. Контроль физического периметра здесь – весомый аргумент за собственную инфраструктуру для ИИ.

Модели и обучающие выборки – это актив

Обученная модель и датасеты – коммерческая тайна и конкурентное преимущество. Передавая их внешнему провайдеру, вы расширяете периметр риска. Суверенитет данных и моделей проще обеспечить на контролируемом объекте.

Что чаще всего забывают в расчете TCO

Ошибка в сравнении почти всегда одна: считают счет за облако против стоимости железа. Реальная картина шире – и в обе стороны.

Энергия и эксплуатация

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

Горизонт устаревания ускорителей

Поколения GPU меняются быстро. Считайте владение на 3–5 лет и закладывайте, что через этот срок часть парка потребует обновления. Если ваши задачи живут меньше – облако честно выигрывает.

Кто будет эксплуатировать

Своя площадка требует дежурной службы или сервисного договора. Компании без эксплуатационной команды часто выбирают гибрид: база на своей площадке под договором обслуживания, пики – в облаке.

Риск недозагрузки

Собственный кластер выгоден при высокой утилизации. Если загрузка плавает от 20 до 100%, посчитайте сценарий, где часть мощности простаивает: иногда он переворачивает результат.

Как перейти от облака к своей инфраструктуре: план

Переход – это управляемый проект, а не прыжок. Последовательность такая:

1. Аудит нагрузки: тип задач (обучение, инференс, RAG), утилизация, рост на 3-5 лет.
2. Аудит площадки: доступная электрическая мощность, перекрытия, трассы, помещения.
3. Расчет TCO и сравнение сценариев: облако, свой объект, гибрид.

Эти три шага дают ответ «строить или арендовать». Дальше начинается проектная стадия – выбор формата, расчет питания и охлаждения, поставка и пусконаладка. Это уже работа подрядчика: строительство ЦОД для ИИ.

Частые вопросы о собственной ИИ-инфраструктуре

При каком масштабе облака перестает хватать?

Ориентир – стабильная загрузка ускорителей и горизонт задач от 1-3 лет. Если GPU работают почти круглосуточно, аренда начинает проигрывать владению. Точный порог показывает расчет TCO под ваш профиль нагрузки.

Что выгоднее при постоянной нагрузке: аренда GPU или своя площадка?

При высокой утилизации на горизонте 3–5 лет владение обычно выигрывает: капитальные затраты распределяются, а стоимость эксплуатации предсказуема. При плавающей загрузке и коротком горизонте выигрывает аренда.

Можно ли совмещать облако и собственную инфраструктуру?

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

Запрещает ли 152-ФЗ размещать ИИ-нагрузки в облаке?

Нет. Закон требует, чтобы базы с персональными данными граждан РФ находились на территории России, поэтому российские облака остаются допустимым вариантом. Отдельно оцениваются меры защиты, разграничение доступа, журналы событий и ответственность сторон в договоре.

Вывод: считайте, а не гадайте

Собственный ЦОД для ИИ – ответ на постоянную нагрузку, дефицит мощностей и требования к данным. Решение принимается на цифрах: утилизация, TCO, доступная энергия, план роста. Если расчет показал, что своя площадка выгоднее аренды, следующий шаг – проектный.

Материал подготовила инженерная команда СИНТО – проектируем и строим ЦОД с 2010 года. 

Когда-то разработчик добавил на сайт кнопки «Войти через Google» и Apple ID – чтобы пользователям было удобнее регистрироваться. В 2026 году эти кнопки превратились в маркер куда более крупного вопроса: насколько глубоко бизнес завязан на зарубежную ИТ-инфраструктуру.

 

С 7 июля 2026 года вход через иностранные сервисы авторизации на российских сайтах попал под административную ответственность. Но если смотреть на ситуацию глазами не юриста, а ИТ-команды, две кнопки на сайте – лишь верхушка айсберга. Под ними почти всегда обнаруживаются почта, документы, облака и совместная работа, которые тоже держатся на зарубежных платформах.

 

Разберем по делу: что меняется, кого это касается, а главное – как навести порядок во всем цифровом контуре без остановки работы.

 

📌 Коротко. С 7 июля 2026 владельцы российских сайтов, приложений и информационных систем могут получить штраф за авторизацию пользователей через Google ID, Apple ID и другие иностранные сервисы. Основание – Федеральный закон от 26.06.2026 № 199-ФЗ, дополнивший КоАП РФ статьей 13.55. Штраф для юрлиц – от 500 000 до 700 000 рублей, за повторное нарушение – до 1,4 млн. Обычных пользователей это не касается: отвечают владельцы ресурсов.

 

---

 

Что вообще произошло

 

Сам запрет на авторизацию россиян через иностранные сервисы – не новость. Он действует еще с 1 декабря 2023 года и закреплен в пункте 10 статьи 8 закона «Об информации, информационных технологиях и о защите информации» (149-ФЗ). Просто до лета 2026 года нарушение этого правила ничем не грозило – санкций в КоАП не было.

 

26 июня 2026 года Президент РФ подписал Федеральный закон № 199-ФЗ. Он дополнил Кодекс об административных правонарушениях новой статьей 13.55, и она вступила в силу 7 июля 2026 года. С этого дня у запрета появились зубы: если владелец ресурса обязан авторизовать пользователей из России разрешенными способами, но продолжает пускать их через иностранный механизм входа, ему выпишут штраф.

 

То есть это не новый запрет, а ответственность за старое правило. Банки, операторы связи, крупные маркетплейсы перестроились давно: оставили вход через Госуслуги, российские ID и SMS, а кнопки Google и Apple убрали. Сейчас очередь дошла до всех остальных.

 

---

 

Сколько стоит ошибка

 

Кто нарушил	Первое нарушение	Повторное нарушение
Юридические лица	500 000 – 700 000 ₽	до 1 400 000 ₽
Должностные лица	30 000 – 50 000 ₽	выше (по правилам КоАП)
Граждане – владельцы ресурса	10 000 – 20 000 ₽	выше (по правилам КоАП)

 

⚡ Обратите внимание: штраф для «граждан» – это не про обычного посетителя сайта, а про физлицо, которое владеет информационным ресурсом.

 

---

 

 

Кого касается, а кого – нет

 

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

 

А вот кого закон не трогает – это обычных людей, которые когда-то входили на сайт через Gmail или Apple ID. На этом отдельно настаивали и авторы инициативы, и Роскомнадзор: норма бьет по инфраструктуре, а не по гражданам. Так что паника в духе «меня оштрафуют за мой гугл-аккаунт» – мимо.

 

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

 

---

 

Что под запретом 🚫

 

Под риск попадает все, где личность пользователя подтверждает внешний зарубежный сервис:

 

• кнопка «Войти через Google» (Google ID / Google OAuth);
• кнопка «Войти через Apple» (Apple ID);
• вход через аккаунты зарубежных соцсетей;
• сторонние иностранные OAuth-провайдеры;
• иностранные корпоративные SSO-сервисы;
• плагины авторизации, которые передают идентификацию внешнему зарубежному сервису.

 

---

Что разрешено ✔

 

Закон отсылает к способам из 149-ФЗ. Авторизовать пользователя из России можно одним из вариантов:

 

• по номеру российского мобильного телефона;
• через ЕСИА (портал «Госуслуги»);
• через Единую биометрическую систему (ЕБС);
• через российскую информационную систему, владелец которой –
• гражданин РФ или российское юрлицо (например, VK ID, Яндекс ID, Сбер ID).

Полный перечень допустимых российских сервисов авторизации дополнительно формирует Правительство РФ.

 

---

 

Важно: почта как логин – это не нарушение

 

Здесь больше всего путаницы, поэтому проговорим четко. Закон не запрещает указывать иностранную почту в качестве логина. Если человек регистрируется по схеме «email + пароль» и пишет адрес на Gmail – это не вход «через Google».

 

Нарушение – это сторонний сервис идентификации. То есть кнопка «Войти через Google / Apple», когда чужая экосистема подтверждает личность и отправляет данные пользователя на серверы за пределами России. Так это разъяснял профильный центр РОЦИТ.

 

Вывод простой: убирать нужно OAuth-кнопки и интеграции с иностранными провайдерами входа, а привычную авторизацию по почте и паролю трогать не обязательно.

Юридические нюансы – точные формулировки нормы и риски конкретной проверки – оставим юристам. СИНТО отвечает за техническую сторону: найти все точки входа, убрать иностранные интеграции и перевести инфраструктуру на российские сервисы. Дальше – по делу.

 

---

 

Почему дело не в одной кнопке

 

Казалось бы, задача на полчаса: зашел в админку, убрал кнопки Google и Apple, выдохнул. Но в реальности иностранные сервисы у большинства компаний вросли в рабочие процессы куда глубже:

 

• сотрудники сидят в Google Workspace или Microsoft 365;
• документы лежат в зарубежных облаках;
• корпоративная почта завязана на иностранную платформу;
• видеовстречи идут в зарубежных сервисах;
• договоры, таблицы и презентации редактируются совместно через внешнее облако;
• подрядчики и клиенты получают файлы через иностранные аккаунты;
  права доступа и SSO привязаны к зарубежному каталогу пользователей.

И вот тут всплывает неудобная правда: можно убрать Google Login с сайта, но если критичные документы и переписка по-прежнему живут в иностранном облаке, зависимость от зарубежной инфраструктуры никуда не делась. Закон лишь подсветил то, что и так было слабым местом.

 

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

 

---

 

 

Чек-лист: что проверить в первую очередь

 

1. Сайты и личные кабинеты. Все страницы входа и регистрации: кабинеты клиентов, партнерские разделы, закрытые каталоги, сервисные порталы, формы с сохранением профиля, обучающие платформы. Смотрите не только видимые кнопки, но и код – иногда иностранный OAuth-провайдер остается в системе даже после того, как кнопку убрали из интерфейса.

 

2. Мобильные приложения. Если есть приложение в App Store, Google Play, RuStore или корпоративном контуре – проверьте способы входа, SDK авторизации и аналитику. Вход для пользователей из России не должен опираться на иностранные аккаунты.

 

3. Корпоративные порталы. HR-порталы, базы знаний, сервис-деск, порталы для дилеров, проектные кабинеты – все это может использовать внешнюю авторизацию или иностранные SSO.

 

4. Документы, почта и совместная работа. А вот здесь начинается самое интересное. Где хранятся документы? Как сотрудники обмениваются файлами? Где согласуются договоры? На каких сервисах держатся почта, видеовстречи и общая работа над проектами?

 

⚡ Если на последнем пункте вы поймали себя на мысли «а ведь у нас тут сплошной Google и Microsoft» – значит, аудит вскрыл главное. И дальше вопрос уже не в кнопке на сайте, а в том, на чем работает вся компания.

 

---

 

Как перейти на российский контур и не остановить работу

 

Резко выдергивать привычные инструменты – плохая идея: встанут процессы, взбунтуются сотрудники. Безопаснее идти по шагам:

 

1. Провести аудит сервисов: авторизация, почта, документы, файловые хранилища, чаты, видеовстречи, проектные системы.
2. Понять, что критично для работы и где именно сидят зарубежные зависимости.
3. Подобрать российскую платформу под реальные сценарии компании.
4. Запустить пилот и проверить совместимость документов, шаблонов, макросов, регламентов и прав доступа.
5. Перенести данные, настроить домены, каталоги пользователей, группы, роли и политики безопасности.
6. Обучить пользователей и администраторов.
7. Поэтапно отключить иностранные сервисы там, где они создают юридические, технические или операционные риски.

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

 

Импортозамещение ПО под ключ

 

Когда аудит показал, где компания завязана на зарубежные сервисы, начинается сам переход. СИНТО берет его на себя целиком – импортозамещение ПО под ключ: внедряем российские ОС, офисные системы, почтовые сервисы и серверную инфраструктуру без остановки бизнес-процессов.

На практике это закрывает все слои, которые всплывают при проверке авторизации:

• операционные системы на рабочих местах и серверах;
• офисные редакторы документов, таблиц и презентаций;
• корпоративную почту и календари;
• серверную инфраструктуру и хранение файлов в контуре компании;
• каталоги пользователей, права доступа и политики безопасности.

Конкретные продукты подбираются под ваши сценарии по итогам аудита – так, чтобы сотрудники сохранили привычную логику работы, а данные и доступы остались под контролем компании. Переход идет поэтапно: пилот, проверка совместимости документов, миграция, обучение и только потом отключение иностранных сервисов.

Где компании чаще всего ошибаются

❌ Убирают кнопку, но не меняют архитектуру. Удалить «Войти через Google» из интерфейса мало, если под капотом остался зарубежный провайдер, внешний SSO или зависимость от иностранного облака.

❌ Забывают про старые сервисы. Чаще всего грабли лежат не на главном сайте, а в забытых кабинетах, партнерских порталах, тестовых доменах и старых приложениях.

❌ Не готовят людей к переходу. Даже отличное российское ПО встречают в штыки, если сотрудников просто ставят перед фактом. Нужны пилот, инструкции и понятная схема миграции.

❌ Не проверяют совместимость документов. Сложные таблицы, шаблоны договоров, презентации с макросами, печатные формы – все это стоит прогнать заранее, чтобы после переезда ничего не развалилось.

Что сделать уже сейчас

Минимум, с которого стоит начать:

• найти все точки регистрации и входа пользователей;
• проверить, нет ли Google ID, Apple ID, иностранных OAuth-провайдеров и
• зарубежных SSO – в том числе в коде и плагинах;
• определить, какие российские способы авторизации можно внедрить;
• посмотреть, какие офисные и коммуникационные сервисы завязаны на иностранные платформы;
• подготовить план перехода на российские решения без остановки бизнеса.

Этот чек-лист удобно закрыть одним заходом – комплексным аудитом ИТ-инфраструктуры. СИНТО проверяет серверы, сеть, рабочие места, 1С, ПО, доступы, лицензии, резервное копирование и базовую безопасность – вход через Google и Apple ID здесь лишь одна из точек. На выходе вы получаете понятный отчет: где скрыты риски, что может остановить работу бизнеса, что исправлять в первую очередь и какой бюджет нужен на наведение порядка.

Аудит дает отправную точку: понятно, что и в каком порядке менять и сколько это стоит. Дальше переход на российские решения СИНТО закрывает под ключ – поэтапно, с пилотом, миграцией данных, обучением сотрудников и поддержкой, без остановки работы.

📋 Оставьте заявку на аудит ИТ-инфраструктуры – найдем рисковые зависимости и составим план. А сам переход закроем под ключ: импортозамещение ПО без остановки бизнес-процессов.

Итог

Штрафы за авторизацию через Google и Apple ID – это не разовая новость про две кнопки, а сигнал: государство переводит идентификацию и данные в российский контур, и бизнесу придется следовать за ним. Правильная реакция – не косметика, а проверка всего: вход пользователей, хранение документов, почта, чаты, видеовстречи, совместная работа. И если аудит показывает, что компания держится на зарубежных облаках, разумнее не латать дыры, а спланировать переход на российские решения. Что именно менять и в каком порядке – подскажет аудит, а СИНТО проведет и сам переход под ключ, без остановки работы.

Часто задаваемы вопросы

Штрафуют ли обычных пользователей за вход через Google или Apple ID?
Нет. Ответственность по статье 13.55 КоАП РФ несут владельцы сайтов, приложений и информационных систем, а не обычные пользователи интернета.

Какой штраф грозит юридическому лицу?
От 500 000 до 700 000 рублей за первое нарушение и до 1 400 000 рублей за повторное. Для должностных лиц – от 30 000 до 50 000 рублей, для граждан-владельцев ресурса – от 10 000 до 20 000 рублей.

С какой даты действуют штрафы?
С 7 июля 2026 года – момента вступления в силу Федерального закона от 26.06.2026 № 199-ФЗ. Сам запрет на иностранную авторизацию действует с 1 декабря 2023 года.

Можно ли использовать Gmail как логин?
Да. К логину требований нет. Запрещен сторонний сервис идентификации (кнопка «Войти через Google / Apple»), а не вход по схеме «email + пароль», даже если адрес почты на Gmail.

Какие способы авторизации разрешены?
Номер российского телефона, ЕСИА (Госуслуги), Единая биометрическая система и российские сервисы авторизации – например, VK ID, Яндекс ID, Сбер ID.

Нужно ли срочно убирать Google и Apple ID с сайта?
Если ваш сайт, приложение или система дает пользователям из России доступ через авторизацию и использует иностранные способы входа – да, этот механизм нужно заменить на разрешенный. Начните с аудита всех точек входа, включая код, плагины и мобильные приложения.

С чего начать приведение ИТ в порядок?
С аудита ИТ-инфраструктуры: он покажет все точки входа и зарубежные зависимости – от формы авторизации до почты, документов и серверов. Дальше переход на российское ПО выполняется под ключ, поэтапно и без остановки бизнес-процессов.

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

 

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

 

И в 2026 году это перестало быть теорией: в крупных городах России подключить новый энергоемкий объект становится все труднее. Разберем, почему энергетика стала одним из ключевых проектных ограничений для ИИ-инфраструктуры, насколько все серьезно и как эту задачу решают на этапе проектирования.

 

 

---

💡 Коротко: в чем суть проблемы

 

Дата-центры под ИИ потребляют в разы больше энергии, чем обычные: стойка с GPU-ускорителями – это 30-100 кВт и выше против 5-15 кВт у стандартной. Ввод новых сетевых мощностей идет медленно, а в популярных локациях свободная мощность стала ограниченным ресурсом. В итоге спрос на ИИ-вычисления растет быстрее, чем физическая возможность их запитать.

 

Проблема решаема, но не «оборудованием», а грамотным проектом. Ключевые решения – выбор площадки по энергии, автономная или гибридная генерация, модульный ввод – закладываются в самом начале, на этапе выбора площадки и энергоаудита. Именно поэтому энергетику прорабатывают до того, как выбраны серверы и архитектура.

 

---

 

Масштаб проблемы

 

Несколько тенденций, которые отрасль сегодня отмечает достаточно единодушно.

 

Плотность нагрузки выросла на порядок. Классический серверный зал проектировался под стойку на 5-15 кВт. Отдельные высокоплотные GPU-конфигурации нового поколения потребляют уже около 100 кВт на стойку и выше – это уровень небольшой электроподстанции в одном шкафу. И это не предел: по прогнозам отрасли, в перспективе появятся конфигурации с еще большей нагрузкой.

 

Ввод мощностей замедлился. По оценкам участников рынка, ввод новых коммерческих стойко-мест в России в 2025 году замедлился по сравнению с ожиданиями рынка. Совокупная мощность всей действующей инфраструктуры дата-центров страны исчисляется единицами гигаватт – и это немного на фоне спроса, который создает ИИ.

 

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

 

Очередь измеряется годами. Технологическое присоединение в дефицитных зонах может растягиваться на год-два, а полный цикл запуска объекта в такой локации – доходить до нескольких лет. Для технологии, где поколения ускорителей сменяются каждые 1-2 года, это критично: пока строишь, железо устаревает.

 

 

---

 

Обычный ЦОД и ЦОД под ИИ: в чем разница

 

Нагляднее всего разрыв виден при прямом сравнении обычной ИТ-нагрузки и нагрузки под ИИ.

 

Параметр	Обычный корпоративный ЦОД	ЦОД под ИИ
Мощность на стойку	5-15 кВт	30-100 кВт и выше
Профиль потребления	Ровный, предсказуемый	Скачкообразный, с пиками при обучении
Охлаждение	Воздушное	Жидкостное (выше ~20 кВт воздух не справляется)
Требования к энергоподключению	Умеренные, чаще решаемы на месте	Высокие, часто упираются в лимиты сети
Роль выбора площадки	Один из факторов	Существенно возрастает из-за требований к энергии

 

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

Почему это бьет именно по ИИ, а не по ИТ вообще

У обычной корпоративной ИТ-нагрузки потребление ровное и предсказуемое. У ИИ – нет. Обучение больших моделей дает резкие скачки потребления при синхронизации вычислений между ускорителями, а пиковые нагрузки заметно превышают средние. Это другой профиль нагрузки, под который нужны другие мощности, другое резервирование и другое охлаждение.

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

Почему это важно: контроль над инфраструктурой

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

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

Вопрос энергообеспечения ИИ-инфраструктуры отрасль и профильные ведомства признают одним из ключевых, и над ним уже работают – от планов синхронизации развития энергетики с цифровой инфраструктурой до вывода новых объектов в энергоизбыточные регионы. Но пока эти механизмы разворачиваются, для конкретного проекта энергетика остается ограничением, которое влияет на то, где и в какие сроки объект можно построить.

Как эту задачу решают на практике

Проблема решается, если учитывать энергетику на старте проекта, а не после выбора площадки. Решения складываются в четыре направления, и все они закладываются на этапе проектирования.

1. Выбор площадки по энергии, а не по удобству

Мощность есть там, где ее меньше потребляют: энергоизбыточные регионы Северо-Запада, Поволжья, Урала и Сибири. В профицитном регионе объект часто удается запустить существенно быстрее, чем в дефицитной зоне мегаполиса.

Но выбор площадки под ИИ – это уже не «найти помещение поближе». Это инженерная задача: проверить реальную доступную мощность, очередь на присоединение у сетевой организации, наличие резерва на ближайшей подстанции, связанность, логистику и доступность кадров. Ошибка на этом этапе обходится дорого, потому что обнаруживается уже в ходе стройки, когда изменить площадку сложно.

2. Автономная и гибридная генерация

Если сети не дают мощности или подключение экономически невыгодно, рассматривают собственную или гибридную генерацию – например, газопоршневые установки как основной, резервный или комбинированный источник.

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

3. Модульный подход вместо долгой стройки

Классическая последовательность «сначала проектируем, потом закупаем, потом строим» под ИИ работает плохо – за два-три года стройки железо успевает смениться на новое поколение.

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

4. Энергоаудит раньше всего остального

Главный практический принцип: под ИИ-объект вопрос «где взять мегаватты» прорабатывают в первую очередь, наряду с выбором оборудования и архитектуры. Реальную доступную мощность, очередь на присоединение и его ориентировочную стоимость проверяют до того, как принято решение о месте.

Затраты на технологическое присоединение на дефицитной площадке могут составлять заметную долю всех капитальных вложений в объект – это слишком много, чтобы оставлять на потом.

Коротко о подходе

Общий принцип для любого ИИ-объекта: энергетику прорабатывают до выбора оборудования. На энергоаудите проверяют реальный лимит мощности на площадке, фактическую очередь на присоединение и доступные альтернативы – профицитный регион, автономную или гибридную генерацию, поэтапный модульный ввод – и уже с этими вводными считают экономику и сроки.

Именно так мы в СИНТО ведем проекты дата-центров под ИИ – как единый генеральный подрядчик, от энергоаудита и проектирования по ГОСТ Р 58811-2020 до ввода в эксплуатацию.

Планируете собственный дата-центр под ИИ-нагрузки?

Мы проводим энергоаудит площадки: оцениваем доступную мощность, очередь на присоединение, резервы и альтернативы – от автономной генерации до размещения в энергоизбыточном регионе – и помогаем спланировать реальные сроки и бюджет еще до старта проектирования. → Услуга: Строительство ЦОД для ИИ

Часто задаваемые вопросы

Почему для ИИ не хватает электричества, если чипы можно купить?

Дата-центры под ИИ потребляют в разы больше энергии, чем обычные: стойка с GPU требует 30-100 кВт против 5-15 кВт у стандартной. При этом ввод новых сетевых мощностей идет медленно, а в ряде популярных локаций свободная сетевая мощность стала ограниченным ресурсом. Купить оборудование можно, а вот подвести к нему нужные мегаватты – не везде и не быстро. Поэтому энергетику проекта прорабатывают в первую очередь, на этапе выбора площадки.

Почему в мегаполисах сложно построить дата-центр под ИИ?

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

В каких регионах России есть свободные энергомощности под ЦОД?

Больше свободной мощности – в энергоизбыточных регионах: на Северо-Западе, в Поволжье, на Урале и в Сибири. В таких локациях объект часто удается запустить быстрее, чем в дефицитной зоне мегаполиса. При выборе учитывают не только энергию, но и связанность, логистику и доступность инженерных кадров – это часть предпроектного аудита.

Что делать, если на площадке не хватает сетевой мощности?

Два основных пути: рассмотреть площадку в энергоизбыточном регионе или собственную либо гибридную генерацию – например, газопоршневые установки как основной, резервный или комбинированный источник. Такой вариант требует отдельного технико-экономического расчета и проверки требований к размещению и эксплуатации. Какой путь дешевле под конкретную задачу, показывает энергоаудит площадки.

Как размещение данных влияет на выбор между своим и арендованным ЦОД?

В проектах с персональными данными граждан РФ, объектами КИИ, банковской, медицинской или иной регулируемой информацией требования к размещению и контролю инфраструктуры нужно проверять отдельно. Для части таких сценариев собственная площадка или российский контур могут быть обязательным или предпочтительным вариантом – а это повышает значимость вопроса доступной энергетической мощности на выбранной площадке.

С чего начать проект дата-центра под ИИ?

С энергоаудита площадки, наряду с проработкой оборудования. Стоит проверить реальную доступную мощность, очередь на присоединение и его ориентировочную стоимость, наличие резерва и альтернативы. Затраты на техприсоединение на дефицитной площадке могут составить заметную долю бюджета, поэтому этот вопрос прорабатывают до принятия решения о месте объекта.

Индикатор	Что отмечают отраслевые оценки	На чём основано
Обращения по ремонту и обслуживанию сетевого оборудования	рост примерно вдвое за 2025 год к 2024-му	оценки сервисных компаний, профильные публикации
Рост числа самих заказчиков за тот же период	лишь несколько процентов	там же
Динамика инцидентов	устойчиво растёт начиная с 2022 года	отраслевые наблюдения
Начало 2026 года	обращения продолжают расти месяц к месяцу	оценки участников рынка
Коммерческие ЦОД с авариями из-за износа	заметная доля – около каждого пятого	опросы интеграторов
Что чаще выходит из строя у «возрастного» железа	блоки питания, вентиляторы, линейные карты	сервисная практика
До какого срока бизнес продлевает службу техники	до 10-12 лет	оценки участников рынка
Доступность комплектующих и ЗИП	дефицит усилился с осени 2025 года	отраслевые оценки
Когда ждать нормализации	по разным прогнозам – не раньше чем через несколько лет	прогнозы сервисных компаний

 

Цифры собраны из открытых отраслевых публикаций и оценок участников рынка. Это ориентиры для понимания тренда, а не результаты измерений в какой-либо конкретной организации; у разных источников значения могут различаться.

 

⚠️ Что это значит для вашей инфраструктуры: если оборудованию 8-10 лет, оно работает без резерва и без ЗИП, а под ним – склад, касса, телефония или филиалы, вы находитесь ровно в той зоне риска, о которой говорят эти оценки. Вопрос не в том, случится ли отказ, а когда – и насколько управляемо вы его встретите.

 

---

 

 

 

---

 

Почему сети начали сыпаться

Причин несколько, и они складываются.

🚫 Оборудование стареет. Коммутаторы, маршрутизаторы и межсетевые экраны, купленные в 2015-2018 годах, физически дорабатывают ресурс. Электролитические конденсаторы, вентиляторы, блоки питания – у всего есть срок.

🚫 Запчасти и ЗИП для сетевого оборудования стали менее доступны. Где-то поставки удлинились, где-то усложнилась логистика, где-то отдельные позиции исчезли с прилавка. Деталь, которую раньше меняли за два дня, теперь ищут две недели.

🚫 Компании осознанно продлевают срок эксплуатации техники. Логика «работает – не трогай» понятна с точки зрения бюджета, но она же превращает критичный узел в мину замедленного действия.

🚫 Инфраструктуры стали гибридными. Часть сервисов уехала в облако, часть осталась на земле, добавились VPN до филиалов и удаленных сотрудников. Связность усложнилась, точек отказа стало больше.

🚫 В одной сети сосуществуют разные поколения и разные вендоры. Где-то еще стоит Cisco, рядом – оборудование других зарубежных производителей, поверх – то, что закупили на замену за последние пару лет. Получается «зоопарк оборудования», который тяжело обслуживать единообразно.

🚫 Документация часто устарела. Схема сети нарисована «как было три реорганизации назад», VLAN-ы и маршруты живут в голове одного инженера – а он в отпуске.

🚫 Мониторинг либо отсутствует, либо настроен формально. Система вроде есть, но сообщает о падении уже после того, как оно случилось. Первые симптомы – рост CRC, флапы линков – остаются невидимыми.

И почти везде один и тот же сценарий с ЗИП: его закупают после аварии, а не до нее.

Главная ошибка – считать сеть набором железок

Самая дорогая управленческая иллюзия звучит так: «сеть – это коммутаторы и маршрутизаторы, они либо работают, либо нет».

🌐 На самом деле корпоративная сеть – это система. В нее входят кабельная инфраструктура и патч-панели, электропитание и ИБП, охлаждение, оптика и трансиверы, конфигурации устройств, таблицы маршрутизации, схемы резервирования, мониторинг, документация и регламенты восстановления.

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

Именно поэтому отказ редко бывает «одной железкой». Чаще это технический долг в стойке, который копился и наконец предъявил счет.

Как понять, что сеть близка к отказу

Хорошая новость: усталость сети видна заранее, если знать, куда смотреть.

 Тревожные признаки:

• растущее число ошибок и потерь на портах;
• флапы линков, которые то поднимаются, то падают;
• перегрев оборудования, горячие зоны в стойке;
• непривычный шум вентиляторов или, наоборот, их остановка;
• частые незапланированные перезагрузки устройств;
• деградация uplink-канала, периодические потери пакетов;
• ошибки PoE, на которых «мигают» камеры и телефоны;
• жалобы пользователей на «иногда тормозит» и «само прошло»;
• отсутствие резервных конфигураций устройств;
• отсутствие актуальной схемы сети;
• отсутствие ЗИП по критичным узлам.

📝 Ни один из этих симптомов сам по себе не катастрофа. Но три-четыре вместе – это уже сеть, которая просит обслуживания, пока не потребовала ремонта.

Почему ремонт не всегда дешевле замены

🔧 Ремонт сетевого оборудования – нормальный инструмент. Но у него есть граница применимости.

Ремонт оправдан, если устройство еще поддерживается, к нему есть рабочий ЗИП или альтернатива, и при этом оно не единственная точка отказа. Заменить вентилятор или блок питания, обновить прошивку, перевести нагрузку – разумно и недорого.

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

Управляемая модернизация корпоративной сети отличается тем, что вы меняете оборудование по плану, в удобное окно, с предсказуемым бюджетом – а не в три часа ночи, когда встал склад. Разница между этими сценариями обычно измеряется не в стоимости железа, а в стоимости простоя ИТ-инфраструктуры.

Что проверить в первую очередь

Если нужна конкретика – вот рабочий чек-лист. Даже беглый проход по нему уже покажет слабые места:

• ядро сети – есть ли резерв, не держится ли всё на одном устройстве;
• агрегирующие коммутаторы и их аптайм;
• маршрутизаторы и актуальность конфигураций;
• межсетевые экраны – версии, поддержка, нагрузка;
• Wi-Fi-контроллеры и покрытие;
• uplink-каналы и их резервирование;
• оптические модули и трансиверы;
• блоки питания и ИБП;
• вентиляторы и охлаждение стоек;
• линейные карты в модульных устройствах;
• актуальные схемы сети;
• резервные копии конфигураций;
• мониторинг сетевой инфраструктуры – что он реально видит;
• ЗИП по критичным позициям;
• версии прошивок и известные уязвимости;
• явные точки отказа без резерва.

📝 Если хотя бы по трети пунктов ответ «не знаю» – это и есть ответ на вопрос, в каком состоянии сеть.

Как снизить риск без полной замены сети

✔ Менять сеть целиком нужно редко. Чаще задача – снять остроту риска поэтапно и в рамках бюджета. Рабочая последовательность:

✔ Аудит сетевой инфраструктуры – зафиксировать реальное состояние, а не то, что «должно быть по схеме».

✔ Классификация оборудования по уровню риска – где единичная точка отказа, где есть резерв, где нет ЗИП.

✔ Формирование ЗИП по критичным узлам – заранее, а не после инцидента.

✔ Обновление документации – схемы, конфигурации, контакты, регламенты.

✔ Настройка мониторинга, который ловит симптомы (CRC, температуру, флапы), а не только факт падения.

✔ План поэтапной замены и модернизации – сначала самое рисковое.

✔ Тестирование российских и альтернативных решений под замену зарубежного сетевого оборудования и замену Cisco – спокойно, в лаборатории, до боя.

✔ Регламент аварийного восстановления – кто, что и в каком порядке делает, когда всё уже упало.

Список устроен так, что первый шаг – аудит ИТ инфраструктуры – закрывает большую часть неопределенности. Без него остальные пункты делаются вслепую.

Когда действовать срочно

Есть ситуации, в которых откладывать уже опасно. Действовать стоит без промедления, если:

• ключевому оборудованию больше 8–10 лет;
• в критичных узлах нет резервирования;
• нет ЗИП для сетевого оборудования;
• участились жалобы пользователей и филиалов;
• растут ошибки на портах и флапы линков;
• сеть обслуживает склад, производство, кассы, телефонию, ЦОД или
• филиальную сеть;
• схемы сети не обновлялись больше года;
• оборудование снято с поддержки производителем;
• сеть собрана из разных вендоров без единого стандарта.

Чем больше пунктов совпало, тем меньше у вас запаса времени. И тем дороже обойдется сценарий «дождемся, пока само».

Сеть подает сигналы заранее – вопрос, кто их читает

❗ Сеть не падает внезапно. Она заранее показывает признаки усталости. Вопрос только в том, смотрит ли на них кто-то до аварии.

Большинство отказов, которые выглядят как «внезапные», на самом деле были предсказуемы за недели и месяцы. Их не увидели не потому, что инженеры плохие, а потому что сеть годами была невидимой для бизнеса: она работала – и на нее не смотрели.

✔ Самый дешевый способ узнать состояние своей инфраструктуры – посмотреть на нее целиком и заранее. Именно для этого СИНТО проводит комплексный аудит ИТ-инфраструктуры: мы проверяем серверы, сеть, рабочие места, 1С, ПО, доступы, лицензии, резервное копирование и базовую безопасность.

На выходе – понятный отчет, а не список непонятных метрик: где скрыты риски, что в первую очередь может остановить работу бизнеса, что нужно исправить сразу и какой бюджет потребуется, чтобы навести порядок. По итогам аудита мы помогаем сформировать ЗИП, настроить мониторинг сетевой инфраструктуры, выстроить сервисную поддержку ИТ-инфраструктуры и подготовить план поэтапной модернизации – без остановки бизнеса.

Если по этой статье вы узнали свою сеть хотя бы в нескольких пунктах – это уже повод посмотреть на нее внимательно. Лучше на аудите, чем на аварии.

Поэтому перед переходом лучше провести аудит программного обеспечения. Он помогает быстро понять:

✔ Какие продукты Adobe и ABBYY установлены на рабочих местах и серверах;

✔ Какие лицензии есть у компании и где есть расхождения с фактическим использованием;

✔ Какие сотрудники действительно работают с Acrobat, FineReader, Photoshop, Illustrator и другими программами;

✔ Какие данные нужно выгрузить из облачных сервисов до отключения;

✔ Какие решения можно заменить российскими аналогами без потери рабочих процессов;

✔ Где можно сократить расходы за счет отказа от неиспользуемых лицензий.

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

Куда переходить: взгляд в сторону российских решений

Если ваша компания использовала Adobe Acrobat для работы с PDF, OCR и документами. Один из вариантов для бизнеса – офисные решения на базе Content AI и продукт ContentReader PDF, который закрывает основные задачи документооборота: редактирование PDF, качественное OCR-распознавание сканов и фотографий документов, конвертацию сканов в редактируемые форматы.

В отличие от серых схем, это российское ПО из реестра отечественного ПО с русскоязычной технической поддержкой и понятным лицензированием – то, что особенно важно для бизнеса, который не может позволить себе остановку документооборота.

В экосистеме Content AI также есть решения для потоковой обработки документов, корпоративного поиска и встраиваемого распознавания. Такие задачи оцениваются отдельно. Подробнее о составе и сценариях применения можно почитать на странице решения Content AI.

Как мы помогаем с переходом

Главный страх любой компании при смене ПО – простой и потеря наработок. Поэтому важно не просто заменить программу, а выстроить процесс перехода так, чтобы сотрудники продолжали работать без перерывов.

Мы сопровождаем миграцию на всех этапах:

✔ Подбираем конфигурацию под реальные задачи компании, чтобы вы не переплачивали за лишний функционал.

✔ Оцениваем возможность переноса или воспроизведения прежних шаблонов, правил обработки и пользовательских сценариев

✔ Настраиваем рабочие сценарии – распознавание, редактирование, конвертацию и передачу документов в нужном формате.

✔ Обучаем сотрудников – короткие практические занятия, после которых персонал работает в новом ПО уже на следующий день.

Такой подход снимает с компании техническую и организационную нагрузку: переход проходит более управляемо и с меньшей нагрузкой на сотрудников.

Как сохранить работу с документами после ухода Adobe

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

Чем быстрее вы начнете переход, тем меньше будет последствий. Если хотите разобраться, какое решение подойдет именно вашей компании и как организовать миграцию в сжатые сроки, – посмотрите подробности о решении Content AI или свяжитесь с нами, и мы поможем оперативно решить задачу.