+87.96
Рейтинг

Виталий Никсенкин

В последние несколько дней мы много слышим о проектах строительства «центров обработки данных мощностью 1 ГВт» для ИИ во Франции

Чтобы понять потребность, вы должны помнить эти три цифры:

Потребуется 50Me для инвестирования в 1000 графических процессоров, которые будут работать в центре обработки данных, потребляющем 1 МВт электроэнергии.

Эти три числа работают вместе на нескольких уровнях шкалы:
  • 50Me — 1k GPU — 1MW
  • 500Me — 10k GPU — 10MW
  • 5Mde — 100k GPU — 100MW
  • 50Mde — 1M GPU — 1GW

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

Для какой нужды? Графические процессоры используются в двух целях:
  • обучение и, следовательно, создание модели LLM с данными (обучение)
  • использование существующей модели LLM клиентами (вывод)

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

Вот почему для нужд обучения на рынок выходит новое поколение графических процессоров: суперчипы. Вместо десятков независимых графических процессоров, которые вы подключаете друг к другу последовательно, каждый суперчип объединяет десятки графических процессоров на одной карте. Отличная работа! Вы сократили расстояние между графическими процессорами и теперь можете подключить в 10 раз больше графических процессоров вместе, не снижая производительности. С другой стороны, у вас есть новые задачи, которые нужно решить: как распределить энергию и охладить инфраструктуру, которая в 10 раз плотнее, как приобрести источник энергии мощностью 1 ГВт и как обеспечить его избыточность.

Для размещения вычислительной мощности в центре обработки данных мы используем отсеки, также известные как стойки, которые представляют собой своего рода шкафы шириной 0,6 м, глубиной 1 м и высотой 2,5 м. На каждый отсек подается около 20 кВт электроэнергии. Для его охлаждения используется свежий воздух, прогоняемый через залив.

Если мы хотим использовать в отсеке более 20 кВт, воздуха будет недостаточно для его охлаждения. Вам необходимо перейти на водяное охлаждение. Вот тут мы начинаем говорить о новом поколении центров обработки данных, и в некоторых случаях речь идет о мощности 1 ГВт. Действительно, для размещения суперчипов мы сейчас говорим о стойках мощностью 120 кВт или даже предполагаем 240 кВт на стойку и систему водяного охлаждения для улавливания и отвода всего этого тепла. Это совершенно новое решение с точки зрения мощности на отсек, а также с точки зрения масштабируемой системы водяного охлаждения. Вот почему такого типа ЦОД не существует и поэтому его необходимо построить.

Для использования выводов нет необходимости в столь сложных центрах обработки данных. И суперчип тоже не нужен. Для модели LLM требуется система графических процессоров, потребляющая от 100 Вт до 10 кВт, редко 20 кВт, что эквивалентно от 1 до 16 графических процессоров. Поскольку каждая система независима, вы можете подключить столько систем параллельно, сколько захотите, что позволит вам обрабатывать большой веб-трафик или мобильный трафик. Еще лучше иметь несколько центров обработки данных вывода, работающих параллельно, и почему бы не создать по одному на страну? Это обеспечивает высокую доступность и низкие задержки за счет использования ближайшего к посетителю центра обработки данных.

И причем здесь OVHcloud? У нас более 40 центров обработки данных в нескольких странах Европы, Канады, Северной Америки и Азии. Мы являемся экспертами в области водяного охлаждения уже более 20 лет. Это позволяет нам охлаждать более 500 тыс. физических серверов во всех наших центрах обработки данных. Наши внутренние технологии с открытым исходным кодом обходятся в 20–40 раз дешевле рыночных решений. У нас есть центры обработки данных мощностью от 40 МВт до 100 МВт, в которых можно проводить обучение, с отсеками мощностью 40 кВт, но у нас также есть центры обработки данных по всему миру для предоставления выводов. Наши инвестиции соответствуют потребностям наших клиентов, и при необходимости мы можем ускориться.

Готовимся к 23 февраля: копите больше Джино.Плюсов!



Готовимся к 23 февраля: копите больше Джино.Плюсов!

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

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

Акция действует ограниченное время. Успейте получить бонусы и выбрать свой подарок!
auth.jino.ru/login/
jino.ru

Статистика Backblaze Drive за 2024 год



По состоянию на 31 декабря 2024 года у нас было 305 180 дисков под управлением. Из этого числа было 4 060 загрузочных дисков и 301 120 дисков с данными. В этом отчете основное внимание будет уделено этим дискам с данными, поскольку мы рассмотрим годовые показатели отказов (AFR) за четвертый квартал 2024 года, показатели отказов за 2024 год и показатели отказов за весь срок службы для моделей дисков, находящихся в эксплуатации по состоянию на конец 2024 года. По ходу дела мы поделимся нашими наблюдениями и идеями по представленным данным, и, как всегда, мы с нетерпением ждем, когда вы сделаете то же самое в разделе комментариев в конце поста.

