KVM и OpenStack

Непосредственное отношение к самому KVM (и прочим гипервизорам) имеет Nova. Остальные сервисы же общаются с Nova, а не с KVM.

компонент который общается с KVM это nova. общается он не напрямую с KVM а с libvirt, который предоставляет все нужные API. Так что общение идет через nova client, который уже дает команды libvirt на хостах.

На самом деле все немного сложнее, потому что есть еще куча компонентов к которым надо обратиться, и которые в свою очередь выдают команды разным компонентам. Емнип там около 25-30 шагов только чтоб запустить один инстанс

Хорошо, но как гипервизоры общаются с Nova?

Тут все довольно детально описано - http://docs.openstack.org/juno/config-reference/content/kvm.html

libvirt

На самом деле все немного сложнее, потому что есть еще куча компонентов к которым надо обратиться, и которые в свою очередь выдают команды разным компонентам.

Угу, ну чувак хотел попроще разъяснить,
я не углублялся)

компонент который общается с KVM это nova. общается он не напрямую с KVM а с libvirt, который предоставляет все нужные API. Так что общение идет через nova client, который уже дает команды libvirt на хостах.

Меня интересует общение в другом направлении. Допустим, программа, исполняющаяся в VM, делает запрос на запись файла - как/куда делает запрос KVM? Если это где-то описано - можно ссылку?

Тут все довольно детально описано - http://docs.openstack.org/juno/config-reference/content/kvm.html

Это я уже читал. Ответа на вопрос там нет.

Меня интересует общение в другом направлении. Допустим, программа, исполняющаяся в VM, делает запрос на запись файла - как/куда делает запрос KVM? Если это где-то описано - можно ссылку?

внутри ВМ бежит программа и пишет файл. Файл лежит на диске ВМ, никакой разницы с обычной виртуализацией.

или вопрос откуда берутся диски?

внутри ВМ бежит программа и пишет файл. Файл лежит на диске ВМ, никакой разницы с обычной виртуализацией.

До этого я дошел...

или вопрос откуда берутся диски?

Вопрос, откуда берется файл. Если это обычный файл на, допустим, локальной ext4, то... что-то я не вижу смысла OpenStack.

файл, то бишь имидж диска, лежит на cinder или swift, при запуске инстанса, он переписывается оттуда на локальный диск. Когда создается свежий инстанс, диск берется из темплейта на glance

файл, то бишь имидж диска, лежит на cinder или swift, при запуске инстанса, он переписывается оттуда на локальный диск

...и дальше kvm работает с ним, как с файлом в локальной ФС? Тогда непонятно, как OpenStack обеспечивает «data replication and integrity across the cluster». Накрывается локальный диск - накрывается и VM.

man ceph

man ceph

Что Ceph? В доке не сказано, что replication and redundancy обеспечиваются только с Ceph, да и в любом случае, файл в Ceph (или CephFS) - это не файл на локальном диске.

локально диск хранится только пока VM бежит. Если нужно обеспечить реальную надежность, используется ceph/gluster/SAN, а не просто локальное хранилище. Но в любом случае, это облако, здесь не предполагается хранение важной инфы, и важных виртуалок, для этого есть другие виды виртуализации. подходящие для «облака» нагрузки можно убить, поднять из темплейта и все продолжит работать как будто ничего не случилось. http://www.theregister.co.uk/2013/03/18/servers_pets_or_cattle_cern/

локально диск хранится только пока VM бежит. Если нужно обеспечить реальную надежность, используется ceph/gluster/SAN, а не просто локальное хранилище.

Окей, значит, при локальном исполнении ни replication, ни redundancy... но к чему тогда они относятся - к хранению объектов внутри самого OpenStack? Или replication and redundancy обеспечиваются только в каких-то особых конфигурациях?

http://www.theregister.co.uk/2013/03/18/servers_pets_or_cattle_cern/

«Няшки или быдло», надо же... хорошо, OpenStack - для быдла, а для няшек что?

Окей, значит, при локальном исполнении ни replication, ни redundancy... но к чему тогда они относятся - к хранению объектов внутри самого OpenStack? Или replication and redundancy обеспечиваются только в каких-то особых конфигурациях?

во первых каждый сервис может быть распределен, контроллеры устанавливаются по несколько штук. что касается хранения объектов, то это swift, который тоже хранит как минимум три копии каждого объекта.

вся идея не в обеспечении кучи девяток для VM, а в масштабируемости инфраструктуры. если например контроллер одного из сервисов не справляется (neutron L3 этим особенно грешит) тупо ставится еще один, и еще один и т.д.

«Няшки или быдло», надо же... хорошо, OpenStack - для быдла, а для няшек что?

