Пауза виртуальной машины kvm

Я никогда и не говорил ничего плохого о zfs. Но когда мне безотвествено заявляют что только zfs обеспечивает консистентные снапшоты (без влезания в виртуалку) я этому не верю и никто из местных zfs'ников так и не смог ничего толкового по этому поводу сказать, кроме «у меня все работает». У меня тоже после hard reseta' все работает, но это также ничего не значит.

Определи для себя что ты понимаешь под словом «консистентность» по-крайней мере в этой фразе «Как мне удостовериться, что сейчас у меня хостА, и хостБ - имеют консистентные данные?» На этот вопрос тебе ведь не дали ответа.

Ответ мне дали: Пауза виртуальной машины kvm (комментарий)

Именно это, то, что меня волновало. Чтобы я точно знал, что у меня идентичные данные на обоих узлах.

Под консистентностью я понимаю следующее: консистентность данных на уровне zfs. Консистентность данных на уровне снепшотов от вирт. машин - Во втором случае потребуется их выключить, чтобы иметь гарантированно консистентный снепшот.

консистентность zfs хостов будет, я же говорил о консистенции виртуальных файловых систем.

Чудес не бывает, и наиболее разумным выходом мне видится, в таком случае: выключить VM, сделать снепшот (например на уровне qcow2), включить VM.

Чудес не бывает,

О чем и речь.

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

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

Все остальное — (не) разумные компромисы, zfs snapshot/lvm snapshot/qcow2 snapshot/rsync/...

выключить VM, сделать снепшот (например на уровне qcow2), включить VM.

даже в варианте - выключить VM, сделать снепшот, включить VM -zfs даст минимальный простой.

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

Ты не пропадай из темы, я буду тестировать сейчас это добро!

Вот мои шаги:

Ставлю ubuntu: /dev/sda

Ставлю zol

Создаю пул:

zpool create -o compression=on,primarycache=all kvm mirror  /dev/disk/by-uuid/4e3bbd9a-9f4a-4669-8c82-43c5d1fabb5a /dev/disk/by-uuid/c92f7813-96a1-46a1-b562-2d6af5a55f46

У меня появляется точка монтирования: /kvm , куда я складываю образы VM.

На другом хосте делаю всё аналогично.

В первый раз на первом хосте:

zfs snapshot kvm@snap1
zfs send kvm@snap1 | ssh host2 zfs recv kvm

Во второй раз:

zfs snapshot kvm@snap2
zfs send -i kvm@snap1 kvm@snap2 | ssh host2 zfs recv kvm
zfs destroy kvm@snap1

Для образов виртуальных машин kvm, включаю опцию: cache=none, чтобы избежать двойного кеширования я ведь использую: primarycache=all?

Насколько резонно, использовать: compression=on в случае образов kvm?

использую сжатие вся прелесть именно в нем, оно выполняется на уровне ФС

Всё остальное я правильно написал? А по-умолчанию какой алгоритм сжатия выбран?

У меня появляется точка монтирования: /kvm , куда я складываю образы VM.

Не надо прямо в /kvm, создай файловую систему, например zfs create /kvm/vm

Ок! По остальному всё ок? Правильно я понял всех вас?

Что по:

Для образов виртуальных машин kvm, включаю опцию: cache=none, чтобы избежать двойного кеширования я ведь использую: primarycache=all?

По остальному всё ок?

Всё ок.

тесты на время создания и восстановления виртуалок на zfs с использованием дисков с помойки, которым хрен знает сколько лет.

сам снапшот:

time zfs snapshot kvmpool/tom/vol-vm7@`date --rfc-3339=date`

real	0m0.100s
user	0m0.000s
sys	0m0.000s

создание бекапа из снапшота:

time zfs send kvmpool/tom/vol-vm7@2014-10-23 > /home/backup.vol-vm7

real	0m34.051s
user	0m0.008s
sys	0m1.204s

размер снапшота, при размере фс в 10ГБ

ls -l /home/backup.vol-vm7
-rw-r--r-- 1 root root 1328905144 Окт 23 16:25 /home/backup.vol-vm7

восстановление виртуалки из снапшота:

time cat /home/backup.vol-vm7 | zfs receive -vdF kvmpool/temp
receiving full stream of kvmpool/tom/vol-vm7@2014-10-23 into kvmpool/temp/tom/vol-vm7@2014-10-23
received 1,24GB stream in 31 seconds (40,9MB/sec)

real	0m31.575s
user	0m0.052s
sys	0m5.620s

характеристики живого трупа:

hdparm -tT --direct /dev/sdb

