Как объеденить 20 Пбайт в один раздел?

В голову пришел LVM, но насчет таких объемов - хз.

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

Если не секрет скажи где используется такие объемы? Сколько думал так и не смог представить зачем оно нужно.

Вроде где-то читал, что можно его поверх сети, но не уверен. Скорее всего нет. Да, я зря его вспомнил.

Если не секрет скажи где используется такие объемы? Сколько думал так и не смог представить зачем оно нужно.

Хостинг?

Недостачно я думал...

мат. биология, rainbow таблицы.

Даа, точно, вот именно хостингом Евгений и фарцует.

20 Пбайт

Это ж откуда столько о_О
я в своей москводеревне терабайт-то только пару раз в жизни видел (в использовании, а не на витринах)

GlusterFS попробуйте или Ceph.

LVM разве не в пределах одной машины?

NBD в теории, но не думаю, что то, что нужно.

Нужно объединение через сеть.

pohmelfs же)

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

Проект С-тау фабрики в Новосибирске. Физика высоких энергий.

В пике J/psi при достаточно разумной светимости частота полезных событий 300 кГц при размере события примерно 30 кБайт, то есть 1 Тбайт набирается примерно за 100 секунд.

pohmelfs же)

Один из вариантов, но скорее при таких объёмах будет проще открыть TCP/IP соединение к конкретной машине и качать через него. Информацию что/где лежит брать в БД.

то есть 1 Тбайт набирается примерно за 100 секунд.

Эмм, а что за каналы у вас используются, чтобы сливать 10Гбайт/с?

У нас пока ничего не используется, потому что только проект. Предполагается 1 Тбит в секунду.

GlusterFS?

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

ах да, Lustre же!

Вам наконец-то выделили финансирование?

Нет. Это ФЦП на составления ТЗ для составления ТЗ по компьютерной инфраструктуре. Как-то так.

Пока я вижу три варианта

а) просто независимый набор дисковых серверов по которым раскидываются файлы. Информация о том, куда скидывается, сохраняется в БД и доступ просто по TCP/IP

б) Lustre

в) SciDB

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

б) Lustre довольно успешно используется, в частности, на «Ломоносове».

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

Ну да. Нормальная распределённая ФС на самом деле особо не нужна. Нужно что-то относительно простое.

б) Lustre довольно успешно используется, в частности, на «Ломоносове».

Это безусловно говорит в её пользу. Кстати, вопрос: на Lustre возможен ли прямой доступ к файлу, то есть операция seek?

а) а если сделать децентрализовано наподобие того же freenet ?

Нет особой необходимости. В любом случае надо будет заводить БД на тему где какой файл лежит. Там же можно хранить всю необходимую информацию о состоянии физических хранилищ.

тогда резко возрастает траффик между клиентами. а тут и так есть чему загружать сеть обмена.

Да, можно делать seek.

А как насчет международного опыта? Тот же CERN, перед ними подобных проблем не стоит? Это вопрос не только по объединению хранилищ, но и по записи и хранению событий.

http://wiki.lustre.org/index.php/Main_Page

http://en.wikipedia.org/wiki/Lustre_(file_system)

за подробностями можно на gentoo@conference.gentoo.ru, а то мне не охота передатчиком быть.

А как насчет международного опыта? Тот же CERN, перед ними подобных проблем не стоит? Это вопрос не только по объединению хранилищ, но и по записи и хранению событий.

Да есть у них решение LCG называется. У них де факто реализован пункт а) Но в ЦЕРН задача изначально была гораздо сложнее — они заложились на распределённые вычислительные мощности, что мы не потянем ни при каких раскладах + сейчас всё необходимое можно собрать в одном месте.

если что на gentoo@conference.gentoo.ru будет возможность поговорить с людьми админящими и работающими на кластере в ПИЯФе.

Спасибо. Но отчёт мне нужно сегодня за ночь написать :)

Если дадут деньги на составление самого ТЗ, то видимо придётся разговаривать.

Ну и просто счётному кластеру не нужна большая файловая система. Как правило до примерно 0.1 Пбайта рулит NFS3, а вот дальше приходится думать.

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

Было бы интересно. Ещё пару часов я смогу не спать :)

Ну да. Нормальная распределённая ФС на самом деле особо не нужна. Нужно что-то относительно простое.

Предлагаю велосипед: LVM поверх iSCSI.

20 Пбайт, ну скажем по 100 Тбайт массивы: получаем 200 клиентов. Не взлетит. Вот InfiniBand взлетит, но он и стоит как самолёт.

Добавить иерархию, объединить массивы первого уровня по двадцать штук и анонсировать уже группы по 10Пбайт?

NFS не взлетит на 10 Пбайт. В любом случае придётся что-то вроде Люстры сажать. Ни в случае введение иерархии появляется лишнее слабое звено.

s/10/1/ естественно

Зачем NFS? То же iSCSI: чем проще на этом уровне, нем надёжнее. Ну и слабое звено в любом случае появится.

сервера майкрософт скайдрайв же )

Ну и как будет происходить копирование файла? Ведь всегда через корень.

Ну да. Какие конкретно к этому есть претензии, помимо «Вы самое слабое звено»? Настройки у такого велосипеда меняться будут редко, можно держать аналогичный дублирующий корень, всё равно на нём ничего важного не хранится, работает только фронтендом.

http://www.almaden.ibm.com/StorageSystems/projects/gpfs/

Два копирования вместо одного. Сначала с ноды нижнего уровня, на ноду верхнего и только потом это получает клиент. Ну и скорость iSCSI не превышает 10 Гбит (при двойном копировании в два раза режется), а при многопользовательском доступе всё просто ложится. Хочется 1 Тбит.

Еще есть яндексовский похмелфс. А точнее, ихний eblob. Файловая система - условность, по большому счету.

Насчет оптимизации на запись не в курсе, лучше автора спрашивать. В яндексе явно на чтение перекос.

(при двойном копировании в два раза режется)

Два порта на средней ноде спасут отца русской демократии или торг здесь неуместен?

при многопользовательском доступе всё просто ложится.

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

Тогда не совсем понятно, осилит ли этот источник дорогу на терабитию. Или источников не один? Тогда не совсем понятно обязательно требование свести всё в одну ФС.

Два порта на средней ноде спасут отца русской демократии или торг здесь неуместен?

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

Да, с чтением тут будет туго, согласен. Тогда да, единственное не велосипедное решение - нормальная распределённка.

Вот нечто сочинил: http://www.inp.nsk.su/~baldin/pic/storagesystem.pdf Предварительная версия (несколько кусков просто скопировал — надо будет переписать).

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