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

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

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

Брехня. Восстановление из бекапа == скорости чтения из бекапа+скорость записи на диск и zfs тут ничего не ускорит. Кончай уже молиться на zfs, будь реалистом.

Испугался.

на дедуплицированный сторедж - мелочь

Пока я не нашёл ничего, что бы могло мне для образов вирт. машин предоставить дедуплицированный сторадж - zfs, требует очень много ОЗУ для этого. brtfs - ещё не готово.

дедуплицированный сторадж - zfs

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

Ну вот и я как-то принимая во внимание, что дедупликацию не советуют, советуют отдавать ей диски вида: sda , sdb, а не разделы и тем более не lvm, что-то не понятно как там с настройками кешей при использовании kvm, боюсь её пользовать.

так что ты решил ?
сам сейчас интересуюсь, стоит тыкать zfs или все же lvm снапшоты ?
sdio твоё мнение тоже интересно.

Пока я не нашёл ничего, что бы могло мне для образов вирт. машин предоставить дедуплицированный сторадж - zfs, требует очень много ОЗУ для этого. brtfs - ещё не готово.

тогда у тебя два три выхода: 1) докупить тупо кучу дешевых дисков для хранения версий 2) купить дедуплицированную хранилку 3) работать на длинных цепочках снепшотов

нельзя и рыбку съесть и аквариум выпить.

ПОКА, планирую делать так (ЕСЛИ не получится, буду делать как тут посоветовали с zfs):

Моя задача, не High Avalibility, а просто backup + возможность проверки обновления ПО.

Следовательно:

nodeA: hw raid /dev/sda -> vg (4tb) /lvgroup (4tb)  -> drbd (master) ->  LAN ->

nodeB: -> LAN -> drbd (slave) -> lvgroup (4tb)/vg (8tb) -> /dev/sda hw raid.

