Спрос на частные облака в России растет, и в ответ на это в 2024 году «Группа Астра» выпустила платформу Astra Cloud. Несмотря на относительно недавний запуск, ее уже успели оценить клиенты из госсектора и облачные провайдеры. О возможностях продукта и планах на будущее рассказывает генеральный директор Astra Cloud (входит в «Группу Астра») Денис Мухин — специально для TAdviser.

Растущий тренд на частные облака
Российский рынок облачных услуг демонстрирует устойчивый рост, при этом особенно заметно увеличивается спрос на частные облака — по оценкам аналитиков, до 30% в год. Этот тренд обусловлен двумя ключевыми факторами: потребностью бизнеса в цифровой трансформации и ужесточением регуляторных ИБ-требований, включая защиту персональных данных, банковской тайны и объектов КИИ.

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

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

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

Платформа Astra Cloud: передовые возможности для создания частных облаков
Платформа Astra Cloud специально разработана для создания защищенных частных облаков с возможностью предоставления услуг IaaS и PaaS. Решение позволяет централизованно управлять ИТ-инфраструктурой на всех уровнях: от физических ресурсов до облачных сервисов, развертывать защищенную облачную среду и размещать ее либо в корпоративном контуре организации, либо на площадках доверенных партнеров.


Платформа поддерживает работу как с аппаратными хранилищами, так и с конвергентными и гиперконвергентными инфраструктурами, включая программно-определяемые системы хранения данных (SDS). Это позволяет максимально эффективно использовать имеющиеся у заказчика ресурсы и снизить совокупную стоимость владения.

Платформа Astra Cloud создана на основе сертифицированной ОС Astra Linux Special Edition со встроенными замкнутой программной средой и мандатным контролем целостности.

Код компонентов платформы создается в соответствии с требованиями действующего законодательства к разработке безопасного ПО (ГОСТ Р 56939-2024), и в том числе благодаря этому платформа надежно защищает данные, обладает высоким уровнем отказоустойчивости и удобна в управлении.

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

Также доступно развертывание виртуальных сервисов для высокопроизводительных вычислений на основе vGPU. Поддержка Nvidia vGPU актуальна ввиду того, что многие клиенты используют видеокарты Nvidia для VDI, систем CAD и машинного обучения.

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

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

Еще одно важное преимущество – встроенный портал самообслуживания, автоматизирующий процессы заказа, предоставления ИТ-услуг, а также контроль и администрирование инфраструктуры. Платформа поддерживает управление не только частными облаками на базе гипервизора KVM, но и инфраструктурами VMware и OpenStack. Платформа поставляется в виде единого лицензированного продукта, что позволяет клиентам сократить время на ее развертывание и снизить операционную нагрузку на ИТ-персонал. С июля 2024 года решение присутствует в реестре Минцифры.


Кому подходит платформа Astra Cloud
Платформа представляет наибольший интерес для организаций с повышенными требованиями к информационной безопасности. В их числе:
Средний, крупный бизнес и компании, у которых уже есть частное облако. Платформа Astra Cloud позволяет консолидировать вычислительные мощности, организовать предоставление услуг, в том числе в защищенном режиме, а также заменить импортные или Open Source-аналоги.Облачные провайдеры. Им платформа дает возможность предлагать своим клиентам защищенные сервисы с повышенным уровнем безопасности и проходить аттестацию, согласно требованиям регулятора. Кроме того, платформа обеспечивает технологически и коммерчески гибкую интеграцию с существующей инфраструктурой.ФОИВы, РОИВы и предприятия с госучастием. Платформа помогает выполнить требования регулятора для аттестации. Также с ее помощью можно создавать, эксплуатировать и оказывать услуги на базе ФГИС и ГИС.Первые пилотные проекты и коммерческие заказчики появились сразу после запуска продукта в 2024 году. На текущий период пользователи есть во всех перечисленных категориях: часть клиентов активно применяет решение, другие находятся на этапе закупки.

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


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



Платформа Astra Cloud как основа защищенной облачной инфраструктуры
Построение частного защищенного облака — комплексная задача, которая всегда сопряжена с рядом вызовов. Значительную их часть помогает решить платформа Astra Cloud. Чтобы получить желаемый результат, важно правильно выполнить все шаги: подобрать аппаратное обеспечение, сетевое оборудование и системы хранения данных, на которых будет развернута облачная инфраструктура. При проектировании инфраструктуры важно убедиться в совместимости всех компонентов друг с другом и провести их проверку по программе Ready for Astra. Также поставка платформы осуществляется в формате ПАКов, в котором производитель гарантирует правильную работу оборудования и совместимость ПО.

Чтобы в полной мере обеспечить информационную безопасность и затем успешно пройти аттестацию, необходимо использовать сертифицированные средства защиты информации российского производства, прошедшие тестирование по программе Ready for Astra. Платформа уже интегрирована с решениями ведущих отечественных вендоров, подробности о которых доступны на официальном сайте «Группы Астра». astra.ru/ready-for-astra/compatible-software/

Завершающим этапом является прохождение процедуры аттестации, для чего после приобретения СЗИ и выполнения пусконаладочных работ необходимо привлечь аккредитованную ФСТЭК России стороннюю организацию.

Преимущества платформы Astra Cloud
Самое главное, что дает платформа российскому бизнесу:
Безопасность: платформа использует уникальные запатентованные и сертифицированные средства защиты информации (СЗИ) на базе решений Astra Linux.Модульность: обеспечивает гибкую настройку платформы и seamless-интеграцию с существующей инфраструктурой.Простота развертывания: инсталлятор позволяет быстро развернуть все компоненты платформы.Отказоустойчивость: автоматическое перераспределение нагрузки при выходе узлов из строя.Учет ресурсов: встроенный функционал для точного биллинга и тарификации.Мониторинг: комплексные инструменты для контроля состояния и производительности всех компонентов.Сертификация: возможность построения облачных решений для КИИ с полным соответствием требованиям регулятора.Масштабируемость: динамическое наращивание вычислительных ресурсов по мере необходимости.Все компоненты платформы разработаны в России. Что касается средств защиты информации (СЗИ), критически важных для большинства заказчиков, они встроены в Astra Linux и обеспечивают защиту не только операционной системы, но и других элементов платформы. Наличие этих механизмов – один из ключевых факторов, обеспечивающих лидирующие позиции «Группы Астра» в своем сегменте рынка.

Отличительные особенности
В отличие от других решений с пересекающимся функционалом, платформа Astra Cloud обладает принципиальным отличием: все компоненты платформы разработаны «Группой Астра» с акцентом на безопасность. Базовые компоненты решения сертифицированы ФСТЭК России по 2-му уровню доверия, что превышает стандартные требования рынка для аналогичного программного обеспечения.

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

Лицензирование и варианты поставки
Сейчас продукт поставляется в двух редакциях: «Базовой» (Base) и «Стандартной» (Standart). Первая включает минимально необходимый набор компонентов, позволяющий использовать его основные возможности и в дальнейшем расширить функционал, добавив необходимые инструменты из «Стандартной» редакции или собственные разработки.

Компоненты «Базовой» редакции — это ОС Astra Linux Special Edition и несколько подсистем:
виртуализация облачных ресурсов;служба каталога и контроллер домена;средства резервного копирования;портал самообслуживания, тарификации и учета;сбор событий, журналов и метрик для мониторинга.«Стандартный» вариант включает все компоненты из «Базовой» редакции и дополнительно средства автоматизации задач управления.

Заказать платформу можно в трех вариантах. Первый — это программный продукт, который инсталлируется на оборудование клиента, а Группа Астра обеспечивает техподдержку. Второй — программно-аппаратный комплекс поставляется как ПАК, и производитель предоставляет, помимо лицензий и услуг поддержки, еще и «железо». Третий вариант — поставка в публичном облаке Astra Cloud. В этом случае платформа приобретается по подписке, и за сопровождение отвечает команда Astra Cloud.



bill.astracloud.ru/billmgr

Основное требование к оборудованию, на котором платформа будет развернута, — чтобы оно было сертифицировано в рамках программы Ready for Astra.
astra.ru/ready-for-astra/compatible-hardware/

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

В ближайших планах — интеграция новых PaaS-сервисов, включая СУБД и инструменты контейнеризации, что значительно увеличит круг задач, решаемых на базе платформы Astra Cloud. Параллельно ведется развитие программно-определяемого хранилища данных (SDS) и сетей (SDN) для обеспечения гибкого управления ресурсами частного облака. Особое внимание уделяется внедрению модуля управления API (APIM). Также запланированы существенные улучшения графического инсталлятора, в том числе добавление функций массового развертывания узлов, что позволит ускорить внедрение платформы и снизить операционную нагрузку на ИТ-подразделения заказчиков.

Платформа Astra Cloud — это полноценный инструмент цифровой трансформации, который сочетает в себе безопасность, удобство, гибкость и соответствие требованиям российского законодательства. Благодаря глубокому уровню интеграции компонентов и проработанной архитектуре, она уже сегодня удовлетворяет ключевые потребности организаций из самых разных отраслей: от госструктур до облачных провайдеров.
astracloud.ru/private-cloud

ЦОД «Остаповский-2» стал второй инфраструктурной площадкой «Облака КИИ» в Москве. По последним исследованиям «iKS-Consulting», в стране насчитывается более 50 тыс. значимых объектов критической информационной инфраструктуры, принадлежащих более чем 5 тыс. организаций.

Облачная инфраструктура для КИИ от РТК-ЦОД — первое на рынке импортозамещенное решение. Примененные в продукте технологии внесены в реестр МинПромТорга, а программное обеспечение — в реестр Минцифры. Безопасность и соответствие площадок «Облака КИИ» строгим требованиям Приказа ФСТЭК России № 239 подтверждаются аттестатами соответствия, которые распространяются на всю облачную платформу и позволяют размещать в облаке объекты КИИ до второй категории значимости, государственные информационные системы первой категории и работать с персональными данными до первого уровня значимости включительно.

Дата-центр «Остаповский-2» введен в эксплуатацию в 2024 году и вмещает 2 048 стоек. ЦОД соответствует уровню защищенности Tier III, что гарантирует работу инженерных систем объекта в случае чрезвычайных ситуаций. Новая аттестованная площадка «Облака КИИ» станет частью отказоустойчивой инфраструктуры компании, которая уже включает площадку в дата-центре «Медведково-1». Расположение двух центров обработки данных в Москве на расстоянии около 20 км друг от друга позволяет обеспечить высокий уровень доступности сервисов и бесперебойность их работы.

Облако КИИ" стало первым решением, без которого наши заказчики столкнулись бы с трудностями на пути импортозамещения, защиты своих систем от киберугроз и приведения к соответствию требованиям регуляторов. Наше решение позволило значимым объектам КИИ избежать выбора между безопасностью и эффективностью в работе с облачными сервисамиАлексей Забродин, технический директор РТК-ЦОД

Сегодня бизнесу нужны практические инструменты для выполнения жестких требований. Мы видим свою роль в том, чтобы сделать этот процесс максимально простым и предсказуемым. Наше аттестованное облако с реализованной геоизбыточностью позволит компаниям сосредоточиться на своей основной деятельности, а не на решении вопросов соответствия инфраструктуры требованиям регуляторов к их объектам КИИ
сказал директор по продуктам РТК-ЦОД Александр Обухов.

С 1 декабря 2025 года стоимость услуг WebHOST1 увеличится на 5%. Кроме того, наша компания переходит на уплату НДС 5% согласно действующему законодательству. Все счета-фактуры с НДС будут формироваться в установленном порядке.

Если вы используете:
общую систему налогообложения,или УСН с уплатой стандартной ставки НДС (20%),вы сможете принять к вычету указанный в счёт-фактуре НДС в соответствии с законом.
webhost1.ru

Ноябрь — время, когда список дел длиннее, чем световой день: догорают отчёты и дедлайны, всем надо что-то успеть. Если вы, как и мы, чувствуете, что стресс достиг критического уровня, пора применять техники самопомощи. Например, покричать в лесу или просто расслабиться и попытаться поймать дзен.



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

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

Теперь обо всём по порядку: заварите ромашкового чаю, и поехали!

Статьи и инструкции
Как создать telegram-бота на Python
В инструкции — как собрать на Python верного помощника, который будет сообщать данные о сервере. А ещё разберём, как сделать так, чтобы он работал круглосуточно, а вы — нет.
firstvds.ru/blog/kak-sozdat-telegram-bota-na-python

