Рейтинг
0.00

TimeWeb Хостинг

3 читателя, 81 топик

Обновления



https://timeweb.cloud

31 июля 2026 Новые правила для владельцев доменов .ru,.рф и .su
Ситуация: с 1 сентября у всех регистраторов доменов .ru.рф и .su должна быть кнопка идентификации владельца, которая подтягивает данные через ЕСИА.
Видим, что вы переживаете, а где же эта кнопка у нас. Актуальный статус одной строкой — кнопка есть, но скрыта.
Мы ждем финальный ОК от профильной организации — обещают в ближайшие недели. Кнопка появится в панели сразу после подтверждения.
Сложность вот в чем:
1. Компании, которые подключали ЕСИА по своей инициативе еще до принятия 569-ФЗ, делали это по упрощенной процедуре.
2. Сейчас процедура не упрощенная. Нужно не просто нарисовать кнопку и подключить через API, но и обеспечить много чего еще. Например, согласовать все этапы с регулятором и докупить оборудование.
Добавим контекст — С 1 сентября 2026 владельцы доменов .ru.рф и .su, должны будут проходить официальную идентификацию через ЕСИА. Проще говоря, подтверждать свою личность через Госуслуги. Этого требует новый ФЗ №149.
Без подтверждения станет невозможно регистрировать новые домены, продлевать старые, передавать на них права, менять NS-серверы и регистратора.
Вы можете не ждать кнопку, если ваши регистрационные данные совпадают с Госуслугами. Если нет — вам нужно самостоятельно их актуализировать. Кнопка лишь сверит эти данные и, если они не совпадают, вернет ошибку.
Единственное, что вы можете сделать, это продлить или зарегистрировать домен до 1 сентября 2026 года. Однако когда срок подойдет к концу вам все-равно потребуется пройти идентификацию.

30 июля 2026 Вернули регу в СПб
Можно успеть, пока снова не разобрали. Заказать облачный сервер.
Kubernetes, Managed Databases, S3 и App Platform в этой локации тоже в строю.

29 июля 2026 Запросы к российским API без ошибок TLS
Многие российские сервисы работают на сертификатах Минцифры (Russian Trusted CA). Только у приложений их по умолчанию нет, а если их не добавить — соединение обрывается с ошибкой проверки.
Теперь в App Platform можно включить поддержку сертификатов Минцифры — сразу при создании приложения или в настройках уже существующего.
Что дают сертификаты:
1. Приложение обращается к российским API без ошибок TLS
2. Не нужно дописывать установку сертификатов в сборку и следить за ней при обновлениях
3. Проверка сертификатов остается включенной, а соединение защищено
— В бэкенд-приложениях сертификаты автоматически попадают в доверенное хранилище.
— В Docker-приложениях их нужно включить в список доверенных самостоятельно. Пошаговая инструкция есть в документации.

22 июля 2026 Пак обновлений в AI Gateway разблокирован
Но сначала о другом. На днях опубликуем на Хабре исследование о том, сколько запросов к нашей доке приходит от AI-агентов. Спойлер: много!
А теперь о двух важных релизах в AI Gateway:
1. Новые модели OpenAI: речь и изображения
Добавили модели для синтеза и распознавания речи — GPT-4o mini TTS, GPT-4o mini Transcribe и GPT-4o Transcribe, а для генерации изображений — GPT Images 2.0.
Голосовые интерфейсы, транскрибация звонков, картинки для продукта — теперь доступны без отдельных интеграций через AI Gateway.
2. Модели в контуре российской инфраструктуры
Для проектов, которым важно соблюдать 152-ФЗ: добавили модели, которые работают в РФ — без трансграничной передачи данных. В панели они собраны под фильтром «Локальные».
В списке: Qwen 3 235B Instruct, Qwen 3 Coder 480B A35B, DeepSeek R1 Distill Qwen 32B, Kimi K2 Instruct, Kimi K2.6, GLM 4.6 357B, GPT OSS 120B.
Пока эти модели доступны в AI Gateway — в AI-агентах появятся немного позже.

21 июля 2026 Меняем архитектуру взаимодействия сервисов

Начнем с самого заметного: стандартный облачный сервер теперь создается в среднем за 30 секунд — от клика на кнопку до готовой машины.
За этим стоит смена архитектуры. На каждом гипервизоре теперь работает свой агент: центральное API ставит задачу → агент выполняет ее на месте и сразу отчитывается.
Цепочка каждой операции стала проще, а независимые процессы идут параллельно, а не по очереди.
И эта схема прозрачная: каждый шаг создания сервера виден на графиках. Если что-то начинает замедляться или сбоить, мы сразу замечаем это по данным — и чиним точечно, а не ищем по всей цепочке.
Что дальше. Переводим на новую схему остальное: управляемые базы данных, серверы с Windows, установку из образов.
Это часть инфраструктурных работ, о которых рассказываем в последних постах: меньше ручных операций, больше автоматики и метрик.

17 июля 2026 Обновленный интерфейс доменов в App Platform
Последние недели разбирали техдолг, чтобы сервисы работали быстрее и предсказуемее. Большая часть работ незаметна снаружи, но одно обновление вы увидите сразу — в доменах App Platform.
Домены — очень чувствительный узел: ошибка в привязке, и приложение не откроется у ваших пользователей. Раньше редактировать их приходилось на отдельной странице, в отрыве от остальных настроек приложения.
Теперь сценарий другой: открываете вкладку «Домены» в настройках приложения → выбираете уже добавленный домен или вводите внешний → «Сохранить» → готово, приложение доступно по домену.
Подробнее о привязке timeweb.cloud/docs/apps/upravlenie-apps-v-paneli#privyazka-domena
1. Домен уже занят другим сервисом? Предупредим об этом заранее — и после сохранения сами перепривяжем его на нужное приложение.
2. Добавляете внешний домен? Подскажем нужный IP прямо в окне — вам останется добавить A-запись у своего регистратора.

