С 1 августа 2026 года стоимость реселлерских тарифов увеличится в среднем на 16%. Изменение коснётся как действующих, так и архивных тарифов:

• VDS-KVM-Реселлинг-5.0
• VDS-KVM-SSD-Реселлинг-5.0
• VDS-KVM-NVMe-Реселлинг-5.0
• VDS-KVM-Реселлинг-6.0
• VDS-KVM-SSD-Реселлинг-6.0
• VDS-KVM-NVMe-Реселлинг-6.0
• VDS-KVM-Реселлинг-7.0
• VDS-KVM-SSD-Реселлинг-7.0
• VDS-KVM-NVMe-Реселлинг-7.0
• VDS-KVM-Реселлинг-8.0
• VDS-KVM-NVMe-Реселлинг-8.0
• VDS-KVM-SSD-Реселлинг-8.0
• VDS-KVM-SSD-Реселлинг-9.0
• VDS-KVM-NVMe-Реселлинг-9.0
• VDS-KVM-SSD-Реселлинг-10.0
• VDS-KVM-NVMe-Реселлинг-10.0
• VDS-KVM-SSD-Реселлинг-2015
• VDS-KVM-Реселлинг-2015

Цена услуги будет зависеть от конфигурации тарифа. Итоговую стоимость можно узнать в Личном кабинете в день повышения цен — 1 августа 2026 года.

В системе KVM/x86 (Kernel-based Virtual Machine) ядра Linux была обнаружена уязвимость CVE-2026-53359, которая позволяет получить доступ к ресурсам хоста из гостевого окружения. Переход с гостевой системы на хост может произойти как на процессорах Intel, так и AMD.

Так как на платформе Advanced выключена вложенная виртуализация и используется аппаратная технология Extended Page Tables (EPT), влияние на платформу уязвимость не оказывает.

Что случилось
Уязвимость CVE-2026-53359 позволяет гостевой системе нарушить изоляцию среды виртуализации и повысить свои привилегии (guest to host escape) в среде KVM/x86. Насколько известно, это первая обнаруженная уязвимость, позволяющая использовать эксплойт перехода с гостевой системы на хост, который может быть активирован как на Intel, так и на AMD, а не только на одной архитектуре. Januscape — это уязвимость типа use after free в эмуляции ShadowMMU KVM/x86.

Подробное описание уязвимости
github.com/V4bel/Januscape/blob/main/assets/write-up.md
CVSS-рейтинг: на момент написания статьи не проставлен.

Влияние
Общее влияние:

• подвержен KVM, не зависит от QEMU;
• отключенная вложенная виртуализация (nested virtualization) сильно затрудняет эксплуатацию.

Влияния на сервисы и пользователей Yandex Cloud уязвимость не оказывает, поскольку:

• вложенная виртуализация (nested virtualization) выключена;
• аппаратная технология Extended Page Tables (EPT) включена.

Компенсационные меры
Мы применяем исправленные стабильные версии, выпущенные 04 июля 2026 года:

• 7.1.3
• 6.18.38
• 6.12.95
• 6.6.144
• 6.1.177
• 5.15.211
• 5.10.260.

Идентификатор CVE (CVE ID): CVE-2026-53359

Ссылка на CVE www.cve.org/CVERecord?id=CVE-2026-53359
Ссылка на NVD nvd.nist.gov/vuln/detail/CVE-2026-53359

В сервисе облачных баз данных Servercore появился ClickHouse — управляемая аналитическая СУБД для обработки данных в реальном времени (OLAP). Она выполняет SQL-запросы со сложными вычислениями по большим массивам.

ClickHouse подойдет, если нужно быстро считать по большим объемам

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

На нем удобно строить дата-платформы: ClickHouse подходит для корпоративного хранилища данных в концепции DWH (Data Warehouse), а нативная интеграция с S3 и Apache Iceberg позволяет выстраивать архитектуру Data Lakehouse (DLH).

Что важно знать

• кластером можно управлять через панель управления или Managed Databases API;
• доступны шардирование и отказоустойчивый кластер с репликацией данных;
• конфигурацию групп нод — vCPU, RAM и диск — вы выбираете под свой профиль нагрузки;
• администрирование СУБД мы берем на себя.

Сейчас ClickHouse работает в режиме бета-тестирования — попробуйте и поделитесь обратной связью.
servercore.com
docs.servercore.com/ru/managed-databases/clickhouse/

Кампания по выпуску патчей для CVE-2026-53359 (Januscape): Уроки, извлеченные из устранения уязвимости KVM на десятках тысяч машин



Уязвимость в подсистеме виртуализации.
Во вторник, 7 июля, в начале дня было выпущено предупреждение о безопасности, касающееся уязвимости CVE-2026-53359, связанной с использованием памяти после освобождения (use-after-free), затрагивающей подсистему теневой подкачки KVM x86 в ядре Linux. Уязвимость, обнаруженная несколько лет назад, была обнародована 6 июля; сообщения в блогах других облачных провайдеров появились еще 7 июля.

KVM — это механизм виртуализации, используемый в подавляющем большинстве экземпляров, размещенных в OVHcloud. Механизм работает следующим образом: при внешнем изменении записи каталога страниц (PDE) запись RMAP может сохранить ссылку на уже освобожденную страницу памяти. Затем ядро ​​разыменовывает эту устаревшую страницу, что может привести к сбою гипервизора или, в худшем случае, к повышению привилегий на стороне хоста. Эксплойт воспроизводим: внутренний тест на незащищенном хосте вызывает сбой примерно через две минуты.

