H3LLO CLOUD

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

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

Облака в тесте:

• Selectel.
• Cloud.ru.
• Timeweb.
• VK.
• Yandex.
• Rostelecom.
• H3LLO.CLOUD.

Коротко о результатах


Radar chart по трём показателям: производительность, стоимость к производительности и задержка инвертированная. Больше площадь — лучше

• Timeweb показал одну из самых низких производительностей, но при этом снова хорошую цену за единицу вычислений.
• VK Cloud и Яндекс оказались аутсайдерами: и производительность не впечатляет, и стоит дорого. У Яндекса есть ограничитель на максимальную производительность.
• Потом вы просили добавить нас в тесты, чтобы потом можно было предъявить, если что, и мы добавили. Нам надо было установить цену для своих тарифов, мы взяли её как медианное значение между Cloud.ru и Selectel.

Нельзя просто взять и протестировать
Мы не ожидали, что это обернётся почти масштабным научным исследованием, а не простым «запустил и померил». Делов-то было на 20 минут, как казалось вначале. Ну, поставим бенчмарк, запустим скрипт, получим циферки, забабахаем красивые графики. А в итоге погружаешься в какую-то научную диссертацию, где каждое число может быть оспорено, а каждое методологическое решение требует обоснования.

Потому что вы нас немного заклевали за подход «херак-херак и в продакшен» на первом тесте. Хотя он вполне решал свою задачу — оценить производительность связки vCPU-RAM на машинах с одинаковыми характеристиками у разных провайдеров. Или, проще говоря, выяснить, кто же больше охренел )

В общем, методология. Сразу решили не изобретать велосипед и взяли встроенный в PostgreSQL тест pgbench. Он создаёт три таблицы разного размера, которые отличаются друг от друга в 10 и в 100 000 раз по числу записей. Выбрали фактор масштабирования 200, и это дало нам таблицы размером 200, 2000 и 20 миллиона записей. Достаточно, по нашему мнению, чтобы проверить, как облака справляются с нагрузкой.

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

• База данных Postgres 16.
• 4vCPU + 16 Гб RAM + 40 Гб SSD (где был выбор между дефолтным флейвором БД и настраиваемым сайзингом, мы выбирали дефолтный флейвор).
• Где был выбор между Ice Lake vs Cascade Lake мы выбирали Ice Lake.
• Без пулинга, репликации и бекапов.
• Без тонкой настройки дополнительных параметров конфигурации Postgres.
• Для бенчмаркинга выбрали стандартный pgbench, который входит в состав Postgres.
• Для минимизации времени отклика pgbench запускался из виртуальных машин находящихся в той же приватной подсети, что и Managed Postgres, без SSL.
• Проводили 4 итерации: 1 разогревочная + 3 фактических.
• Бенчмаркинг проводился в рабочее время.

4 стандартизированных нагрузки pgbench:

• default, «Стандартная нагрузка TPC-B»
• simple_update, скрипт обновляет баланс в таблице `pgbench_accounts`
• select_only, скрипт выполняет выборку данных из таблиц `pgbench_accounts`, `pgbench_branches` и `pgbench_tellers`
• complex_write, скрипт обновляет балансы в таблицах `pgbench_accounts`, `pgbench_tellers` и `pgbench_branches`, моделируя сложную транзакцию

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

• join_heavy: скрипт выполняет соединение таблицы `pgbench_accounts` самой с собой несколько раз, что позволяет оценить производительность при выполнении joins
• insert_with_indexes: скрипт вставляет новую запись в таблицу `pgbench_history` и обновляет баланс в таблице `pgbench_accounts`, что позволяет оценить производительность при выполнении операций вставки и обновления с использованием индексов

Измеряли 2 метрики:

• Количество транзакций в секунду (TPS): Сколько операций база данных может выполнить за одну секунду.
• Время отклика запросов: Сколько времени требуется базе данных для выполнения запроса.

Коэффициент стоимости считался в руб/час/TPS.

Параметры бенчмаркинга:

• scale factor = 200 (это значит что в базе будут 3 таблицы, по 20 млн записей, 2 тыс. записей и 200 записей соответственно).
• Одновременные клиенты базы данных client_counts = [16, 32, 64].
• Рабочие потоки thread_counts = [32, 64, 128].
• run_time одной итерации = 30 секунд.

Всего для каждого провайдера было проведено 108 тестов: 3 различных client_counts * 3 различных thread_counts * 4 типа нагрузки * 3 итерации.

Где только можно, отключали репликацию и пулинг подключений. С пулингом интересный момент: он реально помогает базе данных не захлебнуться при нагрузке, но мы его специально отключали, чтобы увидеть «чистую» производительность самой СУБД без костылей.

В Timeweb такой возможности вообще не было. Так что мы до сих пор не знаем, тестировали мы их с пулингом или без.

Сберклауд и Яндекс просто не дают подключиться к базе извне их экосистемы. То есть, если у вас приложение не в их облаке, вы к своей базе данных подключиться не сможете. Занавес.

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

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

Таймвеб нас забанил тогда, когда мы начинали тестировать с локальной машины. Несколько раз мы запускали и перезапускали скрипт. Надо сказать, что мы его запускали синхронно с другими провайдерами. И в определённый момент мы увидели странное поведение от Таймвеба. Сначала посыпались ошибки, а потом скрипт сам перестал работать, потом перестал работать сайт Таймвеба с нашего публичного IP )

