А кто реально серьезно использует OpenStack в продакшене.

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

rackspace же

Я в вялотекущем режиме поднял стенд у себя, cunder,keystone,glance, nova, qpid все на одной ноде.. Ну понимание есть более менее, доку постоянно читаю. Мы думаем использовать его как аналог VSphere и Vcloud с самописным личным кабинетом для пользователя..
Хостинг – нет, это будет что-то вроде PaaS для конечного польователя..

Не очень ясно как там ситуация с живой миграцией, балансировкой и проче...

Да, но rackspace судя по всему 50% своего дописал ) И потом он хостер, а у нас планируется PaaS с бллингом и кабинетами..

tazhate, вроде как.

У меня есть некий опыт в ковырянии OpenStack , было бы классно с кем-то пообщаться, опытом поделиться увлеченной этой же темой .. Свежий вопрос , не совсем ясно как быть с кластерной ФС, использовать ли ее, какую использовать.. какие преимущества она даст..
У нас нету пока распределенной структуры, все живет в одном C3000 с 8-ю лезвиями..

Да, судя по скиллам: Cloud Software: Nebula, OpenStack, CloudStack. Крутой спец..

Супер все объяснил, а задачи то какие?

Мы (ru.fedoracommunity.org) и openstack.ru планируем в районе 21 сентября в Москве организовать совместное мероприятие посвященное облакам вообще и OpenStack в частности. Будете проходить мимо - присоединяйтесь. Там можно будет пообщаться и с теми, кто использует, и с теми, кто внедряет.

Мы думаем использовать его как аналог VSphere и Vcloud с самописным личным кабинетом для пользователя.

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

Вот у меня в первую очередь вопросы именно к ней. Какое железо, сколько, куда и как раскидано, как хочется все это дело чтобы работало и тд.
Иначе как-то слишком пространственно получается.

Мы (russianfedora.ru) и openstack.ru планируем в районе 21 сентября в Москве организовать совместное мероприятие посвященное облакам вообще и OpenStack в частности. Будете проходить мимо - присоединяйтесь. Там можно будет пообщаться и с теми, кто использует, и с теми, кто внедряет.

О! Запостите новость на главную, приду обязательно.

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

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

Свежий вопрос , не совсем ясно как быть с кластерной ФС

Зависит от задач же! Именно их я и пытаюсь понять в твоем случае.

Кстати, если есть деньги, то было бы намного быстрее и удобнее обратиться к тому же Mirantis для интеграции.

Запостим конечно, только утрясём детали немножко.

я. что конкретно интересует?

Железо: Все это расположено в одной стойки одного ДЦ.
Пока это HP BladeSystem c3000 с восемью лезвиями HP ProLiant BL460c Gen8 (96GB RAM))
И хранилище HP P 2000 с полками расширения на 18 TB

С точной архитектурой пока сложно, ее как бы нет =(. Поступила задача сделать облачную платформу для предоставления разных других платформ в этом облаке, вот и все. Ну, к примеру, что-то типа виртуальный сервер 1С, или SAP в облаке, или Service Desk,.. Теперь я сижу и думаю как быть, на чем пытаться разворачивать.. Я имею хороший опыт работы с Vsphere c Vcloud, но к сожалению как всегда деньги на такие решения тратить не хотят.

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

1. Как, где лучше всего располагать служебные OpenStack сервисы (nova, glance, cinder,keystone итд.. ) , думаю отдать под них два лезвия они будут служебные полностью, сделать идентичные конфиги и думать над хетбитингом ? А на остальных 6-и оставшихся серверах развернуть RHEL6.4+ KVM+nova.

2. Пока не совсем ясно как быть с живой миграцией машинок между двумя физическими серверами, что мне для этого нужно? Общую ФС ? Какую ?

3. Нужен ли мне Swift ? Я понимаю, что это объектное хранилище но какие объекты там хранят? Образы виртуальных машин, это iso, img для инсталла и прочее ? Или это полноценный vmdk или q2cow ? Тут у меня путаница..

4. Допустим я создаю новую VM на 200Gb hdd,где будет лежать q2cow ее образ? Как только я ее потушу.? Верно ли, что стартуя она вся потянется в оперативную память на KVM ноде..

5. Я верно понимаю, что на KVM ноде не нужно выделять места на HDD на виртуальные машины.

6. Какой плюс в использовании iscsi в cinder нежели чем на прямую FC? Т.к у меня на каждом лезвии есть по два FC контроллера..

7. Есть ли в OpenStack такое понятие как DRS, FailtTolerance, ?

8. Если нода с виртуальной машиной падает, как происходить ее поднятие на другой ноде, ? Какие риски потерять полностью машин?

Ниже чел ответил %)

