LINUX.ORG.RU
ФорумAdmin

kvm freeze snapshot


2

3

Друзья, я что-то не понял... Как так?!

# time virsh snapshot-create-as alfresco-tst test
Снимок домена test создан

real	0m13.335s
user	0m0.011s
sys	0m0.005s

Всё это время машина недоступна... Как так? Обещали же вроде без фризов. Ubuntu 14.04

Хранилище у меня достаточно быстрое:

/dev/drbd0                   99G          21G   78G           21% /var/lib/libvirt/images
# dd if=/dev/zero of=/var/lib/libvirt/images/test bs=4096k count=1000 oflag=direct
1000+0 записей получено
1000+0 записей отправлено
скопировано 4194304000 байт (4,2 GB), 46,9889 c, 89,3 MB/c
<domain type='kvm'>
  <name>alfresco-tst</name>
  <uuid>073ac870-ba68-0b99-fef1-1c8bb6180921</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <blkiotune>
    <weight>1000</weight>
  </blkiotune>
  <vcpu placement='static'>4</vcpu>
  <cputune>
    <shares>1023</shares>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/alfresco-tst.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/infooborot_yum_repo.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:3d:04:78'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
</domain>
★★★★★

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

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

Такс... Я похоже делаю что-то не так. Как от этого избавиться? --disk-only ? Что-то муть какая-то: http://wiki.libvirt.org/page/I_created_an_external_snapshot,_but_libvirt_won'...

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

Супер! У тебя там чего живёт: raw в качестве диска для vm?

Как удаляешь снапшоты потом? - Выключать виртуалки приходится?

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

Супер! У тебя там чего живёт: raw в качестве диска для vm?

raw как базовый имидж, а с него снепшоты уже по определению qcow2

Как удаляешь снапшоты потом? - Выключать виртуалки приходится?

пока в оффлайне. blockcommit еще допиливают

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

Скинь пожалуйста команду удаления корректную.

Ещё подскажи пару вопросов пожалуйста:

Вопрос 1: В каком режиме у тебя бегают вирт. машины: c «записью через», c writeback или none?

Что-то мне i/o не дюже нравится... Хотя в целом и ничего... Но хочется большего.

Вопрос 2: снепшоты в итоге то работают в каком режиме? Забыл как называется, но что-то на вроде: redirect on read, или как-то так. Когда ВМ СРАЗУ начинает писать в снепшот, а читает из старых образов+снепшоты, это не бьёт почти по производительности, однако накладывает ограничение на удаление: там возникает операция слияния снепшотов. blockcommit - походит на то, что я говорю.

Вопрос 3: 20-30 снепшотов у вирт. машины это адекватно будет? Чтобы скажем делать их раз в сутки, а потом стопаться раз в месяц, и комитить скажем все, кроме последних штук 15.

Ах, и главное скажи: kvm + libvirt + drbd - продакшн рейди? Хочу гонять миссион критикал приложения. - Без SAN, не более 6 (3 в продакшене, три в запасе, или с drbd снепшоты снимать для разработки и теста юзать машинки) серверов без живой миграции, и 30 виртуалок.

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

Скинь пожалуйста команду удаления корректную.

ух ты, пашет живьем!

sudo virsh blockpull --verbose --wait C7 vda

после этого имидж целиком в последнем снепшоте, всю предыдущую цепочку можно стирать

Вопрос 1: В каком режиме у тебя бегают вирт. машины: c «записью через», c writeback или none?

Что-то мне i/o не дюже нравится... Хотя в целом и ничего... Но хочется большего.

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback' io='native'/>
      <source file='/home/dyasny/Work/snap1.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>

можно еще поиграться, это просто тестовая VM. cache=none лучше для боевых серверов, особенно если там венда

Вопрос 2: снепшоты в итоге то работают в каком режиме? Забыл как называется, но что-то на вроде: redirect on read, или как-то так. Когда ВМ СРАЗУ начинает писать в снепшот, а читает из старых образов+снепшоты, это не бьёт почти по производительности, однако накладывает ограничение на удаление: там возникает операция слияния снепшотов. blockcommit - походит на то, что я говорю.

COW (copy on write) и да, снепшоты таки бьют по производительности, и чем их больше тем сильнее. Вообще в продакшене не рекомендуется их использовать постоянно

