Comments 29
Леша, лучший!
приветствую!
спасибо за статью!
расскажите, пожалуйста, сколько у вас ушло времени на проектирование, разработку и внедрение платформы, до того как она перешла в 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)
А так "опыт эксплуатации одной крупной компании" может быть не релевантен вашим нагрузками и у вас на вашем масштабе и проблем-то и не было бы?
Кстати, у вас же не одно единое облако, а несколько? Или одно, из тысячи железных нод?
Если не одно - то сколько? По сколько нод?
Писать замену нейтрону это хорошо, нужно и правильно, при одном условии - четко понимать зачем, и какие проблемы решает.
Да нет никаких особых критических рисков.
Я работаю в компании, где на k8s кластерах свой меш, свой ингресс контроллер, свой агент логгирования и скоро будет своя immutable OS. Ну может еще будет свой cni, но это не точно. Команда уже сменилась за 5 лет полностью и ничего. Платформа меняется гоаздо быстрее чем приходят и уходят люди в любом случае.
В любой крупной инфраструктуре структуре проще писать свои решения под себя, чем изучать подземные стуки, потому твой пограничный кейс не входит в эти самые 100500
А если вся команда целиком уходит, то это значит что в организации уже такие проблемы, что миллион строк легаси кода по сравнению с ними, это мелочь.
Спасибо за комментарий. Очень верно подмечено.
Мне кажется, что порой люди переоценивают страх разработки своего и недооценивают риски использования чего-то из индустрии. Мы все видим большое количество компаний, которые пишут свои продукты, а по сути свой продуктовый софт это такой же вендор-лок на свою команду разработки, со всеми вытекающими рисками. В этом плане инфраструктурная разработка очень слабо отличается от продуктовой.
При этом есть еще другой аспект - использование чего-то из opensource не гарантирует, то, что бизнес не получит вендор-лок на команду эксплуатации. Особенно, если масштаб использования технологий очень большой. Найти сильного DBA для очень популярной PostgreSQL совсем не просто, или, например, найти людей, которые выстраивали успешную эксплуатацию кластеров ceph-а размером в петабайты и десятки петабайт очень и очень сложно.
У нас вего 5к виртуалок, используем proxmox, полностью устраивает в качестве облаков, да у нас нет возможности пользователям самим пилить себе vm/lxc, но это скорее вопрос не ограничении платформы, а наши собственные
Для меня конечно диковато выглядит написание своего облака, но тут это наверное исключительно мой взгляд
Очень интересно было ознакомиться с вашим опытом.
Несколько раз перечитал статью, но не смог понять, как происходит перенос локальных дисков по сети?
Допустим, упал какой-то из серверов, там крутилось несколько ВМ и они хранили все свои виртуальные диски на этой же ноде. Тогда как вытащить данные, если сервер не загружается, умерла мать?
В 5 минут тут не уложиться, нужно вытащить сервер из стойки, снять диски, куда-то их воткнуть, желательно с таким же контроллером, а это приключение уже на несколько часов.
никак они не переносят, умерла так умерла
локальные диски - лучше не использовать, а если использовать то не рассчитывать на надежность.
В рамках миграции локальные диски переносятся сами. Но в рамках инцидента, когда упал сервер, мы на какое-то время теряем эти диски, да.
Возможно, я плохо объяснил, почему это не надо на самом деле. Когда вы строите отказоустойчивые приложения, вы должны допускать такой вариант отказа, что у вас какой-то датацентр станет недоступным. Соответственно, решать этот вариант отказа можно двумя способами - растягивать сетевые диски между ЦОДами, либо на уровне приложения обеспечивать отказоустойчивость и необходимую репликацию. В реальной жизни допустимый вариант только второй, потому что сетевые диски растянутые между ЦОДами будут работать очень медленно, да еще и стоимость такого решения будет огромной из-за каналов связи, которые вам нужно будет иметь. Соответственно, если вы умеете переживать отказ одного дц без какого-то влияния на приложение, то любой отказ конкретного сервера внутри дц - это частный случай более сложной ситуации, с которой вы уже умеете справляться.
Как мы спроектировали и запустили собственную облачную платформу на 20К виртуальных машин — опыт Wildberries