Аспро: ЛайтШоп [тема: zeroizable LVM блоки на общем хранилище]

zeroizable LVM блоки на общем хранилище

Sat, 15 Jul 2017 00:14:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Пожалуйста, откройте новую тему. LVM thin невозможно использовать на совместном хранилище, о чем и идет речь в этой теме.
15.07.2017 00:14:00, LnxBil.

zeroizable LVM блоки на общем хранилище

Tue, 11 Jul 2017 04:52:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
/ect/lvm/lvm.conf, похоже, указывает на то, что 'thin_pool_zero' включен по умолчанию. Запуск 'lvs' показывает атрибут 'z' для логических томов с тонкой подачей, но, например, 'cat /sys/block/dm-34/queue/discard_zeroes_data' указывает на то, что ядро не учитывает это или не знает об этом. Я не могу найти никаких сообщений по этому поводу. Это задумано (возможно, из-за того, что LVM-thin не обнуляет данные атомарно) или еще не написан необходимый код ядра? Мы используем следующий относительно простой bash-скрипт для обновления блочных устройств (дисков VM) на серверах в резервном центре. Скрипт в основном считывает и сравнивает 1КБ хэши MD5 и затем либо пропускает следующий блок, либо передает этот блок. Работает очень хорошо как со снимками на исходе (консистентный исходный образ), так и на месте назначения (последний снимок является консистентным образом, пока оригинал патчится). Мы надеялись найти способ заставить LVM-thin игнорировать блоки нулей, чтобы сэкономить место на DR-сайте, хотя, похоже, такого пока нет. Гостевые системы используют параметры монтирования discard или запускают дефрагментацию диска с TRIM (Windows) на сервере-источнике, но наша схема репликации в результате записывает нули в пункт назначения, если этот блок ранее содержал данные, поэтому образы назначения медленно растут со временем. Было бы идеально, если бы LVM-thin мог обнаруживать участки, содержащие только нули, и автоматически освобождать их, или если бы мы могли периодически обрабатывать блочные устройства для достижения этого. В настоящее время мы периодически запускаем VM в среде DR и вручную выполняем fstrim или дефрагментацию диска, но хотели бы, чтобы это было автоматизировано. P.S.: Чтение нулей из невыделенного пространства с LVM-thin также происходит очень быстро, так как на самом деле не нужно считывать никаких данных. Вот скрипт, который мы запускаем каждую ночь на системе Proxmox в удаленном офисе, надеюсь, он будет полезен кому-то (использует 'lzop' для сжатия хэшей и данных в пути): P.S.: Скрипт ниже взят из другого устаревшего хоста, который все еще использует стандартный LVM (без тонких томов). Изменить его несложно, так как требуется лишь небольшая настройка команды lvcreate. Код: #!/bin/sh

network_kvm_backup () {
src_vg=$1;
src_lvm=$2;
snapsize=$3;
dst_host=$4;
dst_vg=$5;
export dev1="/dev/$src_vg/$src_lvm-snap1";
export dev2="/dev/$dst_vg/$src_lvm-backup";
export remote="root@$dst_host";

logger "Начинаем обновлять $dev1 на $dst_host как $dev2";
[ "$src_vg" = "vg_kvm" ] && stripes=2 || stripes=1;
lvcreate -i $stripes -L $snapsize /dev/$src_vg/$src_lvm -s -n $dev1 > /dev/null;
ssh -i /root/.ssh/rsync_rsa $remote "
perl -'MDigest::MD5 md5' -ne 'BEGIN{\$/=\1024};print md5(\$_)' $dev2 | lzop -c" |
lzop -dc | perl -'MDigest::MD5 md5' -ne 'BEGIN{$/=\1024};$b=md5($_);
read STDIN,$a,16;if ($a eq $b) {print "s"} else {print "c" . $_}' $dev1 | lzop -c |
ssh -i /root/.ssh/rsync_rsa $remote "lzop -dc |
perl -ne 'BEGIN{\$/=\1} if (\$_ eq\"s\") {\$s++} else {if (\$s) {
seek STDOUT,\$s*1024,1; \$s=0}; read ARGV,\$buf,1024; print \$buf}' 1<> $dev2"
logger "Завершили обновление $dev1 на $dst_host как $dev2";
lvremove -f $dev1 > /dev/null;
}

# src_vg src_lvm snapsize dst_host dst_vg
network_kvm_backup vg_kvm lair-nt01 50G dr2.lair.co.za lvm0
network_kvm_backup vg_kvm lair-eppdns 5G dr2.lair.co.za lvm0
network_kvm_backup vg_kvm lair-webapp 5G dr3.lair.co.za lvm0
11.07.2017 04:52:00, David Herselman.

zeroizable LVM блоки на общем хранилище

Wed, 16 Mar 2016 11:02:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Спасибо за разъяснение. Теперь я лучше понимаю. С наилучшими пожеланиями.
16.03.2016 11:02:00, marco44.

zeroizable LVM блоки на общем хранилище

