Я ищу распределенную, отказоустойчивую сетевую систему хранения данных, которая предоставляет клиентам блочные устройства (а не файловые системы).
Так что в идеале архитектура была бы очень похожа на moosefs (http://www.moosefs.org/), но вместо того, чтобы показывать реальную файловую систему, смонтированную с использованием клиента плавкого предохранителя, он открывает блочные устройства на клиентах.
Я знаю iscsi и drbd, но оба, похоже, не предлагают то, что я ищу. Или я что-то упускаю?
Исходя из вышеуказанных требований, Ceph может быть то, что вам нужно. http://ceph.newdream.net/
Ceph предоставляет распределенную файловую систему, совместимую с POSIX, которую вы можете смонтировать как блочное устройство, используя Блочное устройство радос. Это реализовано непосредственно в современных ядрах Linux (2.6.37+).
Есть даже Драйвер хранилища Qemu / KVM Это означает, что вы можете монтировать файловые системы Ceph как диск виртуальной машины.
Крупная хостинговая компания Dreamhost ( http://dreamhost.com/ ) полагается на Ceph.
Первое, что я хотел бы сказать, это то, что вам, возможно, придется пересмотреть свои ожидания относительно сложности. Только тема вашего вопроса включает:
Каждый из них по отдельности обычно является темой как минимум средней сложности. Объединив все три из них, вы не добьетесь этого без небольшой работы.
Я думаю, что вам не хватает чего-то, что может реально удовлетворить все ваши требования и при этом быть простым или легким. Некоторые из ваших требований очень сложно реализовать вместе, если они не полностью противоречат друг другу. По отдельности можно выполнить без особых трудностей, но сложить их все вместе - вот где сложно.
Я собираюсь рассмотреть каждое из требований и дать комментарии:
Блочное устройство клиента должно одновременно писать в несколько узлов хранения.
Этого можно добиться, используя резервное хранилище под капотом. Избыточность может быть достигнута на уровне «узла хранения», используя избыточное локальное хранилище (RAID и т.п.), или на сетевом уровне путем дублирования данных на несколько узлов.
Блочное устройство клиента не должно выходить из строя, пока не вышли из строя все поддерживающие его узлы хранения.
Наряду с предыдущим, это легко достигается за счет резервирования хранилища. Эта часть потребует, чтобы хранилище было реализовано в конфигурации типа «сетевой RAID1».
Мастер должен автоматически перераспределять данные хранилищ, когда узел хранения выходит из строя или добавляется / удаляется.
Здесь все становится труднее. Вы конкретно заявили, что хотите экспортировать блочное устройство. Это значительно усложняет эту функцию на задней панели и, если вы не реплицируете все блочное устройство. С блочным устройством функциональные возможности на стороне сервера не могут просматривать файл и дублировать блоки, составляющие этот файл, как это было бы, когда он представляет интерфейс файловой системы. Это оставляет на стороне сервера либо обработку всего блочного устройства в целом, и необходимость реплицировать каждый блок целиком в одно отдельное место, либо она должна реализовывать много причудливого интеллекта, чтобы получить хорошую надежность, согласованность и производительность. . Сейчас очень немногие системы реализуют что-то подобное.
Один мастер (только для метаданных) подойдет
По идее, это работает намного лучше, когда вы имеете дело с фрагментами файлов из файловой системы, чем с блочными устройствами. Большинство систем, реализующих нечто подобное, делают это либо с интерфейсом файловой системы, либо с интерфейсом псевдофайловой системы.
Обычно вы принимаете решение. Вы получаете удаленное хранилище в виде файловой системы, и в этом случае вы получаете доступ к высокоуровневому интерфейсу и позволяете стороне хранилища принимать решения и обрабатывать низкоуровневые детали за вас, или вы получаете хранилище как блокировать устройство, в этом случае вы берете на себя ответственность за эти функции, или, по крайней мере, большинство из них. Вы получаете хранилище на более низком уровне, и вам остается больше работы для реализации этих низкоуровневых функций (распределенных, отказоустойчивых и т. Д.).
Кроме того, вам необходимо помнить, что, как правило, отказоустойчивость и высокая производительность являются противоположными сторонами одного и того же спектра с данным набором оборудования. Увеличивая избыточность, вы снижаете производительность. Самый простой пример - у вас 4 диска. Вы можете разделить все 4 из них в массиве RAID0 для максимальной производительности, или вы можете продублировать одни и те же данные 4 раза на всех дисках. Первый даст вам максимальную производительность, второй - максимальную избыточность. Между ними есть различные компромиссы, такие как 4-дисковый RAID5 или, по моему личному предпочтению, 4-дисковый RAID10.
Если бы я собирал что-то, отвечающее вашим требованиям, я бы, вероятно, экспортировал все диски с iSCSI или ATA Over Ethernet (AoE) и использовал программный RAID MD или зеркалирование LVM (или их комбинацию), чтобы получить уровень избыточности. Мне было нужно.
Да, есть некоторая ручная работа по настройке и обслуживанию, но это дает вам точный контроль над вещами для достижения необходимого уровня отказоустойчивости и производительности. DRBD - еще один вариант, который может в него вписаться, но если вы собираетесь иметь дело с более чем парой «узлов хранения», я бы, вероятно, отказался от него.
Обновить: Вышесказанное предполагает, что вы хотите создать собственное решение. Если у вас достаточно большой бюджет, вы можете купить решение SAN / NAS, которое, вероятно, не будет именно как вы описали выше, его можно рассматривать как черный ящик с такими же грубыми функциями.
Вы описываете SAN. Если вы хотите создать его самостоятельно, вы, вероятно, сможете, но я не могу вам помочь, кроме как направить вас в сторону ZFS. Если вы в конечном итоге купите один у поставщика хранилища, вы захотите изменить то, как вы его описываете. Вот разбивка того, о чем вы просите:
Я бы добавил в ваш список, если бы знал больше о вашей среде, но это поможет вам начать.