16 июля 2026 Ваш агент может в разы больше, чем вы думаете
Агент, конечно, может подсказать вам команду, но выполнять ее все равно придется руками. С MCP-сервером иначе: подключаете один раз — и агент действует самостоятельно.
Самое приятное: интеграцию под каждый инструмент писать не нужно. Достаточно взять из галереи:
1. Для разработки — Context7. Попросите обновить зависимости под Next.js 14 → агент возьмет доку 14-й версии, а не из 12-й, которую запомнил при обучении.
2. Для инфраструктуры — Timeweb Cloud MCP. Даете команду развернуть сервер, проверить статус кластера или посмотреть баланс → агент запросит разрешение и выполнит все необходимые действия.
3. Для бизнес-задач — Яндекс Поиск, amoCRM, Контур.Фокус, Bitrix24 и VK Реклама → агент сам найдет нужное в сети, обновит CRM или подтянет статистику кампаний.
А если нужного сервиса нет — любой удаленный MCP-сервер подключается вручную. Например, Google Drive для ответов с опорой на документы с диска или MySQL для запросов к базе прямо из диалога. Подробнее о подключении → в документации

15 июля 2026 Набрали 1165 баллов в новом рейтинге CNews
Сегодня даже стартапу легко доступны те же управляемые сервисы, что и крупным компаниям: Kubernetes, хранилище S3, и базы данных с бэкапами. Если раньше было четкое разделение: «облако для больших» и «облако для маленьких», то теперь это просто инструмент. И главные требования к нему — легко встраиваться в процессы и быть удобным для команды.
Как раз это и учитывал CNews в своем первом рейтинге облаков для малого и среднего бизнеса — и мы заняли в нем первое место.
Максимум баллов набрали в четырех направлениях:
1. Стек управляемых сервисов — за функциональность баз данных, Kubernetes и S3
2. Панель управления — потому что все под рукой с интерактивными дашбордами и сквозным поиском по инфраструктуре
3. AI-агенты — за выбор инструментов для бизнеса: OpenAI-совместимый API, подключение MCP-серверов и множество моделей
4. Цены — одни из самых доступных на рынке
Кажется, рынок наконец определился, что небольшим командам нужно от облака: управляемые сервисы, готовые AI-решения и комплексная поддержка для бизнеса.

14 июля 2026 Подборка под ваш кластер
Kubernetes и так мощный оркестратор, а с нужными аддонами дорастает до полноценной продакшен-среды. На основе статистики ваших установок собрали пять задач, которые можно закрыть аддонами:
1. Envoy Gateway — принимать весь трафик через одну точку входа
Разводит входящие запросы по сервисам — не нужно выдавать каждому отдельный внешний IP. Заодно балансирует нагрузку.
2. cert-manager — продлевать SSL-сертификаты автоматически
Сам выпускает и продлевает сертификаты — посетители не увидят предупреждение о небезопасном соединении.
3. CSI Driver — не терять данные при перезапуске подов
Подключает подам постоянные диски. В первую очередь будет полезно базам данных.
4. kube-prometheus-stack — видеть все, что происходит с кластером
Собирает метрики по всему кластеру и выводит их на готовые дашборды. Если что-то идет не так — прилетает алерт.
5. ArgoCD — деплоить прямо из Git
Синхронизирует кластер с репозиторием. Меняете манифест и кластер сам приходит к нужному состоянию.
А вместе они закрывают весь цикл работы кластера: принять трафик → защитить его → сохранить данные → следить за состоянием → доставлять обновления.

13 июля 2026 Продолжаем усиливать инфраструктуру
1. Перенастроили политики libvirt
Раньше при высокой нагрузке очереди забивались и libvirt дольше расставлял задачи по приоритетам. Отсюда вытекали проблемы — установка отменяется или зависает.
Мы протестировали новые настройки, после чего раскатали на ноды во всех регионах. Теперь действия из панели отрабатывают гораздо быстрее и без проблем.
2. Перевели AI-агентов на High Availability
Теперь у нас два геораспределенных кластера: один находится в Германии, второй в США. Все важные сервисы реплицируются внутри одного региона и дублируются в другой.
3. Свежие дистрибутивы на основе Debian перешли на нативное получение IPv6 по DHCP
Тут логика простая — серверы с публичным IPv6, но без IPv4, теперь грузятся быстрее.

10 июля 2026 Расширили выбор моделей в AI-агентах
Добавили новинки, которые уже ждут вас в панели:
1. GPT 5.6 — Sol, Terra и Luna. Для широкого круга задач: от текста и кода до цепочки рассуждений.
2. Grok 4.5. Для работы с актуальным контекстом.
3. Qwen 3.7 Max, 3.7 Plus и 3.6 Plus. Max — под самые тяжелые задачи, Plus — баланс скорости и качества ответов.
Заодно подключили нового провайдера — Z.ai с линейкой GLM: 5.2, 4.7 и 4.7 FlashX. Это открытые модели, заточенные под код и агентные сценарии.
Это еще не все. Модели, которые раньше делились на thinking и non-thinking, объединили в одну — режим размышлений можно включить прямо в плейграунде.

9 июля 2026 Самое интересное об S3 — в одном видео
Рассказываем про то, что вообще умеет S3 и под какие задачи его берут:
1. Раздача статики через CDN. Файлы находятся в S3, а CDN раздает их пользователям из ближайшей точки.
2. Обмен файлами по временным ссылкам. S3 выдает временный доступ к файлу без настройки прав.
3. Медиа для каталогов. Фото товаров размещаются в S3, не занимают место на сервере и не нагружают приложение.
4. Резервное копирование. Бэкапы лежат вне основного сервера — вне основного сервера и не зависят от его состояния.
Что из этого пригодится именно вашему проекту, рассказал в видеообзоре наш продакт-менеджер Сергей Плеханов. А еще — почему файлы невозможно потерять, и за счет чего S3 помогает экономить.
Смотрите на удобной площадке: ютуб, вк, рутуб.
www.youtube.com/watch?v=OKJILZMVewk
vkvideo.ru/video-28839208_456239650
rutube.ru/video/bb6e8b5999272876454e15e8b0bd97c3/

