Релиз PHP 8.1
25.11.2021 состоялся релиз PHP 8.1. Улучшенная производительность, enums, readonly свойства, пересечение типов, fibers и многое другое.

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

Попробуйте хостинг с поддержкой PHP 8.1 бесплатно 7 дней

Новая услуга «Виртуальный дата-центр»
Дата-центр FREEhost.UA предлагает построить собственный виртуальный ЦОД с использованием нашей инфраструктуры. В единую систему можно объединить виртуальные и выделенные физические сервера, а так же оборудование клиента размещенное как в нашем так и в другом дата-центре. Вычислительные способности нашего дата-центра позволяют построить стему любой сложности. Высокий уровень автоматизации, наличие готовых шаблонов виртуальных машин позволяет запустить проект в сжатые сроки и снизить затратную часть.

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

Подробней по ссылке https://freehost.com.ua/servers/virtualdc/

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

COLLO 0 – 1 юнит, порт подключения 100 мбит, блок питания до 200 Вт, 1 IP адрес, 60 Гб на сервере резервных копий — 749.87 грн. в месяц с НДС.COLLO 1 – 2 юнита, порт подключения 100 мбит, блок питания до 400 Вт, 2 IP адреса, 100 Гб на сервере резервных копий — 1197.90 грн. в месяц с НДСCOLLO 2 – 2 юнита, порт подключения 100 мбит, блок питания до 500 Вт, 2 IP адреса, 100 Гб на сервере резервных копий — 1449.79 грн. в месяц с НДС
Подробней по ссылке https://freehost.com.ua/servers/collocation/

Два новых шаблона VPS хостингаМы продолжаем работу над шаблонами виртуальных серверов. В ноябре мы добавили три новых шаблона:
Дистрибутив AlmaLinux 8 freehost.com.ua/vps-hosting/pr/almalinux/AlmaLinux + HestiaCPDebian 11 + HestiaCP
Новые статьи в нашем блогеДайджест уязвимостей плагинов WordPress за ноябрь 2021freehost.com.ua/faq/articles/dajdzhest-ujazvimostej-plaginov-wordpress-za-nojabr-2021/

Как настроить безопасный FTP сервер vsftpd с использованием пользовательских директорий на ОС Ubuntu 20.04freehost.com.ua/faq/articles/kak-nastroit-bezopasnij-ftp-server-vsftpd-s-ispolzovaniem-polzovatelskih-direktorij-na-os-ubuntu-2004/

От чего зависит скорость загрузки сайта?freehost.com.ua/faq/articles/ot-chego-zavisit-skorost-zagruzki-sajta/

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

В этом месяце мы добавили два шаблона:
Debian 10 + ISP manager 6. Стандартный шаблон с панелью управления, которая пришла на смену ISP manager 5.

Centos 7 + CWP + Apache Tomcat. CentOS Web Panel удобная, бесплатная альтернатива платной панели управления ISP manager 6. Ее дополнительное преимущество — поддержка Apache Tomcat.

Больше информации про наши облачные сервера на сайте https://freehost.com.ua/vps-hosting/

STOCK-сервераВ дата-центре FREEhost.UA размещено более 1000 серверов. Естественно иногда на складе скапливаются сервера с процессорами предыдущих поколений. Чтоб этого не происходило, мы решили такие сервера выделить в отдельную группу и отметить на сайте маркером «stock”. Stock-сервера сдаются в аренду по сниженной стоимости на весь период аренды. Стоимость сервера зависит от количества серверов аналогичной модели на складе. Поэтому иногда сервер с процессором Intel Xeon может оказаться дешевле чем Intel I3. Мы думаем, что стоимость аренды stock-серверов является самой низкой в Украине. При этом качество оборудования и техническая поддержка неизменно на высоком уровне.

Подробней ознакомиться с предложением можно на нашем сайте https://freehost.com.ua/servers/dedicated/

Свежие статьи в блоге:
Создание простого отказоустойчивого почтового кластера на базе IredMailhttps://freehost.com.ua/faq/articles/stvorennja-prostogo-vidmovostijkogo-poshtovogo-klasteru-na-bazi-iredmail/

Лидер нашего блога. Статья за 3 дня набрала более 1000 просмотров.

WordPress vs Wix: какая платформа подойдет вам?https://freehost.com.ua/faq/articles/wordpress-vs-wix-kakaja-platforma-podojdet-vam/

Telegram становится неотъемлемой частью нашей жизни, аки Google, Youtube, Default и другие сервисы. Все чаще я вижу людей, которые нехотя удаляют VK Messenger, Whatsapp, Viber, а уже потом отказываются от своих претензий и навсегда связывают свое личное/рабочее/семейное общение в Telegram. На протяжении 8 лет работы, мессенджер оброс множеством функций, в частности ботами в Telegram. Этот пост про бота, который заменит Check-host.net, Ping.pe, DNSchecker, MXtoolbox в привычном понимании.




Читать дальше →

CyberBunker.com — пионер анонимного хостинга, который начал работу в 1998 году. Компания разместила серверы в одном из самых необычных мест: внутри бывшего подземного комплекса НАТО, построенного в 1955 году как защищённый бункер на случай ядерной войны.

Клиенты становились в очередь: все серверы обычно были заняты, несмотря на завышенные цены: VPS стоил от €100 до €200 в месяц, без учёта платы за установку, при этом планы VPS не поддерживали Windows. Зато хостер успешно игнорировал любые жалобы DMCA из США, принимал биткоины и не требовал от клиентов никакой личной информации, кроме адреса электронной почты.

Но теперь «анонимному беспределу» пришёл конец. Ночью 26 сентября 2019 года бойцы немецкого спецназа и полиции штурмом взяли защищённый и охраняемый бункер. Захват произведён под предлогом борьбы с детской порнографией.

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


Вход в бункер можно рассмотреть рядом с тремя зданиями в левой верхней части фотографии. По центру — вышка связи. Справа — второе здание дата-центра. Фото сделано с полицейского дрона


Спутниковая карта этого района
www.google.com/maps/@49.9664317,7.1207858,660m/data=!3m1!1e3


Полиция перед входом в бункер после начала операции

Захваченный объект находится около городка Трабен-Трарбах в юго-западной части Германии (земля Рейнланд-Пфальц, столица Майнц). Четыре подземных этажа бункера уходят в глубину на 25 метров.


Прокурор Юрген Бауэр (Juergen Bauer) рассказал журналистам, что расследование деятельности анонимного хостинга велось несколько лет. Операция тщательно готовилось. Одновременно со штурмом задержано семь человек в ресторане Трабен-Трарбаха и в городе Швальбах, недалеко от Франкфурта. Главным подозреваемым является 59-летний голландец. Задержаны он и трое его соотечественников (49, 33 и 24 года), один немец (23 года), болгарин и единственная женщина (немка, 52 года).

Обыски проведены также в Польше, Нидерландах и Люксембурге. Всего конфисковано около 200 серверов, бумажные документы, многочисленные носители данных, мобильные телефоны и большая сумма наличных денег (примерно 41 млн долларов в эквиваленте). Следователи говорят, что анализ улик займёт несколько лет.


В ходе рейда немецкие власти также захватили по крайней мере два домена, в том числе домен голландской компании ZYZTM Research (zyztm[.]com) и cb3rob[.]org.

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

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

Бывший объект НАТО был куплен у геоинформационного подразделения Бундесвера. Пресс-релизы в то время описывают его как многоэтажное защитное сооружение площадью 5500 м². У него два смежных офисных здания площадью 4300 м², общая территория построек занимает 13 гектаров земли.


Начальник региональной уголовной полиции Йоханнес Кунц (Johannes Kunz) добавил, что подозреваемый «связан с организованной преступностью» и большую часть своего времени проводил в этом районе, хотя подал документы на переезд в Сингапур. Вместо эмиграции владелец дата-центра, предположительно, жил прямо в подземном бункере.

Всего под следствием находятся тринадцать человек в возрасте от 20 до 59 лет, в том числе трое граждан Германии и семь граждан Нидерландов, сообщил Брауэр.

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

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

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


Среди незаконных услуг, предположительно размещённых в немецком дата-центре, были Cannabis Road, Flight Vamp 2.0, Orange Chemicals и вторая в мире по размеру платформа для продажи наркотиков Wall Street Market.

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

Платформа Wall Street Market обработала около 250 000 сделок по незаконному обороту наркотиков с объёмом продаж более 41 миллиона евро.

Flight Vamp считается крупнейшей в Швеции площадкой для незаконной продажи наркотиков. Розыск её операторов ведут шведские следственные органы. По данным следствия, там отметились 600 продавцов и около 10 000 покупателей.

Через Orange Chemicals по всей Европе распространялись синтетические наркотики разного вида.

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

По словам Бауэра, ботнет-атака на немецкую телекоммуникационную компанию Deutsche Telekom в конце 2016 года, которая вывела из строя около 1 миллиона маршрутизаторов клиентов, также велась с серверов в Кибербункере.

Когда бункер купили в 2013 году, покупатель сразу не назвал себя, но сказал, что связан с CyberBunker, оператором аналогичного голландского дата-центра, расположенного в другом бункере времён холодной войны. Это один из старейших анонимных хостингов в мире. Он декларировал независимость так называемой «Республики Кибербункер» и готовность размещать любой сайт, кроме детской порнографии и всего, что связано с терроризмом. В настоящее время сайт недоступен. На главной странице красуется гордая надпись от правоохранительных органов: «Сервер конфискован» (DIESE SERVER WURDE BESCHLAGNAHMT).


Согласно историческим записям whois, Zyztm.com первоначально был зарегистрирован на имя Германа Йохана Ксеннта (Herman Johan Xennt) из Нидерландов. Домен Cb3rob.org принадлежал организации, которая хостилась в CyberBunker и была зарегистрирована на Свена Олафа Кампхейса, самопровозглашённого анархиста, осуждённого несколько лет назад за участие в вышеупомянутой крупномасштабной атаке, которая ненадолго нарушила работу интернета в некоторых местах.

Предполагаемый владелец и оператор кибербункеров Герман Йохан Ксеннт. Изображение: The Sunday World, 26 июля 2015 года

59-летний Ксеннт и Кампхейс вместе работали над предыдущим проектом «пуленепробиваемого» хостинга CyberBunker, который размещался внутри военного бункера в Нидерландах, пишет исследователь в области информационной безопасности Брайан Кребс.

По словам директора компании Disaster-Proof Solutions Гвидо Блаау (Guido Blaauw), он купил у Ксеннта голландский бункер площадью 1800 м² в 2011 году за $700 тыс. Вероятно, после этого Ксеннт нашёл похожий объект в Германии.

Гвидо Блаау утверждает, что после пожара 2002 года, когда в голландском бункере среди серверов нашли лабораторию по производству экстази, там не размещалось ни одного сервера: «В течение 11 лет они рассказывали всем об этом ультра-безопасном бункере, но [их серверы] размещались в Амстердаме, и в течение 11 лет они обманывали всех своих клиентов».


Аккумуляторы в дата-центре CyberBunker 2.0

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

CyberBunker входил в топ хостеров для аниме. К ним предъявляются специфические требования, в том числе гарантия анонимности клиентов. Хотя Кибербункера больше нет, но другие защищённые и анонимные хостеры продолжают работать. Они обычно физически размещены за пределами американской юрисдикции, в офшорных зонах, и декларируют максимальную приватность. Ниже сервисы расположены по позициям в рейтинге сайта любителей аниме:
Anonymously.ioAruba.itShinJiru.comCCIHosting.comHostingFlame.orgCyberBunker.comDarazHost.comSecureHost.com
Анонимный хостинг в литературе

Бывшая фотография из профиля в Facebook Свена Олафа Кампхейса. После ареста в 2013 году он грубо разговаривал с властями и заявлял о независимости Республики Кибербункер

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

Султанат Кинакута — маленький островок в углу моря Сулу, в середине пролива между Калимантаном и филиппинским островом под названием Палаван. Во время Второй мировой войны японцы использовали Кинакуту как плацдарм для нападения на голландскую Ост-Индию и Филиппины. Там была база ВМФ и аэродром. После войны Кинакута вновь обрела независимость, в том числе финансовую, благодаря запасам нефти.

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

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

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

— Когда её закончат, получится самый большой маршрутизатор в мире. В соседних комнатах мы разместим компьютеры и систему хранения. По сути — самый большой в мире RAID с большим пребольшим кешем.

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

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

У Рэнди в кармане — отксеренная карта из книги. Он вынимает её и подносит к лампочке. Разумеется, высоко в горах отмечен «ВХОД В БОМБОУБЕЖИЩЕ И КОМАНДНЫЙ ПУНКТ».Нил Стивенсон. «Криптономикон»

Крипта заняла ту же экологическую нишу, какую в реальном финансовом мире занимает Швейцария.

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

Даже на такой панели как VMmanager KVM вы можете настроить OVH IP на купленном выделенном сервере ABCVG.net.

Сами ISP System настолько уважают свою панель что даже удалили статью как настроить ее:

Мы не рекомендуем использовать серверы дата-центров OVH / SoYouStart для работы VMmanager.))

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

А есть проще же: клац. А купить серверы можно здесь: клац.

О компании
Югорский лесопромышленный холдинг — одно из ведущих лесозаготовительных и деревообрабатывающих предприятий Уральского федерального округа. Учредителем компании выступает правительство Ханты-Мансийского автономного округа.

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

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

Перед стартом проекта команда основательно подготовилась к переходу на отечественное ПО. Более 80% сотрудников прошли обучение по продуктам Astra Linux: от базового администрирования ОС до курсов по ALD Pro. После этого компания приступила к реализации проекта.

Ситуация до старта и задачи проекта
До перехода на российское ПО инфраструктура компании была построена на продуктах Microsoft. Доменная структура работала на Active Directory, а виртуализация — на Hyper-V.

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

Отсюда сформировались задачи проекта:
Импортозамещение. Выполнение требований регуляторов и переход на отечественные решения.Формирование инфраструктуры в рамках единого контура. Заказчик стремился избежать технологического «зоопарка» от разных вендоров и хотел создать единую экосистему ПО.Стабильность. Возможность оперативно решать вопросы совместно с технической поддержкой.Так компания выбрала стек решений «Группы Астра»: VMmanager, ОС Astra Linux, ALD Pro, RuPost и RuBackup.

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

VMmanager — инструмент для создания отказоустойчивой виртуальной среды, а также для централизованного управления аппаратной и контейнерной виртуализацией.
Одним из ключевых преимуществ VMmanager стала возможность централизованного удалённого управления виртуальной инфраструктурой. Платформа ISPsystem полностью закрыла задачи, которые ранее решались с помощью Microsoft Hyper-V:


Кроме того, новое решение открыло надёжные возможности интеграции для резервного копирования — связку VMmanager и RuBackup.
Факторы выбора платформы VMmanager:


Этапы внедрения
VMmanager стал первым продуктом, внедрённым в рамках проекта импортозамещения — новые сервисы требовали развёртывания в виртуальной среде.

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

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

Особенно полезной для предприятия стала интеграция VMmanager с RuBackup. Взаимодействие продуктов через LDAP-аутентификацию и системные учётные записи позволило объединить процессы резервного копирования и восстановления в единый контур и упростить администрирование сервисов.

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

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

В результате проекта удалось развернуть:
комплексную виртуализацию сервисов предприятия: от ALD Pro до СКУД и таможенного ПО.5 площадок по минимум 2 ноды для отказоустойчивости в каждой.Более 100 ВМ для различных сервисов в общей сложности.
Планы по развитию
В компании планируют дальнейшее развитие сервисов и рассматривают внедрение дополнительных экосистемных продуктов для управления физической ИТ-инфраструктурой и мониторинга.

Мнение заказчика
Балакин Максим Сергеевич
Благодаря внедрению продукта VMmanager компания получила расширенный набор инструментов для более гибкого управления инфраструктурой виртуальных машин. Нам удалось объединить несколько важных аспектов в единое целое: требования регуляторов, увеличить уровень отказоустойчивости и, самое важное, получить ценный опыт.
Начальник отдела Автоматизированных систем управления (АСУП)

Экономика облака начинается не с цены виртуальной машины и выбора «купить сервер или арендовать». Правильная точка входа для CIO и CFO — показатель cost-per-workload: стоимость обработанной транзакции, пользовательского часа, расчетного задания, тестового контура, витрины данных и продуктовой среды.

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

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

В расчет всегда попадают «обязательные дополнения». Там есть СХД, сеть, лицензии, резервирование, электричество, охлаждение, место в стойке, администрирование, мониторинг, ИБ, обновления, аварийные замены, запас по мощности, закупочные циклы и стоимость капитала. Добавим сюда же технологическое «старение»: через три года час CPU уже не тот. В моделях реальной стоимости это прямо учитывается через срок жизни оборудования, NPV и деградацию производительности железа относительно рынка.