Что такое Swagger и как он облегчает работу с API
Swagger — тоже один из способов автоматизировать работу и облегчить себе жизнь. Это набор инструментов для проектирования API-сервисов, который будет полезен разработчикам, аналитикам, тестировщикам и техническим писателям. В статье рассказываем, как использовать инструмент, и разбираем работу самых востребованных приложений в этой экосистеме.
firstvds.ru/blog/chto-takoe-swagger-i-kak-oblegchaet-rabotu-s-api

Подборка мануалов для системных администраторов
Мы знаем, как бывает сложно разобраться в настройках, поэтому наши специалисты подготовили для вас шпаргалки. Они помогут освоить работу с Systemd — инструментом для управления ОС на базе Linux, подключаться к БД MySQL — удалённо или локально, настраивать файрвол и переносить данные между облачными хранилищами. Сохраните их, чтобы заглянуть, когда появится задача.
Systemd: основы управления службамиКак подключиться к базе данных MySQLНастройка iptables в LinuxПеренос данных в объектное хранилище S3 с помощью Rclone
Habr: самое интересное за ноябрь
Когда рабочие задачи накрывают с головой, лучшее лекарство — отвлечься. Приходите к нам на Хабр, чтобы обсудить актуальные и просто интересные темы.
Разберемся, как эффективнее использовать AI-инструменты в разработке на примере Vue SFC, и расскажем про демокит для тестирования RF-плат. Если хочется чего-то более легкого, припасли научный нон-фикшен — трогательную историю создания кардиомонитора и статью о поразительной случайности, которая привела к открытию реликтового излучения.
Vue SFC — идеальный формат для AI-разработки и вот почемуТестируем плату RF Demo Kit for NanoVNA-F Инженер, который научил компьютер слушать сердце: история Хейвуда и его кардиомонитора Космический шум, или как случайно нашли реликтовое излучение
Ищем авторов для блога на Хабр
Подготовьте статью на одну из специальных тем или отправьте материал на тему месяца. И если ваша статья подойдёт для блога, получите повышенный гонорар.
Тема декабря: IT-компании.
firstvds.ru/avtoram


Новости ноября
Запустили новый сервис — статус-панель
 
Статус-панель FirstVDS — инструмент, который позволяет оперативно оценить состояние вашей инфраструктуры: кластеров с тарифными планами, панелей виртуализации, сетей и сервисов. В случае внезапных проблем панель сразу поможет понять: это локальная неисправность или масштабный инцидент.
Перейти в статус-панель можно с главной страницы нашего сайта. Для этого в верхнем меню нажмите на индикатор статус-панели.
firstvds.live
О том, как работает инструмент и какие задачи решает, рассказали в подробной инструкции.
firstvds.ru/technology/status-panel-firstvds

Временно приостанавливаем продажи VDS в Казахстане

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

Топ новостей из мира безопасности
Отличные новости для всех, кто полыхает в огне дедлайнов: в плане безопасности ноябрь выдался довольно тихим и мирным. Но всё-таки специалисты по безопасности обнаружили несколько критических уязвимостей. Мы советуем проверить свои системы, чтобы избежать проблем:
уязвимости в браузерах на Chromium, а также в Wordpress, Docker и Kubernetes;опасные уязвимости в WordPress и Grafana Enterprise.Специалисты по ИБ также обнаружили новую волну атак на реестр npm — затронуто уже 25 000 репозиториев. По принципу действия он напоминает вредонос Shai Hulud: подробный обзор атаки — в нашей статье на Хабре habr.com/ru/companies/first/articles/969916/

Угроза для пользователей браузеров на базе Chromium
ИБ-исследователь Хосе Пино обнаружил серьезную уязвимость в движке Blink, которая позволяет за секунды вывести из строя многие браузеры на базе Chromium или вызвать зависание системы. Уязвимость подтверждена в браузерах на движке Chromium, начиная с версии 143.0.7483.0. В том числе в Microsoft Edge, Brave, Opera и Vivaldi, OpenAI ChatGPT Atlas, Perplexity Comet и другие. Исключение — Firefox, Safari, которые используют собственные движки — Gecko и WebKit соответственно.
Как работает атака. Проблема заключается в том, что Blink не ограничивает частоту обновлений API document.title. Это приводит к миллионам мутаций DOM в секунду: они перегружают CPU, приводя к внезапному завершению работы браузера и падению производительности системы.
Атака включает три этапа:
Подготовка. В память загружаются данные для циклической смены заголовка вкладки.
Инъекция. Скрипт выполняет массовые обновления document.title, создавая огромную нагрузку.
Перегрузка. Главный поток браузера перегружается, что приводит к зависанию интерфейса, вкладок и последующему аварийному завершению работы.
Brash можно активировать по таймеру, превратив в логическую бомбу — достаточно кликнуть по вредоносной ссылке.
Защита пока только одна: не переходить по подозрительным ссылкам и закрывать зависшие вкладки. Разработчики Chromium планируют ограничить частоту обновлений document.title и улучшить управление ресурсами Blink.
xakep.ru/2025/10/31/brash/

Плагин безопасности Wordpress оказался уязвимым
В плагине Anti-Malware Security and Brute-Force Firewall для Wordpress обнаружена уязвимость CVE-2025-11705. Она позволяет пользователям с минимальными правами (например, подписчикам) читать любые файлы на сервере. Например, получить доступ к конфигурационному файлу wp-config.php, где хранится имя базы данных и учетные данные. В этом случае злоумышленник может украсть хеши паролей, email-адреса, содержимое постов и другие конфиденциальные данные, что может привести к полному захвату сайта.
Проблема — в функции GOTMLS_ajax_scan(), которая обрабатывает AJAX-запросы. В ней отсутствует проверка прав доступа — используется только nonce, который может перехватить атакующий. Это позволяет любому авторизованному пользователю вызвать функцию и прочитать критически важные файлы.
Сейчас плагин Anti-Malware Security and Brute-Force Firewall установлен более чем на 100 000 сайтов. Уязвимость затрагивает версии 4.23.81 и более ранние. Чтобы защититься, необходимо обновить плагин Anti-Malware Security and Brute-Force Firewall до версии 4.23.83 или выше, где добавлена проверка прав пользователя. Поскольку уязвимость уже раскрыта публично, атаки могут начаться в любой момент, поэтому обновление следует установить как можно скорее.
xakep.ru/2025/11/01/secure-plugin-bug/

Уязвимость в плагине Wordpress ставит тысячи сайтов под удар
Злоумышленники атакуют сайты на Wordpress, используя критическую уязвимость CVE-2025-11833 в популярном плагине Post SMTP (более 400 000 установок), который применяется для отправки почты. Хакеры перехватывают письма для сброса паролей, получая полный контроль над ресурсами. Уязвимость затрагивает все версии плагина от 3.6.0 и выше.
Дело в том, что плагин передаёт логи писем по любому запросу без проверки прав. Это позволяет злоумышленникам читать письма для сброса паролей администраторов, переходить по ссылкам и захватывать учетные записи. Уязвимость оценивается в 9.8 баллов из 10 по шкале CVSS.
Для защиты необходимо срочно обновить плагин Post SMTP до версии 3.6.1, где эта уязвимость исправлена. Поскольку атаки уже фиксируются в активной фазе (тысячи попыток взлома), мы советуем не откладывать обновление.
xakep.ru/2025/11/06/post-smtp-flaw/

Побег из контейнера: обнаружены три уязвимости в runC для Docker и Kubernetes
Инженер SUSE и член совета Open Container Initiative (OCI) Алекса Сарай обнаружил три критические уязвимости (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) в контейнерном рантайме runC — ключевом компоненте Docker и Kubernetes, отвечающем за низкоуровневые операции управления контейнерами.
Уязвимости связаны с манипуляцией символьными ссылками при монтировании файлов и позволяют злоумышленнику, имеющему возможность запускать контейнеры с кастомными настройками, обойти изоляцию и получить права root на хост-системе:
CVE-2025-31133 — позволяет атакующему заменить /dev/null на символьную ссылку для записи произвольных данных в /proc.
CVE-2025-52565 — через манипуляции с /dev/console и символьные ссылки возможна запись критических данных в procfs.
CVE-2025-52881 — обход LSM-защиты позволяет перенаправлять запись данных в /proc на контролируемые файлы, включая опасные вроде /proc/sysrq-trigger.
Уязвимости требуют возможности настраивать монтирование в контейнерах через вредоносные образы или Dockerfile.
Как защититься:
Обновить runC до версий 1.2.8, 1.3.3, 1.4.0-rc.3 или новее.
Включить user namespace для всех контейнеров без предоставления root-прав хоста.
Использовать rootless-контейнеры где это возможно.
Мониторить подозрительную работу с символьными ссылками.
На текущий момент активных атак не зафиксировано, но лучше как можно скорее установить обновление.
xakep.ru/2025/11/11/runc-bugs/

Критическая уязвимость в W3 Total Cache: полный контроль над сайтом через комментарии
В популярном плагине WordPress W3 Total Cache обнаружена критическая уязвимость CVE-2025-9501. Она позволяет выполнять произвольные PHP-команды на сервере без аутентификации и получить полный контроль над сайтом. Уязвимость затрагивает все версии плагина до 2.8.13.
Уязвимость связана с функцией _parse_dynamic_mfunc(), которая обрабатывает динамические вызовы функций в кешированном контенте. Для атаки достаточно оставить на сайте специально подготовленный комментарий с вредоносной нагрузкой — плагин выполнит содержащиеся в нем PHP-команды.
Чтобы защититься:
обновите W3 Total Cache до версии 2.8.13;
если обновление невозможно, деактивируйте плагин;
в качестве дополнительной меры отключите комментарии на сайте или включите их премодерацию.
Разработчики выпустили исправление 20 октября 2025 года, но сотни тысяч сайтов до сих пор остаются уязвимыми. Исследователи намеренно отложили публикацию PoC-эксплоита до 24 ноября, чтобы администраторы успели обновить системы.
xakep.ru/2025/11/20/w3-total-cache-injection/

Критическая уязвимость в Grafana Enterprise позволяет получить права администратора
В Grafana Enterprise обнаружена критическая уязвимость CVE-2025-41115 (CVSS 10/10), позволяющая злоумышленнику выдать себя за администратора или другого пользователя системы. CVE-2025-41115 затрагивает Grafana Enterprise версий 12.0.0–12.2.1.
Атака работает, если включена функция SCIM provisioning (опции enableSCIM и user_sync_enabled установлены в true). В этом случае вредоносный SCIM-клиент может создать пользователя с числовым externalId, который Grafana соотносит с внутренним идентификатором user.uid. Такая подмена позволяет получить права администратора или другого привилегированного пользователя.
Для защиты необходимо как можно скорее обновить Grafana Enterprise до версии 12.3.0 или патчевых релизов 12.2.1, 12.1.3, 12.0.6. В качестве временной меры рекомендуется отключить SCIM provisioning. Уязвимость в Grafana была обнаружена и устранена 4 ноября 2025 года. По данным компании, злоумышленники не использовали её в атаках на облачный сервис Grafana Cloud.
xakep.ru/2025/11/24/grafana-flaw/

Опасная атака на npm: Sha1-Hulud крадёт данные и уничтожает файлы
Специалисты по ИБ обнаружили волну атак Sha1-Hulud на реестр npm, которая затронула уже более 25 000 репозиториев. Принцип её работы напоминает атаку Shai-Hulud, выявленную ранее в 2025 году. Но новый вредонос может не только красть учётную информацию и получать контроль над системами, но и даёт возможность полностью удалять данные на заражённых устройствах.
Как работает атака Sha1-Hulud на npm:
Злоумышленники добавляют в пакеты вредоносный скрипт preinstall, который выполняется автоматически при установке пакета. Этот скрипт обнаруживает или устанавливает среду Bun.
Запускается вложенный вредоносный код, который регистрирует заражённую машину как GitHub self-hosted runner с именем SHA1HULUD.
Далее создаётся и добавляется в репозиторий вредоносный GitHub workflow (например, .github/workflows/discussion.yaml) с уязвимостью внедрения команд. Этот workflow позволяет злоумышленникам запускать произвольные команды на runner.
Вредоносный код запускает утилиту TruffleHog для локального сканирования машины на предмет поиска токенов npm, ключей облачных платформ AWS, GCP, переменных окружения и других секретов.
Workflow собирает все секреты из GitHub Secrets и сохраняет их в файл actionsSecrets.json, который скачивается обратно на заражённую машину. Workflow удаляется для сокрытия следов.
Собранные секреты и конфиденциальные данные отправляются злоумышленникам, в том числе создаётся публичный репозиторий Shai-Hulud с украденными данными от имени жертвы.
Если вредонос не может получить доступ к токенам или аутентифицироваться в GitHub (или получить npm токены), запускается функция уничтожения всех доступных для записи файлов в домашнем каталоге (wiper). Для повышения привилегий вирус пытается получить root-доступ через Docker, монтируя корневую файловую систему в привилегированном контейнере и копируя вредоносный файл sudoers для беспарольного доступа. Подробнее о механизме атаки и её рисках рассказывали в нашей статье на Хабре.
Как защититься:
просканировать все конечные точки на наличие заражённых пакетов и немедленно удалить их;
обновить все учётные данные и проверить репозитории на наличие подозрительных файлов workflow, таких как shai-hulud-workflow.yml;
внимательно следить за необычными ветками и действиями в .github/workflows для выявления скрытого заражения.
thehackernews.com/2025/11/second-sha1-hulud-wave-affects-25000.html

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