8 июля 2026 Обновления в объектном менеджере S3
Недавно посчитали, что в нашем S3 лежит уже 2,7 млрд ваших объектов, и их становится только больше. Все они защищены тройной репликацией, поэтому остаются доступны даже при отказе отдельных узлов.
Помимо доступности развиваем и сам объектный менеджер — вот что добавили недавно:
1. Возможность предпросмотра
74 новых формата — видео, текстовые файлы, таблицы, документы и презентации доступны для просмотра прямо в объектном менеджере без скачивания.
Полный список поддерживаемых форматов.
2. Роль «Чтение и запись»
Добавили по вашим запросам. С этой ролью сотрудник, сервис или приложение работает только с объектами — читает, загружает, изменяет и удаляет. Настройки бакета и управление хранилищем остаются закрыты, так что задеть конфигурацию не получится. Остальные роли и уровни доступа собрали в доке.
timeweb.cloud/docs/s3-storage/manage-storage/additional-users#urovni-dostupa

7 июля 2026 Апдейты от наших инженеров
Расскажем об инфраструктурных работах в трех направлениях.
1. Масштабируем сервис сетевых дисков
Сервис отвечает за операции вокруг сетевых дисков: создание, монтирование, подключение. Запросов к нему становится больше, и особенно это заметно на пиках — диск может создаваться или монтироваться не сразу.
Переработали архитектуру сервиса и сделали ее распределенной. Сервис масштабируется горизонтально, мощность растет вслед за нагрузкой — прежнее ограничение по скорости снято.
2. Изолируем проблемные ноды в очереди
Как только нода перестает отвечать, сразу откладываем приходящие на нее задачи. Ускорили этот процесс, чтобы нода изолировалась быстрее и не тянула за собой остальные — очередь не застревает, а живые ноды работают как обычно.
Немного технических деталей: мы регулярно проверяем доступность нод через libvirt. Если нода несколько раз подряд не отвечает, помечаем ее как недоступную → задачи к ней откладываются, пока связь не восстановится
3. Ускоряем создание бэкапов
Обновляем парк хранилищ в Москве на более производительное оборудование и заодно приводим все хранилища к единой конфигурации. За счет этого бэкапы создаются быстрее.
На весь парк уйдет около двух месяцев. Данные реплицируются на время работ, так что обновление не затронет ваши проекты.
И это, конечно, не все. Часть обновлений еще обкатываем — поделимся ими, когда сами убедимся, что все работает стабильно.

7 июля 2026 Jivo в AI-агентах
Более 270 000 компаний в России используют этот онлайн-чат. Теперь к нему можно подключить AI-агента — он сам ответит на типовые вопросы клиентов.
Клиент пишет в Jivo-чат → AI-агент сразу отвечает по базе знаний → администратор видит все ответы и в реальном времени может подхватить диалог или поправить бота. Без отдельных окон и переключений между вкладками.
Пошаговая настройка → timeweb.cloud/docs/ai-agents/manage-agents/jivo
Что чат с агентом дает вашему проекту:
1. Поддержка 24/7 — агент отвечает мгновенно ночью, в выходные и в пики обращений.
2. Меньше нагрузки на операторов — команда будет подключаться только к сложным запросам, а типовые вопросы агент возьмет на себя.
3. Ни один диалог не потеряется — когда агент не справляется, он сам передает обращение оператору со свободным доступом к чату.

6 июля 2026 Туда, где охлаждение умеет резервироваться
Нашей новой локацией для зоны ams-1 станет ЦОД NorthC
Прямо сейчас совместно с инженерами площадки мы экстренно расширяем мощности по питанию под объемы наших стоек. На саму миграцию закладываем месяц. Подробности — скоро.

3 июля 2026 Цифры, о которых неприятно говорить
Много вопросов по поводу DDoS. На эту тему у нас много материалов, которыми мы периодически делимся. Сейчас картина следующая:
  • В этот сезон мы сталкиваемся с новой атакой широким конусом на 80 000 IP-адресов одновременно, что делает обнаружение заметно более проблематичным. В отдельных случаях, мы говорим о ~2 000 pps на отдельный хост, что очень не просто отличить от фонового трафика.
  • Атаки по-прежнему идут преимущественно на L3/4 уровни UDP-флудом, в то время как объем паразитного трафика вырос до ~150 млн пакетов в секунду.
  • Волны атак в пике достигают 3 Тбит/с — это беспрецедентный для РФ объем, который становится новой реальностью в 2026 году.
Видим вопросы о том, что мы с этим делаем. Тут правильнее дать слово Максиму Яковлеву, это наш CTO:
Мы давно сотрудничаем с крупнейшим российским провайдером в области информационной безопасности StormWall, пользуемся их решениями. У нас есть ряд внутренних детекторов аномалий, которые при обнаружении нехарактерных для сети пиков, переводят ее за систему очистки StormWall.
На сегодняшний день, по сочетанию факторов, мы считаем этот подход наиболее эффективным, как в разрезе техники, так и экономики. Это позволяет снизить влияние на инфраструктуру, при этом не делая трафик заградительно дорогим для всех.
Когда мы публикуем сообщение в алерт, это означает, что начинает работать массовая фильтрация.
На текущий момент фильтрация защищает эффективно, но при этом может задевать легитимный трафик, который попадает под паттерн атаки. В этом случае идеально работает только индивидуальное включение защиты с подбором под конкретный трафик. Это может быть решение на стороне клиента или через нас — через донастройку StormWall или подключение DDoS-Guard, по запросу или напрямую из панели управления.

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

Обновления



https://timeweb.cloud

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

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

В копилку стабильности — и с конкретным обновлением под капотом.
Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.
Это могло обернуться внезапной недоступностью виртуальных машин, хотя с самими проектами все было в порядке.
Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.
Переезд выполнили поэтапно: сначала подняли резервные серверы, перенесли на них проекты и только потом приступили к обновлению основных хостов. Поэтому пользователи не столкнулись с простоем.
Теперь гипервизоры работают на новом ядре, а риски возможных зависаний нод осталась в прошлом.
Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