Честно говоря кроме меня у нас в “команде” в этих технологиях никто ничего не понимает вообще.. поэтому я занимаюсь и настройкой cisco и настройкой san свитча , зон, лун и всего что связано в SAN, NET… ну а также теперь с софтовой частью.. Вот такая вот беда =))) Cтенд с OpenStack вроде поднял,не не через скрипты автоматические или puppet, а руками каждый модуль , это вроде помогло понять что есть … quantum пока решил не ставить.. хотя пока не определился в необходимости его…

Управляющие ноды на FC19, а nova ноды на RHEL 6.4

1. Как, где лучше всего располагать служебные OpenStack сервисы (nova, glance, cinder,keystone итд.. ) , думаю отдать под них два лезвия они будут служебные полностью, сделать идентичные конфиги и думать над хетбитингом ? А на остальных 6-и оставшихся серверах развернуть RHEL6.4+ KVM+nova.

вариант с разными блейдами хорош. в идеале это конечно лезвия в разных корзинах. все сервисы openstack поддерживают HA, достаточно правильно их настроить, а также mq и базы. что такое хетбитинг не знаю %|

2. Пока не совсем ясно как быть с живой миграцией машинок между двумя физическими серверами, что мне для этого нужно? Общую ФС ? Какую ?

вариантов много. можно просто пейсмейкером фейловерить файлуху, но это костыльно. лучше общую ФС, как vmfs. Рекомендую Veritas CFS. все остальное что пробовал более или менее говно и отваливается, даже нфс лучше (производительнее, надежнее (боже, я только что использовал слова «нфс» и «надежность» в одном предложении)).

3. Нужен ли мне Swift ? Я понимаю, что это объектное хранилище но какие объекты там хранят? Образы виртуальных машин, это iso, img для инсталла и прочее ? Или это полноценный vmdk или q2cow ? Тут у меня путаница..

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

4. Допустим я создаю новую VM на 200Gb hdd,где будет лежать q2cow ее образ? Как только я ее потушу.? Верно ли, что стартуя она вся потянется в оперативную память на KVM ноде..

qcow2 будет там куда положишь =/. мы ложим на Ceph. нет, при запуске он не вычитывается полностью, это только со свифта если.

5. Я верно понимаю, что на KVM ноде не нужно выделять места на HDD на виртуальные машины.

не нужно, если сторедж есть.

6. Какой плюс в использовании iscsi в cinder нежели чем на прямую FC? Т.к у меня на каждом лезвии есть по два FC контроллера..

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

7. Есть ли в OpenStack такое понятие как DRS, FailtTolerance, ?

нет и нет. есть HA, костыльный, FT пилят но пока неюзабельно. да и даже в vsphere с 10Г линком оно тормозит нехило по понятным причинам.

8. Если нода с виртуальной машиной падает, как происходить ее поднятие на другой ноде, ? Какие риски потерять полностью машин?

nova-scheduler принимает решение где, и машина поднимается. риски — тут я не понял про какие именно риски ты спрашиваешь?

спасибо, пропустил бы...

Спасибо огромное за ответы!

вариантов много. можно просто пейсмейкером фейловерить файлуху, но это костыльно. лучше общую ФС, как vmfs. Рекомендую Veritas CFS. все остальное что пробовал более или менее говно и отваливается, даже нфс лучше (производительнее, надежнее (боже, я только что использовал слова «нфс» и «надежность» в одном предложении)).

По Veritas CFS вообще никогда ничего не слышал, попробую погуглить адекватное описание.. Я вот смотрел в сторону Ceph’s RADOS Block Device (RBD) но пока не очень ясно на сколько оно тут применимо..

qcow2 будет там куда положишь =/. мы ложим на Ceph. нет, при запуске он не вычитывается полностью, это только со свифта если.

Т.к у вас на сторадже где лежат все образы VM, Ceph FS?

Если я не ошибаюсь, Cinder использует LVM и рулит волюмами, я прост как-то с недоверием к LVM есть ли альтернатива?

все остальное что пробовал более или менее говно и отваливается

Да ладно, а ceph?

Да ладно, а ceph?

Вот тоже очень много читаю хорошего о ceph FS,

Т.к у вас на сторадже где лежат все образы VM, Ceph FS?

да. но у нас нет стореджа, просто обычные сервачки с хдд, на них rbd ceph, от них iscsi.

Если я не ошибаюсь, Cinder использует LVM и рулит волюмами, я прост как-то с недоверием к LVM есть ли альтернатива?

