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

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

Эта штука — бэк почти всех российских публичных облаков.

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

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

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

Пока мы ковырялись с развёртыванием собственного облака, выявили ещё некоторые нюансы ИБ.

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

• Легаси-архитектура — по большей части распределённый монолит, причём некоторые абстракции вроде взаимодействия с сетью или хранением занесены прямо в ядро.
• 49 команд разработки.
• 18 миллионов строк кода.
• Некоторая беда с документацией.
• Баги на стыках модулей могут не править годами либо править силами соседних команд.
• Некоторые модули перестали обновляться, но всё ещё есть в зависимостях, что рождает точки уязвимостей.

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

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

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

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

Оказалось вот что: чтобы администрировать пользователя, чтобы самому добавить в домен пользователя и добавить свои ресурсы, создать сети, загрузить образы — для всего этого нужны права админа. А как только мы даём кому-то в домене права админа, он может ходить в соседний домен! Позже нашёлся и соответствующий баг. С похожими проблемами сталкивались и коллеги из Mail.ru.

При том что в документации написано обратное:

Так быть не должно, но так работает. Это абсолютно недокументированное поведение безопасности. Что ни делай с перевыпуском токенов, как это всё не пытайся заизолировать — ничего не выйдет. OpenStack просто игнорирует scope, заданный при выпуске токена. В итоге мы переписали эту часть логики и усложнили middleware, которое вызывает API OpenStack.
Проблема известная. Используя эту уязвимость с правами доступа, в принципе, можно получить ресурс других пользователей. У одного публичного провайдера из-за ошибки с очисткой томов злоумышленник получил том предыдущего арендатора с его конфиденциальными данными. Осознанно, то есть злонамеренно.
Потом мы узнали, что у ещё одного провайдера загрузили майнингом вычислительный пул после взлома. Ещё пара закрытых историй, которые не выносятся публично.
Короче, вот наш небольшой обзор того, с чем вам придётся столкнуться. Лучше прочитайте это до того, как делать что-то на OpenStack.
Дисклеймер: информация приведена в образовательных целях. Рекомендации по устранению уязвимостей или защите от них следует искать в официальной документации и сообществах безопасности.

Примеры ключевых уязвимостей
Keystone (CVE-2015-7713, CVE-2017-2673 и другие)
В Keystone — модуле аутентификации — регулярно обнаруживались проблемы с неправильной проверкой прав доступа и утечкой метаданных. Например, CVE-2015-7713 позволяла злоумышленнику определять существующие имена пользователей (user enumeration), а некоторые уязвимости в дальнейшем давали возможность провести брутфорс или повысить права в системе.
Пример: при сценарии user enumeration злоумышленник отправляет множество запросов к Keystone API, проверяя, какие логины уже существуют. В случае слабого контроля на уровне API (ограничение по числу запросов, капчи и т.п.) атакующий мог выявить валидные учётные записи. Дальше, пользуясь уязвимыми правилами аутентификации, можно было провести атаку методом подбора пароля.
В некоторых случаях публичные облачные провайдеры, построенные на OpenStack, имели не до конца корректно настроенный Keystone, и злоумышленникам удавалось автоматически перебрать пароли, получив доступ к ряду виртуальных ресурсов.
Последствия — неавторизованный доступ к ресурсам и развитие атаки на другие сервисы с помощью похищенных учётных данных.

Nova (CVE-2016-2140, CVE-2019-14433, CVE-2020-17376)
Nova, как система для управления виртуальными машинами, исторически страдала от уязвимостей, связанных с некорректной фильтрацией пользовательского ввода при работе с API, а также с ошибками конфигурации при миграции инстансов. Мэтью Бут из Red Hat сообщил об уязвимости в изменении размера/миграции экземпляра Nova. Перезаписав эфемерный или корневой диск вредоносным образом перед запросом изменения размера, аутентифицированный пользователь может прочитать произвольные файлы с вычислительного хоста.
У одного из публичных провайдеров была обнаружена конфигурационная ошибка в Nova: злоумышленник смог отправить специально сформированный запрос к API, что позволило ему получить метаданные других инстансов (такие как IP-адрес и ключи SSH). После этого, используя украденные SSH-ключи, атакующий получил удалённый доступ к виртуальной машине другого арендатора, что фактически нарушило модель многопользовательской изоляции.
Стандартные последствия — компрометация чужих инстансов, хищение данных, возможный сценарий эскалации привилегий в облачной инфраструктуре.

Neutron (CVE-2019-10876, CVE-2021-20267, CVE-2024-53916 и уязвимости сетевых плагинов)
Neutron — сетевой компонент OpenStack, часто становится целью атак из-за сложного взаимодействия сетевых плагинов (Open vSwitch, Linux Bridge, SDN-решения и т.д.). CVE-2019-10876 раскрывала проблему, при которой атакующий мог воспользоваться неправильной валидацией правил безопасности (Security Group Rules) в Neutron для обхода межсетевых фильтров.
Злоумышленник в одном публичном облаке обнаружил, что при настройке двух подсетей на пересекающиеся диапазоны группы безопасности перестают применяться к портам в этом диапазоне. В ряде случаев это позволяло обойти внутренние Access Control List и получить доступ к сервисам, считавшимся доступными только из локальной сети. Это приводило к возможности сканирования внутренних сервисов провайдера, а при наличии других уязвимостей — к дальнейшему проникновению в систему управления облаком.
Другая уязвимость открывает возможность подмены IP-адреса (IP Spoofing) и пересылку трафика в частные сети других арендаторов. Уязвимости существуют как для OVS, так и для Linux Bridge.
Последствия: выход за рамки виртуальной сети, утечки внутренних данных, возможность DDoS-атаки, сканирования или похищения чувствительной информации у соседних инстансов.