Mon, 14 Mar 2016 09:11:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
lvm-thin в исходном коде ядра помечает устройство как не возвращающее нули для освобожденных блоков. На практике это будет зависеть от размера освобожденного пространства. Если вы освободите достаточно большую часть, чтобы LVM мог его деаллоцировать, последующие чтения действительно будут возвращать нули, но это не гарантируется на уровне блоков, так что `detect-zeroes=unmap` не будет использовать освобождение тут. Обычно `detect-zeroes=unmap` заставляет qemu запрашивать у ядра, сообщает ли базовое хранилище, что выполнение освобождения приводит к возвращению нулей при последующих чтениях из этого места. Так что обычно он вернется к использованию запроса BLKZEROOUT, затем все будет зависеть от того, что еще знает хост-ядро о базовом хранилище: это снова может быть освобождение (но в этот момент это маловероятно, иначе qemu уже использовал бы это), одно запись блока с нулями, за которой следуют запросы "write-same" (наверное, в этот момент это наиболее вероятно), или если первое не обнуляет, а второе не поддерживается, это закончится фактическими записями нулей. Последние два запроса не будут выдавать освобождения вообще.
14.03.2016 09:11:00, wbumiller.

zeroizable LVM блоки на общем хранилище

Fri, 11 Mar 2016 18:09:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я заявил, что файловая система может сама выполнять деэмпинг. Если KVM делает это через trim, конечно, это быстрее, но KVM для этого не нужен. Если вы записываете большой файл, например, не сжатый диск виртуальной машины, который содержит много нулей, файл записывается в ZFS, но он автоматически деэмпится, что приводит к очень компактному образу диска виртуальной машины.
11.03.2016 18:09:00, LnxBil.

zeroizable LVM блоки на общем хранилище

Fri, 11 Mar 2016 11:44:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я думал, что если в параметрах KVM установлено detect-zeroes=unmap, то он будет отправлять операции удаления, когда обнаруживаются нули. Это было бы достаточно для LVM-Thin, чтобы справиться с удалениями... так это работает, когда система виртуальной машины действительно выполняет операции удаления.
11.03.2016 11:44:00, marco44.

zeroizable LVM блоки на общем хранилище

Fri, 11 Mar 2016 11:12:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Нет, если вы записываете нули в ZFS, ZFS это обнаруживает и автоматически разъединяет. Это вообще не связано с trim/discard. Не знаю, делает ли thin-LVM что-то похожее. ZFS обычно использует размер записи/блока 128K, вы можете установить его на 8K, чтобы он соответствовал вашему гостю (если правильно выровнен), и тогда получите 1:1 отображение блоков — то есть каждый освобожденный блок может быть разъединен ZFS, если у него теперь количество ссылок равно 0. LVM внутренне использует extend, и не знаю, могут ли тонко выделенные объемы также быть настроены с маленьким размером extend. Вы должны это проверить в документации thin-LVM или попробовать на тонко выделенном тестовом объеме.
11.03.2016 11:12:00, LnxBil.

zeroizable LVM блоки на общем хранилище

Fri, 11 Mar 2016 10:24:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Если это так, то значит, что KVM отправляет отбрасывания в ZFS, когда обнаруживает нули, но не в LVM-Thin. Это было бы странно, не правда ли? Или ZFS сам обнаруживает эти нули?
11.03.2016 10:24:00, marco44.

zeroizable LVM блоки на общем хранилище

Thu, 10 Mar 2016 20:03:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я никогда не использовал тонкое предоставление LVM, но я могу записывать нули в ZFS, и ZFS позаботится о размечивании. Возможно, есть что-то похожее для тонко предоставленных LVM. Возможно, когда расширения LVM свободны, их можно вернуть.
10.03.2016 20:03:00, LnxBil.

zeroizable LVM блоки на общем хранилище

Thu, 10 Mar 2016 18:01:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Привет, извиняюсь, что влезаю в этот разговор, но мне кажется, что мой вопрос примерно о том же: я пытаюсь воспользоваться функцией обнаружения нулевых блоков на LVM-Thin томе, но без успешных результатов. В большинстве виртуальных машин я могу выполнить команды на освобождение места внутри ВМ (это работает). Но у меня есть одна виртуальная машина с Windows и одна очень старая Debian (Debian 3, да, я в курсе, но у меня нет выбора) которые не могут выполнять команды на освобождение. Запуск fstrim в виртуальной машине работает прекрасно, когда эта ВМ может их выполнять… например, с недавним Linux. Место освобождается и возвращается LVM-Thin. Но я не могу вернуть место, записывая нули, и, прочитав эту тему, подумал, что это может сработать. Я что-то упускаю? С уважением.
10.03.2016 18:01:00, marco44.

zeroizable LVM блоки на общем хранилище

Fri, 05 Feb 2016 21:56:00 +0300

zeroizable LVM блоки на общем хранилище Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Привет, я оптимизирую все свои виртуальные машины, заполняя их свободное пространство нулями перед резервным копированием, чтобы файлы резервной копии были как можно меньше. Я делаю это полуручно (скрипт и cronjob), но у меня это не автоматизировано. Я знаю, что можно использовать discard, но только если базовое хранилище это поддерживает. Я использовал это с qcow и даже LVM на SSD, но у меня кластер и SAN на основе FC для моих виртуальных машин. В мануалах KVM сказано следующее: что еще можно сделать? Это не относится к моей проблеме. Я хочу очистить/обнулить блоки на LVM, если файл был аннулирован в виртуальной машине.
05.02.2016 21:56:00, LnxBil.