Как мы создавали собственную платформу vStack
В экономике облачных решений, построенных на «кровавом энтерпрайзе», далеко не последнее место занимают лицензионные отчисления. Честно говоря, стоимость лицензий VMware, составляющую весомую долю от всех затрат, нам уже давно хотелось сократить. Вариантов здесь очень немного:
Встать под Веселым Роджером и пользоваться VMware нелегально.
Построить альтернативное решение на замену VMware.
Первый вариант — не вариант, поэтому мы сразу же приступили к поиску способов реализации второго. В 2018 году, когда горизонтальное масштабирование практиковалось везде и всюду, нам показалось особенно интересным его применение в инженерной системе. В сущности, необходимость в «золотых» виртуальных машинах или хранилищах с появлением горизонтально масштабируемого ПО отпала. Огромный пласт дорогостоящих обеспечительных мер, которые входили в enterprise-решения, стал не нужен. Это позволило нам всерьез задуматься о своей собственной платформе, построенной по канонам гиперконвергенции.
Сегодня я, Евгений Гаврилов, руководитель проекта vStack, расскажу, как мы в ITGLOBAL.COM создавали vStack — собственную гиперконвергентную платформу.
Проектирование
Днем рождения нашего решения можно считать 18 июля 2018 года: тогда мы впервые встретились и начали прикидывать будущий проект на доске. Понимание, что не получится взять и слепить нечто простое, на коленке, и выпустить в прод, было у нас изначально. Нам нужна была система, которая сможет обеспечивать предоставление IaaS как в сервисной, так и в on-premise модели.
Какой мы видели нашу платформу:
возможность использования commodity hardware;
единый endpoint управления (API) — полная противоположность системам с дискретным API/управлением;
сквозное резервирование элементов вплоть до уровня узла.
VMware, являясь стандартом в мире виртуализации, со временем разрослась и превратилась в этакого монстра безумного размера. Задачи построить «убийцу VMware» у нас, разумеется, не было: нам нужно было решение, функциональности которого было бы достаточно для ряда конкретных целей. Более того, мы не видели смысла в реализации поддержки всякого рода legacy, которым очень сильно переполнен продукт с почти 20-ти летней историей. В качестве стека мы выбрали FreeBSD, ZFS, bhyve.
Почему не KVM?
Отдельно стоит сказать о стеке технологий, которые легли в основу нашего решения. На момент начала разработки мы ориентировались в первую очередь на собственный опыт и изучали альтернативы популярных продуктов. Так по ряду причин мы осознанно отказались от рассмотрения KVM.
Во-первых, KVM не умеет хорошо работать в условиях CPU Overcommit –, а для облака это критически важный момент, одна из точек возникновения прибыли.
Во-вторых, KVM распространяется по «неудобной» для коммерческого продукта лицензии GPL. Его использование принудило бы нас придерживаться той же лицензии, а для коммерческого продукта это совсем неподходящий вариант. Мы осознанно выбирали технологии, доступные под лицензиями, отличными от GPL.
Помимо этого, для нас была чрезвычайно важна компактность технологий в составе решения. К примеру, если взять OpenStack или Red Hat virtualization, то окажется, что, чтобы построить нормальное облако с redundancy и резервированием, придется развернуть огромное количество компонентов. А использование OpenStack в гиперконвергентном ключе — это фактически хак, который никак и никем не поддерживается. Нести такое на рынок нельзя.
Реализация
Для реализации проекта нужны были соответствующие специалисты. Август и сентябрь 2018 я провел в поиске подходящих людей и только в конце сентября удалось найти первого участника команды, который удовлетворял требованиям задачи. Октябрь и ноябрь почти полностью ушли на решение задач обеспечительного характера. Необходимо было убедиться, что вся наша идея согласуется с выбранным технологическим стеком: FreeBSD, ZFS, bhyve. Почти вручную мы проверяли, «клеится» ли A к B, и работает ли это все вместе с C. Также необходимо было убедиться в работоспособности механизмов failover, обеспечения целостности слоя данных. Определенное время мы потратили на то, чтобы эти механизмы имели должную управляемость.
К декабрю удалось найти еще одного участника команды, после чего мы приступили к проектированию и имплементации кластерного слоя решения.
Довольно быстро мы удостоверились, что в плане обеспечения Software Defined Storage никаких проблем нет. А вот сетевая часть решения оказалась куда сложнее. Немало времени ушло на то, чтобы произвести в ОС изменения, которые позволили бы нам строить частные виртуальные сети с нужными нам характеристиками и свойствами.
В качестве архитектурного подхода реализации API мы выбрали JSON-RPC. За время эксплуатации мы многократно убедились, что это правильный выбор, на примере случаев а-ля »Влад, у нас там 500-ая ошибка», которые присущи другим реализациям. Добрая половина обращений в нашей практике переставала быть актуальной после просьбы предоставить ID запроса — и это весьма показательно: автор самостоятельно находил причину проблемы на своей стороне благодаря сквозной уникальности каждого запроса.
Отличия от других решений на основе Open Source
Одним из ключевых отличий нашего продукта является большое количество наших собственных разработок. Другими словами, мы не брали готовое решение, на котором просто меняли вывеску/логотип/шрифты. Мы взяли технологии и объединили их в единое решение своими разработками.
Мы сами создали:
собственную реализацию алгоритма RAFT;
собственный кластерный framework;
собственный слой управления, включающий контроллеры SDC/SDN/SDS и API;
собственную виртуальную сеть, выгодно отличающуюся технологически.
Пара слов про тесты
Поскольку наша платформа подразумевает виртуализацию сразу трех слоев — compute, storage, network — тестирование оказалось весьма непростой задачей. Некоторые баги мы ловили по 2–3 недели: для этого приходилось досконально воссоздавать совокупность условий, в которых они предположительно возникали.
Например, однажды мы «поймали» проблему, которая проявлялась только при использовании определенной гостевой ОС, в которой драйвер virtio инициализировался слегка иначе, нежели у остальных.
Идем в прод
На этом этапе нам очень помогла наша внутренняя компания, Serverspace — public cloud провайдер, ориентированный на малый и средний бизнес. С точки зрения нашего проекта это гарантированный потребитель, который находится в одном с нами офисе и может быстро с нами взаимодействовать по любому моменту. Уже через 10 месяцев, прошедших со старта первого этапа, Serverspace получила возможность использовать наш первый кластер на vStack в промышленной эксплуатации.
Это действительно важная веха: годы работы в лабораторных условиях не стоят и месяца в «боевом» продуктиве. Первый кластер был размещен в Амстердаме и продавался по весьма соблазнительной цене — примерно вдвое дешевле, чем VMware. Так что мы сразу же получили пул ранних клиентов. В последующие месяцы мы активно дорабатывали и совершенствовали продукт на основе обратной связи настоящих пользователей.
К примеру, вначале мы считали, что среди клиентов в большей степени будет востребована производительность виртуальной сети. По итогам начальной эксплуатации выяснилось, что людям также нужна хорошая поддержка гетерогенности сети, работающая «из коробки». Это очень важный момент: многие использовали ВМ vStack в качестве ресурсного решения для контейнеризации и пр. Поддержка гетерогенности в любых виртуальных сетях «из коробки» является одной из наших отличительных черт.
Прочие отзывы клиентов касались преимущественно задач прикладного характера, но были и из ряда вон выходящие случаи, в слагаемых неуспеха которых был и пресловутый legacy. Например, нашу платформу выгодно отличает возможность «из коробки» использовать 4kn-диски для виртуальных машин, однако в определенный момент оказалось, что драйвер virtio для операционных систем Windows в некоторых случаях некорректно обрабатывает операции DISCARD для таких дисков. При этом обработка в таких условиях этих же операций в драйвере, входящем в Open Source OS, работала как часы. Нашей команде удалось не только идентифицировать проблему, но и помочь воспроизвести её вендору этого драйвера. Ошибка была им зафиксирована и исправлена.
Кому и когда будет интересна платформа
Компаниям с частями инфраструктуры на commodity hardware
Современный бизнес умеет считать деньги, поэтому vStack интересен в первую очередь компаниям, которые понимают логику гиперконвергенции и осознают плюсы использования горизонтального масштабирования, за счет чего отпадает необходимость использования дорогостоящих компонентов. Мы постоянно подчеркиваем этот тезис и делаем на нём фокус: отпадает необходимость, но не возможность. Вы сами решаете, какие именно компоненты должны быть дорогостоящими, а какие нет, на чём именно приемлема экономия.
Один из распространённых случаев с напрашивающейся экономией — тестовые стенды. Итак, в компании есть 20 команд, которые работают над одним продуктом. Каждая из команд «выпросила» для себя отдельный тестовый стенд. И человек, который несет ответственность за бюджет, рано или поздно заметит, что 90% бюджета тратится на обеспечение тестовых стендов. Да, тестовый стенд по канону не должен отличаться от промышленного. Но когда цена вопроса — 90% бюджета, этот аргумент уже не работает. Поэтому экономическая составляющая — тоже важное преимущество нашей системы. Потребитель самостоятельно формирует контуры и характеристики системы, выбирает компоненты. Если для него важен слой хранения, можно выбрать enterprise-диски. Если нет — можно работать на commodity-дисках и как на этом сэкономить.
Как замена VMware
Из злободневного: если вы планируете импортозаместить VMware, можно рассмотреть vStack.
Платформа может вам подойти как альтернатива VMware, если вы:
задумались о vSAN, но сверхвысокая стоимость вас пугает;
осознаете, что 90% функциональности VMware, которую вы не используете, входит в цену, которую вы платите;
можете с уверенностью сказать, что «вы используете минимум legacy технологий»;
активно используете ПО с технологиями горизонтального масштабирования;
понимаете, что текущая инфраструктура усложнилась настолько, что любые изменения в ней происходят с болью, скрипом и за очень большое время;
не знаете, что делать с этими 12 стойками разношерстного оборудования для тестовых стендов и как на следующем бюджетном комитете защитить статьи на поддержку этого железа без отсылок к Господину Инженеру.
Наша платформа как замена VMware вряд ли вам подойдёт если:
вы хотите «точную копию VMware один-в-один, только не VMware»;
имеющиеся решения с открытым исходным кодом покрывают ваши потребности;
возможность использования привычного инструмента (VMware) для вас важнее любых других факторов.
Как vStack развивается сейчас
Сейчас мы готовим важный мажорный релиз на основе обновленной версии ОС. Кроме того, появится новый тип виртуальных сетей GENEVE: более новой технологии создания виртуальных сетей, использующих инкапсуляцию. Данная технология используется различными вендорами, что позволит реализовать сетевую связнность разных решений виртуализации. Готовятся также изменения в функциональность «мягкой» миграции виртуальных машин.
Производительность всех типов виртуальных сетей и слоя хранения в новой версии заметно повысится за счет совокупности улучшений.
Команда проекта постоянно расширяется, у нас почти всегда есть открытые вакансии очень разных специализаций: и разработчики уровня ядра OS, и backend-разработчики, и тестировщики.
Совсем недавно мы были на выставке «Импортозамещение 2022» и получили немало отзывов, в том числе и о высоком качестве работы нашей платформы в условиях CPU Overcommit. Это правда. Работа в условиях CPU overcommit у нас, во-первых, лучше, чем у KVM, во-вторых, мы сделали самодостаточный механизм адаптивного бюджетирования квантов CPU, который обеспечивает работу этого слоя без негативного влияния на гостевую ОС. В публичном облаке это особенно важно: проблема шумного соседа у провайдеров стоит ежедневно.
Пара фотографий с выставки:
Выставка «Импортозамещение 2022»
Выставка «Импортозамещение 2022»
Веб-интерфейс vStack: по-моему, у нас отлично получилось. Зачастую считается, что веб-интерфейс сложной инженерной системы должен быть максимально ужасным, «лишь бы работал».
Недавно мы запустили программу льготного лицензирования vStack. Образовательные учреждения, библиотеки, музеи и благотворительные организации смогут пользоваться платформой по академической лицензии. Действовать она будет бессрочно, а стоить — намного дешевле, чем обычная. Если у вас есть нужный статус — добро пожаловать.
В этой статье я постарался рассказать историю появления платформы vStack. Конечно, рассказать историю полностью за один раз невозможно. Если я упустил какие-то интересующие вас детали — задавайте вопросы, постараюсь ответить. Как устроена платформы изнутри, я расскажу в следующей статье. Там мы пройдемся по архитектуре vStack, возможностям и различным «плюшкам» платформы.