В общем, попытка напрямую сопоставить «виртуальную машину в облаке» и «купленный сервер» ни к чему продуктивному не приведет. Для CIO и CFO важны другие показатели:
сколько стоит полезная нагрузка;какова фактическая утилизация;что происходит в пике;сколько стоит простой;сколько стоит недозаказанная мощность;сколько времени занимает запуск нового проекта.Если у компании нагрузка ровная, предсказуемая, с высокой утилизацией и зрелой эксплуатацией, собственный контур может быть рационален. Но если инфраструктура покупается под пик, а большую часть времени стоит полупустой, экономика быстро меняется.

Утилизация как основа эффективности
Для облака критична утилизация. В классической формуле сравнения облака и собственного дата-центра это видно довольно отчетливо.

UserHours_cloud × (Revenue − Cost_cloud) ≥ UserHours_datacenter × (Revenue − Cost_datacenter / Utilization)
Смысл простой: собственная инфраструктура должна окупаться не номинальной стоимостью сервера, а стоимостью сервера, деленной на фактическую утилизацию. Если железо загружено на 30%, полезная единица работы становится сильно дороже. Не потому что сервер плохой. Потому что две трети мощности оплачены, но не создают ценности.

Допустим, контур куплен под пик в 1000 условных единиц мощности. Средняя нагрузка — 350. Финансово компания оплачивает 1000, бизнес фактически потребляет 350. Остальное — страховка от пика, закупочного цикла, медленного capacity planning и страха «вдруг не хватит».

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

Эластичность как снижение рисков
Эластичность часто продают как «можно быстро масштабироваться». Для финансового директора важнее другое: эластичность переносит часть риска с компании на провайдера. О чем идет речь? Есть два риска.

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

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

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

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

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

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

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

И последнее — сценарий в группах компаний. Когда у головной компании есть ИТ-команда, у дочерних обществ тоже есть, но разной зрелости. Облачная модель помогает унифицировать сервисы, стандарты безопасности и платформенные решения, сохранив при этом прозрачность потребления для разных бизнес-единиц. Такой подход особенно полезен для компаний, растущих через M&A.

Когда облако будет невыгодным
Честный разговор об экономике требует и обратной стороны. Все-таки есть сценарии, где собственные мощности компании выигрывают.
Если нагрузка стабильная 24/7, хорошо прогнозируется, имеет высокую утилизацию и не требует быстрого масштабирования, купленная инфраструктура может выиграть. Особенно если компания умеет эффективно эксплуатировать железо, имеет дешевую площадку, зрелую ИБ и понятный горизонт загрузки.Если компания сама по себе является рынком, на котором можно создать собственного инфраструктурного «монополиста» для головной организации, дочерних обществ и внутренних продуктов. Другими словами, для отдельных крупнейших групп собственное облако может выступать как мощная индустриальная платформа.Небольшой контекст для второго пункта: масштаб без зрелости не работает. Купить серверы и поставить портал самообслуживания не равно быть провайдером. Нужны каталог услуг, SLA, capacity management, FinOps, chargeback или хотя бы showback, стандарты платформы, процессы обновлений, поддержка, эксплуатация 24/7, безопасность, документация и внятная модель ответственности.
Если внутренний ИТ уже умеет оказывать сервис как провайдер, экономика собственного облака может быть сильной. Если нет — внешний облачный провайдер выигрывает не только ценой железа, но и операционной зрелостью.У компании есть технические ограничения. К примеру, нагрузки с дорогим трафиком, чувствительные к задержкам системы, legacy с тяжелой миграцией, лицензии, привязанные к ядрам или площадке, и др. В таких случаях миграция «перенесем все как есть в облако» редко дает эффективность. Сначала надо понять профиль workload, потом уже выбирать модель.
Что считать перед переходом
Хороший бизнес-кейс начинается с инвентаризации нагрузки.

Нужно посчитать фактическую утилизацию CPU, RAM, storage и сети. Не выделенную, а реально потребленную. Затем — профиль нагрузки: средняя, пик, сезонность, окно обработки, допустимое время простоя.

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

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

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

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

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

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

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

Есть одно «но». Гибридная модель работает только тогда, когда провайдер одинаково хорошо закрывает все виды поставки. На практике у многих игроков рынка on-premise либо формальная опция, либо отдельный продукт с другой архитектурой и другой командой. Поэтому выбор облачного поставщика является такой же частью экономического решения, как выбор между облаком и собственной инфраструктурой.

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

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

О компании и ИТ-отделе
XDataPlus — компания, предоставляющая широкий спектр услуг в сфере ИТ-инфраструктуры: от аренды виртуальных и физических (выделенных) серверов до специализированных решений с GPU для задач, связанных с нейросетями и высокопроизводительными вычислениями. Ключевым преимуществом XDataPlus является собственный дата-центр нового поколения, что позволяет предлагать клиентам гибкие, надёжные и масштабируемые решения.

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

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

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

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

Архитектура проекта до и после внедрения решений ISPsystem
До внедрения: ИТ-инфраструктура не имела централизованной системы управления и автоматизации ключевых процессов.

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

В аппаратной части Заказчик использует: Серверные платформы H3C UniServer R4900 G6/G7 и Gooxi SYR4110G-D24R-G5 на базе высокопроизводительных процессоров (AMD EPYC 9554/9654/9965, Intel Xeon Gold 6530/6780E), ОЗУ DDR5 (4800–6400 МГц) и высокоскоростных NVMe-накопителей.

Программная архитектура реализована на базе экосистемы решений ISPsystem, включающей следующие продукты:
BILLmanager — биллинг и учёт потребляемых ресурсов.DNSmanager — централизованное управление DNS-записями.VMmanager — управление кластером виртуализации.DCImanager — автоматизация предоставления выделенных и виртуальных серверов.Также в проекте используется панель управления хостингом ispmanager, партнёра ISPsystem.

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

Как решения ISPsystem применяются на практике
В рамках проекта XDataPlus использует два ключевых решения ISPsystem:
BILLmanager играет центральную роль в коммерческой части бизнеса: автоматизирует учёт предоставляемых ИТ-услуг (включая аренду виртуальных и физических серверов), процессы тарификации, выставления счётов и управления клиентскими услугами. Это существенно повышает прозрачность финансовых операций и упрощает взаимодействие с клиентами.
BILLmanager — универсальная платформа автоматизации бизнеса по предоставлению и продаже ИТ-услугVMmanager отвечает за управление виртуализацией и ресурсами кластера: оптимизирует выдачу и распределение ресурсов для виртуальных серверов (вычислительные мощности, ОЗУ, хранилища). Также решение обеспечивает централизованное управление виртуальной инфраструктурой и упрощает масштабирование.
VMmanager — платформа автоматизации бизнеса по аренде виртуальной инфраструктурыРезультаты внедренияРешения ISPsystem сыграли ключевую роль в развитии ИТ-инфраструктуры XDataPlus, позволив перейти от разрозненных процессов к единой автоматизированной экосистеме управления дата-центром.

С практической точки зрения, внедрение позволило XDataPlus:

Компания Google представила план по обеспечению безопасности квантовой эры к 2029 году посредством перехода к постквантовой криптографии (PQC).

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

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

Квантовые компьютеры будут представлять значительную угрозу для существующих криптографических стандартов, и в частности для шифрования и цифровых подписей. Угроза шифрованию актуальна сегодня в связи с атаками типа «хранить сейчас — расшифровывать позже», в то время как цифровые подписи представляют собой угрозу будущего, требующую перехода к квантовым компьютерам с предварительным копированием (PQC) до появления криптографически значимых квантовых компьютеров (CRQC). Именно поэтому мы скорректировали нашу модель угроз, чтобы отдать приоритет миграции на PQC для служб аутентификации — важного компонента онлайн-безопасности и миграции цифровых подписей. Мы рекомендуем другим инженерным группам последовать нашему примеру.

В качестве примера нашей постоянной приверженности принципам PQC (Protection Quality Control – проверка качества подписи) можно привести интеграцию в Android 17 защиты цифровой подписи PQC с использованием ML-DSA в соответствии со стандартами Национального института стандартов и технологий (NIST). Это позволяет нашим клиентам напрямую получать доступ к передовым технологиям PQC, развивая поддержку PQC в Google Chrome, предоставляя облачные решения PQC, а также аналитические данные и рекомендации для руководителей, стремящихся к внедрению PQC.

cloud.google.com/security/resources/post-quantum-cryptography

05.05.2026
Компания nLighten назначила Дейм Доун Чайлдс генеральным директором, а Мэтью Харриса — финансовым директором на фоне роста спроса на периферийную инфраструктуру благодаря искусственному интеллекту.
Компания nLighten, ведущий поставщик инновационных услуг для периферийных центров обработки данных в Европе, сегодня объявила о назначении Дамы Доун Чайлдс на должность генерального директора и Мэтью Харриса на должность финансового директора, что еще больше укрепит ее руководящую команду на следующем этапе роста компании.


05.02.2026
Центр обработки данных nLighten в Штутгарте будет направлять избыточное тепло в местную систему отопления.
nLighten и Wärmelösungen Synergiepark Stuttgart поставят здания it.schule и DEKRA.
Избыточное тепло, выделяемое центром обработки данных, будет продаваться компании Synergiepark Stuttgart, которая будет его перерабатывать и распределять. Местная инфраструктура рассчитана на выработку до 1,8 мегаватт тепловой энергии.
В качестве теплоносителя используется замкнутая система водоснабжения, которая улавливает тепло от серверов центра обработки данных и с помощью тепловых насосов повышает его до температуры, необходимой клиентам. Компания Synergiepark Stuttgart, как поставщик, обеспечивает устойчивое, надежное и экономически эффективное теплоснабжение региона.

02.02.2026
Компания nLighten расширяет свою сеть центров обработки данных во Франции за счет приобретения площадки в Париже.
Стратегическое приобретение укрепляет позиции nLighten на ключевом европейском рынке и подтверждает приверженность компании развитию устойчивой цифровой инфраструктуры.
Объект в Эмерайнвиле станет восьмым объектом nLighten во Франции и пополнит портфель nLighten, насчитывающий более 30 центров обработки данных на семи рынках. Стратегически расположенный в восточном кластере центров обработки данных Парижа, примерно в одном километре от существующего объекта nLighten PAR1, этот объект продолжит обслуживать основного клиента oXya в рамках долгосрочного генерального соглашения об оказании услуг, в то время как дополнительные мощности будут предоставлены корпоративным клиентам через партнеров по каналам продаж в соответствии с основной розничной стратегией nLighten.
Этот комплекс спроектирован для поддержки конфигураций высокой плотности и готовности к внедрению ИИ, обеспечивая масштабируемую инфраструктуру, которая может развиваться в соответствии с требованиями заказчика. Подход nLighten делает упор на предоставление устойчивой, взаимосвязанной инфраструктуры, адаптированной к потребностям предприятий, с бесперебойной связью между своими площадками.

27.01.2026
Компания nLighten Germany заключила новое соглашение с энергопровайдером Uniper.
Новое соглашение о поставках электроэнергии обеспечивает центры обработки данных nLighten в Германии гарантированным, измеримым ежечасно и возобновляемым базовым электроснабжением.
Возобновляемая энергия, способная обеспечить базовую нагрузку, и почасовая прозрачность.
Ключевым отличием этого соглашения является способность гидроэнергетики обеспечивать базовую нагрузку. В отличие от возобновляемых источников энергии, зависящих от погодных условий, таких как ветер или солнце, гидроэнергетический компонент непрерывно поставляет безуглеродную энергию — независимо от погодных условий или времени суток. Даже когда немецкая электросеть имеет более высокое содержание углерода, nLighten может постоянно использовать возобновляемую энергию для своей деятельности.
Партнерство обеспечивает nLighten поставками возобновляемой электроэнергии, сертифицированной независимой организацией (TÜV Süd), с возможностью почасового измерения. Вместо того чтобы полагаться на ежегодные гарантии происхождения, nLighten теперь может отслеживать выработку конкретной гидроэнергии ежечасно.

26.11.2025
Новое соглашение в энергетической сфере повышает прозрачность использования возобновляемых источников энергии в работе французского центра обработки данных nLighten.
Компания nLighten заключила новое соглашение о поставках возобновляемой энергии, охватывающее все ее центры обработки данных во Франции.
Новое соглашение включает в себя Axpo, крупнейшего швейцарского производителя электроэнергии и международного лидера в сфере торговли энергией и маркетинга солнечной и ветровой энергии, и независимого производителя электроэнергии (IPP). В соответствии с соглашением, Axpo обеспечивает стандартное электроснабжение французских объектов nLighten, одновременно принимая на себя ответственность за выработку возобновляемой энергии на ветроэнергетических установках IPP, которая затем передается nLighten. Такая структура позволяет Axpo вмешиваться, когда выработка ветровой энергии недостаточна, обеспечивая бесперебойное электроснабжение предприятий nLighten, в то время как IPP обеспечивает специализированное отслеживание выработки возобновляемой энергии.

21.10.2025
Компания nLighten устанавливает новый стандарт устойчивого развития, представив первые результаты оценки ICFEn для центров обработки данных в Великобритании, Германии и Испании.
Европейский поставщик услуг центров обработки данных публикует новаторские интегрированные показатели безуглеродной энергетики, выходящие за рамки отраслевых стандартов и измеряющие воздействие на окружающую среду в режиме реального времени.
Объекты nLighten в Великобритании, Германии и Испании достигли высоких показателей ICFEn благодаря инновационным стратегиям закупок в области возобновляемых источников энергии и программ рекуперации тепла. В период с апреля по июнь 2025 года центры обработки данных компании в Великобритании достигли показателя ICFEn в 94,61%, значительно превзойдя средний региональный показатель CFE в 56,47%.

01.07.2025
Новое соглашение в энергетической сфере обеспечивает большую прозрачность в отношении возобновляемых источников энергии в работе центров обработки данных nLighten в Великобритании.
Компания Conrad Energy постепенно подключает все счетчики nLighten в Великобритании, консолидируя ранее разрозненный подход к закупке энергии. Ежемесячно nLighten получает от Conrad Energy подробную информацию о своих поставках возобновляемой энергии. Эта информация включает в себя данные на уровне отдельных активов о доле ветровой, солнечной и биомассы в энергетическом балансе. Данные позволяют nLighten отслеживать использование возобновляемых источников энергии с течением времени и рассчитывать предотвращенные выбросы CO₂ на основе фактического профиля выработки электроэнергии.

01.07.2025
Компания nLighten назначила Андреаса Хердена управляющим директором в Германии.
Благодаря Хердену компания nLighten получает в свой штат отраслевого эксперта, который поможет и дальше стимулировать рост и устойчивое развитие сети периферийных центров обработки данных в Германии.
Херден обладает многолетним опытом работы в секторе центров обработки данных и цифровой инфраструктуры. До прихода в nLighten он занимал должность старшего вице-президента по продажам в континентальной Европе в компании Green Mountain. Его карьера также включает работу в качестве директора по продажам в Lefdal Mine Data Centers и различные должности в Equinix, в том числе директора по продажам в автомобильном, финансовом и производственном секторах. Этот опыт укрепил его репутацию признанного эксперта отрасли.
В nLighten Херден сосредоточится на укреплении присутствия компании в промышленных и городских регионах Германии для поддержки ее миссии по созданию устойчивой, высокопроизводительной периферийной инфраструктуры.

24.06.2025
Компания nLighten выходит на испанский рынок, чтобы возглавить новую эру локальной, устойчивой и сверхсвязанной цифровой инфраструктуры.
Компания nLighten, европейский оператор периферийных центров обработки данных, трансформирующий цифровую инфраструктуру в Европе, выходит на испанский рынок с четким и революционным предложением: приблизить технологии к пользователям с помощью локальных, устойчивых и сверхсвязанных центров обработки данных.
Приобретя год назад свой первый центр обработки данных в Мадриде и планируя расширение в другие ключевые города, nLighten открывает новые горизонты, предлагая модель, которая переосмысливает роль центров обработки данных: более близкие, эффективные и экологичные. Компания поддерживает текущие потребности в цифровой инфраструктуре, необходимые для развития Интернета вещей, промышленных приложений в реальном времени, игр, дополненной/виртуальной реальности и иммерсивного потокового видео.

18.06.2025
Компания nLighten выбрала Incógnito для поддержки своей маркетинговой стратегии на испанском рынке.
Компания nLighten, европейский поставщик услуг обработки данных на периферии сети, выбрала независимое коммуникационное и маркетинговое агентство Incognito для управления своей маркетинговой стратегией в Испании.
Альянс между nLighten и Incógnito направлен прежде всего на позиционирование nLighten на испанском рынке и продвижение ее стратегического позиционирования как инновационного бренда в европейской цифровой экосистеме.
Кроме того, это сотрудничество укрепит имидж и узнаваемость nLighten в Испании, подчеркнув ее ключевую роль в стимулировании технологической и устойчивой трансформации в этом секторе. nLighten предлагает уникальное ценностное предложение для клиентов, создающих свою цифровую инфраструктуру в периферийных центрах обработки данных.
Компания nLighten, предлагающая ценностное предложение, основанное на создании цифровой платформы стратегически распределенных центров обработки данных, обеспечивающих первоклассный сетевой доступ для предприятий, частных пользователей и мобильных сотрудников, начала свою европейскую экспансию с помощью инновационной модели периферийных центров обработки данных, уже работающей в Великобритании, Франции, Германии, Нидерландах, Бельгии и Швейцарии. В Испании компания укрепляет свои позиции после приобретения и адаптации стратегически расположенного объекта в Мадриде. Агентство