Все ядра x86 Linux, выпущенные до внесения изменений в патч, затронуты независимо от дистрибутива. Официальный патч был перенесен в наши производственные ядра Debian.

Необходимо учитывать три основных риска:

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

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

Предлагаемые варианты снижения риска


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

2: Обновление для текущей версии игры
Для применения «живого» патча необходимо включить соответствующую опцию в конфигурации ядра. По своей сути, это позволяет изменять его поведение «на лету», тем самым снижая уровень защиты и ограничивая возможности обнаружения в случае компрометации. Кроме того, применение «живого» патча — это по своей сути деликатная процедура, которая может привести к нестабильности всей системы. Это вариант, позволяющий выиграть время в ожидании окончательного решения. Мы отказались от этого компромисса, который значительно увеличил бы риск захвата хоста в случае публикации эксплойта.

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

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

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

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

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

Группа по управлению кризисными ситуациями переключается на мониторинг развертывания, после чего ее возглавляет Центр сетевых операций (NOC), который берет на себя роль оперативного координатора: отслеживает общий прогресс, расставляет приоритеты задач между регионами и сервисами и поддерживает всесторонний обзор. Выполнением занимаются эксперты по публичным облакам и VPS, которые управляют перезагрузками, миграцией в режиме реального времени и ограничениями антиаффинности. Разделение между координацией и выполнением является преднамеренным: NOC координирует, а оперативные группы действуют и сообщают метрики и технические события, необходимые для координации.

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

Работа осуществляется по принципу «следуй за солнцем», при этом ячейка работает круглосуточно и без выходных, поочередно меняя географические зоны. Ежедневно проводятся три точки синхронизации, охватывающие переходы между зонами. В этих точках собираются представители центра управления сетью (NOC), оперативные эксперты, служба поддержки и служба безопасности для: обмена информацией о ходе работ по регионам, передачи информации между зонами (что сработало, корректировки процедур на основе отзывов с мест) и определения приоритетов следующего этапа.

В состав этого комплексного подразделения круглосуточно и без выходных входят: команды по разработке ядра и виртуализации (анализ патчей, обратная совместимость, проверка), VPS и публичное облако (развертывание), NOC (управление), Run & SRE (оркестрация, антиаффинность, миграция в реальном времени), операционная деятельность центров обработки данных (ремонт оборудования), служба поддержки клиентов (запросы клиентов), служба безопасности (мониторинг, периметр, завершение работы) и коммуникационная служба (прозрачность, целевые уведомления).

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

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

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

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

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

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

Среда, 8 июля: вылет из Сиднея.
Выбор Сиднея для тестирования развертывания не представляет сложности: количество хостов ограничено, а локальное окно развертывания HNO (ночная смена) совпадает с рабочим временем команд в Европе. Начало работы с самого восточного региона позволяет:

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

Первые волны обновлений и перезагрузок были применены к VPS- хостингам в Австралии. В регионе SYD2 установка прошла без происшествий в начале дня (по парижскому времени). Процедуры корректируются на основе отзывов с мест.

Как только ситуация стабилизируется, применяется подход « следуй за солнцем»: каждый регион по очереди принимает управление, сообщая о местной ситуации следующему региону утром. Первая европейская волна (RBX, GRA6, WAW, DE, SBG, MIL, UK) запускается в тот же вечер, в 18:30 по парижскому времени.

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

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

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

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

Пороги остановки и управление темпом
Каждая волна перезагрузки подчиняется пороговому значению для завершения процесса: если количество одновременно вышедших из строя хостов превышает заданный порог, волна приостанавливается. Этот порог установлен на уровне 15 хостов для регионов с высокой плотностью (GRA, RBX, BHS) и на уровне 5 хостов для остальных. Завершение процесса также запускается в 6:00 утра или по запросу из местного центра обработки данных.

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

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

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

Этот подход, исключающий привязку к конкретному серверу, применяется по мере возможности: он соблюдается в большинстве случаев, но не может быть гарантирован на 100% по всей сети. Цель остается неизменной — распределить воздействие таким образом, чтобы оно было управляемым на стороне приложения. Клиенты, чьи экземпляры зависят от одного хоста, испытывают временный сбой, время которого объявляется заранее.

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

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

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

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

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

Виртуальные машины не перезапускаются после перезагрузки хоста.
Первый крупный инцидент произошёл во время начальной европейской волны: виртуальные машины не перезапускались после перезагрузки гипервизора. Nova Compute сообщала о «самостоятельном завершении работы экземпляра» без синхронизации. Первопричина была выявлена ​​на второй день: служба libvirt-guests конфликтовала с Nova Compute и останавливала экземпляры при перезагрузке без синхронизации API. Решение заключалось в отключении и скрытии службы libvirt-guests.service на хостах перед перезагрузкой. После этого исправления автоматический перезапуск виртуальных машин заработал.

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

API в случае взаимоблокировки в Париже
В ночь со второго на третий день API Nova и Neutron в Париже оказались в тупиковой ситуации: API Neutron (с ограничением в 10 процессов) был перегружен резким увеличением запросов Nova, в результате чего в течение примерно двух часов возвращались ошибки HTTP 503. Решение заключалось в увеличении количества рабочих процессов Neutron с 10 до 30 и количества процессов Apache с 10 до 32. Работа зоны B в Париже и Милане была отложена до стабилизации ситуации.