1. Ежегодная корректировка платы за обслуживание
Ежегодно мы корректируем стоимость наших услуг, чтобы иметь возможность инвестировать в разработку продуктов и продолжать предоставлять вам улучшенные услуги. Мы ограничили индексацию цен до 3,9% в соответствии с пунктом 10.2 наших Условий продаж B2B.
Это повышение применимо ко всем услугам, за исключением программного обеспечения и доменов.

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

2. Увеличение платы за стороннее программное обеспечение (применимо к вашим Услугам, см. ниже)
Как вы, возможно, читали в новостных лентах отрасли, cPanel, Plesk и Microsoft объявили о повышении цен с 1 января 2026 года. Мы отнесём это повышение стоимости лицензий к стоимости услуг. Поэтому следующее повышение вступит в силу с 1 января 2026 года только для тех, кто использует лицензии cPanel, Plesk или Microsoft.




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


Кроме того, в годовщину даты начала действия контракта для вашего выделенного сервера или VPS будет применена индексация платы за обслуживание на 3,9 % в год.

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

С наилучшими пожеланиями,
Берт Стам,
Управляющий,
Leaseweb Netherlands BV

С наилучшими пожеланиями,
Маркус Буш,
Управляющий,
Leaseweb Deutschland GmbH

С наилучшими пожеланиями,
Питер Краан,
Генеральный директор,
Leaseweb Singapore PTE. LTD.

С наилучшими пожеланиями,
Ричард Коупленд,
Генеральный директор,
Leaseweb USA Inc.

CloudKleyer GmbH совместно с Archigas GmbH приступили к реализации DigitalH2-Ops — двухлетнего проекта по исследованию и разработке, направленного на создание федеративной, безопасной и соответствующей нормам ЕС цифровой инфраструктуры для водородной экономики.

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

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

Проект софинансируется Европейским союзом (ERDF) и федеральной землёй Гессен.

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

С 5 декабря 2025 года вступят в силу изменения в юридической документации Yandex Cloud. Ниже в письме подробно разбираем конкретные документы и изменения.

Оферта
П. 5.1, 5.1.1: внесены изменения в условия тарификации сервисов. В частности, тарифы указываются на сайте с учётом всех применимых налогов, если прямо не указано иное; в случае установления новых ставок НДС стороны соглашаются автоматически применять такие изменения с даты их вступления в силу — путём изменения тарифов (стоимости услуг) на размер изменения ставок НДС.П. 7.2.12, 13.6: зафиксировано, что Яндекс может передавать кредитным организациям по их запросу информацию о клиенте, если клиент использует для оплаты сервисов платёжные данные третьего лица и указанное лицо оспаривает операции, связанные со списанием денежных средств.П. 15.2: зафиксировано, что Яндекс вправе направлять клиентам уведомления, сообщения и документы посредством использования мессенджеров, в том числе с привлечением для этого третьих лиц, оказывающих Яндексу услуги по использованию мессенджеров.Раздел 14: изложены условия об обработке персональных данных в новой редакции.Раздел 18: уточнено понятие «Контент».yandex.ru/legal/cloud_oferta/ru/

Условия использования сервиса «Платформа Яндекс.Облако»
П. 4.6: зафиксировано, что определённая информация об использовании клиентом платформы и сервисов может быть использована Яндексом для достижения ряда целей, связанных с совершенствованием качества и усилением безопасности платформы и сервисов.Раздел 4: внесены уточнения в иные условия раздела «Персональная информация».yandex.ru/legal/cloud_termsofuse/ru/

Соглашение об обработке данных
П. 1.2: добавлена ссылка на страницу с актуальным заключением о соответствии системы защиты персональных данных требованиям законодательства о персональных данных.П 3.2: уточнён состав данных, обрабатываемых по поручению клиентов.П 3.9: указаны случаи, когда Яндекс вправе допускать своих сотрудников, подрядчиков и иных третьих лиц к обрабатываемым персональным данным.Раздел 2: удалены те обязанности клиента как оператора персональных данных, которые он должен осуществлять самостоятельно в силу закона, вне связи с поручением на обработку данных.Уточнены формулировки некоторых текущих условий.yandex.ru/legal/cloud_dpa/ru/

Наши бессрочные предложения «Чёрной пятницы» уже действуют. Все предложения включают выделенные серверы, доступные в наших дата-центрах в Нидерландах. Скидки на некоторые серверы действуют в течение всего срока действия сервиса.

В этом году мы представляем кое-что новое:
Мы — первый поставщик, предлагающий Intel Xeon 6 6741P и 6761P.
Оба процессора включены в линейку «Чёрной пятницы».


AMD EPYC 9655P (96 ядер) также доступен по акции «Чёрной пятницы»!

Никаких временных бонусов. Никаких уловок при оплате по промокодам. Реальное оборудование, реальные бессрочные цены.

Что включено:
Скидка пожизненно зафиксированаСерверы с моментальной поставкой (доставка примерно в течение 2 часов)Процессоры AMD EPYC и Intel Xeon (включая Xeon 6)EPYC 9655P теперь доступен по акции BFКруглосуточная поддержка премиум-класса в соответствии с соглашением об уровне обслуживания (SLA)Все серверы находятся в наших дата-центрах в Нидерландах
Ознакомьтесь с предложениями «Чёрной пятницы»: www.worldstream.com/en/dedicated-servers/blackfriday/

Надежные IT-решения. Никаких сюрпризов.
Рекомендуемые серверы к Черной пятнице (пожизненное предложение)

AMD EPYC 7402P – 24 ядра / 48 потоков, 2,80 ГГц
Процессор: AMD EPYC 7402P
Оперативная память: 64 ГБ (максимум 128 ГБ)
Накопитель: 2× 480 ГБ SSD корпоративного класса
Пропускная способность: Гбит/с гарантирована (безлимитный тариф + 30 евро)
Местоположение: Нидерланды – Worldstream Datacenters
Цена: 85,00 евро в месяц (пожизненное предложение)
www.worldstream.com/en/dedicated-servers/configure/121/

2 процессора Intel Xeon E5-2620v4 – 16 ядер, 32 потока, 2,10 ГГц
Оперативная память: 64 ГБ
Накопитель: 2× SSD-накопитель Enterprise объёмом 960 ГБ
Пропускная способность: гарантированная 1 Гбит/с
Местоположение: Нидерланды
Цена: 59,00 евро в месяц (ПОЖИЗНЕННАЯ АКЦИЯ)
www.worldstream.com/en/dedicated-servers/configure/125

Все предложения Чёрной пятницы:
www.worldstream.com/en/dedicated-servers/blackfriday/

Мы отмечаем сезон распродаж и отменяем плату за установку на некоторых серверах, начиная с сегодняшнего понедельника и до 23:59 (CET) 1 декабря 2025 года. Кроме того, вы можете бесплатно получить выбранный вами ресурс Storage Share на месяц.

Независимо от того, хотите ли вы максимально увеличить вычислительную мощность или ищете масштабируемое хранилище, сейчас самое время обновить свою инфраструктуру и сэкономить до €79,00 / $88,00. Только не ждите слишком долго! Это предложение действительно только до тех пор, пока есть запасы.

СЛОЖНО ВЫГОДНОЕ ПРЕДЛОЖЕНИЕ: ВЫДЕЛЕННЫЙ СЕРВЕР EX44
Выделенный сервер EX44 обеспечивает высокую производительность, необходимую для сложных задач. Он оснащён процессором Intel Core i5-13500 13-го поколения с технологией Hyper-Threading, 8 ядрами эффективности и 6 ядрами производительности, 64 ГБ оперативной памяти DDR4 и двумя быстрых твердотельными накопителями NVMe Gen4 объёмом 512 ГБ, обеспечивая при этом высокую скорость и производительность.
www.hetzner.com/dedicated-rootserver/ex44

ФЕНОМЕНАЛЬНАЯ МОЩНОСТЬ: ВЫДЕЛЕННЫЙ СЕРВЕР AX102
Выделенный сервер AX102 поразит вас своим великолепным процессором AMD Ryzen 9 7950X3D с 16 ядрами и 32 потоками, основанным на архитектуре Zen 4. Асимметричная конструкция обеспечивает значительный прирост производительности: 8 ядер поддерживают инновационную технологию 3D-V-Cache для снижения задержек, а остальные 8 ядер идеально подходят для приложений, требующих более высокой тактовой частоты. В качестве оперативной памяти вы получите 128 ГБ оперативной памяти DDR5 ECC, а для хранения данных — два быстрых твердотельных накопителя Datacenter Gen4 NVMe по 1,92 ТБ.

В целом, выделенный сервер AX102 идеально подходит для профессионального использования со сложными вычислениями, такими как CAD/CAM, машинное обучение, 3D-рендеринг и обработка больших данных. Выделенный сервер AX102 доступен всего от 104,00 евро / 116,00 долларов США в месяц. Вы сэкономите 39,00 евро / 44,00 долларов США на настройке.
www.hetzner.com/dedicated-rootserver/ax102/

ФАНТАСТИЧЕСКИ ГИБКИЙ: ВЫДЕЛЕННЫЙ СЕРВЕР AX162
Этот сервер доступен в двух модификациях, обе из которых основаны на процессоре AMD EPYC™ Genoa 9454P 4-го поколения. 48 ядер и 96 потоков, поддержка многопоточности и архитектура Zen 4 обеспечивают максимальную производительность процессора при любых тяжёлых параллельных нагрузках.

AX162-R — это модель с большим объёмом оперативной памяти. В стандартной конфигурации она оснащена 256 ГБ оперативной памяти DDR5 ECC reg, а также двумя твердотельными накопителями Gen4 NVMe Datacenter Edition объёмом 1,92 ТБ, что обеспечивает непревзойденную вычислительную мощность и быстрый доступ к данным. Если вам нужно масштабировать хранилище, выберите AX162-S. В базовой конфигурации она оснащена двумя твердотельными накопителями Gen4 Datacenter Edition NVMe объёмом 3,84 ТБ и 128 ГБ оперативной памяти DDR5 ECC reg.

Вы можете легко настроить выделенный сервер AX162 в соответствии со своими потребностями. Например, можно постепенно увеличивать объём оперативной памяти DDR5 ECC reg до 1152 ГБ. Кроме того, можно добавить накопители, например, до 8 твердотельных накопителей NVMe Datacenter Edition или 2 жёстких диска SATA Enterprise различных ёмкостей.

Вместе с адресом IPv4 стоимость AX162 составляет всего 199,00 евро / 221,00 долл. США в месяц, и во время Черной недели вам не придется платить плату за установку в размере 79,00 евро / 88,00 долл. США!

EX44 с IPv4-адресом может стать вашим всего за 39 евро / 44 доллара США в месяц. Вы сэкономите 39 евро / 44 доллара США на стандартной плате за установку.

www.hetzner.com/dedicated-rootserver/matrix-ax/

OVHcloud заключил неисключительное соглашение с SambaNova. Этот стартап из Кремниевой долины разрабатывает перепрограммируемые чипы для быстрого вывода языковых моделей, при этом потребляя меньше энергии, чем видеокарты Nvidia.

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

Три режима вывода ИИ
Октав Клаба, со своей стороны, выделяет три типа вывода, которые он планирует предложить в OVHcloud. Во-первых, это базовый вывод, который уже доступен широкой публике.

Скоро будут доступны еще два режима.

С 31 декабря пакетный вывод позволит асинхронно обрабатывать большие объёмы данных. И наконец, то, что интересует эту статью: сверхбыстрый вывод, которого ожидают пользователи большинства ИИ-помощников. С таким инструментом, как ChatGPT, вы видите, как буквы формируются прямо на ваших глазах; это просто потрясающеговорит Октав Клаба.

