Timeweb.Cloud News

Обновления в объектном менеджере S3

Недавно посчитали, что в нашем S3 лежит уже 2,7 млрд ваших объектов, и их становится только больше. Все они защищены тройной репликацией, поэтому остаются доступны даже при отказе отдельных узлов.

Помимо доступности развиваем и сам объектный менеджер — вот что добавили недавно:

1️⃣ Возможность предпросмотра

74 новых формата — видео, текстовые файлы, таблицы, документы и презентации доступны для просмотра прямо в объектном менеджере без скачивания.

Полный список поддерживаемых форматов.

2️⃣ Роль «Чтение и запись»

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

Проверить на своем хранилище →

Апдейты от наших инженеров

Расскажем об инфраструктурных работах в трех направлениях.

1️⃣ Масштабируем сервис сетевых дисков

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

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

2️⃣ Изолируем проблемные ноды в очереди

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

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

3️⃣ Ускоряем создание бэкапов

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

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

И это, конечно, не все. Часть обновлений еще обкатываем — поделимся ими, когда сами убедимся, что все работает стабильно 👌

Туда, где охлаждение умеет резервироваться

Нашей новой локацией для зоны ams-1 станет ЦОД NorthC →

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

Цифры, о которых неприятно говорить

Много вопросов по поводу DDoS. На эту тему у нас много материалов, которыми мы периодически делимся. Сейчас картина следующая:

• В этот сезон мы сталкиваемся с новой атакой широким конусом на 80 000 IP-адресов одновременно, что делает обнаружение заметно более проблематичным. В отдельных случаях, мы говорим о ~2 000 pps на отдельный хост, что очень не просто отличить от фонового трафика.

• Атаки по-прежнему идут преимущественно на L3/4 уровни UDP-флудом, в то время как объем паразитного трафика вырос до ~150 млн пакетов в секунду.

• Волны атак в пике достигают 3 Тбит/с — это беспрецедентный для РФ объем, который становится новой реальностью в 2026 году.

Видим вопросы о том, что мы с этим делаем. Тут правильнее дать слово Максиму Яковлеву, это наш CTO:

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

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

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

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

1️⃣ Инфраструктура в зоне ams-1 полностью восстановлена — с сегодняшнего дня всем клиентам подключен нулевой биллинг до 5 июля включительно, инфраструктура будет полностью бесплатной.

2️⃣ Мы инициировали процедуру переезда в другой ЦОД. Под наши объемы в 65 000 виртуальных машин есть хороший вариант с нужной емкостью по стойкам, но в них нужно нарастить мощности по питанию → для этого совместно с ЦОД будем проводить срочные работы по расширению в ближайшие 2 недели. Также прорабатываем вариант аренды второго ЦОДа в локации, чтобы можно было организовать полноценное резервирование. Реалистичный срок срочного переезда учитывая объемы и регион — месяц.

3️⃣ Для этой локации будет организовано бесплатное бэкапирование в другой регион.

Про перегретый дата-центр

В мае мы рассказывали, как перевезли инфраструктуру в зоне ams-1 из закрывающегося ЦОДа в новый.

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

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

Попытки запустить отказавший чиллер не увенчались успехом. Сейчас ЦОД организовал срочную поставку новых силовых кабелей (вероятно для подключения внешнего чиллера к сети ДЦ) — обещают завтра до 12-14 мск. Параллельно ЦОД привлекает дополнительного профильного специалиста для углубленной диагностики и восстановления узла системы охлаждения, но он будет там завтра утром.

Это не соответствует ни нашим ожиданиям, ни нашим стандартам качества и обслуживания.

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

Писать в саппорт с вопросами по срокам не особо целесообразно, так как мы сами ждем информацию.

Как есть.

Обновили ядро Linux на всех Ryzen-серверах в Москве

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

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

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

Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.

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

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

Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

AI-агенты в связке с Cline, Codex и OpenCode

Наших AI-агентов и AI Gateway можно использовать прямо в инструментах разработки.

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

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

Подключение сводится к трем полям в настройках расширения:

1️⃣Тип провайдера — OpenAI Compatible

2️⃣ Базовый URL агента или AI Gateway

3️⃣ И, наконец, ваш API-ключ.

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

Подробнее о каждой среде в доке → Cline, Codex и OpenCode.

История USmall — хайлоад изнутри

6+ млн товаров, 130 ритейлеров и до 70 млн запросов во время распродаж. Мигрировали USmall в наше облако и записали видеокейс о том, как устроена инфраструктура такого проекта.

Из любопытного:

1️⃣130 площадок — 130 изолированных контуров. На каждую свой репозиторий и Docker-образ. Релизы независимы, все изменения изолированы.

2️⃣ Свой механизм иерархических подов. В основе паттерн одноразовых подов — каждый выполняет один цикл и завершается. Поверх него команда построила иерархию, где родительский под запускает дочерние. Так обходят ограничение Python по пропускной способности одного воркера и обрабатывают задачи параллельно.

3️⃣ Выделенный сервер под оркестратор. Когда Airflow потребовалась отдельная конфигурация, под него собрали сервер на двух 32-ядерных процессорах и перенесли без простоя.

4️⃣ AI прямо в Kubernetes-кластере. В тестовом режиме крутится нейросеть, которая ускоряет подключение новых магазинов.

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

В видео Станислав, руководитель Python-разработки USmall, рассказывает про архитектуру и почему выбрали наше облако.

Смотреть видеокейс на ютубе, рутубе и в вк.

Или читать подробный разбор на сайте →

