Автоматические платежи

Дорогие клиенты!



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

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

Чтобы подключить автоматический платёж воспользуйтесь инструкцией — my.hostiman.ru/knowledge/97/498-kak-rabotayut-avtomaticheskiye-platezhi



На данный момент оплата в автоматическом режиме доступна только для банковских карт!

С уважением, Ваш хостинг-провайдер HostiMan.

Франция хочет стать поставщиком ИИ в Европу и за ее пределами

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

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

Во что инвестировать?
В Европе уже есть несколько компаний, которые создают программное обеспечение LLM. Перед этими компаниями стоит задача сделать свои инвестиции прибыльными, а это подразумевает создание клиентской базы, которая будет платить 10-20-50-100 евро в месяц, как это делают OpenIA, Microsoft, Google, X, Anthropic.

Всем этим проектам требуются вычислительные мощности для обучения алгоритмов на данных (обучение) и вычислительные мощности для последующего запуска программного обеспечения (вывод). Поэтому нам нужно Облако. Инвестиции в центры обработки данных и графические процессоры настолько важны и рискованны, что мы часто говорим о связях капитала между этими двумя мирами: Microsoft инвестировала в OpenIA, AWS сделала то же самое с Anthropic. Другое решение предложили Meta, Google и X, которые решили сделать оба варианта одновременно. Все это происходит в Северной Америке.

Инвестиционные заявления, которые мы слышим в течение последних нескольких дней, направлены на создание вычислительных мощностей во Франции для Европы. Частные компании построят центры обработки данных и здания, в которых будут работать графические процессоры. Кроме того, в некоторых объявлениях говорится об инвестициях в графические процессоры, но это касается не всех из них. Однако инвестиции в центр обработки данных составляют лишь 20% от необходимых сумм, а еще 80% необходимо запланировать на графические процессоры. В конечном итоге именно графические процессоры будут сдаваться в аренду либо облачным провайдерам, либо конечным потребителям. Что-то вроде оптового торговца графическими процессорами.

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

И причем здесь OVHcloud? Мы — поставщик облачных услуг. Как и у всех наших конкурентов, наша задача не заключается в обучении собственной модели LLM. Мы предлагаем нашим клиентам облачные сервисы, включая программы LLM с открытым исходным кодом, которые они могут легко использовать через API. Мы также работаем над проектом Omisimo совместно с Qwant, который объединяет несколько программ LLM с открытым исходным кодом для создания полноценного API, вобравшего в себя все лучшее из открытого исходного кода. У нас есть несколько очень крупных центров обработки данных в Европе и Канаде, мощностью от 40 МВт до 100 МВт каждый, и мы можем в любой момент добавить еще несколько сотен тысяч графических процессоров. Наши инвестиции в графические процессоры соответствуют спросу наших клиентов. Мы очень рады всему, что произойдет во Франции. Превосходное европейское обещание.

Распродажа доменов по 79 ₽



Давно мы не устраивали распродажу доменов — надо это исправлять!

С 10 по 23 февраля включительно можно зарегистрировать домен в зоне .RU/.РФ всего за 79 ₽ от регистратора Спринтнеймс! Даже если вы не придумали себе имя, можно воспользоваться нашим подборщиком на сайте — он предложит для вас варианты

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

cp.sprinthost.ru/customer/domains/add-domain
sprinthost.ru/tariffs/domains

Что не так с безопасностью OpenStack (и, соответственно, безопасностью большинства российских облаков)






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

Что не так с OpenStack и почти всеми российскими публичными облаками






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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

h3llo.cloud
auth.h3llo.cloud/register

Какую бюрократию мы прошли, чтобы открыть публичное облако в России по новым законам






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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НИЧЕГО!

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

h3llo.cloud
auth.h3llo.cloud/register

Внимание! Изменение цен на наши услуги



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

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

Новые тарифы с помесячной оплатой (с 1 марта 2025):
  • Базовое: 4 500 руб/мес
  • Оптима: 7 500 руб/мес
  • Премиум: 14 500 руб/мес
Понимая важность этого изменения, мы заранее информируем вас, чтобы у вас была возможность продлить услуги по старым ценам до 1.03.2025.

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

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

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

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

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

https://systemintegra.ru