Мы не делали ничего необычного — просто запускали стандартный pgbench, который создаёт нагрузку не больше, чем обычное приложение. Примерно так интернет-магазин обращается к своей базе данных. На следующий день Timeweb нас разблокировал, и мы попытались запустить тесты уже с виртуальной машины внутри их сети. И тут произошло что-то странное: они сделали что-то со своим кластером managed db, что он вдруг резко стал показывать производительность гораздо выше, чем всё, что у нас было в тестировании — даже выше, чем наш собственный локально размещённый сервер GEN11 на Xeon 6430.

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

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

Казалось бы, 21-й век. Но нет, Ростелеком продолжает жить в эпохе «ждите звонка менеджера». Я готов предположить, что они так сделали для того, чтобы избежать потока людей с непонятной репутацией.

Результаты
Зависимость скорости транзакции к задержке


Количество транзакций в зависимости от соединений


Количество транзакций в секунду по типам нагрузки


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


Отношение стоимости к производительности


Распределение количества транзакций в секунду


Среднее количество транзакций по провайдерам


Средние задержки по провайдерам


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

ВК Cloud оказался примерно на 30–40% ниже лидеров. Это, кстати, полностью коррелирует с нашими предыдущими тестами виртуальных машин на Geekbench — похоже, у ВК просто железо послабее.

С Яндексом получилась совершенно абсурдная ситуация. Как только мы пытались подключить 64 клиента — тесты валились с ошибками. Мы просто не могли провести полноценное тестирование, отрезав весь верхний диапазон производительности. Как это интерпретировать? Да никак. Как будто вы пришли тестировать машину на автодроме, а вам говорят: «Извините, больше 60 км/ч ехать нельзя, у нас такие правила».

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

В результате по цене — Timeweb, несмотря на низкую абсолютную производительность, выглядит довольно неплохо. Они компенсируют технические ограничения привлекательной ценой. Как я уже говорил, VK Cloud и Яндекс — производительность не впечатляет, стоит дорого.

Среднее количество транзакций. Мы уверенно обходим всех. По цене получилось 9 тысяч рублей за кластер в месяц. Возможно, имеет смысл перетестить его )


Дисклеймер

Важный момент: все тесты мы проводили только в рабочие дни и только в дневное время.

Никаких ночных или выходных измерений.

Ограниченное количество конфигураций тестов: 3 варианта thread counts и 3 варианта client counts, только 1 вариант scale factor. Фиксированная конфигурация — тестировалась только одна конфигурация CPU/RAM/SSD (4vCPU + 16 Гб RAM + 40 Гб SSD).

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

Длительность исследования (несколько дней) и продолжительность итерации (30 секунд) могут быть недостаточны для выявления снижения производительности в долгосрочной перспективе. Мы включили 3 итерации для статистической значимости плюс 1 предварительная прогревочная итерация.

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

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

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

h3llo.cloud
auth.h3llo.cloud/register

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

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

В контейнерной упаковке огромное количество софта, в том числе очень много опенсорса. Можно поднять готовый контейнер с сервисом из хаба без проблем вообще. И это не создаёт сложных взаимозависимостей. Нужен PostgreSQL? Docker pull postgres — и он у вас.

К контейнерам монтируются свои ресурсы — диски, сети, конфиги и секреты.

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

Рои контейнеров могут масштабировать крупные корпоративные проекты, про это ниже.

И, наконец, никакой современный CI/CD почти не делается без контейнеров. Системным администраторам, DevOps-инженерам, разработчикам и СТО критически важно разобраться в контейнеризации.

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

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

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

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

Сначала у нас были физические серверы — железки, которые занимали целые стойки. Хочешь новое приложение? Покупай новый сервер. Нужно больше мощности? Апгрейдь железо.

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

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

Виртуалки — штука классная, но у них есть несколько серьёзных ограничений:

• Проблемы масштабирования. Допустим, у вас «чёрная пятница» и нагрузка выросла в три раза. С виртуалками у вас два пути: либо увеличить ресурсы существующей машины (ресайз), либо клонировать её. Оба варианта требуют времени и дополнительной настройки.
• Сложности с зависимостями. Представьте: у вас на одном сервере два приложения. Одному нужна Java 8, другому — Java 11. С виртуалками решение одно: две отдельные виртуалки. Это лишние ресурсы и головная боль с администрированием.
• Неэффективное использование ресурсов. Каждая виртуалка жрёт ресурсы даже в простое, потому что крутит полноценную ОС. Это как держать заведённую машину на парковке.

Разница между виртуализацией и контейнеризацией

Здесь важно понять ключевую разницу в подходах.

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

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

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

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

Существует даже кейс с очень коротким жизненным циклом контейнера: за 1–2 секунды поднимается контейнер, отрабатывает запрос, умирает. Это крайне удобно. Так делают на платформах приложений и в CI/CD-pipeline.

Контейнер — это изолированный процесс, которому кажется, что он запущен в отдельной системе. Но на самом деле он использует ядро хостовой ОС. Для изоляции контейнеры используют не возможности железа (как виртуалки), а возможности ОС — так называемое пространство имён. Например, Docker использует cgroups в ядре Linux.

Виртуалка весит гигабайты, контейнер — мегабайты. Postgres в контейнере (без нагрузки) — всего 9 мегабайт оперативки. Девять! Это просто смешно по сравнению с полноценной виртуалкой.

Виртуалки запускаются минуты, контейнеры секунды.

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

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

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

Вот почему они такие крутые.

Первые шаги: знакомство с Docker’ом

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

