За время работы в облаке я убедился в одной простой вещи: сколько бы сервисов ни предлагало облако — Kubernetes, Serverless, базы данных, Big Data или AI-сервисы, — всё это работает только потому, что под ними есть прочный фундамент: виртуальные машины, диски и сети. Этот фундамент и называется IaaS. Он важен и для клиентов, и для самого облачного провайдера: все сервисы строятся поверх него, а уровень этой базы определяет надёжность и скорость создания сервисов.
Всем привет! Меня зовут Родион Цалкин, TPO в MWS Cloud Platform. Сегодня поговорим о IaaS-слое.
Когда мы начали создавать новую инфраструктурную платформу MWS Cloud Platform, мы решили, что надёжность инфраструктуры и гибкость сервисов — это те требования, от которых нельзя отступать. И чтобы выполнить их честно, мы сделали ставку на два принципа: собственную физическую инфраструктуру и собственную разработку.
Своя инфраструктура как основа надёжности
Наша платформа работает в двух московских ЦОДах MWS, соединённых независимыми каналами связи, проложенными по разным маршрутам. Такое кольцо вокруг города даёт и минимальные задержки, и устойчивость при любых внешних воздействиях, например физических повреждениях кабелей.
Полный контроль над инфраструктурой — это не вопрос амбиций, это вопрос качества сервиса. Клиенту неважно, насколько хорошо написаны наши сервисы, если физически где-то что-то не так: проблемы с питанием, охлаждением и физической безопасностью. Мы хотим, чтобы у наших пользователей никогда не возникала ситуация, когда провайдер говорит: «Простите, ресурсов в этой зоне больше нет».
Поэтому мы сами управляем ёмкостью инфраструктуры, безопасностью и надёжностью. А чтобы дать нашим клиентам возможность строить ещё более отказоустойчивые системы, мы работаем над запуском третьей зоны доступности.
Как мы проектировали физическую фабрику и overlay-сеть на SRv6 — отдельная статья про архитектуру сети.
Свой технологический стек
Если сильно упростить, виртуальная машина — это процесс QEMU, запущенный на сервере и использующий KVM для аппаратной виртуализации.
Но чтобы такой процесс стал полноценной виртуальной машиной, им нужно управлять: определить, на каких физических ядрах будет выполняться ВМ, закрепить за ней ресурсы (о том, почему мы не используем овербукинг CPU, расскажем ниже), подключить сеть и диски. Для этого мы написали собственных агентов, которые работают на каждом хосте и напрямую управляют процессами QEMU, а также сетевым и storage-стеком через VPP и SPDK.
SPDK — это фреймворк, который переносит обработку операций ввода-вывода из пространства ядра в пространство пользователя.
VPP — это модульный, расширяемый фреймворк для обработки пакетов в пространстве пользователя. Простыми словами, это платформа для векторной обработки пакетов.
Про storage-путь и почему мы выбрали SPDK (и что пришлось допилить для продакшена) — подробно разбираем в отдельной статье.
Если интересно, как мы программно конфигурируем VPP , — также есть статья.
Облако — это сотни хостов, над ними работает Control Plane — управляющий уровень системы, который отвечает за принятие решений: где запускать виртуальные машины, как распределять нагрузку, как реагировать на сбои и поддерживать заданное состояние инфраструктуры.
Внутри каждой зоны работает зональный Control Plane, который управляет нагрузкой и ресурсами в пределах зоны, а ещё выше — глобальный Control Plane, развёрнутый в отказоустойчивом мультизональном Kubernetes-кластере. Даже если целая зона выйдет из строя, на глобальном уровне продолжится управление инфраструктурой и координирование её восстановления.
Подробнее о том, как устроен наш сервис Compute и почему мы делаем ставку на декларативный API и реконсиляцию, — в отдельной статье.
Почему мы так делаем, если есть OpenStack или готовые низкоуровневые решения вроде libvirt? Они действительно упрощают управление, но за этой простотой часто скрывается потеря гибкости.
Например, если нам нужно внести изменения в QEMU, в таких системах придётся разбираться и менять код во всех слоях абстракции сверху. Когда весь стек управления написан нами, это намного проще: мы можем менять поведение платформы там, где это действительно нужно, не разбирая тысячи строк кода в чужих сервисах.
Как мы подошли к современному IaaS
Мы не хотели ломать привычные паттерны пользователей, но и повторять то, что делалось двадцать лет назад, тоже не имело смысла. Поэтому мы выбрали не революционный, а эволюционный путь: сделать IaaS предсказуемым, честным и гибким.
Виртуальные машины
Мы сознательно отказались от овербукинга CPU. Минимальная конфигурация — 2 vCPU, и эти ядра полностью закреплены за виртуальной машиной. Две ВМ никогда не делят одно физическое ядро. Это обеспечивает предсказуемую производительность: она не зависит от «шумных соседей» или текущей нагрузки на сервер.
Виртуальные машины запускаются на серверах с процессорами Sapphire Rapids и памятью DDR5. Это новое поколение процессоров Intel и сегодня одно из самых современных решений на российском облачном рынке. В ряде задач Sapphire Rapids показывает до ~20% более высокую производительность по сравнению с предыдущим поколением Xeon (Ice Lake), что позволяет виртуальным машинам лучше справляться с нагрузкой при той же конфигурации.
Тесты производительности DDR4 и DDR5
Диски
Мы намеренно ушли от широко распространённой на рынке практики, при которой производительность диска жёстко привязана к его размеру. В нашей модели связь между объёмом и производительностью разорвана: клиент отдельно выбирает размер диска и отдельно — требуемые IOPS и throughput. Это значит, что даже самый небольшой диск может получить ту производительность, которая требуется конкретной нагрузке.
При этом производительность можно менять на лету, без остановки виртуальной машины, а при отсоединении диска — опускать её в ноль и не платить за неиспользуемые ресурсы.
Защита данных
Снимки дисков (snapshots) создаются по принципу copy-on-write. Такой снимок создаётся практически мгновенно и не требует остановки записи на диск: новые изменения просто записываются в новые блоки, а исходное состояние данных фиксируется в момент создания снимка.
После этого данные из снимка последовательно копируются в наше объектное хранилище S3. Переносятся только изменившиеся блоки, поэтому последующие резервные копии являются инкрементальными и занимают значительно меньше места.
Все резервные копии хранятся в объектном хранилище в зашифрованном виде и автоматически реплицируются. Данные сохраняются с тройной репликацией и распределяются между двумя зонами доступности, что обеспечивает их устойчивость к отказам инфраструктуры.
Образы
Мы перенесли в мир виртуальных машин практики управления Docker-образами. Теперь можно объединять образы в семейства, помечать их как актуальные или устаревшие, отключать образы, не удаляя их, и получать последнюю версию по тегу latest. Это облегчает администрирование и даёт больше контроля при работе с образами.
Сети — отдельная крупная часть инфраструктуры. Они отвечают за связность виртуальных машин и работу в интернете, но это большая тема для отдельного разговора. Подробнее о том, как у нас устроена сеть и как виртуальные машины автоматически получают настройки, разбираем в отдельной статье.
Зачем мы сделали всё это
Мы построили IaaS таким, каким считаем его правильным сегодня: технологичным, прозрачным и стабильным. На собственном железе, на собственном технологическом стеке и с полным контролем — от ЦОДов до контура управления.
В результате клиенты получают виртуальные машины, диски и сети — фундамент, который выдержит любую нагрузку и позволит масштабировать сервисы без ограничений.
В завершение скажу простую вещь: мы правда считаем, что делаем полезную и нужную инфраструктуру, и очень стараемся делать её удобной для клиентов. Нам важно ваше мнение, поэтому приходите, пробуйте платформу и делитесь обратной связью — именно она помогает нам делать продукт лучше. Начать можно здесь: MWS Cloud Platform, а задать вопросы и обсудить работу платформы можно в чате сообщества MWS Cloud Platform.
