История изменений

Исправление DALDON, 22.10.14 17:12 (текущая версия) :

ПОКА, планирую делать так (ЕСЛИ не получится, буду делать как тут посоветовали с 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 - будут расположены в разных зданиях.

Исходная версия DALDON, 22.10.14 17:09:

ПОКА, планирую делать так (ЕСЛИ не получится, буду делать как тут посоветовали с 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.

На 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, чтобы можно было в случае чего просто отсадить любую вирт. машину на неопределённый срок. - Это например может потребоваться, если я буду в тестовом режиме проводить обновление ПО, на любой из машин.