есть ли у кого-нибудь опыт использования DRBD (протокол C) для синхронизации частей хранилищ данных двух хостов esxi для аварийного восстановления выбранных гостей?
У меня есть 2-3 гостя, которые должны иметь возможность восстановиться после аппаратного сбоя хоста за минимально возможное время, но все же с ручным вмешательством и без потери слишком большого количества данных.
Я бы хотел построить что-то вроде этого:
По 1 виртуальной машине DRBD на каждом из 2 хостов esxi, синхронизирующих свое локальное хранилище SAS (первичное / вторичное, активное / пассивное).
Это зеркальное хранилище должно быть подключено только к 1 хосту esxi одновременно через ISCSI или NFS и использоваться гостями для синхронизации виртуальных машин vmdks со вторым, «пассивным» хостом esxi. В случае аппаратного сбоя второй хост esxi должен затем подключить хранилище DRBD для включения этих виртуальных машин (конечно, вручную).
Я нашел некоторую информацию об этом в сети, но я не нашел никакой информации для согласованности vmdks.
Хотя это, конечно, не означает замену резервных копий, инструменты резервного копирования для гипервизоров обычно перед созданием моментального снимка или резервной копии обеспечивают стабилизацию файловых систем и баз данных гостей.
Однако с такой непрерывной синхронизацией это было бы невозможно. Вот почему мне интересно, стоит ли это вообще делать.
Что делать, если сами виртуальные машины VMDK повреждены из-за того, что аппаратный сбой произошел в неподходящее время Я знаю, что DRBD отбрасывает незавершенные записи, но достаточно ли этого, чтобы иметь согласованный (что означает «работающий» с точки зрения esxi, за исключением согласованности гостевой файловой системы, которая, конечно, не может быть гарантирована таким образом) vmdk?
Я надеюсь, что в случае сбоя гость, подключенный ко второму esxi, может вести себя так, как будто виртуальная машина просто некорректно завершила работу (со всеми возможными недостатками, которые обычно могут иметь место в других сценариях), но действительно ли это было кейс? Не могли ли повредить виртуальные машины в целом?
Большое спасибо за чтение и ваши мысли.
Максимум
Я провел обширные тесты со сценариями, как вы описываете. Я попытался создать сервер хранения с возможностью аварийного переключения с помощью DRBD, а затем с помощью iSCSI подключить это хранилище к машинам Debian, на которых запущен Xen. Я быстро отказался от этого, потому что у меня было слишком много проблем. Однако частью этого мог быть я. Один из них заключался в том, что Блочные устройства iSCSI не были созданы.
Затем я попытался создать две машины Debian Xen и реплицировать блочные устройства LVM, на которых находятся виртуальные машины, с помощью DRBD. я имел ошибки барьера файловой системы преодолеть.
Тогда моя производительность была плохой, что я отследил до al-extents параметры. В используемой мной версии DRBD, 8.3, было слишком низкое значение по умолчанию. Я увеличил его до 3833, так как меня не особо заботит немного большее время ресинхронизации.
Я также провел множество экспериментов с убийственной мощностью узлов. DRBD поступил с этим очень изящно. ВМ действительно отреагировала так, как вы надеетесь: перевод ее в режим онлайн на другом узле прошел нормально, просто сказав, что она восстанавливает свой журнал. Перезапуск узла также явно повторно синхронизировал устройство. Конечно, реальный отказ узла часто бывает неприятным из-за полуработающих дисков, сетевого трафика и т. Д., Что трудно предсказать. Вы умны, чтобы сделать раба только вручную.
Я занимаюсь настройкой около 2 лет. Узел еще не отказал :), как и DRBD.
В своих тестах я обнаружил, что гораздо удобнее не иметь центрального сервера хранения с аварийным переключением, а запускать Xen как на первичном, так и на вторичном DRBD. Я бы хотел попробовать еще раз настройку iSCSI, но этого не произойдет в ближайшее время.
Кроме того, я работаю не с файлами изображений, а с блочными устройствами LVM. Для меня это оказалось более надежным. Снэпшоттинг на LVM возможен, например.
Следует отметить одну забавную вещь: DRBD имеет режим, который позволяет ему работать без диска на основном узле. Однажды у меня произошел сбой диска на моем основном узле Xen, который остался незамеченным (ядро MD не запускало диск, но у меня были постоянные ошибки ATA). В течение нескольких недель без моего ведома виртуальная машина нормально работала в бездисковом режиме, используя другой сервер в качестве хранилища :)