Вопрос 3: 20-30 снепшотов у вирт. машины это адекватно будет? Чтобы скажем делать их раз в сутки, а потом стопаться раз в месяц, и комитить скажем все, кроме последних штук 15.

нет, не адекватно вообще. от бекапов никуда не денешься

Ах, и главное скажи: kvm + libvirt + drbd - продакшн рейди? Хочу гонять миссион критикал приложения. - Без SAN, не более 6 (3 в продакшене, три в запасе, или с drbd снепшоты снимать для разработки и теста юзать машинки) серверов без живой миграции, и 30 виртуалок.

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

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

Пока ты мне отвечал, я нагуглил такое:

Therefore, it is important to be able to reduce the length of a backing chain. Qemu exposes at least three options for shortening a backing chain; also, be aware that the options for manipulating a chain while a guest is running differ from the options for manipulating a chain when no guest is using the disk. When shortening a backing chain, the idea is that the guest must continue to see the same information, but that it takes fewer files to represent the information. Qemu's 3 options are:

virsh blockpull: Remove one (or more) backing files, by pulling the content from the backing file into the active file. Limitation: as of qemu 1.6, you can only pull into the active image of an online guest (for offline images, qemu-img you can pull into any image with a rebase command). With this, it is possible to go from:

base <- snap1 <- snap2*

to:

base <- snap2*+^

where the contents of snap1 are now contained in snap2, and where snap2 had metadata rewritten to point to base.

> virsh blockcommit: Modify a deep backing file so that one (or more) intermediate backing files are committed into the base. Limitation: as of qemu 1.6, you cannot commit from the active image of an online guest (for offline images, the qemu-img commit operation can commit, but only through one base file at a time).

То есть, sudo virsh blockpull - будет пахать ТОЛЬКО в онлайне, и тут похоже никуда не деться, рано или поздно, нужно будет делать: blockcommit. И при том, чем позже, тем дольше оно будет делаться, а оно как раз таки требует офлайна.

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

на самом деле это просто два подхода, один говорит что дельту наработанную в снимке надо писать вверх по цепочке, другой говорит что вниз. blockpull, который по ходу у меня работает живьем, тянет все блоки в последний снимок (по правильной терминологии leaf) после чего можно убирать все предыдущие файлы/lv, потому что вся инфа всей цепочки уже в последнем снимке.

в боевых условиях, без извращений с длинными цепочками снепшотов, есть один плоский имидж. для бекапа или тестов снимаем external snapshot, бекапим base, и делаем blockpull в новый снимок, после чего стираем base для экономии места. вполне рабочая схема, имхо.

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

COW (copy on write) и да, снепшоты таки бьют по производительности, и чем их больше тем сильнее.

Да не может быть того! Тогда тебе не надо было бы: blockpull и blockcommit делать. Не?

Вот они пишут про цепочки:

Taking several snapshots in a row, without any cleanup, can result in less efficient operation as qemu has to trawl through ever more open file descriptors for contents that have not changed since the original file

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

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

после чего стираем base для экономии места. вполне рабочая схема, имхо.

Вот тут я не распарсил тебя. Как это ты так решил удалить base?

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

У меня есть база 1С. Бухи косячат. И просят восстановиться на 1,2,3,15 дней назад. Но не более 15ти дней. И смотрят кто и когда накосячил в базе, чтобы понимать как с этим жить. --- Мне вроде как видится, что я могу разместить drbd на lvm, отдавать этот drbd на другую ноду, и там сразу поднимать ЦЕЛУЮ виртуалку из любого снапшота. - Только надо понять как это сделать ещё бы правлиьно. :) Через virt-manager ну или править конфигу виртуалки... - Правильно ли я понял? :)

плоский имидж. для бекапа или тестов снимаем external snapshot, бекапим base

Представляешь сколько мне места понадобится? :) И какая жирная сеть, чтобы base каждый день забирать...

Пока не вижу противопоказаний против >15 снепшотов. :)

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

Это да... При том запись вниз - только офлайн. Запись вверх - только онлайн... Вон оно как...

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

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

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

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

Вот тут я не распарсил тебя. Как это ты так решил удалить base?

