Comments 14
PayPal заменил арендуемый у eBay VMWare на свой персональный OpenStack. Почему бы?)
А как CMP, то есть система управления облаком, может заменить базовую виртуализацию, то есть VMware vSphere, в данном случае? «Внизу» всегда есть гипервизор. А вот произошёл ли переезд на новый гипервизор не указано.
А это и не важно. Внезапно, «они все одинаковые». При том, что очень крутой эксперт сможет потыкать пальцем в различия между Xen'ом, KVM'ом, VMWare и Hyper-V, но они все очень долго и упорно работали на то, чтобы быть неотличимыми с практической точки зрения пользователя, который логинится в виртуалку и запускает там свой код.
Они различаются (радикально) со стороны «back-office». То, как это видит админ, и это то, на что обычно показывают, говоря про различия гипервизоров. Всем очевидно, что KVM и Hyper-V — это фантастическая разница, разные школы администрирования, разные тулстеки, разные ОС. Всё разное. Педанты смогут сказать, что Xen и EXSi — это первого типа, а KVM и Hyper-V — второго.
Однако, openstack энкапсулирует гипервизоры абстракциями более высокого уровня. Ровно так же, как с точки зрения автора программ, чаще всего нет никакой разницы между Intel'ом и AMD — «оно просто работает». Бывают edge-case'ы, когда это важно, но большей частью — совсем-совсем пофигу.
Openstack — это унифицированные ручки для управления инфраструктурой. В условиях, когда гипервизоры отлажены до совершенства, именно эти ручки оказываются критическими. В существующем IT каждый болтик не должен быть произведением искусства и иметь совершенные размеры. Он должен иметь такие размеры, чтобы хорошо закручиваться с гайкой. А если не закручивается, то никого не волнует икрустация по краю шляпки. Если закручивается — ну, можно полюбоваться и поспорить чья школа лучше.
В Openstack одинаково хорошо (я верю в вас, ребята из Microsoft) вкручивается и Hyper-V, и VMWare, и KVM. И они начинают работать как примитивные болтики. Никого не волнует мнение гипервизора о высокой политике (аллокации ресурсов или скедулинга), дело гипервизора — гипервизорить. А вся важная логика (скедулинг, управление снапштами, правами доступа, настройками сети) — это openstack, который стандартен.
И не только стандартен, но и очень ковырябелен. Практически все люди, которые юзают опенстек всерьёз, так или иначе его под себя патчили. Одному важно одно, другому — другое.
Патчи на openstack охватны взглядом и разумны по сложности. В сравнении с этим патч на гипервизор — это rocket science, а для многих это и не возможно по причине закрытых сырцов.
Они различаются (радикально) со стороны «back-office». То, как это видит админ, и это то, на что обычно показывают, говоря про различия гипервизоров. Всем очевидно, что KVM и Hyper-V — это фантастическая разница, разные школы администрирования, разные тулстеки, разные ОС. Всё разное. Педанты смогут сказать, что Xen и EXSi — это первого типа, а KVM и Hyper-V — второго.
Однако, openstack энкапсулирует гипервизоры абстракциями более высокого уровня. Ровно так же, как с точки зрения автора программ, чаще всего нет никакой разницы между Intel'ом и AMD — «оно просто работает». Бывают edge-case'ы, когда это важно, но большей частью — совсем-совсем пофигу.
Openstack — это унифицированные ручки для управления инфраструктурой. В условиях, когда гипервизоры отлажены до совершенства, именно эти ручки оказываются критическими. В существующем IT каждый болтик не должен быть произведением искусства и иметь совершенные размеры. Он должен иметь такие размеры, чтобы хорошо закручиваться с гайкой. А если не закручивается, то никого не волнует икрустация по краю шляпки. Если закручивается — ну, можно полюбоваться и поспорить чья школа лучше.
В Openstack одинаково хорошо (я верю в вас, ребята из Microsoft) вкручивается и Hyper-V, и VMWare, и KVM. И они начинают работать как примитивные болтики. Никого не волнует мнение гипервизора о высокой политике (аллокации ресурсов или скедулинга), дело гипервизора — гипервизорить. А вся важная логика (скедулинг, управление снапштами, правами доступа, настройками сети) — это openstack, который стандартен.
И не только стандартен, но и очень ковырябелен. Практически все люди, которые юзают опенстек всерьёз, так или иначе его под себя патчили. Одному важно одно, другому — другое.
Патчи на openstack охватны взглядом и разумны по сложности. В сравнении с этим патч на гипервизор — это rocket science, а для многих это и не возможно по причине закрытых сырцов.
Разница между гипервизорами например в производительнсти IO.
Зачастую это разница оборудования.
Разница между гипервизорами в производительности в оптимальных настройках гостей несущественна. В реальной жизни её:
а) не обнаружить из-за того, что девиация производительности железа больше разницы между производительностью гипервизоров (всякие turbo boost'ы и т.д.)
б) не обнаружить из-за того, что реальные ОС (применяемые в продакшене) не realtime и могут заняться более важными процессами, чем тест, в процессе тестирования.
По CPU производительность у всех давно за 99% зашкалила. По IO — надо смотреть на технологию виртуализации оборудования (которая к гипервизору постольку поскольку). При SR-IOV производительность будет одинаковая у любого гипервизора. При использовании паравиртуализованных драйверов вопросы гонки производительности уже давно ушли в район десятков гигабит (и немного отстают от производительности хоста).
А вот COW-формат диска или RAW (самый острый вопрос, где IO может в 2-3 раза падать по сравнению с baremetall) — это решение администратора. Хочет плюшек? COW. Хочет производительности? RAW. Все гипервизоры умеют и то, и то.
На практике «производительность гипервизоров» мгновенно заслоняется более важными вещами: «нет, ЭТО сделать нельзя, потому что в модели тулстека Х предполагается, что ...», или «по архитектурным соображениям ограничение в тулстеке на число сетевых интерфейсов — 15».
Заметим, это каждый раз ограничения тулстека, а не гипервизора. Иногда ограничения идиотские, иногда осмысленные. Но чтобы об этом особо не думает, и существует openstack с унифицированным подходом. Ярче всего его видно на примере интеграции xenserver в openstack.
Каждый хост xenserver является пулом. Никаких «пулов на несколько серверов». Никого не интересуют интимные взаимоотношения двух хостов в пуле и выяснения кто из них мастер.
Каждый диск делается в своём SR'е. Никаких «base copy», интимных взаимоотношений с драйвером SR, выясняющим где чьи данные и кто от кого произошёл. Никаких thin copy, с последующим мучением «ограничение на длинну цепочки», «мультипликация IO на запись» и т.д. Выдали файл образа — запусти с него виртуалку. Надо сделать снапшот? Выдай полную копию. Всё.
Вот эта грубоватая простота — она очень приятна. И получающаяся мультитенантность (никто, кроме openstack не даёт настоящего multitenancy «от» и «до»), ещё один важный бонус.
а) не обнаружить из-за того, что девиация производительности железа больше разницы между производительностью гипервизоров (всякие turbo boost'ы и т.д.)
б) не обнаружить из-за того, что реальные ОС (применяемые в продакшене) не realtime и могут заняться более важными процессами, чем тест, в процессе тестирования.
По CPU производительность у всех давно за 99% зашкалила. По IO — надо смотреть на технологию виртуализации оборудования (которая к гипервизору постольку поскольку). При SR-IOV производительность будет одинаковая у любого гипервизора. При использовании паравиртуализованных драйверов вопросы гонки производительности уже давно ушли в район десятков гигабит (и немного отстают от производительности хоста).
А вот COW-формат диска или RAW (самый острый вопрос, где IO может в 2-3 раза падать по сравнению с baremetall) — это решение администратора. Хочет плюшек? COW. Хочет производительности? RAW. Все гипервизоры умеют и то, и то.
На практике «производительность гипервизоров» мгновенно заслоняется более важными вещами: «нет, ЭТО сделать нельзя, потому что в модели тулстека Х предполагается, что ...», или «по архитектурным соображениям ограничение в тулстеке на число сетевых интерфейсов — 15».
Заметим, это каждый раз ограничения тулстека, а не гипервизора. Иногда ограничения идиотские, иногда осмысленные. Но чтобы об этом особо не думает, и существует openstack с унифицированным подходом. Ярче всего его видно на примере интеграции xenserver в openstack.
Каждый хост xenserver является пулом. Никаких «пулов на несколько серверов». Никого не интересуют интимные взаимоотношения двух хостов в пуле и выяснения кто из них мастер.
Каждый диск делается в своём SR'е. Никаких «base copy», интимных взаимоотношений с драйвером SR, выясняющим где чьи данные и кто от кого произошёл. Никаких thin copy, с последующим мучением «ограничение на длинну цепочки», «мультипликация IO на запись» и т.д. Выдали файл образа — запусти с него виртуалку. Надо сделать снапшот? Выдай полную копию. Всё.
Вот эта грубоватая простота — она очень приятна. И получающаяся мультитенантность (никто, кроме openstack не даёт настоящего multitenancy «от» и «до»), ещё один важный бонус.
> При использовании паравиртуализованных драйверов вопросы гонки производительности уже давно ушли в район десятков гигабит (и немного отстают от производительности хоста).
Подскажите, пожалуйста, что нужно сделать с VMware, чтобы она без использования SR-IOV или проброса сетевой карты в гостевую систему выдавала бы более 3 Гбит/с? В случае SR-IOV или VMDirectPath все 10 Гбит/с доступны, а через виртуальный свитч и виртуальные сетевые карты vmxnet3 больше 3-4 Гбит/с получить не получалось.
Подскажите, пожалуйста, что нужно сделать с VMware, чтобы она без использования SR-IOV или проброса сетевой карты в гостевую систему выдавала бы более 3 Гбит/с? В случае SR-IOV или VMDirectPath все 10 Гбит/с доступны, а через виртуальный свитч и виртуальные сетевые карты vmxnet3 больше 3-4 Гбит/с получить не получалось.
Развожу руками, ибо я только с xen работал (в прошлом) и теперь с KVM. По тому, что я слышал про VMWare, 10G она в виртуалках (без SR-IOV) выдаёт. Из интуитивного — попоробовать сетевуху, в которой прерывания могут по нескольким процессорам размазываться (ixgbe умеет, ixgb умеет, e1000e — не умеет).
В контексте openvswitch я видел 8Гбит. Рассказывают, что (без dpdk) оно умеет выдавать до 20Гбит на новой версии (руки не дошли побенчмаркать) с хорошим железом.
В контексте openvswitch я видел 8Гбит. Рассказывают, что (без dpdk) оно умеет выдавать до 20Гбит на новой версии (руки не дошли побенчмаркать) с хорошим железом.
В серверах у меня физически карточки от Mellanox стоят.
Если брать KVM + SR-IOV, то до 20 Гбит/с оно выдает. С виртуальными сетевыми картами я правда не пробовал такую конфигурацию тестировать. А в VMware SR-IOV у меня нет, так как оно только в самой дорогой подписке доступно :)
> По тому, что я слышал про VMWare, 10G она в виртуалках (без SR-IOV) выдаёт.
Эх, знать бы какие ручки для этого нужно подкрутить.
Если брать KVM + SR-IOV, то до 20 Гбит/с оно выдает. С виртуальными сетевыми картами я правда не пробовал такую конфигурацию тестировать. А в VMware SR-IOV у меня нет, так как оно только в самой дорогой подписке доступно :)
> По тому, что я слышал про VMWare, 10G она в виртуалках (без SR-IOV) выдаёт.
Эх, знать бы какие ручки для этого нужно подкрутить.
Развожу руками, ибо я только с xen работал (в прошлом) и теперь с KVM.
Уважаемый amarao, я перепробовал и поработал на проэктах с Xen, Hyper-V (начиная с первой версии) и vSphere (с 3.5). Коллеги, мнению которых я доверяю, сталкивались с Oracle VM.
Так вот, внезапно гипервизоры далеко не одинаковые, не были, не есть, и в ближайшие годы точно не будут. Во-вторых, vCloud Director даёт тру multitenancy, Virtual Machine Manager был почти true в 2012.
phprus, а по поводу производительности виртуалки — пишите в личку, обсудим.
Уважаемый amarao, я перепробовал и поработал на проэктах с Xen, Hyper-V (начиная с первой версии) и vSphere (с 3.5). Коллеги, мнению которых я доверяю, сталкивались с Oracle VM.
Так вот, внезапно гипервизоры далеко не одинаковые, не были, не есть, и в ближайшие годы точно не будут. Во-вторых, vCloud Director даёт тру multitenancy, Virtual Machine Manager был почти true в 2012.
phprus, а по поводу производительности виртуалки — пишите в личку, обсудим.
> Компания самостоятельно построила облако OpenStack. При этом у PayPal был выбор: создать облако самостоятельно, или нанять специалиста или даже компанию, которые смогли бы внедрить собственные решения для PayPal. Компания выбрала самостоятельный путь, и сейчас руководство нисколько не жалеет об этом.
Специалисты из компании Мирантис, если они тут появятся, могут рассказать, насколько самостоятельно PayPal это сделал )
Специалисты из компании Мирантис, если они тут появятся, могут рассказать, насколько самостоятельно PayPal это сделал )
Не секрет, что лицензия на vSphere стоит сильно дороже самого железа, на котором оно работает. При этом для обслуживания небольшой инсталляции до Х хостов достаточно небольшого числа специалистов определенной квалификации, при том что в VMware почти всё делается сравнительно просто и мышкой в GUI. С другой стороны, запуск аналогичного решения на OpenStack потребует совсем другого штата людей для ковыряния консоли, скриптописательства и прочих нетривиальных вещей. При росте Х наверняка есть какая-то критическая точка, при которой выгоднее становится содержать собственную толпу админов-линуксоидов на развитии и поддержке (это если делать на KVM), чем продолжать кормить VMware Inc за каждый следующий физический процессор. Моя личная оценка Х — порядка 50.
Может я отстал от жизни, но есть ли в KVM/Openstack функционал, схожий с CBT, DRS, интегрированные бэкапы типа вима, нормальная поддержка общих блочных хранилищ и плагины к ним?
Может я отстал от жизни, но есть ли в KVM/Openstack функционал, схожий с CBT, DRS, интегрированные бэкапы типа вима, нормальная поддержка общих блочных хранилищ и плагины к ним?
Судя по наблюдаемому всплеску вакансий в области KVM+Puppet/Chef — к этому выводу приходят и компании помельче.
По поводу CBT и вима — у самого были похожие мысли. Но если взглянуть на проблему бэкапа, исключая гипервизор как участника и, смотря на это все с точки зрения снапшотов NAS, к примеру на базе ZFS файловой системы — появляются интересные варианты.
По поводу CBT и вима — у самого были похожие мысли. Но если взглянуть на проблему бэкапа, исключая гипервизор как участника и, смотря на это все с точки зрения снапшотов NAS, к примеру на базе ZFS файловой системы — появляются интересные варианты.
Only those users with full accounts are able to leave comments. Log in, please.
Почему PayPal заменил VMware OpenStack-ом?