Для пакетного и базового режимов OVHcloud может использовать существующие экземпляры Nvidia: H100, V100S, A10, L4, L40S и RTX 5000. С 30 ноября компания будет предоставлять H200 через свои инструменты искусственного интеллекта. Также планируется запуск RTX 6000 Pro, B200 и B300, но дата выхода пока не объявлена.

Но для высокоскоростного вывода провайдер намерен предложить доступ к стойкам SambaNova.

SambaNova — обещание быстрого вывода с низким углеродным следом
SambaNova, гораздо менее известная, чем Nvidia, — американский разработчик перепрограммируемого чипа, предназначенного для выполнения задач искусственного интеллекта (обучения или вывода). Эти чипы называются RDU (Reconfigurable Dataflow Units).

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

Компания SambaNova, с которой LeMagIT познакомился во время пресс-тура в 2022 году, была основана бывшими сотрудниками Sun Microsystems/Oracle и учёными, окончившими Стэнфорд. В то время компания-единорог уже заявляла, что её технология способна выполнять модели типа GPT с высокой скоростью.

Стойка SambaNovaСтойка SambaNova, сфотографированная в 2022 году


Мы протестировали Cerebras, Groq и SambaNova. Мы пришли к выводу, что SambaNova обеспечивает наилучшее соотношение производительности, цены и занимаемой площади в центрах обработки данныхговорит Октав Клаба

SambaNova удалось разместить 16 чипов SN40L, четвёртого поколения своих 5-нм чипов (производства TSMC), в одной стойке (по 2 RDU на лезвие, 8 лезвий). Для обеспечения эквивалентной вычислительной мощности Groq потребовалось бы 9 стоек, а Cerebras — четыре. «SambaRack» может обрабатывать передовые модели с более чем 400 миллиардами параметров, включая Llama 4 Maverick и DeepSeek R1 (671 миллиард параметров). По расчётам SambaNova, одна стойка может вместить до 5 триллионов параметров.

Ещё одной отличительной особенностью чипа SN40L является наличие 520 МБ кэш-памяти SRAM и 64 ГБ памяти HBM. К нему можно подключить 768 ГБ оперативной памяти DDR4. В общей сложности стойка SN40L-16 имеет 8 ГБ SRAM, 1 ТБ HBM и 12 ТБ оперативной памяти DDR4. По словам Октава Клаба, эта стойка потребляет в среднем 10 кВт (пиковая мощность — 14,5 кВт) и может вместить «десятки» моделей, которые можно сменить «менее чем за 2 миллисекунды». «В то время как с графическими процессорами Nvidia это занимает от 30 секунд до 3 минут». Для сравнения, очень мощная стойка GB300NVL72 (с общим объёмом 40 ТБ HBM3e) потребляет от 130 до 140 кВт, по данным Supermicro.

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

SambaNova заявляет, что с Llama 4 Maverick она может получать более 100 токенов в секунду. С более мелкими моделями, такими как Llama 3.1 8B, эта скорость достигает более 1000 токенов в секунду по сравнению с 1837 токенами в секунду у Cerebras.

Напоминаем, что функция Lightning Speed ​​в приложении Le Chat от Mistral AI реализована на базе чипов Cerebras, установленных в дата-центре в Лас-Вегасе.

Сейчас мы развёртываем первое шасси SambaNova в нашем центре обработки данных Gravelines. Если рынок отреагирует положительно, мы планируем добавить стойки в каждый из наших центров обработки данныхговорит Октав Клаба

Речь идёт не о предоставлении прямого доступа к экземплярам GPU/RPU Nvidia и фреймворкам SambaNova. Вместо этого OVHcloud предоставляет эти вычислительные возможности через свой сервис AI Endpoint. Через API он предоставляет доступ примерно к сорока моделям генеративного ИИ и обработки естественного языка. Эти модели в основном имеют открытый вес.

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

Параллельно французский провайдер разрабатывает OmisimO, ИИ-помощника на базе SHAI, программного агента с открытым исходным кодом для ИИ (Apache 2.0). Идея заключается в том, чтобы способствовать появлению реальных сценариев использования, полезных для бизнеса, таких как ИИ-агенты, подключенные к CRM-системам компаний.

Модель ценообразования для API конечных точек ИИ во многом зависит от скорости отклика. Базовый API, как правило, основан на тарификации на основе токенов. Цена зависит от выбранного уровня LLM (локальное управление жизненным циклом). Для объёмов токенов, обрабатываемых через пакетный API, OVHcloud обещает скидку и возможность планировать запросы вне периодов пикового потребления. Для быстрого API потребуется минимальный ежемесячный взнос, но поставщик гарантирует «сверхвысокую пропускную способность, сверхбыструю доставку и повышенную конфиденциальность». Выпуск этого API запланирован на 2026 год.

Объявление о партнерстве было сделано на следующий день после того, как Nvidia опубликовала результаты за третий финансовый квартал 2026 года.
Продажи Blackwell необычайно высоки, и графические процессоры для облака распроданызаявил в пресс-релизе Дженсен Хуанг, основатель и генеральный директор Nvidia.

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

Правда о графических процессорах H100, купленных три года назад, заключается в том, что они практически бесполезны. Люди постепенно поймут, что инвестиционные циклы для графических процессоров гораздо короче, чем для центральных процессоров. Через 18 или 24 месяца у вас уже есть серьёзные вопросы, которые нужно задать себе. А через 36 месяцев вы теряете почти 80% стоимости
Это объясняет, почему OVH не вкладывает значительные средства в обучение суперкомпьютеров. Провайдеры программ LLM переходят на кодирование с точностью FP4 во время обучения. Графические процессоры H100 не поддерживают FP4. Графические процессоры H200 уже широко распространены; снизите ли вы цену на H100 или потеряете клиентов из-за того, что они будут использовать более дешёвые H200? Проблема в бизнес-моделиобъясняет Октав Клаба

Ввод в эксплуатацию шкафа управления безопасности. Система охлаждения сухих охладителей и чиллеров – NL3 Апелдорн

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

Во время ввода в эксплуатацию наши сервисные партнёры будут присутствовать на объекте для проведения испытаний и ввода системы в эксплуатацию.

Подробности технического обслуживания:
Расписание: 9 декабря 2025 г. с 09:00 до примерно 17:00 по центральноевропейскому времениМестоположение: NL3, Апелдорн, НидерландыОбласть применения: Техническое обслуживание инфраструктуры охлажденияВлияние на обслуживание: среднее (температура подачи может колебаться)Сбой: не ожидается

Мы рады объявить о планах по созданию нового региона Google Cloud в Турции в рамках 10-летней программы инвестиций Google в страну на сумму 2 миллиарда долларов.

Создание этой цифровой инфраструктуры мирового класса в сотрудничестве с Turkcell знаменует собой значительные многолетние инвестиции в ускорение цифровой трансформации в Турции и облачных инноваций во всем регионе.

Партнёрство Google Cloud и Turkcell ещё больше ускорит процесс цифровой трансформации Турции. Оно отражает уверенность мировых технологических лидеров в силе, устойчивости и инновационном потенциале нашей экономики. Интегрируя передовую инфраструктуру данных и облачные технологии нового поколения в нашу цифровую экосистему, этот альянс повысит эффективность и будет способствовать инновациям в государственном и частном секторах. Более того, он поддерживает наше долгосрочное видение укрепления цифрового суверенитета и позиционирования Турции как регионального центра технологий, связи и устойчивого роста. Джевдет Йылмаз, вице-президент Турецкой Республики

Наше партнерство с Google Cloud однозначно укрепляет лидерство Turkcell в цифровой трансформации Турции. Это стратегическое партнерство — больше, чем просто инвестиция в технологии. Это важный этап на пути к цифровому будущему Турции, ускоряющий реализацию нашей национальной стратегии за счет использования глобальных технологий Google Cloud и открытия возможностей для инноваций в области искусственного интеллекта. Это сотрудничество предоставляет нашим клиентам беспрепятственный доступ к передовым возможностям Google Cloud. Новый регион Google Cloud позволит предприятиям быстрее внедрять инновации и конкурировать на мировом рынке. В рамках этого партнерства Turkcell планирует инвестировать 1 миллиард долларов в центры обработки данных и облачные технологиид-р Али Таха Коч, генеральный директор Turkcell

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

Облачные технологии играют важнейшую роль в процессе цифровой трансформации финансового сектора. Благодаря новому региону Google Cloud в Турции, Garanti BBVA сможет повысить свою операционную устойчивость, продолжая внедрять инновации, безопасно внедряя искусственный интеллект и передовые технологии аналитики данных. Это сотрудничество подтверждает нашу приверженность предоставлению клиентам надежных и высокопроизводительных цифровых услуг, гарантируя при этом, что суверенитет данных, конфиденциальность и доверие остаются в основе всего, что мы делаем
Илкер Куруоз, Garanti BBVA

Turkish Airlines, будучи глобальной авиакомпанией, соединяющей Турцию со всем миром, опирается на высокопроизводительные и отказоустойчивые технологии для обеспечения бесперебойного обслуживания клиентов круглосуточно и без выходных. План Google Cloud по запуску локального региона в Турции в сочетании с глобальной сетью компании меняет правила игры для наших полетов, пассажирских систем и приложений, работающих с большими объемами данных. Наличие гипермасштабной облачной инфраструктуры ближе к дому обеспечивает низкую задержку, необходимую для внедрения передовой аналитики, надежных решений по кибербезопасности и будущих возможностей искусственного интеллекта, ускоряя реализацию нашей цифровой стратегии и подтверждая нашу приверженность превосходному обслуживанию
Керем Кызылтунч, Turkish Airlines

Yapı Kredi стремится к постоянным инновациям и модернизации нашей базовой банковской инфраструктуры, чтобы предоставить нашим клиентам безграничный банковский опыт. Планируемый регион Google Cloud в Турции обеспечивает надежную, масштабируемую и безопасную инфраструктуру гипермасштабного облака, необходимую для поддержки наших передовых инициатив в области искусственного интеллекта и кибербезопасности. Это локальное присутствие значительно повысит производительность и гибкость, необходимые для поддержки нашего роста, и позволит нам создавать новое поколение безопасных, в первую очередь цифровых финансовых продуктовГекхан Оздинч, Yapı Kredi Bank

Глобальная сеть облачных регионов Google Cloud, охватывающая 42 региона и 127 зон по всему миру, формирует основу для поддержки клиентов любого масштаба и из разных отраслей. Ведущие организации, от розничной торговли, СМИ и индустрии развлечений до финансовых услуг, здравоохранения и государственного сектора, обращаются к Google Cloud как к своему надежному технологическому партнеру.

Ключевые особенности региона Google Cloud в Турции включают:
Передовые возможности и технологии: В регионе будут предоставляться ведущие сервисы Google Cloud для аналитики данных, кибербезопасности и решений для цифрового бизнеса. Передовые инновации Google в области искусственного интеллекта укрепят цифровую экосистему Турции и позволят предприятиям и государственным организациям работать с большей эффективностью, скоростью и безопасностью.

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

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

Масштабируемость и гибкость по требованию: инфраструктура Google Cloud легко масштабируется в соответствии с потребностями любого бизнеса. Независимо от того, являетесь ли вы небольшим стартапом или крупной корпорацией, вы можете легко адаптировать свои ресурсы к меняющимся потребностям.

Узнайте больше о нашей глобальной облачной инфраструктуре, включая новые и развивающиеся регионы.
cloud.google.com/infrastructure

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

Создание защищенного соединения от рабочего места вашего сотрудника до дата-центра Selectel
Это необходимо для аттестации вашей информационной системы в соответствии с требованиями ФСТЭК и при подключении удаленных администраторов со своих рабочих мест.
selectel.ru/services/additional/gost-vpn/

Почему использовать сервис ГОСТ VPN — выгодно и безопасно

Экономия на оборудовании
Откажитесь от закупки дорогостоящего и узкоспециализированного оборудования, оплаты услуг лицензиатов ФСБ по настройке СКЗИ. Железо и помощь инженеров предоставляем мы.

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

Максимальная защита персональных данных и защита ГИС до К1
Используем аттестованную информационную систему и сертифицированное ФСБ оборудование. Благодаря этому услуга позволяет соблюсти требования приказов ФСТЭК № 21 и 17, а также выполнить требования регламентов государственных систем при подключении к ним подрядчиков.

Легко масштабировать и обслуживать
Можно расширить производительность ГОСТ VPN вместе с ростом проекта.

Решение включает линейку из 51 решений для экспертов и предпринимателей в сфере образования и EdTech.