все что было во всей цепочке, от base до leaf после blockpull в leaf оказывается в leaf, значит вся предыдущая цепочка уже не нужна.

У меня есть база 1С. Бухи косячат. И просят восстановиться на 1,2,3,15 дней назад. Но не более 15ти дней. И смотрят кто и когда накосячил в базе, чтобы понимать как с этим жить. --- Мне вроде как видится, что я могу разместить drbd на lvm, отдавать этот drbd на другую ноду, и там сразу поднимать ЦЕЛУЮ виртуалку из любого снапшота. - Только надо понять как это сделать ещё бы правлиьно. :) Через virt-manager ну или править конфигу виртуалки... - Правильно ли я понял? :)

уууу как все запущенно. а какой нибудь git или cvs туда не прикрутить? можно сделать кучку снимков и посмотреть как оно себя поведет, если достаточно шустро, то и х с ним, если нет - надо искать решения.

например делать snap+blockpull каждый день, и откладывать бывший base в хранилку. если надо откатиться - просто убираем leaf, и вместо него подсовываем предыдущий имидж из хранилки. таким образом ВМ всегда пользуется плоским имиджем а не цепочкой, но и откат возможен. места правда надо много, но тут уже такое дело - диски нынче дешевые

Представляешь сколько мне места понадобится? :) И какая жирная сеть, чтобы base каждый день забирать...

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

Это да... При том запись вниз - только офлайн. Запись вверх - только онлайн... Вон оно как...

это пока что. там просто нюансы с манипуляцией IO, которые сложноваты

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

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

Опа... Интересно. Логично! Спасибо. Ведь снапшоты могут быть и ветвлёные. Но смущает вот чего:

до того как в него что либо запишут, снепшот это не набор блоков с информацией, а набор линков на предыдущий по цепочке файл

Почему изначально файл снепшота столь маленький, если в нём куча линков на каждый блок?

Про 1С:

уууу как все запущенно. а какой нибудь git или cvs туда не прикрутить?

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

База бухгалтерии в целом не большая. 20 гиг. Но! Тут ещё вот чего бывает: бывает «бешанный принтер», придумает очередной говнозакон, и приходится поднимать версию конфигурации 1С. А так-как база и без того пиленная, то 1Сник хочет проверить, а как встанет обновление. Для чего: мы имеем отдельную виртуалку, из основной бухгалтерии делаем выгрузку базы в неё, после чего 1Сник накатывает обновления, правит там что-то. После чего мы подключаем всем бухам эту новую базу, и бухи сверяют остатки на счетах. - Если остатки сходятся, значит, мы обновляем продакшн.

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

По сему, мне подумалось: чтобы не платить кучу бабла за вмвари, быть может взять, развернуть на raid-1 SSD, виртуалку с 1С боевой (сейчас это физ. нода), но сделать бутерброд: raid-1, lvm, drbd, ext4, raw образы. Далее, подключаем свободную ноду, где переодически догоняем состояние через drbd, и снимаем снепшоты. Мы ведь не забыли про lvm. Так-как у нас будут и снапшоты от самой виртуалки, мне не сложно будет бухгалтерии в случае чего предоставить базу за столько то дней назад. - Запустив вирт. машину прямо на соседней ноде. А также, не надо будет мутить постоянно с базами, 1Сник сможет там подниматься и творить чего ему надо, на соседней ноде. Ну и плюс соседняя нода - будет выступать как резервный узел. - В общем я написал сложно, и много. Но в целом думаю ты меня поймёшь. А пока я делаю бекапы 1С, банально выгрузкой MSSQL + rdiff-backup.

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

Избежать конфликтов ip адресов при такой схеме, мне поможет NAT в libvirt + буду конфиги libvirt нужные мне держать в git, и сливать на резервную ноду, чтобы запустить вирт. машины.

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

Почему изначально файл снепшота столь маленький, если в нём куча линков на каждый блок?

правильно сказать «ах вот почему пока он пустой без единого блока, у него все равно есть размер - оказывается это линки!»

процедура в целом не плохая, но несколько утомительна

такое можно сказать про весь этот ваш 1с. как хорошо что я с такими ужасами дела не имею

