Комментарии 12
Мы сознательно отказались от овербукинга CPU. Минимальная конфигурация — 2 vCPU, и эти ядра полностью закреплены за виртуальной машиной.
Вообще нет переподписки или все же есть разные флейворы?
А как вы резервируете ядра за процессом qemu? Или всё же это не резервирование и просто не размещаете больше чем есть на хосте?
И что насчёт hyper threading, vcpu считаются с по потокам или по ядрам?
Вообще нет переподписки или все же есть разные флейворы?
В текущей линейке — без переподписки CPU вообще: мы не размещаем больше vCPU, чем есть физических потоков на хосте. Это осознанное решение для предсказуемой производительности. В будущем планируем добавить более «экономичные» типы ВМ.
А как вы резервируете ядра за процессом qemu? Или всё же это не резервирование и просто не размещаете больше чем есть на хосте?
Мы используем CPU pinning: наш агент на хосте при старте ВМ задаёт конкретное соответствие vCPU → pCPU, и эти ядра закрепляются за процессом QEMU. Две ВМ не могут попасть на один и тот же поток — конкуренция исключена на уровне планирования.
И что насчёт hyper threading, vcpu считаются с по потокам или по ядрам?
vCPU у нас = один поток (hardware thread). При этом мы даём конфигурации кратные 2, чтобы фактически выделять целое физическое ядро (оба потока одного ядра) одной ВМ — это убирает конкуренцию внутри ядра и даёт более стабильную производительность.
без переподписки CPU
Это здорово и подход понятен, но все же странновато выглядит для паблика не давать на старте варианты 1/3 или 1/5, а сразу начинать с 1/1 :)
Мы используем CPU pinning
А топология NUMA учитывается при этом?
Начну со второго вопроса: да, NUMA-топологию учитываем, cross-numa ВМок нет.
—
Про частичное выделение ядер (shared-core) всё немного сложнее, чем может показаться на первый взгляд. Здесь есть несколько факторов.
Во-первых, если посмотреть на практики крупных российских и зарубежных провайдеров, то можно заметить, что конфигурации с shared-core обычно ограничены небольшими размерами — как правило, до 4 vCPU, а у зарубежных провайдеров часто и до 2 vCPU. Это связано с тем, что по мере роста размера ВМ эффект переподписки становится значительно более заметным: увеличиваются задержки, ухудшается предсказуемость производительности. В результате такие ВМ плохо подходят для большинства enterprise-нагрузок, на которые мы ориентируемся на старте. Сегмент solo-разработчиков и SMB для нас тоже важен, но решения для него мы планируем вводить чуть позже.
Во-вторых, у нас пока нет поддержки живой миграции. Без возможности “на горячую” перемещать ВМ между хостами и балансировать нагрузку, модель с shared-core становится значительно менее управляемой и более рискованной с точки зрения качества сервиса.
В итоге, если делать shared-core, то важно реализовать его так, чтобы он действительно давал экономию пользователю, но при этом минимизировал деградацию производительности и непредсказуемость. Для этого требуется дополнительная проработка и время, поэтому мы подходим к этому вопросу постепенно.
Да, без миграции будет трудновато управлять плотностью и балансировать нагрузку.
А почему сразу не заложили ее реализацию? У вас даже плановые работы будут неизбежно приводить к простою/ребуту части VM клиентов? Учитывая фокус на сегмент выше SMB/lab/etc, выглядит неприятно.
Даже если не брать в учёт одиночные инстансы, далеко не все виды кластеров без проблем переживают такие события.
Возникает небольшое количество вопросов в связи с вашей публикацией:
Два ЦОДа в Москве, это две зоны отказоустойчивости или два здания в пределах МКАД? Если второе, как вы гарантируете RPO < 5 мин при ЧС городского масштаба, например, кабельный срез по всем маршрутам?
Минимум 2 vCPU на ВМ, это архитектурное ограничение гипервизора или бизнес-решение? Для микросервисов с нагрузкой 0.2 vCPU это прямой оверхед 900%. Как обосновываете?
"Нет овербукинга", звучит очень честно, пока не посчитаешь TCO. Приведите сравнение стоимости 100 ВМ с нагрузкой 15% CPU против аналогичного кластера на Selectel/Yandex и пожалуйста цифры, не принципы.
1 vCPU = 1 физическое ядро или 1 HT-поток? Если поток, то как решаете contention при одновременной нагрузке соседей на разные потоки одного ядра?
Собственный стек вместо OpenStack окей, но где публичная документация по API? Поддержка Terraform provider есть или писать свой на коленке?
Цены в статье отсутствуют полностью. Это такой маркетинговый приём или политика "звоните, менеджер посчитает"? Для архитектора сразу красный флаг.
Производительность диска отвязана от объёма, это круто, но какая максимальная пропускная способность на ВМ? 1 Гбит/с? 10? Или как у некоторых "облаков" 300 Мбит/с и никакого SLA на сетку?
Тройная репликация "между двумя зонами", это 2+1 или 1+1+1? Если первое, то при потере одной зоны вы мгновенно теряете отказоустойчивость. Это осознанный компромисс?
DDoS-защита на уровне сети есть или клиент сам тянет трафик через сторонние фильтры?
Есть ли публичный SLA на доступность ВМ и дисков, и какие компенсации при его нарушении?
Пиринг с Google/Cloudflare/Microsoft есть напрямую или весь исходящий трафик идёт через одного транзитного оператора?
Снапшоты CoW ок, но сколько стоит хранение дельты в месяц? У некоторых провайдеров "бесплатный снапшот" превращается в 30% к стоимости диска за хранение инкрементов.
Как быстро работает миграция ВМ между хостами без даунтайма? Менее 30 сек или как в старых решениях 2–3 минуты с потерей сетевого стека?
У вас свои ЦОДы, супер, но кто поставщик питания и есть ли независимые вводы от разных подстанций?
И последнее, почему в статье, где вы пишите "что надёжность инфраструктуры и гибкость сервисов — это те требования, от которых нельзя отступать. И чтобы выполнить их честно, мы сделали ставку на два принципа: собственную физическую инфраструктуру и собственную разработку." нет ни одной цифры по ценам, ни одного бенчмарка, ни одного кейса клиентов, только лозунги?
Жду ответы, посчитаю реальный TCO под наш стек, пока выглядит как красивая презентация без цифр для принятия решения.
Вы правда ожидали цены в технической (пусть и pr-технической, но тут большая часть таких) статье?
Техническая статья без цен ок, норм. Но техническая статья, которая одновременно:
хвастается отказом от овербукинга (звучит как этический подвиг),
кричит "предсказуемость",
и при этом тщательно убирает единственный параметр, по которому архитектор оценивает предсказуемость, стоимость,
это не техническая статья. Это попытка прикинуться инженером, чтобы потом впаять клиенту ценник как у конкурентов, но чуть дороже, потому что мы честные. Если хочешь писать про честность, пиши цифры. Если не хочешь писать цифры, не используй слово "честное". Это не сложно. Это базовая честность с самим собой. А вопрос "вы правда ожидали цены", звучит так, будто вы только что спросили: "Вы правда ожидали, что еда в ресторане будет съедобной?" Нет. Я ожидал меню. Без цен, это не ресторан. Это социальная столовая.
Добрый день.
Помогу коллеге ответить на часть вопросов:
1) Клиентские ресурсы расположены в дата центрах Авантаж (Лыткарино) и Гринбуш (Зеленоград).
2) Выдаём четное количество vCPU во избежание запуска процессов разных ВМ на одном физическом ядре
4) vCPU = поток, см. выше
5) https://mws.ru/docs/api/ поддержка Terraform есть
9) Есть партнёр, предоставляющий защиту от DDoS
10) https://mws.ru/docs/cloud-platform/compute/general/compute-sla.html
15) Невозможно все охватить в рамках одной статьи
Спасибо за ответы, но часть из них только подтверждает слабые места:
1) Лыткарино + Зеленоград оба в пределах Московской агломерации. При ЧС на уровне региона (кабельный коридор Москвы, авария на МРСК Центра) оба ЦОДа в зоне риска. Это не multi-region, это две зоны в одной географической точке отказа. Для критичных систем, недостаточно.
2) "Чётное количество vCPU во избежание запуска разных ВМ на одном ядре", логика странная. Если 1 физ. ядро = 2 HT-потока, то 2 vCPU = оба потока одного ядра. Вы не избегаете соседей, вы просто гарантируете, что ядро целиком отдано одной ВМ. Но тогда вопрос: почему нельзя 1 vCPU (один поток)? Для бота, фонового воркера, микросервиса с нагрузкой 0.1 ядра это прямой оверхед 900%. Это не техническое ограничение, это бизнес-решение. Признайте честно.
3) vCPU = поток, ок. Тогда при нагрузке 15% CPU вы платите за простаивающие 85% потока. И за второй поток того же ядра, который тоже простаивает. Без овербукинга это не честность, это неэффективность, переложенная на клиента.
4) "Поддержка Terraform есть", в документации вижу только описание REST API. Официальный провайдер в реестре HashiCorp registry.terraform.io есть? Или речь про кастомный модуль на коленке? Для автоматизации это разные вещи.
5) "Есть партнёр по DDoS" не есть встроенная защита. Это "идите сами настраивайте, платите третьей стороне, разбирайтесь с маршрутизацией". У Яндекса защита на уровне сети "из коробки".
6) Посмотрел, например "99,0% — 99,99% | простой от 4 мин 19 сек до 43 мин 11 сек | компенсация 5%", но проблема в том, что 99,0% в калькуляторе, это 7 часов простоя с компенсацией 5%. Серьезно?
7) "Невозможно всё охватить", цены не деталь для углублённого анализа. Цена это первое, что смотрит архитектор при сравнении платформ. Статья позиционируется как про честность, но базовый элемент честности, стоимость владения, убран за рамки. Это не техническая необходимость, это маркетинговый выбор.
Вижу, что мой коллега на часть вопросов ответил, но я решил все же раскрыть подробнее по пунктам
Два ЦОДа в Москве, это две зоны отказоустойчивости или два здания в пределах МКАД? Если второе, как вы гарантируете 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 есть или писать свой на коленке?
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 на сайте есть калькулятор для удобства расчёта.
В статье мы осознанно не указывали цены, на мой взгляд это было бы совсем рекламно 🙂
Производительность диска отвязана от объёма, это круто, но какая максимальная пропускная способность на ВМ? 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 реплики в другой.
Подробнее можно почитать в нашей статье: https://habr.com/ru/companies/mws/articles/979254/
DDoS-защита на уровне сети есть или клиент сам тянет трафик через сторонние фильтры?
На стороне облака мы обеспечиваем защиту сетевой инфраструктуры от volumetric DDoS-атак на уровне L3–L4 (каналы и базовая доступность сервисов). Прикладной уровень (L7 — HTTP/HTTPS и др.) находится в зоне ответственности клиента: при необходимости можем предложить услуги наших партнёров и помощь с интеграцией.
Есть ли публичный SLA на доступность ВМ и дисков, и какие компенсации при его нарушении?
Да, для всех сервисов в General Availability установлен SLA, если это применимо. Тут можно почитать подробнее про Compute: https://mws.ru/docs/cloud-platform/compute/general/compute-sla.html
Пиринг с Google/Cloudflare/Microsoft есть напрямую или весь исходящий трафик идёт через одного транзитного оператора?
Сетевая связность платформы построена на модели с использованием нескольких независимых магистральных каналов и подключением к точкам обмена трафиком (IX).
Прямой пиринг с зарубежными облачными провайдерами может быть ограничен внешними факторами, доступ к их ресурсам обеспечивается через интернет-транзит и существующую инфраструктуру операторов связи.
Снапшоты CoW ок, но сколько стоит хранение дельты в месяц? У некоторых провайдеров "бесплатный снапшот" превращается в 30% к стоимости диска за хранение инкрементов.
Стоимость хранения описана в документации: https://mws.ru/docs/cloud-platform/compute/general/pricing.html
Как быстро работает миграция ВМ между хостами без даунтайма? Менее 30 сек или как в старых решениях 2–3 минуты с потерей сетевого стека?
Если речь о живой миграции, то она пока в разработке, рассчитываем выкатить до конца 2026 года. В первой версии ожидаем кратковременную недоступность сети порядка 10–20 секунд в момент переключения, при этом сетевой стек не теряется, а сами TCP-соединения обычно переживают это за счёт ретраев; общее время миграции может быть больше и зависит от памяти и нагрузки, но для пользователя оно почти незаметно, так как основная часть проходит в фоне.
У вас свои ЦОДы, супер, но кто поставщик питания и есть ли независимые вводы от разных подстанций?
Подробнее о ЦОДах, в которых живёт новая платформа можно почитать на сайтах:
ЦОД Гринбуш: https://greendc.ru/
ЦОД Авантаж: https://alldc.ru/dcs/cod/736.html
И последнее, почему в статье, где вы пишите "что надёжность инфраструктуры и гибкость сервисов — это те требования, от которых нельзя отступать. И чтобы выполнить их честно, мы сделали ставку на два принципа: собственную физическую инфраструктуру и собственную разработку." нет ни одной цифры по ценам, ни одного бенчмарка, ни одного кейса клиентов, только лозунги?
Все очень просто: мы хотели сделать статью не маркетинговым проспектом, а чуть больше рассказать о том, как и почему дизайнили архитектуру и функциональность IaaS.
Цены, бенчмарки и успешные кейсы у нас тоже, конечно, есть, но они имеют смысл в контексте конкретных кейсов. Поэтому всегда будем рады пообщаться и подробно ответить на вопросы. Можно оставить завявку на сайте или написать мне лично t.me/tsalkin.
Спасибо за развернутые ответы, но пара моментов требует уточнения, потому что маркетинг и реальность немного расходятся:
Про 2 vCPU, вы сами признали, что это бизнес-решение, а не техническая необходимость. И что в будущем запустим экономичные типы. То есть сегодня клиент с микросервисом на 0.2 ядра сознательно переплачивает 900%, потому что ваша архитектура не умеет шарить ядра между ВМ. Выглядит как перекладывание неэффективности на клиента. Возможно лучше так и написать, типа минимум 2 vCPU, это временный компромисс ради упрощения архитектуры.
Про цены с натяжкой принято, по мне этого действительно не хватает, чтобы принять решение, потому что кроме прочтения статьи, надо пойти и найти прайсы. Ну ок.
Про миграцию ВМ, ок, ожидаем, у конкурентов она реализована, ведь это не просто фича, это база для обновления гипервизоров без даунтайма продакшена. Значит пока ваше облако не позволяет обновлять инфраструктуру без остановки ВМ.
Про географию, где две зоны в Московской области, при ЧС на уровне региона оба ЦОДа в одной точке отказа. Вы сами написали, что фактический RPO зависит от механизма записи и может быть ненулевым. То есть при городской аварии гарантирована потеря данных. Для критичных систем это осознанный риск, который клиент должен знать до выбора платформы.
Пока просто хорошая техническая база, но маркетинговая упаковка не соответствует зрелости платформы, потому что не хватает расклада по ограничениям и рискам.
Базовый минимум или роскошный максимум: как устроен IaaS в MWS Cloud Platform