Поддержка насыщения в BHS
На площадке BHS (Канада) трафик API превысил обычный пик в 10 раз, что перегрузило менеджера и службы поддержки. Некоторые клиенты обнаружили последствия еще до получения официального уведомления. Этот случай наглядно иллюстрирует цепную реакцию внутри инфраструктуры.

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

Восстановление после перезагрузки и аппаратные вмешательства
Перезагрузка десятков тысяч машин также включает в себя аппаратный аспект. Любая перезагрузка сервера сопряжена с определенным уровнем отказов. В первую ночь примерно 20-30 хостов из 6000 не восстановились самостоятельно: неисправные модули памяти, проблемы с конфигурацией BIOS, неактивные сетевые интерфейсы. В Соединенных Штатах для восстановления работы нескольких хостов потребовалось извлечение батареи CMOS и разрядка батареи — это повторяющаяся аппаратная проблема.

На каждом объекте в качестве подкрепления на время кампании задействованы технические специалисты центров обработки данных. Их роль:

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

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

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

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

Изначально было принято решение не создавать публичную страницу состояния, чтобы избежать раскрытия последовательности развертывания. Коммуникация осуществляется через целевые каналы на нашем портале поддержки, электронные письма отправляются клиентам с уровнями поддержки Business и Enterprise.

Наблюдение: некоторые сообщения не доставляются.
Инструменты коммуникации имеют технические ограничения. Для регионов с большим объемом обращений, таких как GRA6 (почти 90 000 клиентов, с которыми не удалось связаться), массовая рассылка электронных писем исключена во избежание увеличения количества обращений в службу поддержки.

В связи с этой ситуацией на второй день было принято решение изменить подход: внедрить в Менеджере условный баннер с помощью переключения функций — если авторизованный пользователь находится в списке затронутых учетных записей клиентов (NIC), отображается информационное сообщение. Разработка была завершена в тот же день, а баннер был развернут на третий день. В это же время была создана страница состояния публичного облака.

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

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

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




Перспективы
Уязвимость CVE-2026-53359 поставила под угрозу наших клиентов и инфраструктуру. План по смягчению последствий привел к негативному влиянию на клиентов — локальному, последовательному и объявленному, но реальному. Более подробное информирование в ходе выполнения плана по смягчению последствий, пока инфраструктура оставалась без обновлений, значительно увеличило бы риск для наших клиентов, потенциально побудив некоторых из них «протестировать» общедоступную уязвимость.

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

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

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

Мы заметили, что у вас пока нет активных услуг в «Макхост». Ваш надежный и производительный виртуальный сервер уже ждёт — запустите проект в Европе или России на выгодных условиях.

Выберите локацию под свои задачи с оплатой в рублях и usd

• Европейский VPS — для западной аудитории: низкая задержка, стабильный канал, все ресурсы доступны.
• Российский VPS — для локальных проектов: быстрый доступ из РФ.

Почему выбирают нас

• Полный root-доступ и KVM-виртуализация — выделенные ресурсы без влияния соседей.
• Бесплатный перенос сайтов от другого хостера + месяц в подарок.
• Оборудование Dell с NVMe-дисками в дата-центрах Tier III.
• Готовность сервера через 1 минуту после оплаты.
• Русскоязычная поддержка 24/7 — ответ до 15 минут.
• Бесплатная лицензия ispmanager 6 на 1 месяц.
• Оплата в рублях (карты любой страны, СБП, переводы) со скидкой до 40% за год.
• Попробуйте перед покупкой: 3 дня тестового периода.

Гибкость и контроль
Доступны любые ОС: AlmaLinux, CentOS, Debian, Ubuntu. Устанавливайте панели управления (ispmanager, fastpanel), настраивайте сервисы, изменяющие параметры сетевого соединения, почтовые серверы, tg-боты, высоконагруженные приложения.

mchost.ru/services/linux-vps/europe/

Иногда достаточно нескольких дней работы, чтобы понять: этот VPS подходит вашему проекту
Именно поэтому мы предлагаем бесплатный тест.

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

В Majordomo доступны VPS в Сербии с 6 днями бесплатного тестирования. Выберите подходящую локацию, протестируйте сервер и принимайте решение уже после проверки в работе.



Почему выбирают VPS от Majordomo?

• 6 дней бесплатного тестирования — проверьте сервер до оплаты.
• Площадки в России и Европе — выбирайте локацию под задачи проекта.
• Поддержка 24/7 — помощь специалистов в любое время.

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

majordomo.ru

Январь 2026 — месяц короткий, с долгими праздниками, но для наших подмосковных строек он стал не менее значимым, чем любой другой. В то время как многие только возвращались к рабочим ритмам, в Марфино кипела работа.

• Марфино: пусконаладка началась, а главное — объект получил первую «официальную» мощность в 150 кВт!
• Проектирование: активно ведутся работы по основным ЦОДам на обеих площадках.
• Газовый проект: поданы на финальное согласование уточнённые технические условия.

Марфино: контейнерный ЦОД оживает
Январь принёс долгожданный переход от строительства к вводу в эксплуатацию первой очереди.