Показатели отказов жестких дисков в четвертом квартале 2024 г.
По состоянию на конец 2024 года Backblaze отслеживал 301 120 жестких дисков, используемых для хранения данных. Для нашей оценки мы исключили из рассмотрения 487 дисков, поскольку они не соответствовали критериям включения. Мы обсудим критерии, которые мы использовали, в следующем разделе этого отчета. Удаление этих дисков оставляет нам 300 633 жестких диска для анализа. В таблице ниже показаны годовые показатели отказов за четвертый квартал 2024 года для этой коллекции дисков.


Заметки и наблюдения
  • Диски 24 ТБ уже здесь. Диски Seagate 24 ТБ (модель: ST24000NM002H) прибыли в начале декабря. 1200 дисков заполнили одно хранилище Backblaze без отказавших дисков до конца четвертого квартала. Диски Seagate 24 ТБ присоединяются к моделям дисков Toshiba 20 ТБ и WDC 22 ТБ в клубе 20-более-емкостных устройств, поскольку мы продолжаем значительно увеличивать емкость хранилища, оптимизируя существующее пространство сервера хранения.
  • Ноль отказов за квартал. Пять моделей дисков показали ноль отказов за квартал, начиная с модели диска Seagate на 24 ТБ, указанной выше. Остальные — это HGST на 4 ТБ (модель: HMS5C4040ALE640), Seagate на 8 ТБ (модель: ST8000NM000A), Seagate на 14 ТБ (модель: ST14000NM000J) и Seagate на 16 ТБ (модель: ST16000NM002J). Все нули сопровождаются оговоркой относительно небольшого количества дисков и дней работы дисков, но ноль отказов за квартал — это всегда хорошо.
  • Диски емкостью 4 ТБ почти вымерли. Количество дисков емкостью 4 ТБ сократилось еще на 1774 диска в четвертом квартале. (Я подробно рассказал, как мы их переносим, ​​если хотите разобраться.) Оставшиеся ~4000 дисков должны исчезнуть к концу первого квартала 2025 года. Их заменят новые диски емкостью 20 ТБ, 22 ТБ и 24 ТБ. Следует отметить, что из всех дисков емкостью 4 ТБ, которые работали в четвертом квартале, отказал только один, так что этим дискам емкостью более 20 ТБ есть что показать с точки зрения отказов.
  • Квартальный уровень отказов снизился. AFR за Q4 снизился с 1,89% в Q3 до 1,35% в Q4. Хотя все размеры дисков показали некоторое улучшение от Q3 к Q4, одним из основных драйверов стало добавление более 14 000 новых дисков емкостью более 20 ТБ. В целом эти диски показали AFR в размере 0,77% за квартал.

Критерии модели привода
Ранее мы отметили, что исключили 487 накопителей из рассмотрения при составлении приведенной выше таблицы, охватывающей четвертый квартал 2024 года. Существует две основные причины, по которым мы не рассматривали эти модели накопителей.
  • Тестирование. Это диски определенной модели, которые мы отслеживаем и собираем данные Drive Stats, но в настоящее время они не считаются производственными дисками. Например, диски, проходящие сертификационные испытания для определения их достаточной производительности для нашей среды, не включаются в наши расчеты Drive Stats.
  • Недостаточно точек данных. Когда мы вычисляем годовую частоту отказов для модели привода за определенный период времени (ежеквартально, ежегодно или за весь срок службы), мы хотим убедиться, что у нас достаточно данных, чтобы сделать это надежно. Поэтому мы определили критерии для модели привода, которая будет включена в таблицы и диаграммы за указанный период времени. Модели, которые не соответствуют этим критериям, не включаются в таблицы и диаграммы за рассматриваемый период.


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

Ежегодные показатели отказов жестких дисков в 2024 году
По состоянию на конец 2024 года Backblaze отслеживал 301 120 жестких дисков, используемых для хранения данных. Мы исключили из рассмотрения девять моделей дисков, состоящих из 2012 дисков, поскольку они не соответствовали определенным нами годовым критериям. Это оставляет нам 298 954 диска, разделенных на 27 различных моделей дисков. В таблице ниже показаны AFR на 2024 год для этой коллекции дисков.


