KVM и OpenStack

Емнип, своя реализация HA, всякие доделки внешних проектов сначала применяются внутри, а потом уезжают в апстрим, есть свои проекты в рамках опенстека + разные фишки, связанные с интеграцией со сторонними продуктами типа использования vmware nsx в качестве sdn.

Linux это только один винтик в этой махине, там реально до хренища компонентов наворочено

Ты путаешь.

Fuel - это установщик для OpenStack, пожалуй самый продвинутый по фичам на данный момент по набору поддерживаемых сценариев установки и общему виду. Продукт, который выпускает Mirantis - это Openstack-дистрибутив + Fuel как средство его установки. Называется это Mirantis OpenStack.

При этом с помощью Fuel можно разворачивать и «ванильный» OpenStack, если зависимости подредактировать.

А Devstack - это _исключительно_ средство для разработчика. Его нельзя использовать для реального разворачивания OpenStack, только для отладки и разработки. Это по сути большой bash-скрипт, который делает установку всех сервисов OpenStack на один хост и дает возможность дебажить эти процесс через screen.

devstack - это «интерактивная» разработка конкретных openstack-сервисов в screen с установкой OpenStack из Git на одном хосте.

Fuel - это реальное развертывание опакеченного OpenStack с выбором базового дистрибутива, с возможностью назначать роли для разных нод, c HA для контроллеров, с бонусами в виде апгрейдов и плагинов.

Выглядит примерно так http://demo.fuel-infra.org:8000/

Linux это только один винтик в этой махине, там реально до хренища компонентов наворочено

Имеется в виду Linux как ОС, конечно. Не как ядро.

даже как ОС, большинство контроллеров написаны под линукс, но это пайтон, он неплохо портируется. а гипервизоры поддерживаются разные

Почему путаю? То же самое я и имел в виду, возможно я не вполне корректно сформулировал (в частности, запутался в наименованиях и назначении Fuel - был уверен что это и есть целостный Openstack от Mirantis). Я с ним непосредственно не работал - работал только с тем, что развернули до меня, потому прошу простить.

А насчёт devstack - я и не говорил что пора в продакшн. Речь шла о «напосмотреть», почему б и не заюзать его?

Небольшой оффтоп: а ты имеешь к мирантису отношение? Знаю что твой коллега по RF Гнатенко с недавних пор там работает.

Да, я в команде Fuel почти что год уже. Правда я занимаюсь инфраструктурой для разработки и тестирования, а не самим OpenStack-ом.

Linux это только один винтик в этой махине, там реально до хренища компонентов наворочено

Имеется в виду Linux как ОС, конечно. Не как ядро.

даже как ОС

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

это пайтон, он неплохо портируется

Тот код, который я успед посмотреть, портируется очень плохо. Прямые вызовы tgt, mount.nfs... там тупо нет абстракции.

Ну, когда появится OpenStack для венды

Но зочем?

Тут скорее подходит аналогия, что Linux для Openstack - это то же что ядро для Linux.

Тут скорее подходит аналогия, что Linux для Openstack - это то же что ядро для Linux.

Скорее подходит по какому критерию? Если мы сравним массу и сложность кода «Linux как ядра» и «Linux как ОС», «Linux как ядро» просто потеряется. Если так же сравним «Linux как ядро» и OpenStack - потеряется OpenStack.

Если не нравится аналогия с болтами и гайками - считай, что OpenStack - это shell, а то, что он интегрирует - утилиты CLI.

Разве что в контексте Hyper-V, и то нужность крайне сомнительна.

Ну, когда появится OpenStack для венды

Но зочем?

Если споявится - значит, нужен зачем-то. Пойнт в том, что пока OpenStack есть только для Linux, он является болтами для скручивания компонентов Linux.

Пойнт в том, что пока OpenStack есть только для Linux

Не только - гугли Openstack+vsphere

Говорят, что уже.

Правда, я в сторону OpenStack пока смотрел чисто умозрительно.

Не, я ничего не имею против болтов и гаек и я не про код говорю.

Просто если рассматривать логические части OpenStack, то там можно увидеть компоненты типа «Сеть», «Файловая система», «Блочное устройство», там есть системы инициализации, есть логи, есть интерфейс для пользователя и т.п., только все это уровнем выше и размазано по нескольким железкам.

С этой точки зрения OpenStack - это операционная система, в которой вместо процессов оперируют виртуальными машинами. И Linux в ней - это такое базовое ядро не ядро, но в общем самый нижний уровень, невидимый обычному пользователю.

гугли Openstack+vsphere

Боюсь, что для понимания фраз вроде

VIO packages the stable release of OpenStack into an OVA and delivers it as a vApp so that OpenStack can be deployed as an “over-cloud” on to a VMware based “under-cloud.”

нужно знать какой-то VMware-speak, который я не знаю и даже учить не планирую из-за ненадобности.

Ну и в большинстве своем для многих целей используются линуксовые утилиты же.