Cinder (CVE-2017-15139, CVE-2023-2088 — неправильная очистка томов)
В Cinder (сервис облачного хранилища) время от времени возникают уязвимости, связанные с неправильной очисткой или повторным использованием томов.
CVE-2017-15139 указывала, что при определённых сценариях удаления тома не все данные стирались корректно.
Злоумышленник, получивший новый блочный том (Volume) от провайдера, обнаруживает, что этот том ранее принадлежал другому клиенту. Оказалось, что данные не были очищены должным образом, и часть файлов всё ещё могла быть прочитана. Это позволяло достать конфиденциальную информацию прежнего арендатора (например, логи приложений, бэкапы баз данных).
Типичные последствия — утечка критичных данных, нарушение политики конфиденциальности и возможная финансовая/репутационная угроза для провайдера.
Хотя первые симптомы наблюдались ещё в 2015-м, наличие бага CVE-2023-2088, затрагивающего свежие версии, говорит об актуальности проблемы.

SWIFT (CVE-2022-47950 — доступ к данным чужого хранилища)
У OpenStack поддерживаются две версии API объектного хранилища: S3 и SWIFT API. Проблема касается обеих версий. Себастьен Мериот из OVH сообщил об уязвимости в XML-парсере S3 для SWIFT.
Предоставляя специально созданные XML-файлы, аутентифицированный пользователь может заставить S3 API вернуть произвольное содержимое файла с хост-сервера, что приведёт к несанкционированному доступу на чтение потенциально конфиденциальных данных. Это влияет как на развёртывания S3 API (Rocky или более поздние версии), так и на развёртывания SWIFT (Queens и более ранние версии, которые больше не разрабатываются). Это влияет только на развёртывания с включённой совместимостью с S3. Но ведь все стремятся предоставить клиентам такой функционал!
Уязвимость имела место даже в относительно свежем релизе Anthelope, который до сих пор активно применяется в продакшне.

Топ-5 инцидентов
Взлом инфраструктуры европейских HPC-центров (2020 г.)
В ряде публикаций указывалось, что часть узлов в инфраструктуре была развёрнута на базе OpenStack (хотя HPC-решения — это не всегда «чистый» OpenStack, но интегрированы с ним). Злоумышленники использовали уязвимости и неправильно настроенные конфигурации для установки майнеров криптовалют.
Начали с фишинговых писем, дальше двигались внутри кластера. Результат — остановка ряда HPC-кластеров, утечка внутренней документации, потери времени и ресурсов на восстановление. Описание инцидента: HPCwire: Hacking Streak Forces European Supercomputers Offline in Midst of COVID-19 Research Effort (18 мая 2020) и BBC: Europe's supercomputers hijacked by attackers for crypto mining (май 2020).

Атака на публичные сервисы OVH (2013 г., продолжение уязвимостей в последующие годы)
OVH — крупный европейский хостинг-провайдер, использующий OpenStack для OVH Public Cloud, а также крупнейший контрибьютор OpenStack. В 2013 году сообщалось о крупной серии атак методом брутфорса и угона учётных записей. Хотя точный масштаб и детали не всегда раскрывались, часть утечек связана с неправильной настройкой облачных сервисов OVH на базе OpenStack.
Началось в июне 2013 года, позднее — отдельные инциденты в 2015–2016-м. Суть атаки: массовый перебор логинов и паролей с использованием взломанных баз данных (credential stuffing). Последствия: компрометация виртуальных машин клиентов, финансовые и репутационные потери, необходимость срочных мер по усилению аутентификации (2FA). Детали — YCombinator News: OVH has been compromised.

Компрометация тестовой OpenStack-песочницы TryStack (2012–2014 гг.)
TryStack — это (или была) открытая публичная «песочница» для демонстрации возможностей
OpenStack, поддерживаемая рядом участников сообщества, включая Rackspace. Периодически становилась мишенью взломов, поскольку любые желающие могли зарегистрироваться и разворачивать виртуальные машины. В 2013–2014 годах в блогах и на форумах OpenStack часто упоминали про «захват» ресурсов TryStack злоумышленниками для майнинга криптовалют и спама.
Массовые случаи зафиксированы в 2013–2014 годах. Суть атаки: регистрация фейковых аккаунтов и использование уязвимостей в конфигурации Nova/Neutron для скрытного развёртывания ботов. Последствия: повышенная нагрузка на ресурсы TryStack, блокировка части подсистем, необходимость жёстких лимитов и усиленной модерации аккаунтов.

Утечка данных у одного из азиатских OpenStack-провайдеров (2017 г.)
Название провайдера публично не афишировалось (инцидент рассматривался в виде кейса на одной из закрытых сессий безопасности OpenStack Summit). Утверждалось, что причиной стала неправильно настроенная часть API (Nova или Glance), в результате чего злоумышленник получил метаданные образов нескольких клиентов, включая SSH-ключи и конфигурацию VM. Вероятно, атака была в начале 2017 года. Суть атаки: использование неаутентифицированного вызова к сервисам OpenStack; плохой контроль доступа к API. Последствия: компрометация нескольких десятков виртуальных машин, утечка ключей и образов, временная приостановка сервиса для ряда клиентов. Упоминания на закрытых секциях OpenStack Summit (2017 г.). В открытом доступе конкретный провайдер не назван, но рассуждения о проблеме: YouTube-канал OpenInfra Foundation (сессии о безопасности), отдельные обсуждения в OpenStack Discuss (поиск: metadata leak 2017).

«Наследованный» баг Cinder и последующая компрометация данных (2020 г.)
В одном из публичных облаков (упоминалось на форумах, что провайдер базируется в Северной Америке) обнаружился классический сценарий, связанный с неправильной очисткой томов (Cinder). Злоумышленник, получив «освобождённый» том, восстановил оттуда фрагменты данных предыдущего арендатора и нашёл конфиденциальную информацию. После этого инцидента провайдер провёл срочное обновление и внедрил политику гарантированной очистки (secure wipe) дисков. Дату атаки определить затруднительно, но раскрытие данных произошло летом 2020. Суть атаки: эксплуатировали баг (аналогичный CVE-2017-15139) и низкий уровень безопасности при повторном выделении томов. Последствия: украденные базы данных одного из арендаторов, репутационный удар для провайдера, потенциальные судебные иски. Источники Launchpad (Cinder bugs) — упоминание похожих случаев, общие обсуждения проблемы в OpenStack Security Advisory (OSSA) и на профильных конференциях (OpenInfra Summit 2021).