Docker и GUI к нему (Docker Desktop) можно поставить и на Linux, и на Mac, и на Windows. Для начала работы достаточно знать несколько команд: docker run, docker build, docker ps, docker stop. Не пугайтесь — это проще, чем кажется. Чуть-чуть покурить обучение на Ютубе или официальный get started — и вот у вас появляется первый контейнер.

Порог входа обманчиво простой.

Дальше идёт работа с образами и репозиториями — Docker Hub и прочие Container Registry. Docker Hub — это как GitHub, только для контейнеров. Там уже есть готовые образы для большинства популярных программ.

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

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

• Бизнес начинает расширяться.
• Проект превращается во что-то более крупное.
• Вы обновляете приложение несколько раз в день.
• В команде появляется больше 3–5 разработчиков.

Дальше идёт описание многокомпонентных систем в Docker Compose. Docker Compose позволяет описать в одном YAML-файле целую инфраструктуру: несколько связанных контейнеров, их сети, тома для хранения данных. Одна команда — и всё поднимается автоматически в нужном порядке.

Но до этого вас ждёт ещё пара ответвлений в дереве развития навыков.

Podman как альтернатива Docker. Со временем вы узнаёте, что Docker — не единственный вариант. Podman, например, не висит постоянно в памяти. Можно даже сделать алиас, alias docker=podman, и забыть, что у вас на самом деле не Docker.

Podman хорош для простого докерного опыта, но если нужен Docker Compose — это фича исключительно докеровская (хотя последние Podman уже поддерживает Docker Compose через плагины).

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

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

Самое главное — контейнеры упрощают CI/CD. До контейнеров CI/CD был про скрипты, которые что-то собирают, тестируют и куда-то выкладывают. Контейнеры всё упростили: среда сборки такая же, как среда запуска. Куча головных болей с зависимостями просто исчезла.

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

Это управление образами и их версиями. Для каждой версии вашего кода создаётся отдельная версия образа. Хотите откатиться? Просто укажите предыдущую версию. Никаких сложных процедур отката.

Docker Swarm обычно выступает как первая попытка оркестрации. Docker Swarm кажется логичным продолжением Docker — всё-таки от тех же разработчиков.

Вы в нём пытаетесь что-то сделать, плюётесь и думаете: «Хорошо, видимо, судьба ведёт в Кубер».

И в этот момент контейнеры ломают вас об колено.
Установить «настоящий» Кубер (тот, что в репозитории github.com/kubernetes/kubernetes) ужасно сложно. Тут возникает развилка: либо пользоваться облачными Managed Kubernetes, либо использовать упрощённые дистрибутивы вроде k3s, k0s, Minikube или Kind.

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

В Kubernetes базовая единица — не контейнер, а pod. Это такая абстракция, в которой может жить несколько контейнеров. Обычно требуется больше одного дня, чтобы врубиться, что же это такое. Вместе с этим меняется представление о контейнерах, ведь теперь у них появляются роли (init container, side-car container).

Kubernetes автоматически делает то, о чём ты раньше мог только мечтать: если приложение падает, оно автоматически перезапускается; если нагрузка растёт, оно автоматически масштабируется; если нода выходит из строя, рабочие нагрузки перераспределяются. Ну, то есть после настройки кучи всего, конечно. Например, для автомасштабирования понадобится Horizontal Pod Autoscaler и включённые метрики.

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

И ещё бывает автоматическое обновление без простоев. Kubernetes умеет обновлять приложения по принципу rolling update: постепенно заменяет старые поды новыми, поддерживая доступность сервиса. Пользователи даже не заметят, что произошло обновление.

Дальше надо понять базовые принципы сетевого взаимодействия контейнеров:

• TCP/IP и Linux bridge. Контейнеры общаются через обычную сеть. В пределах одной машины это виртуализированная сеть через Linux bridge. Создаётся виртуальный адаптер, крепится к контейнеру, появляется интерфейс с IP-адресом. К этой же виртуальной сети подключаются другие контейнеры.
• Виртуальные сети между контейнерами. С Docker Compose можно создать несколько разных сетей и ограничить общение контейнеров друг с другом. Это как виртуальные VLAN в мире контейнеров. Ручками тоже можно, но с Docker Compose — проще.
• Ingress и маршрутизация трафика. Ingress в Kubernetes — это способ маршрутизировать внешний трафик к сервисам внутри кластера. Если ставить Кубер на голом железе (или в виртуалках на голом железе), то на этом месте можно сломать голову и любой новичок гарантированно забуксует. Без возможности выставить сервис наружу Кубер превращается в чемодан без ручки дом без окон и дверей — все системы прекрасно работают внутри него, общаются между собой, но достучаться к ним снаружи кластера невозможно. Сейчас рекомендуется переходить с Ingress на Gateway API. Совет — не делайте этого, не освоив Ingress. И ни в коем случае не ставьте сразу Kong (он хорош, но о-о-о-чень сложен для начала).
• Балансировка нагрузки. Kubernetes умеет распределять запросы между несколькими репликами приложения. Managed Kubernetes обычно использует LoadBalancer от провайдера. Если ставить Кубер на своём железе — можно попробовать MetalLB — проект специально сделан, чтобы дать функционал LoadBalancer там, где он не предусмотрен по дизайну. Без балансировки между инстансами ничего не получится, иначе вы опять будете реплицировать монолит. Монолит, кстати, тоже можно разворачивать через контейнеры, но обычно смысл в другом.
• Инструменты визуализации (Hubble для Cilium). Kubernetes умеет дружить со множеством различных реализаций контейнеров, сетей и хранилищ. Делается это за счёт интерфейсов. Так вот для сетей есть Cilium, а для Cilium есть Hubble — визуальный интерфейс. Можно буквально увидеть, как взаимодействуют компоненты, куда идёт трафик. Это одна из самых частых проблем — нужно держать в голове карту взаимодействия, и это решение помогает быстрее освоиться.