Пусконаладка: наш ЦОД в действии
На площадку прибыла и начала работу бригада специалистов от поставщика контейнерного ЦОД для проведения пуско-наладочных работ (ПНР). Это ключевая фаза, когда все инженерные системы начинают проверяться, настраиваться и работать в комплексе. Уже сейчас внутри нашего первого контейнера установлены аккумуляторные батареи — основа системы бесперебойного питания (ИБП). Работа по запуску объекта началась.


Энергия: первая мощность подана
Самое важное событие месяца, которого мы долго ждали: осуществлено техническое присоединение электрической мощности в 150 кВт. Рубильник включён, напряжение подано на объект. Можно сказать, что у первого контейнерного ЦОДа теперь есть официальный «пропуск» в энергосистему.


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

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

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

• Марфино: на площадку доставлены и размещены 6 установок холодоснабжения для первого этапа капитального строительства ЦОД.
• Безопасность: заключён договор на пультовую охрану КПП в Марфино.
• Энергоснабжение: подписан договор с МОСЭНЕРГОСБЫТ на 150 кВт.
• Проектирование: получена проектная документация стадии П по ЦОД Мытищи (1 этап), проработаны планировочные решения ЦОД 1 Марфино.

Марфино: холод для серверов
Одно из ключевых событий месяца — поставка, разгрузка и размещение на площадке партии установок холодоснабжения в количестве 6 единиц. Оборудование будет находиться здесь на хранении до завершения возведения бетонного каркаса капитального здания ЦОД, после чего мы выполним его монтаж на крыше. Установки холодоснабжения обеспечат отвод тепла от серверного оборудования — без эффективного охлаждения ни один дата-центр работать не может, так что их появление на площадке — важное событие.

Безопасность: КПП под охраной
Дата-центр — это не только серверы и кабели, но и физическая безопасность. В феврале мы заключили договор на пультовую охрану здания КПП в Марфино с частным охранным предприятием. На объекте установлены и активированы тревожные кнопки для вызова группы быстрого реагирования. Теперь территория находится под профессиональным контролем — ещё один шаг к полноценной эксплуатации площадки.


Энергоснабжение: договор с МОСЭНЕРГОСБЫТ
Напомним, что ранее было осуществлено техническое присоединение мощности 150 кВт. В феврале мы закрепили этот результат юридически — заключён договор энергоснабжения с МОСЭНЕРГОСБЫТ. Если техприсоединение было «пропуском» в энергосистему, то договор — это уже официальное закрепление отношений с энергосбытовой компанией. Контейнерный ЦОД получил стабильную правовую основу для электроснабжения.

Проектирование: движение по двум фронтам
ЦОД Мытищи
Важная новость для второй площадки: от инженерной компании получена проектная документация стадии П по объекту «ЦОД Мытищи» (1 этап). Стадия П — это основные проектные решения, на базе которых далее разрабатывается рабочая документация. Получение этого пакета означает, что проект переходит из концептуальной фазы в предметную.
ЦОД 1 Марфино
Параллельно проработаны схема планировочной организации земельного участка и планировочные решения первого капитального ЦОД в Марфино. По сути, определено, как именно будет организовано пространство: где встанут здания, как пройдут коммуникации, какой будет логистика на территории. Это фундамент, от которого зависят все последующие разделы проекта.

Итого за февраль — месяц получился по-настоящему многоплановым. На площадке в Марфино появилось критически важное инженерное оборудование и обеспечена физическая охрана, оформлен договор энергоснабжения, а проектирование капитальных ЦОДов продвинулось сразу на двух площадках. Контейнерный ЦОД в Марфино с мощностью 150 кВт всё ближе к полноценному запуску.

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

• Марфино: наш первый КЦОД на 10 стоек по 12 кВт прошёл пусконаладку и готов к работе. Принято оборудование холодоснабжения из Китая. На заводе в Самаре принято оборудование системы энергоснабжения.
• Мытищи: проектная документация проверена, назначена встреча с городской администрацией по техусловиям.

Марфино: КЦОД введён в эксплуатацию
Главное событие месяца — завершение пусконаладочных работ нашего первого контейнерного ЦОДа. Объект полностью подключён и готов принимать клиентов. Напомним параметры: 10 серверных стоек с мощностью 12 кВт на стойку, что суммарно даёт IT-нагрузку в 120 кВт. В итоге мы получили полноценный компактный дата-центр, подходящий для colocation и размещения облачной инфраструктуры.
Чуть более года нам потребовалось, чтобы пройти путь от пустыря со старыми заброшенными зданиями до работающего ЦОДа. Модульный формат позволил существенно сократить сроки — и теперь объект в Марфино готов к работе, а рядом будет строиться капитальное здание ЦОД.


Холодоснабжение: оборудование из Китая принято
Выполнена поставка и приёмка оборудования систем холодоснабжения, произведённого в Китае. Установки прибыли на площадку и будут храниться до завершения строительства бетонного каркаса капитального здания ЦОД, после чего займут своё место на крыше. Система охлаждения — один из критически важных элементов инфраструктуры дата-центра: именно от неё зависит, сможет ли оборудование работать в штатном температурном режиме круглый год, включая периоды летних пиковых нагрузок.

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

Дизель-генераторные установки: три ДГУ готовы к отправке


ДГУ — Yuchai ДЭС (ДГУ) представляет собой блок-контейнер, в котором смонтированы дизель-генераторная установка MVAE1800YCО/A (Китай) нагрузки.

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