Российская технологическая компания Рег.ру разработала линейку продуктов, которые упрощают процесс создания и развития образовательного бизнеса «под ключ». Отраслевой набор Рег.решений для сферы образования позволяет в один клик превратить личную экспертизу в образовательный бизнес.
www.reg.ru/solutions/catalog/education

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

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

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

Важной частью запуска Рег.решений стала глубокая сегментация аудитории. Набор разработан с учетом особенностей работы предпринимателей в образовательной сфере и включает 51 решение для 14 различных отраслей. Это позволяет нам точечно работать с нишами — от коучинга и психологии до фитнеса и дизайна. Отдельно в продукте учтены запросы от онлайн-школ и учебных центров
добавляет Иван Грибов.

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

24 октября 2025 SpaceWeb подключил менеджер SSH-ключей для VPS-серверов
Нововведение упростит управление аутентификаций и повысит удобство для веб-мастеров, управляющих сразу несколькими виртуальными серверами.
Хостинг-провайдер SpaceWeb запускает новый инструмент с менеджером SSH-ключей в панели управления VPS для хостинговых и облачных сервисов. Решение разработано для упрощения управления доступами и повышения пользовательского опыта при работе с IT-системами.
Новый сервис помогает управлять безопасностью веб-проектов и упрощает процесс работы с виртуальными средами. Теперь управление хостингом и облаком стало более прозрачным и удобным для пользователей, что особенно важно при работе с большим количеством серверовкомментирует Егор Шилов, руководитель продуктового направления SpaceWeb.
Пользователи смогут генерировать новые SSH-ключи или добавлять уже существующие, настраивать доступы к серверам и управлять их состоянием через удобный интерфейс. Менеджер позволяет отслеживать подключение ключей к серверам и их актуальность всего в пару кликов.

27 октября 2025 SpaceWeb включен в реестр отечественного ПО
Платформа управления облачными сервисами, услугами и хостингом SpaceWeb вошла в реестр российского ПО.
Хостинг-провайдер SpaceWeb получил официальный статус отечественного программного обеспечения на собственные продуктовые разработки. Технологическая платформа компании была внесена в Единый реестр российского ПО Минцифры России.
Хостинговые и облачные сервисы SpaceWeb подтвердили статус официального российского софта. Теперь пользователи смогут выбирать услуги хостера с уверенностью в их полном соответствии законодательным нормам и принципам самостоятельности и независимости.комментирует Алексей Шашкин, коммерческий директор SpaceWeb.
Внесение в реестр ПО открывает SpaceWeb новые возможности для совместных проектов с корпоративными клиентами. Хостинг-провайдер продолжит инвестировать в развитие собственных технологий, чтобы предлагать клиентам современные, безопасные и независимые IT-решения.

07 ноября 2025 SpaceWeb открыл расширенную API-документацию для веб-мастеров
Компания представила новые методы для управления балансировщиками, бэкапами, мониторингом и другими облачными сервисами через API.
Хостинг-провайдер SpaceWeb значительно расширил собственную публичную API-документацию. В открытый доступ выведены методы для управления ключевыми облачными сервисами компании, позволяющие веб-мастерам и DevOps-инженерам проводить более глубокий и детализированный контроль над IT-инфраструктурой.
В документацию добавлены полноценные API-методы для работы с такими сервисами, как балансировщик нагрузки, облачные бэкапы, управление IP-адресами, мониторинг, почта, DBaaS и DNS-управление. Ранее эти функции были доступны только через веб-интерфейс панели управления хостинг-провайдера.
Расширение документации — своевременный и ожидаемый шаг. Конкуренция среди хостинг-провайдеров смещается с цены на удобство и глубину автоматизации. Возможность программно управлять таким широким спектром облачных сервисов, особенно мониторингом и бэкапами, напрямую увеличивает ценность платформы SpaceWeb для технических специалистов, которые строят масштабируемые и отказоустойчивые системысчитает Егор Шилов, руководитель продуктового направления SpaceWeb
Сейчас IT-разработчики смогут осуществлять полный цикл управления: от создания и конфигурирования до масштабирования и мониторинга. А также автоматизировать процессы создания, восстановления и управления политиками резервного копирования, масштабировать системы, настраивать правила фильтрации, выполнять операции с базами данных и управлять DNS-записями.
Открытый функционал поможет пользователям отслеживать метрики потребления ресурсов, интегрировать данные в собственные системы наблюдения, ускорять развертывание и изменения в IT-инфраструктуре.
Мы работаем над следующим этапом платформенного API и движемся к модели, где вся инфраструктура описывается кодом (IaC – Infrastructure as Code). В ближайшем будущем пользователи SpaceWeb смогут легко интегрировать управление своими облачными ресурсами в CI/CD-пайплайны, использовать Terraform и Ansible для полной автоматизации, что значительно ускоряет время вывода IT-продуктов на рынок и повышает надежностькомментирует Виталий Киреев, руководитель отдела исследований и разработок SpaceWeb
Расширение открытой API-документации укрепляет позиции SpaceWeb для технически подкованных клиентов. Пользователи смогут строить более устойчивую, предсказуемую и легко воспроизводимую IT-инфраструктуру, сокращая рутинные задачи и минимизируя издержки человеческого фактора.

10 октября 2025 Новый партнерский статус «Избранный силой»

Один из наших партнеров пересек черту в 1000+ активных клиентов и открыл секретный статус. Это важный рубеж, и мы предложили ему самому выбрать название статуса.
Встречайте — Избранный силой!
Это не просто статус. Это признание того, что можно сделать невозможное.
Теперь этот путь открыт для каждого нашего партнера.
Как работают статусы?
Каждому партнеру присваивается статус в зависимости от количества активных клиентов и отчисляется дополнительное вознаграждение — до 60% от основного.
Как стать Избранным силой: Набрать 1000+ активных клиентов. Всё. Никаких звёздочек и дополнительных условий.
sweb.ru/web/partnerstatus/

30 сентября 2025 Новый тариф VPS — 4 ГБ памяти для вашего проекта

Мы внимательно следим за тем, какие VPS-конфигурации выбирают наши клиенты. И заметили: вариант с 4 ГБ оперативной памяти — один из самых популярных.
Теперь он появился и в готовых тарифах VPS — встречайте Cloud Plus!
Что это значит для вас:
Больше памяти — стабильная работа сайта и приложенийКомфортная скорость даже при росте нагрузкиОптимальное решение для проектов, которым уже тесно на начальных конфигурацияхБольше памяти, быстрый NVMe-диск и стабильный канал 300 Мб/сек — всего от 675 руб./мес.
20 сентября 2025 Новая линейка тарифов Виртуального хостинга

Вега, Электра и Мира
Эти яркие звёзды теперь можно найти не только на небе, но и в нашей новой линейке тарифов.
Объёмный хостинг — это:
Повышенные лимиты нагрузкиВыделенные CPUУвеличенный дискПриоритетная техподдержкаВыбирая один из звёздных тарифов, вы получаете ресурсы выделенного сервера с удобством привычной панели управления.
Эта линейка создана для крупных проектов: интернет-магазинов, корпоративных порталов, сервисов с высокой посещаемостью и сайтов на 1С-Битрикс.
Хотите узнать больше о новых тарифах?
sweb.ru/hosting/

Остин, Техас, 22 октября 2025 г. — Компания Avride, ведущий разработчик технологий автономного вождения, получила стратегические инвестиции и коммерческие обязательства от Uber Technologies, Inc. и Nebius Group.

Общая сумма сделки между Uber и Nebius составляет до 375 миллионов долларов. Она является продолжением коммерческого партнерства Avride с Uber, заключенного после подписания многолетнего стратегического соглашения в 2024 году. Запуск сервиса роботакси Avride на платформе Uber запланирован в Далласе к концу 2025 года. Роботы-доставщики Avride уже выполняют заказы через платформу Uber Eats для сотен ресторанов в Джерси-Сити, Остине и Далласе. Новое финансирование позволит Avride ускорить рост своего парка, поддержать разработку продуктов на основе искусственного интеллекта и расширить свое предложение на новые регионы.

Аркадий Волож, основатель и генеральный директор Nebius Group, сказал:
«Мы рады приветствовать Uber в качестве стратегического инвестора, который разделяет видение Avride и позволит компании двигаться дальше и быстрее в области пионерских разработок в области автономного транспорта на базе искусственного интеллекта».
Сарфраз Маредиа, глобальный руководитель отдела автономной мобильности и доставки Uber, сказал:
«Мы рады дальнейшему углублению нашего партнерства с Avride и с нетерпением ждем возможности представить их впечатляющие технологии автономного вождения большему числу людей на новых рынках».
Дмитрий Полищук, генеральный директор Avride, сказал:
«У нас в Avride есть чёткое видение и чёткий план, как сделать беспилотный транспорт неотъемлемой частью повседневной жизни. Мы очень рады, что у нас есть партнёры мирового уровня, такие как Uber, которые разделяют это видение и продолжают нас поддерживать».

Амстердам, 20 октября 2025 г. — Сегодня компания Nebius представила Nebius AI Cloud в своем новом центре обработки данных ИИ в Израиле, современном объекте, в котором размещено одно из первых в стране общедоступных развертываний графических процессоров NVIDIA Blackwell.

Развертывание позволит местным стартапам, технологическим компаниям и исследовательским институтам получить доступ к передовым вычислительным ресурсам для обучения, тонкой настройки и вывода данных. Оно укрепит цифровую инфраструктуру Израиля благодаря одному из крупнейших в стране облачных развертываний GPU и первому на базе архитектуры NVIDIA Blackwell, включающему 4000 графических процессоров NVIDIA HGX B200, сетевое решение NVIDIA Quantum InfiniBand и доступ к программному стеку NVIDIA AI Enterprise, включая микросервисы NVIDIA NIM и инструменты жизненного цикла агентов NeMo AI.

Развертывание, расположенное на базе колокационного оборудования в Модиине, является частью глобального развертывания ИИ-инфраструктуры Nebius, последовавшего за аналогичными развертываниями в Европе и США. Новая площадка объединяет передовую аппаратную и программную инфраструктуру, включая передовые системы охлаждения, управления энергопотреблением и механизмы контроля данных, разработанные для интенсивных рабочих нагрузок ИИ.

Роман Чернин, соучредитель и главный коммерческий директор Nebius, сказал:
Мы рады сотрудничеству с NVIDIA над созданием вычислительной инфраструктуры, которая будет поддерживать технологическую экосистему Израиля. Израиль зарекомендовал себя как важный центр разработки и внедрения ИИ, особенно в таких областях, как здравоохранение, агротехнологии и кибербезопасность. Наше присутствие здесь позволяет нам тесно сотрудничать с предпринимателями, стартапами, исследователями и лидерами отрасли, которые являются движущей силой этих достижений».
Нати Амстердам, директор NVIDIA в Израиле, сказала:
Запуск Nebius крупнейшего в Израиле облака искусственного интеллекта на базе Blackwell знаменует собой начало развития инфраструктуры искусственного интеллекта в стране. Благодаря суверенному доступу к передовым вычислительным технологиям, сетевым технологиям и программному обеспечению, израильские стартапы, предприятия и исследователи смогут внедрять инновации, внедрять и масштабировать следующее поколение агентного и физического ИИ, укрепляя позиции страны как мирового лидера в области ИИ.
Nebius — партнер NVIDIA по облачным технологиям (NCP) в рамках референсной платформы, предоставляющий услуги с ускорением ИИ на основе референсной архитектуры NCP и обеспечивающий стратегическую ценность и региональное влияние благодаря тесному сотрудничеству с NVIDIA в области поддержки и внедрения. Компания со штаб-квартирой в Амстердаме также входит в число первых NCP, получивших сертификат Exemplar Cloud для учебных рабочих нагрузок на базе NVIDIA H100, продемонстрировав производительность рабочих нагрузок в пределах 95% от референсной архитектуры NVIDIA. Платформа Nebius AI Cloud получила сертификацию SOC2 Type II, включая HIPAA, и обеспечивает сквозное шифрование, а также полное соответствие стандартам защиты данных GDPR и CCPA.

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

В этой статье расскажем, как устроено файловое хранилище RUTUBE с точки зрения SRE, как мы пришли к именно такой конфигурации и как она работает на наших объемах — сейчас это порядка 400 Пбайт или 2 млрд объектов.