04.06.2025
Компания nLighten назначила Кристофа Тиу на должность коммерческого директора.
Кристоф Тиу назначен коммерческим директором (CCO). В качестве нового члена руководящей команды компании Кристоф будет отвечать за рост выручки, масштабирование коммерческих операций и повышение вовлеченности клиентов.
Обладая более чем двадцатилетним опытом руководства в сфере цифровой инфраструктуры, Кристоф продемонстрировал впечатляющие результаты в стимулировании роста и инноваций в секторе центров обработки данных. Его последняя должность – вице-президент по продажам (EMEA) в компании Equinix, где он сыграл ключевую роль в развитии новых сегментов рынка, создании высокотехнологичных экосистем и продвижении облачных и ИИ-совместимых инфраструктур. В его карьере также есть руководящие должности в Cisco WebEx и активное участие в стартап-экосистеме в качестве члена совета директоров French Tech Amsterdam.
Кристоф, базирующийся в Амстердаме, будет курировать коммерческие команды на всех существующих и будущих рынках nLighten.

07.05.2025
Компания nLighten расширяет свою команду руководителей за счет стратегических назначений на руководящие должности.
Компания nLighten, ведущая платформа цифровой инфраструктуры и лидер европейского рынка периферийных центров обработки данных, объявляет о расширении своей руководящей команды путем назначения двух топ-менеджеров.
Ханс Нипшаген присоединился к компании 1 мая, привнеся более двадцати лет опыта в сфере корпоративных продаж, стратегии работы с каналами продаж и регионального руководства. До прихода в nLighten Ханс занимал должность регионального вице-президента по продажам через каналы сбыта в регионе EMEA в компании Akamai Technologies, где успешно реструктурировал организацию продаж через каналы сбыта в регионе EMEA, повысив масштабируемость и согласованность с командами прямых продаж. За 13 лет работы в Akamai Ханс также руководил продажами в сфере кибербезопасности на Ближнем Востоке, в Африке, Центральной и Восточной Европе, а также занимал должность руководителя подразделения в странах Бенилюкса и был членом совета директоров Akamai в Нидерландах и за рубежом.
Арно ван Геннип присоединился к nLighten в апреле, привнеся обширный опыт руководства в сфере эксплуатации критически важной инфраструктуры и устойчивого развития. До недавнего времени он занимал должность вице-президента по глобальному операционному инжинирингу IBX в Equinix, курируя глобальное операционное инжиниринговое обеспечение. За девять лет работы в Equinix Арно также руководил стратегическими инициативами в области экологической устойчивости эксплуатации, управления объектами и инженерной трансформации. До этого он 15 лет проработал в Colt Technology Services на различных руководящих должностях, курируя проектирование, внедрение и техническую инфраструктуру центров обработки данных в Западной Европе.

16.04.2025
nLighten и Shell Spain объединяют усилия для продвижения интеграции возобновляемых источников энергии в центры обработки данных.
Компания nLighten заключила соглашение о покупке электроэнергии (PPA) и договор на поставку электроэнергии с компанией Shell Spain, который вступил в силу 1 апреля 2025 года.
В рамках этого соглашения Shell будет поставлять возобновляемые источники энергии для nLighten, поддерживая усилия центра обработки данных по оптимизации показателя безуглеродной энергетики (CFE), сохраняя при этом гибкость масштабирования в зависимости от спроса и предложения в режиме реального времени. В периоды снижения выработки возобновляемой энергии Shell будет управлять оставшимися запасами энергии для обеспечения бесперебойной работы. Такой подход гарантирует надежность энергоснабжения и подтверждает приверженность nLighten созданию более устойчивой цифровой инфраструктуры.

10.04.2025
Смена руководства в nLighten UK
В рамках своего продолжающегося роста в Европе компания nLighten, ведущая платформа цифровой инфраструктуры и лидер европейского рынка периферийных центров обработки данных, объявляет о назначении Джастина Несбитта на должность управляющего директора nLighten UK.
Джастин присоединился к nLighten в октябре 2023 года в качестве директора по продажам в Великобритании после приобретения компанией nLighten компании Proximity Data Centres. С тех пор он сыграл ключевую роль в развитии нового бизнеса, укреплении стратегических партнерств и повышении позиций nLighten как лидера в области решений для периферийных центров обработки данных. Его назначение отражает как его исключительные лидерские качества, так и обширный отраслевой опыт.
Обладая более чем 25-летним опытом работы в секторах центров обработки данных и связи, Джастин привнесет в компанию обширные знания и подтвержденный послужной список успехов. До прихода в nLighten он занимал руководящие должности в сфере продаж в компании Equinix, где внес значительный вклад в рост компании и наладил прочные отношения с ключевыми заинтересованными сторонами в отрасли.

20.03.2025
Компания nLighten представляет nConnect
Компания nLighten, ведущая платформа цифровой инфраструктуры и лидер европейского рынка периферийных центров обработки данных, запустила nConnect, свою новую платформу сетевых сервисов.
Комплексный спектр услуг и основные преимущества
nConnect предоставляет клиентам широкий спектр услуг, включая Cloud Connect, DC Connect, Direct Internet Access (DIA) и IP Transit (IPT), которые беспрепятственно интегрируются с их присутствием в центрах обработки данных nLighten. Это обеспечивает бесперебойное подключение и оптимизированную интеграцию сети, предлагая клиентам:
Быстрое выделение ресурсов и гибкие варианты пропускной способности. Новейшая сетевая архитектура центров обработки данных с поддержкой сегментации, защиты от DDoS-атак и расширенной аналитики. Стандартизированное соглашение об уровне обслуживания (SLA) и модель ценообразования без долгосрочных контрактов. Комплексное решение для множества услуг, упрощающее процесс и снижающее затраты. Обеспечение скорости, гибкости и современной сетевой архитектуры.Йоахим ван Колленбург, вице-президент по управлению продуктами в nLighten, подчеркивает преимущества nConnect: «С nConnect клиенты получают выгоду от сверхбыстрого развертывания, гибких вариантов пропускной способности и новейшей сетевой архитектуры центров обработки данных. Это особенно ценно для предприятий, стремящихся создать высокопроизводительный центр обработки данных на периферии сети в новом регионе, или для компаний, ищущих экономически эффективные решения для аварийного восстановления со встроенной геоизбыточностью».
Расширение возможностей подключения на ключевых европейских рынках
Теперь nConnect доступен на четырех из семи рынков, где работает nLighten, включая:
Нидерланды: Амстердам (AMS1 и AMS2) Германия: Франкфурт (FRA1) Франция: Париж (PAR2) Соединенное Королевство: Бирмингем (BHX1), Бристоль (BRS1), Честер (MAN1), Лидс (LBA1), Ливерпуль (PLP1), Милтон-Кинс (LTN1), Ноттингем (EMA1) и Суиндон (BRS2).
17.02.2025
Компания nLighten укрепляет свою руководящую команду, назначив Ника Рида председателем совета директоров.
В связи с продолжающимся расширением платформы цифровой инфраструктуры nLighten по всей Европе, компания объявляет о назначении Ника Рида председателем совета директоров nLighten.
Ник более 16 лет проработал на руководящих должностях в глобальных компаниях в сфере телекоммуникаций, инфраструктуры и технологий. В настоящее время он занимает ряд должностей в советах директоров компаний, специализирующихся на цифровой инфраструктуре в регионе EMEA и США, включая должность старшего советника Global Infrastructure Partners (ныне часть BlackRock), консультанта I Squared Capital, председателя совета директоров EXA Infrastructure, а также независимого директора Booking Holdings Inc., Radius Global Infrastructure и Oak Consortium.
Ранее Ник 22 года проработал в Vodafone Group Plc, где сыграл ключевую роль в формировании глобальной стратегии компании. Он занимал должность генерального директора группы и был членом совета директоров с 2014 по 2022 год, руководя Vodafone в период масштабной трансформации бизнеса, расширения сети и операционной эволюции.
До прихода в Vodafone Ник занимал руководящие должности в сфере глобальных финансов в Miller Freeman Worldwide Plc в качестве финансового директора группы компаний, а также в Federal Express Corporation в течение 10 лет. Ник является дипломированным специалистом по управленческому учету и в 2022 году получил почетную степень доктора делового администрирования. Он давно выступает за разнообразие и инклюзивность, являясь участником программы ООН HeForShe и комиссаром ООН по широкополосной связи.
В nLighten Ник будет использовать свой обширный отраслевой опыт для поддержки стратегических планов расширения компании, коммерческого роста и повышения операционной эффективности. Его глубокое понимание глобальных телекоммуникационных рынков и их меняющихся потребностей будет иметь решающее значение для руководства командой nLighten по мере расширения присутствия компании в Европе.

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

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

25.11.2024
Компания nLighten представила ребрендинг компании Euclyde в nLighten France на выставке DC World в Париже.
Компания nLighten, ведущая европейская платформа цифровой инфраструктуры, рада объявить о ребрендинге Euclyde в nLighten France после приобретения центров обработки данных Euclyde в 2023 году.
В рамках ребрендинга компания nLighten продолжает продвигать свой бренд на европейской платформе, чтобы повысить узнаваемость своих предложений и предоставить клиентам новые возможности и услуги. В операционном плане клиенты по-прежнему будут получать ту же местную поддержку от своих выделенных контактных лиц. Французская команда продолжит активно участвовать в проектах, связанных с их клиентами.
Помимо общенациональных операций в периферийных центрах обработки данных в София-Антиполисе, Париже, Лионе, Безансоне и Страсбурге, клиенты nLighten France теперь получат возможности для расширения своей деятельности по всей Европе благодаря периферийным центрам обработки данных группы в Германии, Испании, Великобритании, Нидерландах, Бельгии и Швейцарии.

20.06.2024
Компания nLighten представляет инновационную интегрированную оценку CFE.
Благодаря новой метрике, разработанной в сотрудничестве с FEEM, компания теперь может измерять и сообщать о полном круглосуточном потреблении безуглеродной энергии в своих периферийных центрах обработки данных.
Исследование было разработано компанией nLighten в сотрудничестве с Фондом Эни Энрико Маттеи (FEEM), ведущим международным исследовательским центром по вопросам энергетики и окружающей среды, расположенным в Милане, Италия. Интегрированный показатель CFE, являющийся центральным элементом исследования, подчеркивает приверженность nLighten концепции круглосуточной безуглеродной энергетики, основанной на целостном подходе, включающем в себя межотраслевую интеграцию. Круглосуточная безуглеродная энергетика означает, что каждый киловатт-час потребляемой электроэнергии производится из безуглеродной электроэнергии, каждый час каждого дня, повсюду. Эта цель продвигается для достижения нулевых выбросов.
В отличие от традиционных показателей CFE, которые фокусируются исключительно на потреблении электроэнергии, подход nLighten расширяет анализ, включая как безуглеродную электроэнергию, так и тепло, производимое центрами обработки данных nLighten. Затем он интегрирует рекуперацию отработанного тепла в показатели устойчивого развития, которые выходят за пределы периметра центра обработки данных и охватывают связанные здания или системы. С помощью этой инициативы nLighten стремится обеспечить прозрачную оценку воздействия на окружающую среду и вклада в усилия по декарбонизации.

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

www.nlighten.com

Let's Encrypt стремится к созданию устойчивой к постквантовым технологиям инфраструктуры открытых ключей (PKI) для веб-сети. Мы планируем использовать сертификаты на основе дерева Меркла («MTC»), новый подход, который добавляет постквантовую аутентификацию в веб-среду без ущерба для скорости и надежности, благодаря которым TLS стал универсальным протоколом.

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

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

Этот комфорт постепенно ослабевает. В Соединенных Штатах пакет CNSA 2.0 Агентства национальной безопасности США с 2022 года направляет системы национальной безопасности на внедрение постквантовых алгоритмов в период с 2030 по 2035 год, а проект руководства NIST по переходу предусматривает отказ от RSA-2048 и P-256 после 2030 года и запрет их использования после 2035 года. Дорожная карта Европейского союза нацелена на системы высокого риска к концу 2030 года и на масштабную миграцию к 2035 году. Эти требования не являются прямыми обязательствами для общедоступной инфраструктуры открытых веб-сетей (PKI), но они устанавливают временные рамки на конец десятилетия, к которым уже стремятся поставщики, библиотеки и организации по стандартизации, на которые она опирается.
www.nsa.gov/Cybersecurity/Post-Quantum-Cybersecurity-Resources/
nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

В этом году сроки еще больше сократились. Google объявил о миграции своих сервисов к 2029 году, сославшись на ужесточение оценок потенциального появления CRQC. Cloudflare последовал его примеру, подтвердив аналогичное обязательство. Кроме того, Go 1.27 добавляет в стандартную библиотеку ML-DSA, стандартизированную NIST схему постквантовой подписи, что свидетельствует о том, что постквантовые подписи становятся практичной инфраструктурой.
blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/
blog.cloudflare.com/post-quantum-roadmap/
go.dev/doc/go1.27

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

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

ML-DSA-44, одна из самых компактных схем постквантовой подписи, стандартизированных NIST, имеет подпись длиной примерно 2420 байт. Алгоритмы, используемые сегодня в Web PKI, значительно меньше. Подписи RSA-2048 занимают 256 байт, а подписи ECDSA-P256 — 64 байта. Открытые ключи также больше: 1312 байт для ML-DSA-44, 256 байт для RSA-2048 и 64 байта для ECDSA-P256. Типичное рукопожатие Web PKI сегодня включает пять подписей и два открытых ключа. Замена их на эквиваленты ML-DSA приведет к тому, что одно рукопожатие TLS превысит 10 килобайт. Исследования Cloudflare показали, что при таком масштабе значительная часть TLS-соединений в реальных сетях выходит из строя, а остальные замедляются.

blog.cloudflare.com/another-look-at-pq-signatures/

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

Сертификаты дерева Меркла
За последний год появилась новая технология, называемая сертификатами дерева Меркла («MTC»), и мы считаем, что это перспективный путь развития постквантовой инфраструктуры открытых ключей для веб-технологий.

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

В типичном случае весь путь аутентификации при рукопожатии MTC состоит из одной подписи, одного открытого ключа и одного подтверждения включения. Это меньше, чем рукопожатие Web PKI, даже несмотря на то, что MTC используют постквантовые алгоритмы. Другой случай — это «автономная» форма. Она использует немного более длинные рукопожатия в качестве резервного варианта, когда контрольная точка клиента устарела.


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

Для нас это не совсем новая область. Let's Encrypt использует журналы прозрачности сертификатов с 2019 года. Эти журналы представляют собой деревья Меркла с возможностью добавления данных, ту же самую базовую структуру данных, на которой построены MTC, и которую мы используем в производственной среде в больших масштабах уже много лет.
letsencrypt.org/docs/ct-logs/

Cloudflare и Chrome уже проводят экспериментальную проверку возможности использования MTC на реальном интернет-трафике. Рабочая группа PLANTS IETF работает над стандартизацией этого подхода. Chrome объявил, что MTC являются предпочтительным способом добавления постквантовых сертификатов в публичный интернет.
blog.cloudflare.com/bootstrap-mtc/
datatracker.ietf.org/wg/plants/about/

Наши планы
Мы планируем поддерживать сертификаты на основе дерева Меркла как перспективное направление для постквантовой веб-инфраструктуры открытых ключей (PKI). Мы рассчитываем создать тестовую среду для выдачи сертификатов Меркла к концу 2026 года, а готовую к использованию в производственной среде — к 2027 году.

Это непростая задача. Выпуск MTC в масштабах Let's Encrypt требует существенных изменений во всей нашей инфраструктуре: в нашей системе выпуска, в протоколе ACME, который наши подписчики используют для получения сертификатов, в инструментах отзыва и эксплуатации, а также в инфраструктуре журналов прозрачности, которую включают в себя MTC. Мы участвуем в рабочих группах IETF PLANTS и ACME по мере формирования стандартов.

Наряду с работой над MTC, мы отслеживаем стандарты для подписей ML-DSA в X.509 RFC 9881 и TLS draft-ietf-tls-mldsa а также работу в экосистеме, от которой это зависит, например, добавление ML-DSA в стандартную библиотеку Go. Переход веб-PKI к постквантовой безопасности требует, чтобы все это появилось в браузерах, библиотеках и клиентах ACME, независимо от того, будут ли в конечном итоге предоставлены сертификаты MTC или сертификаты X.509, подписанные ML-DSA.
www.rfc-editor.org/rfc/rfc9881
datatracker.ietf.org/doc/draft-ietf-tls-mldsa/

