LINUX.ORG.RU
решено ФорумAdmin

oVirt - насколько оно стабильно и каким его вариантом лучше пользоваться.

 , , ,


1

5

Привет лор!

Есть у меня несколько древних серверов, которые используются для целей тестирования всяких разных вещей. Сейчас на них используется proxmox, но я хочу попробовать переехать на oVirt. В связи с этим вопросы:

  • На сколько оно стабильно, если регулярно обновляться «не глядя», часто ли оно ломается и требуется ли ручное вмешательство? Можно ли спокойно обновляться на мажорные релизы?
  • Есть ли какие-нибудь стабильные репы(пересборка RHEV?) и какие репы лучше использовать?
  • Как лучше ставить?

    Есть liveimage, который, я так понял, можно установить. Есть ли в нем поддержка установки на софт-рэйд, или надо будет костылять? Я так понял, это та же centos 6 + ovirt repo, но простое в установке. Или это что-то другое? Можно ли мешать хост-системы (centos 6, 7, fedora) при условии одинаковых версий ovirt'a (ну там, посмотреть как оно на 7 центоси)?

    Или надо ставить отдельно центос и на него из реп ovirt?

Сильно много времени я на это растратить не могу, так что хотелось бы, чтобы сразу «приемлимо» заработало.

В общем ждём истории успеха и ваши впечатления.

Перемещено DoctorSinus из talks

★★★★★

На сколько оно стабильно, если регулярно обновляться «не глядя», часто ли оно ломается и требуется ли ручное вмешательство? Можно ли спокойно обновляться на мажорные релизы?

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

Есть ли какие-нибудь стабильные репы(пересборка RHEV?) и какие репы лучше использовать?

надо использовать родные репы. для стабильности, на хостах центос а не федора.

Есть liveimage, который, я так понял, можно установить.

я бы ставил centos minimal, обновлять конечно сложнее чем имидж накатывать, но зато можно использовать vdsm-hooks и поднимать софтрейды и прочие штуки

Я так понял, это та же centos 6 + ovirt repo, но простое в установке. Или это что-то другое?

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

Можно ли мешать хост-системы (centos 6, 7, fedora) при условии одинаковых версий ovirt'a (ну там, посмотреть как оно на 7 центоси)?

в одном кластере не рекомендуется - разные версии libvirt/kvm/qemu плохо работают вместе. в одном датацентре, можно развернуть несколько разных кластеров, и тогда по идее проблем быть не должно.

Или надо ставить отдельно центос и на него из реп ovirt?

для продакшена - самое то.

В общем ждём истории успеха и ваши впечатления.

ну как бы 5 лет в разработке, поддержке и управлении разработкой этого дела, историй успехов полно на сайте red hat, некоторые сам начитывал :)

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

Спасибо за исчерпывающие ответы.

историй успехов полно на сайте red hat

В успехах rhev не сомневаюсь, а вот в успехах овирт есть немного.

Ещё вопросик про обновления. Обновлять надо одновременно все ноды или можно обновлять ноды по очереди? В особенности в случае мажорных релизов. У меня будет только один кластер из 5 узлов, проверять обновления особо не на чем, да и хотелось бы без даунтайма.

И ещё вопрос, как оно переживает не очень надёжное железо? А то у проксмокса с HA с этим не очень гладко (работает, но бывают заминки со сборкой назад в кластер).

Ivan_qrt ★★★★★
() автор топика
Ответ на: комментарий от Ivan_qrt

В успехах rhev не сомневаюсь, а вот в успехах овирт есть немного.

ну это как сказать «в успехах RHEL не сомневаюсь, но вот в успехах fedora есть немного» :) это все таки немного полигон для RHEV, как ни крути. Хотя я знаю провайдеров и фирмы которые используют и вполне довольны. В любом случае, при тех масштабах на которые RHEV рассчитан, $500 за сокет это не деньги.

Ещё вопросик про обновления. Обновлять надо одновременно все ноды или можно обновлять ноды по очереди? В особенности в случае мажорных релизов. У меня будет только один кластер из 5 узлов, проверять обновления особо не на чем, да и хотелось бы без даунтайма.

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