19 июня 2026 AI-агенты в связке с Cline, Codex и OpenCode
Наших AI-агентов и AI Gateway можно использовать прямо в инструментах разработки.
Подключаете один раз → и дальше задаете вопросы по проекту, редактируете код и запускаете команды в терминале — прямо в рабочем окне.
Как это устроено: среда обращается к модели через OpenAI-совместимый API по вашему ключу. Используете наши модели и инфраструктуру, а интерфейс — привычный редактор или окно чата.
Подключение сводится к трем полям в настройках расширения:
  • 1. Тип провайдера — OpenAI Compatible
  • 2. Базовый URL агента или AI Gateway
  • 3. И, наконец, ваш API-ключ.
Дальше можно отправлять запросы модели прямо из кода. Если используете AI Gateway, в настройках доступны и параметры генерации — размер контекста, лимит токенов, температура.
Подробнее о каждой среде в доке → Cline, Codex и OpenCode.

18 июня 2026 История USmall — хайлоад изнутри
6+ млн товаров, 130 ритейлеров и до 70 млн запросов во время распродаж. Мигрировали USmall в наше облако и записали видеокейс о том, как устроена инфраструктура такого проекта.
Из любопытного:
  • 1. 130 площадок — 130 изолированных контуров. На каждую свой репозиторий и Docker-образ. Релизы независимы, все изменения изолированы.
  • 2. Свой механизм иерархических подов. В основе паттерн одноразовых подов — каждый выполняет один цикл и завершается. Поверх него команда построила иерархию, где родительский под запускает дочерние. Так обходят ограничение Python по пропускной способности одного воркера и обрабатывают задачи параллельно.
  • 3. Выделенный сервер под оркестратор. Когда Airflow потребовалась отдельная конфигурация, под него собрали сервер на двух 32-ядерных процессорах и перенесли без простоя.
  • 4. AI прямо в Kubernetes-кластере. В тестовом режиме крутится нейросеть, которая ускоряет подключение новых магазинов.
Все это команда ведет сама — новые ноды добавляет за пару минут через панель, без отдельных DevOps-инженеров. А инфраструктура у нас вышла на 35% дешевле прежнего провайдера — при том же объеме.
В видео Станислав, руководитель Python-разработки USmall, рассказывает про архитектуру и почему выбрали наше облако.
Смотреть видеокейс на ютубе, рутубе и в вк.
Или читать подробный разбор на сайте → timeweb.cloud/success-story/usmall

17 июня 2026 IPv6 в базах данных
Теперь облачной базе данных можно выдать бесплатный публичный IPv6-адрес.
Полезно, если:
1. Уже раскатали IPv6 в своей инфраструктуре и не хотите держать IPv4 только ради базы
2. Масштабируете проект и постепенно уходите от дефицитных IPv4-адресов
3. Строите cloud-native или корпоративную инфраструктуру, где важна поддержка IPv6.
Подключается в пару кликов: при создании новой базы или в настройках существующей «Сеть» → «Публичный IPv6-адрес». Если переключателя IPv6 у базы нет — значит, на вашей сети он пока недоступен.
При защищенном TLS-подключении адрес автоматически привяжется к техническому домену базы. Остальные детали в документации → timeweb.cloud/docs/public-ip/ipv6-adresa
Фича появилась не случайно — ее давно просили в разделе идей (тут и тут), теперь она в проде.
Привязать айпишник к базе

16 июня 2026 Получили награду от Иннополиса
Посетили закрытую встречу резидентов и партнеров Иннополиса с участием руководства Татарстана. Обсудили совместные планы и получили неожиданную, но приятную статуэтку (на фото).
Напомним, что осенью прошлого года наш офис переехал в Казань, где мы участвуем в развитии ИТ-среды и выстраиваем сотрудничество с Университетом Иннополис.
Рады, что коллеги отметили нашу динамику. А ведь времени прошло всего ничего.
Вдохновляет

16 июня 2026 Изменение цен на выделенные серверы
С 1 июля 2026 года цены на выделенные серверы в Москве и Санкт-Петербурге вырастут на 12%.
Причина: рост цен на стойки и серверы со стороны поставщиков.
Цена на выделенные серверы в других локациях, серверы с GPU, расширение канала и доп IP-адреса остаются без изменений.
Рекомендуем заблаговременно внести на баланс сумму, достаточную для оплаты серверов по новым тарифам.

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

В прошлых новостях про инфраструктуру рассказали, как облако устроено изнутри. Сегодня спускаемся уровнем ниже — в кластер, где физически лежат ваши бакеты и сетевые диски. Повод подходящий — после ввода двух новых нод общая емкость кластера превысила 6 петабайт.
Две трети этого объема занимают запасные копии, и так задумано. Все объекты реплицируются трижды — на разных серверах и в разных стойках.
Зачем столько копий? Диски — расходник и ломаются без расписания: бывают месяцы без единой замены, а в прошлом поменяли сразу три из 436 накопителей кластера.
Каждая замена проходит незаметно для ваших проектов: вышел из строя диск → кластер за пару часов восстанавливает копии на соседних нодах, и данные все это время можно читать и записывать.
Что под капотом. Ceph-кластер из 27 серверов с двумя тирами: быстрые NVMe-ноды — под активные данные, емкие HDD — под архивы и объекты, к которым обращаются редко. Между уровнями данные распределяются автоматически.
Кластер растет быстро. В феврале 2024 года в нем было три ноды и 70 терабайт под данные клиентов, сейчас — 27 нод и 2 петабайта. В 30 раз больше за два с половиной года.
Недавно добавили еще две ноды — одну в горячий тир, одну в холодный, ввели без окон обслуживания, данные перераспределились фоном.
6 петабайт — не предел. Про новые отметки расскажем в следующих постах.