Ещё десятки случаев не стали публичными
Многие серьёзные взломы или утечки в OpenStack-провайдерах замалчиваются из-за репутационных и юридических рисков. Поэтому конкретных «громких историй» на уровне, скажем, взломов AWS или Azure, в открытых источниках значительно меньше.

Как видите, ЭТО ПОЛНОСТЬЮ БЕЗОПАСНО
Посмотрите багтрекеры компонентов, CVE Details (сайт для поиска уязвимостей по проекту), OpenStack Security Advisory (OSSA), архив рассылки Security, OpenStack Discuss (Security) — там классно искать по ключевым словам security issue, vulnerability и т.д., и ещё есть доклады на OpenInfra Summit — там видеозаписи и сессии, в которых рассматриваются реальные кейсы взломов и выявления уязвимостей.

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

Никогда не разворачивайте OpenStack «из коробки» в чистом виде в публичной среде! Есть проверенные best practices (например, из OpenStack Security Guide).

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

Что мы со всем этим делали? Ну, замещали компонент за компонентом, а потом поняли, что лучше вложиться в разработку своей платформы. Успешно прошли стадию Proof-of-Concept и усердно пилим MVP. Скоро покажем.

h3llo.cloud
auth.h3llo.cloud/register

Это один из тех адских опенсорсных проектов, которые отлично начинались в 2010-м, но потом с сообществом что-то пошло конкретно не так. Можно сказать, что перед нами — опенсорс, болеющий всеми корпоративными проблемами.

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

Но при этом, если вы строите публичное облако в России, варианты выбора у вас очень богатые: либо на OpenStack с собственной разработкой, либо на OpenStack, но коммерческом.

Просто чтобы вы понимали уровень ситуации:

• Архитектура — заявленная как микросервисная, по факту — распределённый монолит, причём взаимодействие с компонентами вроде файловых хранилищ разного типа не вынесено в отдельные модули, а затянуто в ядро.
• 49 команд разработки, которые делят сервисы по зоне ответственности, а не архитектурной задаче. Десятки комитетов, которые добавляют бюрократии.
• Документация не соответствует реальности.
• Иногда баг в одном модуле исправляется специальной утилитой, убирающей его последствия от другой команды разработки, а не апдейтом исходного модуля.
• Код неоптимальный, сервисы работают медленно, есть бутылочные горлышки.
• Обновляться очень тяжело.
• ИБ часто делается по остаточному принципу.

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

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

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

В альтернативах в опенсорсе есть проекты CloudStack и OpenNebula. Они несколько проще, чем OpenStack, и функционал у них поменьше. Нам для решения задач коммерческого облака они не подходят.

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

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

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

Мы остановились тогда на версии 23.1.

Дальше нужен виртуализатор. У нас это KVM. Слышали про опыт Xen, но тот же Рег.ру ушёл с Xen не просто так. Собрали отзывы и решили, что всё же KVM. Плюс сверху — собственная контрольная панель: это уже наша разработка.

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

Первое, с чем мы столкнулись, — это проблема с инсталляцией. То есть, когда ставишь это не ручками, а автоматизированно на N хостов (у нас на старте было около сотни), начинаются танцы с бубном. Базовый набор таков: есть Ansible Playbooks. Это единственный официальный вариант, как развернуть OpenStack. Все системы — в докер-контейнерах, и, чтобы их развернуть, надо запустить плейбуки. Они поставят контейнеры, а дальше начнут конфигурировать сервисы, чтобы они были связаны друг с другом. То есть это не просто накатывание 100 образов, а 100 полноценных инсталляций со сложными взаимосвязями. Сервис состоит из множества компонентов, и их нужно подружить друг с другом. Подружить один раз и скопировать результат дружбы как образ, повторюсь, не выйдет. Нужно сделать 100 одинаково подготовленных хостов. Нужно с какой-то машины иметь к ним SSH-доступ. Дальше тысячи строчек конфига нужно подстроить под себя. И нельзя сказать, что все параметры там нормально документированы: некоторые не документированы совсем или документация не обновлялась очень давно.

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

Но! Даже если вы прошли этот квест, то знайте, что не все сервисы ставятся через этот инсталлятор. Мы хотели использовать контейнерный оркестратор Zun. Там классная задумка, что контейнер является First-Class Citizen, как и ВМ. Проблема заключается в том, что он не ставится. Даже в чистовой инсталляции вместо того, чтобы развернуть нужную схему в БД, он зачем-то идёт через миграции. В какой-то момент эти миграции ломаются, потому что поменялась версия внутреннего компонента, и некоторые типы полей больше не поддерживаются. Приходится вручную лезть в код и разбираться, что же там такое. И все, кто проходил этот путь, делают именно так. Знает ли об этом сообщество? Знает. Что-то поменялось? Да. Они положили это в беклог.

Дальше такие сюрпризы были примерно каждый день.

Вот наше короткое практическое резюме.

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

Каждая служба (Nova, Neutron, Cinder, Keystone и т. д.) имеет множество зависимостей и конфигурационных опций. Любая ошибка в настройке или конфигурации сразу может привести к общесистемным проблемам.

Пример: Chris Dent, один из активных участников Технического комитета OpenStack, в 2021 году отметил, что «обилие сервисов и интеграционных компонентов приводит к усложнённому процессу сопровождения, особенно — в крупных развёртываниях». И дальше запустил опрос, который показал, что разработчики не хотят участвовать в некоторых ветках из-за качества кода, скорость развития проекта пугающе медленная, в целом очень много работы, очень странная унаследованная архитектура и много легаси-кода.

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

Само по себе развёртывание OpenStack требует глубоких знаний Linux, виртуализации, сетевых технологий, а также специфики каждого из сервисов. Когда дойдёте до сетевых драйверов, вы, вероятно, поседеете.

Его почти невозможно обновить
Процесс обновления сопоставим с тем, как вы мигрировали бы с 1С, скажем, 7 на современную версию. А это, знаете ли, некий показатель.

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

Примеры проблем при миграциях — тут, тут, тут, и ещё вот тут и тут. Достаточно загуглить «Upgrade issues from Antelope to Bobcat» or «Openstack Problems after Caracal upgrade».

На практике очень болезненны бывают патчи по 0-day ИБ-проблемам. Часто компании вынуждены на долгое время «застревать» на более старых релизах, чтобы не рисковать стабильностью.