совершенно не стоит боятся lvm, хорошее, проверенное решение. альтернатива — все тот же veritas, в частности vxvm (тот что сейчас компонент в storage foundation). отличная штука, намного круче lvm, но не бесплатно.

ceph ceph'у рознь. мы используем rbd, про cephfs слышал много плохого от людей которые его пытались использовать и которым я склонен верить, хотя сам и не пробовал.

Как оказалось информации по Veritas CFS не так уж и много, вернее русскоязычных отзывов и так называемых ”best practices” Если я все верно понял она совсем не бесплатная, а о стоимости видимо до контакта с их менажёром узнать ничего не получится.. Поэтому будет сложно убедить реководство в целесообразности покупки ФС. Похоже, что из бесплатных альтернатив придётся тестировать GFS2, OCFS2…

тестируйте. но именно о них я говорил что они малоприигодны — в основном из-за тенденции падать (блокировать все ноды, терять консистентность метаданных етц) в нештатных ситуациях. короче говоря, это в определенной мере gamble хотя ситуация медленно исправляется....

А какую вы ОС используете под исправляющее ноды?
Не так давно обнаружил, что RedHat активно решило включиться в разработку OpeStack, начав выпускать свою адаптированную версию пакетов OpenStack под кодом RDO. Пробывали? Есть ли смысл с ними связываться?..

Сейчас у меня есть парк серверов с разными гипервизорами.. ESXi5, Xen, KVM ..
Уживутся ли они между собой в пределах одной управляющей ноды?
При условии, что сторадж у них один будет ..

А какую вы ОС используете под управляющее ноды?

fixed..

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

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

А какую вы ОС используете под исправляющее ноды?

ubuntu

Не так давно обнаружил, что RedHat активно решило включиться в разработку OpeStack, начав выпускать свою адаптированную версию пакетов OpenStack под кодом RDO. Пробывали? Есть ли смысл с ними связываться?..

неа, не пробовали пока.

Уживутся ли они между собой в пределах одной управляющей ноды?

незнаю, сорри. вам действительно надо такой зоопарк гипервизоров? можно поинтересоваться зачем?

кстати. тред про OpenStack, но продукты Joyent нельзя не рекомендовать. Если бы не отсутствие совместимости на уровне API с OpenStack, мы бы 100% использовали SmartOS, она офигенна даже более, чем Solaris 11

Выбили все таки ключик на VRTS STORAGE FOUNDATION ENTERPRISE CLUSTER FILE SYSTEM HA 6.0 S64LNX.
Оказалось, что это целый набор решений Сейчас начал разбираться как все это настраивается. При условии, что у нас пока только один сторадж на 20TB. и четыре Nova-node
Мануалы по администрированию конечно почетного размера.. надеюсь, разберусь быстро…
Видимо теперь использование этой ФС обяжет использовать только RHEL в качестве Nova nodes…

Евгений, А как вы Vritas cfs и Cinder подружили ? У вас вычислительные ноды по FC соединены со стораджем ?

ээ, я же несколько раз писал, что на этом проекте у нас нет нормального стореджа — все на ceph rbd с экспортом по iscsi...

в любом случае — в чем проблема? да, вам надо будет подключить nova ноды к аррею.

cephfs или rbd в ceph? Разные вещи же!

наверно я что то не понимаю, но ни как не пойму - зачем вам распределенная файловая система, если у вас один общий сторадж, который будет шариться по FC на все блэйды лунами? Или на блэйдах еще диски закуплены и вы хотите и их задействовать?

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

наверно я что то не понимаю, но ни как не пойму - зачем вам распределенная файловая система, если у вас один общий сторадж, который будет шариться по FC на все блэйды лунами? Или на блэйдах еще диски закуплены и вы хотите и их задействовать?

Да, Lun-ы будут шариться на все вычислительные ноды, в качестве менеждера томов CLVM + ФС..
Вот с ФС мне до сих пор не ясно, использовать кластерную или можно будет обойтись ext4.. Мне важно чтобы была возможность мигрировать виртуальным машинам на физические другие сервера которые имеют доступ к этому LUN. Т.е скорее всего исполья обысную ФС я даже не смогу под монтировать LUN на второй или третий сервер..

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

Суть: компания созрела для облачного решения, есть over 10 физических серверов (linux, windows, приложения, базы данных, сервисы etc.) и появился смысл все это дело завиртуализировать.

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

Для стендовых экспериментов есть с десяток слабеньких серверов (двуядренные процы @2.8 с поддержкой Intel vt, 4Гб памяти, 2х500Гб харды). Думаю, этого более чем хватит для стендовых испытаний и показательных выступлений.

