bcache на md или md на bcache

bcache позволяет одному или нескольким быстрым дискам, таким как твердотельные накопители на флэш-памяти (SSD), выступать в качестве кэша для одного или нескольких медленных жестких дисков .

Если я правильно понимаю,

SSD ^* может быть назначен для кэширования нескольких резервных жестких дисков, а затем получающиеся в результате кэшированные устройства могут быть подключены с помощью mdadm
или
несколько жестких дисков могут быть подключены к одному устройству резервного копирования md, а SSD назначен для

Мне интересно, какой разумный подход. Мне приходит в голову, что рост RAID5 / 6 может быть проще с той или иной техникой, но я не уверен, какой!

Существуют ли веские причины (например, расширение резервного хранилища или что-то еще) для выбора одного подхода вместо другого (для большой некорневой файловой системы, содержащей файлы поддержки ВМ)?

_{^* под «SSD» я имею в виду какое-то избыточное устройство SSD, например RAID1 из двух физических SSD}

В любом случае все диски, bcacheдля которых сохранены резервные копии, должны быть отформатированы, bcacheпоэтому вам придется либо создать mdмассив, либо отформатировать единственный результирующий диск целиком как bcacheрезервный раздел, связать его с диском кеша и перейти оттуда или отформатировать многие с дисками bcache, свяжите их с их диском кэша, затем отформатируйте много дисков как один массив. В любом случае есть несколько точек возможного сбоя, все из которых зависят от совместимости между двумя файловыми системами - не говоря уже о финальном fs. смотрите здесь : прокрутите вниз .

— mikeserv

Благодаря github.com/g2p/blocks вы можете конвертировать его на месте, хотя для этого есть некоторые ограничения.

— Адам Рычковски,

@mikeserv Я все это понимаю, это специально построенный сервер, так что все хорошо. Что вы имеете в виду "две файловые системы"? bcache не является файловой системой - единственной файловой системой, которую я буду иметь, будет XFS на конечном устройстве bcache или mdadm (в зависимости от того, какой вариант я выберу).

Спасибо @Adam, конвертация на месте для меня не проблема.

@mikeserv нет, это не так. Файловые системы (например, btrfs, xfs, extN и т. Д.) Живут поверх блочных устройств. mdadm и bcache работают на уровне блочных устройств, а не на уровне файловой системы (btrfs путает проблему с нарушением наслоения, но это совершенно отдельный разговор).

Ответы:

Я думаю, что кэширование всего устройства md имеет смысл.

Использование bcache для кэширования всего устройства md жертвует всей идеей использования raid, потому что оно вводит еще одну единственную точку отказа.

Отказы OTH SSD-дисков встречаются относительно редко, и bcache можно перевести в режим writethrough/ writearound(в отличие от writebackрежима), где нет данных, хранящихся только на устройстве кэш-памяти, и сбой кеша не уничтожает информацию в рейд делает его относительно безопасным вариантом.
Другим фактом является то, что существует значительная вычислительная нагрузка программного RAID-5; при кэшировании каждого члена вращающегося рейда отдельно, компьютер все равно должен пересчитать все паритеты, даже при попадании в кеш
Очевидно, вы бы пожертвовали дорогостоящим пространством ssd, если бы вы кэшировали каждый вращающийся диск отдельно. - Если вы не планируете использовать рейдируемый ssd-кеш.
Оба варианта относительно не влияют на время нарастания процесса - хотя вариант с вращением дисков, кэшируемых отдельно, потенциально может быть медленнее из-за увеличения трафика шины.

Это быстрый и относительно простой процесс настройки bcache для удаления диска ssd, когда вам нужно его заменить. Благодаря блокам можно было перенести настройку рейда в обе стороны на месте.

Вы также должны помнить, что в настоящее время большинство (все?) Дистрибутивов live-CD не поддерживаютbcache , поэтому вы не можете просто получить доступ к своим данным с помощью таких инструментов независимо от выбранной вами опции bcache- mdraidlayout.

— Адам Рычковски
источник

Я обновил вопрос, чтобы было ясно, что я не планирую иметь резервный SSD-кеш. Ваше второе замечание является отличным, спасибо за это. Вы третий пункт о космосе: вы имеете в виду, потому что вы будете хранить паритет на SSD? Ваш последний пункт, я использую F20, но в конечном итоге буду использовать RHEL / CentOS7 или Debian Jessie (если bcache-tools сделает это).

@JackDouglas Объявление 3-й пули: Да, именно это. Но так как вы планируете использовать рейдированные диски SSD, это не относится к вам.

— Адам Рычковски,

Это все еще происходит, потому что они будут не только зеркально отражены, но и должны будут хранить четность RAID для резервных дисков. Это не тот случай, если RAID сделан ниже bcache, который, как я думал, был вашей

Полагаю, вы имеете в виду обратное: матрица ssd не должна хранить четность вращающихся дисков, если она запитана всем диском mdraid.

— Адам Рычковски,

да, это именно то, что я имею в виду!

Я думаю, что здравый подход заключается в кэшировании полученного MD-устройства.

bcache предназначен для последовательного чтения и записи.

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

В то время как том MD с кэшем будет выглядеть как обычно, запись файлов на том, а не случайные блоки на несколько устройств.

Весь смысл аппаратного и программного рейда состоит в том, чтобы чередовать данные в бэкэнде так, чтобы полученная файловая система выглядела как обычный том.

Это может быть неверно (поскольку разработчики bcache могут быть хитрыми и учитывать такую ситуацию), но оптимальным логическим решением является кэширование томов, а не блокирование устройств.

— enlightnd
источник

тоже очень хороший момент

Большая последовательная запись в RAID5 / 6 производит последовательную запись на все компоненты устройства. Каждый компонент устройства получает каждый блок данных N-1 (или четность), но данные, которые он получает, являются последовательными. Но вы правы, что это будет искажать вещи. Если есть некоторые чанки, которые видят частые записи с частичной полосой, что приводит к чтению-модификации-записи (части) полосы четности, это может быть кэшировано bcache. Кэширование выше, до того, как запись с частичной полосой попадет на устройство MD, было бы еще лучше.

— Питер Кордес