Начнём с требований к хранилищу, которые учитывают специфику видеоконтента и архитектуру RUTUBE (кстати, подробнее о ней рассказывается в отдельной статье):
Надёжность — базовое требование к любому хранилищу. Низкая стоимость хранения контента — имеет большое значение, когда речь идёт о таких объемах контента, как у нас.Высокое быстродействие — так как обращение к хранилищу может внести существенный вклад в скорость отклика сервиса, а мы хотим, чтобы пользователь не ощущал задержек, когда выбирает просмотр интересного ему видеофайла. Горизонтальная масштабируемость тоже очень важна на таком объеме хранения. Так как объемы заливаемого видео постоянно растут, нам нужно регулярно вводить в эксплуатацию новые серверы. Когда вы систематически запускаете по 200-250 серверов файлового хранилища за раз, нужно делать это так, чтобы это занимало минимальное количество времени и требовалось как можно меньше ручного труда инженеров.
Далее подробно разберём, как мы обеспечиваем каждый из пунктов, с фокусом на эффективность хранения.

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

Серверы видеохранилища
Какие серверы мы используем для файлового хранилища, как балансируем стоимость хранения и производительность на уровне железа?

HDD vs SSD
Как только появились SSD диски, аналитики начали «хоронить» HDD. Первые успехи в массовом производстве и, как следствие, удешевление SSD давали ощущение, что пройдет несколько лет и жесткие диски вымрут, останутся только SSD. Однако мы все всё ещё в той ситуации, когда стоимость хранения на SSD в 10 и более раз превышает стоимость хранения на традиционных жёстких дисках. Развиваются не только SSD, но и в HDD внедряют новые технологии.



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



Мы отказались от RAID-массивов и любых СХД на серверах видеохранилища. Используем железо любого вендора, но предъявляем два важных требования:
возможность полной настройки, от BIOS и IPMI до установки ОС, с помощью утилит, таких как Redfish, для полностью автоматического ввода в эксплуатацию любого количества серверов;плотность жестких дисков в сервере не менее 36, а по возможности больше.
Объясню на примере, какое значение на наших объемах имеет плотность дисков в сервере. Рассмотрим современный хороший сервер Supermicro, ёмкость которого 90 жестких дисков на 4 юнита.


Если использовать диски по 18 Тбайт, то ёмкость одного сервера будет 1,62 Пбайт.

Соответственно, в обычную стойку на 10 серверов войдет 16 Пбайт. Это почти в 2,5 раза большая плотность по сравнению с более старой конфигураций на 36 дисков, где максимально в одну стойку можно впихнуть 6,5 Пбайт.


Мы сейчас используем в основном диски на 18 Тбайт, но Seagate уже выпустил в продажу 36-терабайтные серверные диски. С ними в одну стойку уже можно уместить 32 Пбайта — то есть всё видеохранилище, накопленное RUTUBE к лету 2025-го, без учёта репликации можно уместить всего в 15 стоек! А раньше это было бы несколько машинных залов.

Почему мы здесь вообще считаем стойки? Во-первых, их аренда тоже стоит денег: средняя цена по рынку где-то 140 тысяч рублей в месяц. В нашем примере при хранении 16 Пбайт на серверах по 90 дисков вместо 36 экономия получится 210 тысяч рублей в месяц. Не столь заметно для большой компании, но это ещё не всё.

Во-вторых, давайте рассчитаем стоимость железа на примере тех же серверов Supermicro 12-го поколения. С одной стороны, сама платформа на 90 дисков почти в два раза дороже, с другой — требуется 10 серверов, а не 25 (для ориентира используем цены европейского поставщика, потому что в России логистические факторы вносят существенные коррективы).


Даже при более дорогой платформе разница на эту ёмкость составит 34% или 36755 €.

Ниже расчёт для полной комплектации серверов со всем железом на платформе одного поколения — здесь разница составляет 21% и больше 128870 €.


Серверное ПО
На серверах видеохранилища RUTUBE стоит:
Rocky Linux — дистрибутив, который появился как форк Red Hat Enterprise Linux и должен быть на 100% с ним совместимым. Angie — nginx-совместимый форк, который имеет дополнительные плюшки, например, в виде возможности получения конфигурации сервера и статистики по API и большого набора уже собранных сторонних модулей. Модуль Kaltura для адаптивного видеостриминга.FileHeap — самописное ПО, о котором поговорим дальше.
Указанные характеристики позволяют нам не испытывать каких-либо проблем с производительностью на серверах видеохранилища. Пиковый трафик отдачи RUTUBE составляет примерно 7 Тбит/с, однако он распределяется по CDN (подробнее о CDN RUTUBE читайте в отдельной статье), а нагрузка по сети на один сервер весьма разумная.

Ниже пример графика скорости отдачи непосредственно из файлового хранилища, для наглядности с достаточно слабого старого сервера.


Нагрузка на процессор (старого сервера с однопроцессорной конфигурацией) в пике составляет 40%, обычно меньше.



FileHeap
RUTUBE создавался в 2006 году. Тогда ещё не существовало хороших общепринятых готовых решений для файлового хранилища, Amazon S3 и Ceph появились позже. Поэтому видеохранилище создавалось логичным и доступным тогда способом — с нуля самостоятельно, ориентируясь на основную задачу, то есть хранение видео для видеохостинга.


Наше ПО управления хранилищем называется FileHeap. Оно написано на Python, для хранения всех объектов используется RabbitMQ и PostgreSQL, для кеша — Redis. Это хранилище разработано специально для хранения видео, оптимизировано под него и ни для чего другого не используется.

Рассмотрим основные задачи FileHeap.
Управление хранилищем контента — стандартный необходимый набор админских функций: добавлять и удалять серверы, регулировать количество репликаций, добавлять и удалять пользователей и так далее. Загрузка/удаление контента в хранилище. Основная функция для любого файлового хранилища — загрузка файлов и их удаление.Получение сведений о контенте в хранилище — его хэш-суммы, даты и всей информации о файле, которая нам необходима. Раздача контента клиентам. FileHeap на самом деле ничего не раздаёт пользователям, он лишь сообщает сервису балансировки, где находится видео, на каком сервере его необходимо найти: в основном видеохранилище или в реплике на CDN-серверах. На основании чего уже балансер генерирует манифест для потока и отдаёт его на клиент. Актуализация storage — постоянный процесс поддержания необходимого количества активных актуальных реплик (напомним, у нас их две). Валидация storage — постоянный процесс проверки на ошибки доступности жестких дисков непосредственно на сервере. Если что-то выходит из строя, FileHeap сразу же узнаёт об этом через RabbitMQ, автоматически запускается система создания активных реплик на других дисках или серверах. Балансировка storage — процесс перемещения реплик по серверам хранения для равномерного распределения нагрузки на них. Обычно мы добавляем сервера большими пачками, например, по 200 новых за раз. Чтобы не влиять на производительность хранилища, переносим данные в фоновом режиме, когда нагрузка на существующие серверы минимальна. Так постепенно контент размазывается по серверам, что позволяет равномерно балансировать нагрузку между ними. Check online storage — процесс проверки реплики на доступность. Сервер хранилища может даже быть жив, но потерять сетевую связность с CDN — мы это тут же увидим на мониторинге, а балансировщик будет создавать манифест с живыми серверами, чтобы пользователи ничего не заметили.
Ниже схема взаимодействия видеосервисов. В рамках этой статьи не будем углубляться во все элементы (напишите в комментариях, что стоит раскрыть подробнее в следующих материалах), здесь нас интересует хранилище, в том числе то, как видео в него попадает.



Как видео попадает в видеохранилище
Пользователь может залить видео практически в любом формате и любом качестве. Мы поддерживаем upload для: MP4, AVI, WMV, MOV, FLV, MPEG-1, MPEG-2, MPEG-4, MPG, MPEGPS, 3GPP, WebM, DNxHR, ProRes, CineForm, HEVC (H.265). Загруженное видео нам нужно преобразовать в формат, который мы потом сможем показать на всём многообразии пользовательских устройств. Соответственно, перед тем как положить видео в основное видеохранилище, нужно его перекодировать (у нас основной кодек H.264) и нарезать в разные качества для адаптивного стриминга (поддерживаем от 144p до 8К).

Разберём этот процесс по шагам.


Данные от пользователя загружаются на upload-серверы, которые представляют из себя, по сути дела, просто серверы временного хранения, но с очень быстрыми NVMe-дисками. Их не очень много и их основная цель — максимально быстро получить контент от пользователя и начать обработку.Как только видео заливается на upload, оно отдаётся на сервер транскодирования, который у нас называется WatchDuck. Каждое видео нарезается во все поддерживаемые качества (ниже исходного) и в нужном кодеке отправляется в FileHeap.FileHeap раскладывает все экземпляры видео во всех качествах по двум серверам видеохранения обязательно в двух разных дата-центрах.
Особенности хранения очень большого количества файлов
Как мы видим, видео хранится во многих качествах, то есть 400 млн единиц контента превращается примерно в 2 миллиарда объектов хранилища. Это может стать проблемой, если не учесть одну особенность устройства файловых систем, про которую нередко забывают в современной разработке. Возможно, потому что люди всё реже работают на низком уровне, а всё чаще оперируют абстракциями типа контейнеров.

Представьте: проект тестировали на dev, всё было хорошо, всё работало быстро. Отдали на прод, и через какое-то время производительность очень деградировала или и вовсе проект перестал работать. Что случилось?

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


На 10-20 тысяч файлов — а dev за эти рамки обычно не выходит — всё замечательно работает. Далее проект выходит в продакшен, несколько недель нормально функционирует, бакет заполняется, и начинается резкая деградация скорости ответа MinIO. По достижении примерно 100 тысяч файлов (зависит от файловой системы на серверах) система полностью выходит из строя и уже не отдает ничего. Причем быстро это исправить проблематично.

Чтобы предотвратить подобное поведение, давно придумали хеш-структурированное хранение. Работает следующим образом: берётся, например, хеш-сумма файлов (мы вместо хеш-суммы используем UUID), создаются папки и подпапки по значениям последних символов хеш-суммы, файлы раскладываются в соответствующие подпапки — ни одна директория не переполняется.


Глубина вложенности может быть 2 или 3, при этом используется 4 или 6 последних символов хеш-сумм (или UUID, как в нашем случае). При вложенности 2 получается, что будет создано (16*16) ² = 65536 поддиректорий. При вложенности 3 получится уже ≈16 млн поддиректорий.

Для наглядности рассчитаем подходящую глубину вложенности в случае видеохранилища RUTUBE. На диски по 18/36 Тбайт, которые мы используем, помещается порядка 100 000 файлов — видео тяжелые и в среднем занимают несколько сотен мегабайт. При глубине вложенности 2 получится по 5-10 файлов в директории — это нам подходит. Если сделать глубину вложенности 3, то можно разложить 1 млрд файлов (примерно по 60 файлов в каждой директории). Таким образом можно в тот же самый бакет заливать сколько угодно файлов, просто регулируя глубину вложенности по папкам.

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

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


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

Существует два основных протокола адаптивного видеостриминга: HLS (HTTP Live Streaming, разработан Apple в 2009) и DASH (Dynamic Adaptive Streaming over HTTP, разработан рабочей группой MPEG в 2011 году). Они отличаются способами организации манифеста, но базово устроены похоже и вы точно сталкивались с их работой. Именно они отвечают за то, чтобы, если у пользователя ухудшилось качество связи, воспроизведение не прервалось, а просто уменьшить разрешение видео.

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

Чтобы на лету нарезать нужные фрагменты, мы используем nginx-модуль vod от компании Kaltura. Он читает исходный mp4-файл и динамически его сегментирует в нужный протокол: HLS (.m3u8 + .ts) или DASH (.mpd + .mp4).

Ниже короткие примеры конфигурации:
location /hls-vod/ { alias /media/; vod hls; vod_bootstrap_segment_durations 2000; vod_bootstrap_segment_durations 2000; vod_segment_duration 4000; vod_base_url "$video_id.mp4/"; vod_mode local; hls_metadata_cache 16m; vod_align_segments_to_key_frames on; vod_hls_segment_file_name_prefix "segment"; vod_manifest_segment_durations_mode accurate; } location /dash-vod/ { alias /media/; vod dash; vod_bootstrap_segment_durations 2000; vod_bootstrap_segment_durations 2000; vod_segment_duration 4000; vod_align_segments_to_key_frames on; vod_manifest_duration_policy min; vod_dash_manifest_format segmenttemplate; vod_dash_profiles urn:mpeg:dash:profile isoff-live:2011; vod_base_url "$video_id.mp4/"; }
Здесь созданы две локации, где в качестве root мы указываем одну и ту же папку с одними и теми же видеофайлами. При обращении к одной пользователь будет получать манифест DASH, к другой — HLS. Из основных параметров — длина чанков, и для разных форматов стриминга она может быть задана по-разному.

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

Пример запроса от плеера за HLS:

/hls-vod/0x5000c500c32ab248/77/ec/a8ae0fb363484dc180705b8a5dbc77ec.mp4/index.m3u8