Он медленный. Нет, МЕДЛЕННЫЙ
После 100 хостов начинают возникать узкие места, которые не масштабируются. В частности, это основные компоненты Nova-scheduler, Neutron и Placement.

Наш пример: в Placement они даже не могут сделать нормальный веб-сервис, который будет отвечать на запросы быстрее чем за три секунды. Три секунды, Карл! Да, теперь они вытащили микросервис наружу из монолита, и он отвечает за полторы секунды. Но под нагрузкой он снова отвечает за три, а то и за пять секунд. Забиваем это всего лишь десятью тысячами записей — пять секунд!

Мы тут тестировали нагрузку созданных Scala-сервисов, которые сами пишем. У них ходит 200 миллионов сообщений в секунду, API отвечает на миллион запросов с одной машинки, с ноута безо всяких задержек без увеличения времени ответа. Под капотом у неё — база данных Кассандра, и 100 миллионов записей для неё — это какая-то мелочь.

Но вернёмся к Опенстеку. Вот статья Fix Your Debt: Placement Performance Summary с тестами производительности Placement (зависимости Nova) после переноса в отдельный сервис. Ещё стоит погуглить Nova-scheduler meltdown bug и баги Neutron при создании большого числа сетей или портов.

На практике многие вынуждены применять нетривиальные хаки (например, использовать внешнюю маршрутизацию или кастомные плагины для Neutron) и постоянно тюнить базу данных (RabbitMQ, Galera Cluster и т. д.), что сильно усложняет поддержку.

Некоторые пользователи отмечают дополнительную прослойку абстракции, из-за чего теряется производительность по сравнению с «голой» виртуализацией (KVM, VMware). При большом количестве сервисов зачастую растут задержки при создании/удалении ресурсов и ведении баланса нагрузки.

Крупные инсталляции (100+ физических узлов) требуют выделенных команд администраторов, девопсов и очень хороших внешних мониторингов типа Prometheus, Nagios, Zabbix.

Документация даже просто одного сервиса Nova (нова) — это тысяча+ страниц А4. Инструкция для оператора — ещё тысяча. Если взять материалы по автоматизированной установке, то ещё тысяча. Это только один сервис из семи корневых или десятка потенциально необходимых облачному провайдеру.

Наш пример: Ceph не подключился. Просто последняя версия у нас разворачивается, но не функционирует от слова «совсем» даже при абсолютно чёткой правильной инсталляции. Просто не работают тома. Синдер рубит создание виртуалок. Это проблема исключительно с багами последней версии. Надо лезть ручками и смотреть, что не так с настройками именно вот этой автоматической инсталляции. Ручная инсталляция работает, автоматическая — нет.

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

На OpenStack Forum 2021 в ходе «круглого стола» о болевых точках (сессия «Troubleshooting the Hard Way») многие операторы жаловались на сложность анализа инцидентов из-за нестыковок логов разных сервисов. Видео доклада на YouTube OpenInfra Summit 2021 — «Troubleshooting in OpenStack» больше недоступно, но поиск выдаёт доклады с не менее обнадёживающими названиями:


На практике при проблемах, связанных одновременно с Nova, Neutron и Cinder, часто приходится манипулировать несколькими логами, отдельно просматривать состояние очередей в RabbitMQ, мониторить состояние баз данных и сервисов. Это точно к длительной отладке.

Что гораздо хуже — внутри есть известные баги, которые не правятся буквально годами. Например, Neutron — один из самых критикуемых компонентов из-за многослойной конфигурации сетей (L2-, L3-агенты, SDN, различные плагины). Это часто вызывает проблемы при отладке и обновлении. Известный баг, который ссылается на другой известный баг, — Launchpad #1961740 (известен аж с 22.02.2022).

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

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

Несмотря на большую активность в прошлом, часть разработчиков уходит в другие проекты (Kubernetes, Docker, Public Cloud Solutions). Это ведёт к тому, что некоторые модули OpenStack остаются без должного внимания.

Бюрократия
Внутри проекта OpenStack много подкомитетов (Technical Committee, Board of Directors), а также большое количество разных Special Interest Groups. Бюрократию это создаёт неиллюзорную.

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

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

Нестабильность отдельных проектов и «призрачные» сервисы
В OpenStack исторически появлялось очень много новых проектов (Manila, Mistral, Barbican и др.). Некоторые из них теряли поддержку или переходили на «режим малой активности». Например, Mistral (Workflow as a Service) неоднократно признавался «низкоприоритетным» из-за отсутствия достаточного количества мейнтейнеров. Вот его репозиторий с невысокой активностью коммитов. Вот аналогичный Zaqar (Messaging Service).

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

Некоторые сервисы просто нестабильны. В сообществе встречаются частые жалобы на нестабильную работу Manila (файловые шары), затягивание решения багов в Ironic (bare metal provisioning).

Также умерли:

• Trove (Database as a Service). Trove создавался для управления СУБД (MySQL, PostgreSQL и др.) в стиле «DBaaS» в рамках OpenStack. Многие операторы вообще не используют Trove, предпочитая управлять базами отдельно (через Kubernetes Operators или внешние PaaS-платформы).
• Sahara (Big Data as a Service). Sahara предназначен для разворачивания кластеров Hadoop/Spark через OpenStack. С развитием Kubernetes и появлением разнообразных операторов для Big Data-решений (Spark Operator, Airflow и т. п.) популярность Sahara упала.
• Karbor (Application Data Protection). Он создавался как сервис для бэкапов и восстановления приложений в OpenStack, но полноценной популярности не снискал. Несколько лет назад проект был малоактивным, и на данный момент упоминания о Karbor в комьюнити редки.
• Rally (Benchmark & Testing). Rally задумывался для нагрузочного тестирования и оценки производительности сервисов OpenStack. Хотя он всё ещё используется некоторыми командами CI/CD, его активное развитие снизилось: многие операторы переключились на собственные фреймворки тестирования или используют Performance-тесты в других инструментах.

Костыли
Orphaned Resource Allocation (Nova)

