Меня зовут Рене, я сетевой инженер в FirstVDS. В прошлой статье я рассказывал, как мы переезжали из euNetworks в QupraDC и почему даже маленькую площадку полезно строить как нормальную фабрику, а не как одну большую коробку на всё.

Сначала я не планировал писать отдельную статью про второй переезд. Со стороны всё выглядело слишком похоже: снова Amsterdam, снова EVPN/VXLAN-фабрика, снова временная связность между дата-центрами и постепенный перенос серверов. Казалось, что получится пересказ той же истории другими названиями площадок.

Но повод был уже другим. В мае–июле 2026 года в Qupra DC2 произошла серия отказов системы охлаждения: оборудование уходило в аппаратную защиту от перегрева, а локация получала многочасовую недоступность. Аномальная жара стала триггером, но не единственной причиной нашего переезда: единичный сбой превратился в целый каскад проблем, которые вскрыли инженерные и эксплуатационные просчёты площадки. После этого ждать гарантий или доработок со стороны дата-центра мы не считали надёжным планом. Решение было простым и неприятным: надо переезжать в другой ДЦ. После оценки доступных вариантов, сроков, рисков и возможности сохранить текущую сетевую модель мы выбрали NorthC — в текущих условиях новая площадка полностью отвечала нашим требованиям к надёжности, инженерии и эксплуатации.

Задача была не просто перевезти железо из одной стойки в другую. Нужно было сохранить текущие IP-адреса, не заставлять клиентов менять DNS-настройки и выполнить миграцию с минимальным воздействием на сервисы. Внутренний дедлайн тоже был жёстким: успеть до начала горячего для нас эксплуатационного сезона (нового учебного года). Чем дольше мы оставались на площадке с незакрытым риском охлаждения, тем выше была вероятность получить не контролируемую миграцию, а ещё один инцидент.

Именно в процессе подготовки стало понятно, что это всё-таки отдельная история. В первом переезде у нас не было такого набора ограничений: временный Leaf упёрся в 48 портов, постоянный Leaf пришлось освобождать через перекоммутацию оставшихся серверов, Spine нельзя было просто выключить и увезти, а прямую Leaf-to-Leaf связность после переезда мы решили оставить как аварийный путь.

Ниже — не повтор статьи про euNetworks → QupraDC, а разбор второго переезда: как мы готовили NorthC, как использовали подменный leaf3, как пережили нехватку портов, как перевезли spine1 без потери EVPN-сигнализации и почему временная перемычка между Leaf в итоге стала частью аварийного сценария.

Исходное состояние и план переезда
Перед новым переездом площадка уже была построена как EVPN/VXLAN-фабрика. У нас были Leaf-коммутаторы, Spine, routed host networking для гипервизоров, BGP-анонсы VM-префиксов и внешний транзит, разнесённый по Leaf.

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

Базовая идея осталась прежней:

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

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

• подменное железо на время миграции — L3-коммутатор класса Leaf с 48 портами доступа и 6 портами QSFP28, тот самый будущий leaf3;
• два L2 40G-канала между QupraDC и NorthC;
• два L3 100G-канала в Интернет для внешней связности уже из нового дата-центра;
• management-подключение для управления подменным коммутатором;
• отдельные management-подключения для постоянных коммутаторов после их физического переезда в NorthC.

Здесь важно не перепутать назначение каналов. L2 40G между дата-центрами был нужен не для растягивания клиентских VLAN и не для построения большого L2-домена между площадками. Это был временный транспорт, поверх которого мы могли поднять свою IP-связность и включить новый Leaf в существующую фабрику. А два L3 100G-канала в Интернет были нужны для того, чтобы новая площадка получила внешнюю связность до завершения всего физического переезда.

Только после того как поставщик реализовал эти условия, мы начали саму миграцию. В таких работах нельзя сначала перевезти железо, а потом внезапно выяснить, что нет out-of-band управления, не готовы междатацентровые каналы или внешняя связность в новом ЦОД существует только на схеме.

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

Отдельная бытовая, но важная деталь — первичная настройка подменного коммутатора. Leaf3 приехал без нашей конфигурации, а значит, его сначала нужно было как-то настроить до появления нормального management-доступа через продакшен-сеть. Для этого я использовал наш старый Vertiv Avocent ACS804, который мы заранее сняли из QupraDC. Консольный сервер в таких работах — не роскошь, а страховка от ситуации, когда коробка стоит в другой стране с пустым конфигом, OOBM ещё не настроен, а единственный способ поговорить с ней — serial console.

Задача leaf3 была простой: стать временным Leaf в новой локации и дать нам возможность начать перенос серверов до того, как туда переедет всё основное сетевое оборудование.

Первая волна: leaf3 в NorthC и миграция до упора в порты
Leaf3 физически установили в NorthC и временно включили в существующую фабрику. С точки зрения сети он стал ещё одним Leaf-коммутатором, только расположенным в новом дата-центре.

Как и в прошлой миграции, нам была важна не магия конкретного канала между площадками, а его свойства: нормальная IP-связность underlay, достаточный MTU, стабильность и возможность использовать канал как временный транспорт для overlay. Временная связность нужна была для того, чтобы Leaf в новой локации мог стать участником существующей IP-фабрики.

После включения leaf3 мы начали переносить серверы в NorthC партиями. Модель подключения гипервизоров не менялась: серверы по-прежнему работали в routed-модели, VM-префиксы продолжали анонсироваться через BGP, а достижимость внутри фабрики обеспечивалась через EVPN/VXLAN.

Но быстро проявилось ограничение, которого в первой миграции не было в таком виде: портовая ёмкость.

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


