LINUX.ORG.RU

ovirt localstorage zfs

 , ,


1

4

Привет всем! Столкнулся вот с каким моментом, имеем:

ovirt node, и хотим покрутить там вирт. машинки с 1С и офтопиком. В настоящий момент пробовал решения: lvm+mdadm+ssd cache, zfs.

Самый лучший результат (в два раза лучше), даёт схема: zvol (LARC,ZIL on ssd), compression=on, + ext4 поверх всего этого бутерброда.

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

Костыли в виде расшарить zfs по iscsi - не интересны.

И так, как лучше всего организовать сей бутерброд?

Сейчас проблема основная вот в чём:

[root@ovirt-beet ~]# df -h|grep loca
/dev/zd0                                    300G         155G  146G           52% /mnt/local_storage
[root@ovirt-beet ~]# zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
kvmpool         309G   140G    96K  /kvmpool
kvmpool/zvol1   309G   415G  34,7G  -

То есть, штука такая: на zfs, у меня занято всего 34.7G, тогда как ext4, показывает уже 155G. Что будет, когда ext4 заполнится? А в реале, место ещё будет..?

Как бы более красивее разрулить сей бутерброд? Может есть что-нибудь более эффективное и побыстрее, в этом плане?

★★★★★

На чём 1С? Постгрес? Размеры блоков zfs подкручены на 8к?

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