не совсем так. просто есть много видов нагрузки которые не надо держать под особым контролем. nginx фронтэнд например - он туп, его можно понять один или сто, в зависимости от нагрузки на сайт, и если пара из этой сотни сдохнет, нет проблем развернуть еще. это не делает эти фронтэнды быдлом, но ведь и бекапить их ты не станешь - достаточно хранить темплейт. Вот такие нагрузи отлично подходят для облака, особенно если задействовать heat и ceilometer (тогда связки сервисов будут запускаться и опускаться автоматически, в зависимости от нагрузки).

для своих, родных и любимых серверов, которые надо бекапить и держать в HA, есть oVirt/RHEV, proxmox, vsphere и т.д.

swift, который тоже хранит как минимум три копии каждого объекта.

А это в документации где-то отражено?

вся идея не в обеспечении кучи девяток для VM, а в масштабируемости инфраструктуры

Ясно. Я просто пытаюсь понять терминологию OpenStack.

nginx фронтэнд например - он туп, его можно понять один или сто, в зависимости от нагрузки на сайт, и если пара из этой сотни сдохнет, нет проблем развернуть еще. это не делает эти фронтэнды быдлом

Просто когда-то на ЛОР пытались перевести на английский слово «быдло», сошлись на «cattle» :)

для своих, родных и любимых серверов, которые надо бекапить и держать в HA, есть oVirt/RHEV, proxmox, vsphere и т.д.

Ясно, спасибо.

А это в документации где-то отражено?

должно быть :) искать на самом деле лень

Ясно. Я просто пытаюсь понять терминологию OpenStack.

да, там вся парадигма не совсем тривиальна для обычного ИТ, но нас усиленно ведут именно в этом направлении.

Просто когда-то на ЛОР пытались перевести на английский слово «быдло», сошлись на «cattle» :)

быдло и скот это одно и то же? наверное я плохо знаю русский язык

Ясно, спасибо.

без проблем. на самом деле, и я сейчас постоянно составляю дизайн таких вот датацентров, есть совмещенные решения, с набором хостов под pets и набором под cattle, с общим управлением и мониторингом. У нас это RHCI, с RHEV с одной стороны и openstack с другой, все под управлением cloudforms. Всякие одноразовые серверы и девопс забрасываются в опенстак, корпоративный набор серверов (мейл, базы и т.д.) бегают под RHEV, cloudforms за всем этим следит.

А это в документации где-то отражено?

должно быть :)

Почему-то я не могу найти в ней простых ответов... вот например, умеет ли OpenStack не виртуалки, а эмуляторы - PowerPC, например. По идее должен, но явно это нигде не сказано.

быдло и скот это одно и то же? наверное я плохо знаю русский язык

«Быдло» - это определенно «скот», «скотина». Просто само слово «быдло» скорее польское или белорусское.

cloudforms

Это закрытый продукт?

Почему-то я не могу найти в ней простых ответов... вот например, умеет ли OpenStack не виртуалки, а эмуляторы - PowerPC, например. По идее должен, но явно это нигде не сказано.

гуглить openstack nova powerpc support

«Быдло» - это определенно «скот», «скотина». Просто само слово «быдло» скорее польское или белорусское.

пусть будет, я привык воспринимать его в немного ином контексте.

Это закрытый продукт?

http://manageiq.org/

Кстати, спасибо за развернутые ответы - несмотря на свой опыт с Openstack, я много для себя прояснил.

Тем, кто посоветовал «поставь OpenStack и посмотри» - большое спасибо.

Поставь опенстек и посмотри. Я серьёзно. Если есть 16гб и виртуалбокс, то рабочее окружение можно получить простым скриптом: https://software.mirantis.com/quick-start/

Вполне сойдёт для предварительного изучения.

Поставь опенстек и посмотри.

OpenStack я обязательно поставлю, но немного позже. Когда решу, что понял, как работает Neutron.

А сначала ставить и смотреть - это путь, приводящий к появлению царей и анонiмусов. Нормальные люди сначала знакомятся с матчастью и говорят с теми, у кого есть опыт.

Mirantis Openstack - это не совсем ванильный Openstack.

Ванильный на посмотреть лучше брать тут - http://docs.openstack.org/developer/devstack/

Так ты совмещай и то и то - и ставь, и изучай.

Согласен. Но при обучении когда нужно просто получить рабочую лабу, чтобы было где экспериментировать и проверять правильно ли ты понял документацию это не имеет значения.

у меня у самого этого опыта около полугода, но меня швырнули прямо в воду (сразу 4 разных production установки, 3 новых и одна готовая, но требующая доработки), пришлось плыть :)

а можно без всего этого поставить devstack и поковыряться. разворачивается вообще на полном автомате. rdo тоже ставится без глюков.