Прежде чем приступить к ковырянию конфигов хотелось бы уяснить сколько и чего мне понадобиться. В моем понимании готовая система должна состоять как минимум из двух серверов и внешнего хранилища, либо просто двух серверов с drbd, например. Но почитав документацию от той же компании Mirantis увидел только конфигурации минимум с тремя серверами, не считая внешнего хранилища. Понятное дело, что OpenStack - система гибкая и можно нагородить что угодно, но тут интересует именно best-practice, как сделать правильно.

Далее, опять таки возвращаясь к HA - трушный FT таки не запилили, а есть ли альтернатива с рабочим FT, и чтоб не пришлась за нее последние штаны отдать? Есть некоторые сервисы, которые уж очень критичные к простоям.

В моем понимании готовая система должна состоять как минимум из двух серверов и внешнего хранилища, либо просто двух серверов с drbd, например. Но почитав документацию от той же компании Mirantis увидел только конфигурации минимум с тремя серверами, не считая внешнего хранилища.

Если вам нужна НА (высокая доступность) - то три сервера необходимо как минимум. Дело в том, иначе как арбитру определить что тот или иной сервер упал, а не просто серваки оказались изолированными по сети друг от друга. Т.е. использовать 2 сервера можно, но с НА в таком случае возможны накладки.

По поводу СХД - можно использовать как общий СХД (отдаю предпочтение NFS),так и кластерную ФС на нескольких серваках (не собирал, практики нет, не знаю).

Далее, опять таки возвращаясь к HA - трушный FT таки не запилили

Не надо путать НА и FT:НА == это когда при падении физического хоста машинки перезапускаются на другом сервере. FT == при падении физического хоста машинка тут же включается в работу на другом хосте, без простоя и потери данных.

Не надо путать НА и FT:НА == это когда при падении физического хоста машинки перезапускаются на другом сервере. FT == при падении физического хоста машинка тут же включается в работу на другом хосте, без простоя и потери данных.

Я не путаю, как раз в том то и вопрос - для большинства сервисов простой в пару минут не критичен, но у нас так же есть сервисы, которые должны быть доступны 100% времени. У vmware с этим делом тоже далеко не все так радужно, несмотря на заявления. Сейчас у нас это дело реализовано системой костырей и подпорок (бд-репликация, heartbeat, свои скрипты). В принципе, оно работает и свои обязанности выполняет, но коли заморачиваюсь с облаками, думал о возможности более красивого и стабильного решения.

Исходя из статьи: http://habrahabr.ru/company/mirantis_openstack/blog/175807/

Нужно по узлам:
2 х оконечный (балансировка, HA);
2 х управляющий (БД, очередь, коммуникация, админка);
2< х вычислительный (гипервизор с виртуалками на борту);
? хранилище (nova-storage).

Так вот... зачем нужен nova-storage, если он всего лишь принимает, например, тот же iSCSI/SAN/NAS и раздает внутри кластера? И нужен ли он вообще, если можно то же самое раздать без него.

По железу получается... можно объединить оконечные и управляющие узлы - это 2 машины.
Вычислительные узлы лучше отдельно - по требованиям, но минимум 2.
nova-storage - 2 шт, тоже можно объединить с оконечными и управляющими узлами, но с учетом хорошего сетевого обеспечения (толстые сетевые / агрегация каналов / FC...).
Внешнее хранилище - 2 шт, на случай если сдохнет, например, контроллер на полке.

В принципе, опять возвращаемся к тому, что абсолютно все можно поднять на двух машинах, с учетом достаточной производительности оных. Так что нужен совет практикующих облачистов... /Вернулся к началу.

Я верно понимаю, что если я создаю VM из Flavor, тогда HDD для этой машины не создается, все находится только в оперативной памяти и при рестарте данные теряются?

А если я при создании указываю, что нужно создать volume на 20 GB и приаттачит его к виртуальной машине, то появляется возможность поставить туда систему с CD и в следующие разы грузиться с него?

Также не совсем ясно, почему для притачивания блочного устройства используется iscsi, неужели нельзя просто указать:

<disk type="block" device="disk">
      <driver name="qemu" type="raw" cache="none"/>
      <source dev="/dev/cinder-volumes/volume-e6cc2af0-5550-478e-9f5b-3b1ad9f6b073"/>
      <target bus="virtio" dev="vda"/>
      <serial>e6cc2af0-5550-478e-9f5b-3b1ad9f6b073</serial>
    </disk>

А то, из коробки там в source dev указан iqn адрес для iscsi и это не работает...

Внешнее хранилище - 2 шт, на случай если сдохнет, например, контроллер на полке.

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