MSSQL. Какие выбрать размеры блоков в zfs - не знаю... Слишком толстый бутерброд выходит конечно... :( Сейчас блок в zvol 128к. Какой нужен - не имею понятия.

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

Меня всё же больше волнует вопрос: что будет делать ext4, когда у неё закончится место, а при этом на zvol, из-за сжатия - будет его ещё половина свободных? Сейчас монтирую ext4, с опцией discard, но это немного в другую степь...

DALDON ★★★★★ ()

-=:=-

Вообще интересный вопрос.
ПО факту, ext4 ничего не узнает о том, сколько она реально места жрёт на пуле. Для ext4 - она фул. А вот можно ли тогда создать еще один zvol (если пред. zvol как бы уже создан на фул сайз, хоть и занимает меньше места? по идее нет? или да?)
Возможно есть смысл дропнуть ext4 и юзать нативно zfs?
хм, чтото мысля кудато убежала..

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

-=:=-

discard?
нет смысла.
Если ext4 впиливают на блочное, типа ssd - то по идее она узнает, что есть trim.
А вот ext4 на zvol - не скажет что есть трим,ведь zvol для ext4 - простая блочка и все, аки hdd. триму взяться неоткуда. Zpool (zfs) через zvol ничего не скажет ext4 про трим.

KosmiK ()
Последнее исправление: KosmiK (всего исправлений: 1)

-=:=-

Ах да.
Если виртуалки крутятся с режимом сохранения изменений - то представь, какой будет со временем ад фрагментации. Если внутри виртуалки не будет чего-нибудь софтового, что будет затирать свободное пространство нулями (O&O dtfrag, Dummy file creator), и сам менеджер виртуалки не будет компрессить нули (как вмТварь сжимает образа) то любые изменения будут откладываться вплоть до диска, через весь бутерброд: virt.ntfs->hdd.image.виртуалки->ext4->zvol (да еще и с компрессией)->zpool->диск.

KosmiK ()
Последнее исправление: KosmiK (всего исправлений: 1)
Ответ на: -=:=- от KosmiK

Возможно есть смысл дропнуть ext4 и юзать нативно zfs?

ovirt, не может юзать нативно zfs для local_storage, т.к. оно хочет, похоже O_DIRECT, и сваливается при инициализации хранилища (я не говорю уже о запуске VM).

DALDON ★★★★★ ()
Ответ на: -=:=- от KosmiK

А в гугле говорят, что без discard, место в zvol будет расти и расти, и будет весёлая ситуация, когда на ext4, будет полно места, а zvol скажет - мне больше некуда писать... - Как-то так...

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

-=:=-

И это верно. Но дискард нужен для ssd, дабы триммить спейс, что высвободился после удаления файла. Где у zvol устройства трим, чтобы ext4 мог применять discard?
Ты пытался монтировать с дискардом? что dmesq сказал? прокатило? Помойму не прокатит.
А так да.

KosmiK ()
Ответ на: -=:=- от KosmiK

Что сказал dmesg - не смотрел. Но смонтировалось вполне успешно! Вот результат с discard, чуть позже повторю без него:

[root@ovirt-beet ~]# df -h
/dev/zd0                                    300G         155G  146G           52% /mnt/local_storage



[root@ovirt-beet ~]# zpool list
NAME      SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
kvmpool   464G  35,1G   429G         -     3%     7%  1.00x  ONLINE  -


[root@ovirt-beet ~]# cat /dev/urandom > /mnt/local_storage/test
^C

[root@ovirt-beet ~]# du -sh /mnt/local_storage/test
6,0G    /mnt/local_storage/test


[root@ovirt-beet ~]# df -h
/dev/zd0                                    300G         161G  140G           54% /mnt/local_storage


[root@ovirt-beet ~]# zpool list
NAME      SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
kvmpool   464G  41,0G   423G         -     4%     8%  1.00x  ONLINE  -


[root@ovirt-beet ~]# rm /mnt/local_storage/test
rm: удалить обычный файл «/mnt/local_storage/test»? y


[root@ovirt-beet ~]# df -h
/dev/zd0                                    300G         155G  146G           52% /mnt/local_storage


[root@ovirt-beet ~]# zpool list
NAME      SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
kvmpool   464G  35,1G   429G         -     3%     7%  1.00x  ONLINE  -

Вроде очистилось... Надо попробовать без discard...

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

-=:=-

Воу. Это хорошая ньюса. Тоесть по крайней мере в случае удаления образа с ext4 - discard проходит полностью. НО это не отменяет тот факт, что ext4 никогда не узнает что она в сжимаемом контейнере.
Мда.

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

-=:=-

А если не юзать zvol?
Если создавать ext4.loop образа нужного размера внутри обычного zfs-пула с сжатием? Ведь пул их сожмет - значит реально можно будет создавать больше лупов для ext4?

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

Сейчас блок в zvol 128к. Какой нужен

АФАИК, БД в основном обмениваются с диском страницами в 4кб. Некоторые больше, некоторые настраиваются. Почти во всех гайдах для БД «Set ZFS recordsize=8K».

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

Есть нюанс, в zfsonlinux zvol с volblocksize=8k есть проблемы с производительностью, рекомендуют бОльшие значения блока.

King_Carlo ★★★★★ ()
Ответ на: -=:=- от KosmiK

Костыльно как-то... От слова, совсем)

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

Блин, пока одного не могу понять, тест гилёва 1С, показывает в два-три раза больше попугаев на zfs, нежели на lvm... Как такое возможно - не понимаю... Можешь подробнее объяснить, суть блоков в zvol? Это блоки блочного ус-ва просто? На что и как это может влиять? Ну и вообще буду очень рад, если что-то расскажешь, про: zvol + ext4. - В гугле - тишина.

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

не могу понять, тест гилёва 1С, показывает в два-три раза больше попугаев на zfs, нежели на lvm... Как такое возможно - не понимаю...

Агрессивное кэширование arc, l2arc и zil на ssd, конечно zfs будет быстрее lvm, удивительно если было бы иначе.

Можешь подробнее объяснить, суть блоков в zvol?

zvol volblocksize это тоже самое, что и recordsize, который, по умолчанию, равен pagesize. Pagesize (default volblocksize) зависит от конкретной архитектуры и на солярисе = 8к, такое же дефолтное значение перекочевало и на x86 и оно там как то не очень. Если мне надо развернуть виндовые виртуалки на zvol, использую volblocksize=32k.