Поэтому мы мигрировали до тех пор, пока на leaf3 не закончились свободные порты. Это было нормальное промежуточное состояние: часть серверов уже работала в NorthC через leaf3, часть оставалась в QupraDC на старых Leaf-коммутаторах, а фабрика продолжала жить как единая система.

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

Освобождаем leaf1 и продолжаем переезд
Чтобы продолжить перенос, нам нужно было получить ещё один Leaf в NorthC. Покупать новый постоянный коммутатор под эту задачу не хотелось, а leaf3 был временным и должен был вернуться поставщику. Поэтому мы пошли другим путём: освободили один из действующих Leaf-коммутаторов.

На тот момент часть серверов ещё оставалась в QupraDC. Мы перекоммутировали оставшиеся подключения так, чтобы освободить leaf1: все порты серверов, которые ещё оставались в старой локации, временно собрали на leaf2. Leaf2 продолжал работать в QupraDC и держал оставшуюся часть нагрузки. Это стало возможным за счёт того, что часть серверов с leaf1 и leaf2 уже переехала в NorthC на leaf3, освободив достаточное количество портов на leaf2, чтобы принять оставшуюся нагрузку.

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

После освобождения leaf1 мы физически перевезли его в NorthC и включили в фабрику уже в новой локации. В NorthC у нас появились два Leaf-коммутатора: временный leaf3 и постоянный leaf1. Это дало дополнительную портовую ёмкость и позволило завершить перенос оставшейся серверной нагрузки.

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

Самая неприятная часть: как перевезти Spine и не порвать overlay
Если Leaf-коммутаторы уже находятся в NorthC, а Spine всё ещё остаётся в QupraDC, фабрика продолжает работать за счёт временной междатацентровой связности. Но Spine нельзя просто выключить и перевезти, если Leaf-коммутаторы в новой локации используют его как точку обмена маршрутной и EVPN-информацией.

Проблема была в следующем: если выключить spine1 без подготовки, leaf1 и leaf3 потеряют через него маршруты друг друга. А это уже риск для overlay-сервисов и для клиентского трафика.

Нам нужно было сделать так, чтобы Leaf-коммутаторы в NorthC продолжали видеть loopback-адреса друг друга и обмениваться EVPN-информацией даже в момент, когда spine1 физически выключен и едет из одного дата-центра в другой.

Решение получилось простым и достаточно красивым: мы соединили leaf1 и leaf3 напрямую 100G DAC-кабелем.

Но одного физического кабеля оказалось недостаточно. Нужно было временно построить маленький underlay между этими двумя Leaf-коммутаторами и дать overlay нормальную достижимость.

Для underlay между leaf1 и leaf3 мы использовали ISIS (протокол маршрутизации). Его задача была не заменить всю фабрику, а решить конкретную временную задачу: просигнализировать loopback-адреса Leaf-коммутаторов и обеспечить IP-достижимость, поверх которой можно продолжить работу overlay.

После этого между Leaf-коммутаторами была настроена BGP-сигнализация для EVPN. Иными словами, мы дали leaf1 и leaf3 возможность обмениваться EVPN-информацией напрямую, минуя spine1 на время его физического переезда.

С точки зрения логики это был временный обходной путь:

• физически leaf1 и leaf3 соединены прямым 100G DAC;
• underlay-достижимость loopback-адресов обеспечивается через ISIS;
• overlay продолжает работать через EVPN;
• Leaf-коммутаторы видят необходимые префиксы друг друга;
• spine1 можно выключить и перевезти без потери клиентского сервиса.

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

После проверки прямой связности, ISIS-соседства, loopback reachability и EVPN-обмена мы перевезли spine1 в NorthC. Клиентский трафик при этом не пострадал: Leaf-коммутаторы на новой площадке продолжили видеть друг друга через временную прямую связку.

После переезда Spine мы решили не убирать саму идею прямой Leaf-to-Leaf связности полностью. Временная перемычка показала себя полезной как аварийный сценарий на случай проблем с единственным Spine, поэтому в целевой схеме между постоянными Leaf-коммутаторами мы оставили прямой 100G DAC-линк.

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

На уровне overlay на каждом Leaf в экспортной политике мы добавили трёхкратный AS-PATH prepend с собственной AS — искусственно увеличив длину AS-PATH. EVPN-маршруты, полученные через прямую Leaf-to-Leaf BGP-сессию, становятся менее предпочтительными по AS-PATH. Пока BGP-сигнализация overlay нормально работает через spine1, маршруты через прямую Leaf-to-Leaf сессию не выбираются как основные.

На уровне underlay мы тоже не хотели, чтобы прямой линк случайно стал приоритетным путём при исправном Spine. Поэтому ISIS на этой перемычке был настроен как локальный L1 с выставленным route preference 171. То есть такой underlay-путь заведомо менее предпочтителен, чем любой путь через eBGP в основной фабрике.

В результате прямой 100G DAC между Leaf не нагружает обычный трафик при исправном spine1. Он вступает в работу только тогда, когда ломается основной путь: пропадает нормальная BGP-сигнализация overlay через Spine и вместе с ней основной underlay-путь до loopback-адресов. Получается не постоянный обход Spine, а аварийная страховка от его отказа.

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

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

Поэтому возврат leaf3 поставщику был не формальностью, а полноценным этапом миграции. К этому моменту в NorthC уже можно было собрать целевую схему на постоянных Leaf-коммутаторах, поэтому мы начали обратную перекоммутацию: переносили серверные подключения с leaf3 на leaf1 и leaf2.

Как мы перекоммутировали серверные линк-и без остановки VM
Отдельно стоит рассказать, как именно мы переключали серверы с временного leaf3 на постоянные leaf1 и leaf2. Со стороны это выглядит как простая физическая перекоммутация: был линк в leaf3, стал линк в leaf1 или leaf2. Но если сделать это грубо, можно получить потери трафика или неочевидную асимметрию маршрутизации.