• При неполном или ошибочном удалении виртуальных машин (например, сбой в момент удаления, прерванная операция миграции) в базе данных Nova могут оставаться «осиротевшие» записи о зарезервированных ресурсах (CPU, RAM, диски).
• Следствие: гипервизор якобы «загружен» и отказывается принимать новые инстансы, хотя фактически ни одной рабочей ВМ не запущено.
• Рабочий костыль (workaround): использовать процедуру очистки «orphaned allocations» вручную или скриптами nova-manage placement heal_allocations, а также проверять состояние ВМ (stopped, error и т. д.), чтобы корректно завершать.
• При серьёзных сбоях — удалять «зависшие» записи напрямую из базы данных (что нежелательно в промышленной среде, но иногда это единственный выход).
• Официальная документация Nova Troubleshooting — Orphaned Allocations.

То есть они допустили баг в основном сервисе и выпустили утилиту для сборки «осиротевших» ресурсов, а не исправили баг.

«Зависшие» тома (Stuck Volumes) в Cinder

• Сценарий: том был выделен, но виртуальная машина, которая к нему подключалась, удалена с ошибкой. В результате в Cinder остаются «призрачные» тома в статусах deleting, error_deleting или даже «внешне доступные», но фактически они не прикреплены ни к одной ВМ.
• При повторных запросах на создание/удаление Cinder может сообщать «Не хватает места», «Ресурсы недоступны» и т. д., хотя физически дисковое пространство есть.
• Рабочий костыль: использовать команды cinder reset-state и cinder force-delete, вручную приводя томы в согласованное состояние. В некоторых случаях — чистить записи в базе данных Cinder или на уровне бэкенда (Ceph, LVM и т. п.), если стандартные инструменты не помогают.

«Забытые» порты и сети (Neutron Leftover Ports/Networks)

• При сбоях в процессе удаления инстансов или сетевых ресурсов могут оставаться порты, не привязанные к активным VM. Аналогично могут «зависать» сами сети, если они не были корректно отвязаны.
• Это мешает созданию новых сетевых ресурсов и приводит к путанице в конфигурации (особенно если используется DVR, L3-HA или VLAN trunking).
• Рабочий костыль: проверять через openstack port list (или neutron port-list) все «зависшие» порты, удалять их вручную openstack port delete. Если удаление не срабатывает, то искать в логах ошибки (конфликты с другими службами), а в крайних случаях — править базу данных Neutron или восстанавливать целостность через пересоздание сети.

«Призрачные» образы (Glance Ghost Images)

• Иногда процесс загрузки или удаления образа прерывается ошибкой сети, нехваткой места и т. д. В результате в Glance могут остаться «полусуществующие» записи: метаданные есть, но реального файла нет. Либо наоборот: файл в бэкенде хранится, а метаданные удалены.
• Это приводит к некорректным подсчётам объёма занимаемого места, а при попытке заново загрузить образ с тем же UUID возможно возникновение конфликтов.
• Рабочий костыль: проверка статусов образов (например, deleted, но всё ещё существующий) и при необходимости — ручная очистка метаданных или объектов в бэкенде (Swift, Ceph RBD и т. д.). Регулярное сканирование базы данных Glance и соответствующего хранилища для выявления рассинхронов.

Heat: «зависшие» стеки (Stuck Stacks)

• При сбоях в шаблонах (Templates) или ошибках в ссылках на внешние ресурсы (Nova, Neutron, Cinder) Heat может застревать в состоянии UPDATE_IN_PROGRESS или DELETE_IN_PROGRESS.
• Пользователь не может ни завершить операцию, ни перейти к следующему обновлению: «раскрутить» это бывает нелегко.
• Рабочий костыль: перевод стека в состояние FAILED через специальную команду heat stack update --mark-failed, а затем — повторное удаление. В самых тяжёлых случаях используют скрипты для массовой ручной очистки зависимых ресурсов. Если удаление отдельных ресурсов невозможно, то приходится корректировать записи в базе данных Heat.

Ceilometer/Gnocchi: некорректные метрики (Stale Metrics)
При сбоях в агенте сбора метрик (ceilometer-agent) или при неправильных настройках pipelining возникают «осиротевшие» записи о ресурсах, которые уже не существуют.
Это приводит к некорректным показателям в мониторинге и сбоям при выставлении счетов (биллинг), особенно если реализована auto-scaling через Heat или другой механизм.
Рабочий костыль: чистить «зависшие» записи в базе Gnocchi, скриптово пересоздавать индекс или вручную выгружать «битые» серии метрик. Отслеживать логи и периодически перезагружать сервисы телеметрии, чтобы избежать накопления устаревших данных.

Horizon: «подвисшие» действия в веб-интерфейсе

• В веб-панели иногда случаются ситуации, когда пользователь инициирует операцию (создание VM, присоединение тома), но обновление страницы «застряло», и остаётся неочевидным, сработало действие или нет.
• Повторный клик порождает дублирующиеся запросы, в итоге в бэкенде появляются «лишние» ресурсы, а Horizon может не отобразить их корректно.
• Рабочий костыль: ручной мониторинг через CLI (openstack server list, openstack volume list, openstack network list) в параллель с Horizon, чтобы убедиться в статусе. Если обнаружены дублирующиеся или «зависшие» ресурсы, то удалять их из CLI и/или чистить записи в базах данных.

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

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

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

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

h3llo.cloud
auth.h3llo.cloud/register

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

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

При открытии облака есть 3 больших области, где нужно всё сделать:

1. Открыть юрлицо (как и любому бизнесу) и прикрутить оплату.
2. Запустить ЦОД (у нас несколько площадок, и одна в собственности, потому что там серверы с иммерсионным охлаждением). Там из интересного, например, строительство оптических линий связи.
3. И, собственно, соблюсти требования РКН по включению в реестр хостингов.

Именно третья часть вызвала больше всего приключений.

Что нужно сделать для РКН
Вот новость, вот юридический разбор и последствия неисполнения.

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

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

Дальше надо подключиться к системе ГосСОПКА. Есть вариант под ключ от крупных ИБ-вендоров, есть вариант ковыряться самостоятельно. Готовое решение явно заточено под крупные корпорации и стоит плюс-минус 10 миллионов рублей.

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

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

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

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