Апрель стал месяцем, когда проект в Марфино окончательно перешёл из категории «стройка» в категорию «работающая инфраструктура». Контейнерный ЦОД прошёл боевое крещение — причём не только плановыми испытаниями, но и реальными аварийными отключениями энергии. А на площадке продолжает поступать оборудование для капитального здания. Обо всём по порядку.

• КЦОД: контейнерный ЦОД работает в штатном режиме. Резервный дизель-генератор прошёл проверку реальными отключениями энергии. Проводим показы и общаемся с потенциальными клиентами.
• Энергетика для капитального ЦОД: доставлены 3 дизельные электростанции по 1,3 МВт. Доставлены и размещены 2 из 3 газопоршневых установок.
• Газ: идёт проектирование газового подключения, в мае проект уходит на согласование в Мособлгаз.

КЦОД: боевое крещение
В марте мы сообщали о завершении пусконаладки контейнерного ЦОД на 10 стоек по 12 кВт. Теперь можно сказать: КЦОД работает. Объект полностью функционален и готов к размещению клиентского оборудования.

Как проверяли надёжность
Во время пусконаладки мы многократно тестировали сработку резервного дизель-генератора мощностью 200 кВт, который был специально закуплен для КЦОД ещё осенью 2025 года. Сценарий простой: имитация отключения внешнего питания — и проверка, запустится ли генератор в штатном режиме.

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

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

Первые показы и обратная связь
КЦОД уже вызывает интерес у рынка. Мы проводим показы объекта потенциальным клиентам и общаемся с компаниями дистанционно. Вопросы типичные и предметные: соответствие требованиям уровня Tier III, доступная мощность, наличие резервного питания, тип охлаждения. По всем пунктам КЦОД отвечает требованиям: резервное питание проверено в реальных условиях, охлаждение — фрикулинговое.

Энергетика капитального ЦОД: дизель и газ
Пока КЦОД работает на своём компактном дизель-генераторе мощностью 200 кВт, для будущего капитального здания ЦОД формируется серьёзная энергетическая инфраструктура. И здесь за апрель произошло сразу несколько событий.

3 дизельные электростанции: резервное питание
На площадку в Марфино доставлены и разгружены 3 дизельные электростанции (ДЭС) в контейнерном исполнении. Мощность каждой — 1 300 кВт. Суммарная резервная мощность — 3,9 МВт. Каждая ДЭС (ДГУ) оснащена топливным баком на 10 тонн, что обеспечивает автономную работу при полной нагрузке в течение 30–36 часов.



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



2 газопоршневые установки: основное питание
Ключевая новость в энергетике: на площадку в Марфино доставлены и размещены 2 из 3 газопоршневых установок (ГПЭС). Они стоят на площадке хранения рядом с ДЭС. Третья ГПЭС (ГПУ) находится на этапе изготовления — её пакетируют и оборудуют на заводе.


Важно понимать распределение ролей: ГПЭС — это основной источник электроснабжения капитального ЦОД, а ДЭС — резервный, на случай аварий. Такая схема позволяет обеспечить и экономическую эффективность (газ дешевле сетевого электричества), и надёжность (дизель подхватит нагрузку при любом сбое).

Газовое подключение: проект на финише
Газовая труба проходит по границе участка — подведение с нуля не требуется. Сейчас завершается проектирование газового подключения от существующей трубы к нашим потребителям. Технические условия были скорректированы. В мае проект уходит на согласование в Мособлгаз, после чего — сразу прокладка. Подрядчик определён и ждёт отмашки.

Масштаб капитального ЦОД: первые цифры
Раз мы заговорили об энергетике, стоит обозначить масштаб того, что строится. Планируемая мощность первого модуля капитального ЦОД — 4 МВт, разделённая на два машинных зала по 2 МВт каждый. Строиться будет весь модуль целиком, но запуск начнётся с первого машинного зала. Это позволяет ввести объект в эксплуатацию быстрее, а второй зал наращивать по мере заполнения первого.

Для сравнения: действующий контейнерный ЦОД — это 120 кВт IT-нагрузки. Первый машинный зал капитального здания — 2 МВт. Разница в масштабе — более чем в 16 раз.

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


А что с Мытищами?
Напомним, что параллельно мы строим второй ЦОД — в Мытищах. В этом выпуске он остался за кадром: ключевые события апреля происходили в Марфино. Как только в Мытищах начнётся активная фаза — мы посвятим этому отдельный материал.

Итого за апрель
Контейнерный ЦОД в Марфино прошёл проверку реальными аварийными отключениями и работает в штатном режиме. Для капитального здания ЦОД мощностью 4 МВт на площадке уже находятся 3 дизельные электростанции суммарной мощностью 3,9 МВт (резерв на 30–36 часов автономной работы) и 2 из 3 газопоршневых установок (основное питание). Газовый проект выходит на согласование. Масштаб растёт.

Если апрель был месяцем энергетики, то май стал месяцем связи и масштаба. У площадки в Марфино появилась «нервная система» — мы проложили магистральный оптический кабель и выстраиваем сразу несколько независимых вводов. А ещё утвердили генплан целиком, и теперь видно, во что вырастет площадка на бумаге: шесть модулей и до 24 МВт. Параллельно закрыли вопрос автономности по топливу и сдвинули с места фундаменты под энергоцентр. Обо всём по порядку.

