Как сделать репликацию и бекап образов KVM на другой сервер?
Добрый день.
Требуется настроить систему виртуализации в небольшой фирме.
Выбор пал на KVM. Требуется настроить репликацию виртуальных машин между двумя нодами и периодических их бекап.
Репликацию вроде как настроил через DRBD. Работает. Схема такая (для общего понимания): sda+sdb->MDADM->LVM->LV->DRBD0->KVM, то есть ссылка на диск в настройках виртуалки ведет на устройство DRBD.
Верное решение? Насколько это надежно, если виртуалки будут с критически важными сервисами?
Подразумевается, что если первая нода падает, заходим на вторую, повышает там реплику drbd до primary и запускаем виртуалку, которая там уже импортирована и диск у которой указан так же вида "/dev/drbd0" (secondary устройство, на которое ведет реплика с первой ноды). Сколько раз так делал в рамках теста - проблем пока не увидел. И плюс так же в том, что без перевода реплики в режим primary - виртуалку на второй ноде не запустить (ошибка вываливается).
Правильный ли выбор хранить виртуалки на LVM? Ведь можно выбрать файловый вариант. Но тогда встает вопрос как вешать на них drbd (он работает только с блочными устройства). Через loop будет подходящей идеей?
И еще вопрос насчет периодического бекапа БЕЗ остановки ВМ. В файловом варианте я это делал через промежуточное создание снепшота силами virsh.. как это сделать, когда диск виртуалки это /dev/drbd0 поверх lvm? Бекапы надо складывать в сжатом виде на Synology по NFS.
интересно.
Насчет mdadm - ок. Но вообще в идеале убрать именно его, а не mdadm.
Насчет трех узлом по-подробнее пожалуйста) Какая схема "на пальцах" более приемлема?
Написано
Армянское Радио
@gbg Куратор тега Системное администрирование
Евгений Воробьев, Без пальцев - любые, кластерные схемы с автовосстановлением вводят понятие кворум
Кворум - это такое количество узлов, при котором кластер считает себя единым целым и продолжает работать. Если кластер обнаруживает, что в нем узлов меньше, чем нужно для кворума, он останавливается и ждет пока не наберется кворум. Это исключает ситуацию, когда кластер разваливается на две равные части и обе отдельные части продолжают работать.
Например, в случае двух узлов это будет классический split brain
При трех узлах допускается потеря любого одного узла. Два других понимают, что третий отпал (и точно не будет работать) и продолжают без него, автоматически.
В своих проектах я использую под это дело ceph. Его главный плюс - отвал чего угодно для него - штатная ситуация, пока есть кворум, он спокойно себе работает. Его главный минус - медлительность, причем вызвана она скорее всего неоптимальным кодом, нежели плохой архитектурой.
То есть, если что-то умерло, мне не нужно бежать и вручную менять роли и что-то поднимать - хранилка останется доступна, а упавшие виртуалки поднимет HACLUSTER.
Фокс Йовович, не не. То что вы имеете в виду это пока что слишком круто. Хочется пока что поднять именно репликацию, при которой запускать вирты на другой ноде надо будет вручную (именно с переводом ролей ручками). То есть нам сейчас надо чтобы тупо на другой ноде была копия в реальном времени (желательно) образа вирты с главной ноды. Ну и бекапы чтобы автоматом периодически с первой ноды снимались скриптами по ночам.
По-сути пока что в "ДАНО" можно записать так: "есть файл, который пишется и читается в реальном времени. Нужно на втором компе вести реплику этого файла в реальном времени (небольшое отставание допустимо). Главное, что бы было надежно"
Написано
Армянское Радио
@gbg Куратор тега Системное администрирование
Евгений Воробьев, тогда вам надо между DRBD и виртуалкой положить что-то, что может снимать снапшоты - LVM (еще один), OCFS2 или что-то подобное. Потому что раньше у вас снапшот снимался средствами формата QCOW2, который в данной схеме исключен.
Ну и главное. Если возможен бекап вашего приложения средствами самого приложения (например, у вас на виртуалке СУБД или файлопомойка), то этот колхоз весь даром не нужен.
Фокс Йовович, тогда простой будет. Пока развернешь новую вирту, пока развернешь бекапы баз тех же. Репликация позволяет уложиться в простой минут 5-10, запустив просто ту же самую вирту на другой ноде.
"у вас снапшот снимался средствами формата QCOW2".
Нет. Снапшот снимался средствами virsh.
"virsh snapshot-create-as --domain $@ snapshot$diskspec --disk-only --atomic --quiesce --no-metadata"
Тут qcow2 уже не причем.
Написано
Армянское Радио
@gbg Куратор тега Системное администрирование
Евгений Воробьев, э нет, сначала вы будете долго чинить поломанную ФС, потом поломанную базу. Если у вас СУБД, вам нужно настроить бекап / HA средствами этой самой СУБД, а не городить велосипеды вокруг велосипедов. Большинство взрослых баз поддерживают это из коробки.
virsh - это только интерфейс управления, он сам ничего особо делать не умеет, только KVM пинает.
У вас раньше виртуалки лежали в виде файлов в формате qcow2?
Фокс Йовович, ну насчет снепшотов и требования qcow2 для них не могу спорить) А насчет репликации базы данных... ладно. А как быть с другими сервисами? например виртуалка с астериск.... или виртуалка с почтовым серваком
Написано
Армянское Радио
@gbg Куратор тега Системное администрирование
Евгений Воробьев, астериск штука персистентная, у него может поменяться только конфиг - с ним нечего реплицировать.
С почтой - тут надо разбираться индивидуально.
Важно понимать вот какой момент - снапшот, это фактически, дерганье машины из розетки. ФС будет в неконсистентном состоянии, отработает ли откат журнала - это как повезет (это еще надо проследить, чтобы журнал был включен и чтобы вся цепочка слоев корректно прокидывала fsync).
Фокс Йовович, что-то я почитал темы на форумах и статьи всякие... не видел каких то страшных отзывов о потере данных при работе drbd (в режиме C). Не поймите меня неправильно) Я не говорю что сказали ерунду, а просто пытаюсь подробно разобраться в вопросе. Знаете же как бывает? Один не разбирающийся сказал и все приняли его мнение за истину. Вдруг вы ошибаетесь и зря меня пугаете) Буду рад, если у вы дадите примеры или расскажете о таких.
Написано
Армянское Радио
@gbg Куратор тега Системное администрирование
Евгений Воробьев, Если вы пытаетесь уличить меня в предвзятости, да я предвзят в пользу CEPH.
Я эксплуатировал DRBD около 6 месяцев, после чего сделал вывод о том, что он требует к себе уж очень много внимания на рутинных операциях.
Это все равно что спрашивать у человека, пересевшего с ЗАЗ на иномарку, стоит ли покупать ЗАЗ (и при этом посещать форумы любителей ЗАЗ, где обсуждают тонкости сверловки магниевого картера или приколхаживания электровпрыска вместо макета карбюратора, который там идет по заводу)
Попробуйте на досуге сделать две вещи:
1) урезать диск одной виртуалке
2) отдать это место другой виртуалке
Запишите необходимое количество кувырков с бубном, при условии что CEPH сделает п/п 1 полностью автоматом (при удалении файлов из первой виртуалки сработает TRIM и место станет свободным)
п/п 2 - сделать ресайз диска второй виртуалки (одна команда, делается моментально), загрузить ее и сделать ресайз раздела (двинуть полосочку в менеджере дисков мышкой)
И еще одно упражнение - склонировать одну виртуалку три раза. Я это сделаю за пару минут, потому что CEPH CoW, клоны в нем создаются моментально (но по началу клонированные виртуалки тормозят)
Фокс Йовович, ну тут больше стоит вопрос надежности. Такими вещами как увеличивать и уменьшать место мы заниматься постоянно не собираемся. Нам главное, чтобы развернутая вирта с базой psql (1) работала, (2) ее диск реплицировался на вторую ноду (3) без потери данных. Ну и, как замечено выше, (4) была возможность бекапить диски этой вирты БЕЗ остановки самой вирты. Требуется соблюсти эти 4 пункта. Про то, что забекапленная "на горячую" виртуалка, после восстановления без запущенна как после жесткого выключения, это я прекрасно понимаю и иначе быть не может. Но отсутствие остановки важнее в данном случае. Неудобства изменения размеров, расположения данных (при наличии этой возможности как таковой) нас не сильно волнуют (пока что).
Написано
Армянское Радио
@gbg Куратор тега Системное администрирование
Фокс Йовович, стоп? Как это не заметят? Люди работают с базой на сервере *.1.1. Реплика на *.1.2. Если первый ляжет, то как минимум сменится адрес активной базы же? Это не говоря о поднятии реплики до уровня мастера.
Написано
Армянское Радио
@gbg Куратор тега Системное администрирование
Сложный