Что это значит, если вы используете Let's Encrypt?
Сегодня ничего не меняется. Ваши текущие сертификаты Let's Encrypt будут по-прежнему выдаваться и продлеваться точно так же, как и всегда. Когда появятся постквантовые сертификаты от Let's Encrypt, они будут предоставляться так же, как и всегда: бесплатно, автоматически и доступны любому пользователю с клиентом ACME.

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

Если вы используете ACME-клиент или управляете конвейером выдачи сертификатов на основе ACME, сейчас самое время начать отслеживать работу рабочей группы PLANTS и обсуждения в списке рассылки mtcs@chromium.org Некоторые из грядущих изменений потребуют поддержки на стороне клиента, и экосистема выиграет от клиентов, готовых к поддержке на стороне выпуска сертификатов.

Замечание о более широком постквантовом переходе
Для всего интернет-сообщества: постквантовое шифрование — более актуальная проблема, поскольку любое TLS-соединение без постквантового обмена ключами потенциально может быть использовано для последующей расшифровки. Если вы используете серверы, убедитесь, что они поддерживают гибридный постквантовый обмен ключами (X25519MLKEM768). Основные браузеры и операционные системы уже поддерживают его, и включение этой функции на сервере — одно из самых эффективных действий, которые вы можете предпринять в этом году.

В заключение
С 2013 года мы создаём инфраструктуру для общедоступного интернета, исходя из принципа, что безопасность должна быть доступна каждому, автоматически и бесплатно. Квантово-цифровой переход — это смена поколений в том, как эта безопасность работает «под капотом».

Компания запустила услугу доверенного администратора .ru/.рф/.su для нерезидентов. Сервис позволит иностранным клиентам сохранить и продолжить управление доменами в российских национальных зонах с учетом новых требований к идентификации администраторов.

С 1 сентября 2026 года вступает в силу требование Федерального закона № 569-ФЗ, которое вводит обязательную идентификацию администраторов доменов в зонах .ru,.рф и .su через портал «Госуслуги» (ЕСИА). Для нерезидентов такая процедура может быть затруднена из-за необходимости локального присутствия для создания подтвержденной учетной записи в ЕСИА. Услуга доверенного администратора позволяет соблюсти новые требования: домен регистрируется на компанию Рег.ру, уже прошедшую идентификацию, а фактическое управление доменом — продление, DNS и другие настройки — остается за нерезидентом через его личный кабинет в Рег.ру.

Trustee-сервисы широко используются на международном доменном рынке: во многих странах регистрация национальных доменов возможна только при наличии локального присутствия или выполнении специальных требований. Новый сервис Рег.ру решает аналогичную задачу для иностранных владельцев доменов в российских зонах .ru,.рф и .su.
www.reg.ru/user/account/domain_identification

Рег.ру — самый массовый регистратор в России, и среди наших клиентов порядка 80 тысяч нерезидентов, для которых важно сохранить свои онлайн-активы в российских доменных зонах. Новый сервис позволит им сделать это без лишних сложностей: выполнить требования законодательства и при этом продолжить управлять доменами в привычном личном кабинетеотметила Ирина Белоус, руководитель отдела развития сервисов Рег.ру.

Запуск trustee-сервиса стал частью подготовки доменной экосистемы компании к новым законодательным требованиям. Сейчас идентификацию через Госуслуги уже могут проходить физические лица и индивидуальные предприниматели в Рег.ру. В ближайшее время Рег.ру планирует добавить функционал для юридических лиц. По состоянию на начало июня 2026 года идентификацию через ЕСИА прошли администраторы 456 тысяч доменных имен в Рег.ру.

Экспертная статья «Точка, точка, запятая»: как появились привычные нам знаки препинания и при чём тут Венеция?», опубликованная в блоге хостинг-провайдера VPS серверов RUVDS на сайте «Хабр», завоевала победу в ежегодном конкурсе технических статей «Технотекст-8».
habr.com/ru/companies/ruvds/articles/971260/

Материал Алексея Костенкова был признан лучшим в номинации «Бесконечность идей». В общей сложности в шорт-лист вошли 14 материалов, опубликованных в блоге компании. Также в рамках конкурса RUVDS традиционно выступил в роли хранителя номинации «Системное администрирование».

В конкурсе могла принять участие любая статья, опубликованная на «Хабре» в период с 1 января 2025 года по 17 апреля 2026. В качестве одного из ключевых критериев значилось требование отсутствия применения ИИ при работе над материалом.

Статьи из блога хостинг-провайдера VDS серверов регулярно занимают призовые места на конкурсе: так, в прошлом году лучшими в своих номинация были признаны сразу два материала.
ruvds.com/ru/ruvds_2025_techtxt_winners/

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

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

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

По первой части:
Мы запускаем второе поколение Metal, нашу аппаратную платформу второго поколения, в которую интегрирован опыт двух лет работы с собственными сайтами.Ввод в эксплуатацию 4 новых площадок для размещения центров обработки данных.Улучшение процесса резервного копированияРасширяем наше предложение по Postgres, добавляя в него больше батарей.Укрепление защиты от DDoS-атак с помощью собственной сети CDN и сетевой инфраструктуры.Мы стремимся работать над стандартом ISO27001 для клиентов, у которых еще более деликатные вопросы соответствия требованиям.Мы также собираемся расширить функциональность основного продукта:
Как сделать историю об агентной железной дороге более изящной (примитив песочницы, удаленный сервер MCP, агенты, способные создавать шаблоны) — следите за обновлениями!Улучшаем наш фронтенд с помощью настоящей CDN.Внедрение системы самовосстановления на железной дорогеВозрождение шаблонов с улучшенным поиском и поддержкой создателей.Улучшение работы с API с помощью SDK.Более элегантная история IaCБолее безопасное развертывание с помощью маркировки функций.Мобильное приложение выходит в общий доступ (мы не забыли и о владельцах телефонов Android).Обновление опыта использования O11yРасширение защитных механизмов ИИ для предотвращения более разрушительных действий.Среди других важных задач, над которыми усердно работала команда поддержки и решений:
В бета-версии панели управления железнодорожным транспортом будет запущен агент поддержки. Мы также занимаемся модернизацией системы обработки запросов на основе искусственного интеллекта.Передача всей обратной связи по продукту непосредственно инженеру, работающему над данной функцией. Мы называем это «Приоритетная посадка 2».Мы также перерабатываем процесс демонстрации продукта, чтобы сделать процесс покупки намного, намного, намного лучше для компаний. От звонка до заключения договора вы можете пройти всего 30 минут.Вы увидите значительные инвестиции в AEO для повышения доступности моделей (пожалуйста/извините).Второй квартал 2026 года — это закладка основы надежности, третий квартал 2026 года — развитие продуктового цикла на её основе, а четвёртый квартал 2026 года и начало 2027 года — это время, когда облачные решения, изначально разработанные для производственных систем, станут стандартом по умолчанию.Мы собираемся изучить возможности улучшения ценообразования и упаковки в рамках цепочки поставок для агентов.Если этот обзор вас заинтересовал, читайте дальше, чтобы получить более подробную информацию по этим темам.

Шесть лет с момента запуска
Для начала, немного предыстории: меня зовут Анджело, я инженер по решениям в компании Railway. До работы в Railway я работал в Citrix, помогая управлять критически важными облачными средами для таких компаний, как Verizon и Lockheed. Это вежливый способ сказать, что я провел годы, участвуя в принятии решений по инфраструктуре других людей, в совещаниях, где моей задачей было честно говорить о том, что платформа делает хорошо, а что нет. Многие из ранних документов, чатов с клиентами и поддержки были созданы по моей инициативе. Пять лет спустя у нас замечательная команда и много знакомых вам людей. (И вы еще увидите их.)

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

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

Нас вдохновляет то, что работает: скорость git pushзагрузки активного URL-адреса и то, как платформа обрабатывает те части развертывания, о которых никто не хочет думать. В то время как многие спорят о будущем разработки, мы тестируем внутри компании совершенно новый опыт, который нам не терпится вам показать.

А затем есть еще и другая часть.

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

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

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

До
Когда мы запускали Railway, наша стратегия была проста: разработчики должны отправлять код, и он должен работать.

Этот контракт берет свое начало еще со времен Heroku в 2007 году. Все, что мы добавили, является его продолжением.

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

Я часто подчеркиваю, что в период примерно с 2014 по 2020 год разработчики перешли от git pushиспользования Helm-диаграмм, привязок IAM и управляемых сервисов, распределенных по трем облачным аккаунтам, к использованию управляемых сервисов.

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

Основные выводы из этого:
Побеждает тот, у кого самый быстрый цикл. Postgres, MySQL, Redis, Mongo — все в одном проекте, в одной частной сети, по одному счету. Минимизация переключения контекста любой ценой.Отправьте код, получите URL. Git — это контракт развертывания. CI/CD — это задача платформы, а не ваша.Вы платите за то, что используете. Ценообразование основано на потреблении, при этом счетчик останавливается, когда останавливается движение транспорта.Многорегиональная поддержка — это обязательное условие. Прошли те времена, когда выбор региона us-east-1 был равносилен смертному приговору. Выберите регион для каждой услуги; платформа сама позаботится о маршрутизации.Агент — первоклассный потребитель. Сервер MCP не является дополнительной интеграцией. Приложение Stripe не предназначено для маркетинга, и агентам нужны более совершенные базовые функции.Надежность — это скорее позиция, а не характеристика. Мы будем много говорить об этом в этой статье.
Что прошло хорошо
Огромное количество проектов, прошедших через Railway (более 50 миллионов сборок в месяц, более 12 000 новых пользователей в день, а также обработка сотен миллиардов запросов в процессе производства), мотивировало меня настолько, что это трудно описать словами.

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


На изображении выше вы можете увидеть рост числа развертываний на платформе. Люди внедряют решения с невероятной скоростью. Кстати, вы можете следить за этим в режиме реального времени по ссылке www.railway.com/stats

В течение последних трех месяцев мы также наращивали потенциал для создания более отзывчивой платформы, соответствующей вашему реальному темпу работы. Эти функции также будут постепенно внедряться в дальнейшем.
После сбоя в GCP мы завершили переключение на нашу полностью распределенную сеть маршрутизатора, что означает, что если выйдет из строя одно облако, мы сможем перенаправлять трафик по резервным каналам связи между Metal/AWS/GCP.Мы внедрили новый инструмент сборки, не зависящий от облачной платформы, что, как побочный эффект, значительно ускорило наши собственные внутренние сборки.Мы внедрили настоящий SSH в интерфейс командной строки и интерфейсы баз данных, отказавшись от старого SSH-прокси и открыв доступ к новому типу отладки с помощью агентов, который ранее был невозможен.В марте 2026 года мы запустили PostgreSQL с поддержкой высокой доступности в один клик на платформе Patroni. Внутрирегиональные реплики, автоматическое переключение при сбое, наконец-то реализована функция «управляемая база данных, которая переключается без запроса на обновление».Мы выпустили приложение Stripe, использующее их протокол APP для агентского управления. Теперь ИИ-агент может зарегистрировать вас, оплатить услугу и запустить работающую систему Railway в одном непрерывном цикле.Мы значительно улучшили поиск по шаблонам. В этом направлении ещё многое предстоит сделать (подробнее чуть позже).С каждым релизом мы улучшали и совершенствовали платформу, внедряя улучшения там, где видели возможности. Однако последний год не обошелся без трудностей и проблем, поэтому давайте обсудим их.

Что мы узнали
С чего начнём?

Мы могли бы отмахнуться от проблем, с которыми столкнулись, сказав: «Ну, интернет горит», пока эти разработчики выходят в онлайн, но это не совсем соответствует ценностям нашей компании (и нашим личным ценностям).

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

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

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

Вот как мы сейчас к этому относимся.

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

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

Инвестиции в коммуникационную сферу осуществлялись параллельно.

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

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

Доверие — это одновременно и опережающий, и отстающий индикатор. Нам предстоит его вернуть.

2. Разработка фронтенда еще не завершена.
Если вы перешли на Railway с Heroku, значит, вас интересовал бэкенд. И в этом мы отлично разбираемся. Разместите приложение Rails, API на Node, обработчик Python — платформа всё это обработает. Попробуйте разместить маркетинговый сайт, который должен быстро загружаться для пользователей в Сеуле, Мадриде и Сан-Паулу, и в ответ вам вежливо скажут: «А вы не рассматривали вариант размещения фронтенда на Vercel, а бэкенда у нас?»

Это прекрасная модель сочетания.

Это также налог на клиентов, которые предпочитают одну платформу и один счет.

Это можно увидеть в обсуждениях на Station. Клиенты в Азии и Южной Америке наблюдают время отклика в 5 секунд на бэкэнде, который действительно работает быстро после получения запроса. Клиенты решают проблему производительности, переключая DNS-записи с CNAME на A, поскольку маршрутизация на уровне периферии сети по-прежнему осуществляется через стороннего поставщика услуг, а не размещается совместно с Metal.

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

Мы создаём настоящую CDN-сеть. Сейчас она находится на стадии тестирования.

Хорошая новость в том, что комплексный набор инструментов для тестирования на периферии сети уже запущен, и мы проверяем работу CDN, WebSockets, SSE и заголовков как на тестовой, так и на производственной среде. Вскоре появится Railway Websites, и мы работаем над устранением этого пробела.

…и мы отслеживаем это расширение на нашей собственной железнодорожной станции.


3. Изделие должно петь.
Откройте Claude Code в терминале.

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

Мы еще не достигли цели.

Мы выпустили MCP-сервер. Мы выпустили протокол Stripe APP. Мы говорим об агентской железной дороге уже больше года. Путь от того, где мы находимся сегодня, к концепции «агент может делать все от начала до конца», реален, и он еще не завершен. У нас пока нет базового примитива песочницы, который необходим агентам для безопасной проверки своей работы. Удаленный MCP-сервер еще не достиг необходимого уровня. Видение ясно. Реализация идет полным ходом, и мы обязаны обеспечить вам прозрачность в этом вопросе.

Необработанные края нитей также хорошо видны.

Агенты по программированию сами себя блокируют, совершая слишком много вызовов CLI за слишком короткий промежуток времени (кстати, это исправлено). Другой пример: клиенты путаются в значении пункта «Использование агента» в их счете, потому что мы не провели достаточно четкой границы между собственными функциями ИИ Railway (диагностика с помощью ИИ, агент поддержки на панели управления) и агентами, которые клиенты запускают самостоятельно.

По мере того, как мы усваивали эти уроки, мы также проводили эксперименты и замечали первые признаки того, что помогает:
Процессы сборки больше не являются медленными, и закономерности, выявленные в ходе этой работы, начинают проявляться во времени сборки, предназначенной для клиентов.Интеграция Stripe APP позволила быстрее, чем мы ожидали, перевести больше клиентов из категории «интересующиеся агентами» в категорию «агенты, работающие с реальными стеками технологий».Клиенты, которые настраивают оповещения о расходах в первый же день, почти никогда не сталкиваются с ситуацией, когда «ваше приложение за 5 долларов обходится в 40 долларов». Те, кто этого не делает, иногда сталкиваются. В одном из недавних обсуждений агент Datadog незаметно оставил работу над проектом, превратив ежемесячный счет в 40-60 долларов в 544 доллара, прежде чем клиент это заметил. Мы собираемся сделать оповещения более заметными.За этот год мы получили огромное количество информации благодаря отзывам, звонкам клиентов и данным о платформе от всех вас. Порой от этого у нас голова кружится. Как вы можете заметить, мы просто в восторге.

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

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

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

Надежность
Это лишь подготовительная работа. Не всё будет видно в виде эффектных презентаций. (Но здесь многое сделано.)

Самый важный этап — это внедрение технологии Gen2 Metal.

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

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

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

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

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

Больше всего меня интересует история о железной дороге, рассказанная агентом.

Три взаимосвязанных вещи:
Базовый примитив песочницы, позволяющий агенту безопасно проверять свою работу перед запуском в производство.Более органичное взаимодействие агентов с панелью управления или терминалом (например, передача управления Railway существующим инструментам программирования ИИ, таким как Claude, Codex или Cursor).Удаленный сервер MCP, позволяющий агенту не находиться локально для управления платформой (запущен сегодня), а также возможность для агентов создавать шаблоны так же, как это делают люди (также запущен сегодня).Мы также предлагаем решение проблемы «Railway — не лучшее место для размещения фронтенда». Частью этого является полноценная CDN-сеть. Railway Websites — это часть решения. В итоге вы сможете размещать приложения Next.js или TanStack на Railway, не разрываясь между двумя вариантами размещения кода.

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

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

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

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