Мы делали переключение шагающим способом. Сначала административно гасили нужный интерфейс на leaf3. После этого для сервера линк переходил в состояние down, а связанный с ним next-hop исчезал из RIB/FIB. Для исходящего трафика это было ключевым моментом: сервер больше не пытался отправлять пакеты через уже выключенный путь, а оставшийся живой next-hop продолжал использоваться как рабочий путь в ECMP-группе.

После этого физический линк можно было переносить на новый Leaf. Когда порт поднимался уже на leaf1 или leaf2, появлялась новая связность, маршруты возвращались в таблицу, и сервер снова получал несколько рабочих путей. Затем мы переходили к следующему линку. То есть мы не выдёргивали всё сразу, а последовательно убирали из работы один путь, дожидались корректного пересчёта forwarding-состояния и только потом двигались дальше.

С входящим трафиком логика была похожей, но работала через BGP-сигнализацию. Достижимость клиентских виртуальных машин была анонсирована через BGP и два route reflector. Когда один из путей становился недоступен, соответствующая сигнализация пропадала, и путь к пересылке уходил на оставшийся живой next-hop. Поскольку порты гасились непосредственно на коммутаторе, событие link down доходило до сетевого стека сразу, без ожидания долгих таймаутов. После этого обновлялись RIB/FIB, и фабрика переставала использовать нерабочий путь.

В результате физическая перекоммутация серверов не требовала остановки клиентских VM. Мы не переносили риск на уровень виртуальных машин, а управляли им на уровне линков, next-hop'ов и BGP-сигнализации. Каждый шаг был маленьким: погасили один порт, убедились, что трафик ушёл на живой путь, перенесли линк, проверили восстановление связности и только после этого переходили к следующему.

После перекоммутации серверов на leaf1 и leaf2 мы вывели leaf3 из фабрики, проверили, что на нём не осталось клиентской и сервисной нагрузки, и вернули коммутатор поставщику.

В целевом состоянии площадка в NorthC снова осталась на постоянной архитектуре:

• серверы подключены к leaf1 и leaf2;
• spine1 находится в новой локации;
• временный leaf3 выведен из эксплуатации;
• между постоянными Leaf оставлена прямая 100G-связность как резервный путь для EVPN и underlay-достижимости;
• клиентская адресация сохранена;
• overlay/underlay-модель не менялась;
• миграция выполнена без остановки сервиса.

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

Главное отличие было в том, что нам пришлось мигрировать не просто «из старого ЦОД в новый», а через несколько вынужденных состояний:

1. Сначала запросить у поставщика подменный Leaf, два L2 40G-канала между дата-центрами, два L3 100G-канала в Интернет и management-доступ.
2. Дождаться готовности этой базовой инфраструктуры.
3. Смонтировать несколько пустых серверов под живую миграцию клиентских VM.
4. Поднять первичный доступ к подменному Leaf через консольный сервер.
5. Затем включить leaf3 как подменный Leaf в NorthC.
6. Потом провести миграцию до исчерпания его 48 портов.
7. Затем освободить leaf1 за счёт временной концентрации оставшейся нагрузки на leaf2.
8. Далее перенести перенос leaf1 в NorthC и завершить серверную миграцию.
9. Пробросить прямой 100G DAC между leaf1 и leaf3, ISIS как временный underlay между Leaf-коммутаторами, организовать EVPN-соседство между ними без участия spine1.
10. Выполнить физический переезд spine1.
11. Шагающая перекоммутация серверных линков с leaf3 на leaf1 и leaf2 через управляемый link down;
12. Вернуть leaf3 поставщику.

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

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

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

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

2. Портовая ёмкость — это не мелочь. Если у каждого сервера несколько физических подключений, один 48-портовый Leaf очень быстро перестаёт быть достаточным для переезда всей площадки. План миграции должен учитывать не только BGP, EVPN и MTU, но и банальное количество физических портов.

4. Освобождение постоянного оборудования может быть частью плана. Мы не покупали ещё одну коробку только потому, что временный leaf3 упёрся в 48 портов. Вместо этого мы временно сконцентрировали остаток нагрузки на leaf2, освободили leaf1, перевезли его и продолжили миграцию.

5. Spine нельзя считать просто «транспортной коробкой», которую можно выключить в любой момент. Если через него Leaf-коммутаторы получают EVPN-информацию друг о друге, его переезд нужно готовить отдельно. В нашем случае прямой 100G DAC между Leaf, ISIS для underlay и EVPN-сигнализация поверх него позволили перевезти spine1 без удара по клиентскому трафику.

6. Временную аварийную связность иногда имеет смысл оставить, но только если она не становится основным путём. Прямой 100G DAC между Leaf мы оставили как страховку от проблем с единственным Spine, но сделали его менее предпочтительным сразу на двух слоях. В overlay — через eBGP AS-PATH prepend. В underlay — через ISIS с L1 preference 171. В штатном режиме сигнализация и трафик идут через Spine; прямой Leaf-to-Leaf линк нужен только тогда, когда основной путь через Spine перестаёт работать.

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

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

Автор статьи: Рене, сетевой инженер FirstVDS
firstvds.ru

Мы используем нашу ферму 3D-печати для изготовления на заказ небольших деталей для наших серверов, таких как воздуховоды и крепления для жестких дисков. Вместо того чтобы заказывать их, мы разрабатываем, тестируем и производим их непосредственно в нашем цехе по производству оборудования. Это экономит время и деньги и позволяет избежать длинных цепочек поставок. Мы сами разрабатываем и моделируем детали: сначала мы создаем 3D-модель на компьютере и печатаем прототип. После того как деталь проходит серию испытаний, она запускается в серийное производство. Для этого более 40 принтеров Prusa XL работают в среднем по 20 часов в день и производят около 1000 воздуховодов в неделю. В качестве материала мы используем термостойкий пластик PETG.

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