Когда решу, что понял, как работает Neutron.

удачи, это надолго :)

Кидал выше - KVM и OpenStack (комментарий)

И RDO хорош, да.

Обучении с какой целью?

Ну у меня плюс-минус то же самое было)

Это к хвостострелу вопрос. У меня сложилось впечатление, что он просто пытается понять что такое опенстек и как с ним бороться.

Когда решу, что понял, как работает Neutron.

удачи, это надолго :)

Ну, мне же нужно только _решить_, что я понял :) Пока что мне кажется, что Neutron - это реализация виртуального свитча, как VDE (или Open vSwitch) + API для конфигурирования этого свитча; вместо встроенной реализации свитча может использоваться сторонняя (тот же vSwitch, но не мой любимый VDE, плак), причем API сохраняется.

Еще вопрос к гуру: умеет ли Cinder хранить тома (volumes) в локальных файлах? Я вижу плагины для NFS, LVM, чертовой уймы проприетарщины, но не вижу плагина для локальных файлов. Это никому не нужно, или локальный файл нельзя сервить через iSCSI, или я просто несу чушь от непонимания?

Дабы не плодить темы. Задам глупый вопрос. В чем отличии openstack от mirantis от openstack devstack? Кроме коммерческой поддержки. И выкладывает ли сабж сорцы (не нашел, пишут только что активно коммитят в апстрим).

В том что мирантис кастомизирует Openstack, выпуская свой продукт под названием Fuel.

Devstack - это набор для автоматизации развертывания ванильного Openstack.

нет, это реализация SDN контроллера управляющего плагинами через централизованный API.

это никому не нужно, насколько я знаю. не блочное это дело файлы хранить.

мне кажется, что Neutron - это реализация виртуального свитча, как VDE (или Open vSwitch) + API для конфигурирования этого свитча; вместо встроенной реализации свитча может использоваться сторонняя

нет, это реализация SDN контроллера управляющего плагинами через централизованный API.

Ну, на моем нынешнем уровне понимания разницы нет... правда, в презентации по Quantum на вопрос «Is Quantum „software-defined networking“?» ответили «it depends».

Но если реализации свитча внутри Quantum/Neutron нет, то вообще весь OpenStack (за исключением Swift, пожалуй) кажется набором прослоек для конфигурации системных facilities.

не блочное это дело файлы хранить.

Странно, на первый взгляд плагин для NFS с почти тем же успехом мог бы ыбть плагином localfs, и какие-то намеки в исходниках есть. Ладно, может, и мне это не надо :)

Это и так понятно. Какие там реально различия, которые могут быть полезными, по сравнению с оригинальным?

Ну, на моем нынешнем уровне понимания разницы нет... правда, в презентации по Quantum на вопрос «Is Quantum „software-defined networking“?» ответили «it depends».

абсолютно точный ответ :)

Но если реализации свитча внутри Quantum/Neutron нет, то вообще весь OpenStack (за исключением Swift, пожалуй) кажется набором прослоек для конфигурации системных facilities.

именно потому и it depends :) реализации свича как такового там нет, есть управление свичами, которые могут быть софтовыми или нет.

а вообще я вижу ты прозреваешь :) в опенстаке нет ничего своего, кроме побочных проектов которые тоже в принципе wrapper-ы. ну и с готовностью кода там тоже все не айс. продакшен на нем требует очень серьезного уровня поддержки

Странно, на первый взгляд плагин для NFS с почти тем же успехом мог бы ыбть плагином localfs, и какие-то намеки в исходниках есть. Ладно, может, и мне это не надо :)

технически именно так, nfs и просто fs почти не отличаются в данном случае. но так сложилось что хранить файлы просто на локальной фс в контексте openstack бессмысленно

Fuel - готовое к использованию решение (поставил и юзаешь), в отличие от ванильного опенстека, который нужно допиливать под себя.

С другой стороны, если нужно что-то допиливать, лучше это делать с сырым опенстеком, а не чьей-то поделкой

продакшен на нем требует очень серьезного уровня поддержки

На чем и зарабатывает Мирантис)

Понятно, значит не нужно.

отнюдь не только мирантис. но не будем вдаваться в эти разборки

devstack и fuel --- продукты разного класса. Первый --- простенький скрипт развернуть ванильный опенстек на поиграться. А второй --- разворачивает продакшен рэди окружение с фишками от мирантиса.

Вот, ну наконец уже ближе к тому, что я хотел узнать. Какие фишки?

В общем, насколько я сейчас понимаю, Linux предоставляет детали, а OpenStack - гайки и болты, чтобы их скручивать. Такое понимание мне и нужно было. Жаль, что в интернетах пишут всякую маркетинговую шелуху.