es
Feedback
MWS Cloud Platform | Сообщество

MWS Cloud Platform | Сообщество

Ir al canal en Telegram

Чат MWS Cloud Platform: помощь, вопросы, баги и обсуждение идей Команда разработки на связи 👋

Mostrar más
El país no está especificadoLa categoría no está especificada
496
Suscriptores
Sin datos24 horas
Sin datos7 días
Sin datos30 días
Archivo de publicaciones
Друзья, коротко — зачем делаем своё S3 и как оно устроено 👇 Почему вообще S3 первым Минимум зависимостей, максимум пользы: годится и как самостоятельный продукт, и как базовый блок для других сервисов (снимки дисков, образы, логи, бэкапы). Поэтому запускали именно его. Почему не «как есть» на Ceph RGW — Масштаб: кластеры >1000 OSD становятся хрупкими, multisite даёт разрозненные инстансы — нужен умный stateful-фронт, чтобы склеить в единое S3. — Зоны/«регионы»: бакет привязан к одной zone group → сложно шардинговать внутри одного «региона». — Избыточность: в типовой конфигурации выходит 3× и выше (хуже, чем ~1.8× у AWS при 3 AZ). — Большие бакеты и delete-штормы: решардирование с простоем на запись, LSM-compaction бьёт по HDD и деградирует OSD. — Апстрим: фундаментальные правки в RGW — годы работы с неопределённым результатом. Что в итоге делаемGolang-сервисы: приложение, auth, API. — PostgreSQL — метаданные (транзакционность, read-after-write). — Kafka — фоновые процессы (межДЦ-репликация, lifecycle, GC). — Ceph — только blob-storage, независимые кластеры по ДЦ, репликация — на уровне приложения. Модульно, заменяемо, скейлится по частям. Полный разбор и мотивация — на Хабре.

⚡️️️️️️️️️Друзья, мы завершили опрос о DevOps-практиках и, наконец, можем поделиться его результатами! Спасибо всем, кто принял участие и помог нам узнать текущие тенденции индустрии. Если вам интересно: ⚫️️️️️️️️️какие инструменты сейчас действительно используются ⚫️️️️️️️️️как команды работают с Kubernetes, AI, Security, IDP и инцидентами ⚫️️️️️️️️️какие подходы масштабируются, а где возникают основные сложности ⬇️ Ищите результаты в презентации и делитесь мнением в чате сообщества. Розыгрыш билетов на конференции «Онтико» (любую на выбор) и объявление авторов лучших вопросов проведем в пятницу, 10 апреля. Не забудьте подписаться на Сообщество MWS Cloud Platform, чтобы забрать призы! Следите за обновлениями!

Добрый день! Для всех участников раннего доступа мы предусмотрели грант в размере 15 000 ₽, который будет действовать в течение месяца и покроет часть расходов на сервисы Compute и VPC. Если у вас масштабная инфраструктура, мы можем обсудить индивидуальные условия. Напишите мне личку, договоримся о звонке.

⚡️️️️️️️️️️️️️️Снижаем цены на GPT Model Hub! До 15 июля уменьшаем стоимость работы с MWS GPT Model Hub в MWS Cloud Platform. Коротко:
♦️входящие токены — дешевле до 95% ⚫️️️️️️️️️️️️️️исходящие токены — дешевле до 80% ⚫️️️️️️️️️️️️️️скидка применяется автоматически, ничего подключать не нужно ⚫️️️️️️️️️️️️️️действует для всех — и для новых, и для текущих пользователей
Что это меняет на практике? Теперь соотношение стоимости входящих к исходящим токенам — примерно 1:4. Это помогает делает сценарии с большим объёмом контекста заметно выгоднее. Например:
♦️
RAG: можно передавать больше данных в контекст без ощутимого роста стоимости
♦️
code assist: дешевле анализировать кодовую базу и давать более точные ответы
Если вы уже используете GPT Model Hub — новые цены начнут применяться автоматически. Если нет — хороший момент попробовать и посмотреть, как это влияет на ваши сценарии. ➡️ Цены и детали ➡️ Условия акции Попробовать

MWS Cloud Platform на DevOps Conf, 2–3 апреля, 2026 Подготовили программу нашего стенда — будем разбирать, как работают наши решения, играть, и отвечать на вопросы. Также запланировали техтоки по 10 минут в оба дня конференции. За лучший вопрос дарим мерч. Точное расписание докладов ищите на стенде. Приходите общаться, участвовать в наших активностях и забирать подарки!