По сему, мне подумалось: чтобы не платить кучу бабла за вмвари, быть может взять, развернуть на raid-1 SSD, виртуалку с 1С боевой (сейчас это физ. нода), но сделать бутерброд: raid-1, lvm, drbd, ext4, raw образы. Далее, подключаем свободную ноду, где переодически догоняем состояние через drbd, и снимаем снепшоты. Мы ведь не забыли про lvm. Так-как у нас будут и снапшоты от самой виртуалки, мне не сложно будет бухгалтерии в случае чего предоставить базу за столько то дней назад. - Запустив вирт. машину прямо на соседней ноде. А также, не надо будет мутить постоянно с базами, 1Сник сможет там подниматься и творить чего ему надо, на соседней ноде. Ну и плюс соседняя нода - будет выступать как резервный узел. - В общем я написал сложно, и много. Но в целом думаю ты меня поймёшь. А пока я делаю бекапы 1С, банально выгрузкой MSSQL + rdiff-backup.

слишком сложно. drbd зачем нужен? есть virsh blockcopy, или даже стоп на виртуалку и virt-clone. или вообще - снять снепшот, ответвить от base еще один снепшот руками (qemu-img create -b -o ...) и поднять с него тестовую ВМ. запасной хост для отказоустойчивости это хорошо, но опять же - городить настоящий HA нужно только когда оннужен. а если ебольшой даунтайм не проблема - просто держим на запасном хосте бекапы имиджей, (заодно и бекап сервер получается) и если надо поднимаем любой из них по мере надобности

кстати, ничто из этого выгрузку из mssql не отменяет как последнюю инстанцию, желательно в другом здании или в облаке

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

слишком сложно. drbd зачем нужен?

Дано:

Локальная сеть 1гбит/сек. + Она ещё и загружена.

Пусть есть n узлов (в разных зданиях). На которых выполняются вирт. машины: 1C (50 гб.), samba (350 гб.)- файлопомойка, ECM (4 ТБ), ERP (500 гб.).

Пусть есть узел x. На который можно выполнять резервное копирование с узлов n.

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

В условиях задачи допустимо, при самом плохом варианте потерять 1-2 дня от указанных выше узлов. При катастрофе, допустимо восстановиться на 1 месяц назад.

Вопрос: как добиться, чтобы на узле x, были копии всех виртуальных машин с узлов n с максимальным отставанием в 1-2 дня?

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

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

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

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

единственный вариант который мне видится с drbd({glusterfs|ceph|zfs}) это большой локальный том в каждом из хостов, на котором складываются еще и бекапы (то есть реально очень большой том) плюс репликация всего этого огорода на все три ноды. сеть будет забита - мало не покажется, но от этого никуда не денешься.

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

dyasny ★★★★★
()

используй zfs там и снапшоты и репликация и бэкап красивый. только снапшотов много не советую держать. 15 вполне пойдет

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

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

Я бы вообще наверно смотрел в сторону вмваре + fibrechanell + спец. железо. Но это дорого. Очень дорого. У меня сервисы не нагруженные, но они разнообразные, и их много. Центральной серверной нету, по историческим причинам.

единственный вариант который мне видится с drbd({glusterfs|ceph|zfs}) это большой локальный том в каждом из хостов, на котором складываются еще и бекапы

Очень круто! Но во истину жутко по ресурсам, да и glusterfs - насколько я понял, fuse модуль, а значит не быстро. zfs - во истину стрёмно. ceph - не знаю.

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

drbd не дает копию, он дает репликацию

Можно стопать/поднимать реплику по расписанию, что по идее очень существено разгрузит сеть, и если это делать ночью, то виртуалки вообще не будут иметь оверхеда от drbd, так-как днём его фактически не будет. Тогда будет консистентная копия, но с отставанием (что в моём случае - ок). А на некоторые события, можно повесить sh скрипты. - Всё уже идёт из коробки.

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

Я бы вообще наверно смотрел в сторону вмваре + fibrechanell + спец. железо. Но это дорого. Очень дорого. У меня сервисы не нагруженные, но они разнообразные, и их много. Центральной серверной нету, по историческим причинам.

ну вмварь не нужна когда есть rhev/ovirt. FC тоже уже не так критичен, при наличии RDMA и/или 40-100Gbps сетей.

