FirstVDS Хостинг

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


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

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

В общем, листайте и выдыхайте!

Статьи и инструкции
Установка и настройка Portainer
Если у вас несколько Docker-хостов, может возникнуть вопрос, как управлять ими централизованно. Ответ — Portainer, веб-платформа для организации контейнерной инфраструктуры через единый GUI и REST API. Подключается к средам на базе Docker, Docker Swarm и Kubernetes и позволяет администрировать их из одного интерфейса. В статье на примере Ubuntu 24.04 пошагово показываем, как поднять и запустить её вручную
firstvds.ru/technology/ustanovka-i-nastroyka-portainer
Как установить и запустить vLLM: от базовой проверки до тяжёлых моделей
vLLM — сервер для запуска ИИ-моделей с открытым API. С его помощью можно поднять локальный эндпоинт для больших языковых моделей и подключить к нему свои приложения, чат-ботов или агентов. В статье рассказываем про два варианта установки vLLM — uv и Docker, а также разбираем основные параметры запуска.
firstvds.ru/technology/kak-ustanovit-i-zapustit-vllm

Habr: самое интересное за июнь
Ловите подборку из нашего блога на Хабре. Гвоздь программы — статья о том, как мы взяли L40S и vGPU на 16 ГБ и прогнали через бенчмарки в реальных задачах. Далее — пара рабочих гайдов: как ускорить сайт через оптимизацию изображений и как организовать личный CI/CD. Бонусом — необычная история о математике и плагиате.

• Тестируем выделенный L40S и vGPU на 16 ГБ по производительности (llama.cpp, ComfyUI)
• Оптимизация под Pagespeed: работа с изображениями как с наиболее частой и весомой проблемой сайтов
• Личный CI/CD за один вечер: настраиваем GitLab Runner на собственном VPS
• Человек, укравший бесконечность: подлинная история Георга Кантора

Ищем авторов для блога на Хабр.

Подготовьте статью на одну из специальных тем или отправьте материал на тему месяца. И если ваша статья подойдёт для блога, вы получите повышенный гонорар.
Тема июля: Алгоритмы.
firstvds.ru/avtoram

Новости июня
Запустили новую услугу — «Мониторинг сайтов»

Теперь следить за доступностью сайта, сервера, домена и SSL-сертификата можно в одной панели. Сервис работает 24/7, отслеживает четыре ключевых параметра и при появлении проблем сразу отправляет уведомления на email, в телеграм, VK и другие каналы. Это помогает быстрее замечать сбои, не тратить время на ручные проверки и снижать риск простоев.
firstvds.ru/services/site-monitoring

Кешбэк до 10% по выходным в течение всего лета

Летние выходные стали ещё приятнее. Каждую пятницу, субботу и воскресенье за пополнение баланса (на рекомендуемую сумму и выше) можно получить кешбэк до 10%. Посмотреть рекомендуемую сумму можно через форму пополнения баланса на сайте или в Личном кабинете.
Процент кешбэка выше, если оплачивать услуги через СБП. Акция продлится до 30 августа.

Добавили новые рецепты для автоустановки на сервере

В июне мы добавили три новых рецепта для быстрого развёртывания популярных сервисов на VDS. При заказе сервера просто выбираете нужный рецепт и получаете VDS с уже предустановленным ПО. Все рецепты — бесплатные.
OpenClaw и Hermes Agent — self-hosted платформы для ИИ-агентов. Обе позволяют общаться с ассистентом через веб-интерфейс или в телеграме. Встроенные инструменты включают поиск в интернете и работу с файлами. OpenClaw интегрируется с Gmail, GitHub и другими сервисами, а также даёт доступ к агенту через API. Hermes Agent умеет подключаться к терминалу сервера и планировщику задач cron, что удобно для автоматических фоновых сценариев.
n8n — open-source платформа для автоматизации без кода. Поможет создать сценарии из готовых блоков в визуальном редакторе: от сбора данных по расписанию до отправки уведомлений и резервного копирования.

Доступна регистрация домена на родном языке

Теперь зарегистрировать сайт или почту можно на родном языке — без транслита и искажений. В зону.РФ добавлены буквы абазинского, татарского, чеченского, якутского и ещё 13 языков. А также 26 новых кириллических символов. Меньше барьеров, больше родного языка в интернете.
firstvds.ru/services/domain_names
Важно: С 1 сентября вступят в силу требования ФЗ № 569: владельцам доменов придётся проходить обязательную идентификацию через Госуслуги. Оформляйте домен на реальные данные, чтобы избежать проблем в дальнейшем.

