LINUX.ORG.RU
ФорумAdmin

Правильность такого метода репликации KVM

 , ,


2

9

Добрый день. Требуется настроить систему виртуализации в небольшой фирме. Выбор пал на 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.

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

спасибо. Но еще хотел бы узнать… виртуалки с базами данных. Сервис критичный. Правильный выбор drbd? Это надежно?

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

У баз данных есть свои механизмы репликации/кластеризации

Система (системный диск) почти статика, там раз в пол-года (условно) можно просто rsync’ом (условно) синхронизировать.

Придумываете на пустом месте проблемы и героически их пытаетесь решать.

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

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

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

Поставьте Proxmox. Там и бэкапы настраиваются удобно и интерфейс понятный. Общее хранилище на CEPH для обычных сервисов и локальные диски гипервизоров для кластера БД.

dhameoelin ★★★★★ ()

Придумать велосипед из костылей – это, конечно, вариант быть «незаменимым админом»… Но, когда ваш велосипед развалится – вас вздёрнут, а нам разгребать…

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

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

А ошибки везде есть.

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

вы конечно классные ребята, да… но существующий парк машин не очень мощный и на свяких цефс будут потери большие. Общего хранилища нормального НЕТ. СХД так же НЕТ. Есть несколько серверов на стареньких LGA1366, один на не очень мощных LGA2011 и один на (ВНИМАНИЕ!) на LGA771. Диски тоже везде не очень быстрые. Proxmox ставил. Все как то не быстро там с репликацией (как я понимаю из-за схемы на основе ZFS).

Почему вариант с drbd это велосипед? Вы реально хотите сказать что drbd полный шлак и не имеет права на жизнь? Или чисто так свое мнение считаете за истину и т.д. и т.п.? Пока не вижу аргументов и реальных доводов.

И с каких это пор схема с drbd это «самописное решение»?)) Оно мало где юзается?

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

Люди дело говорят, используй CEPH. Без него основная трабла будет отсутствие нормального fencing-a и постоянные локи на обоих сторонах сетевого зеркала по любому чиху. Если бы сам попробовал drbd на полигоне, то уже это знал бы.

anonymous ()
Ответ на: комментарий от astrave

Если нет СХД, то Ceph может тебя спасти от потери данных.

Старенькие серверы сетапить без zfs, использовать кластеризацию Proxmox и его же Live migration + Shared Storage типа Ceph.

Вариант с DRBD – это велосипед, так как ты сам собрался делать его реализацию, а не пользуешься готовым проверенным решением. Поправь меня, если я ошибаюсь.

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

