Разработка публичных облаков *

Привет, меня зовут Борис Хасанов, я сетевой архитектор в MWS Cloud Platform. 

Решил поделиться с вами обзором новой технологии MRC* для создания сетей для AI/ML-кластеров, так называемых backend networks. Технология интересная и перспективная — там есть магия SRv6 :)

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

* MRC — Multipath Reliable Connection, расширение RoCE-архитектуры, предложенное коллегами из OpenAI, Microsoft, Nvidia, AMD, Broadcom. Недавно вышло несколько англоязычных публикаций с его анонсом. Вот одна из них на сайте OpenAI.

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

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

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

У Брюса Уэйна есть деньги, влияние и ресурсы.

У Бэтмена — скорость, гибкость и гаджеты на все случаи жизни.

Но по отдельности один без другого не может: без Брюса неоткуда взять технологии, а без Бэтмена они не имеют смысла. Только вместе они закрывают проблемы, с которыми поодиночке не справились бы. Гибридная инфраструктура работает (примерно) так же...

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

Привет! Я Владимир Атасунц, руководитель направления Security Services в MWS Cloud Platform. В этой статье расскажу о сервисе аудитных логов — базовом инструменте облака для контроля действий с ресурсами и анализа изменений в инфраструктуре.

Разберу:

зачем конкретно нужен такой сервис и какие сценарии использования предусматривает;

как он выглядит с точки зрения продуктовой модели;

какие требования легли в основу системного дизайна;

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

Пойдём последовательно — от бизнес-сценариев к технической реализации.

Привет, Хабр! На связи Алексей Тюняев, директор по облачным продуктам Рег.облака.

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

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

Всем привет! Меня зовут Александр Пивкин, я ведущий SRE‑инженер в MWS Cloud Platform. Сейчас Ceph — основная технология хранения данных в MWS Cloud Platform, и поэтому она должна работать хорошо. 

Сегодня сфокусируемся на инструментах диагностики и устранения проблем производительности в Ceph‑кластерах.

Привет, Хабр! На связи Даша Косова, я продакт менеджер Рег.облака.  Представим знакомую многим ситуацию. У компании есть сервер. Он работает уже несколько лет. На нем крутятся базы данных, backend-сервисы, cron-скрипты, система мониторинга. Всё настроено, всё работает, и трогать это никто особенно не хочет.

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

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

Сегодня достаточно уметь сформулировать задачу. ИИ радикально снизил порог входа в разработку — и это прекрасно.

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

Разбираем, почему так происходит и как разрабатывать с ИИ эффективно.

Знаете, бывают технологии, которые изучаешь — и сразу понятно, куда шли и чем закончили, но OpenStack — это не просто технология, это целая эпоха. Причём такая, где на одной временной шкале у тебя NASA, Rackspace, Mirantis и Red Hat и десятки других крупных компаний, каждая из которых решила, что надо объединиться чтобы сделать свой, «домашний» AWS.

Кстати, да, меня зовут Эдгар Сипки, я девелопер-адвокат в MWS Cloud Platform, и сегодня мы поговорим об OpenStack.

Привет, Хабр! На связи команда Рег.облака. 16 апреля мы провели свой Демо день — продуктовую конференцию для тех, кто строит IT-инфраструктуру и хочет делать это без лишних расходов. Два параллельных трека, панельная дискуссия про ИИ с «ВкусВиллом», банком «Синара», Raft и РБК, а вечером — нетворкинг с живой музыкой в Центре событий РБК. Для тех, кто пропустил, рассказываем, что обсуждали и к чему пришли.

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub.

В первой части статьи про KNGFW мы разобрали, как собрать контур управления, связать компоненты и получить рабочую основу. Но на этом этапе NGFW всё ещё остаётся «правильно собранным железом». Оно готово к работе, но само по себе ещё ничего не защищает.

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

Дальше материал будет максимально прикладным. Сначала собирем базовую конфигурацию: сеть, доступы, NAT, логирование, интеграции. Всё, на чём держится повседневная работа. А затем переходим к модулям безопасности и той задаче, ради которой NGFW в принципе и внедряется.

Я год экспериментировал с on-premise Copilot — прямо над нашими разработчиками, — чтобы проверить: а правда ли эта штука разгоняет разработку на десятки процентов? Делюсь реальными метриками скорости и точности, разбираю, как оно работает на примере нашей инсталляции, и показываю результаты. По пути расскажу про все подводные камни: где ИИ стал турбоускорителем, а где подставил подножку и превратился в скрытую ловушку.

Базовый сценарий: вы пушите образ в Container Registry, и ничего не происходит. Чтобы обновить Serverless Container, нужно идти в консоль и накликивать обновление контейнера. Странно, что такой автоматизации нет «из коробки», но её легко собрать на коленке.

Я прошел этот путь и упаковал всё в готовый репозиторий:

Cloud Function на Go, которая ловит события Registry.

Terraform-конфиг, который разворачивает всю обвязку.

Разбор формата событий YMQ (самая неочевидная часть).

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

Привет! Меня зовут Кирилл, я инженер команды киберзащиты облачного провайдера Nubes. В зоне моей ответственности решения сетевой защиты. В рамках запуска облака КИИ «ТУЧА» мне досталась задача развернуть и настроить NGFW для защищённого контура. В этой статье хочу поделиться практическим опытом первого внедрения Kaspersky NGFW без лишнего маркетинга, а с акцентом на те моменты, которые действительно важны при первом знакомстве с продуктом.

«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. 

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

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

Ещё недавно, разработав Телеграм‑бота, его можно было разместить на любой VPS, и он работал. Но с недавнего времени появились региональные ограничения. Чтобы бот мог подключиться к API Telegram, его нужно разместить на VPS вне России.

В статье я предложу краткий список как российских, так и зарубежных провайдеров VPS (и не только) для телеграм‑ботов, где можно разместить бота для стабильной работы.

Сегодня обсудим развёртывание агентов, созданных в Yandex Cloud AI Studio Agent Atelier. Atelier — это такой очевидный UI для настройки PromptTemplate для Responses API.

За время работы в облаке я убедился в одной простой вещи: сколько бы сервисов ни предлагало облако — Kubernetes, Serverless, базы данных, Big Data или AI-сервисы, — всё это работает только потому, что под ними есть прочный фундамент: виртуальные машины, диски и сети. Этот фундамент и называется IaaS. Он важен и для клиентов, и для самого облачного провайдера: все сервисы строятся поверх него, а уровень этой базы определяет надёжность и скорость создания сервисов.

Всем привет! Меня зовут Родион Цалкин, TPO в MWS Cloud Platform. Сегодня поговорим о IaaS-слое. 

Когда мы начали создавать новую инфраструктурную платформу MWS Cloud Platform, мы решили, что надёжность инфраструктуры и гибкость сервисов — это те требования, от которых нельзя отступать. И чтобы выполнить их честно, мы сделали ставку на два принципа: собственную физическую инфраструктуру и собственную разработку.

Как мы проектировали физическую фабрику и overlay-сеть на SRv6 — отдельная статья про архитектуру сети.

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).