Обязательное требование — это взаимодействие с системой ГосСОПКА. Это такая система, в которую все участники сообщают свои кибер-инциденты и с помощью аналитического центра могут получить рекомендации по противодействию атакам. Например, на кого-то начинается DDos-атака. Сообщение об инциденте приводит к тому, что пул потенциально атакующих адресов могут забанить все.

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

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

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

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

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

Потом, сообщив номер этого ГОСТ VPN, выяснили, что он нам не нужен!

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

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

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

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

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

Тогда же встал вопрос по использованию своих площадей.

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

Следующая часть — подключить интернет. Объект, который нам принадлежит, находится всего в 120 километрах от Москвы. А знаете, чего из ИТ-инфраструктуры нет в 120 километрах от Москвы?

НИЧЕГО!

Подключиться на чём-то быстрее, чем 1 Гб/с за бешеные деньги, в принципе, невозможно. Мы дали заявку на 10 Гб/с сейчас. Дважды услышали ответ “нет технической возможности”. Понятно, ни про какие 100 речь не идёт, все выкатывают глаза и ценники.

В середине декабря подали новую заявку на 10Гбит. До сих пор ждём, что провайдер изучит техническую возможность реализации такого канала на этом объекте. Мы, в принципе, готовы стартовать сейчас, начать загружать объект и проапгрейдиться, но всё равно очень странно. Казалось бы, тут ехать не так далеко, как из одной точки Москвы в другую. Утром выезжаешь за МКАД и там окажешься за полтора-два часа, а в Москве можно столько с одного ЦОДа на другой ехать.

Из последнего диалога с провайдером выяснилось, что у них проблема с SFP+ трансиверами. Мы уже предложили им своих отсыпать. С коммутаторами до кучи. Снова тишина и бесконечные согласования…

Но, чтобы нормально развиваться, строим полностью свои каналы.

Стойки в партнёрских ЦОДах
Встали ещё в одно место и столкнулись с тем, что стоек-то вообще нет.

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

Самое интересное, что некоторые машзалы стоят полупустые. Просим в этом же зале дать стойку. Ждём месяц. Говорят: «Ой, а единственная стойка вообще на другом конце машзала». Как так? Уже год рядом с нами нет ни одной стойки. Но нет, продать не могут. Кто-то забронировал для своих, для других, перепродал другим. Запутанные истории, и даже сами менеджеры эти истории распутать не могут. Главное, кто-то платит, стоек нет, но кто-то платит.

Собственно, именно так, наверное, выглядит фьючерс на стойку.

С пониманием этой истории мы пришли к тому, что лучше построить ещё один объект. Сейчас нашли перспективный объект под второй собственный ЦОД. На этот раз мы не влезем в строительство, пока железно не будем знать, что вся инфраструктура (включая связь) подводится за земные деньги.

Железо
Железо стало можно купить. Это только в 2022-м были проблемы, сейчас вам продадут много чего. Но есть особенности. Вот коммутаторы, они продаются без проблем, но они бывают в двух видах поставки: OEM и коммерческой, условно. Вторая отличается тем, что там внутри салазки для монтажа в стойку. Купить салазки можно только с коммутатором, отдельно они не продаются.


Если очень нужно, можно сделать заказ, но цена там — как треть железки.

В итоге мы нашли тех, кто делает кастомные, взяли за разумные деньги. И это лучше, чем ждать оригинальную железку с салазками на 3–4 недели дольше, чем без них.

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

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

Ещё мы должны использовать российские NTP и DNS. По факту это непонятно как проверяется. Указано, что нужно взаимодействовать с разными госорганами в случае мероприятий, учений и так далее.

Про СОРМ, которого все боятся ввиду космических затрат. Внешние каналы связи проходят через провайдерское оборудование, на котором СОРМ повсеместно. Но этого мало, и хостинги теперь тоже должны его внедрять. С другой стороны, он отличается от операторского. Для хостингов он представляет систему с защищенным доступом, предоставляющую GraphQL-endpoint. Требования к нему подробно описаны. Строит его каждый провайдер хостинга сам.
publication.pravo.gov.ru/document/0001202312010108

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

Связь в офисе
Самая интересная история. Мы, хотя и строим хостинг, в своём офисе долго сидели с мобильного интернета с телефона. Это было забавно, потому что протянуть оптическую линию от ЦОДа к себе в офис заняло полгода. Из Москвы. В Москву.

Мы связь сделали на базе ЦОДа Ростелекома, с двумя операторами, с каждым по двум независимым линиям. Мы детально проверяли, чтоб у них не оказалось общей инфраструктуры и не повторился известный фейл одного крупного проекта. Все линии строим так, чтобы условный пьяный тракторист не прибил сразу обе. Соответственно, осталось пробросить оптику в офис и наслаждаться 4K п… быстрыми видеозвонками без лагов от пролетающих мимо базовой станции голубей. 22 км трассы удалось собрать за 2 недели. Но 100 метров трассы проходят через подвал соседнего жилого дома. Получить согласие от ТСЖ и от собственника этого кусочка заняло большую часть времени строительства.

Некоторое удивление
Собственно, мне казалось, что многие вещи решаются тривиально в момент, когда понятно, что одна сторона готова заплатить, вторая продать. Но нет. Многое буксует именно из-за бюрократии. Чья-то бумажка с чьей-то подписью, и без этого нельзя, неделя на просто получение ответа на коммерческое предложение, месяц — дождаться поставки. Не говоря уже о том, что простая история с тем же ГОСТ VPN-устройством.

Уже после оплаты 100%, с подписанным договором со сроками, выходят все сроки. Мы связываемся с менеджером и говорим: «Уважаемый, где там поставка-то?» Ответ: «Я не могу на это ответить, потому что сам производитель не может мне на это ответить». Он уже все сроки тоже продолбал и просто не отвечает. Вот это продолжалось несколько недель, пока в итоге не пришло к нам оборудование. Хотя потом оказалось, что могли бы и просто фото серийника прислать.