10 июня 2026 Запустили мониторинг сервисов
Теперь можно отслеживать стабильность работы сайтов, серверов и приложений, размещенных в нашей инфраструктуре или на сторонних платформах.
Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.
Что можно мониторить:
Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.
Доступность серверов. Сервер перестал отвечать на запросы — среагируете до того, как это заметят остальные.
TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.
SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.
Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.
Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации → timeweb.cloud/docs/monitoring
Стоимость — 30 ₽ в месяц за сервис, списания почасовые.
Подключить мониторинг → timeweb.cloud/my/monitoring

8 июня 2026 Последние инфраструктурные изменения
Атака на DNS, отказ диска, плановые работы на хосте — раньше это могло влиять на работу ваших проектов. С ростом числа клиентов и нагрузок прежние архитектурные решения перестали справляться.
Перестроили инфраструктуру по трем направлениям так, чтобы такие ситуации проходили для вас незаметно — или с минимальным эффектом.
1. Защитили исходящие запросы ваших серверов
Приложения регулярно обращаются к внешним сервисам по доменным именам — платежным шлюзам, API, базам, репозиториям. Каждый запрос проходит через наши DNS-резолверы. При мощной атаке на них запросы могли подвисать или не доходить — приложения теряли связь с внешним миром, даже когда серверы работали штатно.
Развернули резолверы по схеме anycast: запрос уходит на ближайший доступный узел → нагрузка распределяется между всеми. Атака на один узел не выводит DNS из строя — остальные продолжают отвечать, и приложения работают стабильно.
2. Отвязали данные от конкретного хоста
Внедряем сетевое хранилище NVMe-oF вместо локальных дисков. Начали с Москвы, постепенно раскатываем дальше.
На практике: если у конкретной ноды отказывает железо, сервер быстрее перезапускается на исправном оборудовании. Не нужно ждать, пока починят именно эту ноду, или разворачиваться из бэкапа.
3. Сделали миграцию виртуальных машин универсальной
С ростом числа клиентских конфигураций уперлись в корнер-кейсы — на некоторых миграция могла подвисать или требовать остановки сервера. Теперь переносим серверы быстро и без даунтайма в любом конфиге. Обычно в трех сценариях:
Плановые работы на железе: на время обслуживания хоста мигрируем машины на другой.
Балансировка: если хост перегружен, переносим часть виртуалок на свободный.
Проблемное железо: если нода ведет себя нестабильно, сразу запускаем миграцию до реальных сбоев.
Главная идея — закладывать запас прочности, чтобы инфраструктура справлялась и с текущим ростом, и с нештатными ситуациями.
P.S. Инженеры уже пишут статью на Хабр про факапы и победы в росте инфраструктуры. Пишите в комментариях, что хотите там увидеть — разберем.

3 июня 2026 Поручить работу с сервисами своему AI-агенту
Чтобы поднять сервер, базу и бакет под новый проект — можно просто создать AI-агента в связке с Timeweb Cloud MCP. Пишете агенту, что нужно, он запрашивает подтверждение и после вашего разрешения берется за работу.
Причем наш MCP можно подключить и к стороннему агенту — например, Cursor, Claude или своему боту. Подробнее про подключение → в доке.
Из последних апдейтов — открыли для MCP почти весь публичный API. Доступны все методы, кроме удаления, добавим их позже.
Что вы можете поручить агенту в связке с Timeweb Cloud MCP:
Запустить инфраструктуру с нуля
Создай сервер на Ubuntu 24.04 с 4 ГБ RAM в Москве для тестов
Мониторить работу
Покажи список серверов и их статус, а еще оцени состояние кластера
Собрать контур под проект
Создай балансировщик и добавь в него 2 сервера, а потом настрой приватную сеть между ними
Запустить AI-агента с поддержкой MCP → timeweb.cloud/my/cloud-ai/tools

2 июня 2026 Под капотом управляемых сервисов
Вместе с инфраструктурой и сетью продолжаем менять то, что напрямую влияет на стабильность. Сегодня подробнее про управляемые сервисы — базы данных, кластеры Kubernetes, балансировщики и др.
Главное — перестроили процесс развертывания сервисов.
Теперь задачи разделены: cloud-init поднимает сервис при создании, а фоновая служба агента на инстансах DBaaS обслуживает его дальше.
Что это значит для вас — сервисы в среднем создаются на 3 минуты быстрее. А за счет сокращения задержки между запросом из панели и его выполнением агент оперативнее применяет изменения.
Параллельно:
1. Пересобрали образы ОС под сервисы. Вместо универсального образа у баз данных, Kubernetes и других сервисов теперь свой минимальный образ только с нужными зависимостями. За счет этого сервис создается быстрее и не зависит от состояния внешних репозиториев.
2. Подняли все версии PostgreSQL до последних минорных. Обновили линейки 17.x, 16.x, 15.x — чтобы у вас был доступ к стабильным версиям с закрытыми уязвимостями.
3. Усилили безопасность управляемых баз. Перенесли сетевую изоляцию на уровень гипервизора виртуальной машины и пересмотрели список доступных расширений PostgreSQL.

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





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

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

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

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

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

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

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

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

https://timeweb.cloud

Получили награду от Иннополиса



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

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

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

Вдохновляет

https://timeweb.cloud

Изменение цен на выделенные серверы



С 1 июля 2026 года цены на выделенные серверы в Москве и Санкт-Петербурге вырастут на 12%.

Причина: рост цен на стойки и серверы со стороны поставщиков.

Цена на выделенные серверы в других локациях, серверы с GPU, расширение канала и доп IP-адреса остаются без изменений.

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

Сейчас часть пользователей сталкивается с недоступностью подключения к инфраструктуре при использовании сетей российских операторов связи



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

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

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

Признаки проблемы: таймаут подключений по SSH/RDP, недоступность протоколов HTTP/HTTPS/ICMP на сервере. Они актуальны при условии, что вы не используете средства обхода блокировок — это нарушает правила платформы (пункт 1.18): st.timeweb.com/cloud-static/legal-info/platform-rules.pdf

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

Обновления