• Связь: проложен подземный бронированный кабель на 48 волокон (2,5 км) от КЦОД до магистрали на Дмитровском шоссе. Готовим до трёх независимых вводов.
• Генплан: утверждён мастер‑план площадки — 6 модулей, суммарно до 24 МВт. Идёт проектирование (стадия П).
• Энергетика: приступаем к устройству фундаментов под ДГУ и ГПУ; третья ГПУ — на заводе, доставка в конце июля; газовый проект уходит на согласование.
• Топливо: заключены два договора на поставку дизтоплива; экстренная доставка — до 8 часов.
• Мытищи: иной формат — изначально крупный ЦОД на 40 МВт из двух зданий, без модульной схемы.

Связность: у Марфино появляется «нервная система»
ЦОД без связи — это просто здание с серверами. Поэтому мы вплотную занялись оптикой. И сразу закладываем не один канал, а несколько независимых вводов — с запасом по надёжности, чтобы доступность площадки не зависела от одной‑единственной трассы.

Первый ввод: магистральный кабель уже в земле
Мы проложили подземный бронированный оптический кабель на 48 волокон от контейнерного ЦОД до оптических магистралей вдоль Дмитровского шоссе. 2,5 км — это всё расстояние до магистрали, кабель уложен полностью. Со стороны КЦОД он уже сварен и заведён внутрь контейнерного ЦОД. Этот ввод мы реализуем с оператором ООО «Наука‑Связь».

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



Второй ввод: телеком‑канализация от «Марафона»
Параллельно, по другой стороне дороги, проектируется телекоммуникационная канализация — её по государственному проекту тянет компания ООО «Марафон» из Дубны в Москву. Для нас уже утверждён проект ответвления: канализацию доведут прямо на наш участок, и в ней пойдёт ещё один 48-волоконный кабель. Реализация — до конца года, договор техприсоединения уже готовим.

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

Третий контур — резерв
Сейчас в работе есть и воздушный кабель на 12 волокон (тоже от «Науки‑Связи»). Пока он выступает как второй, резервный канал. Когда «Марафон» доведёт свою канализацию, воздушка станет третьим контуром — либо мы откажемся от неё совсем.

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

Генплан: проявился полный масштаб
Мы утвердили мастер‑план площадки целиком — и теперь можно показать, во что вырастет Марфино. Проектом предусмотрено шесть модулей: три отдельных типовых и один «тройной», эквивалентный ещё трём. Каждый модуль — это два машинных зала по 2 МВт, то есть 4 МВт на модуль. Суммарно сейчас запроектировано 24 МВт.

Для сравнения: действующий контейнерный ЦОД — это около 120 кВт IT‑нагрузки. Полная площадка по генплану — 24 МВт. Разница в масштабе — двухсоткратная.

Кроме самих зданий ЦОД с админ‑блоком, генплан расставил всю обвязку площадки:

• два въезда;
• энергоцентр (ГПУ и ДГУ);
• КПП с переговорной;
• резервуары сброса топлива;
• резервуары пожаротушения;
• парковку для клиентов.

Зачем нужен «типовой» модуль. Утверждённая планировочная структура первого модуля становится шаблоном для остальных: те же материалы, те же работы, единый энергоцентр на всех. Это заметно ускоряет и удешевляет строительство следующих зданий — не нужно каждый раз проектировать с нуля.

Что внутри первого модуля
Сейчас проектирование здания идёт на стадии П. Уже определены ключевые параметры первого модуля: два машинных зала по 150–153 стойки в каждом, мощность одной стойки — до 15 кВт. Здание в 2–3 этажа (третий — технический). Охлаждение — фрикулинг с принудительным насосом для доохлаждения.



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

• Устройство фундаментов под ДГУ и ГПУ — начинается. Подрядчик есть, на местности наносят координаты, работы стартуют со следующей недели. Напомним: летом установки должны занять свои штатные места.
• Третья ГПУ — пока на заводе. Её доставку на площадку ждём в конце июля. Две из трёх уже в Марфино (об этом писали в части 15).
• Газ — на пороге согласования. Проект газового подключения только уходит на согласование, сама прокладка ещё не началась: сейчас на стадии заключения договора на прокладку.

Топливо: автономность закрыта договорами
В части 15 мы рассказывали про три дизель‑генераторные установки (ДГУ) с баками по 9–10 тонн — это 30–36 часов автономной работы под полной нагрузкой. В мае мы закрыли логичный следующий вопрос: а что будет, когда баки начнут пустеть?

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

Почему это важно. Баков ДГУ хватает на 30–36 часов, а экстренная доставка укладывается в 8 часов. То есть подвоз успевает прийти задолго до того, как топливо закончится — автономность фактически становится неограниченной. Поэтому отдельное топливохранилище на площадке не требуется: запас в самих баках ДГУ большой. Поставщиков выбирали по круглосуточному приёму заявок, скорости доставки, опыту и наличию транспорта как большого, так и малого объёма. Пока, к слову, заправляли только небольшой ДГУ контейнерного ЦОД.

А что с Мытищами?
Второй наш ЦОД — в Мытищах — пока остаётся на стадии П, и подробности будут уже в следующем выпуске. По формату это принципиально иной объект, чем Марфино: не модульная схема, а изначально крупный ЦОД. Планируемая мощность — 40 МВт, в двух основных зданиях, расположенных более плотно. Как только начнётся активная фаза, посвятим Мытищам отдельный материал.