Мы также рассматриваем следующие вопросы:
Ценообразование и комплектация, ориентированные на рабочий процесс агентов, отражают то, как команды фактически используют Railway, когда агенты выполняют работу, а не внешний вид страниц с ценами 2018 года.Обновленный интерфейс мониторинга, позволяющий агенту (и вам) задавать платформе вопросы о причинах замедления работы и получать полезные ответы.Расширение наших механизмов защиты ИИ, чтобы платформа отказывалась от деструктивных операций, которые агент вообще не должен совершать.Шаблоны, которые представляют собой не просто статические рецепты, а готовые к использованию в производственной среде примитивы, из которых агент может составить реальный стек.
Сейчас и после
Если бы это был один из тех рекламных роликов, я бы поставил музыку на паузу, ещё раз кликнул бы на панель управления железной дороги, подмигнул бы камере и минуту смотрел бы в окно, прежде чем продолжить.

Сегодня мы завершаем год в таком виде, как «Железнодорожная линия», но наши взгляды устремлены на будущее, на оставшуюся часть 2026 года и на 2027 год, и мы прямо сейчас работаем над прокладкой этих путей (понимаете, да?). Предстоящий путь будет заключаться в том, чтобы сделать платформу более надежной, более функциональной и более ориентированной на агентов, и все это ради той же простой ставки, которую мы сделали в самом начале: разработчики должны отправлять код и запускать его.

Чтобы более конкретно взглянуть на то, куда мы движемся дальше:

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

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

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

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

Заключение
Тем из вас, кто был с нами с самого начала, или с 2025 года, или только что присоединился, большое спасибо. Ваши отзывы, ваше терпение в трудные времена, ваша готовность указывать нам на наши ошибки и (что не менее важно) ваша готовность указывать нам на то, что мы сделали правильно, — вот причины, по которым мы стремимся выпускать больше продуктов, делать это честно и получать от этого удовольствие.

Мы будем и дальше развивать компанию Railway, опираясь на вас, ваше сообщество и созданные вами предприятия, и мы полны решимости оправдать доверие, которое мы вам обязаны.

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

Хорошо. Здесь я нажимаю «стоп». Я написал много слов.

Удачной доставки!
Анджело + команда железнодорожников

railway.com

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

Потом го катку в битве гиков! Мы создали :) И не успеете оглянуться, как придёт лето.


Статьи и инструкции
Регистрация доменов через Госуслуги с 1 сентября 2026 года
Осенью вступят в силу требования Федерального закона № 569-ФЗ: теперь всем владельцам доменов придётся проходить обязательную идентификацию через Госуслуги. В статье разбираемся с новыми правилами и рассказываем, что важно сделать прямо сейчас.
firstvds.ru/blog/obyazatelnaya-registraciya-domenov-cherez-gosuslugi-s-1-sentyabrya-2026-goda-razbiraem-novye

GPU: что это, как устроен и для каких задач подойдёт
GPU — крутой инструмент для игр, нейросети, визуализация, анализ данных. В статье рассказываем, как работает графический процессор, какие решения предлагают хостеры и что выбрать для своей задачи.
firstvds.ru/blog/gpu-chto-eto-kak-ustroen-i-dlya-kakikh-zadach-podoydyot

Как сделать лендинг для бизнеса с помощью нейросети — без разработчика и конструктора
Опубликовали статью в крутом медиа для компаний — Бизнес Секретах. Загляните почитать, как собрать лендинг с помощью нейросети, бесплатно и не влезая в код.
secrets.tbank.ru/blogi-kompanij/lending-s-pomoschyu-nejroseti/

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

Также в подборку добавили гайд про злой и страшный eBPF (про который толком никто ничего не знает) и авторизацию в Go.
Маленькая EVPN/VXLAN-фабрика без тупика: как мы запускали площадку в АмстердамеОнлайн-переезд EVPN/VXLAN-фабрики между дата-центрами: euNetworks → QupraDC без остановки сервисаeBPF для начинающих: практическое введениеАвторизация в Go без боли: как Casbin заменяет километры if-проверок
Ищем авторов для блога на Хабр.
Подготовьте статью на одну из специальных тем или отправьте материал на тему месяца. И если ваша статья подойдёт для блога, вы получите повышенный гонорар.
Тема июня: лайфхаки для гиков.
firstvds.ru/avtoram

Новости мая
Запустили тарифы с vGPU

Расширили возможности аренды серверов с графическими ускорителями — добавили тарифы VDS с vGPU. Подходит для 3D-задач, рендеринга, а также для стримов, гейминга и экспериментов с нейросетями.
vGPU — это виртуальная видеокарта. Один мощный физический GPU (NVIDIA L40S, 48 GB) делится на виртуальные профили: каждая виртуальная машина получает гарантированную долю видеопамяти. Главный плюс vGPU — вы платите ровно за ту мощность, которая нужна. Это позволяет снизить стоимость аренды и не переплачивать за избыточный ресурс.
firstvds.ru/products/vps-vds-gpu

Добавили новый тариф для GPU Passthrough

Дополняем линейку GPU Passthrough. В мае добавили новый тариф с флагманской видеокартой NVIDIA RTX 5090. Это видеокарта нового поколения с максимальной пропускной способностью и поддержкой FP4 — всё, что нужно для высокоскоростного инференса LLM, быстрой генерации видео и продвинутых ML-задач.
firstvds.ru/products/vps-vds-gpu

Стартовали с акцией «День Гика»

Запустили масштабную акцию с настоящей PvP-игрой и артефактами из культовых вселенных. Сражайтесь и выигрывайте крутые игровые консоли и лимитированный мерч!
А ещё участники акции смогут получить скидки и сертификаты на VDS, чтобы развернуть сервер под пет-проект, запускать стримы, работать с 3D, играть в любимые игры или работать с ИИ.
firstvds.ru/actions/geek_day_2026

Обновили S3-хранилище

Продолжаем улучшать наше S3-хранилище.
firstvds.ru/services/s3
Теперь файлы в S3 теперь можно смотреть не скачивая. Добавили в S3 Manager встроенный помощник: с его помощью можно открывать в панели видео-, аудиофайлы а также документы (PDF, Excel, DOCX).
В наш облачный проект CLO добавили файловый менеджер для хранилища S3: теперь можно управлять объектами в хранилище прямо из браузера без установки десктопных клиентов, настройки aws-cli или сторонних утилит.
clo.ru/blog/faylovyy-menedzher-dlya-s3-khranilishcha

Запустили рецепт Portainer

Portainer — это удобный веб-интерфейс для управления контейнерной инфраструктурой. С его помощью можно работать с контейнерами, образами, сетями, томами и стеками без постоянного использования командной строки.
Теперь на сайте можно заказать виртуальный сервер с готовым рецептом Portainer и получить VDS с необходимым ПО и базовой настройкой. Сервис развернут через Docker Compose, запущен и готов к работе.
Подходит для быстрого старта. Упрощает управление Docker-окружением. Экономит время на ручной установке и настройкеfirstvds.ru/technology/nachalo-raboty-s-portainer-posle-avtomaticheskoy-ustanovki-iz-recepta

Топ новостей из мира безопасности
Заметили, что уязвимостей в последнее время стало заметно больше? Это не случайность: ИБ-компании всё активнее используют ИИ для аудита кода и находят баги быстрее, чем раньше. В индустрии уже появился термин для этого явления — «вулнапокалипсис» (от англ. vulnerability — уязвимость).
Советуем хотя бы одним глазком следить за нашими ИБ-дайджестами: собираем самые важные новости, которые не стоит пропускать в общем потоке
Уязвимость Copy Fail позволяет любому пользователю Linux получить root-доступДве критические уязвимости в ядрах Linux и FreeBSD: локальное повышение привилегий до rootДайджест ИБ-новостей: ядро Linux снова под ударом, червь в TanStack, критические баги в Exim и nginxДайджест ИБ-новостей: новые уязвимости Copy Fail, взломы GitHub и OpenAI, zero-day в Exchange Выявлена критическая уязвимость CVE-2026-42945 в nginx, которая существовала 18 лет.Зафиксирована масштабная атака на TanStack

Теперь всем пользователям виртуального хостинга доступна новая версия PHP – 8.5.

Что нового в версии языка программирования PHP 8.5
Встроенный модуль URI – он предоставляет API для безопасного анализа и изменения URI и URL в соответствии со стандартами RFC 3986 и WHATWG, таким образом, теперь можно разбирать и изменять URL без использования сторонних библиотек, что снижает риск ошибок и уязвимостей и упрощает работу с адресами.Оператор Pipe позволяет связывать вызовы функций в цепочку без использования промежуточных переменных – это делает код более читаемым и лаконичным и дает возможность выстраивать последовательность операций без лишних переменных.Упрощена работа с неизменяемыми объектами – можно обновлять свойства во время клонирования объектов, передавая ассоциативный массив в функцию clone(), что позволяет клонировать объект и сразу изменить нужные свойства.Увеличение безопасности API – теперь при добавлении атрибута #[\NoDiscard] к функции PHP будет проверять, используется ли возвращаемое значение, и выдавать предупреждение, если это не так.Сокращение количества вспомогательных классов и строковых выражений – статические замыкания и вызываемые объекты первого класса теперь могут использоваться в константных выражениях.Возможность использовать DNS-кэш и соединения между PHP-запросами – если найден постоянный дескриптор с тем же набором параметров, он будет использован повторно, что позволяет избежать затрат на повторную инициализацию дескрипторов cURL при каждом запросе.Теперь проще и безопаснее получать первый или последний элемент массива – функции array_first() и array_last() возвращают первое или последнее значение массива, а если массив пустой, возвращается значение null.И это – далеко не полный список, ознакомиться со всеми нововведениями можно на официальном сайте. Дата выхода версии 8.5 языка программирования PHP – 20 ноября 2025 года.
www.php.net/releases/8.5/ru.php

Как обновить версию PHP
перейдите в раздел Управление сайтами;
нажмите на шестеренку справа от домена;

выберите из выпадающего списка версию языка программирования PHP 8.5 и дождитесь обновления – как правило, оно занимает до 10 мин.


beget.com

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

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

Согласно данным Рег.решений, регистрация домена остается наиболее востребованным запросом — его выбрали 54,1% респондентов. Еще 24,6% обращаются за созданием сайта. При этом для большинства предпринимателей домен уже не просто техническая необходимость. 57,8% опрошенных сообщили, что регистрируют домен сразу для запуска сайта или онлайн-проекта. Ещё 19,6% используют его как инструмент продвижения бренда в интернете, 18,3% — чтобы заранее закрепить название будущего проекта, а 14% — для создания корпоративной почты.
Присутствие в онлайне стало частью базового подхода малого бизнеса уже на старте. Если раньше компании выходили в онлайн спустя месяцы после запуска, то теперь предприниматели стремятся заранее подготовить площадку для продаж, коммуникации и продвижения. Особенно заметно это среди небольших команд, локальных сервисов и начинающих брендов. Для них сайт становится основной точкой контакта с клиентом, а домен — лицом компании в сети.

Мы знаем, что быть предпринимателем — это работа 24 часа в сутки, поэтому берем на себя часть рутинных задач, чтобы освободить ценное время предпринимателям для стратегии и новых идей. Сегодня они конкурирует не только продуктом, но и скоростью выхода к клиенту. Если у бизнеса нет понятного адреса в интернете, он теряет часть доверия ещё до первого контактаотметил Владислав Иванов, евангелист Рег.решений.

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

businessday.reg.ru

Меня зовут Рене, я сетевой инженер в FirstVDS. В первой части я рассказывал, как мы запускали небольшую европейскую площадку в Амстердаме: один Leaf, один Spine, routed host networking для гипервизоров, EVPN-VXLAN как сервисная плоскость, DDoS в отдельном VRF, OOBM и Flow-коллектор.

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

Хорошая новость в том, что стартовая схема была построена не вокруг одной большой god-box, а как маленькая, но нормальная фабрика. Именно это позволило нам не делать одно рискованное переключение «всё сразу», а провести переезд через несколько контролируемых промежуточных состояний.

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

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

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

Требования получились такими:
по возможности не покупать дополнительное сетевое оборудование;не останавливать продажи и не останавливать клиентский сервис;переносить серверы постепенно;сохранить старую клиентскую IP-адресацию;не сводить переезд к одному большому окну работ, в котором нужно переключить всё и сразу.
Переводя это на сетевой язык, я понял, что нам просто нужен ещё один Leaf в QupraDC, который можно временно включить в существующую фабрику. Старый Spine оставляем в euNetworks, новый Leaf физически ставим в QupraDC, а между площадками поднимаем временный IP-транспорт.

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

Так вынужденный переезд превратился ещё и в проект по повышению отказоустойчивости.

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

На самом деле нам было почти всё равно, как именно поставщик реализует этот канал внутри своей сети: тёмная оптика, лямбда, проброс VLAN по коммутационной фабрике оператора, L2VPN, L3VPN или какой-то иной транспорт. Для нашей задачи была важна не технология, а конкретные технические свойства:
пропускная способность не меньше 40G;возможность передавать IP-пакеты между старой и новой площадкой и желательно одним p2p-линком с /31-адресацией;MTU 9216;возможность быстро разобрать канал после завершения миграции;недорого.
Dot1q теги нам были не нужны, потому что мы не тащили пользовательские VLAN между дата-центрами, а даже если бы такая потребность была, то мы бы cделали это силами EVPN-VXLAN. Underlay-интерфейсы на Leaf и Spine были обычными L3-портами с IP-адресацией. По временному каналу должны были ходить IP-пакеты underlay и поверх них — VXLAN-инкапсулированный трафик overlay.

MTU был критичен. Внутри underlay передаются не только обычные IP-пакеты, но и трафик виртуальных машин в VXLAN-инкапсуляции. Если клиентская VM отправляет стандартный 1500-байтный пакет, к нему добавляется накладной расход VXLAN/UDP/IP. Если забыть про это на междатацентровом канале, можно получить неприятные проблемы с фрагментацией или чёрными дырами для части трафика. Отдельная практическая причина — сервисная потребность использовать jumbo frames для сетевых хранилищ: такие сценарии тоже требуют нормального запаса MTU в фабрике.

На underlay-интерфейсах мы используем MTU 9216 байт. Это максимальный размер передаваемого пакета для наших коммутаторов, поэтому нет практического смысла задавать меньшее значение внутри управляемой нами фабрики. Такой MTU даёт достаточный запас под VXLAN-инкапсуляцию, упрощает эксплуатацию и используется как единый стандарт во всех наших IP-фабриках.

Важно подчеркнуть: мы не строили stretched-L2 между дата-центрами. Временный L2-канал от поставщика использовался как транспорт для нашей L3-связности underlay. Для фабрики новый Leaf выглядел как ещё один Leaf, который просто находится чуть дальше, чем ожидалось ранее.

Никаких растянутых клиентских VLAN через xSTP, никаких попыток склеить две площадки в один большой L2-домен. Только IP-связность underlay и EVPN-VXLAN поверх неё.

Новый Leaf должен был быть точно такой же модели, чтобы сетевые чипы и версии программного обеспечения были максимально идентичны. В миграции под давлением и в условиях дефицита времени это важно. Теоретически EVPN должен нормально работать между разными платформами, но на практике смешивание разных чипов, разных версий ПО и разных профилей поведения control plane может превратить переезд в отладку ещё неразрешенных багов.

После физической установки нового Leaf в QupraDC последовательность работ была такой:
Подключили новый Leaf через временный 40G-канал к существующему Spine.Настроили базовую IP-связность underlay.Проверили reachability между участниками фабрики.Подняли BGP-сессии underlay и overlay.Отмониторили стабильность BGP-сессий и качество канала.Проверили, что новый Leaf участвует в EVPN control plane и корректно получает необходимые маршруты.
На этом этапе важно было не торопиться с клиентской нагрузкой. Сначала должна стабильно заработать управляющая плоскость: reachability VTEP-адресов, MP-EBGP EVPN, передача маршрутной, MAC/IP-информации и EVPN Type 5 routes, а также программирование EVPN database. Только после этого можно перевозить первые серверы.



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

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

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

Маршрут до виртуальной машины на перенесённом сервере мог выглядеть так: интернет → старый Leaf → Spine → междатацентровый канал (DCI) → новый Leaf → гипервизор → VM.

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

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

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

Перенос внешней связности и инфраструктуры


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

К счастью, наш IP-транзитный оператор присутствовал и в QupraDC. Это позволило перенести одну из BGP-сессий с апстримом в новую локацию.

Здесь важно уточнить: в QupraDC мы не повторяли старую физику 2×10G. При переносе стыка в новую локацию сразу включили 100G-подключение на новом Leaf. Сервисно это выглядело как перенос одной из двух BGP-сессий вместе с её VLAN и point-to-point-адресацией /31, а физически — как переход новой площадки на 100G-аплинк.

После этого схема стала такой:
одна BGP-сессия с апстримом осталась на старом Leaf в euNetworks через старый 10G-стык;вторая BGP-сессия с тем же апстримом поднялась на новом Leaf в QupraDC уже через 100G-подключение;оба Leaf продолжили участвовать в общей фабрике;внешний трафик начал распределяться между двумя площадками.
С нашей стороны появился второй выход к тому же оператору, но уже из новой локации и на новой физике. На каждом Leaf был свой локальный default-route от апстрима. Кроме того, default-route мог распространяться внутри overlay как EVPN Type 5 route, чтобы у фабрики сохранялась связность между частями временной схемы.