29 мая 2026 Крупный апдейт в App Platform
Теперь развернуть приложение можно не только из своего репозитория, но и сразу из Docker Hub.
Выбираете образ → App Platform сам настраивает обратный прокси и выдает бесплатный технический домен. Через пару минут — рабочее приложение с HTTPS и логами.
Удобно, когда нужен готовый сервис здесь и сейчас — в Docker Hub есть множество образов под любые задачи: веб-серверы, CMS, базы, мониторинг и не только.
Подробнее о деплое приложений → в доке. timeweb.cloud/docs/apps/deploying-with-docker-hub
Планируем добавить деплой из приватных и кастомных реестров контейнеров, а также упростить работу с доменами.

28 мая 2026 Ускорили сборку и доставку образов для облачных серверов
Раз в минуту у нас разворачивается минимум два новых сервера — это 3000+ установок в день. Каждый из них должен запускаться быстро, быть готовым к работе из коробки и иметь актуальные обновления безопасности.
Чтобы держать эту планку, мы пересобрали qcow_builder — наш внутренний конвейер сборки и тестирования образов.
Вот как мы это сделали:
1. Перешли на cloud-образы вместо установки с ISO
Для большинства Linux-дистрибутивов берем готовые .qcow2 с зеркал вендоров и дорабатываем до своих стандартов. Сборка одного образа теперь занимает 5–15 минут вместо полутора часов. Образы унифицированы с другими облаками: плейбуки, раннеры и привычная автоматизация переносятся к нам без существенных доработок.
2. Ввели модульный конвейер вместо гигантского скрипта
Теперь сборка устроена из двух частей. Конвейер приводит все диски к единым стандартам, чтобы любая ОС работала у нас одинаково предсказуемо. А роутер отвечает за точечную настройку под конкретное семейство ОС — туда подключаются модули с плейбуками. Так мы быстрее раскатываем новые ОС по вашим запросам.
3. Добавили единую настройку через Ansible
После сборки диска временный сервер прогоняется через плейбуки. В каждый образ закладываем необходимые для мониторинга юниты и корректные сетевые конфигурации — чтобы потом вам не пришлось доставлять их вручную.
4. Расширили автотесты до публикации в продакшн
Каждый образ проверяется на реальной виртуальной машине — такой же, как и у вас. Прогоняем сеть, SSH, cloud-init, QEMU Guest Agent, Zabbix-агент и базовые сценарии запуска. Если что-то пошло не так — образ возвращается на доработку и дальше не идет.
В итоге вы получаете сервер, готовый к работе сразу после выбора образа в панели. Под капотом — 58 наших образов на весь стек, от Linux для облачных серверов до сборок под Kubernetes и managed-сервисы.
Платформа нативно работает с cloud-образами и cloud-init — проще переносить существующие проекты, автоматизацию и CI/CD-процессы без лишней адаптации.

22 мая 2026 Запускаем городскую сеть в Москве — и расширяем пиринг с одной точки до четырех
В прошлых постах рассказывали про опорную сеть — поставили Juniper PTX 10003-80C в Петербурге и перешли на 400 Гбит/с по магистрали.
Следующим этапом запускаем городские сети там, где у нас несколько площадок, и делим всю сеть на три уровня — опорный, городской и внутри каждого дата-центра.
Суть проекта: в городах с несколькими точками присутствия или дата-центрами мы развернем городские MAN-сети. Они объединят площадки в единое кольцо и помогут эффективнее передавать трафик внутри города.
Преимущества таких сетей:
1. Больше точек присутствия для пиринга
Расширим количество узлов связи для стыковки с операторами и партнерами: с 1 узла в ММТС-9 до 4 узлов на разных площадках. Маршруты до клиентских проектов и операторов-партнеров станут короче, а сеть устойчивее. Если одна точка будет недоступна, трафик автоматически перераспределится через остальные.
2. Двойное подключение каждого ЦОД к городской сети
Каждый дата-центр планируем подключить минимум к двум городским узлам на скорости до 4 Тбит/с. Связность сохранится даже при аварии на одном из узлов городской сети.
3. Меньше задержек между площадками
Сможем гибче развивать новые площадки и добавлять емкость до дата-центров. А еще проводить работы на узлах связи без снижения производительности.
Первый город на очереди — Москва. Соберем кольцо на сетевых интерфейсах 100 и 400 Гбит/с — хватит, чтобы спокойно прокачивать трафик и оставить большой запас.

21 мая 2026 Веб-поиск и генерация изображений
Развивается не только наша инфраструктура, но и сервисы. Сегодня — про AI-агентов.
За последние три месяца количество активных агентов выросло в 4 раза, а пользователи тратят больше миллиарда токенов в день.
Теперь можно закрывать больше сценариев в одном диалоге: поиск актуальных данных и создание визуалов под запрос.
— Веб-поиск
Агент ищет информацию в интернете перед ответом, а вы получаете актуальные цены, тарифы, новости, данные с сайтов. Под капотом — интеграция с Яндексом.
Функция включается в настройках агента. Стоимость — 0,49 руб. за запрос.
— Генерация изображений
Агент генерирует иллюстрации, иконки, баннеры прямо в диалоге, без лишних переключений. В будущем добавим и генерацию аудио.
Доступные модели: Gemini 3.1 Flash Image Preview и Gemini 3 Pro Image Preview, они же Nano Banana. Список будет пополняться.
Оплата — по токенам выбранной модели. Включить можно где удобно: при создании агента, в настройках уже готового или прямо в чате.
Бонусом поменяли способ тарификации для новых агентов на поресурсный. Так можно дешевле тестировать новые фичи, платить только за фактическое использование и настраивать агента под свои задачи.