Наш последний проект в стиле «сделай сам» — это 3D-печать. На данный момент мы изготовили более 100 000 деталей и не планируем останавливаться.
В этой статье вы узнаете, что стоит за этим и какое отношение к этому имеет бывший мясной магазин.

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

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



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

Отдел 3D-печати был запущен в середине 2025 года на нашем заводе по производству оборудования в Гунценхаузене. Наша команда 3D-производителей работает совместно с нашим основным производственным предприятием в Фалькенштайне, где мы собираем наши выделенные серверы, которые затем отправляем на наши предприятия в Германии и Финляндии. Таким образом, ферма 3D-печати расположена непосредственно у источника.

Но как идея превращается в готовый продукт?



От прототипа до серийного производства
Сначала мы проверяем, подходит ли деталь вообще для 3D-печати. ​​На данный момент это включает более 20 различных воздуховодов и множество других мелких деталей. Они идеально подходят, потому что не должны выдерживать экстремальные механические нагрузки, имеют простую геометрическую форму и подвергаются воздействию температур только до 80°C.

Как только мы решаем, что хотим изготовить компонент самостоятельно, мы переходим к моделированию, а затем и к разработке. Для этого команда создает виртуальную модель в нашем программном обеспечении САПР. САПР расшифровывается как «Computer-Aided Design» (система автоматизированного проектирования) и описывает распространенную категорию программного обеспечения, используемого для создания и редактирования 3D-моделей. Практическое преимущество этого заключается в том, что мы можем видеть прямо на экране, в масштабе, все ли детали подходят друг к другу.

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

Команда разработчиков в отделе 3D-печати постоянно тестирует и экспериментирует с новыми компонентами. Потребность в индивидуальных решениях так же велика, как и разнообразие наших серверов.

Наша типография работает в непрерывном режиме.
Массовое производство? Как это вообще должно работать? Ежедневно мы производим несколько сотен серверов, значит, нам нужно столько же деталей, напечатанных на 3D-принтере, верно? Именно. Вот почему нам нужны кронштейны и воздуховоды в таких масштабах — и они нужны нам каждый день.

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



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

Чтобы справиться с огромным объемом заказов, станки работают в среднем 20 часов в сутки, семь дней в неделю, а иногда и до 24 часов. Производительность впечатляет: мы производим 1000 воздуховодов в неделю. Для этого мы используем около полутонны филамента в месяц. Филамент — это пластиковая нить, которую принтер плавит и наносит слой за слоем. В качестве материала мы используем PETG, прочный пластик, способный выдерживать достаточно высокие температуры. Поскольку серверы работают круглосуточно, внутри может быть очень жарко.

Технологии, лежащие в основе парка самолетов Prusa XL.


Мы выбрали чешский FDM-принтер Prusa XL. FDM расшифровывается как Fused Deposition Modeling (послойное наплавление) и точно описывает описанный выше принцип: принтер нагревает нить и послойно выдавливает ее через тонкое сопло до тех пор, пока деталь не будет готова. У Prusa XL это сопло имеет ширину всего 0,4 мм.

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

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

Объем рабочей области 360 x 360 x 360 мм обеспечивает достаточно места. Это позволяет печатать воздуховоды целиком, без необходимости сборки отдельных деталей. Например, типичный воздуховод имеет размеры 150 x 100 x 96 мм. Поскольку мы используем весь объем рабочей области, мы можем печатать от четырех до шести воздуховодов одновременно, в зависимости от их размеров.

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

Это больше, чем просто эксперимент.
Если деталь не подходит, мы её подгоним — даже если для этого потребуется прямой 3D-принтер. Это экономит нам время и деньги, а также снижает зависимость от цепочек поставок. Кроме того, мы можем производить детали, которые, возможно, даже не доступны для покупки.

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

Дело в том, что 3D-печать в компании Hetzner — это уже не эксперимент, а неотъемлемая часть нашего производства.

Новый сервер GEX45 с графическим процессором: возможности искусственного интеллекта по доступной цене.
Компания Hetzner представляет новый GEX45 — сервер с графическим процессором, обеспечивающий профессиональную производительность по привлекательной цене начального уровня. В основе системы лежит NVIDIA RTX PRO 4000 Blackwell SFF Edition с 24 ГБ видеопамяти GDDR7 ECC. Благодаря тензорным ядрам 5-го поколения с поддержкой FP4 и ядрам RT 4-го поколения, GEX45 особенно хорошо подходит для выполнения задач искусственного интеллекта и тонкой настройки ИИ. GEX45 обеспечивает высокую производительность и за пределами приложений ИИ; к областям его применения также относятся 3D-рендеринг, САПР-приложения и видеопроизводство.

Процессор Intel Core i5-13500 13-го поколения «Raptor Lake» обеспечивает высокую производительность. Он имеет шесть высокопроизводительных ядер и восемь энергоэффективных ядер, в общей сложности 20 потоков. 64 ГБ оперативной памяти DDR4 обеспечат достаточный запас для ресурсоемких приложений, а два твердотельных накопителя NVMe по 512 ГБ гарантируют быструю загрузку и доступ к данным.

В комплект GEX45 входит IPv4-адрес, который можно приобрести за 214,00 евро / 249,00 долларов США в месяц плюс единовременный сбор за настройку в размере 209,00 евро / 249,00 долларов США. Это делает GEX45 идеальным выбором для тех, кто ищет мощный сервер начального уровня для профессиональных задач, связанных с графическими процессорами.
www.hetzner.com/dedicated-rootserver/gex45/