Грабли, которые вы соберёте
В этом месте, если вы научитеcь оркестрировать, возникнет следующий уровень сложности — ИБ. Она, как и везде, ошибок не прощает.

Настройка портов и их экспозиция. Даже Senior-разработчики, бывает, путаются в настройке портов: что такое publish, expose, когда использовать ClusteIP, а когда NodePort. Это нормально — все через это проходят. Каждый раз, когда вы открываете порт наружу, вы создаёте потенциальную дыру в безопасности.

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

Контейнеру не нужны все права в мире. Дайте ему только то, что ему действительно необходимо для работы. Используйте seccomp, AppArmor или SELinux для дополнительных ограничений. Если Junior-разработчик предлагает запустить контейнер с флагом --privileged, это повод для серьёзного разговора (или увольнения, в зависимости от обстоятельств).

Уделите время освоению модели RBAC и практикам её использования в Kubernetes.

Никогда не хардкодьте пароли и ключи в образ контейнера. В Docker есть Docker Secrets, в Kubernetes — Secrets API. Используйте их вместо переменных окружения с чувствительными данными. Это важно, когда вы начнёте раскатывать что-то за пределы одного проекта.

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

Заражённые контейнеры тоже бывают. Образы контейнеров, как и любой код, могут содержать уязвимости. Да и атаки на цепочки поставки никто не отменял. Используйте инструменты вроде Trivy или Clair для проверки образов перед деплоем.

Ну и не наступайте на грабли с лицензиями. В мире контейнеров доминирует открытое ПО. Postgres вместо Oracle, Nginx вместо IIS. Это не только дешевле, но и удобнее упаковывается. Если у софта всё же есть коммерческая версия, то чаще всего она подразумевает поддержку от разработчика и дополнительный функционал. Обычно в мире open-source софт лицензируется по фичам, а не по ресурсам. Вы покупаете энтерпрайз-версию, а как её масштабировать — ваше дело.

Зачем всё это?
Современные LLM генерируют не просто куски кода, а целые приложения. И идеальный способ их запустить — контейнеры. Sonnet 3.7 уже настолько круто кодит, что многие компании смогли увеличить производительность в разы.

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

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

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

Яндекс, например, предлагает сервис, где контейнер запускается только на время вызова. Происходит HTTP-запрос, запускается контейнер, отрабатывает и умирает.

У нас в L1veStack подход, скорее — замена виртуалок. Serverless containers. Это логическое развитие контейнеризации: вы не думаете о серверах вообще. Есть контейнер, он запускается и работает пока вы его не остановите, и тарификация только за потреблённые ресурсы во время его работы. Наши контейнеры рассчитаны на долгую жизнь, но никто не мешает вам убить полстада и запустить заново. И повторить через 5 секунд.

Как учиться
Отличный первый проект для освоения контейнеризации — простой чат-бот. Он включает и фронтенд, и бэкенд, и базу данных — всё, что нужно для понимания взаимодействия контейнеров. Вот у нас пример. Там ещё и простой CI/CD на базе GitHub Actions, который собирает образ при каждом новом коммите.

Начните с запуска отдельных контейнеров, потом объедините их с Docker Compose, затем перенесите в Kubernetes. Это естественный путь освоения технологии.

Сейчас есть множество готовых Docker Compose файлов для популярных стеков. Хотите WordPress? Есть готовый рецепт. Хотите LowCode-платформу? Есть готовый рецепт. Нужна CRM-система? Есть готовый рецепт. Не изобретайте велосипед, используйте готовые решения.

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

Грейды примерно такие:

• Junior: базовые знания Docker, умение запускать и останавливать контейнеры.
• Middle: сборка своих образов, Docker Compose, CI/CD с контейнерами, основы Kubernetes.
• Senior: глубокое понимание Kubernetes, настройка производительности, мониторинг.

Если говорить про администрирование, то джуны ломаются на Ingress и выставлении портов наружу. Мидлы поломаются на Gateweay API и настройке Auto Provisioning для persistent volumes — как настроить систему, чтобы она автоматически выделяла дисковое пространство, например в Ceph. Даже некоторые сеньоры спотыкаются на сетевых тонкостях Kubernetes.

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

Нейронки сделали возможным выкатывать Proof-of-Concept целых систем за дни, а MVP — за недели. Скорость Time-to-Market решает в этой гонке, и её не повысить без инструментов автоматизации сборки и деплоя. И Kubernetes тут как нельзя в тему.

Если вы освоили всю стопку технологий и умеете их применять на практике (и не просто применять, а устанавливать и правильно настраивать), вы — мега-DevOps с зарплатой от 500к и выше. И спрос на таких специалистов только растёт.

Начать можно с официальной документации Docker и Kubernetes. Для углубления знаний рекомендую «Kubernetes в действии» и Docker: Up & Running. Есть даже отдельная книга «Kubernetes и сети» — для тех, кто хочет разобраться в сетевом взаимодействии.

Лучший способ учиться — делать. Пройдите интерактивные курсы на Katacoda или Play with Docker. Устройте себе хакатон выходного дня — запакуйте своё приложение в контейнер и запустите его в Kubernetes.

Почитайте Open Container Initiative.

Покурите service mesh решения (Istio, Envoy), которые важны при работе с микросервисами.