Ребят, привет! Хочу авторизироваться в консоли, но не получается. Я нахожусь в Казахстане, поэтому когда ввожу номер телефона, мне блокируют ввод (у нас номера такие: +7 705 123 45 67). Вторую семёрку сразу отметают. Значит, другими способами не получится войти в консоль? (у меня точно нет SSO и MTS ID)

grpc отличное инженерное решение и разработчики его любят. Но мы делаем облако для обычных людей. И поэтому важно не выстраивать лишнюю стену между разработчиками и пользователями. Упущенные бенефиты я оцениваю как незначительные. Кодогенерация grpc для java отвратительная (для go сильно лучше). Код абсолютно не читаемый. А нам крайне важно, чтобы любой код был понятен и упрощал жизнь разработчика. Поэтому мы и написали свой генератор для openapi. Есть правда один важный нюанс - разработчики любят grpc. И вот это было самой большой проблемой при выборе openapi. Напишу при случае про это в своем тг канале :)

Поделюсь, когда выложим в конфлюенс

Добрый вечер, дорогая.

Добрый день. Спасибо за ваш вопрос. GLM-5/5.1 держим в поле зрения — модели действительно сильные, особенно для code generation. Сейчас они у нас в стадии оценки (смотрим на стабильность, требования к инфраструктуре и спрос со стороны клиентов). Точных сроков пока назвать не можем. Обо всех новых моделях будем сообщать в анонсах.

Приветствую. Есть ли апдейты?)

⚡️️️️Открываем ранний доступ к локальным дискам для виртуальных машин Локальные диски — это временные NVMe-хранилища. Они производительнее, чем сетевые диски, но не подразумевают гарантию сохранности данных. При остановке виртуальной машины данные с них стираются. Это сделано специально, т. к. ВМ после перезапуска может быть запущена на другом хосте. Локальные диски пригодятся в таких сценариях, как:
⚫️️️️Кеши, буферы и временные структуры баз данных. Важно использовать вместе с постоянными сетевыми дисками и/или в кластерной схеме, чтобы потеря локального диска не приводила к потере бизнес-данных ♦️Временные артефакты тяжёлых CI/CD-сборок (раннеры, кеши зависимостей и т. д.). Локальный диск помогает ускорить pipeline, если результаты сборки и важные артефакты затем сохраняются во внешнее хранилище ♦️Временная обработка данных (ETL, batch-задачи, рендеринг, промежуточные результаты расчётов). Данные загружаются из постоянного хранилища, быстро обрабатываются локально, а итоговый результат сохраняется обратно
Функциональность сейчас находится на стадии бета-тестирования и доступна бесплатно. Приглашаем вас попробовать и оставить обратную связь. Чтобы получить доступ, напишите в поддержку через виджет в консоли. Подробнее о локальных дисках читайте в документации.

Продолжаем рассказывать о технологиях MWS Cloud Platform! :) Сегодня поговорим о том, как мы выжимаем максимальную производительность из дисков виртуальных машин с помощью SPDK Когда виртуальная машина обращается к диску, данные должны дойти в хранилище максимально быстро и надёжно. Обычный kernel-based подход добавляет слишком много overhead: данные прыгают между гостевой ОС, QEMU и хостовой системой. Для сотен тысяч операций в секунду это становится узким местом. Наш коллега Василий Иванов, ведущий разработчик команды Data Storage, рассказывает, как мы использовали SPDK (Storage Performance Development Kit) — фреймворк Intel — для построения высокопроизводительных хранилищ в user-space. История получилась с большим количеством диагностики и неожиданных открытий! Фишки при использовании SPDK: 🔹 Kernel bypass через vhost-user — данные идут напрямую между VM и SPDK без лишних прыжков 🔹 Polling-модель вместо прерываний — ультранизкая латентность, лучше для NVMe Ключевые фишки нашего форка SPDK: 🔹 Поддержка 3000+ дисков в одном SPDK-инстансе 🔹 Поддержка vhost-user client mode — для более быстрого переподключения SPDK к VM 🔹 Расширенные статистики устройства — для лучшего observability 🔹 QoS на группы устройств — правильное ограничение нагрузки на уровне VM 🔹 Асинхронное API к Ceph — чтобы висящие операции не блокировали весь I/O-путь Несмотря на то что фреймворк существует не первый год, команда столкнулась с некоторыми проблемами на масштабах нашего облака. Поэтому приходилось тут и там допиливать SPDK. Например, мы пофиксили и отдали в upstream проблемы, возникающие с QoS, про что тоже рассказали в статье. 👉 Читайте подробности в статье на Хабре