/dev/sdb:
 Timing O_DIRECT cached reads:   398 MB in  2.00 seconds = 198.87 MB/sec
 Timing O_DIRECT disk reads: 176 MB in  3.02 seconds =  58.31 MB/sec

sdparm -i /dev/sdb
    /dev/sdb: ATA       WDC WD800JD-08MS  10.0
Device identification VPD page:
  Addressed logical unit:
    designator type: vendor specific [0x0],  code set: ASCII
      vendor specific:      WD-WMAM9WY36112
    designator type: T10 vendor identification,  code set: ASCII
      vendor id: ATA     
      vendor specific: WDC WD800JD-08MSA1                           WD-WMAM9WY36112

hdparm -i /dev/sdb 

/dev/sdb:

 Model=WDC WD800JD-08MSA1, FwRev=10.01E01, SerialNo=WD-WMAM9WY36112
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=65
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156312576
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

Что-то оно жууутко медленно работает.

Делал так:

zpool create -O compression=on -f kvm mirror /dev/disk/by-id/ata-WDC_WD4000F9YZ-09N20L0_WD-WCC131162936 /dev/disk/by-id/ata-WDC_WD4000F9YZ-09N20L0_WD-WMC1F1986858
zfs create kvm/images

Скорость отдельного диска:

root@kvm1-slave:~# hdparm -tT /dev/sdc

/dev/sdc:
 Timing cached reads:   27570 MB in  1.99 seconds = 13863.37 MB/sec
 Timing buffered disk reads: 524 MB in  3.00 seconds = 174.49 MB/sec
root@kvm1-slave:~# hdparm -tT /dev/sdd

/dev/sdd:
 Timing cached reads:   27414 MB in  1.99 seconds = 13786.57 MB/sec
 Timing buffered disk reads: 482 MB in  3.01 seconds = 160.11 MB/sec

Скорость записи в пул:

root@kvm1-slave:~# dd bs=1M count=256 if=/dev/zero of=/kvm/images/test oflag=dsync
256+0 записей получено
256+0 записей отправлено
скопировано 268435456 байт (268 MB), 2,84927 c, 94,2 MB/c

Просела в два раза. - Быть может это объясняется тем, что используется RAID 1? Оно пишет в два диска... По сему ждёт каждого.

Ок.

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

compression=lz4 попробуй, lzjb, что по дефолту, намного медленнее работает. остальные догадки я лучше не буду комментировать.

Делал так

При создании пула забыл -o ashift=12 (выравнивание для hdd с секторами по 4096). Может быть поэтому тормозит.

root@kvm1-slave:~# zdb kvm|grep ashift
                ashift: 12

А какая должна быть скорость записи в mirror zfs? Такая же как у одного диска? Такая же как у двух, или меньше чем один?

А какая должна быть скорость записи в mirror zfs?

Как у 1 диска.

На raidz (raid5) получается как то так:

dd bs=1M count=256 if=/dev/zero of=/zpool1/tmp/ddd oflag=dsync
256+0 записей получено
256+0 записей отправлено
скопировано 268435456 байт (268 MB), 0,55756 c, 481 MB/c

zpool status -v
  pool: zpool1
 state: ONLINE
  scan: none requested
config:

	NAME                                     STATE     READ WRITE CKSUM
	zpool1                                   ONLINE       0     0     0
	  raidz1-0                               ONLINE       0     0     0
	    scsi-SAdaptec_LogicalDrv_1_25CA8B2B  ONLINE       0     0     0
	    scsi-SAdaptec_LogicalDrv_2_E0469B2B  ONLINE       0     0     0
	    scsi-SAdaptec_LogicalDrv_3_706A9B2B  ONLINE       0     0     0
	    scsi-SAdaptec_LogicalDrv_4_9C8E9B2B  ONLINE       0     0     0
	spares
	  scsi-SAdaptec_LogicalDrv_5_12BE9B2B    AVAIL  

root@kvm1-slave:~# zfs set compression=lz4 kvm/images
root@kvm1-slave:~# dd bs=1M count=256 if=/dev/zero of=/kvm/images/test oflag=dsync
256+0 записей получено
256+0 записей отправлено
скопировано 268435456 байт (268 MB), 3,25527 c, 82,5 MB/c

Это КАК такое возможно? Без компресии скорость в два раза НИЖЕ...

Нашел в хозяйстве ПК с zfs mirror, два харда wd-red воткнуты в набортный контроллер материнской платы.

dd bs=1M count=256 if=/dev/zero of=/zpoolddd/test oflag=dsync
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 5,08677 s, 52,8 MB/s