Пример запроса от плеера за DASH:

/dash-vod/0x5000c500c32ab248/77/ec/a8ae0fb363484dc180705b8a5dbc77ec.mp4/manifest.mpd

А ещё vod-модуль позволяет на лету генерировать превью (thumbnails) — то есть картинку из видеофайла как стоп-кадр по временной метке в миллисекундах. Зачем это нужно? Во-первых, для перемотки по таймлайну, чтобы пользователь на миниатюрах видел, куда перетаскивает курсор. Во-вторых, для создания обложек. Авторы, которые заливают видео на RUTUBE, могут загрузить свою обложку, а могут использовать любой стоп-кадр, который и будет показываться на главной странице.

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

Выше на графике скорость раздачи со всех вместе взятых серверов файлового хранилища. Пик нагрузки составляет ≈525 Гбит/с при общем трафике нашей платформы около 7Тбит/с. Это значит, что большая часть раздачи происходит с CDN-серверов, из хранилища забирается только незакешированое по CDN видео.

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


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

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

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

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

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

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

Как взаимосвязаны эти приоритеты и в чём проблема:
Раздавать видео по всей нашей большой стране и за её пределы из одного хранилища, очевидно, не быстро — пинг от Москвы до Владивостока около 100 мс. Некоторые видео популярнее других, то есть одновременно их хотят посмотреть очень много пользователей. Если показывать такие видео напрямую из видеохранилища, это не будет надежно — потому что вся нагрузка пойдет на один сервер, серверу может стать плохо и «кина не будет».Чтобы раздавать контент быстро, надо его разместить как можно ближе к зрителю. Но с учётом размера нашей библиотеки мы не можем её всю разложить по всем точкам присутствия пользователей — это будет неэффективно.
Решением этой задачи, как понятно из названия, является CDN — Content Delivery Network. Далее в статье сначала определим особенности нашего контента и то, какие требования к CDN в связи с этим возникают, а потом будем искать способы им соответствовать.

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


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



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

Два уровня кэширования
Для эффективного и быстрого доступа к горячему и холодному контенту соответственно выделим в CDN два вида кэша: L1 для холодного и L2 для горячего.


Исходный контент находится в видеохранилище. Далее разместим L1-кэш — уровень, который предназначен для холодного контента, ближе к хранилищу и с прямым доступом к нему. А L2, то есть горячий кэш, расположим как можно ближе к зрителям, в том числе в регионах. При этом, как показано на схеме, у региональных CDN-серверов с горячим контентом нет доступа в основное видеохранилище, вместо этого используется L1 для подкачки на уровень L2.

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

Ниже в таблице характеристики серверов для раздачи горячего и холодного контента. Для горячего L2-кэша в среднем не требуются очень производительные серверы и скорости отдачи в 20-40 ГБит/с обычно достаточно, зато их нужно много. L1 же прокачивает через себя больше контента, так как является промежуточным звеном и обеспечивает доступ к тому самому длинному хвосту из миллионов видео. Поэтому холодные серверы обычно мощнее и оснащены сетевыми картами на 100 или 200 Гбит/с.

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



Как раздать 200 Гбит/с с одного сервера
Если просто взять сервер, вставить в него сетевую карту на 200 Гбит/с, то, к сожалению, без дополнительных усилий скорость отдачи будет намного ниже. Чтобы утилизировать всю пропускную способность сетевой карты, нужно знать, что такое NUMA — Non-Unified Memory Access.

Идея состоит в следующем: когда на сервере несколько процессоров, то скорость их доступа к разным областям памяти отличается. Потому что часть RAM для процессора будет локальной и соответственно более быстрой, а к другой он будет обращаться через шину (это называется interconnect), то есть медленнее. Ниже иллюстрация принципа работы NUMA.


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

К счастью, для сетевых карт Mellanox, которые мы используем, уже есть специальные скрипты, которые позволяют настроить NUMA (см. github.com/Mellanox/mlnx-tools). Скрипты имеют возможность выбора профиля: minimum latency предназначен для оптимизации задержек, а high throughput — для максимальной пропускной способности. Нас в данном случае интересует максимальная пропускная способность.

Кэширование
Разберём, как разложить контент по кэширующим серверам. Теоретически можно, например, с помощью rsync копировать видео из хранилища. Это даже будет работать, но придется городить целую схему, чтобы обеспечить эффективность и надёжность. Поэтому у нас кэширование организовано в обратную сторону: вместо того чтобы нам закачивать на CDN-серверы какие-то файлы, CDN сам скачивает нужные данные из хранилища по мере надобности при помощи обратного проксирования.

Мы используем nginx proxy_pass для скачивания и, что логично, делаем и proxy_cache, чтобы сервер складывал то, что скачал, в свой кэш. Также мы разделяем контент на чанки по 4 секунды, то есть скачиваются не сразу гигабайтные видеоролики, а чанки в несколько мегабайт.

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

В зависимости от этого параметра контент будет попадать на диск только после нескольких обращений за ним.

Распределенное кэширование
На CDN-серверы под кэш мы ставим обычно 8-32 диска, но не объединяем их в общий RAID. Потому что, если вдруг RAID развалится, то потребуется долгая процедура rebuild. Вместо этого можно использовать такой трюк:
proxy_cache_path /media/d0 keys_zone=d0:512m levels=2:2:1 use_temp_path=off; proxy_cache_path /media/d1 keys_zone=d1:512m levels=2:2:1 use_temp_path=off; proxy_cache_path /media/d2 keys_zone=d2:512m levels=2:2:1 use_temp_path=off; proxy_cache_path /media/d3 keys_zone=d3:512m levels=2:2:1 use_temp_path=off; proxy_cache_path /media/d4 keys_zone=d4:512m levels=2:2:1 use_temp_path=off; proxy_cache_path /media/d5 keys_zone=d5:512m levels=2:2:1 use_temp_path=off; split_clients $request_uri $disk_cache { 16.66% d0; 16.66% d1; 16.66% d2; 16.66% d3; 16.66% d4; 16.66% d5; * d0; }

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

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

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



Распределенное кэширование устроено так, что каждый запрос, попадающий в nginx, проходит две стадии:
балансировка с consistent-hash, непосредственно кэширование.
Таким образом, даже если запросы приходят от разных серверов, они попадают всегда на один и тот же кэш-сервер и дублирование не происходит. Сплошное пространство кэширования помогает эффективнее использовать ресурсы и обеспечивать большой объем закэшированного контента. Например, на площадке в Москве мы рассчитываем получить 10 Пбайт кэша.

На самом деле в качестве веб-сервера мы используем не nginx, а Angie — форк nginx от его бывших разработчиков. В Angie из коробки есть полезный нам расширенный мониторинг, а также там уже собраны некоторые сторонние модули, которых нам не хватает для nginx.
Поиск ближайшего сервера
После того, как мы разложили видео по горячим и холодным кэшам, нужно адресовать запрос от пользователя на правильный сервер так, чтобы:
это был ближайший сервер, то есть чтобы было быстро; сбалансировать нагрузку, чтобы это было надёжно;и при этом эффективно расходовать сетевые ресурсы.
Для выбора ближайшего сервера существует BGP Anycast.


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

Сделать Anycast достаточно несложно, нужно:
купить сеть, которую мы будем анонсировать;поставить на сервер демон маршрутизации, мы используем bird;всё, profit.

Это будет работать, но если что-то в сломается, то починить будет трудно, потому что везде транслируется один и тот же IP-адрес, а значит, трудно локализовать проблему.

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

Чтобы определять ближайший к пользователю сервер с учётом физического расстояния, существует другая технология — GeoIP. GeoIP — это база данных производства компании MaxMind — по сути бинарный файл, который загружается в nginx-модуль. С его помощью в ответ на запрос с IP-адресом nginx возвращает: регион местоположения пользователя, город, а также, возможно, информацию об операторе.

Однако в GeoIP-базе MaxMind есть неточности, причём количество этих неточностей растет, поэтому нам приходится накладывать на неё правки.

Ниже представлен пример корректировки GeoIP-базы:
заводим список, где пишем IP-адреса и то, к какому региону их нужно относить;через директиву geo формируем переменную, которая в ответ на IP-запрос возвращает расположение;делаем map на приоритетное использование региона из нашего списка. # geoip_corrections.conf example 198.51.100.0/24 Moscow; # RFC 5737 TEST-NET-2 # nginx.conf geo $region_name_from_geo { # The variable will be empty if IP address does not match. include geoip_corrections.conf; } # Now we combine region names. map $region_name_from_geo $region_name { # If there is no correction. '' $geoip2_region_name; # And if there is. default $region_name_from_geo; }

Это было бы не такой уж большой проблемой, если бы не влияло на пользователей. Но, к сожалению, о необходимости поправок мы обычно узнаём из обращений зрителей. Как это происходит? Неправильный GeoIP приводит к двум нежелательным ситуациям:
Если определить неправильный регион, то можно направить зрителя не на ближайший сервер. Зритель скорее всего этого не поймёт и не будет жаловаться, но мы же хотели так не делать. Если неверно определить страну, то из-за локальных лицензионных ограничений контент может вовсе стать недоступен для пользователя. Тогда, возможно, он обратится в поддержку, мы всё исправим, но зритель на какое-то время останется без любимого шоу и будет расстроен.
Есть другой вариант GeoIP-базы, но с ними тоже есть свои особенности. Во-первых, в базе MaxMind 32 млн записей, а в geoip.noc.gov.ru — 4,5 млн записей. Допустим, это не так страшно, потому что это записи о сетях и они могут быть разного размера. Во-вторых, в базах различаются названия регионов, например, Chuvashia вместо Chuvash Republic. И третье, что нам действительно мешает перейти на эту базу: порядка 5 млн IP-адресов со всей страны в ней приписаны к Москве. То есть она опять не позволит всегда корректно определять ближайшие кэш-серверы, некоторым зрителям из регионов по-прежнему придется ждать лишнее время, чтобы посмотреть видео на RUTUBE.

Балансировка
Все запросы зрителей за видео идут не напрямую к одному из CDN-серверов, с сначала попадают в наше самописное ПО, которое называется видеобалансер.

Видеобалансер:
определяет, где находится зритель, по GeoIP-базе;учитывает оператора, чтобы раздавать контент по возможности минуя меж-операторские стыки;считает температуру видео, то есть горячий это контент или холодный;мониторит нагрузку на серверы CDN;распределяет зрителей на ближайший свободный сервер, где есть нужный контент.
Ниже скриншот из видеобалансера — у него утилитарный инженерный интерфейс, не самый красивый, но рабочий.


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

Итоговая схема раздачи приведена на схеме ниже.


Когда пользователь открывает плеер RUTUBE происходит следующее:
клиент отправляет запрос за видео в видеобалансер; балансер по GeoIP определяет ближайший к пользователю CDN; балансер знает температуру запрашиваемого видео, он мониторит CDN-серверы и в соответствие с этими данными возвращает мастер-манифест на клиент со ссылками на плейлисты с чанками запрашиваемого видео;по манифесту зритель уже направляется на конкретные CDN-серверы (с учётом всех уровней кэширования, которые мы рассмотрели ранее).
Edgestat на схеме выше — это наш сервис мониторинга, с помощью которого балансер узнаёт о состоянии серверов. Edgestat написан на Go и напрямую из псевдо-файловой системы /proc собирает параметры производительности процессора, сети и пр. Ниже пример файла, который модуль мониторинга возвращает в балансер:
{ "net": { "tx_bytes": 3070389798640361 }, "cpu": { "user": 821038789, "nice": 7206904, "system": 1068090496, "idle": 8891017069, "iowait": 140402173, "irq": 183963736, "softirq": 1899188205, "steal": 0, "guest": 0, "guest_nice": 0 }, "tcp": { "out": 4009339463073, "retrans": 107337952956 }, "pressure": { "cpu": 0.42, "io": 1.77, "memory": 0.77, "irq": 1.7 } }

Разберем подробнее блок «pressure». Pressure Stall Information — подсистема внутри Linux-ядра, которая отслеживает задержки в работе системы, связанные с нехваткой железных ресурсов, таких как CPU, устройств ввода-выводы, память.

По меркам ядра PSI появилась относительно недавно, около 7 лет назад. А также буквально пару лет назад — совсем новинка — в неё добавили отслеживание задержек по обработке прерываний — IRQ (значения в микросекундах).