Очень круто! Но во истину жутко по ресурсам, да и glusterfs - насколько я понял, fuse модуль, а значит не быстро. zfs - во истину стрёмно. ceph - не знаю.

гластер уже не только fuse. ceph тем более. а диски - штука дешевая. имхо drbd намного стремнее, я насмотрелся на то как оно рассыпается

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

drbd намного стремнее, я насмотрелся на то как оно рассыпается

В master/slave рассыпается? Как это выглядит? В целом там есть хуки и готовые скрипты на события, и снепшотить оно умеет перед синком вроде (но я пока не проверял :( ).

ну вмварь не нужна когда есть rhev/ovirt.

Спорно в плане конечной стоимости владения я думаю. Впрочем спорить не буду. Пока в бюджете нет на это средств.

гластер уже не только fuse

А всё равно сцыкатно, master/master же. Надо будет мудрить тогда с арбитором каким-нибудь...

FC тоже уже не так критичен, при наличии RDMA и/или 40-100Gbps сетей.

А поцене то..? То на то и выйдет... ИМХО. :)

У меня просто не 24/7. Я могу стоять иногда. И могу потерять день информации.

Сейчас попробовал: qcow2 как образ. И делаю туда офлайн снепшоты. - Первые впечатления - всё супер!

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

В master/slave рассыпается? Как это выглядит? В целом там есть хуки и готовые скрипты на события, и снепшотить оно умеет перед синком вроде (но я пока не проверял :( ).

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

Спорно в плане конечной стоимости владения я думаю. Впрочем спорить не буду. Пока в бюджете нет на это средств.

спорно? rhev в 10 раз дешевле. ovirt вообще бесплатен

А всё равно сцыкатно, master/master же. Надо будет мудрить тогда с арбитором каким-нибудь...

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

А поцене то..? То на то и выйдет... ИМХО. :)

это скорее всего так :)

У меня просто не 24/7. Я могу стоять иногда. И могу потерять день информации.

Сейчас попробовал: qcow2 как образ. И делаю туда офлайн снепшоты. - Первые впечатления - всё супер!

главное помнить что цепочка не должна быть слишком длинной

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

главное помнить что цепочка не должна быть слишком длинной

Вот это мне и не очень нравится в моей затее. Хотя, ты ведь не предложил мне решение backup. Ты пока всё говоришь про HA. Ибо те-же вендоры от VMWare, предлагают примерно такую схему: хранилище по FC (с дублированием железяк внутри него), и блейд сервера для выполнения вирт. машин.

А вот, резервное копирование - это уже отдельное хранилище. Куда выполняются копии.

И отдельное хранилище - архив.

Всё что пока говоришь ты - это НА. А мне оно пока не очень актуально.

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

ovirt вообще бесплатен

Не ужели можно реально крутить вирт. машины по NFS? Даже не представляю как будет работать таже 1С... В таком виде.

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

zfs - во истину стрёмно

это еще почему? работоспособность ZOL+KVM на linux железобетонная. ну а если такие страхи по поводу ZOL, то можно san поднять на bsd, нарезать тома zfs, и отдавать их под виртуалки на linux по iscsi.

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

отдавать их под виртуалки на linux по iscsi.

Сеть то 10 гигабит нужна будет под это дело? Сейчас поглядел стоимость 10G оборудования... - Дорого. Очень дорого. Считай, от 160 тысяч, только простые свитчи.

Конечно в целом, не плохой идеей выглядит машинка с zfs + iscsi. Но вот конечно вопрос, даст-ли оно мне: 90 МБ/сек на честном гигабите? Ну и всё одно - это будет медленее, чем локальный сторадж. Да и тогда не очень понятно, как использовать виртуалки в таком раскладе... - А если свитч навернётся? Чего будет с образами виртуалок? В общем много нюансов возникает.

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

на drbd гоняю только контейнеры lxc, kvm там стремно держать.

А что не так с drbd то? У меня же оно в режиме: master/slave. Вроде не вижу никаких серьёзных препятствий, чем оно могло бы мне помешать. Это конечно ещё одна абстракция, дело то понятное. Но zfs, люстра - это тоже же абстракции...

Но в целом, конечно хочется попробовать рискнуть, и пользоваться zol + drbd. Но в Интернет, говорят, что этого не стоит делать. Это не совместимая связка.

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