Разберитесь со StatefulSets (хранение состояния в контейнерах) — если не сломаете голову до этого.

На сладкое оставьте CRD и операторы (возможно, даже свои).

Подписывайтесь на телеграм-каналы DevOps-сообществ, следите за кейсами компаний, которые внедрили контейнеризацию. Вступайте в сообщества на Reddit, Stack Overflow, GitHub Discussions. Задавайте вопросы, делитесь своими находками. Контейнеризация — это живая экосистема, и лучший способ оставаться в курсе — быть её частью

h3llo.cloud
auth.h3llo.cloud/register

LiveStack — это бессерверная PaaS (Platform-as-a-Service) платформа, созданная для удобного развёртывания, управления и масштабирования приложений и сервисов, работающих на основе Docker-контейнеров. Она предлагает мощные инструменты для автоматизации процессов, облегчая работу разработчиков и DevOps-инженеров с современными облачными решениями и микросервисной архитектурой.






l1vestack.ru
auth.l1vestack.ru/register
console.l1vestack.ru

Первая тестовая стойка дома, до заезда в ЦОД. Уже после сборки я понял, что держать 35 миллионов рублей в квартире — так себе идея

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

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

Про ад с бюрократией я писал вот здесь.

В этом посте, кстати, было про Ростелеком, речь про Даталайн, который им стал в процессе нашего заезда:

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

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

Знаете, в эти игры можно играть вдвоём.

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

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

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

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

Это про наше подключение офиса к интернету.

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

У нас потребность была. Начали смотреть предложения, считать, думать.

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

Получили очень адекватное такое предложение — прямое включение, скорость любая, всё зависит от той пары трансиверов, которые поставишь на концах. Два волокна TX/RX, то есть одно на приём, одно на передачу.

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

Решили, что сейчас поставим 40 и врубим, потом 100 Гбит/с. Удобно же для офиса. Тем более команда быстро растёт.

Начали делать. Всё хорошо, но был один нюанс. Последние 150 метров достроить — надо согласовывать с собственником здания, через которое проходит как раз от ближайшего колодца трасса. У нас что с одного ввода люка, что с другого стоят жилые дома. В подвале этих жилых домов лежит трасса МГТС, в которой лежит оптика ШПД. Но когда вы ведёте там свою жилу, это становится не вопросом ШПД для дома, а отдельным проектом.

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

Собственник должен просто сказать: «Разрешаю, согласовываю». Подписать на плане, что согласовано, и, пожалуйста. Председатель ТСЖ, через которого предполагалось, что всё это идёт, хотел за это денег. От председателя надо получить документ, что трасса прокладки через подвал согласована. Она там уже по факту лежит и оказывает услуги дому. Казалось бы, надо как-то через неё класться. Но всё равно нужна его подпись. В этот момент мужик понял, что настал его звёздный час, и решил не упускать свой лучший шанс в жизни стрясти денег с коммерсов. Правда, он не знал, сколько именно трясти. А через помощника сигналил, что коммерческое предложение пришлите: сколько это, как это. Всё боялся продешевить. Непонятно же, сколько это стоит — 50 метров кабеля положить тебе в существующий лоток. Сколько за это взять? Разово? Ежемесячно?

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

А потом после примерно десятой итерации переговоров выяснилось, что председатель ТСЖ вообще не при делах. И его звёздный час прошёл. Подвал, через который всё идёт, давно выкупил другой человек — и он нам всё это очень быстро подписал. Безвозмездно.

Теперь по цене обычного офисного интернета у нас 40 Гбит/с напрямую к ЦОДу с минимальными задержками и без посторонних на пути. Но второй раз в такую игру я играть не хочу. Либо же сразу буду приходить с ультимативным коммерческим предложением.

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

Теперь представьте тех людей, которые строят трассу длиной не 150 метров, а 120 километров. И через сколько собственников она проходит. Сразу вспоминаются все эти жилые дома посреди скоростной трассы и прочие радости жизни.

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

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

Просто взяли и закрыли себе одну из двух кабинок туалетов.

Врезали в дверь замок и сделали выделенный персональный туалет.

К этому моменту у нас было уже под два десятка человек. А два десятка человек во вторую кабинку помещается не всегда.

Грубо говоря, их туалет dedicated, а у нас адская переподписка. Зашли на чай к собственникам бизнес-центра, они сильно удивились, и через 20 минут работы АХО, замок исчез. Всё, казалось бы, хорошо, я думал на этом и закончилось. Так нет, их учредитель пришёл к нам за эти туалеты качать права. Казалось бы, уже 25-й год на дворе, а кто-то додумывается поделить кабинки туалета. К счастью, быстро объяснили про общие права доступа.

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

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

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