Июньские изменения: что важно знать

Жизнь не стоит на месте, и июнь 2026-го — очередное тому подтверждение. Собрали самое важное в одном месте, чтобы вы были в курсе изменений и могли заранее к ним подготовиться.
О частичной недоступности ресурсов по HTTPS
С 1 июля повысятся цены на VDS и объектное хранилище S3
Новые правила работы с SSL-сертификатами

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

Один HTTP-запрос открывает доступ к любому аккаунту в phpBB
В свободном движке для форумов phpBB нашли уязвимость обхода аутентификации. Одним HTTP-запросом атакующий подключается к сессии любого пользователя форума, включая администратора. Проблема проявляется в конфигурации по умолчанию — никаких специальных условий или знания внутреннего устройства платформы не требуется. По данным исследователей, ошибка прожила в кодовой базе около десяти лет.
Метод эксплуатации уже воссоздали с помощью ИИ на основе патча. Запрос идёт к обработчику login_link с методом аутентификации auth_provider=apache, а логин подставляется через Basic Auth. После этого PHP выставляет переменную окружения PHP_AUTH_USER, и phpBB достаёт из неё логин без проверки пароля.
Уязвимость затрагивает все версии веток 3.x и 4.x вплоть до phpBB 3.3.16 и 4.0.0-a2. Перехват сессии обычного пользователя даёт доступ к приватной переписке и возможность писать от его имени. С сессией модератора или администратора добавляются удаление чужих сообщений, просмотр IP-адресов и email, чтение приватной переписки. Но даже админская сессия не открывает саму панель администрирования: вход в неё защищён отдельной проверкой пароля, поэтому до хоста и удалённого выполнения кода баг не доводит. Искать жертв несложно — список участников на форумах phpBB по умолчанию открыт всем.
Уязвимость обнаружили в начале июня специалисты компании Aikido и через программу bug bounty на HackerOne передали данные разработчикам. Те отреагировали быстро: уже 6 июня вышел патч в составе версии 3.3.17. Крупные форумы исследователи предупредили напрямую.
Что делать: обновиться до версии 3.3.17. Для ветки 4.x стабильного исправления пока нет, поэтому пользователям рекомендуют перейти на актуальную версию. После обновления некоторые форумы могут столкнуться с проблемами в работе OAuth-аутентификации — это связано с переносом обработчика OAuth-переадресации.
www.opennet.ru/opennews/art.shtml?num=65667
xakep.ru/2026/06/16/phpbb-auth-bypass/

В AUR захватили 1577 пакетов и раздавали из них вредонос
AUR (Arch User Repository) массово скомпрометировали — через этот репозиторий в Arch Linux распространяют приложения от сторонних разработчиков. Атакующие получили контроль примерно над 1577 пакетами и внедрили в них код для кражи паролей и ключей доступа. Среди затронутых оказался ALVR — пакет, популярный у любителей компьютерных игр.
Схема простая. Атакующие брали на себя заброшенные пакеты со статусом orphaned: указывали имя прежнего мейнтейнера, но другой email, добавляли один коммит и публиковали обновление. Коммит добавлял npm в зависимости PKGBUILD и вставлял в post_install-блок скрипта install.sh установку нескольких NPM-пакетов. Среди них — один-два легитимных и пакет atomic-lockfile или js-digest со скрытым вредоносным ПО. Установку прописывали во все скомпрометированные проекты, даже туда, где JavaScript и NPM не используются.
После активации вредонос закреплялся в системе как сервис systemd со случайным именем и маскировался под поток ядра. С правами root он создавал сервис на системном уровне (/etc/systemd/system) и дополнительно поднимал rootkit уровня ядра; с правами пользователя — запускал его от имени пользователя (~/.config/systemd/user). Дальше он сканировал систему и отправлял на внешний сервер ключи и учётные данные VPN, Docker, Podman и SSH, конфиденциальные данные из браузера, историю команд shell, ключи криптокошельков и токены доступа к Slack, Microsoft Teams, Discord, GitHub, NPM и Vault.
Масштаб рос на глазах: загрузку вредоносного js-digest успели внедрить в 879 пакетов, общее число захваченных оценивают в 1577. Первой волны не хватило — позже подставили код ещё в 54 пакета, на этот раз через зависимость bun и обфусцированную строку с установкой через bun add. Разработчики Arch Linux принимают меры, поэтому до окончательного решения возможны проблемы с регистрацией новых учётных записей в AUR, отправкой обновлений и созданием пакетов.
www.opennet.ru/opennews/art.shtml?num=65670