НАДЕЖНОЕ СЕТЕВОЕ СОЕДИНЕНИЕ: 50,12 Тбит/с И НОВЫЙ ПОЯВИТЕЛЬ В ВАРШАВЕ
Мы постоянно расширяем общую внешнюю пропускную способность, чтобы вы могли пользоваться мощным и надежным сетевым соединением. Недавно мы увеличили пропускную способность нескольких исходящих каналов и подключили к сети другие:

Приватные пиринги:

• 400 Гбит/с CDN77 (HEL)
• 100 Гбит/с 1CentHost (Франция)
• 100 Гбит/с Aurologic (HEL1)
• 100 Гбит/с BackboneDirect (AMS)
• Группа передачи данных 100 Гбит/с (FRA)
• 100 Гбит/с EliteServices (AMS)
• EliteServices (STO) 100 Гбит/с
• 100 Гбит/с Exatel (Франция)
• 100 Гбит/с Fastly (PAR)
• Глобальный слой 100 Гбит/с (AMS)
• 100 Гбит/с Lumaserv (Франция)
• 100 Гбит/с Netshield (HEL)
• 100 Гбит/с UTG (Франция)
• 100 Гбит/с Wilhelm.Tel (Франция)
• 100 Гбит/с Worldstream (AMS)

Точки взаимодействия:

• 100 Гбит/с OCIX (Франция)
• 100 Гбит/с ERA-IX (VIE)
• 400 Гбит/с GNM-IX (HEL)

Кроме того, мы расширили нашу сеть, включив в нее новую точку присутствия (PoP) в Варшаве. Это улучшает доступ к локальным сетям доступа для клиентов в Восточной Европе и снижает задержку. В то же время, новое местоположение повышает надежность нашей сетевой инфраструктуры, поскольку точка присутствия в Варшаве служит дополнительным резервным маршрутом для нашего соединения по подводному кабелю C-Lion1 с Финляндией.
www.hetzner.com/unternehmen/rechenzentrum/

Хетцнер в очередной раз вошел в число 50 лучших игроков Баварии.
Компания Hetzner в очередной раз вошла в число 50 самых быстрорастущих средних компаний Баварии в 2026 году. Министерство экономики, регионального развития и энергетики Баварии в шестой раз удостоило компанию звания «50 лучших компаний Баварии». Министр экономики Баварии Хуберт Айвангер вручил награду генеральному директору Штефану Конвичковой и представителю компании Кристиану Фицу 30 июля во дворце Шляйсхайм в Мюнхене, Германия.



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

Один из крупнейших ютуберов, специализирующихся на технологиях, посетил Hetzner.
Смотрите, кто заглянул! К нам приехал Линус из Tech Tips, и вместе со своей командой он осмотрел крупнейший в Германии парк центров обработки данных в Фалькенштайне.
Оказалось, что канадская энергетика и немецкая инфраструктура представляют собой довольно удачное сочетание.

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

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

Что это значит для клиентов Cloud4box?
Домены продолжаем регистрировать в привычном порядке — никаких дополнительных действий сейчас не требуется.

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

Следить за этапами принятия правил можно по ссылкам:
regulation.gov.ru/projects/166376/
regulation.gov.ru/projects/166378/

А пока — без новых квестов с Госуслугами

https://timeweb.cloud

31 августа 2026 AI-агенты тоже идут учиться
К 1 сентября добавили агентам навыки — отдельные инструкции под конкретные задачи.
Раньше все инструкции были в одном системном промпте. Больше задач → длиннее промпт → дороже каждое обращение к модели. Теперь инструкции раскладываются по навыкам, а это значит:
Экономия токенов. В запрос уходит только компактный индекс навыка, полная инструкция добавляется под задачу.
Порядок в логике. Один навык = одна задача, которую проще править, тестировать и понимать.
Переиспользование. Написали навык один раз — подключаете его любому агенту, не копируя текст между промптами.
Как начать применять:
1. Выберите повторяющуюся задачу: оформление ответов, работа с возражениями или сбор данных.
2. Создайте навык: название, условия применения и сама инструкция.
3. Подключите его к одному или нескольким агентам — дальше агент сам подтянет инструкцию, если запрос подойдет под условие.
Каждое изменение навыка сохраняется отдельной версией, между ними можно переключаться.
timeweb.cloud/my/cloud-ai/skills

26 августа 2026 Воркер-группа растет вместе с кластером
Раньше, когда кончались ресурсы в кластере, приходилось создавать новую воркер-группу и переносить нагрузку на нее. Теперь все гораздо проще: добавили возможность увеличить текущую группу без пересоздания.
1. Проект вырос и поды уперлись в лимиты CPU и памяти → повышаете тариф воркер-группы, кластер остается прежним.
2. Нужна более гибкая настройка → переходите с тарифа на конфигуратор и собираете ресурсы под задачу.
Учтите, что апгрейд доступен только внутри вашей тарифной линейки. При изменении конфигурации воркер-ноды перезагружаются по очереди, чтобы не останавливать кластер.
timeweb.cloud/my/kubernetes

25 августа 2026 Кончается лето, но не токены
Запускаем неделю акций на AI Gateway — через него вы работаете с популярными моделями (Claude, DeepSeek, Qwen, Gemini, GPT, Grok и др.) по одному ключу и одному API.
Выгода для каждого своя:
1. Тем, кто еще не пробовал — скидка 10% на все токены. Переход занимает пару минут: меняете адрес API на наш и вставляете новый ключ.
Действует с 25 по 31 августа, до 23:59 мск.
2. Активным пользователям — за расходы в августе действует скидка на весь сентябрь. Потратили от 5 000 ₽ → 10%, от 50 000 ₽ → 15%. Скидка включится автоматически 1 сентября.
Считается по всем тратам на AI Gateway с 1 по 31 августа.
Обе скидки действуют на весь парк — 69 моделей от 9 провайдеров, включая локальные на серверах в России. Полные условия акции — по ссылке.
timeweb.cloud/my/cloud-ai/gateway