Ты говорил что Openstack завязан на Linux. Я тебе намекнул что это не так. О том, что тебе учить я не говорил.

Просто если рассматривать логические части OpenStack, то там можно увидеть компоненты типа «Сеть», «Файловая система», «Блочное устройство»

Я там не увидел таких компонентов. Вот компоненты «настройщик сети», «настройщик доступа к блочному устройству по iSCSI» - есть, а «Сети» и «Блочного устройства» - нет.

OpenStack - это операционная система, в которой вместо процессов оперируют виртуальными машинами

Сойдемся на том, что каждый имеет право на свою ментальную модель, но ИМХО твоя притянута за уши - хотя бы потому, что «процессы» «ОС OpenStack» не пользуются ее услугами.

Ты говорил что Openstack завязан на Linux. Я тебе намекнул что это не так.

А другие об этом сказали прямо. По твоему же посылу гуглится только VMware-speak.

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

Ну это вопрос выбора определений

Что именно является «вопросом выбора определений»? Обращение за услугами - это вопрос передачи данных. Есть передача запроса от гипервизора к OpenStack на обслуживание, выполнение OpenStack этого запроса и возвращение результата? Я не говорю, что такой передачи нет, просто она противоречит ментальной модели, которую я составил за пару дней чтения документации по OpenStack

Считать ли например Ceph компонентом OpenStack или считать его самостоятельным сервисом

Хм. Этот вопрос точно есть? У кого, почему? Мне всегда казалось очевидным, что Ceph - совершенно самостоятельный сервис (точнее, набор сервисов), умеющий работать при полном отсутствии OpenStack. А OpenStack обеспечивает интеграцию этих сервисов.

http://stackalytics.com/report/driverlog

Там упомянуты Hyper-V и vSphere, но надо искать подробности, что конкретно поддерживается и на каком уровне.

Да, пожалуй Ceph это не подходящий пример. Он скорее планка памяти, которую можно вставить или убрать по необходимости. А надо было взять cinder, как собственно block storage-сервис.

Ну и понятно, что это просто аналогия, и тут есть к чему придраться, если захотеть. Просто «набор утилит» это верно, но слишком абстрактно, а аналогия с операционной системой позволяет чуть точнее представлять себе структуру проекта как набора программ реализующих разные части этой системы: https://wiki.openstack.org/wiki/Programs

Да, пожалуй Ceph это не подходящий пример. Он скорее планка памяти, которую можно вставить или убрать по необходимости. А надо было взять cinder, как собственно block storage-сервис.

Да блин. В качестве примера чего надо было взять Cinder - в качестве примера не самостоятельной службы? Прекрасно. Но Cinder тоже просто конфигурирует доступ гипервизора к ресурсу, потом отдает этот ресурс гипервизору и тот использует ресурс, никак не обращаясь к Cinder.

Просто «набор утилит» это верно, но слишком абстрактно

Ы? Я не называл OpenStack «набором утилит». Я сказал, что OpenStack - это shell, а «набор утилит», которые он объединяет - это Linux.

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

Вот и я думал, что OpenStack похож на ОС. А он похож на shell.

https://wiki.openstack.org/wiki/Programs

Это чуть ли не первое место, куда я заглянул.

Я очень мало знаю про Hyper-V, но, например, для поддержки vmware vsphere переход на виндовс не понадобился. nova спокойно работает на линуксе и командует vsphere, запущенном на винде. Если гипервэ позволяет удалённое управление, то так же можно поступить и с ним.

Я не понял к чему ты это сказал

Ну собственно, еще сюда загляни - http://docs.mirantis.com/openstack/fuel/fuel-5.1/

я к тому, что для поддержки hyper-v портировать опенстек на винды не нужно.

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

Можешь все-таки пояснить преимущество банальных систем виртуализации, которые ты перечислил перед частными «облаками», в первую очередь openstack?

google://pets+vs+cattle

Спасибо)

И оффтоп - ты все еще сотрудник enovance?

Тут на носу возможная миграция с банального kvm/libvirt на что-то серьезнее, думаю насчет ovirt, openstack или стороннего провайдера типа amazon, могут быть вопросы по выбору технологий на миграцию

Спасибо)

да без проблем. на самом деле, в любой нормальной фирме, где у начальства мозг работает, openstack будет работать параллельно с обычной виртуализацией, более того, при наличии того же RHEV, у которого есть HA из коробки, контроллеры openstack садятся туда в виртуалки, и не надо городить кучу легко ломающихся решений типа keepalived, haproxy и т.д. только ради обеспечения высокой доступности. У нас это RHCI, мирантис вроде как ставят вмварь, ну и вообще, вариантов хватает.

И оффтоп - ты все еще сотрудник enovance?

ага, хотя это фактически red hat

Тут на носу возможная миграция с банального kvm/libvirt на что-то серьезнее, думаю насчет ovirt, openstack или стороннего провайдера типа amazon, могут быть вопросы по выбору технологий на миграцию

пиши сюда, или на мойник@гмыло, если смогу - помогу

