LVM vs ZFS vs BTRFS

но весьма огорчает скорость записи 20мб/сек при активном снапшоте

надо исп. lvm thin-provisoning и скорость будет 200

Спасибо, ознакомлюсь, почему то думал, что это просто «растущий», по мере необходимости, lv.

В pve 5 на ZFS сделали инкрементальную репликацию между нодами.

Размазывать сторайдж по нодам(ceph/drbd/etc) вообще не фонтан

Окей, как ты предлагаешь делать live migration без shared storage? Или он тебе нинужен? Тогда вопросов нет

А что на счёт шифрования на zfs?

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

Опробовал lvm thin provisioning, падения, если они и есть, то не критические - 5-10%, но не факт, потому как подробно тестировать не было времени. Теперь осталось найти способ синхронизации всего этого добра на двух серверах. Может есть у кого идеи? Буду благодарен за направление, в котором нужно копать.

Недавно была новость что в zfsonlinux добавили поддержку шифрования.

а оно уже имеет статус production ready?

новость то я видел, но разворачивать это на боевых серверах не охота. Еще, как вариант, можно попробовать запилить zfs поверх luks, на device mapper.

Кстати, вот такой вопрос: а что собственно даёт эта он-лайн миграция? Какое приложение её реально выдержит? 1С/MSSQL/ORACLE/SAP? Или это больше для всяких LAMP?

Proxmox умеет живую миграцию с одновременным переносом диска, если он не шареный. Тот же принцип что и в libvirt.

ЕМИНП, нет. Только в планах такое.

Умеет умеет. Но только из консоли (смотри qm help migrate). К сожалению, не умеет мигрировать в storage с другим именем (опция для нового имени стораджа добавлена, но фейлится при попытке). Мы использовали много раз такую миграцию. И 1С-ки мигрировали (и с шареным и не шареным хранилищем) и СУБД и терминальные сервера. Ну пропадет пара пакетов. В TCP сессии незаметно.

Умеет, но не в миграции дело.

Если в primary сервер угодил метеорит, VM то перелезут на slave согласно HA groups, но на не актуальные образы, соответственно нужна синхронизация этих самых образов, хотя бы каждые 3-4 часа, но если брать во внимание, что сетка гигабитная и образы весят >200GB, то полный перезалив образов каждых 3 часа не самая лучшая идея. Общего хранилища нету и не будет. Соответственно как вариант сделать следующее:

на primary сервере стопнуть все vm

1 раз полностью скопировать разделы /dev/pve-vg/vm-thin-pool/$VM_ID на второй сервер

сразу же сделать снапшоты /dev/pve-vg/vm-thin-pool/$VM_ID на первом сервере

запустить все ВМ Каждые три часа делать снапшоты всех ВМ на первом сервере и мержить его в LV на втором сервере.

но вот тут меня одолевают сомнения, если на обычном LV это делается просто с помощью lvmsync, то как это делать с дополнительным уровнем абстракции в виде thin-{pool,lv} я не знаю, или не имеет значения?

В 1С, скорее вопрос о привязке лицензии к железу. - Наверняка спалит смену хоста.

В общем, мне интересно именно поведение лицензий.

Proxmox умеет живую миграцию с одновременным переносом диска, если он не шареный. Тот же принцип что и в libvirt.

И сколько перенос не-thin-provisioned тома гигов на 300 займет? :-)

Потеря одного-двух пакетов при миграции... Наверное почти любое TCP-приложение выдержит

Вопрос в смене окружения... К примеру, та же 1С при смене CPUID, потеряет лицензию, если она программная...

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

Ну 300 гигов минут за 45 перельется. При условии выделенной сети на эти нужды. Для HA это не годится, зато годится для вывода сервера на плановое обслуживание без остановки виртуалок. Здесь можно и зажать скорость и неспеша все перетащить.
По теме топикстартера, о шифровании. Можно же ZFS поверх LUKS раскатать, какой бы там ни была стадия встроенной поддержки шифрования в zfsol, если вдруг ZFS ну очень хочется ради какой-то ее собственной фичи.

https://pve.proxmox.com/wiki/Storage_Replication ничего другого в вашем случае не могу предложить

если вдруг ZFS ну очень хочется

так в том то и дело, что не хочется, буду пробовать схему с синхронизацией thin-снапшотов.

Опробовал lvm thin provisioning...осталось найти способ синхронизации всего этого добра на двух серверах

Тот же lvmsync

https://github.com/mpalmer/lvmsync/issues/45

Можно же ZFS поверх LUKS раскатать, какой бы там ни была стадия встроенной поддержки шифрования в zfsol, если вдруг ZFS ну очень хочется ради какой-то ее собственной фичи.

Не стоит. ZFS для нормальной работы хочет как минимум прямой доступ к диску (безо всяких RAID контроллеров, не говоря уже о том что ZFS будет работать поверх LUKS шифрования и тп) и ЕСС память (желательно побольше).

Так что в вашем случае LVM-thin самый верный способ. С ним никаких особо проблем, кроме как следить за тем чтобы место не закончилось. Либо шифрование ФС внутри каждого гостя средствами этого самого гостя - тогда можно ZFS на хосте.

В 5 версии прокса работает live migration через обычный local storage

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

В общем, пока большого бизнес кейса в online миграции не вижу. Разве LAMP.

ZFS не хочет ECC памяти больше чем её хотят все остальные FS. Остальные просто об этом не заявляют...

Так что в вашем случае LVM-thin самый верный способ. С ним никаких особо проблем, кроме как следить за тем чтобы место не закончилось.

Слыхивал, что там может заканчиваться не только основное место, но и место для метаданных. - Вроде на ЛОРе не давно пробегало как раз... И разве LVM-thin, при первом снепшоте не просаживает производительность? Они вроде говорили, что первый снепшот ведёт себя как классический, зато остальные уже не понижают производительность. - Могу ошибаться. Поправьте если не прав.