24 августа 2026 Готовность к агентам — 99%
Когда вы просите Cursor или Claude что-то развернуть на Timeweb Cloud, агент идет в нашу документацию. Таких визитов уже треть от всех обращений к доке — посчитал наш руководитель разработки Миша Шпаков в статье.
Вывод простой: понятные инструкции нужны и агентам. Доработали их и получили 99 из 100 в AFDocs.
Вот как это повлияло на ваши запросы к доке:
1. В сотни раз меньше токенов — добавили llms.txt и llms-full.txt. С чистыми текстовыми версиями доки на страницу теперь уходит около 1 100 токенов вместо 295 000.
2. Задачи доходят до конца — подняли рейт-лимиты, чтобы частые запросы проходили без блокировок, а страницы быстро загружались из кэша.
3. Агент читает то же, что и вы — для этого выровняли разметку HTML- и MD-версий. Теперь никаких расхождений или устаревших данных.
timeweb.cloud/docs

21 августа 2026 Пройти идентификацию через ЕСИА за пару минут
Мы уже рассказывали, зачем нужно подтверждение данных владельца домена через Госуслуги — с 1 сентября без этого нельзя будет зарегистрировать, продлить и передать домены .ru,.рф и .su.
Теперь пройти идентификацию можно в панели, в разделе «Домены и SSL». Пока она доступна только для физлиц, юрлица смогут подтвердить данные после 1 сентября.
1. Зайдите в «Домены и SSL» → «Администраторы»
2. Нажмите «Подтвердить данные» → «Я — администратор»
3. Авторизуйтесь в Госуслугах
Если данные совпали, появится отметка о подтверждении. Если нет — мы свяжемся с вами для уточнения. Более подробно разобрали в документации.
timeweb.cloud/docs/domains/esia-identification
Если у вас домен .SU
Для доменов .su идентификация проходит через Руцентр, нашего партнера.
После 1 сентября при регистрации или продлении домена на емейл администратора придет письмо с инструкцией от Руцентра.

20 августа 2026 > открыть доступ к веб-серверу
Этот запрос мы встретили в «Идеях» трижды (раз, два, три) — и теперь настройки веб-сервера можно менять прямо в приложении.
Страницы стали грузиться медленно — включаете сжатие и кэширующие заголовки. Или пользователи загружают файлы по 500 МБ — ставите лимит на размер запроса.
Что можно настраивать:
1. Редиректы — указывайте, куда перенаправлять пользователей со старых страниц на новые. Например, с www.site.cоm на sitе.cоm.
2. HTTP-заголовки — для Cache-Control, CORS и заголовков безопасности. Можно добавлять, менять и удалять.
3. Сжатие — поддерживаются gzip или zstd, чтобы отдавать страницы быстрее.
4. Параметр SPA — что увидит пользователь по несуществующему адресу: главную страницу (стандарт для SPA) или вашу страницу 404.
5. Лимиты для бэкенда — чтобы защититься от тяжелых запросов и зависших соединений. Задаются максимальный размер тела запроса и таймаут ожидания заголовков ответа.
Пошаговый гайд по каждому параметру → в доке.
timeweb.cloud/docs/apps/reverse-proxy

18 августа 2026 MCP-сервер, который не тратит лишние токены
Пересобрали Timeweb Cloud MCP и выложили описание новой версии на GitHub.
С MCP-сервером агент сразу видит ваши ресурсы и может ими управлять: создавать, менять и настраивать. Раньше все инструкции при подключении уходили в контекст и тратили слишком много токенов. Сейчас вместо полного набора действий — три команды:
1. search_tools — найти нужную операцию по описанию задачи
2. get_tool_definition — получить ее параметры
3. execute_tool — выполнить операцию с этими параметрами
Итог: агент не держит в памяти весь каталог действий, а ищет нужное под конкретную задачу. Контекст остается компактным, токены не сгорают впустую — а список доступных действий стал больше.
Работает с Cursor, Claude Code, Codex и любым агентом с поддержкой удаленных MCP-серверов. Из настройки только API-токен и адрес сервера в конфиге ассистента. Готовые инструкции есть в доке.
timeweb.cloud/my/cloud-ai/agents/create

13 августа 2026 Новинки для ваших AI-агентов
За неделю выкатили сразу несколько релизов — собрали все в один пост. Суть у всех одна: агенты забирают на себя больше задач в ваших проектах.
Теперь можно:
1. Делиться с агентом файлами в Telegram
Отправляете файл в чат вместе с запросом — агент сделает сводку по CSV с данными или найдет ошибку на скриншоте с логами.
Особенно удобно для тех, кто уже настроил ИИ-помощников в чатах поддержки.
2. Управлять облаком через команды
Выложили репозиторий со скиллами (инструкциями) для работы с Timeweb Cloud MCP. С ними агент получит готовые сценарии, например, как поднять сервер или настроить DNS. Меньше ошибок и лишних действий.
В Claude Code скиллы ставятся как плагин в две команды, в Cursor, Codex и OpenCode — через npx skills.
3. Передавать агенту файлы через API
Добавили Files API — отдельный механизм для работы с файлами в API агентов. Он снял прежние ограничения по формату и размеру, и вы можете принимать любые файлы от своих пользователей.
Схема простая: пользователь вашего сервиса прикрепил файл в чате → сервис передал его агенту через API → агент ответил с учетом содержимого.
А еще выкатим новые локальные модели с низкой стоимостью — подробности скоро.