Заглянем внутрь КЦОД
Пока на площадке разворачивается большая стройка, контейнерный ЦОД в Марфино уже работает. Под конец — кадры изнутри: вот как он выглядит, пока рядом растёт капитальное здание.



Итого за май
Май добавил проекту в Марфино то, без чего ЦОД не работает, — связность. Магистральный кабель на 48 волокон уже в земле, врезка в магистраль — вопрос пары недель; параллельно готовятся ещё два независимых ввода, включая канализацию от «Марафона». Утверждённый генплан показал полный масштаб: 6 модулей и до 24 МВт. Приступаем к фундаментам под энергоцентр, газовый проект выходит на согласование, а два договора на топливо с доставкой до 8 часов фактически снимают потолок автономности. По Мытищам прояснился формат — крупный ЦОД на 40 МВт. Площадка обрастает инфраструктурой.

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

Каким будет ЦОД
Напомним масштаб. Участок — более 8,2 га. По утверждённому мастер-плану на площадке предусмотрено шесть модулей ЦОД: три отдельных типовых и один «тройной», эквивалентный ещё трём. Каждый модуль — это два машинных зала по 2 МВт, то есть 4 МВт на модуль; суммарно по генплану запроектировано 24 МВт. Подробно мастер-план мы разбирали в 16-й части.

Первая очередь — это один типовой модуль (здание №1 на генплане). Его характеристики:

• примерно 300 ИТ-стоек в модуле (150–153 в одном машинном зале, залов два);
• мощность стойки — в среднем около 10 кВт, до 15 кВт;
• энергопотребление модуля — до 4 МВт (два машинных зала по 2 МВт).

Фрагмент генплана. Первая очередь строительства — в границах голубого контура. Типовой модуль ЦОД выделен розовым. Слева — КПП, ДГУ и ГПУ.


Таким образом, модуль первой очереди — это примерно 300 ИТ-стоек и до 4 МВт (два машинных зала по 2 МВт). На старте запускается один машинный зал — 150–153 стойки и 2 МВт, затем второй. Утверждённый типовой модуль становится шаблоном для остальных: те же материалы, те же работы и единый энергоцентр на всю площадку — это заметно ускоряет и удешевляет строительство следующих зданий. Соответственно, «тройной» модуль — это порядка 900 стоек и до 12 МВт.

По технико-экономическим показателям корпус — двухэтажное здание общей (наземной) площадью 3 698,11 м², без подземной части. Суммарная поэтажная площадь в габаритах наружных стен составляет 4 166,79 м², строительный объём выше отметки 0,000 — 22 536 м³.

Резервирование оборудования всех систем — от N+1 до 2N в зависимости от системы. Заложена возможность полностью автономной работы ЦОД. К проектированию и последующей эксплуатации привлекаются команды специалистов с опытом реализации проектов в ЦОДах из ТОП-10 России.

Отметим, что на площадке уже действует контейнерный ЦОД (КЦОД) — всепогодный утеплённый контейнер конфигурации Tier III, о запуске которого мы рассказывали ранее. Строящееся основное здание проектируется под более высокий уровень надёжности — Tier IV.

Энергоцентр: шесть фундаментов и первые мегаватты
Главное событие месяца — старт работ по фундаментам энергоцентра. Энергоцентр единый на всю площадку: проектом первой очереди предусмотрено до пяти газопоршневых установок (ГПУ) и пяти дизель-генераторных установок (ДГУ). В июне залиты фундаменты под первые шесть установок — по одному под каждую из трёх ГПУ и трёх ДГУ.


Каждый фундамент — это плита на сваях, по 8 свай глубиной 2,5 метра. Конструкцию проектировщик рассчитывал индивидуально, исходя из параметров конкретного оборудования и характеристик грунта. К концу отчётного периода бетон в сваях уже залит; на заливку приезжала строительная лаборатория и проверяла соответствие параметрам. Следующие шаги — подготовка подушек и заливка плит.

Собственная генерация этой первой партии установок — 6,9 МВт: три ГПУ по 1 МВт и три ДГУ по 1,3 МВт. Далее мощность энергоцентра наращивается по мере ввода оставшихся установок и модулей ЦОД. Газовая труба рассчитана с расчётом на перспективу, поэтому запас по мощности заложен изначально.

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

Газоснабжение
Газовое проектирование завершено, и проект уходит на согласование в Мособлгаз. Определились и цифры. Максимальный расход газа на первом этапе — 821 м³/ч, фактическое давление — 0,38 МПа. Проектируемый подземный газопровод — более 600 метров.

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

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

Инженерные решения и безопасность
Помимо энергетики, проект задаёт и «начинку» будущего ЦОД.

Охлаждение — фрикулинг (свободное охлаждение наружным воздухом) с принудительным насосом для доохлаждения: энергоэффективное решение, рассчитанное на надёжную работу под нагрузкой. Отказоустойчивость обеспечивается резервированием всех систем от N+1 до 2N; электропитание дублируется ИБП и дизель-генераторами с собственным топливохранилищем.

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

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

Связность: оптика врезана в магистраль
По внешним каналам связи июнь принёс осязаемый результат: подземный оптический кабель уже врезан в магистраль «Наука-Связь». Воздушная линия при этом продолжает работать как резервная. Третий, дополнительный ввод — телекоммуникационная канализация от «Марафона» — пока на стадии проектирования; его ждём к концу года. Тогда связность площадки выйдет на три независимых маршрута. Линии заведены и на уже действующий КЦОД, и на строящееся основное здание.



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