Оператор со своей стороны также использовал multipath и старался отдавать входящий трафик относительно симметрично. В результате мы получили два полезных эффекта.

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

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

DDoS-сервис переносился параллельно и по той же логике. DDoS-защитный провайдер тоже присутствовал в QupraDC, поэтому его подключение можно было перенести в новую локацию без изменения прежней модели. Стык с ним также состоял из двух BGP-сессий на двух разных юнитах, с разными VLAN-тегами на два разных Leaf. С точки зрения маршрутизации и фильтров всё осталось прежним: изменилось только физическое место подключения.

На этом этапе состояние выглядело так: часть серверов уже в QupraDC, часть ещё в euNetworks, внешний транзит, в том числе защищённый, работает на обеих площадках, в QupraDC уже используется 100G-стык к апстриму, оба Leaf участвуют в маршрутизации, миграция продолжается без остановки клиентского сервиса.

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

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

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

В сетевой инфраструктуре route reflector — это не просто очередная виртуальная машина. Это элемент управляющей плоскости, и обращаться с ним нужно соответствующе.

После переноса RR и оставшейся инфраструктуры мы перенесли вторую BGP-сессию с апстримом в QupraDC. Напомню, внешняя связность в новой локации уже строилась на 100G: целевая схема предусматривала два независимых 100G-стыка, по одному на каждый Leaf.

К этому моменту вся клиентская и инфраструктурная нагрузка находилась в QupraDC. Старая площадка фактически оставалась только местом, где ещё физически стояли старые Leaf и Spine, а также один инфраструктурный сервер виртуализации, который нужно было убрать последним.

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

На этом этапе старый Leaf и Spine уже не были критичны для клиентского сервиса в прежнем смысле. Основная нагрузка находилась в QupraDC, внешние BGP-сессии были перенесены туда же, а временный междатацентровый канал продолжал поддерживать связность на время завершения работ.

Мы обесточили старый Leaf и Spine, демонтировали их, перевезли в QupraDC, смонтировали и включили обратно.

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

После этого переезд можно было считать завершённым: клиентская нагрузка находилась в QupraDC, инфраструктурные сервисы находились там же, обе BGP-сессии к апстриму были подняты из QupraDC на 100G-стыках, стык с DDoS-провайдером был перенесён в QupraDC, старое сетевое оборудование было физически перевезено на новую площадку.

Временный междатацентровый канал, который был нужен только как инструмент миграции, мы незамедлительно разобрали.


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

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

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

Здесь важно не спутать это с классическим LACP/ESI-LAG. Мы не собирали два физических линка в один L2-агрегат и не строили multihoming через LACP. Модель осталась той же, что и раньше. Разница только в том, что теперь эти два L3-пути идут не в один и тот же Leaf, а в два разных.

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

С точки зрения диагностики такая схема остаётся очень прозрачной. Нет необходимости выяснять, что именно произошло с LACP-состоянием, кто из пары коммутаторов считает себя активным и как отработала дополнительная сигнализация EVPN multihoming. В такой схеме DF election завязан на Type 4 — Ethernet Segment route, а aliasing и mass-withdraw — на Type 1 Ethernet A-D routes: per-ES и per-EVI. Это рабочая модель, но при отказах в ней появляется больше состояний, которые нужно уметь проверять и отлаживать.

В нашем случае есть интерфейс, есть connected route, есть next-hop, есть BGP-анонс VM-префикса. Каждый элемент можно проверить отдельно.

Важный нюанс — IPMI. У большинства серверов отдельный порт управления один. Его невозможно одновременно подключить в два Leaf без дополнительной схемы. Поэтому IPMI-порты мы распределили симметрично: часть серверов смотрит в первый Leaf, часть — во второй. При отказе одного Leaf мы теряем доступ к IPMI части серверов, но не ко всем сразу. Для этой задачи это приемлемый компромисс.

После финальной коммутации внешняя связность выглядела так:
каждый Leaf имеет собственное 100G-подключение к апстриму;каждая BGP-сессия поднимается независимо;оба Leaf могут анонсировать одинаковый набор наших префиксов;отказ одного Leaf не убивает внешний канал целиком;отказ одного 100G-линка не оставляет площадку без транзита;входящий и исходящий трафик может распределяться через multipath.
Проверка отказов и один Spine как компромисс
После миграции и перекладки серверных линков мы провели серию отказных тестов. Это обязательный этап: отказоустойчивость нельзя считать существующей только потому, что она нарисована на схеме.

Проверяли несколько сценариев.

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

Второй сценарий — перезагрузка второго Leaf. Проверка симметричная, но её всё равно нужно проводить отдельно. В реальной эксплуатации часто выясняется, что «одинаковые» устройства отличаются мелочами: набором подключённых серверов, BGP-соседствами, политиками или физической коммутацией.

Третий сценарий — отключение серверных интерфейсов. При физическом обрыве всё работает быстро: сетевой стек гипервизора видит carrier loss, маршрут через этот интерфейс перестаёт использоваться, и трафик остаётся на другом ECMP-пути. В этом случае не нужно ждать истечения BGP holdtime, потому что проблема видна на уровне интерфейса.

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

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

Пятый сценарий — проверка DDoS-сегмента. Здесь всё плюс/минус аналогично, проверяется отказ стыка к DDoS-провайдеру.

Для быстрой детекции отказов в самой IP-фабрике используется BFD. Благодаря BFD мы не ждём длинных BGP-таймаутов: если сосед перестаёт отвечать, путь быстрее признаётся нерабочим, и трафик перераспределяется по другим next-hop'ам в рамках ECMP-группы

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

Внимательный читатель заметит: после всех улучшений Spine всё ещё один. Значит ли это, что он остаётся single point of failure?

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

Но в нашей текущей топологии отказ Spine не равен полной остановке клиентского сервиса.

Причина в том, что два Leaf после переезда не завязаны на Spine как на единственную точку выхода наружу или единственный шлюз для серверов:
каждый Leaf имеет собственную BGP-сессию к апстриму;каждый Leaf получает свой локальный default-route от оператора;оба Leaf анонсируют одинаковый набор наших внешних префиксов;гипервизоры подключены к обоим Leaf отдельными L3-связями;маршруты до виртуальных машин распространяются через BGP;если нет BGP-сигнализации до конкретного VM-префикса, сеть не считает этот путь рабочим.
То есть ситуация «трафик пришёл на Leaf, а дальше его некуда доставить» в нормальном состоянии не должна возникать. Если конкретный хостовой линк падает, соответствующий путь исчезает. Если Leaf теряет внешнюю связность, трафик может уйти через второй Leaf, у которого есть свой апстрим.

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

В какой-то момент один Spine перестаёт быть разумным компромиссом и становится техническим долгом. Тогда фабрику нужно будет довести до более канонической Clos-топологии с избыточностью на каждом уровне.

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

До переезда схема была минимальной: один Leaf, один Spine, вся нагрузка в одной физической локации, внешний аплинк 2×10G, Leaf одновременно выполняет роли server leaf и border leaf, отказоустойчивость на уровне фабрики минимальная.

После переезда схема стала заметно сильнее: два Leaf в новой локации, серверные подключения разнесены по двум Leaf, внешние BGP-сессии к апстриму подняты с разных Leaf, внешняя физическая связность в QupraDC сразу собрана на 2×100G, DDoS-сервис перенесён в QupraDC, его подключения также разнесены по двум Leaf.

Главное — что мы не меняли архитектурную модель в процессе переезда. Новый Leaf встроился в уже существующую фабрику, серверы продолжили работать в routed-модели, VM-префиксы продолжили распространяться через BGP, а EVPN-VXLAN остался общей управляющей и сервисной основой площадки.

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

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

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

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

Следующий необходимый этап — второй независимый апстрим. Две BGP-сессии к одному оператору дают резервирование на уровне наших стыков, Leaf-коммутаторов и физических линков. Но они не защищают от аварии внутри сети самого ISP: проблем на магистрали, ошибок маршрутизации, отказов route-server'ов провайдера или неудачных изменений в его политике. В такой ситуации уже не так важно, что с нашей стороны подняты две сессии: если проблема находится внутри операторской сети, оба стыка могут деградировать одновременно.

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

Но здесь есть важный нюанс: такое переключение сработает само только если BGP-сессия действительно погасла и маршрут был отозван. Аварии внутри операторской сети не всегда выглядят именно так. Сессия может оставаться поднятой, default-route — присутствовать в RIB, а качество связности при этом уже стать неприемлемым. В таких случаях нужны мониторинг, понятные процедуры переключения и рабочий OOBM-доступ, чтобы можно было быстро вмешаться и поменять политику маршрутизации не через сломанную сеть.

И вполне вероятно, что в какой-то момент появится смысл вынести внешнюю маршрутизацию на полноценную пару border-router'ов операторского класса с full view. Но это уже следующий этап для нас: сотни гигабит трафика, несколько апстримов, более сложный traffic engineering и отдельные требования к пиринговой политике.

Ещё один очевидный шаг — второй Spine. Пока один Spine остаётся приемлемым компромиссом для текущей топологии, но при дальнейшем росте Leaf-коммутаторов и требований к отказоустойчивости его нужно будет добавить. Тогда фабрика станет ближе к канонической Clos-топологии: несколько Leaf, несколько Spine и отсутствие единственной точки отказа не только в underlay, но и в overlay control plane. В нашей схеме Spine участвует в распространении EVPN-информации, поэтому его резервирование важно не только для транспортного уровня, но и для управляющей плоскости overlay.

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

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

firstvds.ru

Меня зовут Рене, я сетевой инженер в FirstVDS. Я работаю из Иркутска и люблю строить сетевые фабрики на базе VXLAN/EVPN — не в теории, не в лабе, а на практике в жёстком продакшене, где важнее не красивый референс-дизайн, а то, насколько решение готово к авариям, миграциям нагрузки, физическому переезду и неожиданным вводным от бизнеса.

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

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

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

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

Проект на старте мог и не взлететь, поэтому капитальные затраты хотелось держать под контролем. От сети требовалось следующее:
стартовать с минимального количества коммутаторов;не упереться в тупик, когда потребности масштабирования выйдут за пределы стартового оборудования;сохранить возможность горизонтального масштабирования;использовать тот же инженерный подход, что и в других локациях;на первом этапе не строить полноценную отказоустойчивость, но оставить возможность добавить её позже.
Мой ответ был простым: строим фабрику в архитектуре Clos/Fat-Tree, а, значит, нам нужны Leaf и Spine. На старте — по одному устройству в каждой роли, остальные держим в уме как следующий этап масштабирования.

Leaf должен был выполнять роль коммутатора доступа для серверов виртуализации, поддерживать VXLAN/EVPN и уметь L3-gateway. Для стартовой схемы мы выбрали модель с 48×10G портами под downlink и 6×100G на uplink-портах. Spine — коммутатор с возможностью маршрутизации и deep buffer. Под эту задачу хорошо лёг коммутатор с портовым радиксом 36×40G одного известного производителя.

Самый дешёвый стартовый вариант выглядел бы так: поставить один большой коммутатор, подключить к нему серверы и аплинк, а затем считать задачу закрытой. Проблема в том, что такая схема решает только боль первого дня. Она не даёт нормального scale-out. Когда закончатся порты, появится новая стойка или потребуется разнести подключения по разным устройствам, сеть придётся не расширять, а перестраивать.

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

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

Хосты виртуализации: routed host networking вместо классического L2
Важная деталь: наши серверы виртуализации не подключаются как обычные хосты в одном большом или нескольких L2-доменах. Мы используем оркестратор виртуализации ISPsystem VMmanager 6 в режиме IP-Fabric, где сеть до гипервизора строится через динамическую маршрутизацию — через BGP.

Каждый гипервизор подключается к фабрике двумя физическими 10G-линками. Каждый линк — это отдельный point-to-point линк с адресацией /31 из приватного диапазона.

На гипервизоре нет LACP bond поверх этих двух портов. Вместо этого на хосте настроены статические маршруты по умолчанию через оба сетевых интерфейса. Оба next-hop равнозначны, поэтому исходящий трафик может распределяться через ECMP средствами Linux, по L4 hash: IP-адрес источника, IP-адрес назначения, протокол, порт источника и порт назначения. Такое поведение требует изменения ряда параметров ядра Linux: по умолчанию используется другой алгоритм выбора пути.

То есть отказоустойчивость и балансировка здесь строятся не через LAG/LACP, а через обычную маршрутизацию. Для сети это два независимых L3-линка, а не один логический L2-агрегат.

Мы сознательно не стали делать классический LAG/Port-channel через LACP bond в режиме 802.3ad. Команда «погонщиков» виртуализации протестировала оба подхода: bond-модель и routed-модель. В продакшен выбрали именно маршрутизацию. По их наблюдениям, routed-вариант давал меньше CPU utilization, позволял сохранить NUMA-локальность и лучше ложился на задачи, где важны pps и bps.

С эксплуатационной точки зрения такая L3-схема даже проще. Если физический линк до Leaf падает, гипервизор видит carrier loss, связанный с этим интерфейсом маршрут по умолчанию перестаёт использоваться, и трафик продолжает идти через оставшийся линк.

LACP/multihoming даёт отказоустойчивость, но добавляет много состояний, которые сложно отлаживать. Уже на этом этапе мы держали в голове будущую топологию, где серверы должны были подключаться не двумя линками в один Leaf, а двумя независимыми L3-линками в разные Leaf. Поэтому сравнение с LACP/multihoming важно не только теоретически — оно напрямую связано с тем, как площадка должна была развиваться дальше.

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

Маршруты до виртуальных машин анонсируются с гипервизоров по BGP. Каждый гипервизор сообщает, какие VM-префиксы находятся именно на нём. Обычно это host-routes /32 для IPv4-адресов виртуальных машин и /64 для IPv6.

Чтобы не строить full mesh из BGP-сессий между всеми гипервизорами и Leaf-коммутаторами, гипервизоры пирятся с двумя RR-серверами. В этой части схемы гипервизоры и RR находятся в одной ASN: RR принимают маршруты от гипервизоров как iBGP route reflector, а дальше передают их в сторону Leaf уже через eBGP, с политикой не переписывать next-hop. Уникальные приватные ASN на каждое устройство относятся к сетевым устройствам фабрики — Leaf и Spine, — а хостовая часть с гипервизорами и RR живёт в своей BGP-модели.

RR позволяют удержать количество BGP-сессий под контролем и упростить ввод новых гипервизоров через плейбуки Ansible. RR — это такая же Linux-машина с BGP-демоном. Минимум два RR на разных инфраструктурных хостах нужны для того, чтобы отказ одного из них не ломал распространение маршрутов до виртуальных машин.

Тут важна не внутренняя реализация VMmanager, а сама сетевая модель: клиентские адреса не выносятся в общий L2-домен, а становятся маршрутизируемыми префиксами, достижимость которых распространяется через eBGP family unicast.

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

Причин несколько.

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

Во-вторых, текущая нагрузка не обязана навсегда оставаться единственным сценарием.

Сегодня в локации продаются VDS, и основная модель — маршрутизация до гипервизоров. Завтра бизнес может решить продавать в Амстердаме bare metal для массового рынка. И как бы мы ни вдохновлялись RFC 7938, реальные сервисы могут оказаться разными. Например, это могут быть сервисы для корпоративного заказчика, где по сей день любят L2 и часто требуют его просто потому, что так исторически сложилось.

Многолетний опыт работы в корпоративных средах, где либо не умеют, либо не хотят нормально планировать сеть, наводит меня на мысль, что «один большой VLAN на всё» для многих до сих пор остаётся базовым требованием. Так быть, конечно, не должно, но реальность от этого не меняется. Такой клиент вполне может потребовать не routed-модель, а обычное мостовое подключение своих серверов или гипервизоров.

При этом строить современную дата-центровую сеть на L2 — плохая инженерная практика и моветон. И проблема не только в размере конкретного L2-домена. Сама модель хуже управляется: широковещательный трафик, зависимость от ARP/ND, обучение MAC-адресов, риски петель, неявное поведение при отказах и сложная диагностика. Чем больше такая сеть, тем сильнее проявляются эти проблемы, но принципиально они никуда не исчезают даже в небольших сегментах.

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

EVPN/VXLAN позволяет эмулировать L2 поверх маршрутизируемой фабрики, не превращая весь дата-центр в набор мостовых соединений. А наша текущая маршрутизируемая нагрузка аккуратно ложится в отдельный routing-instance поверх overlay-сети и не смешивается с underlay. При необходимости рядом можно добавить новые L2-сервисы, отдельные VLAN/VNI, MAC-VRF и другие сценарии — не ломая базовую архитектуру.

То есть VXLAN/EVPN здесь не потому, что нам обязательно нужно растягивать L2 прямо сейчас. Он нужен как универсальная сервисная плоскость, которая не заставит нас в будущем переезжать на новую архитектуру.