Конфигурационные файлы: /etc/libvirt/qemu/* синхронизируется с nodeA на nodeB.

Итого: каждую ночь, запускается сценарий из crontab на nodeB, который делает одну простую команду «drbd connect all», в конфигурационном файле drbd установлен ШТАТНЫЙ сценарий для создания снепшота перед операцией синка, и его удалением после. - Я буквально пять строк в него добавлю, чтобы оно мне ротировало lvm снепшоты (всего планирую держать 7мь снапшотов) и делало: «drbd disconnect $DRBDRESOURCE». - Таким образом у меня не будет постоянной реплики между узлами, а значит и скорость i/o на nodeA будет равна практически нативной скорости.

На nodeA раз в неделю я делаю снепшоты от самих вм, через qcow2 (т.е. простой машин, не более 15сек в неделю).

Таким образом, на nodeB, я буду иметь: возможность запустить любую виртуальную машину МНГНОВЕННО, просто примонтировав любой снепшот lvm в каталог: /var/lib/libvirt/images, с шагом в сутки на состояние 7 дней назад. И буду иметь возможность запуститься потом с шагом в неделю назад - уже из самих снепшотов образов вирт. машин. Теперь о дисковом пространстве на nodeB: если внимательно посмотреть, то там места у меня будет 8TB, в отличии от узла nodeA. - Это место специально для снепшотов. Мало кто знает но в lvm место для снепшота может выделяться динамически - вот пруф: http://dustymabe.com/2012/03/04/automatically-extend-lvm-snapshots/ , а стало быть у меня там точно хватит 4ТБ на неделю. Также на nodeB, будет ещё один винчестер на 4ТБ без RAID и без lvm, чтобы можно было в случае чего просто отсадить любую вирт. машину на неопределённый срок. - Это например может потребоваться, если я буду в тестовом режиме проводить обновление ПО, на любой из машин.

Теперь касаемо страшного места: drbd. - Во первых оно мне будет передавать только diff за сутки. И мои большие вирт. машины будут за десять минут прилетать на nodeB. Во вторых, в drbd есть механизм проверки целостности каждого блока - при пересылке. В третьих, в drbd есть механизмы, которые в любое время позволят провести проверку целостности всех блоков drbd на узлах, чтобы они были идентичными. - В zfs, я таких механизмов не видел.

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

Да, это не HA... Может не совсем молодёжно. НО! Я использую строго стандартные linux решения, которые в ядре более 10ти лет уже. И не пользуюсь zfs, которая пока нигде официально не поддерживается, и не имеет явных проверок целостности на разных узлах. Более того, такая схема, мне позволит выполнить обновление того же qemu/drbd - и посмотреть чего будет. В следствии чего, я уже смогу потом обновить всё это на nodeA.

И да: nodeA и nodeB - будут расположены в разных зданиях.

нельзя и рыбку съесть и аквариум выпить.

он покрошил картошки, порубил лучка, посолил, перемешал и поставил аквариум на огонь

про теме - солидарен.

Круто, большой шкаф, громко падать будет.

А с zfs это не шкаф? :) Передавать разницу от снепшота, на другой узел по ssh, да ещё и пожатую разнциу... - Не шкаф? :)

тогда у тебя два три выхода: 1) докупить тупо кучу дешевых дисков для хранения версий 2) купить дедуплицированную хранилку 3) работать на длинных цепочках снепшотов нельзя и рыбку съесть и аквариум выпить

Быть может я попробую zfs с компрессией для резервного хранения вирт. машин. - Хотя я склоняюсь к тому что мне это нафиг не надо всё. Хранить образы от вирт. машин в трёх местах. Я лучше буду по старинке пользоваться rdiff-backup и делать бекапы из самих вирт. машин на уровне софта внутри вм (напр. MSSQL).

sdio, твоё мнение тоже интересно.

Я иначе строю такие системы.

Storage экспортирующий диски (LUNы далее) по HBA (на крайний случай iscsi или даже nfs) --> пара хост машин, видящие одни и теже диски. На «второй» хост системе виртуалки выключены и вкл. при «выключении» на первом хосте.

При проверке обновлений делается clone (cow, copy, что там доступно) диска на сторадже и поднимается тестовая виртуалка.

Бекапы данных обычными методами. Бекап системы зависит от системы, чаще всего это бекап списка пакетов и относительно небольшое кол-во файлов из /etc — одна виртуалка — один сервис.

Установить систему исп. kickstart минутное дело и раскатать конфиги тоже мелочь. Зачем тягать гигабайты ненунжых системных файлов?

Это с антресолью. :)
Я собственно к тому, что мне повезло поймать баг с ext4 over mdadm l1. Пачка qcow на помойку ушла. А у тебя там сплит дрбд, лвм, снэпшоты, qcow. Ух, аж дух захватывает !

Storage экспортирующий диски (LUNы далее) по HBA (на крайний случай iscsi или даже nfs)

Это уже решение уровня VMWare. А не уровня KVM. В таком случае есть смысл заплатить бабла вендору, и сделать всё по уму. Всё как у всех. У меня просто машин десяток. Не больше.

Я собственно к тому, что мне повезло поймать баг с ext4 over mdadm l1.

Именно по-этой причине у меня нету mdadm. LVM + drbd - штатная вещь, рекомендуемая разработчиками. И из-за опасений, тут опять же нету zfs.

уровня VMWare. А не уровня KVM

плакать хочется

Для тебя 15 сек паузы проблема, но ты упорно строишь наколенные системы.

15 сек. не проблема. На этих проектах, которые я делаю сейчас. Если это будет проблема - то я даже думать не буду, а пойду к вендору. Толковому вендору. Я уже ходил, но там получилось очень, очень дорого, не наш уровень. Даже в кредит - дорого. Руководство сказало - очень дорого.

Но люди делают вроде на proxmox всякое... :)

Так весь напряг в синхронизации дисков между основным и резервным хостом (drbd по сети). В случае общего хранилища этого нет.

А с общим хранилищем напряг появляется в его сохранности. Появляется напряг между аплинком - хостов которые крутят с него VM, и им. - Надо как минимум: сторадж, полностью продублированный. Сеть к железкам на которых будет бегать нечто - тоже всё продублированное. Некий арбитр который будет мониторинг вести узлов, и в случае падения одного из них, запускать резервный - в общем тоже очень, очень много чего надо. - Я посмотрел на proxmox, в серьёзном продакшене, его использовать может только идиот. А серьёзные решения, стоят очень серьёзных денег. Потом: я ещё раз подчёркиваю, что я делаю backup, а не HA. То есть дисковая полка тоже должна как-то backupиться. - В идеале если это будет решение ОДНОГО вендора, и лучше если будет полки дисковых две, плюс один архив - куда будут сливаться бекапы, и будет всё это монолитно, то есть от одного вендора, удобно и т.п. - но тут возникает ряд нюансов - ПО от вендора тоже надо обновлять, а что делать если надо обновить ПО на дисковой полке? - В общем тоже всё не просто... - Если я в ЭТИХ рассуждениях не прав, прошу мне указать, всегда рад критике. Толковой критике.

Моё решение, в общем то, ничего такого страшного не имеет, http://www.drbd.org/users-guide/ch-lvm.html - вот официальная документация по тому, чего я хочу. Ничего такого я не придумываю, и велосипед не изобретаю. А вот решение с zfs, мне местами видится как нечто примотанное изолентой. - Когда мы собираем модуль отдельно, и передаём diff через ssh... - Это прям изолента.

Я не могу предложить тебе общее решение на все случаи жизни.

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

Надо отталкиваться от конкретной виртуалки, что там будет крутиться, как конкретное её надо бекапить, как быстро надо восстанавливать и т.д.

Когда мы собираем модуль отдельно, и передаём diff через ssh... - Это прям изолента.

Если очень охота ковыряться с СХД, набить шишек и поиметь геморрой то zfs противопоказана, ибо она просто работает, неинтересно. Если нужно продуктивно работать и не отвлекаться на СХД, то ZFS самое оно. А разговоры про «модули» и «изоленту» я ещё могу понять, если их ведут разработчики этой самой zfsoninux, но вам то какая разница? Оно работает и всё.

Надо отталкиваться от конкретной виртуалки, что там будет крутиться, как конкретное её надо бекапить, как быстро надо восстанавливать и т.д.

Хорошо. Итак: плариную исполнять следующие VM: alfresco - 2шт. Одна тестовая (для разработчиков java + для конечных пользователей), одна продуктивная. jrebel - для разработчиков java. apache - как фронтенд для всего выше названного. zabbix. Также время от времени ко мне приходят патчи на alfresco или OS для alfresco - и я хочу их тестировать, НО! Я не должен мешать ни разработчикам java, ни конечным пользователям - то есть, иметь отдельную копию alfresco для тестирования уровня системного администратора.

ОС: alfresco - linux подобная анальная ОС. zabbix, apache, jrebel - ubuntu.

Планируемые объёмы данных: alfresco до 2ТБ со временем (каждый файл VM, так-как из продуктива в тест будут переодически переливаться данные/или их часть). Остальное - до 20гб.

Простой в случае аварии: до 1раб.дня. В случае катастрофы: допустимая потеря данных: 1 раб. день.

Нагрузка: 200 чел.

Допустимое время простоя в неделю: до 10 минут. (ночное время)

Бюджет на железо, ПО, уровня системного администратора: 250 тыс./руб.

Нормально описал?

Сами понимаете, Вы мне предлагаете решение, для 200 чел. которое будет стоить отнюдь не 250тысяч. Один свитч на 10 гбит/сек - стоит от 180 тысяч... Ну можно конечно слепить из того что было: NAS, налепить гигабитного бондинга... - Но это кхм...

Если сервак как hot-spare используется, то скорость восстановления из бэкапа - скорость чтения+скорости записи на диск инкрементальной разницы. Да, ZFS умеет инкрементальный бэкап на блочном уровне.

ЕМНИП такое хотели запилить(или уже запилили?) в btrfs.

простите, а оракл сертифицирован для работы внутри KVM?

там было что оба сервера накрылись и надо восстанавливать из «глубокого» бекапа

Моё решение, в общем то, ничего такого страшного не имеет

Ну как сказать http://habrahabr.ru/post/219295/

Да, видел. В общем то видел потом подтверждение, от proxmox. У меня к Вам собственно встречный вопрос: а умеет zfs проверять целостность томов то? Как мне удостовериться, что сейчас у меня хостА, и хостБ - имеют консистентные данные?

а умеет zfs проверять целостность томов то?

Что касается инкрементных бэкапов, то там всё просто - diff либо дошел, либо нет. Снапшот появится на удаленном хосте только если он точно совпал с исходным.
По поводу проверки целостности, насколько я знаю, есть только zfs scrub. scrub запускается у меня по cron раз в месяц, создает зверский IO, ошибок ни разу не нашел, необходимость его запуска под сомнением.

Очень толково! Спасибо.

А ресайзить можно zfs которая имеет снепшоты? Что будет в этом случае, если я на узле А увеличу файловую систему?

pool ресайзить нельзя, а понятие «ресайз» к файловым системам ZFS вообще не применимо, все файловые системы «резиновые» в рамках пула.

ZFS, собственно, тем и хороша, что не нужно думать заранее как организовать данные. Нужно блочное устройство? Не вопрос, можно сделать в рамках пула zvol. Файловая система? Создается одной командой, причём любой степени вложенности, с наследованием свойств родителя. Ресайз ФС? Забудьте, у вас больше нет такой проблемы.

pool ресайзить нельзя,

В смысле нельзя? Заменяешь по одному диски на большие и «zpool set autoexpand=on pool» тоже самое с выданными от схд - рескан шины и всё.

А, ну да, пул только уменьшить нельзя, увеличить можно. Пардон.

Я бы делал так:

У тебя железо: 2 хост системы. На каждой по копии виртуальной машины: на одной Online, на другой Standby. Online распределены между хостами, так при выходе из строя железа, одного из хостов, придется поднимать только половину всех виртуалок.

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

Синхронизировать online->standby банальным rsync (за исключением баз данных и кластера alfresco), никакого простоя и никаких «сложных» подсистем (drbd,...) для уменьшения точек отказа.

Активация standby либо сменой адреса в ДНС, либо добавлением IP адреса от online к сетевухе standby (алиас)

В случае выхода из строя обоих хостов, надо отталкиваться от имеющейся системы бекапа. Но я бы позаботился о сервере развертывания, pxe boot, tftp, unattended installation еще на этапе установки этих двух хостов.

В общем не вижу препятствий чтобы не попробовать zfs. Но я не знаю с чего начать.

Есть: /dev/sda для системы. /dev/sdb /dev/sdc

Хочу сделать RAID1 на zfs, для двух последних дисков. В дальнейшем, хочу добавить ещё два диска /dev/sdd /dev/sde, в ранее созданный пул. Вы могли бы подсказать какие мне точно потребуются команды для создания storage для kvm, и каким образом организовать правильно кеши?

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

за исключением баз данных и кластера alfresco

p.s. никогда не тыкал альфреско, даже не знаю что это такое. предложил как вариант.

Спасибо за ответ!

Также alfresco может работать в режиме кластера, поэтому я бы этим воспользовался.

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

Синхронизировать online->standby банальным rsync

Проблема в том, что в момент синхронизации, я имею неконсистентные данные на узле Б. И если в момент синхронизации, у меня выйдет из строя узел А, то я получу тыкву на обоих узлах. Так что перед выполнением rsync придётся делать снепшоты как на узле А, так и на узле Б.

Проблема в том, что в момент синхронизации, я имею неконсистентные данные на узле Б.

смотря о каких данных идет речь.

придётся делать снепшоты

Делай в виртуалках (на внутреннем lvm), а не на хосте.

от vxzvxz

Ну во-первых прочитай про особенности использования zfs, не нужно использовать имена вида /dev/sdb /dev/sdc, нужно использовать полный путь к устройству их можно посмотреть здесь ls -l /dev/disk/*

от vxzvxz, здесь же все написано - Очередной тред выбора бакапов (комментарий)

время восстановления виртуалки (фс которой = 20ГБ из которых 4,5ГБ занято) из полного снапшота занимает всего несколько секунд, т.к. на zfs со сжатием она занимает меньше гига и нужно преписать всего гиг а не 4,5ГБ.

Спасибо, я рад что ты вернулся в этот тред, даже не смотря на твой забан. :)

Меня очень напугало вот это у тебя:

интересно при таком подходе какова вероятность превратить в кашу xfs внутри снапшота?

Делай в виртуалках (на внутреннем lvm), а не на хосте.

Мучительно гемморойно выходит. Тоже надо предусмотреть много ситуаций, а что если rsync завершится аварийно? И т.п. Также надо будет следить, чтобы настройки нужных вирт. машин на обоих узлах были постоянно идентичны. - То есть, там увеличили дисковое пространство - и там надо не забыть. И т.п. - Ну и опять-же в полный рост встаёт вопрос: а как собственно откатиться на 2 дня назад? Делать rsync между вирт. машинами, создавая внутри них снепшоты, и делать снепшоты от самих вирт. машин? - Больно запутано выходит.

и это тоже внимательно изучить надо - http://pve.proxmox.com/wiki/ZFS

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

а как собственно откатиться на 2 дня назад?

zfs решает эти проблемы, ты ведь уже готов ее использовать. Кстати сколько RAM будет в хостах и сколько уйдет виртуалкам, ты уже прикидывал?

В остальном zfs не поможет, равно как и другие дисковые системы. Консистентность вещь физическая и логическая одновременно и зависит от внутренностей виртуалки, а не от ее внешнего содержимого как zfs, lvm, ...

в кашу xfs

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

zfs решает эти проблемы, ты ведь уже готов ее использовать.

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