про: zvol + ext4

Твою схему zfs->zvol->ext4->«файлы образы» никогда не использовал, очень костыльно выглядит. ext4 на zvol видел только когда виртуалка (linux) лежит непосредственно на zvol, но в таком случае никаких сюрпризов. В твоём случае, место на ext4 кончится раньше, чем на zpool.

King_Carlo ★★★★★ ()
Последнее исправление: King_Carlo (всего исправлений: 1)

И так, как лучше всего организовать сей бутерброд?

qemu/kvm + lvm. Больше никаких абстракций не надо.

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

Ребята King_Carlo, KosmiK, я не фанат zfs, но, чтобы не было скучно, посмотрите на картинки: https://dl.dropboxusercontent.com/u/20100592/document.pdf - ВЕЗДЕ, где написано mdadm - там имеется ввиду: mdadm raid, lvm, ext4 - это на тестовом железе, перед покупкой серверов. Ребята, за такую производительность (mdadm raid, lvm, ext4), мне работодатель побреет ноги! Кстати, сейчас у меня 1С крутится на zfs, без ZIL, я и то имею 16 попугаев! Против 10 на lvm+ext4

И так, какие у меня мысли:

чтобы быть объективным, и принимая во внимание вот это:

Агрессивное кэширование arc, l2arc и zil на ssd, конечно zfs будет быстрее lvm, удивительно если было бы иначе.

Хотя там у меня попадание на тесте Гилёва в l2arc, было минимальным, ZIL заруливает просто, предполагаю... В общем, пока рассматриваю связку такую:

Боевые сервера: hardware raid + NV cache на нём. Далее: lvm + lvmcache on ssd + ext4. Но данный вариант, за неимением боевого железа (ещё не покупали пока), не представляется возможность протестировать.

Тестовые сервера: mdadm/hardware raid + lvm + lvmcache on ssd + ext4 (external journal on SSD).

Вот хочу сделать Гилёва, на второй связке (благо железо имеется). Я думаю, действительно, zfs выигрывает во многом за счёт: ZIL на SSD! Почему бы не попробовать ext4, с аналогичной фичей?

Твою схему zfs->zvol->ext4->«файлы образы» никогда не использовал, очень костыльно выглядит. ext4 на zvol видел только когда виртуалка (linux) лежит непосредственно на zvol, но в таком случае никаких сюрпризов. В твоём случае, место на ext4 кончится раньше, чем на zpool.

Понимаю... Но уж очень дорогие сейчас диски для серверов, по сему очень хотелось получить сжатие. Но, это или мне придётся отказываться от ovirt, и тыкать в proxmox (чего я не хотел бы делать...). Или отказываться от zfs, или городить костыли. В общем, пока наилучшим вариантом, выглядит отказ от zfs, и вытягивание производительности на ext4. Ну или использовать zfs, без сжатия, но всё равно: zfs->zvol->ext4->«файлы образы» - схема не радует...

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

Моё мнение такое - ovirt на proxmox не менять, перейти на mdadm/hardware raid + lvm + lvmcache on ssd + ext4 (external journal on SSD).

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

Угу. Рад читать твоё мнение (хорошо, что ты адекватный пользователь zfs, а не ярый фанат).

С ovirt, ещё один, очень, очень, очень не приятный момент вылазит сейчас. Который возможно поставит всё же крест на нём (хотя очень не хочется). - А именно, как тут не крути, а ovirt точат под shared storage, а вот в локальном storage, похоже что backup работающей вирт. машины, можно делать только через: создание снепшота от неё, полный её клон в новую VM из этого снепшота. Удаление снепшота, и снятие backup с клонированной VM. - То, есть по мимо того, что мне надо на local_storage иметь места под целую продуктивную VM, мне ещё надо будет пережить кучу i/o, пока будет клонироваться VM, а потом ещё и ждать пока с клонированной VM, будет сливаться backup. Но потом, мне ещё придётся переживать i/o по удалению клонированной машины... - Если это так, то, стоит очень, очень крепко задуматься об ovirt.

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