Стартовая фабрика: ERB, eBGP и lean Spine


Как и было запрошено на старте, мы запускались с одним Leaf и одним Spine.

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

Мы используем модель ERB — Edge-Routed Bridging. В такой архитектуре маршрутизация выполняется на краю фабрики, ближе к серверам, то есть на Leaf-коммутаторах. Spine остаётся транспортным уровнем underlay и не превращается в центральную точку маршрутизации всех L3-сетей в overlay.

Leaf в нашей схеме выполняет сразу несколько ролей:
коммутатор доступа для серверов виртуализации;VTEP, то есть точка терминации VXLAN-туннелей;L3 шлюз для маршрутизации между VLAN/VNI через IRB-интерфейсы;выполняет роль stateless firewall, но объём правил ограничен ресурсами TCAM чипа;border leaf для выхода в интернет и подключения внешнего IP-транзита через единственного ISP.
Underlay собран на eBGP: отдельные point-to-point-связи между Leaf и Spine, отдельная адресация, отдельные BGP-соседства. Overlay control plane работает через MP-EBGP EVPN, а data plane — через VXLAN. Для выделения ASN использовалась модель с уникальным приватным номером автономной системы под каждое сетевое устройство фабрики: у каждого Leaf и Spine была своя ASN.

eBGP с уникальными ASN хорошо формализуется: у каждого устройства чётко определены роль, соседи, address families, политики и маршруты. Для автоматической валидации это удобнее, чем более свободная iBGP/RR-топология. Но на Spine'ах обязательно должен быть настроен next-hop unchanged для EVPN-маршрутов транзитных Leaf, потому что eBGP по умолчанию переписывает next-hop своим адресом, что ломает VTEP-to-VTEP reachability.

Есть и практический плюс для эксплуатации: по AS-PATH очень наглядно видно, через какие устройства проходит маршрут внутри фабрики. Это удобно при диагностике и при разборе несимметричных или неожиданных путей. А если нужно временно увести трафик с проблемного участка, можно повлиять на выбор пути стандартными BGP-инструментами, например добавив AS-path prepend на нужном направлении.

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

В этой роли Spine можно считать lean spine: он обеспечивает IP-связность underlay между Leaf-коммутаторами и может участвовать в BGP overlay, распространяя EVPN-маршруты. При этом ему не обязательно быть VTEP, не обязательно терминировать VXLAN и не обязательно держать IRB-шлюзы клиентских сетей.

Аплинк к IP-транзиту был заведён на Leaf. Физически это был 2×10G LACP bundle. С внешним оператором мы подняли две BGP-сессии и начали анонсировать наши префиксы. Полную таблицу маршрутизации на Leaf мы не принимали: для стартовой схемы было достаточно default-route от оператора. RIB для внешней связности оставался минимальным.

Так мы получили минимальную, но не тупиковую площадку: первые серверы виртуализации, VLAN/IRB под серверные подключения, overlay через EVPN и готовность добавить следующий Leaf без смены архитектуры.

Сервисные контуры: DDoS, OOBM и телеметрия


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

Аплинк к DDoS-транзиту был аналогично заведён на Leaf, через наших постоянных партнёров, специализирующихся на подобном сервисе. Физически это также 2×10G LACP bundle. Мы подняли две BGP-сессии: фактически это были две отдельные point-to-point-стыковки в разных юнитах, с собственной адресацией для каждой сессии.

Важное требование было таким: защищённый трафик не должен смешиваться с обычным IP-транзитом на уровне маршрутной политики. Поэтому мы вынесли DDoS-направление в отдельный VRF.

Внутри этого VRF был выделен отдельный свободный на тот момент префикс. Он анонсировался только в сторону провайдера DDoS-фильтрации. В результате в сети появились две логические зоны: основной VRF с обычным IP-транзитом и отдельный VRF для DDoS-protected transit.

Исходящий трафик с защищённого ресурса направлялся через FBF — filter-based forwarding. На интерфейсах, смотрящих в сторону родительских серверов, применялся фильтр: если source IP попадал в защищённый префикс, для такого трафика выбирался routing-instance с DDoS-защитой.

Обратное направление было сделано через статический маршрут с действием next-table. Такая конструкция означает не перенос пакета между VRF, а повторный lookup в другой таблице маршрутизации. В нашем случае маршрут из защищённого VRF продолжал поиск в таблице базового VRF, где уже находились маршруты до нужных виртуальных машин и гипервизоров.

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

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

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

Поэтому управление сетевым оборудованием вынесено в отдельный OOBM-контур — out-of-band management. Это независимая сеть управления, которая не зависит от клиентского трафика, EVPN/VXLAN-фабрики и внешнего IP-транзита.

Но одного OOBM недостаточно. Бывают ситуации, когда устройство загружается некорректно, ломается конфигурация management-интерфейса или требуется смотреть процесс загрузки до поднятия сети управления. Для таких случаев у нас есть доступ к последовательным консолям коммутаторов через консольный сервер. Терминал всех коммутаторов доступен через web-интерфейс с HTML5-просмотрщиком, поэтому к консоли можно подключиться без физического присутствия в дата-центре.

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

В контексте DDoS-защиты и внешнего транзита это особенно полезно. Сетевая телеметрия используется не только для ручного анализа, но и для обнаружения DDoS-атак. Если система видит аномальный трафик на конкретный адрес, она может автоматически инициировать RTBH — Remotely Triggered Black Hole. Для этого в BGP анонсируется host-route атакуемого адреса, обычно /32 для IPv4 или /128 для IPv6, с blackhole-community оператора. После этого операторская сеть начинает отбрасывать трафик до того, как он доедет до нашей площадки.

Итоги первой части
Эта первая часть не про героический переезд, а про скучную, но важную подготовку почвы. Мы не пытались сделать маленькую площадку «как-нибудь, лишь бы запустилось». Мы сразу разложили роли: Leaf для доступа и сервисов, Spine для underlay и EVPN control plane, гипервизоры — через маршрутизацию, DDoS — в отдельный VRF, управление — через OOBM.

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

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

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

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

10 апреля 2026 Почему более высокий уровень компетенции в области соблюдения нормативных требований важен в современной инфраструктуре

Долгое время проверка благонадежности клиентов, проверка «знай своего клиента» (KYC), проверка на соответствие санкциям и мониторинг соблюдения нормативных требований рассматривались в основном как задачи банков, платежных систем и других регулируемых финансовых учреждений. Однако это мнение больше не соответствует действительности. Теперь эти вопросы важны и для поставщиков инфраструктуры, включая хостинговые компании, облачные платформы и операторов центров обработки данных.
Этот сдвиг легко объяснить. Инфраструктура больше не является просто нейтральным техническим слоем. Она поддерживает продукты SaaS, клиентские порталы, внутренние системы, API, корпоративные рабочие нагрузки и критически важные для бизнеса потоки данных. Когда инфраструктура играет такую ​​роль, поставщики не могут думать только о времени безотказной работы, подключении и отказоустойчивости оборудования. Им также необходимо учитывать проверку клиентов, обработку данных и риски.
В MIRhosting это одна из причин, по которой мы продолжаем укреплять нашу внутреннюю экспертизу в области GDPR, соблюдения нормативных требований и проверки благонадежности клиентов. Наша команда недавно прошла специализированное обучение, посвященное приему клиентов, мониторингу, осведомленности о санкциях и защите данных в практических операционных условиях.
Это было сделано не ради видимости. Это было сделано потому, что подобные вопросы все чаще возникают в ходе реальной работы над инфраструктурой.
Почему это важно на практике
Вопросы соблюдения нормативных требований до сих пор пор иногда рассматриваются как прерогатива исключительно юридических отделов. В действительности же они влияют на повседневные решения гораздо сильнее, чем предполагали многие поставщики инфраструктуры.
Команде может потребоваться решить, является ли информация о клиенте полной, соответствуют ли подтверждающие данные друг другу, вызывает ли структура компании вопросы относительно бенефициарного владельца или требуется ли дополнительная проверка профиля клиента из-за юрисдикционного риска. Все это не абстрактно. Такие ситуации могут возникать во время регистрации, проверки счетов, внутренних проверок и плановой оценки рисков.
Вот где важна внутренняя экспертиза. Общей осведомленности недостаточно. Командам необходимо знать, на что обращать внимание, когда случай все еще является рутинным, когда оправдана осторожность и когда целесообразно эскалировать проблему.
Для MIRhosting накопление этих знаний помогает сделать внутренние процессы более понятными и последовательными. Что не менее важно, это помогает связать требования соответствия с повседневной реальностью эксплуатации инфраструктурных сервисов.
GDPR — это не просто юридическая тема.
Защита данных — это часть той же картины. GDPR часто обсуждается как правовая основа, но на практике он также зависит от операционной дисциплины.
Сбор информации о клиентах должен осуществляться только при наличии веских оснований. Хранение данных не должно занимать больше времени, чем необходимо. Запрос дополнительной информации по умолчанию не должен осуществляться. При этом способ обработки данных внутри компании должен соответствовать цели процесса.
Это особенно важно на этапах регистрации и верификации. Не каждый случай требует одинакового уровня проверки. Здесь важен практический подход, основанный на оценке рисков. Стандартная процедура регистрации должна оставаться простой для добросовестных клиентов. Дополнительные проверки следует запускать только при наличии реальной причины, будь то юридические обязательства или объективные индикаторы риска.
Более глубокое понимание GDPR внутри компании способствует как ответственному обращению с данными, так и принятию более взвешенных оперативных решений. Это также помогает предотвратить излишнюю сложность процессов соблюдения требований.
Проверка благонадежности клиентов становится частью обычной операционной деятельности.
Для хостинг-провайдеров и поставщиков облачных услуг процесс подключения к системе перестал быть просто этапом продаж или технической поддержки. Он все чаще становится частью более широкого процесса управления рисками.
Это не означает, что нужно относиться к каждому клиенту как к подозрительному. Это означает наличие разумного способа понять, кто этот клиент, имеет ли предоставленная им информация смысл и заслуживает ли что-либо в данном случае более тщательного изучения.
Иногда это означает более тщательную проверку данных о бизнесе или личности. Иногда это означает внимание к структуре собственности. Иногда это означает выявление неполноты, противоречивости или несоответствия подтверждающей информации заявленному сценарию использования.
Вот где обучение действительно имеет ценность. Оно помогает командам понять не только формальную процедуру, но и то, как разумно ее применять. Когда достаточно стандартного вводного обучения? Когда оправдан более глубокий анализ? Когда следует передать дело на рассмотрение вышестоящему руководству?
Это практические вопросы, а не теоретические.
И подход, основанный на оценке рисков, по-прежнему имеет важное значение. Большинство клиентов должны иметь возможность пройти процедуру регистрации без лишних сложностей. В то же время поставщикам услуг необходим четкий способ выявления случаев повышенного риска и соответствующего реагирования.
Почему осведомленность о санкциях тоже важна
Понимание необходимости соблюдения санкций также стало более актуальным для поставщиков инфраструктурных услуг.
Инфраструктурные услуги часто включают клиентов, организации и транзакции, связанные с несколькими юрисдикциями. Поэтому вопросы, касающиеся санкций, нельзя рассматривать исключительно как относящиеся к финансовому сектору. Поставщикам услуг необходимо достаточно глубокое внутреннее понимание ситуации, чтобы распознавать, когда требуется дополнительная осторожность, а когда дело нуждается в дальнейшем рассмотрении.
Это не означает, что каждая необычная ситуация должна приводить к ограничениям или эскалации. Это означает, что организация должна уметь отличать обычный случай от случая, заслуживающего более пристального внимания.
Для MIRhosting повышение осведомленности в этой области способствует более последовательной внутренней оценке и более надежному подходу к отзывам клиентов.
Часть более широкой модели безопасности
Здесь кроется более важный момент.
В инфраструктуре безопасность — это не только технические аспекты. Межсетевые экраны, сетевые средства контроля, физическая защита и меры кибербезопасности остаются важными, но они не исчерпывают всей картины. Компания не сможет построить устойчивую операционную модель, если будет сосредотачиваться только на системах и оборудовании, игнорируя риски для клиентов, обработку данных, качество внутренней проверки или подверженность санкциям.
Верно и обратное. Процессы обеспечения соответствия требованиям гораздо менее эффективны, когда они оторваны от оперативной реальности.
Эти области работают наиболее эффективно, когда рассматриваются как часть единой системы. Защита данных, проверка благонадежности клиентов, осведомленность о санкциях, внутренние процессы проверки и технические меры защиты — все это способствует одному и тому же результату: более надежной и подотчетной работе инфраструктуры.
В MIRhosting укрепление экспертных знаний в этих областях является частью более широкого подхода. Это способствует повышению внутренних стандартов, большей согласованности и более зрелому пониманию того, что требуется для ответственной эксплуатации инфраструктуры.
Практический шаг вперед
Сектор инфраструктуры меняется. Клиенты по-прежнему ожидают производительности, надежности и оперативной поддержки. Но они также ожидают от поставщиков работы в соответствии с четкими стандартами и надежными внутренними процессами.
Вот почему важна внутренняя экспертиза. Она помогает командам принимать более взвешенные решения, более последовательно применять правила и подходить к проверке клиентов и защите данных практично и соразмерно.
Для MIRhosting недавнее обучение, пройденное нашей командой, является частью этих усилий. Оно отражает нашу постоянную работу по укреплению как операционной, так и технической стороны безопасности инфраструктуры, одновременно обеспечивая работоспособность процесса подключения для добросовестных клиентов.

13 марта 2026 MIRhosting усиливает контроль за соблюдением нормативных требований и проверкой клиентов благодаря интеграции с Handelzeker
Компания MIRhosting укрепляет свою систему безопасности и соответствия нормативным требованиям благодаря новой интеграции с Handelzeker, голландским поставщиком автоматизированных решений для проверки благонадежности клиентов и выявления нарушений санкций.
В настоящее время партнерство реализуется через API и призвано улучшить процессы регистрации клиентов, проверки на соответствие санкциям, предотвращения злоупотреблений и постоянного мониторинга рисков, осуществляемые компанией MIRhosting. Благодаря этой интеграции данные клиентов могут автоматически проверяться по нескольким международным источникам, включая санкционные списки ЕС, реестры политически значимых лиц и базы данных негативной информации в СМИ.
Для MIRhosting этот шаг отражает более широкое изменение в понимании безопасности инфраструктуры. Традиционные риски, такие как хакерские атаки и DDoS-атаки, остаются важными, но теперь юридические, нормативные и репутационные риски требуют такого же уровня внимания.
Будучи нидерландской компанией, работающей на международном уровне, MIRhosting продолжает структурировать свои внутренние процессы приема и контроля клиентов в соответствии с требованиями санкций, обязательствами Wwft, требованиями AML/CTF и предотвращением финансирования терроризма. Цель состоит не только в том, чтобы соответствовать требованиям регулирующих органов, но и в том, чтобы сократить операционные «слепые зоны» и укрепить долгосрочное управление рисками.
По данным MIRhosting, структурированная проверка клиентов становится неотъемлемой частью ответственного управления инфраструктурой. На практике недостаточная осмотрительность может привести к серьезным операционным, юридическим и репутационным рискам — не только для самих провайдеров, но и для партнеров и добросовестных клиентов.
Компания заявляет, что ее модель соответствия требованиям основана на принципе конфиденциальности по умолчанию и соответствует GDPR, соответствующим нормативным актам ЕС и Закону о цифровых услугах. Обработка контента клиентов осуществляется только по явному запросу клиента или по законному запросу компетентного органа.
Решение об усилении внутренних процедур было также обусловлено предыдущей ситуацией, когда клиент косвенно оказался замешан в санкциях. В соответствии с действующими обязательствами, предоставление услуг было немедленно прекращено, и для обеспечения тщательного рассмотрения дела и надлежащего документирования были привлечены внешние юристы.
«Подобные ситуации могут возникнуть в любой момент, даже после начала работы с компанией», — сказал Андрей Нестеренко, основатель MIRhosting. «Именно поэтому мы инвестируем в более строгие внутренние процедуры и постоянный мониторинг. Handelzeker — важная составляющая этого процесса, но всегда в рамках более широкой системы, которую мы активно совершенствуем».
Компания MIRhosting ожидает, что интеграция с Handelzeker позволит проводить более быстрые и надежные проверки клиентов, а также повысит общий уровень безопасности и соответствия нормативным требованиям компании.

22 февраля 2026 Компания MIRhosting оказывает поддержку Международному конкурсу пианистов в Энсхеде и обеспечивает его техническое сопровождение с 2006 года