После всего этого остались уже сущие мелочи технического характера: включить все аплинки, проверить трассы, настроить балансировку и переключение, сделать нормальную ИБ (по best practice), свести все системы в SOC, развернуть мониторинги. Дальше идёт подключение к платёжным системам. Настройка биллинга. Настройка обработки счетов, платежей. Подключение к Диадоку. Интеграция с кассой. Интеграция с другой кассой, потому что пришёл офер из Т-Банка, где комиссия ниже (хотя бэком используется тот же сервис), убедиться, что арендованные айпишники не в чёрных списках (все в каждом блоке по 4к адресов) — и можно после этого наконец-то заниматься делом.

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

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

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

h3llo.cloud
auth.h3llo.cloud/register

Уважаемые клиенты!

К сожалению, мы вынуждены изменить цены на наши тарифы услуг администрирования серверов.
Стоимость разовых работ повышается до 1800 руб/час (минимальная оплата за пол часа — 900 руб)

Новые тарифы с помесячной оплатой (с 1 марта 2025):

• Базовое: 4 500 руб/мес
• Оптима: 7 500 руб/мес
• Премиум: 14 500 руб/мес

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

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

Что нами уже сделано и что планируется:

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

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

До 1 мая 2025 года у вас есть возможность продлить услуги по старым ценам. Если у вас возникнут вопросы, наша команда готова на них ответить.

С уважением,
Команда Systemintegra

https://systemintegra.ru

Прокачайте свой бизнес с супер скоростью 10 Gbps в Дании! Наши серверы обеспечивают эффективность и надёжность, гарантируя отличные результаты при любых условиях.
PQ.Hosting теперь обеспечивает новую скорость до 10 Gbps для всех проектов в Дании. Мы предлагаем:

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

Обновление до 10 Gbps — это ваш ключ к новым достижениям! Заказывайте виртуальные серверы в Дании и получите скидку 25% по промокоду DK25 до 11.02.2025
pq.hosting/vps-vds-denmark-copenhagen

Отличные новости, друзья! Совсем недавно мы анонсировали новую локацию, объявляли предзаказ и теперь серверы в Люксембурге доступны всем желающим. Вы можете заказать VPS со скоростью 10 Gbps в самом центре Европы!

Дата-центр в Люксембурге — передовой объект, соответствующий строгим международным стандартам. Он сертифицирован по стандартам ISO, что гарантирует высокий уровень качества услуг и защиты данных. Кроме того, дата-центр оснащен современными технологиями, обеспечивающими стабильную работу и высокую производительность серверов. С PQ.Hosting ваши проекты работают без задержек!
pq.hosting/vps-vds-luxembourg

Почему стоит заказать сервер именно в Люксембурге?
Наша новая локация открывает множество преимуществ!

• Идеальное географическое положение. Благодаря ему у пользователей из Западной Европы ваши сайты будут загружаться максимально быстро. Если ваш бизнес ориентирован на эту аудиторию, то сервер в Люксембурге — отличное решение.
• Стабильность и надежность. Люксембург — современное правовое государство с четким регулированием в сфере IT. Вам не нужно беспокоиться о перебоях в работе дата-центра или рисках, связанных с нестабильным законодательством.
• Размещайте серверы в Люксембурге уже сегодня и оцените все преимущества новой локации!

Всего у нас 4:

• 500 млн облигаций по 4,75%
• 450 млн банковских кредитов ≈ 4,5%
• 200 млн «многоцелевого» кредита
• 200 млн кредита ЕИБ

из которых более 300 млн неиспользованы.

Таким образом, мы завершаем проект OPRA, о котором мы объявили в октябре 2024 года, который заключался в выкупе акций OVHcloud на сумму 350 миллионов по 9,00 евро (у всех, кто хотел их продать). Сейчас наш объем акций в свободном обращении составляет 19%, что по текущей цене составляет менее 250 млн.

Молодцы команды! Отличная доставка! Отличная реакция рынка и высокий уровень доверия к нашим цифрам!

Как мы будем возвращать эти кредиты?
При заявленном росте выручки на 9–11% в год наша маржа (EBITDA) также увеличится. В 2023 финансовом году наш показатель EBITDA составил 36,3%, в 2024 финансовом году — 38,4%, а в первом квартале 2025 финансового года мы уже превысили 40%.

Продолжая работать в этом направлении, через несколько лет коэффициент Долг/EBITDA снова снизится, а мы только что прошли с 1,8 до 3,1. В «крестьянском» режиме это означает, что в худший момент цикла, теоретически, мы могли бы погасить весь долг за 3,1 года.

Короче говоря, с финансовой стороны мы знаем эту механику уже 25 лет, и мы снова применяем ту же схему, колеблясь по показателю «Долг/EBITDA» между «Вверх», «Вниз», «Вверх» и «Вниз».

Все это благодаря клиентам, которые доверяют нам, заказывают у нас услуги, продлевают их или берут еще больше! СПАСИБО! И мы разрабатываем новые продукты :)

Ищете надёжный виртуальный сервер с высокой производительностью и стабильной работой? Попробуйте VDS от Hosting-VDS.com!

• Конфигурации на процессорах AMD EPYC 74F3: Максимальная производительность для ресурсоёмких проектов.
• Стандартные конфигурации: Оптимальное соотношение цены и качества на базе современных процессоров Intel Xeon Gold 1 и 2 поколения.
• Гибкие тарифы: От 2.39$ за 2GB RAM — подберите идеальный вариант для любого бюджета.
• Высокая надёжность: Серверы размещены в дата-центре Selectel в Москве. В «комплекте» бесплатная защита от DDoS атак компании Selectel.
• Трафик и передача данных: Сервера подключены по портам 10Гбит/с. Для всех тарифов отсутствует ограничение скорости, но имеется ограничение по потребляемому трафику.
• На каждый сервер выдаётся 1 x IPv4 адрес и подсеть IPv6 /64 которая полностью смаршрутизирована на ваш VDS.

Способы оплаты:

• Банковские карты РФ
• ЮMoney кошелёк
• СБП
• TPay
• Webmoney (WMZ)
• Криптовалюты, включая USDT и множество других способов.

Мы предлагаем:
1. Надежность и стабильность.

