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

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

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

-=:=-

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

-=:=-

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

-=:=-

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

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

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

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

-=:=-

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

Что сказал 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...

-=:=-

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

-=:=-

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

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

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

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

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

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

не могу понять, тест гилёва 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.

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

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

Ребята 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->«файлы образы» - схема не радует...

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

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

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

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

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

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

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

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

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

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

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

• клонирование, подразумевает собственно клонирование, на локальный сторадж. Локальный сторадж - на серверном оборудовании (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 таких проблем не было, ровным счётом - никогда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оставлю это здесь: Виртуализация для лохов (комментарий)

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

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

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

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

Ну если радует KVM , присмотрись вот к этому http://www.nutanix.com/products/community-edition/