12 августа 2026 Одно приложение хорошо, а два — лучше
Сделали то, что вы часто просили в идеях (раз, два, три). Теперь в App Platform копию приложения можно создать также, как копию облачного сервера.
Пригодится, когда:
1. Пользователи в другом регионе — разворачиваете копию ближе к ним и снижаете задержки.
2. Подбираете конфигурацию — поднимаете клон на других ресурсах и сравниваете с оригинальным приложением
3. Нужен резерв — переводите трафик на копию в другой локации
Копия делается в два шага: выбираете нужное приложение → жмете на значок справа от него. Все настройки подтягиваются с родительского приложения, а вы меняете только то, что нужно:
— Ветку и коммит
— Локацию
— Конфигурацию
— Название, комментарий и проект
— Приватную сеть

11 августа 2026 Эволюция ченжлога на сайте
Многие из вас предлагают идеи по развитию продуктов и следят за обновлениями. Чтобы отслеживать релизы было проще, даже если пропустили дайджест, мы переделали старый ченжлог в «Журнал обновлений». В нем записана вся история релизов, изменений и исправлений багов с лета 2024 года.
Что появилось:
1. Блок «Запланировано» — что сейчас в работе и выйдет в ближайшее время. Прежде чем нести фичу в «Идеи», стоит заглянуть туда.
2. Поиск — если нужно узнать, добавили ли нужные AI-модели или новую ОС в маркетплейсе.
3. Теги — показывают, к каким сервисам относится релиз.
4. Фильтр — по месяцам и сервисам, работает и вместе: например, все обновления S3 за июль.
А если следить за релизами удобнее в Телеграме, обновления дублируются в нашем канале.

10 августа 2026 Ctrl+Z для баз данных
Классическая ситуация — наводите порядок в панели и случайно удаляете нужный кластер. Или перепутали прод с тестовым и выполнили команду удаления не в том окне.
Чтобы избежать потери данных (а еще кучи времени и нервов) — запустили функцию отмены удаления базы данных. С ней удаленный кластер можно бесплатно восстановить в течение 72 часов со всеми данными, резервными копиями и конфигурацией.
Как подключить: настройки кластера → Бэкапы → Отмена удаления. Для новых кластеров — сразу при создании.
Стоимость — 200 ₽ в месяц, а разовое восстановление без подключенной защиты — 2000 ₽
Условия и порядок восстановления собрали в документации.
timeweb.cloud/docs/dbaas/dbaas-manage/deletion-protection

5 августа 2026 Все нужное в одном месте
Сервисов у нас много, а новые продолжают появляться. Чтобы не тратить драгоценные клики, сделали «Избранное».
В него можно закрепить любой раздел или отдельный сервис — наводите курсор на нужный пункт и отмечаете звездочкой.
Заодно обновили настройки доступа для тех, кто работает в панели не один:
Доступ к «Новостям и идеям» — основной аккаунт может открыть их дополнительному пользователю: только чтение или полный доступ.
Уведомления по тикетам — у дополнительного пользователя появится доступ к поддержке, письма по тикетам будут приходить и ему.

4 августа 2026 Почти 7000 приложений на App Platform
Как бы ни росло количество ваших фронтенд- и бэкенд-приложений, главное — предсказуемая сборка и понятная картина после деплоя.
С этим помогают три инструмента:
1. Стенды для проверки релизов
Копия приложения, чтобы протестировать изменения: поднимаете стенд, кидаете ссылку команде, собираете правки и только потом выкатываете в прод. Подробнее о настройке стендов → в доке.
2. AI-помощник в логах деплоя
Если деплой упал, во вкладке «Деплой» остается полный лог — AI-помощник его разберет и выдаст отчет с причинами и подсказками.
Где смотреть: откройте проблемный коммит на вкладке «Деплой» → подсказка появится в панели справа.
3. Графики нагрузки
Процессор, память, диск и сетевой трафик на одном экране помогают мониторить приложение после деплоя. На дашборде сразу можно увидеть, уперлось ли приложение в лимиты конфигурации или это разовый пик.

4 августа 2026 Режим стримера
Теперь можно спокойно снимать скринкасты, стримить работу в панели или шарить экран на демо-звонке. Нам, кстати, тоже стало заметно проще записывать для вас инструкции. Все потому, что в панели появился режим стримера.
Включаете — и панель сама блюрит конфиденциальные данные:
— Публичные IP-адреса
— Баланс
— Личные данные: ФИО, телефон, email
— Домены и почтовые ящики
Пока переключатель в меню профиля в правом верхнем углу. Позже переедет в настройки персонализации.

• AMD Ryzen 7 5800X
• 1x Radeon RX 6700 XT 12 GB
• 64 GB DDR4 2666 MHz ECC
• 2x 960 GB SSD NVMe Soft RAID
• 1Gbit/s unmetered and guaranteed

Заказать
bill.yacolo.net/billmgr

Так же напоминаю

• Продаем AI-маркетплейс Selectel за любую криптовалюту, а так же токены Inference-сервиса
• Продаем AI Studio Yandex за любую криптовалюту
• Продаем AI Agents Сбербанка за любую криптовалюту и все остальные ИИ сервисы
• Продаем токены timeweb за любую криптовалюту
• Продаем токены GPT Model Hub от МТС за любую криптовалюту

Мы завершили перенос инфраструктуры в новый дата-центр NorthC Amsterdam 1. Новая площадка полностью соответствует нашим требованиям по надёжности, уровню инженерной инфраструктуры и качеству эксплуатации.

