Новое слово в хранении данных - BLOCK-RAID

Я довольно давно вынашивал эту идею и довольно странно, что она никем еще не реализована.

Как многие знают, при очень большом числе дисков в массиве - 12/24/48 или даже 96 стандартные режимы работы RAID (к ним я отношу 0/1/10/5/6) уже категорически неприменимы, ибо даже самый надежный RAID-6 дает совершенно неадекватные цифры по уровню надежности.

Разумеется, можно использовать совмещенные режимы, когда, например, RAID-0 собирается поверх нескольких RAID-6. Это немного улучшает ситуацию, но для кейсов 48/96 дисков по-прежнему не особо приятно себя ведет.

Кроме этого, очень мало реальных данных, которые будут эффективно разбросаны по 24м дискам (кейс RAID-6). Какой объем нужно записывать в среднем, чтобы он был разбросан по аж 24м дискам? Нереальный, согласитесь. А если писать на каждый диск по байту - тоже получится весьма и весьма печальная ситуация.

Кроме этого, редкий RAID даст собрать, скажем, 24х дисковый RAID-10 (тот же LSI ограничен 16ю дисками).

Намного более хорошая ситуация у нас с ZFS. Там есть режимы RAIDZ-1/2/3 которые в свою очередь являются аналогами RAID-5 (выдерживает отказ 1го диска) / RAID-6 (выдерживает отказ 2х дисков), а RAID-Z3 аналогов вовсе не имеет! Зато переживает отказ аж 3х любых дисков в массиве!

Но даже ZFS в чистом при большом числе дисков не панацея. Но если сделать, скажем ZFS stripe поверх десятка RAID-Z3, то можно достигнуть очень крутого уровня надежности и емкости!

Но если речь идет о хранении очень больших файлов, то самый гибкий вариант, который приходит в голову - это разбить файл на блоки и разбросать по N (2 и более) разным логическим устройствам!

Таким образом, мы сможем читать файл параллельно из двух мест (например, осуществляя выборку четных/нечетных блоков с разных дисков), но при записи придется писать на два устройства, что может привести к задержкам, так как скорость записи будет ограничена скоростью дисковых устройств.

Такой режим распределения данных используется в распределенном хранилище-mapdreduce кластере HADOOP (а также его реализации HDFS).

Но с учетом увеличения объемов локальных стораджей он вполне может быть использован и на локальных машинах и весьма успешно.

Конечно, такой режим приводит к 2-3х кратной потере места, но дает очень высокий уровень гибкости и полной независимости от числа дисков в массиве.

Но стоит отметить, что для случая механических дисков все не так очевидно - этот вариант будет точно очень плох для SATA и даже SAS. Но вот для SSD, когда скорости одного диска хватает почти любому приложению (а вот надежности - нет), будет просто идеален.

Стоит отметить, что такой режим можно легко реализовать с помощью Linux Device Mapper или же того же ZFS, с помощью использования опции copies:

copies=1 | 2 | 3
Controls the number of copies of data stored for this dataset. These copies are in addition to any redundancy provided by the pool, for example, mirroring or RAID-Z. The copies are stored on different disks, if possible. The space used by multiple copies is charged to the associated file and dataset, changing the used property and counting against quotas and reservations. Changing this property only affects newly-written data. Therefore, set this property at file system creation time by using the -o copies=N option.

Разве что стоит обратить внимание, что ZFS не умеет "жесткой" гарантии на размещение таких данных на разных дисках. Она лишь пытается, но не гарантирует.

Также стоит отметить потрясающий уровень гибкости такого решения.

1. Мы можем на лету добавлять диски, сколько угодно и никакого полного копирования данных.
2. Мы можем свободно удалять диск из системы не заменяя его ни на что при наличии свободного места на другом массиве - все данные перетекут на свободное место
3. Мы можем собирать массивы из разных по скорости дисков и при выделении нового volume указывать, что "разместить на пуле с SSD".
4. Мы можем постоянно двигать блоки с диска на диск (например, как раз в случае потребности в более высокой скорости). Причем, это может осуществляться динамически (сама система переносит их на более быстрый сторадж)!
5.  При таком подходе даже теряя 3+ дисков, на которых размещен раздел мы теряем лишь  разделы, размещенные лишь на этом диске! Но других разделов это не касается!

Пункт 5 на самом деле очень и очень важный потому что в классических RAID (что программных, что аппаратных) потеря дисков больше чем допустима для соотвествующего уровня RAID - фатальна, а для BLOCK RAID - это можно пережить - повредятся лишь затронутые данные! Это крайне актуально особенно в случае хранения нескольких тысяч терабайт данных. Безусловно, потеря 1/100 этих данных будет крайне неприятна, но это в миллион раз менее неприятно и фатально, чем потеря ВСЕГО массива!

Добрые люди подсказали, что по похожей схеме устроен Google File System: https://ru.wikipedia.org/wiki/Google_File_System