Сеть то 10 гигабит нужна будет
А если свитч навернётся

iscsi позволяет «объединять» обычные сетевухи, получая или повышенную производительность сети или отказоустойчивость, называется это - iscsi multipath - http://ivirt-it.ru/multipath-io-iscsi/

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

zol + drbd

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

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

не стоит так делать. zfs не любит прокладки не под собой и не над собой

Стало быть, нужно тогда будет организовывать центральное хранилище.

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

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

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

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

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

свитч берется не один, сетевых карт тоже надо несколько, а дальше multipath все сделает

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

Плоский имидж - здорово! Но плоский имидж будет жить на zfs, а zfs потребует единого стораджа. А это в моей ситуации не годится. Так-как надо будет этому стораджу как-то делать какой-то failover. И это в свою очередь потребует организацию человеческого SAN/NAS. - В общем это уже будет совсем другая архитектура.

Если тебе интересно, я тебе могу рассказать, как я сейчас задумал это всё делать (буду рад, если покритикуешь!). - В общем и целом получается довольно не плохо, с тем учётом, что я могу выпросить ночной downtime на 5 минут для практически любого сервиса. Да, не так круто, как предполагаешь ты, но всё же в целом, не плохо. Планирую lvm + drbd + csync2. Никаких костылей (почти). Всё штатно. Быстро, достаточно удобно, и вполне подходит под мои задачи.

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

но большой огород выходит из всего этого. :(

Всем пофиг, зато Developers, developers... , упс ,т.е. ZFS,ZFS,ZFS,ZFS!

P.S. Как бы все красиво, фичасто, но как до реализации доходит, так надо 100500 условий соблюсти, новое оборудование докупить и душу продать.

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

Плоский имидж - здорово! Но плоский имидж будет жить на zfs, а zfs потребует единого стораджа. А это в моей ситуации не годится. Так-как надо будет этому стораджу как-то делать какой-то failover. И это в свою очередь потребует организацию человеческого SAN/NAS. - В общем это уже будет совсем другая архитектура.

zfs replication? хотя SAN оно конечно получше

а предлагаемое, ну я не фанат drbd. csync это из той же оперы, и опять же - решение скорее для HA а не бекап/роллбек. Кстати, quadstor выглядит на этом фоне намного интереснее

а так можно вообще убрать qemu snapshots и делать вот так: http://wiki.jokeru.ro/howto-server-backup-with-drbd-and-lvm-snapshots

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

если есть время на даунтайм, то вот как я себе это представляю:

1. основной сервер на котором живут все ВМ. Один такой или несколько - не важно.

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

3. каждый день проходит следующая процедура:

- live snapshot

- base image copy to DAS

- blockpull + remove base image from main storage

4. ротация копий имиджей, т.е. храним последние 15

5. если надо откатиться - останавливаем ВМ, подменяем имидж на нужный, зпаускаем ВМ.

6. закладываем в бюджет центральный бекап сервер для этой кухни, куда складываются бекапы сервера(ов). очень жирная дура которой на самом деле не нужно ничего кроме дисков (ВМ там гонять не будем, так что проц/память пофиг). Можно поднять там дедупликацию и сжатие для экономии места - zfs/quadstor/sdfs - не важно.

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

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

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

Как бы все красиво, фичасто, но как до реализации доходит, так надо 100500 условий соблюсти, новое оборудование докупить и душу продать.

к чему эти потуги?

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

к чему эти потуги?

Вот и я о том же. Если нельзя zfs использовать локально, то зачем выдумывать NAS на основе дополнительного сервера на f-bsd + zfs, iscsi, замена сетевого оборудования, ... ??? Но зачем?

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

Ага. Ну это второй мой вариант, так сказать запасной. :) Свой вариант, я тебе завтра напишу, если ты не против. :) В моём варианте всё несколько похуже будет правда... Но в целом, тоже не плохо. У меня несколько менее надёжно выходит. Это с одной стороны. А с другой... - У меня вполне себе супер. В твоём варианте - единая точка отказа:

к нему докупается жирный DAS набитый дешевыми дисками, или NAS, но висящий на отдельном кабеле

Сдохнет у него источник питания... - И чего я делать буду? :) С бекапа всё поднимать..? :)

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