Мысль возникла, сам так не делал, но вдруг прокатит. Изобразить отдельный сетевой сторадж на локалхосте. Делаем так: оставляем zfs, нарезаем zvol-ы для виртуалок и отдаём их по iscsi ovirt-у на localhost. Соответственно снапшотами/бэкапами сможешь управлять скриптами вне ovirt.

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

Да такая мысль у меня имеется давно, но я не вижу никакого смысла добавлять слой TCP/IP, и более того, если мне придётся снепшотами управлять из вне, тогда смысла от ovirt становится не много. Можно отдать один zvol как iscsi. Тогда ovirt будет сам рулить снепшотами. Но проблема backup остаётся. Видишь ли в чём дело... Дело в том, что: мне надо делать backup машинок не ради того чтобы у меня был backup, а мне нужен backup ради того, чтобы его поднять в песочнице, и не просто проверить его работоспособность, но и (например), проверить, процедуру обновления ПО в виртуалке или чего-либо подобное. - Если делать backup ниже уровня ovirt, я потом такой backup не разверну нигде, кроме как в том же DC ovirt (эта сволочь хранит же всё в центральной базе своей, соот-но там всё по uuid, и на local_storage, лежит по сути мусор, в котором никто кроме ovirt-engine ничего не поймёт), что заставит меня держать два ovirt и т.д. - Короче бред.

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

Может проще тогда без ovirt и proxmox просто использовать kvm через libvirt, всё под контролем.

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

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

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

