Debian RAID10 vs RAID0 + 2xRAID1 vs LVM + 2xRAID1

на основании личного опыта

Я обычно иду по пути наименьшего сопротивления и собираю raid10. В процессе использования меня отмирающие диски. Именно на практике это вариант для ленивых.

с учётом требований к возможностям расширения

Так как рейд я собираю не на весь диск, а сначала создаю на нём раздел, который уже добавляю в рейд, расширяю по мере того, как постепенно заменю все диски в рейде на больший размер. В случае с домашним NAS это легко, там всего четыре диска, можно разом заменить. В случае с сервером, где у меня десять дисков в raid10, пока что объём не увеличил. Возможно, имеет смыл в такой конфигурации собрать несколько рейдов и увеличивать их по очереди. Это для случая, если ты хочешь вставить в комп диски большего размера.

На сервере поверх raid10 держу lvm, так как там на хосте ничего нет - 100500 виртуалок, для каждой виртуалки свой lvm-том.

Производительность не замерял. Надёжность на уровне - так, чтобы вылетело несколько дисков одновременно, у меня не было ни разу. Замена одного диска производится на лету без проблем.

я знаю про существование raid0+1, его плюсы и минусы - данный вариант к данной теме не относится.

Тем не менее точню, что плюсы у него отсутствуют.

Как лучше это сделать?

Из твоего - raid10, всё остальное это придумывание костылей на ровном месте. Но с учётом пожеланий:

в будущем может появиться необходимость расширить массив путём добавления ещё нескольких дисков (суммарно их всегда будет чётное количество);
вероятно, имеющиеся диски будут постепенно заменены на HDD большего объёма и понадобится расширить доступный объём в RAID10;

порекомендую подумать над вариантом «два raid1 тома, данные раскидываются между ними на уровне файловой системы/приложения».

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

Такой же план и у меня ;D

Правда, пока не разобрался, как именно происходит такое расширение. Можешь направить на нужные ресурсы или здесь расписать, как расширить RAID10 после замены всех дисков без потери данных? Есть, конечно, вариант создать новые разделы на дисках и банально добавить их в массив, но звучит несколько муторно для большого количества дисков.

Когда заменишь все диски на большие, по одному пересоздай разделы в сторону увеличения и потом mdadm --grow. Подробности в man mdadm. Каких-то специальных ресурсов не знаю. Я чаще всего по манам делаю. :) Тут как бы не особо сложная архитектура, чтобы искать спецстатьи.

Муторно, да. Но если хочется на живую, то только так. Если есть возможность переносить данные и пересоздать массив с нуля, конечно проще.

UPD: Но это всё-таки разовая операция. И ручной работы не особо много. Большую часть времени только ждать синхронизации.

Тем не менее точню, что плюсы у него отсутствуют.

Справедливо.

Из твоего - raid10, всё остальное это придумывание костылей на ровном месте.

Не изучал документацию настолько глубоко, но возможно ли создание «нетрадиционных» конфигураций RAID1+0 с помощью mdadm raid10? Например, таких:

1. (RAID1 из трёх дисков) + (RAID1 из двух дисков) в RAID0;
2. (RAID1 из RAID0+диск+диск) + (RAID1 из трёх дисков) + (RAID1 из двух дисков) в RAID0.

И как можно гарантировать, что именно нужный порядок дисков будет использован при построении массива? Если верить https://serverfault.com/questions/723388/md-raid10-how-to-make-sure-that-replicated-data-is-stored-in-right-place, то единственный способ - создать вручную два RAID1, а из них RAID0.

После каждого пересоздания раздела массив будет пересобираться? Или при увеличении размера раздела и неизменности данных mdadm просто продолжает работать, а пересоберётся всё уже только при mdadm --grow?

Смотря насколько большие будут диски. Если это диски 8+ тб, забудь про mdadm и создавай lvm raid10. Зачем тебе сутками синхронизировать пустое место и с большой вероятностью ловить вылеты из рейда от незначительных сбоев?

Хотя если это на работе, то из принципа KIS можно попробовать mdadm. Но классический рейд все же для не слишком больших дисков

Диски достаточно большие, но KIS определённо в приоритете - нужно сделать так, чтобы при необходимости и вручную с микроскопом можно было данные по битам считать. Отсюда же необходимость знать однозначно, где какой блок данных будет лежать.

Про синхронизацию пустого места mdadm’ом и большую скорость синхронизации LVM не слышал - есть ссылки на материалы по этой теме?

Тебе нужно будет сначала по очереди вывести каждый диск из массива, расширить раздел, дождаться синхронизации. Т.е. если четыре диска, четыре раза ждать. Сам по себе --grow проходит относительно быстро и один раз.

Это если делать, как я, когда у тебя в массиве, условно, не /dev/sda, а /dev/sda1. Можно ли сделать быстрее и на весь диск сразу без разделов - не проверял. Я не так часто увеличиваю свои массивы. А рабочими занимаются специально обученные люди. Как делают они - не интересовался. Ну и там не mdadm, там своё.

Диски достаточно большие, но KIS определённо в приоритете

Все же пощупай lvm raid в виртуалке. Даже если не под эту задачу, рано или поздно пригодится

нужно сделать так, чтобы при необходимости и вручную с микроскопом можно было данные по битам считать

Тогда тем более lvm. у всех утилит есть ключ «-m», который покажет информацию по отдельным экстентам

У меня почему-то lvm raid выдавал много ошибок при вылете одного из дисков. Но это было давно и опыт может быть нерелевантным.

А, ты хочешь использовать такие конфигурации как промежуточные при наращивании дисков? Ну, если так, то вероятно и правда надо вручную это задавать. Но выглядит это как-то плохо по-моему.