19 мая 2026 Переехали в новый ЦОД в Нидерландах и забрали сеть под свой контроль
С апреля мы вели масштабный проект по переносу европейской локации на новую площадку. Старый дата-центр euNetworks закрывается в июле, поэтому задачу требовалось решить в сжатые сроки и полностью бесшовно для клиентов.
За 2 месяца плотной работы мы провели онлайн-миграцию около 35 000 виртуальных серверов в новый дата-центр Qupra DC2. Процесс шел поэтапно: сначала перераспределяли нагрузку внутри инфраструктуры, а затем запускали миграцию виртуалок. Благодаря этому все клиентские проекты продолжали работать в штатном режиме без даунтайма.
В новом ЦОДе мы заняли 15 стоек, где на текущий момент суммарно работает уже около 60 000 виртуальных серверов и есть большой запас для масштабирования.
Миграция стала поводом для полноценного апгрейда всей локации:
1. Усилили сетевую инфраструктуру
Мы внедрили DWDM-систему для спектрального уплотнения каналов, что увеличило пропускную способность сети. Для объединения трафика с серверных стоек и его ускорения внутри площадки установили модульный коммутатор агрегации Arista 7508.
2. Перевели стойки и сети под свой контроль
Теперь серверы размещаются в наших собственных стойках, а сетевое оборудование внутри ЦОДа находится под полным контролем нашей команды. Это позволяет быстрее мониторить состояние площадки и оперативно реагировать на инциденты.
3. Обновили системное ПО
Параллельно с переносом данных мы актуализировали ПО на хостах. Часть старых нод перевели на свежие версии операционных систем и обновили ядро Linux, чтобы минимизировать риски сбоев на уровне хост-машин.
Итого снизили риски инфраструктурных сбоев в локации до минимума, ускорили связность внутри ЦОДа и заложили большой запас по мощности.

18 мая 2026 Седьмая локация для облачных серверов
Теперь вы можете развернуть сервер в Нью-Йорке. Хороший вариант, если важна низкая задержка для пользователей в Северной Америке или вы хотите распределить инфраструктуру между США и Европой.
Физически дата-центр находится в Буффало, штат Нью-Йорк. Мы подключили локацию к опорно-магистральной сети, чтобы обеспечить стабильное управление и качественное соединение с инфраструктурой в других локациях.
Есть фиксированные и произвольные конфиги. Минималка 1 CPU, 1 ГБ RAM и 15 ГБ диска.

14 мая 2026 Укрепляем защиту ваших проектов
За последнее время в публичном поле появилось несколько заметных уязвимостей: Copy Fail, Dirty Frag, Fragnesia, а также уязвимости в Exim и nginx.
В некоторых конфигурациях они могли нарушить работу сервисов, обойти защиту или повысить риски доступа к данным.
Что мы сделали со своей стороны
Проверили, касаются ли эти угрозы нашей инфраструктуры. Установили обновления и добавили меры доп защиты.
Тем самым снизили риск повышения привилегий и ограничили возможные варианты несанкционированного доступа.
В нашей зоне ответственности все необходимые меры защиты уже применены.
Как можно усилить безопасность у себя
В первую очередь советуем проверить актуальные версии ОС и системных пакетов. Copy Fail, Dirty Frag и Fragnesia связаны с Linux-ядром и повышением привилегий.
Если внутри сервера вы ставили Exim или nginx, то также проверьте их на обновления:
Exim: 4.99.2 или актуальная версия из репозитория вашего дистрибутива
nginx: версия 1.30.1 stable или 1.31.0 mainline
Еще немного базовых рекомендаций:
— Пересмотрите доступы: права пользователей, SSH-ключи и sudo
— Убедитесь, что пароли, токены и ключи не хранятся в открытом виде
Подробнее о мерах безопасности → в туториале

13 мая 2026 Juniper PTX 10003-80C в Петербурге
В петербургский ЦОД поставили Juniper PTX 10003-80C, маршрутизатор операторского класса с нативной поддержкой 400G.
— Расширяем магистральный канал до Амстердама. PTX добавляет емкость на одном из транзитных маршрутов в европейском направлении.
— Разгружаем MX480. Часть трафика, которая шла через текущее ядро петербургской сети, переходит на PTX. MX480 получает запас по производительности.
— Фундамент под Nх400G-кольцо по Петербургу. PTX нативно поддерживает 400G, а наша конфигурация MX480 нет. Переход кольца на 400G сейчас в работе.

12 мая 2026 Про Telegram API, СХД, сети и многое другое
За последние 3 месяца мы экстерном прошли курс выживания в экстремальном ИТ. Событий было столько, что хватило бы на сериал.
Просто доросли до нагрузок, где вылезают проблемы совсем другого уровня — те самые, с которыми воюют гиперскейлеры. На этом этапе любые неочевидные зависимости или ограничения масштабирования бьют в разы больнее.
Решили разобрать эти кейсы открыто. Это хроника того, как мы адаптируем инфраструктуру под новые нагрузки.
— Инцидент в ЦОД (Германия). В феврале из-за возгорания на площадке во Франкфурте полностью отключили питание, доступ к стойкам был закрыт на 2 часа. Часть компонентов вышла из строя.
Обновили протоколы «холодного старта» и резервирования для зарубежных сегментов. Дополнительно пересмотрели подходы для более быстрого взаимодействия с поставщиками и партнерами.
— Сетевые атаки в марте. Мы столкнулись с DDoS-атаками новых масштабов и паттернов (пики 1, 2, 14 и 16 числа).
Обновили профили фильтрации, правила классификации и пороги реакции на аномалии. Это позволяет эффективнее отсекать всплески, не задевая легитимный трафик.
— Сбой на уровне гипервизоров. 24 марта из-за флапа сети в московских стойках «зависли» RDMA-сессии на стороне СХД. Это привело к потере связности на 15 нодах, часть ВМ пришлось эвакуировать.
Изменили параметры взаимодействия сетевого стека и гипервизоров, чтобы локальные колебания сети не приводили к каскадному влиянию на виртуальные машины.
— Сбой на уровне СХД. 9–10 апреля кластер СХД столкнулся со сбоем. Причина — софтовый баг, не заявленный ранее вендором, проявился под нашей продакшен-нагрузкой.
Обновили ПО, пересмотрели процедуры обслуживания и ввели дополнительные лимиты на контроллерах для защиты системы в пиковых сценариях.
— Доступность Telegram API. Масштабные сбои в работе ботов по всей РФ затронули и наши сервисы.
Отладили систему мониторинга внешних сервисов, чтобы информировать пользователей о глобальных сбоях, на которые не можем влиять напрямую.
— Ошибка в БД. 4 мая во время плановых работ возник технический сбой, который привел к некорректным балансам и блокировкам.
Ошибку устранили, доступ восстановили. Внесли изменения в регламенты техработ и добавили дополнительные уровни проверки данных (валидацию), чтобы минимизировать риски, связанные с человеческим фактором.
Понимаем, что чем больше становится проект, тем важнее быть открытыми с теми, кто им пользуется. Поэтому решили немного изменить формат новостей.
Теперь наравне с продуктовыми обновлениями будем регулярно рассказывать про архитектуру сетей и работу с железом. Для нас это новый вызов, а для вас — возможность увидеть, с чем сталкивается большая инфраструктура изнутри.