Такая конфигурация у меня как раз сейчас. Не удобно всё это сопровождать дело... Есть даже web морда. Но вот операции: изменить настройки VM, поправить сеть, сделать снепшот - приходится делать из консоли. Что со временем порождает бардак. Во всём остальном - решение отличное, по гибкости и т.д.! :(

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

Разумеется, нативный backup mssql будет. Мне от backup, по большей части нужен клон. То есть сделал клон, развернул на другом узле. Накатил backup сделанный на уровне СУБД - проверил, что всё работает. Ну как-то так. Прямой экспорт из снепшота, всё ещё не реализован в API ovirt, насколько я понимаю. В том случае если мне для local_storage надо кучу места, и плюс к тому ещё нету возможности использовать zfs - решение выходит очень дорогим (в плане железа).

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

А почему бы не клонировать машины в таком случае?

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

Есть несколько причин:

  • клонирование, подразумевает собственно клонирование, на локальный сторадж. Локальный сторадж - на серверном оборудовании (2,5' SAS 10k), дорогой. Если говорить о fullclone. Не fullclone, я пока не нашёл как делать (не считая возможности использовать шаблон, но это совсем о другом).
  • если делать полное клонирование, то это вызовет гигансткий io
  • есть потребность, на клонированной машине, не изменять никаких настроек. Особенно, это касается сети. Если я буду клонироваться на тот же узел, как минимум MAC, придётся менять.
  • есть потребность иметь полную копию продуктивного окружения (в т.ч. сеть, DNS и т.д.). Для теста обновления ПО или наката из backup.
  • продуктивная машина может быть достаточно «толстой», и в клонированном виде, придётся ей урезать ОЗУ (к примеру), что может вызвать ряд проблем, внутри самой VM.

Вообще, активно потыкав ovirt - нашёл, что это ПО, во-первых заточено под shared storage. Что вообще говоря, правильно и хорошо. Но весьма не дёшего. И ovirt, имеет ряд багов. Сходу наткнулся прям на несколько. Все баги есть в bugtracker. Один из багов фатальный, и приводит к не возможности управлять нодой. То есть, ovirt - не идеален. Факт прям из фактов! Да, я знаю про RHEV, но в виду того, что с zfs есть проблемы, и всё точится под shared storage, я вынужден посмотреть на proxmox (в виду цены shared хранилища).

Да и вообще, можете считать меня рукожопым, но... CentOS мне совсем не нравится. Я тут давича тред создавал, что не мог работать с локальными дисками в ней, так вот, таки выяснил, что надо настраивать multipath - чёрные списки дисков, тогда будет всё ок. - И всё у меня получилось. Так что мои руки тут не при чём! Это by design так... Теперь следующая проблема: у меня после ребута далеко не всегда поднимается сеть... В начале загрузки centos, прям тухнут светодиоды на сетевой карте. Помогает только ifdown, ifup, ifup, reboot. - Только так..! Что тут глючит - не знаю. Железо серверное. Может systemd дурит, или selinux. - В общем, на debian таких проблем не было, ровным счётом - никогда.

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

В общем, всё плохо у ovirt в этом плане (получил развёрнутый ответ от авторов тулзы для backup). Через backup API будет клонироваться на тот же сторадж. И клонирование будет полным. + Ещё нужно место для разрастания снепшота (если во время клонирования будет изменение данных). В общем, ovirt без шаренного хранилища, смысла практически не имеет. В виду цены и не особой эффективности локальных дисков. Всё сообщество в ожидании, когда RedHat, поправит сей момент... Ждут уже я так понимаю, не первый год.

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

zvol на ходу ресайзить можно, ext заполнит доступное пространство и перейдет в ридонли, размер блока у zvol зависит от организации масива

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

Но вот операции: изменить настройки VM, поправить сеть, сделать снепшот - приходится делать из консоли. Что со временем порождает бардак. Во всём остальном - решение отличное

ну а написать простой гуй на пыхе?

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

Спасибо! Весьма полезная информация, буду пробовать.

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

ovirt, как апстрим для rhev, это решение для больших установок. весь фокус разработки именно на этом, а не на мелких фичерах которые в энтерпрайзе не особо нужны. Так что дело все в приоритетах, ресурсы разработчиков ограничены. А приоритет всегда был и будет на серьезных решениях а не на бутербродах для локалхостов.

но все таки если по делу, то не обязательно делать экспорт. Можно по NFS подцепить data domain, и клонировать VM из снепшота туда. с версии 3.5 емнип, можно спокойно импортировать целые домены в новые датацентры.

Или можно вообще сдирать с машины ее domxml и выдергивать диск скриптом на standalone libvirt host.

насчет centos вообще разговор абсурдный, и я в него встревать не буду.

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

Можно по NFS подцепить data domain

Надо посмотреть на предмет этой возможности именно в local_dc.

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

Отлично понимая это, я собственно и рассматриваю различные решения. В том числе всеми не любимый proxmox...

насчет centos вообще разговор абсурдный, и я в него встревать не буду.

Настолько там всё плохо у них в этих centos?

Спасибо! В общем, то по делу тоже есть варианты. Буду смотреть. :)

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

Настолько там всё плохо у них в этих centos?

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

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

Оставлю это здесь: www.linux.org.ru/forum/admin/10147452?cid=10151522

Эх... Даже не подумал бы никогда, что ты такое мог когда-то писать. :)

В общем, по теме: пока у меня ОЧЕНЬ хорошие результаты с proxmox + zfs. Производительность, ЧУДОВИЩНО РАДУЕТ: (zfs + zvol + lz4 + zil + larc2 + ARC по-умолчанию). Удобство, безглючность proxmox - так же радует! С тем же ovirt, я прям с первых минут нападал на баги. В proxmox (даже в версии community) - пока не встретил ни одного бага.

Из больших недостатков proxmox: при backup машины, оно не сохраняет снепшоты. В остальном: всё ПОКА ровно.

В общем, пока, планируем к покупке proxmox enterprise версию + zfs в продакшн.

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