Заметки и наблюдения
  • Никаких нулей за год. В 2024 году не было ни одной модели накопителя, соответствующей требованиям, с нулевым количеством отказов. При этом накопитель Seagate емкостью 16 ТБ (модель: ST16000NM002J) приблизился к этому показателю, зафиксировав всего один отказ накопителя в третьем квартале, что дало накопителю показатель AFR в 0,22% на 2024 год.
  • Занятые техники ЦОД. В 2024 году наши техники ЦОД установили 53 337 дисков. Если предположить, что в году 2080 рабочих часов (52 недели по 40 часов), то математика будет 53,337/2,080, и это значит, что наши бесстрашные техники ЦОД устанавливали 26 дисков в час. Заняты, заняты, заняты!
  • Диски Seagate на 24 ТБ? Хотя в 2024 году было добавлено 1200 новых дисков Seagate на 24 ТБ, они были установлены в начале декабря и не накопили достаточно дней работы, чтобы попасть в годовые или пожизненные таблицы. Включая диск Seagate на 24 ТБ, три модели не были включены в годовые таблицы 2024 года, эти модели дисков перечислены ниже.


Сравнение статистики Drive за 2022, 2023 и 2024 годы
В таблице ниже сравниваются годовые показатели отказов по моделям приводов за каждый из последних трех лет. Таблица включает только те модели приводов, которые соответствовали годовым критериям по состоянию на конец 2024 года. Данные за каждый год включают только этот год для рабочих моделей приводов, присутствующих на конец каждого года. Таблица отсортирована по размеру привода, а затем по AFR.


Заметки и наблюдения
  • Годовой показатель AFR снизился. AFR 2024 года для всех перечисленных приводов составил 1,57%, что ниже 1,70% в 2023 году. Мы ожидаем, что общие показатели отказов продолжат снижаться в 2025 году, но мы будем следить за следующими показателями.
  • Частота отказов моделей дисков объемом 8 ТБ и 12 ТБ. Все модели превысят пятилетний срок службы. В целом частота отказов заметно увеличится по мере того, как срок службы дисков превысит пять лет. И хотя есть исключения, такие как текущие диски HGST объемом 4 ТБ, нельзя предполагать, что это произойдет.
  • Частота отказов моделей дисков 14 ТБ и 16 ТБ. Эти модели приближаются к среднему возрасту — от трех до пяти лет эксплуатации. Именно здесь, согласно кривой ванны, частота отказов может постепенно увеличиваться — но не так сильно, как когда они превышают пять лет.
  • Частота отказов для моделей дисков 20 ТБ, 22 ТБ и 24 ТБ. Эти диски войдут в плоскую часть кривой ванны, то есть там, где частота их отказов должна быть самой низкой.
  • Годовые показатели отказов в зависимости от размера диска
  • Теперь мы можем углубиться в цифры, чтобы увидеть, что еще мы можем узнать. Мы начнем с рассмотрения квартального годового показателя отказов по размеру диска за последние три года.


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

Минимальное влияние. Диски 4 ТБ (синяя линия) и 10 ТБ (золотая линия) оказали незначительное влияние на общий уровень отказов за последний год, поскольку каждый из них закончил год с относительно небольшим количеством дисков. Тем не менее, дикая поездка, которую обеспечивают диски 10 ТБ, держит наших технических специалистов DC в напряжении.

Более старые диски. Диски емкостью 8 ТБ (серая линия) и 12 ТБ (фиолетовая линия) имеют возраст от пяти до восьми лет, и поэтому их общие показатели отказов должны со временем увеличиваться. Диски емкостью 12 ТБ следуют этой тенденции, увеличиваясь с примерно 1% AFR в 2021 году до всего лишь около 3% в 2024 году. Показатели отказов дисков емкостью 8 ТБ, хотя и нестабильны от квартала к кварталу, имеют почти ровную линию тренда за тот же период.

Диски Workhorse. Диски 14 ТБ (зеленая линия) и 16 ТБ (линия Azure*) составляют 57% от всех используемых дисков, и в среднем их возраст составляет от двух до четырех лет. Они находятся в расцвете сил. Таким образом, у них должны быть низкие и стабильные показатели отказов, и, как вы видите, они есть.

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

Новые диски на блок. Диски емкостью 22 ТБ (оранжевая линия) находятся на ранней стадии, поскольку мы продолжаем регулярно добавлять новые диски. Как только количество дисков стабилизируется, мы получим лучшее представление о направлении AFR. Тем не менее, первые результаты надежны: AFR за весь срок службы составляет 1,06%.

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


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


HGST. Хотя линия тренда HGST не очень красивая, она не рассказывает всю историю. Если посмотреть на первый график, то до четвертого квартала 2023 года приводы HGST были на уровне или ниже среднего значения для всех приводов, то есть всех производителей. В этот момент HGST превысил среднее значение, и даже больше. В таблице ниже приведены результаты только для приводов HGST за 2024 год. Мы отсортировали их по убыванию по AFR 2024 года.