при наличии того же RHEV, у которого есть HA из коробки, контроллеры openstack садятся туда в виртуалки, и не надо городить кучу легко ломающихся решений типа keepalived, haproxy и т.д. только ради обеспечения высокой доступности.

Это же и ovirt касается?

пиши сюда, или на мойник@гмыло, если смогу - помогу

Спасибо, занес в контакты

Это же и ovirt касается?

само собой, просто RHEV стабильнее и с т.з. продакшена я бы всегда рекомендовал заплатить за него (тем более что цена не особо кусается, по сравнению с ценами на все остальное в большом ДЦ).

кстати, если использовать RHCI (ну или ovirt+rdo) всем можно управлять из под одной панели cloudforms (или его апстрим manageiq.org)

само собой, просто RHEV стабильнее и с т.з. продакшена я бы всегда рекомендовал заплатить за него (тем более что цена не особо кусается, по сравнению с ценами на все остальное в большом ДЦ).

Цена - тут? https://www.redhat.com/en/files/resources/en-rhev-vs-vmware-vsphere-competiti...

кстати, если использовать RHCI (ну или ovirt+rdo) всем можно управлять из под одной панели cloudforms (или его апстрим manageiq.org)

Я правильно понимаю что для Pets ты рекомендуешь RHEV/ovirt, для Cattle - Openstack (RDO)?

а у меня такой вопрос, как на fedora поставить полноценный rhev и потестить? хочу посмотреть, удобнее ли он чем vsphere. Не подскажешь какой реп подключить, а то чтот нифига не понял где он там.

Цена - тут? https://www.redhat.com/en/files/resources/en-rhev-vs-vmware-vsphere-competiti...

не знаю насколько свежий этот документ, но похоже на правду. емнип там что-то около $500 за сокет за год, без доплат за фичеры, и плагины. Можно договориться и дешевле наверное, я не продаван, точных деталей не знаю. Помню только как в одном из проектов, подписка на RHEV оказалась 2к, против 20к на вмварь.

Я правильно понимаю что для Pets ты рекомендуешь RHEV/ovirt, для Cattle - Openstack (RDO)?

именно так. RDO/RHEL-OSP

а у меня такой вопрос, как на fedora поставить полноценный rhev и потестить? хочу посмотреть, удобнее ли он чем vsphere. Не подскажешь какой реп подключить, а то чтот нифига не понял где он там.

rhev на федору не поставишь, там нужен RHEL и/или RHEV-H.

на федору можно поставить ovirt, есть вариант all-in-one (все на одном хосте), хотя такой вариант не покажет всех возможностей системы (LB/HA/live migration/...). http://www.ovirt.org/OVirt_Live

на федору можно поставить ovirt, есть вариант all-in-one (все на одном хосте), хотя такой вариант не покажет всех возможностей системы (LB/HA/live migration/...).

Правильно ли я понимаю что ovirt пока нет возможности установить на CentOS 7?

Правильно ли я понимаю что ovirt пока нет возможности установить на CentOS 7?

есть, и уже давно

Не туда смотрю? http://www.ovirt.org/Quick_Start_Guide#Install_oVirt_Engine_.28Fedora_.2F_Red...


Или просто ман и под CentOS 7 подходит?

меня просто интересовали Storage I/O control, Storage multy path в kvm чистом этого вроде нет.

странная штука, вроде как engine пакеты только под el6, а vdsm и все что вокруг (то есть гипервизор) есть под el7. я смотрю на http://resources.ovirt.org/pub/ovirt-3.5/

можно написать на users@ovirt.org, узнать что там с пакетами engine под el7, скажут точно.

установка сама по себе простая - цепляем репозитории, делаем yum install ovirt-engine, прогоняем engine-setup и контроллер готов. хосты добавляются прямо из гуев - надо только дать айпи о пароль рута, на хосте должны быть прописаны репозитории в которых есть vdsm и прочее. engine сам полезет, все поставит, создаст ключи и хост станет доступен для дальнейших настроек

меня просто интересовали Storage I/O control, Storage multy path в kvm чистом этого вроде нет.

а зачем гипервизору эти вещи? это все обеспечивается линуксом. storage io через cgroups и ionice, multipath через device-mapper-multipath. kvm именно поэтому так быстро был написан и так легко раскрутился, что нет никакого смысла дублировать функционал который уже есть в ядре и в операционной системе. Так что kvm по сути это драйвер для VT/AMD-V, а все остальное сам линукс уже и так давно и хорошо умеет.

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

По сути что мне нужно, я хочу в веб интерфейсе видеть общее кол-во операций ввода/вывода на сервере, загруженность дисковой системы, и на сколько гипервизор считает загружена дисковая система в процентах. Хотелось бы иметь доступ к умным утилям от hp прямо из гипервизора, потому что если вдруг получу san от hp это может быть полезным. Не всегда есть время и желание разбирать, иногда хочется умной статистики от самой техники. Можно конечно zabbix натянуть, но это всё же не то.