Дыра в JCE для Joomla открывает прямой путь к веб-шеллу
В JCE (Joomla Content Editor) — одном из старейших и популярнейших расширений Joomla — устранили критическую уязвимость CVE-2026-48907. Она позволяла импортировать профиль без аутентификации: атакующий заливал профиль, который отключал проверку MIME-типов и разрешал загрузку PHP-скриптов на сервер. Уязвимость успели взять на вооружение — зафиксированы реальные атаки, в которых злоумышленники ставили веб-шелл и получали удалённый доступ к системе. Затрагивает все версии JCE — от Joomla 3 до Joomla 6.
Что делать: обновиться до выпуска 2.9.99.5, следом за которым вышло обновление 2.9.99.6 с усилением защиты. После обновления стоит убедиться, что система не скомпрометирована и в ней не остался бэкдор:

• проверить подставной профиль (как правило, у него бессмысленное автоматически сгенерированное имя): Компоненты → Редактор JCE → Профили редактора;
• убедиться, что в параметре Разрешённые расширения файлов нет разрешения на загрузку PHP-файлов;
• просмотреть логи на предмет запросов к URL импорта профилей: index.php?option=com_jce&task=profiles.import;
• проверить сайт на сторонние .htaccess и файлы с именами, типичными для WordPress, а не Joomla, — например, wp-config.php и wp-cron.php.

www.opennet.ru/opennews/art.shtml?num=65715

Один восклицательный знак в ядре Linux открывает путь к root
Исследователи Exodus Intelligence разобрали уязвимость CVE-2026-23111 в подсистеме nf_tables. Это механизм пакетной фильтрации в ядре Linux: он управляет правилами брандмауэра и сменил iptables, ip6tables, arptables и ebtables. Виной всему один лишний восклицательный знак в коде — из-за него возникла ошибка use-after-free. Она позволяет непривилегированному пользователю или процессу поднять права до root.
Уязвимость ломает процесс удаления вердиктов — определений, которые решают, подходит ли пакет под правило. В нём участвуют элементы catchall: они работают как подстановочный знак, когда совпадений с другими элементами набора нет. Когда карта вердиктов удаляется из памяти, catchall-элементы деактивируются, а счётчик ссылок цепочки уменьшается. Если при удалении возникает ошибка, операция отменяется, а счётчик возвращается обратно. CVE-2026-23111 позволяет вмешаться в этот процесс: эксплойт уменьшает счётчик произвольное число раз, а затем удаляет и освобождает цепочку, хотя часть объектов всё ещё на неё ссылается. Так и появляется обращение к уже освобождённой памяти.
Если верить Exodus Intelligence, эксплойт многократно срабатывает на этой уязвимости и приводит к утечке базового адреса ядра, затем адресов кучи и перехвату потока управления. На неактивной системе авторы добились стабильности выше 99 %. Уязвимость воспроизводится на Debian и Ubuntu.
Уязвимость закрыли в ядре ещё в феврале. В апреле эксплойт продемонстрировала компания FuzzingLabs, а затем собственный рабочий эксплойт опубликовала и Exodus Intelligence — он тоже работал на Debian и Ubuntu.
Такие баги особенно опасны в связке: вместе с отдельным эксплойтом они позволяют обходить встроенную защиту операционной системы.
Что делать: Исправление вышло ещё в феврале — установите обновление ядра.
3dnews.ru/1143264/v-yadre-linux-nashli-seryoznuyu-uyazvimost-sozdannuyu-vsego-odnim-lishnim-simvolom-v-kode/