Тест какой то неправильный, вот тоже на ssd с ext4:

dd bs=1M count=256 if=/dev/zero of=/home/serg/eee oflag=dsync
256+0 записей получено
256+0 записей отправлено
скопировано 268435456 байт (268 MB), 4,64347 c, 57,8 MB/c

Ок. Давай правильный какой-нибудь попробуем? :)

Надо какие то тесты с fio придумать.

root@kvm1-slave:~# dd if=/dev/urandom of=/kvm/test bs=8k count=100000
100000+0 записей получено
100000+0 записей отправлено
скопировано 819200000 байт (819 MB), 50,2043 c, 16,3 MB/c

Сейчас просто cp попробую. :)

Ты бы хоть железо для наглядности описал: cpu, ram, lspci, ...

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

zfs тут не при чём. В BIOS серверной платы, была выключена VT-d. Но таки да: kvm-ok - возвращало - что всё ок. И /dev/kvm присутствовал.

Железо/soft:

Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz
32 GB RAM with ECC
2x = ST380013AS  - zfs mirror
2x = WD4000F9YZ - host OS

ubuntu x64 - 14.04
zol - 0.6.3.1
qemu-kvm 2.0.0

Народец, давайте потестим скорости записи/чтения то..? :)

VT-d

Оно тебе нужно? Это для проброса железа (pci) в виртуалку. скорости я так понял ты на хосте проверял, какая связь с виртуализацией?

VT-d, VT-x - всё было отключено.

По поводу скорости: я запустил вирт. машину, и... Удивился, что так всё медлено, хотя kvm-ok, возвращал, что всё ок. Начал тестировать скорость на хосте.

Потом включил в BIOS, всё что мне надо, и всё стало ок, по скорости виртуализации.

Теперь всё же хочется проверить скорость работы zfs.

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

Я пока не смотрел что у тебя за ключи для zfs. Но вот прям с ходу возникает вопрос: ты передаёшь инкремент, между вчерашним, и сегодняшним снепшотом. - Это всё ок. НО! Что будет, если у тебя slave узел не был доступен три дня? - Если ты ему впихнёшь разницу между сегодняшним, и вчерашним снепшотом. А куда ещё пару дней денутся на slave узле..? Сходу я вижу, что slave станет вообще не консистентным. Вполне вероятно, что ключ F , тут будет играть решающую роль. Надо посмотреть внимательнее... В общем тут главное консистентность чтобы была.

скорость работы zfs.

slow read / fast write. wtf? (комментарий)

zpool create -O compression=on

при создании пула не задано выравнивание

НО! Что будет, если у тебя slave узел не был доступен три дня? - Если ты ему впихнёшь разницу между сегодняшним, и вчерашним снепшотом.

кто мешает для пущей надежности (хранить в 3-х местах), дополнительно инкрементальную разницу между снапшотами писать в файл локально или на сетевое хранилище

запись:

zfs send -i kvmpool/tom/vol-vm12@3-2014-10-24 kvmpool/tom/vol-vm12@4-2014-10-24 > vol-vm12@4-2014-10-24.temp

восстановление:

cat 4-2014-10-24.temp | zfs receive -vdF kvmpool/temp

Не могу комментировать, линуксов с zfs нет под рукой, но 1) нулями zfs с компрессией не тестируют, 2) в реальности тоже будешь dsync писать?

Это всё ок. НО! Что будет, если у тебя slave узел не был доступен три дня? - Если ты ему впихнёшь разницу между сегодняшним, и вчерашним снепшотом. А куда ещё пару дней денутся на slave узле..? Сходу я вижу, что slave станет вообще не консистентным.

да прочитай ты уже документацию, блджад. Открой для себя транзакции, 'zfs send -I' и много другое.

http://docs.oracle.com/cd/E19253-01/820-0836/gfwqj/index.html

for i in `seq 1 10`; do (dd if=/dev/zero of=$i.txt count=1000 bs=1M ; sync) done;
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,18866 c, 5,6 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,182905 c, 5,7 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,167042 c, 6,3 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,166092 c, 6,3 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,171476 c, 6,1 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,178844 c, 5,9 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,180285 c, 5,8 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,169902 c, 6,2 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,170607 c, 6,1 GB/c
1000+0 записей получено
1000+0 записей отправлено
скопировано 1048576000 байт (1,0 GB), 0,169813 c, 6,2 GB/c

Почему то оно всё одно, через кеш бежит...

да прочитай ты уже документацию, блджад. Открой для себя транзакции, 'zfs send -I' и много другое.