И ещё вопрос, как оно переживает не очень надёжное железо? А то у проксмокса с HA с этим не очень гладко (работает, но бывают заминки со сборкой назад в кластер).

упал хост, его зафенсили, и подняли HA виртуалки на других. все очень просто. правда фенсинг нужен, хотя бы по ipmi

dyasny ★★★★★
()
Последнее исправление: dyasny (всего исправлений: 1)
Ответ на: комментарий от dyasny

упал хост, его зафенсили, и подняли HA виртуалки на других. все очень просто. правда фенсинг нужен, хотя бы по ipmi

Ноды воткнуты в циску, проксмокс сейчас фенсит через неё. Я так понял, что после подъёма хоста и разблокировки портов, он обратно зайдёт в кластер и будет всё ок?

И ещё подтвердите плиз, что если падает нода с управляющей виртуалкой (которая ovirt engine), то она сама поднимется на другой ноде и потом поднимет всё грохнувшееся, что HA. Я понял это так, но не уверен.

Ivan_qrt ★★★★★
() автор топика
Ответ на: комментарий от Ivan_qrt

Ноды воткнуты в циску, проксмокс сейчас фенсит через неё. Я так понял, что после подъёма хоста и разблокировки портов, он обратно зайдёт в кластер и будет всё ок?

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

И ещё подтвердите плиз, что если падает нода с управляющей виртуалкой (которая ovirt engine), то она сама поднимется на другой ноде и потом поднимет всё грохнувшееся, что HA. Я понял это так, но не уверен.

если использовать self hosted engine то да. без него - управлялка на отдельном хосте или кластере

dyasny ★★★★★
()

На всякий случай напомню, что oVirt рассчитан на RHEL/CentOS, и с гипервизорами на других ОСях работать не будет

По крайней мере ещё год назад KVM на Debian он не мог установить агентов

router ★★★★★
()
Ответ на: комментарий от router

знаю две небольших конторы которые пользуются генту. но вообще, RHEL/CentOS - самая подходящая платформа для kvm как такового.

dyasny ★★★★★
()

Я возился с oVirt, советую серьезно подумать над целесообразностью его внедрения. Это довольно сложная и большая махина, которая для датацентров больше подходит, или кластеров, т.к. только для ее построения рекомендуется использовать минимум 3 разные физические машины (год назад было так) . По этому, если у тебя меньше 10-20 виртуалок, то обычного kvm + virtmanager должно быть достаточно.

abdus
()
Ответ на: комментарий от abdus

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

arsik
()
Ответ на: комментарий от abdus

только для ее построения рекомендуется использовать минимум 3 разные физические машины

http://www.ovirt.org/Features/Self_Hosted_Engine

обычного kvm + virtmanager должно быть достаточно

в принципе их достаточно, и даже миграцию можно настроить, но при масштабировании это кошмар. со стореджем тоже все неоднозначно, надо или поднимать кластер или использовать NFS, что опять же плохо масштабируется, и требует дополнительных шагов в конфигурации и поддержке. ovirt берет все на себя, и очень сильно упрощает жизнь админу

dyasny ★★★★★
()
Ответ на: комментарий от arsik

я вышел из положения так. Т.к. у меня без GUI сервер с kvm, то я сделал 1 виртуалку с убунтой, и под виндой использую XWin32 чтоб по ssh запускать GUI virtmanager с этой убунты.

abdus
()
23 февраля 2015 г.
Ответ на: комментарий от router

На всякий случай напомню, что oVirt рассчитан на RHEL/CentOS, и с гипервизорами на других ОСях работать не будет По крайней мере ещё год назад KVM на Debian он не мог

Какая-то не правда... С 2013 года oVirt стоит на Fedora...

k0ste
()
Ответ на: комментарий от k0ste

Какая-то не правда... С 2013 года oVirt стоит на Fedora...

Ну как бы Fedora всегда была тестовым полигоном для RHEL, это логично

router ★★★★★
()
15 апреля 2015 г.
Ответ на: комментарий от dvrts

самый распространенный механизм STONITH. команда reset отправленная на девайс контролирующий питание сервера, обычно управляемый PDB или встроенный IPMI/BMC типа DRAC/iLO/IMM

dyasny ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.