Надёжность уровня Tier 3
Дата-центр соответствует стандарту Tier 3, что означает резервирование ключевых инженерных систем, включая электропитание, охлаждение и сетевые подключения.

Современная инфраструктура
NorthC Amsterdam 1 принадлежит компании NorthC — крупному оператору дата-центров с сетью площадок в Нидерландах, Германии и Швейцарии.

firstvds.ru/products/vps_vds_netherlands

Федеральный закон № 569 от 29 декабря 2025 года «О внесении изменений в федеральный закон «Об информации, информационных технологиях и о защите информации» и отдельные законодательные акты Российской Федерации» среди прочих изменений меняет правила работы регистраторов доменов и обязанности администраторов доменных имён.

Изменения вступают в силу с 1 сентября 2026 года и затрагивают администраторов и регистраторов доменов в российских доменных зонах .RU/.РФ/.SU Администраторам доменов необходимо пройти идентификацию через Госуслуги, а регистраторам — обеспечить этот функционал.

Как указано в законе, для любых действий с доменом:

• регистрации;
• продления регистрации;
• смене администратора;
• смене регистратора;
• изменения настроек (смене DNS-серверов).

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

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


В случае регистрации одним администратором доменов во всех зонах он будет учтён несколько раз, поэтому допустимо ориентироваться на общие значения по количеству в зоне .RU как наиболее популярной — 2,278 млн., из которых 82% физические лица и 18% — юридические. То есть, нормы закона коснутся порядка 2,3 млн. администраторов доменов.

Порядок идентификации домена

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

1. Следует уточнить паспортные данные (для физических лиц) и реквизиты (для юридических лиц), указанные регистратору домена ранее, и при необходимости обновить их.
2. Получить от регистратора индивидуальную ссылку для прохождения идентификации.
3. При переходе по ссылке и после входа в Госуслуги подтвердить факт администрирования домена.

Изменения для регистраторов доменов

Также под действие закона подпадают профессиональные участники рынка — аккредитованные регистраторы. На август 2026 года Координационным центром доменов .RU/.РФ аккредитовано 185 регистраторов. Для продолжения профессиональной деятельности и реализации требований закона регистраторам необходимо выполнить подключение к системе ЕСИА (Единая система идентификации и аутентификации) Госуслуг. Технически это требует приобретения и настройки программных и аппаратных средств сопряжения через СМЭВ (Система межведомственного электронного взаимодействия), соответствующих требованиям ГОСТ по стойкости шифрования и информационной безопасности, что составляет минимум несколько миллионов рублей.

Несмотря на срок 1 сентября 2026 года из 185 регистраторов доменов идентификацию через Госуслуги выполняют лишь 3 и лишь физических лиц. Из-за того, что требуемые нормативные акты к данному закону не были приняты, у компаний-регистраторов отсутствуют формальные правовые основания для подключения к ЕСИА. По этой причине Минцифры отклоняет запросы регистраторов на доступ к системе, без которой невозможно выполнение требований закона. По той же причине пока не решён вопрос с идентификацией регистраторами администраторов юридических лиц.

Необходимые регулирующие изменения документы:

• «Об утверждении Правил регистрации доменных имен» (ID: 164913)
• «Об утверждении Правил формирования и ведения перечней регистраторов доменных имен и требований к российским юридическим лицам, включаемым в указанные перечни» (ID: 166378)

находятся на этапе размещения текста проекта на федеральном портале проектов нормативных правовых актов regulation.gov.ru

Учитывая данные правовые лакуны Координационный центр доменов .RU/.РФ предоставил регистраторам доменов отсрочку до 18 января 2027 года по приведению информационных систем в соответствии с требованиями закона. До этого срока работа аккредитованных регистраторов возможна по прежним правилам.

Что следует делать администраторам уже сейчас?

Рекомендации различаются в зависимости от статуса администратора и регистратора его домена.

Регистратор предоставляет идентификацию

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

Регистратор пока не предоставляет идентификацию

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

Администратор — государственная организация

Государственным организациям в соответствии с требованиями закона следует перенести свои домены на обслуживание к уполномоченным регистраторам. Законом установлен один такой регистратор для доменов .RU/.РФ и один для .SU

Администратор — нерезидент

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

Цель нововведений

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

Новые требования предусматривают идентификацию администратора домена через подтверждение его данных посредством Госуслуг. Вряд ли это станет непреодолимым препятствием для мошенников, ведь и в банковской сфере существуют «дропы», номинальные держатели карт, используемых в незаконных переводах. Нетрудно предположить, что идентификацию мошеннических доменов .RU будут проводить такие же номиналы. Другой путь для злоумышленников — использовать домены в международных зонах .COM, .NET, .ORG и множестве других, находящихся вне юрисдикции РФ.

Влияние на рынок

Существенные расходы на приведение информационных систем в соответствие законодательству не могли не сказаться на экономике регистраторов, что привело к росту цен на рынке. Так, крупнейший регистратор уже поднял в 2026 году розничные цены на домены в 1,5 раза. Некоторые другие участники рынка также повысили стоимость своих услуг или планируют сделать это в ближайшее время. Таким образом, стоимость внедрения требований № 569-ФЗ будет возложена на администраторов доменов.

Другим результатом исполнения нового закона станет сжатие рынка регистраторов. Маржа регистраторов довольно скромная и многие из них сочтут целесообразным уйти с рынка, чтобы не нести непосильные расходы на внедрение. Это грозит ещё большей монополизацией рынка и, как следствие, повышением цен на услуги. Уже сейчас регистратором более чем 68% доменов .RU/.РФ является группа компаний под единым управлением.

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

Источник: https://tendence.ru/news/identifikatsiya-administratorov-domenov-po-569-fz

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

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

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



www.majordomo.ru