Комментарии 24
Леша, лучший!
приветствую!
спасибо за статью!
расскажите, пожалуйста, сколько у вас ушло времени на проектирование, разработку и внедрение платформы, до того как она перешла в production-ready и запустились первые продуктивные ВМ?
планируете ли использовать SDS-решения, или локальные диски в гипервизорах пока полностью устраивают?
есть ли планы по GPU, для каких-нибудь AI/ML сервисов? или может эта часть закрывается с помощью сервисов публичных облаков?
Привет. Спасибо за комментарий. Давайте по порядку.
У проекта была относительно сложная судьба - до релиза он несколько раз переписывался. Ну, наверное, последняя итерация разработки релизной версии заняла около года, причем достаточно маленькой командой - около 10 человек.
Пока что для наших собственных целей мы не хотим использовать SDS - кажется, что это очень недешевая технология, которая при этом решает достаточно мало наших проблем. И эти проблемы нам дешевле решать другим способом.
Да, про GPU был заход, но пока что не очень успешный - в рамках нашего облака пока что нет такого сервиса. Но вообще в компании есть достаточно много использования GPU, просто не в рамках нашего продукта. Ну а публичными облаками мы стараемся не пользоваться.
а терраформ провайдер написали?
Интересный опыт, да ещё и изложенный в оптимистическом духе. Пишите еще!
Всё это хорошо, но непонятна мотивация решения строить облако для запуска виртуалок, а не контейнеров. Виртуализация же добавляет дополнительные накладные расходы и усложняет деплой (т. к. тебе надо деплоить не образ с одним только приложением и нужными для него данными, а полной системой с ядром и прочей требухой вокруг него типа systemd). Почему не стали делать облако контейнеров (поверх подмана или подобного)? В крайнем случае, если у вас есть какое-то легаси, которое требует для своего запуска эмуляции физической машины - то тот же qemu можно запускать внутри такого контейнера (пробросив туда kvm - он будет работать не медленнее, чем на физической). А решение получилось бы более эффективным и универсальным.
У нас в компании сформировался уже технологический стек - stateless нагрузки мы запускаем в k8s (кажется, что их у нас уже сотни), а statefull, вроде баз данных, очередей и прочих приложений, в виртуальных машинах. Заставлять пользователей менять технологии, которые они используют == иметь большие сложности в внедрении.
Ну пойдя по пути облака для контейнеров - вы бы могли получить единое облако, в котором можно селить и stateless и statefull, контейнером или виртуалкой в любых сочетаниях. Вместо двух разнородных облаков. Примеры таких успешных решений мне лично известны, причём в них вполне успешно селятся в том числе и базы данных.
Странная статья.
Открыли что диски одного вендора одновременно выходят из строя. Что известно десятки лет и есть во всех рекомендациях по отказоустойчивым решениям это давно написано.
Выяснили что raid 1 не обеспечивает надёжность - так же известно десятки лет, резервные копии, хотсвап-диски в нормальных серверных платформах, 6-й рейд где надо прям сильно надёжно.
Достигли изучения reservation в dhcp серверах, ну ок, допустим новое поколение это вновь для себя открыло.
1 Тб за 5 минут - это все сервера на NVMe значит, на HDD даже на 20 в raid 0 не вытянуть, на SSD только на 8-штук в raid 0 на ооочень хороших контроллерах. Но в статье самозбор из гавна и палок (вспухшие кондёры, несовместимые CPU с материнками).
Но зачем было писать свой вариант OpenNebula не понятно совсем.
Рассказ о том как нахлабучить Таню Ким (теперь уже :)) на бабки и посадить на свой ведор лок, ибо теперь ведь не уволишь никого потому что никто не разберется с этой хренью.
Средний срок работы сотрудника в компании стремится к 2 годам. Что будет делать Wildrerries со всеми 20к VM, которые внезапно штормит из-за странных барабашек внутри множества легаси Software Defined Нечто, которые управляются полностью сменившейся командой, которая смотрит на миллионы строк самописного легаси-кода? OpenStack/OpenNebula хотя бы отчуждаемы и обладают каким-никаким комьюнити и прошли и решили 100500 пограничных кейсов, про которые вы ещё не знаете.
Странное решение с точки зрения TCO и долгосрочной эксплуатации.
Да, такие риски обоснованы и всегда есть.
Но начиная с определенных объемов инфраструктуры потенциальная экономия начинает превосходить риски. Надо еще учесть, что условный OpenStack - это не зеленый луг с бабочками. Мы, конечно, же общались с коллегами из других компаний, которые эксплуатируют такие решения и учитывали их опыт.
Вообще однозначного ответа и серебряной пули в этом вопросе нету - есть и примеры условных покупок vmware/huawei с последующими проблемами с уходом вендоров, есть успешные примеры разработки и эксплуатации собственных технологий в индустрии, но есть и примеры неудачных собственных разработок.
У меня есть опыт работы в команде крупного провайдера и глядя изнутри на OpenStack я вижу, что команда человек в 20, из которых половина это поддержка пользователей невысокой квалификации, способна поддерживать множество огромных инсталляций. При этом есть отчуждаемость, на рынке есть некое количество готовых спецов, из опытного линуксоида можно вырастить за полгода-год опытного админа и есть какое-никакое, но мировое комьюнити. Не говоря уже о том, что из коробки есть и Dashboard для пользователей с набором типовых пользовательстких кейсов и terraform provider для IaC. И это всё на опенсорс-вариантах вроде kolla, где платишь за компетенцию команды поддержки. Есть и вендорские дорогие варианты с разными коробочками и SLA, но они в контексте импортозамещения опасны, хоть и доступны, судя по cloud.ru.
И что-то я сомневаюсь, что у вас обсуждаемый функционал уложится в 10 опытных (читай дорогих) программистов, когда он наконец-то будет реализован и его надо будет поддерживать и багфиксить.
Странное решение.
Тут возникает много вопросов
1 - 20К ВМ это сколько в жезеных серверах?
2 - OpenStack это конечно не луг с бабочками, уж скорее луг где коровы паслись, и где можно хорошо вступить, но есть куча вендоров которые ставят и обслуживают опенстек, и это работает.
Это конечно не свой код с виртуалками и SDN пилить, но в конечном итоге может быть заметно дешевле. (правда пилить, точнее допиливать под себя может быть не так уж вессело, а уж пропихнуть в апстрим так просто квест)
PS
К опенстеку можно крутить контрейл/тангстен фабрик если есть желание или необходимость. Есть интеграции с дисковыми массивами что б не хранить данные локально, ну если захочется когда-то, да в общем-то много чего уже есть
Если я правильно понял вопросы, то ответы следующие:
Железок у нас в эксплуатации "высокие" сотни.
Может я недостаточно ясно выразился в статье, но основной наш код это как раз клей между текущими opensource решениями такими как kvm/qemu/ovn/ovs/итд.
Да, в опенстек можно много чего прикрутить. Я лично под большим впечатлением от опыта эксплуатации одной крупной компании, которая и замену нейтрона пишет, и замену trove и много чего еще делает.
"Высокие сотни" это, скажем, 999 раз не "тысячи"
И ради несчастной почти-тыщи железок писать свой софт?
Оверкилл это
Да и опенстек тоже сам по себе - "клей" между теми-же компонентами, ни OVS ни KVM/QEMU особо заменить нечем (хотя я видел инсталляции опенстека где в качестве compute использовали VMware)
А так "опыт эксплуатации одной крупной компании" может быть не релевантен вашим нагрузками и у вас на вашем масштабе и проблем-то и не было бы?
Кстати, у вас же не одно единое облако, а несколько? Или одно, из тысячи железных нод?
Если не одно - то сколько? По сколько нод?
Писать замену нейтрону это хорошо, нужно и правильно, при одном условии - четко понимать зачем, и какие проблемы решает.
У нас вего 5к виртуалок, используем proxmox, полностью устраивает в качестве облаков, да у нас нет возможности пользователям самим пилить себе vm/lxc, но это скорее вопрос не ограничении платформы, а наши собственные
Для меня конечно диковато выглядит написание своего облака, но тут это наверное исключительно мой взгляд
Очень интересно было ознакомиться с вашим опытом.
Несколько раз перечитал статью, но не смог понять, как происходит перенос локальных дисков по сети?
Допустим, упал какой-то из серверов, там крутилось несколько ВМ и они хранили все свои виртуальные диски на этой же ноде. Тогда как вытащить данные, если сервер не загружается, умерла мать?
В 5 минут тут не уложиться, нужно вытащить сервер из стойки, снять диски, куда-то их воткнуть, желательно с таким же контроллером, а это приключение уже на несколько часов.
Как мы спроектировали и запустили собственную облачную платформу на 20К виртуальных машин — опыт Wildberries