Я осторожно выдохнул и спросил опытного middle+ про концепцию DRY (Don't repeat yourself) и как он применяет её в работе.

— DR что?

Я объяснил. На что кандидат просто сказал: «Нет, сдаюсь» и вышел с собеседования.

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

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

Вторая история с собеседования была ещё веселее. И вот она уже заставила надолго задуматься.

Два Scala-разработчика. Забегая вперёд, скажу, что в итоге-то мы столкнулись с очень большими проблемами с набором Scala-команды и после выхода Sonnet 3.6 переключили часть компонентов на Go, но про это чуть позже. А Sonnet 3.7 вообще поставил точку в вопросе.

Но вот собеседование. Откликов совсем немного. Scala-разработчики — это нечто очень экзотическое, днём с огнём не найдёшь.

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

— Вот. Готово.

Я не понял.

Смотрю — действительно готово.

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

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

Спустя полтора часа на Play! Framework эта штука еле-еле завелась и выдавала один работающий метод. Не микросервис, а именно один метод. Без логики.

Контраст, конечно, был очевиден.

Денег он запросил столько же много. А за сакральное знание, как выйти из Vim, мы столько платить не готовы.

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

Ещё одна интересная особенность в том, что современные LLM обучены очень хорошо кодить на Go, но очень плохо на Scala, и использовать их возможности просто не выйдет. Возможно, выборка была не очень большая. Мы надеялись на o1 и R1, но тоже нет. В общем, Go. Там и проблем с разработчиками нет.

Третья история с собеседований — аналитики ИБ. Руководитель по ИБ в компании должен завестись сам, потому что публиковать вакансию всё равно не выйдет со всеми деталями. Да и на рынке специалистов по ИБ нет от слова «совсем». Как и самого ИБ в малом и среднем бизнесе.

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

Специфика бизнеса — в том числе не допустить открытия канала к ОРМ. Мы, как хостер, должны определённый формат СОРМ поддерживать. К счастью, мы не должны закупать никакое дорогостоящее железо как телеком-операторы. Но мы должны наружу выставить для них защищённые концы с доступом к определённой информации. Её перечень, структуры и так далее, они все открыты в нормативке. Там 70-страничный документ с описанием GraphQL схемы. Собственно, мы должны её поддерживать и не давать посторонним лицам. Это персональные данные и, в принципе, репутация. Ну и помимо СОРМ есть базовая гигиена ИБ, за которой необходимо следить.

Поиски, кстати, всё ещё продолжаются.

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

У меня несколько розеток отдельных под домашний кинотеатр, акустику и так далее. По идее каждый сервак — блоки питания 800–1400. После включения всё это начинает жужжать адски, как рой дронов. Я думал, что соседи испугаются, что сейчас атака будет.

Потом ёлочка начинает гореть, то есть греться. Естественно, включаешь кондей либо открываешь окно, когда холодно. Дальше можно с этим сидеть, жить, настраивать.

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

Но самое смешное случилось, когда мы это через неделю настроили и повезли уже в ЦОД. Вызвали «Грузовичкоф». Приехала к нам Лада Ларгус и такой типичный водитель Ларгуса, который откуда-то с региона, видимо, приехал на заработки.

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

Выезжаем из паркинга, и он говорит:

— Ребята, а незамерзаечки у вас не будет? У меня что-то закончилась.

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

Уже приехав в ЦОД, мы поняли, мало того, что он её хреново закрыл, он в багажник её кинул прям поверх серверов.

И вся незамерзайка по ним течёт!

Пока я матерился страшными словами, он всё поспешно выгрузил и уехал.

В незамерзайке спирт (этиловый или изопропиловый), что для серверов условно-безопасно. И вода. Вода уже не так безопасна. К счастью, дальше крышки это не протекло. В паре мест капнуло на платы, я протёр, просушил, и всё завелось.

Это были наши первые серваки для Proof-of-Concept. Сейчас эти серваки будут доживать в наших инстансах под CDN, а мы закупаем уже HPE Gen12. Надеюсь, скоро покажу. Их точно сразу в ЦОД и не на Ларгусе.

VDI
Изучали рынок VDI в России, когда думали, кому и что будем продавать.

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

Садится команда людей, среди которых DevOps опытный, который сам Linux-драйверы низкоуровневые пишет для железа. Тимлид, который поднял десятки проектов руками, до этого много в студии Лебедева отработал и в блокчейн-проекте. Собственно, L1veStack (наш контейнерный хостинг) под его руководством вышел. Другой тимлид (тоже с хорошим опытом за плечами), разработчики и я.

И вот мы логинимся в VK и начинаем делать себе VDI. Прям по кнопке «создать VDI». Перед нами мастер на 7 шагов. Проходим первый экран, и там такая хитрая кнопочка «протестировать, всё ли правильно». Нажимаем. Просто начинает крутиться кругляш, и ничего не происходит.

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

Но виртуалку он не удаляет. Тарификация на неё капает.

Едем дальше. Дальше сетевые настройки, надо зайти в настройки сети, создать новую сеть. Причём диапазон 24-й ей маловат, ей подавай сразу минимум 22-й — и иди ещё с этим всем разберись и пойми из их описания. Ладно, курим маны и кое-как этот этап проходим.

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

На следующем шаге запуск виртуалки под уже выбранную конфигурацию.

1 рабочий стол, 1 контроллер, минимальные ресурсы.

Запустить виртуалку невозможно, потому что квоты не хватает.

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

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

Мы всё это посмотрели и поняли, что вряд ли кто-то эти сценарии проходит легко и хорошо.

Пошли тестить других. На третий день случайно вспомнили про ту виртуалку, которая включилась во время теста, пошли тушить. Тоже непросто, удаление заняло минут 20, потому что её нельзя просто удалить (кнопка тупо заблокирована). Сначала надо удалить все связанные с ней ресурсы — сеть, VDI-группу и так далее. А до этого надо ещё додуматься. Прикинули, сколько таких у других крупных клиентов )

Кстати, вероятно, если вы несколько раз запустите тест, виртуалок тоже будет несколько. Пробовать не стали.

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

Как покинуть офис
Лучшая история с офисом была, когда мы устроили вечеринку в пятницу с пиццей. Бизнес-центр у нас относительно небольшой, арендаторов не сотни, все уходят около 20–21. Охранник по стандартной привычке закрывает выход из здания и уходит на обход.