Пробовал снапшотить на thin'e - все гуд с производительностью. Место под метаданные можно вынести в отдельный lv или же расширить при необходимости при помощи lvresize.

Для одной совковой программули пробрасываю hasp по сети, для онтопика есть бесплатный проприетарный софт. С 1С не пробовал, но рассказывают, что тоже работает.

Норм схема, но я бы сделал почаще. Переливать 3 ГБайт раз в три часа или 100 МБайт раз в пять минут - особой экономии нет.

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

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

Заделишься названием?

Посмотреть не могу, но вроде вот эта:

http://www.incentivespro.com/downloads.html

Я нисколько не сомневаюсь в том что live migration в такой конфигурации возможна(сам такое делал на OpenNebula), просто скорость обычно печальная, ибо надо передавать дохреналион данных на другую ноду.

пока большого бизнес кейса в online миграции не вижу. Разве LAMP.

Ну хз, у меня для access-серверов(хотел по привычке написать VPN-серверов, ибо только-только недавно прикопал в массе PPTP в качестве опции доступа, теперь там в основном IPoE) пользователей используется live migration. Ибо, как я уже сказал, даунтайм в единицы секунд(обычно 1-2, больше только если что-то пошло не так и надо «вертать всё взад»). А обслуживать ноду с гипервайзором(профилактика, обновления и т.д.) гораздо удобнее.

виртуалки будут размазаны по двум нодам 50/50

Одно из ключевых слов - «ДВУМ»
Нафига ради 2х нод кластер городить?
сам страдал такой же ерундой - никакой пользы окромя обоих нод в одном окне вебморды я не получил...
Предположительно-спорная польза - лайв мигнрация...
но опять - у ТС указана скорость сети - ОДИН гигабит...
В моем случае мне помогла сборка отдельного стореджа, в котором луны подключал через ФС...
но и тут у меня была оппа, связанная с 4гигабитным интерфейсом..
проще купить 4 8гиговых кулоджика (не такие они сейчас и дорогие) - 2 в хранилку, и по одной в ноду; и запилить хранилку на scst или на бсд (тут уже - что вам по аппетиту).. тут вам и бекапы, и разделенные хранилища и вообще все плюшки, какие захотите..
Кстати, на хранилке от зфс отказался - но это потому, что у меня контроллер жирный и прямая публикация лун оказалась эффективней, чем через зфс, а если у Вас диски в хранилке будут напрямую включены, то тогда для зфс надо памяти дофига...

Нафига ради 2х нод кластер городить?

Раз уж аналогия с метеоритом не внушает доверия, приведу другую:

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

у ТС указана скорость сети - ОДИН гигабит...

именно ПОЭТОМУ и не хочу iscsi/san/nas/нефтегаз.

проще купить

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

А теперь по теме.

Обкатываю пока что lvm thin provisioning, и вот с чем столкнулся, оказывается, любимый qemu не поддерживает миграции между нодами, если ему скормить thinpool как thinpool, хрен знает почему...

Выход из ситуации:

Скармливаем через веб-гуй простой lvm, делаем бекап VM, в VM добавляем второй диск с указанием того самого lvm, удаляем первый, восстанавливаем VM из бекапа во второй диск, конвертируем обычный lv второго диска в thin с помощью lvconvert, запускаем VM, и можно делать живую миграцию туда-сюда.

так никто и не говорил, что нужна только одна нода :)
рухнула одна из 2х нод, так подменили таргеты с хранилки на второй ноде и поехали дальше :) я для себя сделал.. Хотя надо будет еще скриптец наваять, чтобы автоматом это делал :)
Ну а раз нод у вас 2 и виртуалки размазаны по ним, то их как минимум 4 :) И каждая минимум по 200 гигов... Включаем калькулятор...
копироваться они будут по гигабитной сети сначала 2 в одну сторону полтора часа, потом 2 в другую сторону полтора часа...
при этом, наверное, Вам не надо объяснять что творится с каналом (это раз) и с ИО (это два) и как это все влияет на состояние работающих виртуалок...
кстати, почему-то, я думаю, у Вас не получится копировать работающую машину.
к чему это я - без хранилки с вменяемой скоростью доступа кроме тормозов и головняка не выйдет ничего путного.
простите за сарказм - но я все это пережил один в один за последние пол года...
уговорите клиента хоть на кулоджики 4х гигабитные.. (в кыйиви ценник на них баксов по 10-15 за штуку)

В этом случае хранилка будет единой точкой отказа, возвращаемся к метеоритам. Виртуалок 6, и общий их объем 200GB, а не 200гб каждая и, если вы читали несколько постов выше, то предполагается, что синхронизироваться будут только изменения в снапшотах, а это ~20гб в сутки. Как по мне не плохой вариант, с теплыми бекапами и живой миграцией, без всяких мутантов ака san'ы/nas'ы.

кстати, почему-то, я думаю, у Вас не получится копировать работающую машину.

Но ведь получается)

В этом случае хранилка будет единой точкой отказа,

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

без всяких мутантов ака san'ы/nas'ы.

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

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

Ответь мне, милый онанизмус, а сколько стоит схд, которая поддерживает шифрование и удаленное управление?

250 тыщ руб без дисков :)

Меня за предъявление такой суммы сожгут на костре и скормят вурдалакам)

Кстати, шифрование можно делать посредством числодробилок. Благо камушки с xeon 56xx серии это отлично умеют делать.

Главное - быстрое подключение к массиву...

Но, по-моему, я повторяюсь :(

Моя хранилка стала где-то в 2200$, вместе с контроллерами, оптической инфраструктурой и дисками.

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

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

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