да в том то и дело что тестил и сейчас тестирую drbd. sda+sdb->md0->drbd0->xfs /kvm/*.qcow2 проблем пока не заметил и меня смущает ваш негатив в сторону этого. А вот про цефс я слышал очень много историй про неторопливость и полную недееспособность для виртуальных машин.

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

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

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

Ты готовишь Proxmox неправильно.

Для кворума количество нод Proxmox >= 3.

Никакой «репликации», а общее хранилище + ha.

Почитай уже доки, блин!

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

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

Готовься ловить split brain и циклические перезагрузки.

Репликация в Proxmox не для горячей миграции, а для холодной. Когда у тебя HA виртуалки настроено на работу в группе нод А, а реплицируешься ты в группу нод Б и на другое хранилище. Чтобы в случае гибели группы нод А ты бы запустился с минимальными потерями и простоем на группе нод Б. И бэкапы никто не отменял, да.

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

sda+sdb->md0->drbd0->xfs /kvm/*.qcow2

Нужно больше слоёв

тестил и сейчас тестирую drbd

проблем пока не заметил и меня смущает ваш негатив в сторону этого

Ну, вот так.

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

То есть, твой ничем не подкреплённый негатив в сторону Ceph тебя не смущает, а мой в сторону DRBD – смущает, аж «кушать не можешь»?

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

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

Ладно. Просто тогда попрошу вас расписать наиболее подходящую схему организации.

Имеется 2 сервера, на каждом по 2x4 ядра LGA1366 и 32ГБ оперативки. Дисковая система их RAID 4xSAS 15k rpm.

Нужно чтобы на этом была заведена KVM виртуализация с репликацией виртуалки в формате qcow2 с ноды 1 на ноду 2. HA не нужен. Нужно чтобы в случае выхода из строя ноды 1, можно было запустить эти же вирты на ноде 2 (данные на ней были СВЕЖИЕ). На виртах будут psql, asterisk, почта.

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

Есть несколько серверов на стареньких LGA1366, один на не очень мощных LGA2011 и один на (ВНИМАНИЕ!) на LGA771

У тебя же типа есть железо, не?

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

HA не нужен

данные на ней были СВЕЖИЕ

Shared storage или x/0.

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

типа да, но филиала ДВА. и нужно это по ним раскидать. Получается по 2 ноды. Про это не говорил, т.к. это не важно. Вопрос получается крутится вокруг «2 ноды и между ними реплика» Канал между ними примерно 15мбит. Так что считай они изолированы.

Один сервер с двумя LGA771, один с двумя E5-2620 и 2 сервера на 2 x LGA 1366. На всех серверах по 32ГБ оперативки.

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

Proxmox HA, кстати, тоже требует нормального fencing-а. Если HA не нужен, а требуется только быстрое ручное переключение VM между 2 KVM нодами, то можно сделать так. 2 ноды Ceph OSD + 1 нода MON (можно даже локальной VM), и 2 ноды KVM/libvirt. Всё. Минимализм Ceph будет даже плюсом. Отсутствие локов dlm. Минус только, что qcow2 на rbd не положишь, только raw, но зато с trim, sparse и снэпшотами. Попробуй на полигоне, понравится. Ну, да, Ceph настраивается немного посложнее Drbd, но он того стоит.

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

2 ноды Ceph OSD + 1 нода MON (можно даже локальной VM), и 2 ноды KVM/libvirt.

Анон, пожалуйста, подробнее распиши.

И как тут кворум у Цефа должен сходиться?

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

2 OSD они же MON + 1 чисто MON, кворум 2 из 3 MON. Нормально работает на 1 Гигабите, но супер-скорость мне и не нужна была.

15 Мегабит/сек? т.е. 1,5 Мегабайта в сек? Ну, с этого и надо было начинать. Для Ceph мало. Здесь уже конечно сложно что-то посоветовать, кроме велосипедов.

anonymous ()
Ответ на: комментарий от dhameoelin

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

astrave ()
Ответ на: комментарий от dhameoelin

а еще такой вопрос. Я вижу что вы знаете эту тему и пытаетесь помочь. Вы писали что буду ловить split-brain. Да, такое слышал про drbd. Но я так же видел инфу, что это только когда обе ноды примари. У меня будет примари-секандари… то есть HA строить не буду. В этом случае разве так же есть риск split-brain? Ведь реплика идет только в одну сторону и ничего «встретиться» не может.

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

Зависит от того как будет производиться проверка доступности. В любом случае надо будет настраивать stonith, иначе split-brain точно словишь. Про цеф не слушай, товарищи видимо разворачивали его только в песочнице. Особенно дятла, который предлагает size2 делать.

jewelry ()
Ответ на: комментарий от turtle_bazon

И почему думаете, что существующие решения не обладают недостатками?

ок, каким недостатком обладает mysqldump ?

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

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

DALDON ★★★★★ ()
12 июля 2021 г.
Ответ на: комментарий от astrave

для баз данных в частности.

«Для баз данных в частности», а точнее для СУБД в вашем случае, файловая система это не всё, по этой причине использование методов F5 в nc для СУБД не применимы.

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

А что это?

Не прикидывайтесь что не знаете, что такое norton commander :)

anc ★★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.