IPv6 в базах данных

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

Полезно, если:

1️⃣ Уже раскатали IPv6 в своей инфраструктуре и не хотите держать IPv4 только ради базы

2️⃣ Масштабируете проект и постепенно уходите от дефицитных IPv4-адресов

3️⃣ Строите cloud-native или корпоративную инфраструктуру, где важна поддержка IPv6.

Подключается в пару кликов: при создании новой базы или в настройках существующей «Сеть» → «Публичный IPv6-адрес». Если переключателя IPv6 у базы нет — значит, на вашей сети он пока недоступен.

При защищенном TLS-подключении адрес автоматически привяжется к техническому домену базы. Остальные детали в документации →

Фича появилась не случайно — ее давно просили в разделе идей (тут и тут), теперь она в проде.

Привязать айпишник к базе →

Посетили закрытую встречу резидентов и партнеров Иннополиса с участием руководства Татарстана. Обсудили совместные планы и получили неожиданную, но приятную статуэтку (на фото).

Напомним, что осенью прошлого года наш офис переехал в Казань, где мы участвуем в развитии ИТ-среды и выстраиваем сотрудничество с Университетом Иннополис.

Рады, что коллеги отметили нашу динамику ⚡ А ведь времени прошло всего ничего.

Вдохновляет 😎

Хранилище S3-бакетов и сетевых дисков в Петербурге перевалило за 6 петабайт

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

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

Зачем столько копий? Диски — расходник и ломаются без расписания: бывают месяцы без единой замены, а в прошлом поменяли сразу три из 436 накопителей кластера.

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

Что под капотом. Ceph-кластер из 27 серверов с двумя тирами: быстрые NVMe-ноды — под активные данные, емкие HDD — под архивы и объекты, к которым обращаются редко. Между уровнями данные распределяются автоматически.

Кластер растет быстро. В феврале 2024 года в нем было три ноды и 70 терабайт под данные клиентов, сейчас — 27 нод и 2 петабайта. В 30 раз больше за два с половиной года.

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

6 петабайт — не предел. Про новые отметки расскажем в следующих постах.

Запустили мониторинг сервисов

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

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

Что можно мониторить:

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

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

TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.

SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.

Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.

Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации →

Стоимость — 30 ₽ в месяц за сервис, списания почасовые.

Подключить мониторинг →

Закладываем запас прочности

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

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

1️⃣ Защитили исходящие запросы ваших серверов

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

Развернули резолверы по схеме anycast: запрос уходит на ближайший доступный узел → нагрузка распределяется между всеми. Атака на один узел не выводит DNS из строя — остальные продолжают отвечать, и приложения работают стабильно.

2️⃣ Отвязали данные от конкретного хоста

Внедряем сетевое хранилище NVMe-oF вместо локальных дисков. Начали с Москвы, постепенно раскатываем дальше.

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

3️⃣ Сделали миграцию виртуальных машин универсальной

С ростом числа клиентских конфигураций уперлись в корнер-кейсы — на некоторых миграция могла подвисать или требовать остановки сервера. Теперь переносим серверы быстро и без даунтайма в любом конфиге. Обычно в трех сценариях:

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

Главная идея — закладывать запас прочности, чтобы инфраструктура справлялась и с текущим ростом, и с нештатными ситуациями.

P.S. Инженеры уже пишут статью на Хабр про факапы и победы в росте инфраструктуры. Пишите в комментариях, что хотите там увидеть — разберем.

Тестируем 8 серверов в одном шасси

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

В новом видео Влад Олейник, ведущий инженер ЦОД, рассказал про 3-х юнитовый Microcloud компании Supermicro 3015MR с приставкой H8TNR.

В одном 3U-шасси умещается 8 полноценных серверов вместо классической схемы 1 сервер = 1 юнит. Все ноды изолированы друг от друга, а общими остаются только питание и охлаждение.

Универсальное ли это решение? Нет — поэтому покажем, где такая сборка особенно полезна:

1️⃣ 1С (SQL + App). Производительность 1С часто упирается в частоту процессора, а десктопные Ryzen как раз обеспечивают 5+ ГГц.

2️⃣ Frontend-сборка. На высокочастотных процессорах сборка может идти в 1,5–2 раза быстрее, чем на многих серверных Xeon.

3️⃣ Build-фермы. Разные типы лезвий можно подбирать под задачи CI/CD. Конфигурации с десктопными AMD-процессорами ускоряют этапы сборки, требующие высокой однопоточной производительности.

Посмотреть видео можно на ютубе, рутубе и в вк.

Поручить работу с сервисами своему AI-агенту

Чтобы поднять сервер, базу и бакет под новый проект — можно просто создать AI-агента в связке с Timeweb Cloud MCP. Пишете агенту, что нужно, он запрашивает подтверждение и после вашего разрешения берется за работу.

Причем наш MCP можно подключить и к стороннему агенту — например, Cursor, Claude или своему боту. Подробнее про подключение → в доке.

Из последних апдейтов — открыли для MCP почти весь публичный API. Доступны все методы, кроме удаления, добавим их позже.

Что вы можете поручить агенту в связке с Timeweb Cloud MCP:

Запустить инфраструктуру с нуля

Создай сервер на Ubuntu 24.04 с 4 ГБ RAM в Москве для тестов

Мониторить работу

Покажи список серверов и их статус, а еще оцени состояние кластера

Собрать контур под проект

Создай балансировщик и добавь в него 2 сервера, а потом настрой приватную сеть между ними

Запустить AI-агента с поддержкой MCP →