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