Международный конкурс пианистов для юных музыкантов проводится в Энсхеде каждые четыре года и в этом году отметил свою 25-ю годовщину.
Компания MIRhosting является технологическим партнером конкурса с 2006 года. Мы обеспечиваем техническое сопровождение проекта, включая веб-сайт, запись выступлений и прямую трансляцию, чтобы зрители могли следить за конкурсом как в зале, так и онлайн.
Наша работа сосредоточена на трех ключевых областях: стабильная потоковая передача, точная синхронизация аудио и видео, а также скоординированные рабочие процессы камер и операторов. Такой подход помогает обеспечить стабильное и ничем не отвлекающее качество просмотра как для зрителей на месте проведения мероприятия, так и для онлайн-аудитории.
За этим партнерством стоит и личная история. Андрей Нестеренко, основатель MIRhosting, впервые принял участие в конкурсе в 2002 году и занял второе место. Позже он учился в Энсхеде у Михаила Маркова, основателя и музыкального директора конкурса.
Компания MIRhosting продолжает участвовать в организации и техническом обеспечении мероприятия и оказывает поддержку конкурсу в качестве его технологического партнера.

5 декабря 2025 Как MIRhosting использует 400G ZR+ для объединения суверенитета данных с высокопроизводительным межцентровым соединением

Амстердам остается одним из важнейших европейских центров цифровой инфраструктуры. Его ценность очевидна: развитая экосистема операторов связи, широкие возможности пиринга и прямой доступ к провайдерам, с которыми многие компании по-прежнему хотят оставаться в непосредственной близости. Для компаний, планирующих создание своей инфраструктуры, размещение оборудования в Амстердаме продолжает предлагать реальное стратегическое преимущество.
Но рынок изменился. В окрестностях Амстердама реальным ограничением является уже не только наличие стоек. Во многих случаях это электроэнергия — и, в более широком смысле, сколько полезной мощности еще можно разместить в нужном месте. По мере роста спроса все больше компаний вынуждены выходить за пределы одного объекта или даже за пределы одного мегаполиса.
Это создает практическую проблему. Предприятия по-прежнему хотят иметь доступ к экосистеме связи Амстердама, но не все рабочие нагрузки должны размещаться в уже перегруженном центральном узле. Им нужен способ масштабирования на другие площадки без потери производительности, согласованности или контроля.
Именно эту проблему и стремилась решить компания MIRhosting
Задача: оставаться вблизи крупных транспортных узлов, не ограничиваясь ими.
Многие организации по-прежнему стремятся располагаться вблизи ключевых узлов межсетевого взаимодействия в Амстердаме и его окрестностях. Такие объекты, как Nikhef, Equinix и аналогичные, остаются центральными элементами региональной сетевой инфраструктуры. Проблема заключается в том, что когда слишком много компаний конкурируют за одно и то же пространство и электроэнергию, гибкость начинает исчезать.
На практике инфраструктура часто оказывается распределенной по нескольким комнатам, коридорам или совершенно отдельным площадкам центров обработки данных. Это может работать, но только если эти площадки по-прежнему функционируют как единая среда.
Без правильной архитектуры распределенная инфраструктура быстро превращается в фрагментированную.
Подход MIRhosting: физическое распределение, логическая согласованность.
Компания MIRhosting разработала межцентровую архитектуру, которая позволяет клиентам развертывать инфраструктуру там, где действительно есть свободные мощности, включая пригородные и региональные площадки, оставаясь при этом напрямую подключенными к крупным узлам в Амстердаме и Франкфурте через собственную сеть MIRhosting.
Цель была проста: клиентам не нужно было бороться за последнюю свободную стойку в перегруженном центре обработки данных, чтобы оставаться рядом с нужной экосистемой. Они должны иметь возможность размещать рабочие нагрузки там, где есть место для роста, сохраняя при этом надежный доступ к сетям и точкам межсоединения, которые для них важны.
Для этого компания MIRhosting объединила VXLAN с технологией 400G ZR+
VXLAN позволяет объединять несколько физических местоположений в единую логическую среду. Это означает, что инфраструктура может быть распределена по разным площадкам без потери сегментации, согласованности или оперативного контроля. С точки зрения клиента, среда по-прежнему функционирует как единая платформа, даже если оборудование находится в разных местах.
Технология 400G ZR+ обеспечивает транспортный уровень, делающий эту модель практичной в масштабируемом режиме. Она позволяет осуществлять высокоскоростное прямое соединение между точками и поддерживает производительность, необходимую для современной распределенной инфраструктуры.
Для клиентов, которые стремятся совместить размещение оборудования в Амстердаме с расширением за пределы столичного региона, такое сочетание особенно полезно.
Почему 400G ZR+ имеет значение
В этой архитектуре 400G ZR+ — это не просто пропускная способность. Ее настоящая ценность заключается в архитектурных особенностях.
Традиционные схемы передачи данных часто зависят от дополнительных промежуточных систем, что усложняет систему, увеличивает операционные издержки и создает дополнительные точки зависимости. Компания MIRhosting выбрала более прямой подход, используя оптические модули 400G ZR+ непосредственно в основной сети. Это позволило уменьшить потребность в дополнительных транспортных уровнях и создать более чистую топологию.
В результате получается не только высокоскоростное межсайтовое соединение, но и более простая в эксплуатации и масштабировании конструкция. В реальных условиях производительность определяется не только пропускной способностью. Простота, предсказуемость и управляемость имеют не меньшее значение.
На практике 400G ZR+ помог MIRhosting создать мощную платформу, не усложненную при этом.
Практический пример
Рассмотрим компанию, которая хочет разместить чувствительные к задержкам сервисы и рабочие нагрузки, взаимодействующие с межсетевыми соединениями, недалеко от Амстердама, но предпочитает разместить часть своих вычислительных или запоминающих мощностей в месте, где больше электроэнергии и места.
Без правильной организации межцентровой сети это обычно приводит к разрозненным каналам связи, несогласованным политикам и дополнительным операционным издержкам. С VXLAN и 400G ZR+ эти среды можно объединить в единую логическую платформу. В результате получается более чистая операционная модель: инфраструктура физически распределена, но не создает ощущения операционной фрагментации.
Суверенитет данных посредством выбора инфраструктуры
Одним из важнейших результатов применения этой модели является укрепление суверенитета данных.
Клиенты все чаще хотят иметь больший контроль над размещением инфраструктуры и рабочих нагрузок. Иногда это обусловлено требованиями законодательства. Иногда это связано с внутренней политикой, управлением рисками или желанием избежать чрезмерной зависимости от одного перегруженного мегаполиса.
Благодаря возможности размещения инфраструктуры в альтернативных центрах обработки данных при сохранении прямой интеграции с основными узлами связи, MIRhosting предоставляет клиентам больший контроль над географическим расположением, распределением рисков и долгосрочным планированием.
Речь идёт не только о физическом местоположении оборудования. Это также вопрос суверенитета сети. Поскольку соединение осуществляется через собственную сеть MIRhosting, клиентам не приходится использовать разрозненную модель сторонних поставщиков только для того, чтобы оставаться на связи с Амстердамом и Франкфуртом.
Это создает существенное преимущество для организаций, которым необходима как региональная устойчивость, так и доступ к крупным европейским центрам, включая размещение оборудования во Франкфурте в рамках более широкой стратегии обеспечения связи.
Более эффективный способ использования имеющихся мощностей.
Этот подход также отражает более реалистичную модель роста числа объектов, размещаемых в одном месте.
Если вся рабочая нагрузка будет сосредоточена в одних и тех же центральных узлах, нагрузка на пространство и электроэнергию будет только возрастать. Это неэффективно для операторов и негибко для клиентов. Лучший подход — использовать мощности там, где они действительно есть, сохраняя при этом достаточную мощность сети, чтобы распределенное развертывание работало бесперебойно.
Именно это и обеспечивает MIRhosting.
Клиенты могут размещать инфраструктуру в местах с большим потенциалом роста, сохраняя при этом прямые высокопроизводительные каналы связи с Амстердамом и Франкфуртом. Для некоторых это означает сочетание развертывания в пригородах с выборочным размещением оборудования в Амстердаме, где доступ к экосистеме имеет наибольшее значение. Для других это означает создание более сильной региональной сети с прямым подключением к Франкфурту и другим стратегическим точкам соединения.
Эффективность за счет продуманного дизайна
Здесь также наблюдается очевидная выгода с точки зрения эффективности.
Упростив транспортный уровень и сократив количество промежуточных систем, MIRhosting повысила общую эффективность проектирования. Меньшее количество уровней означает меньшую сложность управления и более прочную основу для долгосрочной операционной стабильности.
Это на практике подтверждает принцип «экологичности по умолчанию». Более эффективное использование доступной энергии, более разумные решения по размещению и более чистая сетевая архитектура — все это способствует более устойчивому масштабированию инфраструктуры.
Высокая производительность в реальных условиях
Важной особенностью этого проекта является то, что MIRhosting не рассматривал производительность как теоретическое значение.
400G ZR+ предоставляет значительные преимущества, но также предъявляет реальные требования к энергопотреблению, охлаждению и конструкции оборудования. Компания MIRhosting тщательно подошла к этим ограничениям и принимала решения, основываясь на стабильности и надежности в производственной среде. Целью было не создание максимально агрессивной конфигурации на бумаге, а обеспечение стабильной работы платформы в реальных условиях эксплуатации.
Именно это и должна означать высокая производительность в инфраструктуре: не только скорость, но и правильный баланс масштаба, отказоустойчивости, эффективности и управляемости.
Создан для роста без добавления лишней сложности.
Основная ценность этой архитектуры очевидна. Она предоставляет клиентам возможность развиваться, не будучи привязанными к одному ограниченному местоположению.
Вместо того чтобы заставлять клиентов выбирать между возможностями подключения и пропускной способностью, MIRhosting позволяет сохранить и то, и другое. Клиенты могут развертывать решения там, где расширение реально, оставаясь при этом напрямую связанными с экосистемами, поддерживающими их бизнес.
Благодаря VXLAN и 400G ZR+ физически распределенная инфраструктура может по-прежнему функционировать как единая логическая среда. Собственная сеть MIRhosting позволяет выйти за рамки традиционного ядра, не теряя доступа или контроля. Это означает большую гибкость в размещении, подключении и масштабировании инфраструктуры.
Заключение
Будущее размещения оборудования в центрах обработки данных заключается не только в том, чтобы максимально приблизиться к крупнейшим узлам. Речь также идет о том, как разумно использовать эти узлы, не становясь полностью зависимым от их ограничений.
Межцентровая архитектура MIRhosting демонстрирует, что клиентам не нужно выбирать между суверенитетом данных, высокой производительностью и прямым доступом к Амстердаму и Франкфурту. Объединив VXLAN, 400G ZR+ и собственную сеть, MIRhosting создала модель, которая упрощает эксплуатацию, масштабирование и делает распределенную инфраструктуру более практичной в долгосрочной перспективе.

4 сентября 2025 MIRhosting выходит на индийский рынок: услуги управляемого размещения оборудования теперь доступны в Мумбаи

Услуги по размещению оборудования в центрах обработки данных в Мумбаи: практичный способ выхода на индийский рынок.
Мумбаи — один из ключевых цифровых центров Южной Азии, и для многих международных компаний это наиболее практичная точка входа на индийский рынок. Главная проблема обычно заключается не в поиске места в дата-центре, а в обеспечении бесперебойной работы повседневных операций, когда ваша команда находится не в городе.
Именно поэтому MIRhosting расширяет свое присутствие. Теперь мы предлагаем услуги управляемого размещения оборудования в Мумбаи, поддерживаемые инженерами из Индии и круглосуточной оперативной поддержкой.
Что означает управляемое размещение оборудования в MIRhosting?
В MIRhosting управляемое размещение оборудования выходит за рамки простой аренды стоек. Мы предлагаем операционную модель, которая позволяет вам выбрать уровень контроля и поддержки, подходящий для вашей команды.
Благодаря нашей представительстве в Мумбаи вы можете:
Вы можете использовать собственное оборудование или воспользоваться нашими услугами по закупке и изготовлению на заказ.Управление сетевыми сервисами и IP-транзитом осуществляется компанией MIRhosting.Воспользуйтесь круглосуточной удаленной поддержкой инженеров, находящихся на месте в Индии.Получите комплексную поддержку, от поиска и настройки оборудования до координации таможенных процедур и текущей эксплуатации.Для компаний, которым нужна инфраструктура в Индии без создания полноценного локального операционного уровня, это зачастую наиболее оптимальный подход. Он сочетает в себе гибкость частного размещения оборудования с удобством модели управляемых услуг.Центр обработки данных в Мумбаи
Наше решение для Мумбаи предоставляется через партнерский центр обработки данных уровня Tier-4, управляемый компанией Yotta, который разработан для обеспечения высокой отказоустойчивости и соблюдения строгих эксплуатационных стандартов.
Объект подходит для современных задач, в том числе в условиях высокой плотности населения, и предлагает:
до 12 кВт на стойку с полным резервированием,дополнительные мощности для стоек высокой плотности, включая инфраструктуру для графических процессоров и искусственного интеллекта.Энергоэффективная система охлаждения, разработанная для рабочих нагрузок в области искусственного интеллекта/машинного обучения и высокопроизводительных вычислений.Многоканальное подключение к сети нескольких операторов связи первого уровня.Благодаря этому платформа подходит как для стандартных корпоративных развертываний, так и для более требовательных сценариев инфраструктуры, где требуется размещение оборудования в частных центрах обработки данных или более высокая плотность размещения оборудования в стойках.Для кого это создано?
Данная схема особенно актуальна для компаний, которые:
въезжают в Индию и нуждаются в надежном первом пункте посадки в Мумбаи.Мы управляем многорегиональными платформами и стремимся к стабильному присутствию в Азии.Необходима непосредственная оперативная поддержка без найма местного персонала.для выполнения работ с высокой плотностью нагрузки требуется помещение, уже подготовленное для таких задач.Как начать
Для подготовки практического плана внедрения, пожалуйста, предоставьте нам три входных параметра:
Плотность размещения оборудования в стойках и требования к энергопотреблению, включая мощность в кВт на стойку и количество стоек.Требования к подключению, включая операторов связи, транзит, кросс-соединения и потребности в IP-протоколе.сроки и предпочтительная модель работы, независимо от того, используете ли вы собственное оборудование или вам требуется закупка и изготовление на заказ.После этого мы определим необходимый объем поддержки и перейдем к внедрению. Если вы также сравниваете цены на размещение оборудования в дата-центре, мы можем помочь вам оценить компромисс между стандартным местом в стойке, частным размещением и полностью управляемой моделью размещения в дата-центре в Мумбаи.
27 мая 2025 MIRhosting теперь является официальным партнером SpeedIX во Франкфурте (Equinix FR5/FR7)

Франкфурт предлагает множество вариантов пиринга, и у каждого есть свои недостатки. Некоторые платформы отлично подходят для локального трафика. Более крупные международные биржи обеспечивают более широкий охват, часто с другой моделью ценообразования.
Цель этого партнерства – обеспечить практичность: легкий доступ во Франкфурт и удобный путь в Амстердам, когда это будет целесообразно для вашей архитектурной деятельности.
Компания MIRhosting теперь является официальным представителем SpeedIX во Франкфурте, что делает SpeedIX доступным через нашу инфраструктуру в офисах Equinix FR5 и FR7.
Что это дает для сетей во Франкфурте?
1) Бесплатные порты пиринга 10G
С SpeedIX от MIRhosting вы получаете бесплатный доступ к порту пиринга 10G без каких-либо периодических платежей или платы за настройку, как указано в объявлении. Это простой способ быстро начать пиринг или без проблем расширить существующие сессии.
2) Транспорт L2 Франкфурт ↔ Амстердам
Если ваша сеть охватывает оба узла (или вам нужна такая опция), мы обеспечиваем передачу данных уровня 2 из Франкфурта в Амстердам по нашей магистральной сети DWDM. Цель проста: поддерживать порядок на транспортном уровне, а не создавать цепочку отдельных каналов.
3) Открытая модель пиринга и простые обновления.
SpeedIX использует открытую модель пиринга — участники могут обмениваться услугами как локально, так и за пределами сообщества. А когда вам потребуется больше пропускной способности, по запросу доступны обновления без полной перестройки всей системы.
Для кого это предназначено?
Эта конфигурация идеально подходит, если вы:
Мы работаем во Франкфурте и ищем практичный вариант IX с низким порогом входа.Необходимо обеспечить связь с Амстердамом в рамках той же сетевой логики.Предпочтительны решения, которые остаются чистыми по мере роста сети.Как начать
Процесс намеренно упрощен:
Подайте заявку на членство в SpeedIXВыберите точку присутствия в офисе Equinix FR5 или FR7 (Франкфурт).MIRhosting поддерживает предоставление ресурсов и настройку.Если вам нужна помощь с «скучными, но важными» аспектами — проектированием VLAN/L2, форматом хэндоффа или интеграцией этого в вашу транспортную сеть — просто упомяните об этом. Мы предложим вам удобную для работы конфигурацию.Готовы к общению?
Укажите, где у вас уже есть присутствие (FR5/FR7 и/или Амстердам), вашу начальную мощность и какой сценарий наиболее важен: локальный пиринг, L2 в Амстердам или оба. mirhosting.com/speedix-frankfurt