Как вы можете видеть, есть две модели дисков емкостью 12 ТБ, которые обеспечивают высокий AFR для дисков HGST. Модель HUH721212ALN604 начала демонстрировать признаки увеличения квартального AFR в первом квартале 2023 года, а модель HUH721212ALE604 последовала ее примеру в третьем квартале 2024 года. Без этих моделей дисков AFR 2024 года для диска HGST составил бы 0,55%.

Seagate. Квартальная линия тренда AFR снизилась для дисков Seagate с 2022 по 2024 год. Хотя снижение было небольшим, с 2,25% до 2,0%, Seagate был единственным производителем, который сделал это. Снижение, по-видимому, по крайней мере частично, связано с изъятием дисков Seagate 4 ТБ в этот период.

Toshiba. В период с 2022 по 2024 год квартальный показатель AFR для моделей накопителей Toshiba варьировался в довольно узком диапазоне от 0,80% до 1,52%, при этом большинство кварталов колебалось в районе 1,2%. Самое главное, что ни одна из отдельных моделей накопителей не была исключением, поскольку самый высокий квартальный показатель AFR для любой модели накопителя Toshiba составил 1,58%. Нам нравится последовательность.

WDC. Хотя модели накопителей WDC показали такой же уровень стабильности, как и модели Toshiba, они сделали это с более низким AFR каждый квартал. С 2022 по 2024 год диапазон квартальных значений AFR для моделей WDC составлял от 0,0% до 0,85%. AFR в 0,0% был в первом квартале 2022 года, когда ни один из 12 207 работающих накопителей WDC не вышел из строя в течение этого квартала.

Статистика жесткого диска за весь срок службы
По состоянию на конец 2024 года Backblaze отслеживал 301 120 жестких дисков, используемых для хранения данных. Применив наши критерии дисков, указанные выше, для периода жизненного цикла, мы исключили 11 моделей дисков, состоящих из 2736 дисков, из рассмотрения, поскольку они не соответствовали определенным нами критериям жизненного цикла. Это оставляет нам 298 230 дисков, разделенных на 25 различных моделей дисков. В таблице ниже показаны AFR жизненного цикла для этой коллекции дисков.


Текущий показатель AFR за весь срок службы для всех дисков составляет 1,31%. Это ниже показателя 1,46% в 2023 году. Снижение в первую очередь обусловлено завершением миграции дисков Seagate емкостью 4 ТБ в 2024 году, в результате чего по состоянию на конец 2024 года в эксплуатации осталось только два таких диска. В результате 79 миллионов дней работы дисков и более 5600 отказов дисков, накопленных дисками Seagate емкостью 4 ТБ к концу 2023 года, не включены в данные, представленные в таблице срока службы за 2024 год выше.

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

При рассмотрении таблицы следует сделать несколько оговорок.
  • Для каждой модели достаточно данных, чтобы сказать, что значения AFR надежны. Тем не менее, завтра все может измениться. В целом, частота отказов жесткого диска следует кривой ванны по мере старения дисков — если только это не так. Некоторые диски отказываются выходить из строя по мере старения, как диски HGST емкостью 4 ТБ. Другие диски великолепны, а затем «упираются в стену» и быстро изгибают кривую отказов вверх.
  • Модель накопителя с годовым показателем отказов 1% означает, что можно ожидать, что один накопитель из 100 выйдет из строя в течение года. Если вы являетесь пользователем персонального накопителя, этот накопитель может быть вашим. Если у вас ровно один накопитель, ваш годовой показатель отказов составляет 100%. Другими словами, всегда имейте резервную копию и не забывайте ее тестировать.

Время миграции
Я был автором различных отчетов Drive Stats в течение последних десяти лет, и этот будет моим последним. Я ухожу на пенсию, или, возможно, на жаргоне Drive Stats это будет «мигрировать». В любом случае, после 10 лет в ВВС США и 30+ лет в Silicon Valley Tech, пришло время. Drive Stats продолжит работу со Стефани Дойл и Дэвидом Джонсоном в качестве моделей приводов для замены, начиная с отчета за первый квартал 2025 года. Желаю им всего наилучшего.

Я хочу поблагодарить каждого из вас, кто уделил время изучению и взаимодействию с отчетами и данными Drive Stats за последние 10 лет. И спасибо вам также за комментарии, вопросы и обсуждения, которые бурлили и бушевали в различных сообществах, которым небезразлична такая обыденная и потрясающая вещь, как жесткий диск. Это была та еще поездка — еще раз спасибо.

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

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

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

Во что инвестировать?
В Европе уже есть несколько компаний, которые создают программное обеспечение 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

Ускорение до 10 Gbps в Дании с PQ.Hosting!



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

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