5 мая 2026 Все дороги ведут к CDN
Замечали, что сайт в разных локациях грузится по-разному?
Так происходит потому, что контент идет с одного источника. Чем дальше пользователь, тем дольше загрузка. Особенно это заметно на сайтах с изображениями и видео, а также при раздаче файлов.
И тут в игру вступает CDN. Выкатили решение, которое ускорит загрузку: пользователь открывает сайт → контент прилетает с ближайшего узла → все загружается быстрее.
Если файл уже есть в кэше — он отдается мгновенно. Если нет, то CDN загружает его с источника, сохраняет и ускоряет последующие запросы. Подробнее → в доке.
С CDN посетители сайтов и приложений получают:
1. Быструю загрузку страниц и медиа
2. Стабильную работу сервиса
3. Меньше ошибок при загрузке контента
Как подключить: Перейти в раздел CDN → «Создать ресурс» → указать источник (сервер или S3) → сохранить настройки
timeweb.cloud/my/cdn

4 мая 2026 Ваш кластер больше не черный ящик
Не нужно разбираться в каждой ноде и гадать, что случилось с кластером. Все видно прямо в панели управления — с новыми логами системных компонентов в Kubernetes:
— Healing
— Автоскейлинг
— CCM
— kube-apiserver
Что можно узнать по логам:
Не создается LoadBalancer → открыть логи CCM и сразу увидеть причину
Кластер странно скейлится → посмотреть, какие поды триггернули добавление ноды и почему она потом удалилась
Нода внезапно исчезла → проверить, почему ее пересоздал хиллер и почему это произошло
Искать логи не нужно — они уже в отдельной вкладке кластера.

Запускаем городскую сеть в Москве — и расширяем пиринг с одной точки до четырех





В прошлых постах рассказывали про опорную сеть — поставили Juniper PTX 10003-80C в Петербурге и перешли на 400 Гбит/с по магистрали.

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

Суть проекта: в городах с несколькими точками присутствия или дата-центрами мы развернем городские MAN-сети. Они объединят площадки в единое кольцо и помогут эффективнее передавать трафик внутри города.

Преимущества таких сетей:
1. Больше точек присутствия для пиринга

Расширим количество узлов связи для стыковки с операторами и партнерами: с 1 узла в ММТС-9 до 4 узлов на разных площадках. Маршруты до клиентских проектов и операторов-партнеров станут короче, а сеть устойчивее. Если одна точка будет недоступна, трафик автоматически перераспределится через остальные.

2. Двойное подключение каждого ЦОД к городской сети
Каждый дата-центр планируем подключить минимум к двум городским узлам на скорости до 4 Тбит/с. Связность сохранится даже при аварии на одном из узлов городской сети.

3. Меньше задержек между площадками
Сможем гибче развивать новые площадки и добавлять емкость до дата-центров. А еще проводить работы на узлах связи без снижения производительности.

Первый город на очереди — Москва. Соберем кольцо на сетевых интерфейсах 100 и 400 Гбит/с — хватит, чтобы спокойно прокачивать трафик и оставить большой запас.

Переехали в новый ЦОД в Нидерландах и забрали сеть под свой контроль



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

За 2 месяца плотной работы мы провели онлайн-миграцию около 35 000 виртуальных серверов в новый дата-центр Qupra DC2. Процесс шел поэтапно: сначала перераспределяли нагрузку внутри инфраструктуры, а затем запускали миграцию виртуалок. Благодаря этому все клиентские проекты продолжали работать в штатном режиме без даунтайма.

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

Миграция стала поводом для полноценного апгрейда всей локации:

1. Усилили сетевую инфраструктуру
Мы внедрили DWDM-систему для спектрального уплотнения каналов, что увеличило пропускную способность сети. Для объединения трафика с серверных стоек и его ускорения внутри площадки установили модульный коммутатор агрегации Arista 7508.

2. Перевели стойки и сети под свой контроль
Теперь серверы размещаются в наших собственных стойках, а сетевое оборудование внутри ЦОДа находится под полным контролем нашей команды. Это позволяет быстрее мониторить состояние площадки и оперативно реагировать на инциденты.

3. Обновили системное ПО
Параллельно с переносом данных мы актуализировали ПО на хостах. Часть старых нод перевели на свежие версии операционных систем и обновили ядро Linux, чтобы минимизировать риски сбоев на уровне хост-машин.

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

https://timeweb.cloud

Juniper PTX 10003-80C в Петербурге





В петербургский ЦОД поставили Juniper PTX 10003-80C, маршрутизатор операторского класса с нативной поддержкой 400G.
  • Расширяем магистральный канал до Амстердама. PTX добавляет емкость на одном из транзитных маршрутов в европейском направлении.
  • Разгружаем MX480. Часть трафика, которая шла через текущее ядро петербургской сети, переходит на PTX. MX480 получает запас по производительности.
  • Фундамент под Nх400G-кольцо по Петербургу. PTX нативно поддерживает 400G, а наша конфигурация MX480 нет. Переход кольца на 400G сейчас в работе.

https://timeweb.cloud