У нас корпоратив до 22. Мне понадобилось срочно уехать. Спускаюсь, охранника нет, выход закрыт. Соответственно, наши, кто любит просыпаться в 16 и работать вечером, делятся со мной лайфхаком — надо выйти в окно.

Показали окно. Я и вышел.

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

Привет Таймвебу
Ну и чисто хабровская история. Про комментарии к статьям. Буквально недавно столкнулся с тем, как эсэмэмщики работают в лучших традициях.

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

Сначала от них пришёл засланец просто, у которого стояла отметочка в профиле, что он работает в Таймвебе. Он накатал длинную-длинную телегу про то, какое мы говно. Его начали минусовать, спустили до -5. И внезапно попёрли плюсы, причём очень кучно! И это совпало с моментом, когда он отредактировал профиль и убрал, что он работает в Таймвебе. Прям отличная переобувка в воздухе — чудо, человек уволился, чтобы нас прокомментировать.

«Я вам оборудование закину погонять»
Напомню, когда мы только взяли площадку под ЦОД, там были развёрнуты ванны под асики. И ещё контейнеры стояли. И вот один из наших знакомых спрашивает, раз уж мы купили площадку, можно ли поставить своё оборудование.

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

Асиков там было почти на миллиард. Комплект майнера включал в тот момент травматический пистолет, и не один.


Набор майнера

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

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

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

Всё же облаком в России заниматься гораздо спокойнее и предсказуемее.

h3llo.cloud
auth.h3llo.cloud/register

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

Аренда чужого ЦОДа в 5-летней перспективе даёт 10% от стоимости оборудования — это соотношение примерно одинаковое что для стойки, что для целого машзала по мере его заполнения.

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

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



Это асики, утопленные в диэлектрической жидкости. С каждой ячейки отводится до 5 киловатт тепла — как со среднестатистической серверной стойки

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

Естественно, при ставке рефинансирования 21% мы бы в жизни не пошли в строительство своего ангара, подстанции, воздушного сегмента и завоз новых ванн с бурлящей охлаждайкой, не заморачивались бы на прокладку оптической трассы в соседний регион и так далее. Но начинали-то мы тогда, когда такой ставки не было, и теперь у нас есть ЦОД. Немного, скажем так, необычный.

В двух ДЦ Tier-3 в Москве мы ставим высокопроизводительное железо, а в своём занимаемся разгоном серверов в ваннах. В средней полосе.

Как выбирали ЦОДы в Москве
Сначала мы заехали в Даталайн (когда он ещё не был Ростелекомом) и в 3Data. Оба они на тот момент были отличными.

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

Потом в Даталайне завёлся (или правильнее сказать — окончательно установил свои порядки) Ростелеком, и мы смекнули, что мы не аудитория этого ЦОДа, всё-таки там госы или окологосударственные компании. Сейчас переезжаем в два крутых IXcellerate. Это второй по крупности оператор ЦОДов, то есть после Ростелекома у них самое большое количество стойкомест. У них два кампуса по несколько ЦОДов. И темпы их роста соответствуют нашим потребностям. Мы берём по несколько рядов в каждом машзале. Ряды там проектируют так, чтобы они были с энергонезависимыми вводами каждый. Ещё у них каждая стойка под отдельным СКУДом с биометрией.

Другие также рассматривали, но основные варианты вот такие. Почему так — потому что важны локация и связность. Между кампусами IXcellerate трассы выходят по 30 километров, это значит, что наши 400-гигабитные трансиверы между ЦОДами прекрасно добьют.

Всё, что расположено за МКАДом и так далее — это не очень интересная история.

Второй момент — это условия по количеству электричества на стойку и как оно тарифицируется. Основная история у ЦОДов — это 5–6 киловатт, а IXcellerate нам даёт 14.

И ещё есть свой ЦОД.

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

Потом эфир перешёл на другую систему счисления, на Proof-of-stake вместо Proof-of-work.

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

Тот же ЦОД в Медведкове — частично ЦОД, частично — склад СДЭК. И это вполне нормальная история.

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

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

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

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

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

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

Итак, зачем всё же свой
Подводя итог, условно, он нам достался почти что в наследство.

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

Плюс в своём мы также делаем иммерсию.


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

Это значит, что в своём ЦОДе мы с GPU сможем снимать очень-очень много вычислительной мощности за раз. Каждая ячейка установки (а в одной ванне их 24 штуки) может снимать по 5 киловатт. Чуть меньше того, сколько снимает целая стойка в среднестатистическом ЦОДе. Соответственно, в каждую такую ячейку можно погрузить мощный процессор и ещё их подразогнать, если они это поддерживают. Можно погрузить много GPU, и в рамках одной ячейки всё это будет прекрасно жить.

Умножаем это на самый дешёвый тариф электроэнергии и получаем вполне подходящие условия для таких решений, как VDI, 3D-рендеринг и инференс.

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

Облако IaaS — в ЦОДах партнёров, инференс и Архикад по VDI — в своём ЦОДе.

Почему так — потому что в самой Москве сейчас меняются условия игры, и HP уже 12-го поколения занимают, условно, в 7 раз меньше места, чем 10-го. По факту получается, что серваков нужно намного меньше, чтобы обеспечить хороший объём производительности и количество виртуальных машин для клиентов.

Поэтому решили, что самое эффективное для локации в Москве — это встать у партнёров.

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

Но во второй собственный ЦОД я не пойду, это прямо точно лишнее.

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

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

На улице стояли контейнеры, а само здание просто пустовало.

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

Проект ЦОДа на новой площадке


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

