Начну со второго вопроса: да, NUMA-топологию учитываем, cross-numa ВМок нет.
—
Про частичное выделение ядер (shared-core) всё немного сложнее, чем может показаться на первый взгляд. Здесь есть несколько факторов.
Во-первых, если посмотреть на практики крупных российских и зарубежных провайдеров, то можно заметить, что конфигурации с shared-core обычно ограничены небольшими размерами — как правило, до 4 vCPU, а у зарубежных провайдеров часто и до 2 vCPU. Это связано с тем, что по мере роста размера ВМ эффект переподписки становится значительно более заметным: увеличиваются задержки, ухудшается предсказуемость производительности. В результате такие ВМ плохо подходят для большинства enterprise-нагрузок, на которые мы ориентируемся на старте. Сегмент solo-разработчиков и SMB для нас тоже важен, но решения для него мы планируем вводить чуть позже.
Во-вторых, у нас пока нет поддержки живой миграции. Без возможности “на горячую” перемещать ВМ между хостами и балансировать нагрузку, модель с shared-core становится значительно менее управляемой и более рискованной с точки зрения качества сервиса.
В итоге, если делать shared-core, то важно реализовать его так, чтобы он действительно давал экономию пользователю, но при этом минимизировал деградацию производительности и непредсказуемость. Для этого требуется дополнительная проработка и время, поэтому мы подходим к этому вопросу постепенно.
Вообще нет переподписки или все же есть разные флейворы?
В текущей линейке — без переподписки CPU вообще: мы не размещаем больше vCPU, чем есть физических потоков на хосте. Это осознанное решение для предсказуемой производительности. В будущем планируем добавить более «экономичные» типы ВМ.
А как вы резервируете ядра за процессом qemu? Или всё же это не резервирование и просто не размещаете больше чем есть на хосте?
Мы используем CPU pinning: наш агент на хосте при старте ВМ задаёт конкретное соответствие vCPU → pCPU, и эти ядра закрепляются за процессом QEMU. Две ВМ не могут попасть на один и тот же поток — конкуренция исключена на уровне планирования.
И что насчёт hyper threading, vcpu считаются с по потокам или по ядрам?
vCPU у нас = один поток (hardware thread). При этом мы даём конфигурации кратные 2, чтобы фактически выделять целое физическое ядро (оба потока одного ядра) одной ВМ — это убирает конкуренцию внутри ядра и даёт более стабильную производительность.
Вижу, что мой коллега на часть вопросов ответил, но я решил все же раскрыть подробнее по пунктам
Два ЦОДа в Москве, это две зоны отказоустойчивости или два здания в пределах МКАД? Если второе, как вы гарантируете RPO < 5 мин при ЧС городского масштаба, например, кабельный срез по всем маршрутам?
Два ЦОДа представляют собой две зоны доступности (AZ) в одном регионе (Московская область). В каждой зоне развёрнут собственный зональный control plane, а между зонами обеспечена связность через независимые каналы связи, проложенные по разным физическим маршрутам. Такая архитектура позволяет сохранять работоспособность сервисов при отказе одной из зон.
Данные реплицируются между зонами с использованием тройной репликации (ниже в комментарии расписал подробнее). В объектном хранилище данные изначально размещаются с учётом мультизональности, а для дисков виртуальных машин используются механизмы снапшотов и репликации. При этом отказ одной зоны не приводит к потере уже записанных данных, однако фактический RPO зависит от механизма записи и может быть ненулевым.
Минимум 2 vCPU на ВМ, это архитектурное ограничение гипервизора или бизнес-решение? Для микросервисов с нагрузкой 0.2 vCPU это прямой оверхед 900%. Как обосновываете?
"Нет овербукинга", звучит очень честно, пока не посчитаешь TCO. Приведите сравнение стоимости 100 ВМ с нагрузкой 15% CPU против аналогичного кластера на Selectel/Yandex и пожалуйста цифры, не принципы.
1 vCPU = 1 физическое ядро или 1 HT-поток? Если поток, то как решаете contention при одновременной нагрузке соседей на разные потоки одного ядра?
2 vCPU на ВМ это бизнес-решение для нашего основного типа ВМ – новых мощных процессоров без переподписки. Оно связано с вопросом про гипертрединг: 1 vCPU – это 1 поток на физическом ядре. Чтобы не возникало конкуренции, конфигурации ВМ по vCPU кратны 2, то есть мы всегда выделяем целые ядра.
Соглашусь, что такой уровень производительности и стабильности не всегда нужен, например для микросервисов, если разносить их по разным ВМ, или dev-окружений. В будущем мы планируем запуск более экономичных типов ВМ.
А сейчас можно воспользоваться нашим Managed Kubernetes – он решает задачу шеринга ресурсов и оптимальной утилизации ресурсов, особенно в сочетании с функцией автоскейлинга.
Собственный стек вместо OpenStack окей, но где публичная документация по API? Поддержка Terraform provider есть или писать свой на коленке?
Сразу отвечу на вопрос из соседнего комметария: нет, сейчас TF-провайдера в официальном реестре HashiCorp нет по тем же причинам, по которым registry.terraform.io недоступен из России :) Скачать можно в виде бинаря или через пакетный менеджер, описали в доке детали. Инструмент поддерживается командой облака и постоянно дорабатывается по мере появления новой функциональности и сервисов.
Документация API сейчас в процессе подготовки публикации на GitHub в формате OpenAPI спецификаций, однако есть альфа-версия. Можно написать мне телеграм (t.me/tsalkin) – пришлю прямую ссылку.
Цены в статье отсутствуют полностью. Это такой маркетинговый приём или политика "звоните, менеджер посчитает"? Для архитектора сразу красный флаг.
Цены на все сервисы и принципы тарификации у нас опубликованы в документации по сервисам. Например, вот цены по Compute и VPC.
Также у нас на странице Compute на сайте есть калькулятор для удобства расчёта.
В статье мы осознанно не указывали цены, на мой взгляд это было бы совсем рекламно 🙂
Производительность диска отвязана от объёма, это круто, но какая максимальная пропускная способность на ВМ? 1 Гбит/с? 10? Или как у некоторых "облаков" 300 Мбит/с и никакого SLA на сетку?
Пропускная способность сети для виртуальных машин (взаимодействие ВМ-ВМ и внешний трафик) составляет до 15 Гбит/с на ВМ.
Для сетевых дисков производительность определяется заданным количеством IOPS. При максимальном значении 10 000 IOPS пропускная способность достигает ~313 Мбит/с (при типовом размере блока 4 КБ).
Фактическая производительность может зависеть от характера нагрузки, а также от конфигурации виртуальной машины.
Тройная репликация "между двумя зонами", это 2+1 или 1+1+1? Если первое, то при потере одной зоны вы мгновенно теряете отказоустойчивость. Это осознанный компромисс?
У объектного хранилища для обеспечения сохранности данных используется erasure coding в режиме 4 + 2 и полная асинхронная репликация данных между 2 зонами, что даёт по итогу тройную репликацию. При этом для erasure coding домен отказа – стойка.
Кластеры БД для метаданных также разнесены по 2 зонам: мастер + реплика в одной и 2 реплики в другой.
DDoS-защита на уровне сети есть или клиент сам тянет трафик через сторонние фильтры?
На стороне облака мы обеспечиваем защиту сетевой инфраструктуры от volumetric DDoS-атак на уровне L3–L4 (каналы и базовая доступность сервисов). Прикладной уровень (L7 — HTTP/HTTPS и др.) находится в зоне ответственности клиента: при необходимости можем предложить услуги наших партнёров и помощь с интеграцией.
Есть ли публичный SLA на доступность ВМ и дисков, и какие компенсации при его нарушении?
Пиринг с Google/Cloudflare/Microsoft есть напрямую или весь исходящий трафик идёт через одного транзитного оператора?
Сетевая связность платформы построена на модели с использованием нескольких независимых магистральных каналов и подключением к точкам обмена трафиком (IX).
Прямой пиринг с зарубежными облачными провайдерами может быть ограничен внешними факторами, доступ к их ресурсам обеспечивается через интернет-транзит и существующую инфраструктуру операторов связи.
Снапшоты CoW ок, но сколько стоит хранение дельты в месяц? У некоторых провайдеров "бесплатный снапшот" превращается в 30% к стоимости диска за хранение инкрементов.
Как быстро работает миграция ВМ между хостами без даунтайма? Менее 30 сек или как в старых решениях 2–3 минуты с потерей сетевого стека?
Если речь о живой миграции, то она пока в разработке, рассчитываем выкатить до конца 2026 года. В первой версии ожидаем кратковременную недоступность сети порядка 10–20 секунд в момент переключения, при этом сетевой стек не теряется, а сами TCP-соединения обычно переживают это за счёт ретраев; общее время миграции может быть больше и зависит от памяти и нагрузки, но для пользователя оно почти незаметно, так как основная часть проходит в фоне.
У вас свои ЦОДы, супер, но кто поставщик питания и есть ли независимые вводы от разных подстанций?
Подробнее о ЦОДах, в которых живёт новая платформа можно почитать на сайтах:
И последнее, почему в статье, где вы пишите "что надёжность инфраструктуры и гибкость сервисов — это те требования, от которых нельзя отступать. И чтобы выполнить их честно, мы сделали ставку на два принципа: собственную физическую инфраструктуру и собственную разработку." нет ни одной цифры по ценам, ни одного бенчмарка, ни одного кейса клиентов, только лозунги?
Все очень просто: мы хотели сделать статью не маркетинговым проспектом, а чуть больше рассказать о том, как и почему дизайнили архитектуру и функциональность IaaS.
Цены, бенчмарки и успешные кейсы у нас тоже, конечно, есть, но они имеют смысл в контексте конкретных кейсов. Поэтому всегда будем рады пообщаться и подробно ответить на вопросы. Можно оставить завявку на сайте или написать мне лично t.me/tsalkin.
Привет! На связи Родион Цалкин, продакт IaaS-сервисов в MWS Cloud Platform.
Спасибо за подробный обзор — нам важна обратная связь от сообщества.
Вы правы, что подавляющее большинство сервисов находятся в стадии Preview, и мы сознательно просим относиться к ним именно как к ранней версии продукта. Нам важно получить обратную связь как можно раньше, чтобы лучше понимать потребности реальных пользователей.
Некоторые функции у нас есть уже сейчас — например, назначение внешнего IP, автоматическое шифрование дисков, выбор операционных систем, загрузка больших объектов в объектное хранилище. Если при тестировании они остались незамеченными, это для нас сигнал: будем делать интерфейс и документацию ещё понятнее и удобнее.
При этом мы понимаем ваши ожидания в отношении тех фич платформы, которых действительно не хватает. Команда непрерывно работает над новой функциональностью сервисов, поэтому мы будем рады вашей обратной связи после выхода в general availability.
Если у вас возникнут любые вопросы, у нас есть сообщество в Telegram, где команда оперативно отвечает и помогает. Там же можно следить за анонсами новой функциональности.
Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать.
Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
RnD задачи не вписываются в спринты
Важно разделять этап Discovery и Delivery фичи. На этапе Discovery продакт (или другой стейхолодер) изучает и описывает фичу, а разработчик (техлид, CTO) анализирует ее техническую реализуемость. И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
Однако ловкие продавцы церемоний усвоили только часть:
процесс важнее всего
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить. Как минимум потому что иначе это перестает быть управляемым.
И чем крупнее организация, тем более единообразными хочется делать эти процессы.
Инструменты Kanban, такие как проиретизация задач и WIP limit, дают возможность управлять потоком работы, не прерывая сам рабочий процесс.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер? Потому что если не опираться на размер задачи, то WiP всегда должен быть =1, иначе большие задачи будут висеть на разработчике очень и очень долго.
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.
Начну со второго вопроса: да, NUMA-топологию учитываем, cross-numa ВМок нет.
—
Про частичное выделение ядер (shared-core) всё немного сложнее, чем может показаться на первый взгляд. Здесь есть несколько факторов.
Во-первых, если посмотреть на практики крупных российских и зарубежных провайдеров, то можно заметить, что конфигурации с shared-core обычно ограничены небольшими размерами — как правило, до 4 vCPU, а у зарубежных провайдеров часто и до 2 vCPU. Это связано с тем, что по мере роста размера ВМ эффект переподписки становится значительно более заметным: увеличиваются задержки, ухудшается предсказуемость производительности. В результате такие ВМ плохо подходят для большинства enterprise-нагрузок, на которые мы ориентируемся на старте. Сегмент solo-разработчиков и SMB для нас тоже важен, но решения для него мы планируем вводить чуть позже.
Во-вторых, у нас пока нет поддержки живой миграции. Без возможности “на горячую” перемещать ВМ между хостами и балансировать нагрузку, модель с shared-core становится значительно менее управляемой и более рискованной с точки зрения качества сервиса.
В итоге, если делать shared-core, то важно реализовать его так, чтобы он действительно давал экономию пользователю, но при этом минимизировал деградацию производительности и непредсказуемость. Для этого требуется дополнительная проработка и время, поэтому мы подходим к этому вопросу постепенно.
В текущей линейке — без переподписки CPU вообще: мы не размещаем больше vCPU, чем есть физических потоков на хосте. Это осознанное решение для предсказуемой производительности. В будущем планируем добавить более «экономичные» типы ВМ.
Мы используем CPU pinning: наш агент на хосте при старте ВМ задаёт конкретное соответствие vCPU → pCPU, и эти ядра закрепляются за процессом QEMU. Две ВМ не могут попасть на один и тот же поток — конкуренция исключена на уровне планирования.
vCPU у нас = один поток (hardware thread). При этом мы даём конфигурации кратные 2, чтобы фактически выделять целое физическое ядро (оба потока одного ядра) одной ВМ — это убирает конкуренцию внутри ядра и даёт более стабильную производительность.
Вижу, что мой коллега на часть вопросов ответил, но я решил все же раскрыть подробнее по пунктам
Два ЦОДа представляют собой две зоны доступности (AZ) в одном регионе (Московская область). В каждой зоне развёрнут собственный зональный control plane, а между зонами обеспечена связность через независимые каналы связи, проложенные по разным физическим маршрутам. Такая архитектура позволяет сохранять работоспособность сервисов при отказе одной из зон.
2 vCPU на ВМ это бизнес-решение для нашего основного типа ВМ – новых мощных процессоров без переподписки. Оно связано с вопросом про гипертрединг: 1 vCPU – это 1 поток на физическом ядре. Чтобы не возникало конкуренции, конфигурации ВМ по vCPU кратны 2, то есть мы всегда выделяем целые ядра.
Соглашусь, что такой уровень производительности и стабильности не всегда нужен, например для микросервисов, если разносить их по разным ВМ, или dev-окружений. В будущем мы планируем запуск более экономичных типов ВМ.
А сейчас можно воспользоваться нашим Managed Kubernetes – он решает задачу шеринга ресурсов и оптимальной утилизации ресурсов, особенно в сочетании с функцией автоскейлинга.
Terraform provider есть, вот документация https://mws.ru/docs/cloud-platform/terraform/general/whatis-terraform.html.
Сразу отвечу на вопрос из соседнего комметария: нет, сейчас TF-провайдера в официальном реестре HashiCorp нет по тем же причинам, по которым registry.terraform.io недоступен из России :) Скачать можно в виде бинаря или через пакетный менеджер, описали в доке детали. Инструмент поддерживается командой облака и постоянно дорабатывается по мере появления новой функциональности и сервисов.
Документация API сейчас в процессе подготовки публикации на GitHub в формате OpenAPI спецификаций, однако есть альфа-версия. Можно написать мне телеграм (t.me/tsalkin) – пришлю прямую ссылку.
Цены на все сервисы и принципы тарификации у нас опубликованы в документации по сервисам. Например, вот цены по Compute и VPC.
https://mws.ru/docs/cloud-platform/compute/general/pricing.html
https://mws.ru/docs/cloud-platform/vpc/general/whatis-vpc.html
Также у нас на странице Compute на сайте есть калькулятор для удобства расчёта.
В статье мы осознанно не указывали цены, на мой взгляд это было бы совсем рекламно 🙂
Пропускная способность сети для виртуальных машин (взаимодействие ВМ-ВМ и внешний трафик) составляет до 15 Гбит/с на ВМ.
Для сетевых дисков производительность определяется заданным количеством IOPS. При максимальном значении 10 000 IOPS пропускная способность достигает ~313 Мбит/с (при типовом размере блока 4 КБ).
Фактическая производительность может зависеть от характера нагрузки, а также от конфигурации виртуальной машины.
У объектного хранилища для обеспечения сохранности данных используется erasure coding в режиме 4 + 2 и полная асинхронная репликация данных между 2 зонами, что даёт по итогу тройную репликацию. При этом для erasure coding домен отказа – стойка.
Кластеры БД для метаданных также разнесены по 2 зонам: мастер + реплика в одной и 2 реплики в другой.
Подробнее можно почитать в нашей статье: https://habr.com/ru/companies/mws/articles/979254/
На стороне облака мы обеспечиваем защиту сетевой инфраструктуры от volumetric DDoS-атак на уровне L3–L4 (каналы и базовая доступность сервисов). Прикладной уровень (L7 — HTTP/HTTPS и др.) находится в зоне ответственности клиента: при необходимости можем предложить услуги наших партнёров и помощь с интеграцией.
Да, для всех сервисов в General Availability установлен SLA, если это применимо. Тут можно почитать подробнее про Compute: https://mws.ru/docs/cloud-platform/compute/general/compute-sla.html
Сетевая связность платформы построена на модели с использованием нескольких независимых магистральных каналов и подключением к точкам обмена трафиком (IX).
Прямой пиринг с зарубежными облачными провайдерами может быть ограничен внешними факторами, доступ к их ресурсам обеспечивается через интернет-транзит и существующую инфраструктуру операторов связи.
Стоимость хранения описана в документации: https://mws.ru/docs/cloud-platform/compute/general/pricing.html
Если речь о живой миграции, то она пока в разработке, рассчитываем выкатить до конца 2026 года. В первой версии ожидаем кратковременную недоступность сети порядка 10–20 секунд в момент переключения, при этом сетевой стек не теряется, а сами TCP-соединения обычно переживают это за счёт ретраев; общее время миграции может быть больше и зависит от памяти и нагрузки, но для пользователя оно почти незаметно, так как основная часть проходит в фоне.
Подробнее о ЦОДах, в которых живёт новая платформа можно почитать на сайтах:
ЦОД Гринбуш: https://greendc.ru/
ЦОД Авантаж: https://alldc.ru/dcs/cod/736.html
Все очень просто: мы хотели сделать статью не маркетинговым проспектом, а чуть больше рассказать о том, как и почему дизайнили архитектуру и функциональность IaaS.
Цены, бенчмарки и успешные кейсы у нас тоже, конечно, есть, но они имеют смысл в контексте конкретных кейсов. Поэтому всегда будем рады пообщаться и подробно ответить на вопросы. Можно оставить завявку на сайте или написать мне лично t.me/tsalkin.
Привет! На связи Родион Цалкин, продакт IaaS-сервисов в MWS Cloud Platform.
Спасибо за подробный обзор — нам важна обратная связь от сообщества.
Вы правы, что подавляющее большинство сервисов находятся в стадии Preview, и мы сознательно просим относиться к ним именно как к ранней версии продукта. Нам важно получить обратную связь как можно раньше, чтобы лучше понимать потребности реальных пользователей.
Некоторые функции у нас есть уже сейчас — например, назначение внешнего IP, автоматическое шифрование дисков, выбор операционных систем, загрузка больших объектов в объектное хранилище. Если при тестировании они остались незамеченными, это для нас сигнал: будем делать интерфейс и документацию ещё понятнее и удобнее.
При этом мы понимаем ваши ожидания в отношении тех фич платформы, которых действительно не хватает. Команда непрерывно работает над новой функциональностью сервисов, поэтому мы будем рады вашей обратной связи после выхода в general availability.
Если у вас возникнут любые вопросы, у нас есть сообщество в Telegram, где команда оперативно отвечает и помогает. Там же можно следить за анонсами новой функциональности.
Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
Важно разделять этап Discovery и Delivery фичи. На этапе Discovery продакт (или другой стейхолодер) изучает и описывает фичу, а разработчик (техлид, CTO) анализирует ее техническую реализуемость. И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить. Как минимум потому что иначе это перестает быть управляемым.
И чем крупнее организация, тем более единообразными хочется делать эти процессы.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер? Потому что если не опираться на размер задачи, то WiP всегда должен быть =1, иначе большие задачи будут висеть на разработчике очень и очень долго.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.