Проектная документация и экспертиза
Проектная документация по Марфино готова на 95%. Оставшиеся части незначительны — например, согласование архитектурно-градостроительного облика (АГО), которое изначально в договор не входило. Сейчас заключаются договоры на экспертизу и на АГО. На экспертизу планируется выйти в июле; сама процедура занимает 30 дней, а дальнейшие сроки будут зависеть от наличия или отсутствия замечаний.

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



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

Что дальше
Ближайшие вехи — заливка плит фундаментов энергоцентра, выход проекта на экспертизу в июле и получение согласований в Мособлгазе. К концу года ожидается третий ввод оптики от «Марафона».

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

Российская технологическая компания Рег.ру зафиксировала сдвиг в ИТ-потреблении российского бизнеса: «цифровая корзинка» сервисов за два года сместилась от базового набора — домена, сайта и почты — к сложной инфраструктуре: облачному резервированию, выделенным серверам, Bare metal и GPU. Компания проанализировала спрос на облачные и инфраструктурные решения в Рег.облаке и онлайн-сервисах для предпринимателей Рег.решения и выяснила, какие цифровые инструменты используют компании в России на разных этапах развития.

По оценке экспертов Рег.решений, в 2025 году бизнес зарегистрировал в зонах .ru и.рф порядка миллиона доменов. А за первое полугодие 2026 года почти 600 тысяч. В первый год работы на 38% новых доменов уже размещается сайт, 36% используется корпоративная почта. Среди доменов с сайтом у 65% подключены SSL/TLS-сертификаты, аналитические системы стоят лишь у 4%, системы управления содержимым сайта (CMS) — у 3%. Базовый онлайн для бизнеса уже стал стандартом: компании регистрируют домен, запускают сайт, подключают почту и защищают соединение. Следующий этап цифрового развития связан с управлением эффективностью этого присутствия — подключением аналитики, CMS и инструментов для работы с клиентским потоком.

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

дополняет Иван Грибов, директор по развитию продуктов для предпринимателей Рег.решения.

В публичном облаке спрос смещается от запуска проектов к управлению инфраструктурой. У микрокомпаний среди используемых сервисов доминируют внешние IP — 50,3%, вычислительные мощности — 31,8%. У малого бизнеса — доля снапшотов 35,2%, у среднего — 37%: это подтверждает активный переход к резервированию. Следующий шаг для более зрелых компаний — не только резервные копии, но и размещение критичных сервисов на отдельной инфраструктурной площадке. Чаще всего облако используют компании из сегмента ИТ и телеком, торговли, профуслуг и электронной коммерции. Доля ИТ растет с размером компании: с 21% у микробизнеса до 43,8% у среднего бизнеса.

В сегменте dedicated и Bare metal решений структура спроса тоже изменилась. Число компаний с потреблением выше 500 тыс. руб. в месяц — выросло более чем вдвое. Их доля в общем объеме dedicated-инфраструктуры увеличилась с 35% в декабре 2024 года до 49% в декабре 2025 года. В Рег.облаке отмечают, сегментация отражает уровень инфраструктурной нагрузки конкретного проекта. Отдельным индикатором усложнения спроса стала облачная GPU-инфраструктура. За январь–июнь 2026 года объем потребления вырос на 507% год к году, число новых подключений — на 160%, ежемесячная активность — на 240%. Самая массовая карта — NVIDIA A4000 (63% компаний). Спрос формируют не только ИТ: среди пользователей — электронная коммерция, производство, логистика и финансы. Спрос на GPU у аудитории переходит из точечных экспериментов в регулярный инструмент работы с данными и моделями.

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

отмечает Максим Дарулис, коммерческий директор Рег.облака.

Эксперты Рег.ру фиксируют, что цифровая корзинка бизнеса в России стала не просто шире, а сложнее по логике потребления. Базовый онлайн — домен, сайт, почта и защищенное соединение — уже стал отправной точкой. Дальше компании выбирают инфраструктуру под конкретные задачи: резервное восстановление, нагрузку, работу с данными, ИИ и интеграцию разных облачных сред. Главный сдвиг заключается в том, что бизнес все чаще покупает не отдельные ИТ-сервисы, а готовые технологические сценарии для роста, устойчивости и масштабирования.
Рег.ру развивает экосистему цифровых сервисов для бизнеса: регистрацию доменов, хостинг, сервисы для предпринимателей Рег.решения, а также облачные и Bare metal-решения на базе Рег.облака. Компания сопровождает клиентов от первого выхода в онлайн до построения сложной ИТ-инфраструктуры.

Мы расширили каталог моделей в MWS GPT Model Hub. Теперь вы можете точнее подбирать модель под задачу и выбирать подходящий баланс качества, скорости и стоимости.

GLM 5.2 и Kimi K2.6 уже доступны для инференса
Используйте новые мощные LLM для анализа и генерации текста, работы с кодом, документами, AI-ассистентами и многошаговыми запросами. Всё это — в несколько кликов в облачной консоли.

mws.ru/cloud-platform/model-hub

Реранкеры для RAG-сценариев — Preview
Новые модели-реранкеры помогают повторно оценивать найденные фрагменты и выбирать наиболее релевантный контекст для ответа LLM.
Используйте их, чтобы повысить качество поиска и ответов в RAG-системах.