Самое смешное, что при таких технологиях даже наш ангар будет с коэффициентом энергоэффективности 1,05. По расчёту. Это даже не мифические 1,4 для недостижимых воздушных ЦОДов, это классика иммерсивки.

Как мы собираемся сертифицировать по Tier котельную
Никак.
Мы строим под Tier-3, но не будем ничего сертифицировать.

Сертификация — это долгая, дорогая и ненужная история, если ЦОД не продаётся как услуга. Если у вас сервис, то важно SLA, фактический аптайм и т.п. Тот же Amazon, в принципе, долгое время вообще не заявлял никакую сертификацию у своих ЦОДов. Если долго искать, то можно найти, где они говорят что-то вроде «Tier3+». И вроде бы это на словах. Но в целом, когда у вас облачный сервис, которому плюс-минус пофигу, что целый ряд отрубился во время распределённой задачи, то сертификация не очень актуальна. Лишнее удорожание просто и лишний входной барьер.

h3llo.cloud
auth.h3llo.cloud/register

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

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

Ну и вот теперь показываю вам.

Задача: понять, насколько одинаковый тариф с одинаковым количеством vCPU и RAM выражается в реальную производительность у разных провайдеров.

Забегая вперёд — у меня нет вопросов к Селектелу, Клауд.ру (Сберу) и Яндексу (почти). У них переподписки, вроде, нет. А вот дальше начинается дичь.

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

Какие тесты гонял
Обычный Geekbench 6. То есть это проверка CPU + RAM, но не дисковой подсистемы. Это синтетический тест, он не показывает производительность в реальных задачах вроде задёрганной 1С или реальной работы веб-сервера под нагрузкой, но считается, что его результаты достаточно показательны, чтобы админы могли ориентироваться на них. Со временем, возможно, я добавлю тесты дисковых подсистем и сети, но пока только вычисления.

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

Везде я брал виртуальную машину с одинаковой конфигурацией — 2 vCPU и 4 Гб оперативной памяти. Оговорка: у Рег.ру такой конфигурации нет, пришлось взять 2vCPU и 2Гб RAM.

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

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

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

Результаты Singe Core теста

Тут всё чётко:


Здесь зависит от машины, с одной не повезло:


Аналогично:


Тут график пожевало:


Вопросов нет:


Вопросов больше, чем ответов:


Сводная:


Сводный средний балл:


Из расчёта на затраченный рубль (больше — лучше):


Коротко — лучше всего идти в Селектел, Сбер или Яндекс, а вот на ВК, Рег.ру и Таймвебе есть устойчивое ощущение переподписки. В случае Рег.ру — ПЕРЕПОДПИСКИ, которую пытаются компенсировать низкой ценой.

Результаты Multicore
Странный результат показывает Яндекс — показатели тестов почти как на SingleCore:


Облако ВК — есть просадки:


Клауд.ру — очень хорошие результаты, но была непонятная просадка:


Таймвеб — график попердолило:


Селектел — вопросов нет:


Рег.ру удивляет:


Сводная:


Сводный средний балл:


И вот из расчёта на затраченный рубль (больше — лучше):


Ссылки на сырые данные
pastebin.com/JK4i6wcC
static.h3llo.cloud/bench_final.xlsx

Результаты словами
Как я говорил, нет вопросов к Сберу, Селектелу и с натяжкой — к Яндексу. К остальным есть.

Облако ВК в среднем ниже на 15‐20%, а отдельные инстансы — на 30%, и может показать внезапную просадку на такой же конфигурации с таким же процессором, и это, похоже, рандом.

Дальше очень много вопросов к Таймвебу, но у них есть оговорка — они продают линейку «Стандарт» и нигде не указывают, что она переподписанная. Есть отдельная линейка Dedicated, где они говорят, что закрепляют одно ядро за пользователем без переключений. Там с производительностью всё более-менее, но цена примерно в два раза выше, чем у других провайдеров. То есть вы покупаете переподписанный тариф, но у вас складывается ощущение, что нормальный.

Производительность MultiCore тестов Яндекса сильно удивила — там, где другие провайдеры честно показали x2, результаты Яндекса почти идентичны Single Core-тестам.

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

Также мы не включили 1cloud.ru, потому что у них нет ни последних образов ОС, ни адекватного механизма тестирования, честной почасовой оплаты тоже не нашли — при создании ВМ консоль просит пополнить баланс на месяц. Этим, кстати, и Таймвеб грешит. Cloud4Y перезвонили и на пожелание разместиться в хостинге с прозрачной почасовой оплатой предложили «идти туда, где такое есть».

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

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

Ещё ограничение теста
Мы не проверяли две следующие гипотезы:

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

Зачем я это делаю
Мы строим публичное облако в России. Хочется строить его сразу прозрачно, честно и чтобы было понятно, за что пользователи платят.

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

Пока же мне было просто интересно, кто насколько реально отдаёт 1 vCPU, и я получил числа. Что с ними делать и делать ли — решать уже вам.

Относительно нас самих — не думаю, что мы покажем плохие результаты в категории «производительность за вложенный рубль». Я точно не планирую так сильно переподписывать ресурсы. Кроме того, у меня стоят Xeon 4 на DDR5, которые в 2–3 раза производительнее того, что стоит у других.

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

Соответственно, цикл жизни, который я строю для облака, такой: vCPU, продаваемые как самые топовые, когда проживают какое-то время и устаревают, уходят на PaaS-сервисы, где не тарифицируется само железо.

h3llo.cloud
auth.h3llo.cloud/register

Коротко: огромный опенсорс-проект, который последние 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