Так вот -I , я и не развидел у товарища King_Carlo, и у меня возникло стойчайшее ощущение, что он делает что-то явно не так, и может у него на slave хосте тыква давно а не zfs.

и может у него на slave хосте тыква давно а не zfs.

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

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

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

у меня возникло стойчайшее ощущение, что он делает что-то явно не так, и может у него на slave хосте тыква давно а не zfs.

Ощущения тебя, в этот раз, подводят.

Да Бог бы с ними, с моими ощущениями... Не в них дело, не тебя хочу уколоть, а сам боюсь, тыкву получить. Что сделает твой сценарий если у тебя на пару суток не будет доступна slave инстанция? Руками разруливать?

Я ПОКА, для ТЕСТА, сделал так:

на $master поставил: zfs-auto-snapshot, и настроил чтобы оно раз в сутки мне снимало снимки, ну и хранило их 31 день - собственно, там уже всё настроено, даже можно сказать и делать ничего не нужно.

Далее я написал примерно такой кусочек сценария (базируясь на твоём сценарии):

slave_last_snapshot=$(ssh root@$slave zfs list -H -o name -t snapshot| sort | grep zfs-auto-snap_daily | tail -n1 | cut -d @ -f 2)
master_last_snapshot=$(zfs list -H -o name -t snapshot| sort | grep zfs-auto-snap_daily | tail -n1 | cut -d @ -f 2 )


zfs send -R -i $master/images@$slave_last_snapshot $master/images@$master_last_snapshot | ssh root@$slave zfs receive -Fdu $slave

Суть: сервер master, приходит на slave узел, и узнаёт имя последнего снепшота. Потом берёт это имя, и подставляет в качестве своего изначального имени в разнице zfs send -i, и в качестве второго имени, подставляет свой последний текущий снепшот, ну и отправляет этот diff, на slave узел.

Таким образом, я надеюсь, что временная недоступность slave узла, не приведёт к тому, что потом что-то будет не так и не сяк...

Буду конечно рад, твоим замечаниям!

P.S. в качестве дополнительной проверки консистентности узла slave, можно делать не scrub от файловой системы zfs, а делать на более высоком уровне! Например брать и сверять md5sum от образа небольшой но часто изменяемой вирт. машины. - Если не будет совпадать - кричать тревогой в zabbix.

И ещё: Скорость записи на ZFS (комментарий) - о каком кеше идёт речь? ARC? Почему ограничил?

берёт это имя, и подставляет в качестве своего изначального имени в разнице zfs send -i, и в качестве второго имени, подставляет свой последний текущий снепшот, ну и отправляет этот diff, на slave узел.

Всё будет ок. С мастера будут переданы все пропущенные снапшоты.

Да Бог бы с ними, с моими ощущениями... Не в них дело, не тебя хочу уколоть

Не бери в голову, всё нормально.

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

Не могу до конца распарсить значения: ключей send -R , и recv -Fdu

Можешь пожалуйста объяснить как для младенца? :-)

Я запутан...

Представим, у тебя узел slave был три дня не доступен. Стало быть: на мастер узле ты даёшь: zfs send -R -i $snapshot_yesterday $snapshot_today , что в моём понимании означает: отправь diff между указанными снепшотами а также все свойства файловой системы. Но у тебя и в помине нету на slave узле snapshot_yesterday, у тебя же там: snapshot_today -3d. Чего толку от того, что он ему туда diff пришлёт свежий, если на slave нету снепшотов за три дня, а стало быть он ничего не знает об изменившихся блоках в этот период? Или ключ -R сделает магию. Он сперва выравнет локальную и удалённую файловую систему полностью, а потом в следующий раз уже будет только diff посылать, если файловые системы выравнены?

Следующий вопрос: а что если, я на slave узле склонирую любой снепшот, и примонтирую его куда-либо на запись? Поскольку, у тебя стоят ключи: -R и -F, у меня получается всё похерится?

Флаг -u выставляет: canmount=noauto для файловой системы насколько я понял, что дополнительно меня защитит от идеи перезаписать что-то на слеве. Но это ведь не должно мне мешать создавать clone снепшотов на запись на удалённом узле?

Суть вопроса вот какая: мне бы хотелось иметь возможность на slave узле поднять любую вирт. машину с шагом в сутки, для записи. - Например, для того чтобы восстановить удалённые данные, или выполнить обновление ПО, и посмотреть что будет. - На master я этого делать не хочу, по причине того, что на master ресурсы заняты, а slave то вроде как без дела валяется...

Просто я думаю, быть может мне хватит нечто: recv -Fu ? Без R на передатчике...

P.S. не очень понял зачем тут тебе нужен ключ -d.