• Наши серверы оборудованы современными SSD NVMe-накопителями Datacenter Edition Intel DC P4610 и D7-P5600, что обеспечивает высокий IOPS и стабильную работу ваших ресурсов даже при высоких нагрузках без каких-либо «просадок».
• Серверные платформы, серверные процессоры и серверная DDR4 память. Никаких «десктопных» решений и серверов «на коленке». Используем процессоры серии AMD Epyc и Intel Xeon Gold (подробнее будет ниже).
• Всё оборудование и IP адреса, являются нашей собственностью и не находятся в аренде.

2. Гибкие тарифные планы.

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

3. Полная свобода настройки.

• Вы получаете полный root доступ, что позволяет самостоятельно настраивать сервер под особенности вашего проекта.
• Вы получаете возможность установки любой ОС через загрузку с собственного ISO образа, так что это может быть даже MikrotikOS (CHR) или другая ОС.
• ОС доступные для быстрой установки Debian 12/11/10, Ubuntu 24.04/22.04/20.04/18.04, AlmaLinux 8.4-9.4, CentOS 7/8/9, Fedora, OpenSUSE, ArchLinux, Windows Server 2022/2019 и даже BitrixVM

4. Бесплатные возможности и бонусы ко всем услугам.

• Еженедельные резервные копии всех серверов.
• Бесплатная защита от DDoS атак предоставляемая Дата-Центром Selectel.
• API к панеле управления серверами (SolusVM).
• VNC доступ ко всем серверам.
• Готовые шаблоны приложений — Pterodactyl, Marzban, FastPanel, OpenVPN и прочие не сильно известные и востребованные приложения.

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

Стандартные тарифы:

• Цена: от 2.39$ (~236 руб) в месяц
• Процессоры: Intel Xeon Gold 6138/6150/6230 — 2.0-3.7GHz — честная рабочая частота в диапазоне 2.7GHz
• DDR4 память (2666 MT/s) от 2ГБ
• Каналы и трафик: 10Гбит/c без всяких Fair Use, ограничение лишь по объёму трафика в каждом тарифном плане, после использования которого включается ограничение скорости 10Мбит/c до следующего сброса (в календарный день покупки сервера)

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

Hi-Memory тарифы:

• Цена: от 3.59$ (~354 руб) в месяц
• Процессоры: Intel Xeon Gold 6138/6150/6230 — 2.0-3.7GHz — честная рабочая частота в диапазоне 2.7GHz
• DDR4 память (2666 MT/s) от 4ГБ
• Каналы и трафик: 10Гбит/c без всяких Fair Use, ограничение лишь по объёму трафика в каждом тарифном плане, после использования которого включается ограничение скорости 10Мбит/c до следующего сброса (в календарный день покупки сервера)

Тарифы не подходят под игровые сервера с высокими CPU требованиями и высоконагруженные CPU задачи.
Предназначены для RAM требовательных проектов, как MySQL базы, Java приложения, кеширование и обработка данных.

Hi-CPU тарифы:

• Цена: от 4$ (~395 руб) в месяц
• Процессоры: AMD EPYC 74F3 — 3.2-4.0GHz — честная рабочая частота минимум 3.6GHz — GeekBench 6 сопоставим на уровне AMD Ryzen 9 3900
• DDR4 память (2666 MT/s) от 2ГБ
• Каналы и трафик: 10Гбит/c без всяких Fair Use, ограничение лишь по объёму трафика в каждом тарифном плане, после использования которого включается ограничение скорости 10Мбит/c до следующего сброса (в календарный день покупки сервера)

Тарифы подходят под игровые сервера, в частности не решают все потребности пользователей, но подходят под большинство задач и игровых серверов со средним онлайном.
Отлично справляется с Bitrix и 1C нагрузками не испытывая проблем. Предназначены для ведение бухгалтерии на высоконагруженных 1C, под удаленный рабочий стол с несколькими сотрудниками, игровые сервера Source Engine, CS 1.6, Minecraft и прочее.

Юридические и формальные моменты:

• Условия предоставления услуг
• Согласие на обработку персональных данных
• Политика конфиденциальности
• ООО «ЦИФРОВЫЕ РЕШЕНИЯ» — ИНН 7733449199
• Мы состоим в реестр РКН как хостинг-провайдер

hosting-vds.com

Дата-центр в этой небольшой стране стал бы нашей 44-й локацией, но из-за местных законов все пошло не по плану.



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

Однако сегодня история совсем другая. Без хэппи-энда, зато с интересными нюансами и одной любопытной особенностью в IT-законодательстве Андорры.

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


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

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

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

Мы сначала подумали, что это какие-то трудности перевода или просто недопонимание. Ответили, что, конечно, в GEO-данных RIPE (организации, распределяющей IP-адреса в Европе) будет указана Андорра. Казалось бы, вопрос закрыт.

Но нам снова ответили: нет, по закону IP-адреса должны принадлежать единственному провайдеру в стране. Единственному! То есть, не просто должны числиться за Андоррой, а быть выданы конкретной телеком-компанией. Вот как мы прочувствовали все «прелести» монополии на собственной коже.

Тут мы поняли, что дело серьезное.

Почему это нас не устроило?
У нас в PQ.Hosting есть очень четкая политика: все критически важные инфраструктурные элементы должны быть под нашим контролем. Так, железо во всех ДЦ у нас везде свое, IP-адреса мы у местных провайдеров не арендуем.

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

Ну и еще один «приятный» бонус: у андоррского провайдера даже нет IPv6. В 2025 году. Это уже само по себе говорит о многом.

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

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

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

Какую локацию нам стоит выбрать следующей вместо Андорры? Напишите свой вариант в комментариях! Может лучше пойти куда-нибудь на север? Кстати, в Дании у нас уже есть локация, и до 11 февраля на виртуальные серверы с 10 Gbps в этом ДЦ действует скидка 25% по промокоду DK25.

https://pq.hosting

Мы рады сообщить, что расширяем нашу инфраструктуру!

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

Благодаря новому местоположению мы теперь можем гарантировать:

• Более быстрое подключение для клиентов в Центральной и Восточной Европе
• Повышенную надежность и безопасность
• Защиту от DDoS-атак на скорости 10 Гбит/с
• Настраиваемые конфигурации серверов

Вы можете просмотреть все новые серверные планы на нашей странице
abelohost.com/offshore-dedicated-server/

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

С наилучшими пожеланиями,
AbeloHost