Гонка в процессорах ARM выпускает гостя за пределы виртуальной машины
Компания ARM раскрыла уязвимость CVE-2025-10263 в своих процессорах. Она позволяет писать в ресурсы, принадлежащие более высокому уровню исключений (Exception Level), и так повышать привилегии в системе. В связке с гипервизором Xen последствия еще более серьёзные: гостевая система может писать в память гипервизора.
В основе — рассинхронизация при операции TLBI (TLB Invalidation), которая очищает запись в кэше трансляции адресов (TLB). Инструкция DSB (Data Synchronization Barrier) подтверждает выполнение TLBI. Но на одном процессорном ядре она может отработать раньше, чем запись с другого станет видна всей системе. Из-за этого запись успевает пройти уже после того, как доступ был закрыт через TLBI.
Из-за этой рассинхронизации можно обойти сразу несколько барьеров защиты памяти: ограничения на уровне хоста (Stage 1) и виртуальной машины (Stage 2), а также защиту целостности памяти GPT (Granule Protection Table). На практике это выглядит так. Гипервизор командой TLBI закрывает виртуальной машине доступ к памяти. Система подтверждает, что доступ прекращён, — но гостевая ВМ всё равно продолжает туда писать.
Проблема проявляется только на многоядерных процессорах Arm: C1-Ultra, C1-Premium, Neoverse V3 и V3AE, Neoverse V2, Neoverse V1, Neoverse N2, Neoverse N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 и X1C, Cortex-A710, Cortex-A78, A78AE и A78C, Cortex-A77, Cortex-A76 и A76AE, а также NVIDIA Olympus.
Что делать:

• Для гипервизора Xen исправление уже выпущено — установите его.
• Для ядра Linux патч предложен, но в штатные обновления пока не вошёл — следите за апдейтами своего дистрибутива.

www.opennet.ru/opennews/art.shtml?num=65660