Хотя данные в случае аварии ты конечно из таких дисков в итоге вытащишь, но это будет длинный простой. Если делать отдельные мирроры то их намного удобнее обслуживать отдельно друг от друга в контексте «плавно добавлять/увеличивать диски».

Вот, да. Я выше писал, что, возможно, удобнее будет создать несколько mdadm-рейдов, которые потом объединить с помощью lvm в один pv. Но надо смотреть подробнее по требованиям ко всей системе.

Спасибо!

Пощупать-то можно, но на практике применять - пока что сомнительное удовольствие (пробовал просто LVM, в том числе шифрованный - как-то не особо зашло). Тема старая, но, думаю, общий смысл ответов до сих пор актуален: https://unix.stackexchange.com/questions/150644/raiding-with-lvm-vs-mdraid-pros-and-cons. Благодарю за рекомендацию!

как промежуточные при наращивании дисков

Может, как промежуточные, а может, и как постоянные - зависит от состояния дисков.

Хотя данные в случае аварии ты конечно из таких дисков в итоге вытащишь, но это будет длинный простой.

Простои - как раз не проблема. Данные больно уж ценные, а используются они далеко не 24/7.

Если делать отдельные мирроры то их намного удобнее обслуживать

Согласен, но тогда теряется прирост скорости от RAID0, а HDD запилены под надёжность, скорость у них средненькая - хотелось бы побольше.

Данные больно уж ценные

Ценные данные бэкапят на бэкап сервер и оффсайт бэкап сервер. RAID это не про ценные данные, а именно про избавление от простоя хранилища.

А никто и не говорил, что оффсайт бэкапы отсутствуют ;D

Просто все бэкапы нужно где-то хранить, и делать это в RAID1-массиве куда надёжнее, чем на одном диске. Ну или RAID10 для большей производительности.

но возможно ли создание «нетрадиционных» конфигураций RAID1+0 с помощью mdadm raid10? Например, таких:
(RAID1 из трёх дисков) + (RAID1 из двух дисков) в RAID0;

Никакой «нетрадиционщины», это ваше личное дело сколько вы дисков будете включать в raid1, можете даже деградированный с одним диском сделать.

Если это диски 8+ тб, забудь про mdadm и создавай lvm raid10. Зачем тебе сутками синхронизировать пустое место

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

и с большой вероятностью ловить вылеты из рейда от незначительных сбоев?

А можно подробностей?

Но классический рейд все же для не слишком больших дисков

Ему побарабану до объемов и он тот самый KISS.

Данные больно уж ценные

raid не про сохранность данных, ценные данные надо бэкапить по принципу 3-2-1.

У меня с LVM RAID негативный опыт - на трех разных дистрибутивах он отказался при загрузке автоматически подымать зеркальный(raid1) том из двух дисков, если один из дисков отсутствует (в отличие от mdadm). Для меня это критично: большой жирный warning от отсутствующего диска в зеркале - это ОК, если при этом система сама подымается и работает. А выпадать в осадок и требовать ручного вмешательства там, где оно не надо - не ОК.

если объём дисков не очень большой (<2ТБ)б то спокойно можно сделать R5. выиграешь в объёме. только bitmap обязательно сделай. но для / это не очень решение.

если дисков в итоге планируется иметь сильно больше, то LVM - как раз тот случай когда он кстати. и да - он сам умеет в RAID.

технически ещё можно сделать относительно небольшой / тройным зеркалом и 4 диск запасным, а остальное большое место - под R5.

если добавлять не планируется, а только заменять на большее, то на большой диск можно переехать с небольшим перерывом на замену 1 диска (если горячая замена - то вообще без неё), далее остальные по очереди, в конце делаешь grow, а затем также увеличиваешь саму fs, команды для ext2/3/4 я не помню, online был сделан для неё ещё где-то в районе 2005 года. в остальных надо смотреть доку но тоже было такое.

можно / иметь отдельно на mdadm, а остальное - отдать под LVM

про R1, а особенно R10 - это очень спорно, а особенно в эпоху дисков боле 1 ТБ. никогда не видел как при схождении RAID по замене 1го диска отказывает другой?

дурью маешься. на деле если дисков 6 и более и они большие (2TB+) - можно смело R6 делать - так надёжнее нетрадиционных половых отношений с развалом RAID. как ни странно.

и да - mdadm умеет в R10 напрямую, нафига костыли?

И зачем, простите, такой бутерброд нужен? RAID внутри самого LVM подкупал возможностью создавать отдельные тома с заданным уровнем отказоустойчивости (хочешь отдельный том в RAID1 - не проблема. Хочешь рядом большой том, но без отказоустойчивости - окей).

А так у нас на современной системе мало того что с зеркалированием содержимого EFI раздела приходится без вариантов плясать(в Proxmox для этого даже понаписали отдельные удобные костыли), так еще и с корнем предлагается пердолиться?

Нет уж, спасибо. Где смог - я переехал на ZFS(и в нём я бы не отказался от возможности отдельно задавать отказоустойчивость для dataset, но эх - параметр copies это не то), где не смог - остался на чистом mdadm.

это не бутерброд, а управление рисками. mdadm+/ - очень надёжно работают вот уже много лет. но с управлением места у mdadm - не очень, он не для этого. вот там LVM и пригодится. а если что не так -то хотя бы / загрузится и дальше уже можно спокойно ковыряться.

У меня с LVM RAID негативный опыт - на трех разных дистрибутивах он отказался при загрузке автоматически подымать зеркальный(raid1) том из двух дисков, если один из дисков отсутствует (в отличие от mdadm).

activation_mode=degraded пробовал? В конфиге, и потом пересобрать initramfs

Пробовал, с корневой ФС это почему-то не сработало

Для очистки совести - /boot был вне lvm?

Да, отдельно