Мониторить irq особенно полезно на серверах, обрабатывающих много трафика, так как в таких условиях обработка прерываний от сетевой карты уже может вносить существенный вклад в общую производительность.
$ ls /proc/pressure cpu io irq memory $ cat /proc/pressure/io some avg10=2.50 avg60=2.38 avg300=2.34 total=13968383315 full avg10=2.35 avg60=2.22 avg300=2.15 total=12888830571 $ cat /proc/pressure/irq full avg10=0.64 avg60=0.36 avg300=0.24 total=7294258624 $

На серверах, прокачивающих большой трафик, например, как у нас в Тбит/с, показатель irq pressure часто скачет и сообщает нам, что сервер перегружен, даже если этого не видно по другим характеристикам. Внедрение PSI помогло нам окончательно избавить CDN от тормозов — повысить скорость.

Для обеспечения дополнительной надёжности в схеме раздачи в мастер-манифесте содержится не один, а два CDN-сервера: основной и резервный. Мастер-манифест — это по сути плейлист из плейлистов, выглядит примерно так:
#EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=478000, FRAME-RATE=25, CODECS="avc1.42c01f, mp4a.40.2", RESOLUTION=256x144 https://cdn-server #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=478000, FRAME-RATE=25, CODECS="avc1.42c01f, mp4a.40.2", RESOLUTION=256x144 https://backup-cdn

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

Сеть
Работа с сетью — также неотъемлемая часть эффективной реализации CDN, ведь на таких расстояниях и объемах трафика сеть легко может стать узким местом.

Ниже неполный вывод команда ip, который показывает список сетевых интерфейсов одного из наших CDN-серверов.
$ ip -c a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: aggr0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:x1 brd ff:ff:ff:ff:ff:ff 3: aggr1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:x2 brd ff:ff:ff:ff:ff:ff 4: aggr2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:x3 brd ff:ff:ff:ff:ff:ff 5: aggr3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond1 state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:x4 brd ff:ff:ff:ff:ff:ff 6: anycast2: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether xx:xx:xx:xx:xx:xa brd ff:ff:ff:ff:ff:ff inet 198.51.100.79/24 brd 89.248.230.255 scope global anycast2 valid_lft forever preferred_lft forever 7: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xb brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/24 brd 192.0.2.0 scope global bond0 valid_lft forever preferred_lft forever 8: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xc brd ff:ff:ff:ff:ff:ff inet 203.0.113.2/24 brd 203.0.113.0 scope global bond1 valid_lft forever preferred_lft forever $

То есть на каждом из десятков CDN стоят серверы с десятками же сетевых интерфейсов — всем этим нужно эффективно и надёжно управлять. Например, везде должны быть правильные согласованные с операторами настройки. Использовать для этого штатный NetworkManager не очень удобно, поэтому мы перешли на systemd-networkd.

systemd-networkd — это демон для настройки сети. Как и всё в systemd, все настройки в нём хранятся в текстовых файлах, что удобно для автоматизации, например, Ansible.

Ниже пример файла .link, который настраивает физические сетевые устройства. В нём задаётся максимальный размер буферов для эффективной раздачи больших объемов трафика.
# /etc/systemd/network/10-aggr0.link [Match] MACAddress=xx:xx:xx:xx:xx:xx [Link] Name=aggr0 RxBufferSize=max TxBufferSize=max
В файле .netdev описываются виртуальные сетевые устройства, например, bond — объединение двух физических сетевых устройств в одно логическое для большей отказоустойчивости или скорости отдачи.
# /etc/systemd/networkd/bond0.netdev [NetDev] Name=bond0 Kind=bond [Bond] Mode=802.3ad MIIMonitorSec=100ms TransmitHashPolicy=layer3+4
Другой пример полезной настройки в .netdev — dummy-интерфейс. По сути это loopback, который мы используем для того, чтобы на него назначать Anycast-адрес. Можно назначить этот Anycast-адрес как второй ip-адрес на сетевой интерфейс, но тогда, если сетевой интерфейс перестанет работать, то и Anycast-адрес перестанет быть доступным.

# /etc/systemd/network/anycast2.netdev [NetDev] Name=anycast2 Kind=dummy

Третий вид файлов systemd-networkd это .network. Они описывают стандартные настройки: IP-адреса, gateway, маршруты и т.д.

# /etc/systemd/network/aggr0.network [Match] Name=aggr0 [Network] Bond=bond0 # /etc/systemd/network/bond0.network [Match] Name=bond0 [Network] Address=12.34.56.78/28 Gateway=12.34.56.79

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


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

Как сделать, чтобы ответ на запрос уходил тому же оператору, от которого он пришел? При помощи fwmark — меток сетевых пакетов. Это виртуальные метки, которые ставятся на сетевые пакеты и при этом существуют в рамках одного Linux-хоста. Они позволяют сделать такой трюк:
chain prerouting { type filter hook prerouting priority mangle; policy accept; iifname "bond0" ip daddr 198.51.100.0/24 meta mark set 0x00000010 accept comment "isp1 fwmark" iifname "bond1" ip daddr 198.51.100.0/24 meta mark set 0x00000020 accept comment "isp2 fwmark" }

Выше представлены правила nftables: на запросы, приходящие через сетевой интерфейс «bond0», ставим на него метку 0x00000010 (неважно какую, важно, что не ноль), а на «bond1» ставим другую метку.

В соответствие с этим прописываем и исходящие правила маршрутизации:
$ ip rule 0: from all lookup local 110: from 198.51.100.0/24 fwmark 0x10 lookup 100 proto static 120: from 198.51.100.0/24 fwmark 0x20 lookup 101 proto static 32766: from all lookup main 32767: from all lookup default $

Здесь в приоритете 110 написано: если запрос с Anycast-адреса и есть метка 0x10, то нужно посмотреть в таблицу номер 100, где будет default gateway для bond0; а если метка другая — то надо смотреть в другую таблицу, где уже будет default gateway для bond1.

Воедино входящие правила фаервола и исходящие правила маршрутизации связывают несколько sysctl:
net.ipv4.tcp_fwmark_accept=1 net.ipv4.fwmark_reflect=1 net.ipv4.conf.all.src_valid_mark=1

Здесь написано следующее: если на сетевой пакет, который пришел на данный сетевой интерфейс, есть метка, то её нужно скопировать на весь сокет и выставлять на все исходящие пакеты в рамках соединения.

Player events
Мы мониторим состояние серверов, но кроме того, для надёжности, плеер пользователя в случае каких-либо проблем научен отправлять специальные сообщения, которые называются player events. Если на клиенте, в вебе, в мобильном или Smart TV приложении RUTUBE возникнут какие-то проблемы с доступом к CDN, то мы узнаем об это по резервному маршруту. Например, сбои в каком-то сегменте сети, дадут всплеску player events и наш мониторинг тут же отреагирует.

И последняя в этой статье оптимизация: простая, но важная. Мы уже говорили, что используем демон маршрутизации BIRD, чтобы анонсировать Anycast. Логично, что тогда должен быть запущен и nginx, чтобы он что-то раздавал. Если запустить bird, но не запустить nginx (а у нас такое бывало), то зрители придут и попадут в черную дыру. Чтобы такого избежать, можно использовать такой трюк:
# /etc/systemd/system/bird.service.d/requisite_nginx.conf [Unit] # If nginx is stopped, bird will be stopped as well. # If nginx is not running, bird will refuse to start. # If bird is stopped, nginx is not affected. # If nginx is restarted, bird is not affected. Requisite=nginx.service

Главное тут в последней строчке: если nginx запущен, то bird работает; если nginx выключить, то bird погаснет; если nginx не запущен, то и bird не запустится.

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

Вот три основных момента, на которые нужно обратить внимание, если вы строите свой CDN:
Если вы только начинаете строить CDN, то начните с BGP Anycast как наиболее простого варианта. Но не ограничивайтесь им и подключайте узконаправленные средства балансировки, подходящие для вашего профиля трафика и нагрузки. Используйте разные источники мониторинга: и изнутри системы, и снаружи.Pressure Stall Information — это ваш союзник в борьбе с тормозами.

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

Взять, к примеру, движки Unreal Engine и Unity: последние несколько лет они предъявляют новые требования к оборудованию, особенно к тактовой частоте. Игры на Unreal Engine часто сильно зависят от производительности одного ядра, где скорость каждого ядра важнее, чем их общее количество. Хотя Unreal Engine 5 делает шаги к лучшему масштабированию многоядерных процессоров, более высокие тактовые частоты по-прежнему обеспечивают бесперебойную работу большинства современных игр.

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

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

Введите AMD
Компания AMD ворвалась на рынок игровых процессоров с Athlon 64 X2 в 2003 году и с тех пор продолжает разрабатывать процессоры для потребительского рынка.

Прошло двадцать лет, и теперь AMD Ryzen — имя, известное геймерам по всему миру (я до сих пор с гордостью ношу 5800x3d).

Итак, когда AMD анонсировала в 2022 году Ryzen 7950X — самый мощный на сегодняшний день процессор потребительского класса — он произвел фурор в отрасли. Будучи частью серии 7000, 7950X обладал 16 ядрами, высокой производительностью в однопоточном и многопоточном режимах и лучшими тактовыми частотами среди всех массовых процессоров на тот момент. Журнал PC Mag далее описал 7950X как «самый быстрый процессор, который можно купить, не перейдя на серверное оборудование».

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

С успехом приходит спрос
AMD знала, что с серией 7000 они на верном пути. Но я уверен, что они не ожидали такого спроса на 7950X во всей игровой индустрии. Процессоры Zen3 EPYC — корпоративная серия AMD — уже существовали некоторое время, но разработки Ryzen в 2022 году быстро превзошли все процессоры, которые студии и хостинг-провайдеры использовали ранее. Очень быстро 7950X превратился из B2C-продукта в B2B-продукт.

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

Фактически, многие наши партнёры — от крупных разработчиков AAA-контента, которых мы поддерживаем напрямую, до компаний частного хостинга B2C и провайдеров управляемого хостинга B2B — уже используют процессоры Ryzen, снижая затраты и получая доступ к более мощным технологиям. Ведущие игровые студии знают, что создание современных игр требует важного сочетания мощных технологий и квалифицированных экспертов по их использованию.

Второй игрок готов
Ryzen 7950X завоевал сердца и умы как потребителей, так и предприятий. Три года спустя он даже возглавил список «Лучшие процессоры AMD 2025 года» по версии TechRadar.

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

В мае 2024 года AMD решила выпустить EPYC 4004 — новую линейку процессоров корпоративного класса, основанную на той же архитектуре Zen 4, что и серия Ryzen 7000. У AMD уже был рецепт успеха с 7950X, поэтому целью EPYC было предложить аналогичные процессоры, но предназначенные для предприятий, а не для потребителей: круглосуточную нагрузку на центры обработки данных, поддержку ECC (памяти с коррекцией ошибок) и зеркалирование памяти для повышения уровня резервирования.

Встречайте EPYC 4564P — флагманский процессор серии 4004, созданный для удовлетворения потребностей бизнеса в процессорах серии 7950X. И, как видите, их конфигурации практически идентичны:


Более того, процессоры EPYC также выигрывают от более низкой совокупной стоимости владения (TCO), поскольку серверы будут иметь корпоративные гарантии, меньше простоев и меньше замен.

Для разработчиков и хостинг-провайдеров взгляды на процессоры изменились. Чистая скорость важна, но не менее важно и то, как она сохраняется со временем, и именно здесь AMD EPYC 4564P блистает. Созданный на той же архитектуре Zen 4, что и Ryzen 7950X, он обеспечивает ту же однопоточную производительность, но оптимизирован для центра обработки данных благодаря функциям надежности, необходимым для непрерывных рабочих нагрузок: высокой степени параллелизма, бесперебойности работы и стабильности.

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

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

Что будет дальше?
За последние четыре года разработчики, издатели, сервисы управляемого хостинга и поставщики частных серверов B2C достигли больших успехов в оптимизации своих многопользовательских игр. Прогресс в разработке игр, похоже, идёт в ногу с развитием игровой инфраструктуры, на которой они размещены, и обсуждение Ryzen EPYC — яркое тому подтверждение.

В то время как AMD Ryzen 7950X продолжает обеспечивать исключительную производительность для геймеров, те, кто арендует серверы у поставщиков, использующих EPYC 4564P, могут рассчитывать на ту же мощность с дополнительными преимуществами корпоративной надежности и эффективности.

На сайте servers.com мы ежедневно наблюдаем эти изменения, работая с хостинг-провайдерами, которым важна стабильная производительность и доступность. Будучи геймером, я понимаю стремление к производительности; моя задача — обеспечить нашим клиентам необходимую производительность и поддержку благодаря инфраструктуре на базе EPYC для бесперебойной многопользовательской игры.

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