Продолжаем рассказывать о технологиях MWS Cloud Platform! На этот раз — про объектное хранилище 🗄️ Когда нужно хранить петабайты данных с гарантией сохранности и при этом обеспечить линейное масштабирование, классические файловые системы не справляются. Как построить распределённое хранилище, которое выдерживает отказ двух серверов одновременно? Как обрабатывать миллионы запросов в секунду к метаданным? И главное — как обеспечить S3-совместимость без костылей? Наша команда разработки Object Storage подробно рассказывает про всю архитектуру хранилища в MWS Cloud Platform. От erasure coding на уровне данных до шардированного PostgreSQL для метаданных, который позволяет масштабировать систему горизонтально без единой точки отказа. Ключевые фишки нашего Object Storage: 🔹Erasure Coding 4+2 — выдерживаем отказ 2 нод с overhead всего 50% 🔹 Двухслойная архитектура (data layer на Ceph RADOS + metadata layer на PostgreSQL) 🔹 Шардирование метаданных — каждый bucket в своей базе для изоляции 🔹 Полная S3-совместимость (multipart upload, versioning, lifecycle policies) 🔹 Горизонтальное масштабирование до сотен петабайт Особая гордость — разделение слоёв данных и метаданных, где запросы к PostgreSQL обрабатываются независимо от RADOS, что позволяет масштабировать каждый компонент под свою нагрузку без переделки архитектуры. Читайте полную статью на Хабре

Спасибо, это и хотел увидеть!

То есть это тот же Ceph, только с RDMA? Или полностью с нуля SDS пилите?

Друзья, а задумывались, почему безопасность облака — это критично? Потому что взлом облачной платформы — это не просто утечка данных одной компании, а потенциальная катастрофа для сотен клиентов одновременно. Когда строишь облачную платформу, сталкиваешься с атаками, о которых обычные компании даже не подозревают. Есть классические взломы через уязвимости, но есть и экзотика: side-channel атаки типа Spectre и Meltdown, которые эксплуатируют особенности процессоров. Или атаки на dom0 — привилегированный домен гипервизора, через который можно добраться до Control Plane всего облака. Несколько интересных моментов из нашей практики: * Недавно сканировали периметр наших клиентов. Нашли пароль администратора VMware vCenter одного клиента прямо на GitHub. У других — 44 открытых порта баз данных и сотни незащищённых RDP. Предупредили всех, помогли закрыть дыры. * Применяем принцип defense in depth — если злоумышленник пробьёт один уровень защиты, он всё равно не сможет пройти дальше. При этом мы увидим его на скомпрометированном эшелоне и остановим атаку. Каждый слой независим и имеет свои механизмы мониторинга. * Внедрили Security Design Review — анализируем безопасность каждой новой фичи ещё на этапе проектирования. Выявляем потенциальные угрозы до того, как код попадёт в продакшн. * Проблема dependency confusion: разработчики любят использовать тег latest для Docker-образов. Хакеры создают вредоносные образы с очень высокими версиями и публикуют в открытых реестрах. При автоматическом обновлении CI/CD подтягивает именно их. Мы отслеживаем все зависимости и проверяем каждый компонент. Почему это критично прямо сейчас? Недавний кейс: крупный российский агрохолдинг поймал шифровальщик. Хакеры потребовали 70 биткоинов — это больше 600 миллионов рублей. Для сравнения: это годовой бюджет на всю информационную безопасность крупной корпорации. В облаке многие проблемы решаются автоматически: активы инвентаризированы, патчи ставятся централизованно, мониторинг работает 24/7. Плюс аттестация по требованиям регуляторов уже проведена — клиентам не нужно проходить это самостоятельно. Подробнее обо всём этом — в большой статье нашего CISO Виктора Бобылькова на Хабре. Там про vulnerability management, управление доступами, анализ компонентов и зависимостей, и как мы помогаем клиентам не стать следующей жертвой киберпреступников.Retry