В настоящее время у меня есть уровень RAID 1 из 2 жестких дисков емкостью 500 ГБ. RAID управляется сервером 1, а диски находятся на 2 разных серверах.
RAID работает отлично, как только я его настроил, однако в случайные моменты соединение, кажется, обрывается, и mdadm отмечает его как неисправный, и хотя я использую nbd-client с параметром -persist; mdadm отказывается считать диск хорошим. Единственный способ вернуть этот отключенный диск обратно в массив RAID - это:
mdadm -r / dev / md0 / dev / nbd1
mdadm -a / dev / md0 / dev / nbd1
Моя проблема в том, что это вызывает ПОЛНОЕ СИНХРОНИЗАЦИЯ 500 ГБ по сети.
У меня к этой проблеме 2 вопроса:
Есть ли способ сказать mdadm не выполнять полную повторную синхронизацию, потому что он завершает повторную синхронизацию перед отключением, поэтому я не вижу веских причин для выполнения ПОЛНОЙ повторной синхронизации?
Было бы лучше использовать rsync, потому что все, что мне нужно, это просто резервная копия всех данных, которые я пишу / удаляю? Я предлагаю это, потому что rsync, предположительно, передает только дельта (или измененные) данные, а не то, что, по-видимому, делает mdadm.
Вау, я давно не слышал, чтобы кто-нибудь использовал NBD.
Вы рассматривали возможность использования DRBD вместо?
Это функции включать автоматическое восстановление после сбоев сети и дифференциальную ресинхронизацию.
А еще лучше, это идет основная линия!
Хотя я бы никогда в здравом уме не подумал о создании сетевого RAID 1 через NBD, и я большой поклонник DRBD для всего, что связано с «хранилищем высокой доступности», в вашем вопросе есть один момент, который применим к другим ситуациям с mdadm. Ты сказал:
Есть ли способ сказать mdadm не выполнять полную повторную синхронизацию
Да, есть. Проверьте mdadm(8) для «растрового изображения с намерением записи» - в основном, это способ для mdadm запоминать, какие блоки синхронизированы, и повторно синхронизировать только те, о которых он не знает, что они обновлены. В вашей ситуации я бы все равно использовал DRBD, но для больших локальных RAID-массивов он может также очень помочь после сбоя.
Поддерживаю предложение использовать DRBD, потому что это именно тот сценарий, для которого он был разработан. Вы также получаете возможность маскировать ошибки локального диска - если локальный диск выходит из строя, DRBD может обслуживать блоки с удаленного диска, так что, насколько известно ОС, он все еще имеет полностью функциональный диск.
DRBD также имеет необходимую инфраструктуру для управления отказоустойчивостью и согласованностью способами, превосходящими использование простого программного решения RAID.
Я собираюсь предложить что-нибудь кроме DRBD ... и это GlusterFS. У него есть целый набор различных механизмов хранения, вы можете имитировать RAID на нескольких блочных устройствах, распределяя их по ним, зеркалируя или имея структуру массива, подобную RAID-5.
Вы также можете делать классные вещи, например, шифрование. Единственным недостатком является то, что он основан на FUSE, но в последних ядрах RHEL / CentOS это нормально. Это нормально и для Ubuntu / Debian.
(Я не работаю с gluster, но использую его в некоторых крупномасштабных инсталляциях, и это чертовски хорошая сетевая файловая система.)
Да, RAID - неправильная технология для использования в этом сценарии. Вы хотите либо использовать rsync, либо изучить некоторые разрабатываемые распределенные файловые системы.