Червь mini-shai-hulud в 32 NPM-пакетах Red Hat
Злоумышленники скомпрометировали сборку релизов на GitHub Actions в репозиториях Red Hat (аккаунт RedHatInsights на GitHub). В результате в каталог NPM попали 64 вредоносные версии 32 пакетов для платформы Red Hat Cloud Services.
В код встроили новый вариант червя mini-shai-hulud. Об аналогичной атаке мы уже писали: тогда червь прошёл через пакеты TanStack и зацепил GitHub и OpenAI.
Новый вредонос ищет токены и учётные данные в окружении. Червь размещается в файле index.js и активируется через preinstall-обработчик при установке поражённого пакета. После запуска он ищет в системе токены к NPM (~/.npmrc), PyPI, CircleCI, AWS, GCP, Docker, Azure, HashiCorp и Kubernetes, а также закрытые ключи SSH, и отправляет найденное злоумышленникам. Если червь находит токен к NPM, он сам публикует новые вредоносные релизы для пакетов из текущего окружения — и так заражает дерево зависимостей.
Доступ к GitHub Actions злоумышленники получили через скомпрометированную учётную запись сотрудника Red Hat. Это позволило отправлять коммиты в репозитории javascript-clients, frontend-components и platform-frontend-ai-toolkit напрямую, в обход рецензирования. Через коммиты подставлялся файл ci.yaml, который при сборке запускал с помощью bun скрипт _index.js. Скрипт использовал полномочие id-token: write, чтобы запросить у GitHub токен OIDC (OpenID Connect), а затем применял его для аутентификации в NPM по механизму trusted publishing.
Кого затронуло: всех, кто устанавливал поражённые версии пакетов @redhat-cloud-services/*. Полный список из 32 пакетов с заражёнными версиями — тут.
Как защититься:

• Проверить, не установлены ли перечисленные версии. Если установлены — считать все токены и учётные данные на этой машине скомпрометированными и сразу их перевыпустить.
• Закрепить конкретные версии зависимостей и переходить на чистую установку из локфайла (npm ci).
• По возможности отключить выполнение установочных скриптов сторонних пакетов (npm install --ignore-scripts).

www.opennet.ru/opennews/art.shtml?num=65599

Захват WordPress-сайтов через плагин WP Maps Pro
В популярном плагине WP Maps Pro для WordPress нашли критическую уязвимость, которую злоумышленники уже эксплуатируют в реальных атаках. Баг позволяет без аутентификации создать на сайте учётную запись администратора и получить полный контроль над ресурсом.
Уязвимость получила идентификатор CVE-2026-8732 и оценку 9,8 балла по шкале CVSS. Под ударом — все версии WP Maps Pro до 6.1.0 включительно. Сам плагин коммерческий, его используют, чтобы встраивать на сайты карты Google Maps и OpenStreetMap, а также создавать локаторы магазинов и каталоги точек продаж.
Проблему обнаружил ИБ-исследователь Дэвид Браун (David Brown). По его словам, корень бага — в функции временного доступа для техподдержки, через которую специалисты разработчика подключаются к сайту клиента для диагностики. Реализация оказалась небезопасной: AJAX-эндпоинт был доступен неавторизованным пользователям и защищался только nonce-токеном, который через JavaScript публиковался на всех страницах сайта. В итоге проверка не давала реального контроля доступа.
Для эксплуатации хватало одного запроса с параметром check_temp=false. После этого плагин создавал нового пользователя с жёстко заданной ролью администратора, генерировал для него magic-ссылку и возвращал её в ответе. При переходе по ссылке WordPress авторизовал пользователя автоматически — ни пароль, ни дополнительные проверки не требовались. Получив права администратора, атакующий мог ставить вредоносные плагины, размещать веб-шеллы, внедрять бэкдоры, красть данные пользователей или полностью перехватить управление сайтом.
Кого затронуло: сайты на WordPress с установленным WP Maps Pro версии 6.1.0 и ниже. Атаки уже идут: в Wordfence сообщили, что за сутки заблокировали около 2858 попыток эксплуатации, а специалисты Defiant за тот же период зафиксировали более 3600 атак.
Как защититься: обновить WP Maps Pro до версии 6.1.1 или новее — патч вышел 20 мая 2026 года и ограничил доступ к проблемному эндпоинту только авторизованными администраторами. Учитывая, что эксплуатация уязвимости уже началась, откладывать обновление не стоит.
xakep.ru/2026/06/04/wp-maps-pro/

HTTP/2 Bomb: атака, которая исчерпывает память сервера
Раскрыта информация об уязвимости HTTP/2 Bomb, которая затрагивает разные реализации протокола HTTP/2 и позволяет добиться отказа в обслуживании, исчерпав всю доступную процессу память. Проблему подтвердили в конфигурации по умолчанию у nginx, Apache httpd (CVE-2026-49975), Microsoft IIS, Envoy (CVE-2026-47774) и Cloudflare Pingora.
Метод напоминает zip-бомбу, только применённую к сжатию заголовков в HTTP/2. Запрос может содержать тысячи сжатых заголовков (например, Cookie) без полезных данных. Каждый такой заголовок в запросе — это однобайтовая ссылка в индексе HPACK, но на сервере под него выделяется память под весь заголовок целиком. Отсюда и многократное усиление: на каждый байт в индексе сервер тратит куда больше.
Кого затронуло: перечисленные HTTP-серверы в конфигурации по умолчанию. Сервер Angie уязвимости не подвержен — защиту от этой атаки в него перенесли из freenginx ещё в версии 1.8.0 в 2024 году. Позднее наличие проблемы подтвердили и в HTTP-сервере h2o.
Как защититься:

• nginx — обновиться до 1.29.8: туда из freenginx перенесли директиву max_headers, которая по умолчанию допускает не более 1000 заголовков.
• Envoy — обновиться до 1.35.11 или 1.36.7 с лимитами mutable_max_request_headers_kb и max_headers_count.
• Cloudflare Pingora — обновиться до 0.8.1, куда добавили ограничения, блокирующие атаку.
• Apache httpd — исправление готово в модуле mod_http2 2.0.41, но в релизы Apache httpd оно ещё не вошло. До выхода релиза обновление сервера дыру не закроет — остаётся обновить mod_http2 вручную или использовать обходной путь (ниже).
• Microsoft IIS — исправления пока нет.
• h2o — исправление доступно в виде патча.
• В качестве обходного пути можно отключить HTTP/2 и выставить ограничение на объём памяти для рабочих процессов.

Теперь в одной панели можно следить за доступностью сайта, сервером, SSL-сертификатом и доменом.
Сервис работает 24/7 и отслеживает:

• URL
• Ping
• SSL
• Domain

Если возникает проблема, сервис сразу отправляет уведомление в выбранный канал связи: Email, Telegram, VK, MAX, Slack или webhooks. Это помогает быстрее замечать сбои, не тратить время на ручные проверки и снижать риск простоев.
firstvds.ru/services/site-monitoring


Сервис находится в стадии MVP, и ваша обратная связь поможет нам сделать продукт лучше. До 13.07.26 включительно предлагаем вам поискать баги (как вы любите). За активность конструктивность мы обязательно порадуем вас бонусом в течение срока тестирования либо после окончания теста. Вступить в группу тестировщиков в телеграм t.me/+Dk2H0nypfLs0ZmJi

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

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

Процент кешбэка различается в зависимости от метода оплаты и для недели.
Пятница:
8% при оплате СБП
6% другие методы оплаты

Суббота:
9% при оплате СБП
7% другие методы оплаты

Воскресенье:
10% при оплате СБП
8% другие методы оплаты

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

https://firstvds.ru

В последние дни часть пользователей сообщает о проблемах с доступом к серверам FirstVDS по протоколам HTTPS, SSH и RDP. Возможны также сбои с ICMP (пинг).

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

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

Как восстановить доступ
Юридическим лицам и ИП. Подайте сведения о ваших IP-адресах и доменах через Личный кабинет ВТС (Выгрузка реестра и технического содействия). Это официальный способ исключить ресурсы из-под блокировок.
service.rkn.gov.ru/monitoring/vts

Всем клиентам — временные решения:

• Используйте веб-консоль (VNC) в личном кабинете FirstVDS. Она работает через браузер и не зависит от SSH и RDP.
• Попробуйте сменить оператора связи — например, переключиться с домашнего интернета на мобильный.
• Временно используйте браузер Mozilla Firefox: его TLS-отпечаток отличается от браузеров на Chromium.
• Отключите QUIC (HTTP/3) в настройках браузера chrome://flags/#enable-quic → Disabled.
• Смена IP-адреса на сервере иногда помогает, но не гарантирует результат: фильтрация применяется к целым подсетям.

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

Уже несколько дней как мы и другие хостинг провайдеры фиксируем аналогичные обращения от клиентов. Также у части провайдеров РФ наблюдаются проблемы с доступностью различных ресурсов, иногда есть зависимость от используемого браузера, протокола https или http и т.п…

С нашей стороны всё работает штатно, никаких изменений или ограничений мы не вносили.

Предполагаем, что могут быть введены какие-либо ограничения со стороны ТСПУ или что-то тестируется в плане очередных блокировок в РФ.

К сожалению, повлиять на ситуацию и помочь вам мы не можем.

Вы можете поискать в сети информацию об этом, широко обсуждается, например

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

Исход любого сражения можно изменить даже в последний момент. Успейте поучаствовать в Битве Гиков — она закончится уже сегодня.
До конца дня ещё можно:

• заказать VDS со скидкой до 30% по промокоду ARTIFACT,
• подключить лимитированный тариф FirstGeek по специальной цене, которая сохранится на всё время заказа и продления сервера,
• принять участие в битве и получить шанс на участие в финальном розыгрыше, если вы ещё не успели это сделать.

ARTIFACT

firstvds.ru/actions/geek_day_2026

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

В зону.РФ добавлены буквы абазинского, адыгейского, алтайского, башкирского, бурятского, ингушского, кабардино-черкесского, калмыцкого, коми, марийского, осетинского, татарского, тувинского, удмуртского, хакасского, чеченского, чувашского и якутского языков.

А также 26 новых кириллических символов. Меньше барьеров, больше родного языка в интернете.

firstvds.ru/services/domain_names

Список символов, допустимых в составе доменного имени в домене.РФ

U+002D HYPHEN-MINUS -
U+0030 DIGIT ZERO 0
U+0031 DIGIT ONE 1
U+0032 DIGIT TWO 2
U+0033 DIGIT THREE 3
U+0034 DIGIT FOUR 4
U+0035 DIGIT FIVE 5
U+0036 DIGIT SIX 6
U+0037 DIGIT SEVEN 7
U+0038 DIGIT EIGHT 8
U+0039 DIGIT NINE 9
U+0430 CYRILLIC SMALL LETTER A а
U+0431 CYRILLIC SMALL LETTER BE б
U+0432 CYRILLIC SMALL LETTER VE в
U+0433 CYRILLIC SMALL LETTER GHE г
U+0434 CYRILLIC SMALL LETTER DE д
U+0435 CYRILLIC SMALL LETTER IE е
U+0451 CYRILLIC SMALL LETTER IO ё
U+0436 CYRILLIC SMALL LETTER ZHE ж
U+0437 CYRILLIC SMALL LETTER ZE з
U+0438 CYRILLIC SMALL LETTER I и
U+0439 CYRILLIC SMALL LETTER SHORT I й
U+043A CYRILLIC SMALL LETTER KA к
U+043B CYRILLIC SMALL LETTER EL л
U+043C CYRILLIC SMALL LETTER EM м
U+043D CYRILLIC SMALL LETTER EN н
U+043E CYRILLIC SMALL LETTER O о
U+043F CYRILLIC SMALL LETTER PE п
U+0440 CYRILLIC SMALL LETTER ER р
U+0441 CYRILLIC SMALL LETTER ES с
U+0442 CYRILLIC SMALL LETTER TE т
U+0443 CYRILLIC SMALL LETTER U у
U+0444 CYRILLIC SMALL LETTER EF ф
U+0445 CYRILLIC SMALL LETTER HA х
U+0446 CYRILLIC SMALL LETTER TSE ц
U+0447 CYRILLIC SMALL LETTER CHE ч
U+0448 CYRILLIC SMALL LETTER SHA ш
U+0449 CYRILLIC SMALL LETTER SHCHA щ
U+044A CYRILLIC SMALL LETTER HARD SIGN ъ
U+044B CYRILLIC SMALL LETTER YERU ы
U+044C CYRILLIC SMALL LETTER SOFT SIGN ь
U+044D CYRILLIC SMALL LETTER E э
U+044E CYRILLIC SMALL LETTER YU ю
U+044F CYRILLIC SMALL LETTER YA я
U+0456 OLD CYRILLIC I і
U+0458 CYRILLIC SMALL LETTER YE ј
U+0493 CYRILLIC SMALL LETTER GHE WITH STROKE ғ
U+0495 CYRILLIC SMALL LETTER GHE WITH MIDDLE HOOK ҕ
U+0497 CYRILLIC SMALL LETTER ZHE WITH DESCENDER җ
U+0499 CYRILLIC SMALL LETTER ZE WITH DESCENDER ҙ
U+04A1 CYRILLIC SMALL LETTER BASHKIR KA ҡ
U+04A3 CYRILLIC SMALL LETTER EN WITH DESCENDER ң
U+04A5 CYRILLIC SMALL LIGATURE EN GHE ҥ
U+04AB CYRILLIC SMALL LETTER ES WITH DESCENDER ҫ
U+04AF CYRILLIC SMALL LETTER STRAIGHT U ү
U+04BB CYRILLIC SMALL LETTER SHA һ
U+04CF CYRILLIC SMALL LETTER PALOCHKA ӏ
U+04D1 CYRILLIC SMALL LETTER A WITH BREVE ӑ
U+04D5 CYRILLIC SMALL LIGATURE A IE ӕ
U+04D7 CYRILLIC SMALL LETTER IE WITH BREVE ӗ
U+04D9 CYRILLIC SMALL LETTER SCHWA ә
U+04DD CYRILLIC SMALL LETTER ZHE WITH DIAERESIS ӝ
U+04DF CYRILLIC SMALL LETTER ZE WITH DIAERESIS ӟ
U+04E5 CYRILLIC SMALL LETTER I WITH DIAERESIS ӥ
U+04E7 CYRILLIC SMALL LETTER O WITH DIAERESIS ӧ
U+04E9 CYRILLIC SMALL LETTER BARRED O ө
U+04F1 CYRILLIC SMALL LETTER U WITH DIAERESIS ӱ
U+04F3 CYRILLIC SMALL LETTER U WITH DOUBLE ACUTE ӳ
U+04F5 CYRILLIC SMALL LETTER CHE WITH DIAERESIS ӵ
U+04F9 CYRILLIC SMALL LETTER YERU WITH DIAERESIS ӹ

Расширяем линейку GPU Passthrough: добавили тариф с NVIDIA RTX 5090.

Теперь помимо существующих конфигураций доступен VDS с флагманской настольной видеокартой нового поколения.
Подходит для:

• высокоскоростного инференса LLM,
• быстрой генерации видео,
• сложных ML-зач.

Поддержка FP4 помогает эффективнее работать с современными AI-нагрузками. Стоимость от 1750 рублей в сутки.
firstvds.ru/products/vps-vds-gpu

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

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


Статьи и инструкции
Регистрация доменов через Госуслуги с 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

Меня зовут Рене, я сетевой инженер в 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