Вышла GlusterFS-2.0

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

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

Скорость, удобство, надежность - выберете любые два.

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

Не проще/эффективнее нативные ФС пилить/допиливать?

(я тоже было смотрел давно в берклидб, но некрасивость 2 уровней перевесила).

Оракл и тот рекоммендует raw-partitions

Что скажете?
я без наезда, с уважением

>Оракл и тот рекоммендует raw-partitions

ocfs2 и статья про дешёвый RAC
btrfs опять же, но под винду конечно raw-partition

спасибо, я понимаю. но ехт4 тоже пользуется B-Tree (или улучшенной версией) - для индексации. Зачем класть ФС на ФС?
То что оракле втюхивает что-то - для меня не аргумент. Они много что втюхивали. Виртуализации, множество слоёв, делающих одно и то-же, виртуальные машины - поверх уже существующих ОС имеют место быть по разным причинам, но избыточны и _некрасивы_ по природе.
почему не делать то-же - на базе ехт4? НЕ хватает индексов, функциональности - добавить (но не городить следующий этаж).

Гластер поддерживает MPI-IO ? Поиск по их сайту даже такого ключевого слова не нашёл :)

Вот PVFS2 его поддерживает с мохнатых времён, в том числе в MVAPICH2

=))))))))))))))))

Терабайтный SAS за 200$. Самому не смешно? Посмотри сколько стоит SAS на 450 Gb чудик...

+)))) Почитай wiki, разберешься в вопросе.

Ну смотри, сломается у тебя 1 писюк этот, и что ты будешь делать? Будешь бегать по рынку искать комплектующие. А если все сломается числа 1-го?

> 9Т - это 6 дисков - будет работать под самым дешёвым писюком сегодня (и стоить меньше штуки: $900)

предполагается набирать по 5 ТБ каждый сеанс, всего их будет возможно 6-8, плюс столько же нужно сгенерить монте-карло, 100 ТБ даже в две писюки при всём желании не запихнуть (с учётом дублирования будет ещё больше)

> Гластер поддерживает MPI-IO ? Поиск по их сайту даже такого ключевого слова не нашёл :)

большинство обработчиков на просьбу выучить новый интерфейс доступа к файлам для того чтобы обрабатывать данные на полпроцента быстрее пошлёт куда подальше

месье может показать каким способом MPI-IO может помочь обойти ботлнеки в железе?

>большинство обработчиков на просьбу выучить новый интерфейс доступа к файлам для того чтобы обрабатывать данные на полпроцента быстрее пошлёт куда подальше

Какой такой "новый" ? :) MPI-2 уже больше 10 лет как стандарту :)


>месье может показать каким способом MPI-IO может помочь обойти ботлнеки в железе?


Мануал читать не пробовали ? http://www.sesp.cse.clrc.ac.uk/Publications/paraio/paraio/node54.html
http://www.sesp.cse.clrc.ac.uk/Publications/paraio/paraio/node55.html

PS: MPI-IO ПЕРЕНОСИМЫЙ интерфейс НАД FS specific API чтобы как раз не заниматься изучением новых API 

+ ещё одна ссылочка (в конце есть список кластерных FS для которых реализован MPI-IO) http://www.mhpcc.edu/training/workshop2/mpi_io/MAIN.html

ЗЫ: Собственно вопрос то возник в связи с упоминанием предыдущим оратором MPI и glusterfs. Я просто поинтересовался реализован уже MPI-IO для гластера или еще нет. Быстрый поиск не дал утвердительного ответа.

> большинство обработчиков на просьбу выучить новый интерфейс доступа к файлам для того чтобы обрабатывать данные на полпроцента быстрее пошлёт куда подальше

Это Вы MPI-IO называете пол-процентами?

> месье может показать каким способом MPI-IO может помочь обойти ботлнеки в железе?

Вот Вам пример - у нас приложение может записать файл со скоростью примерно 80GB/ (GPFS). Я вот не знаю железок, поддерживающих такую скорость записи.

> Какой такой "новый" ? :) MPI-2 уже больше 10 лет как стандарту :)

и переписать кучу библиотек которые про MPI-IO не знают в принципе...

> Collective IO operations can be useful when several processors need to write a single file.

такого у нас не бывает по определению

> The MPI-IO implementation may achieve extra efficiency through combining data into a few large (and contiguous) writes rather than many small ones.

буферизация это называется, если она отсутствует, то её можно добавить за 10 минут руками

я вообще-то про ограничение на скорость езернета или доступа к диску спрашивал

> Это Вы MPI-IO называете пол-процентами?

соглашусь на 0.75 :)))

> Вот Вам пример - у нас приложение может записать файл со скоростью примерно 80GB/ (GPFS). Я вот не знаю железок, поддерживающих такую скорость записи.

это sustained в теч нескольких часов или peak'овая скорость?

DDR3-1600, Peak transfer rate: 12800 MB/s

http://en.wikipedia.org/wiki/DDR3_SDRAM

откуда и чем у вас пишутся данные с такой скоростью?

если опять же имеется ввиду "Collective IO operations can be useful when several processors need to write a single file.", то это не интересует в принципе

Просветите, плиз,
почему нельзя поверх iSCSI использовать distributed софтверный stripping (RAID10 или подобный), ведь в линуксе кажется нет ограничения на количество дисков в софтверном рейде в ядре.
И не надо костылей в виде лод-балансирующего сервера, работающего на файловом уровне. Ведь iSCSI уже работает на блочном. Ведь именно поэтому iSCSI быстрее чем NFS. А стриппинг даст балансировку.
(можно сделать ещё уровни QoS - для разных клиентов/скоростей, и стриппить по-разному)

Я не врубаюсь в кластерную специфику?

Только после того, как увижу расшифровку аббревиатуры SAS...

в "поверх iSCSI использовать distributed софтверный stripping (RAID10 или подобный)" можно расширять хранилище (видимое как один большой диск) после создания RAID'а простым добавлением новых узлов/дисков?

кто будет заниматься локами при одновременном доступе к (мета)данным с разных хостов?

всё равно нужно ставить кластерную ФС, в вашем случае поверх распределённых блочных устройств (например GFS от RedHat), а уж насколько она будет лучше/хуже glusterfs и в каких случаях это уже другой вопрос

ОК, iSCSI+RAIDx+LVM (и можно добавлять//маунтить - сколько хочешь). Можно разные комбинации.

> кто будет заниматься локами при одновременном доступе к (мета)данным с разных хостов?

метаданные - иметь _отдельно_, в беркидб (но она не будет дёргаться когда нужно и не нужно) - только когда надо метаданные.
А так - обычные чтения - не будут идти через неё.

Это как локать всё на всякий случай - если некоторым аппликациям это надо.

для меня - юникс-вей - это составить систему из кирпичиков (под конкретную задачу), где кирпичики - это iSCSI, RAIDx, LVM, NFS, berkleyDB итд, а втискивание всё в одну трубу, с одним механизмом, да ещё и иметь уровень над уровнем - видоус-вей. Не?
(опять же - я не кластеровод, могу быть не в курсе каких деталей)

>iSCSI+RAIDx+LVM
AoE быстрее, но один фиг будут тормоза, LVM не сможет правильно распределить запись и чтение

кластерные системы могут работать на нескольких тысячах узлов, думается мне, что всякие lvm сдохнут

> а если берклидб поменяет внутренний формат в очередной раз? (сколько раз это уже делалось?)

Номинально они меняют чуть ли не каждый релиз, но изменения форматов собственно данных там не так часто. Меняют формат журналов, скажем - это не проблема. Форматы хеша и дерева давно уже не меняли, насколько я помню.

> диски на ВСЕХ узлах видны как единое хранилище

Какой максимальный размер одного файла допустим для файловой системы GlasterFS? Это очень существенно при монтаже фильмов.

Эта система прописывается в ядре или идет как дополнительный модуль? Интересен сам процесс ее установки.

пропускная способность связок на основе iSCSI и кластерных решений различается на порядки. В данном случае это будет скорость сетевого интерфейса (даже транкового). Уважаемый VIT привёл примерную скорость обращения _распределённого_ приложения к _распределённому_ хранилищу.

VIT привел пример суммарной скорости при нескольких (ОЧЕНЬ нескольких) клиентах, которые лезут в непересекающиеся узлы.

На отдельных клиентах скорость не будет выше скорости сетевого интерфейса, так что маркетинговый булшит оставьте тем, кому интересны сферические кластерные системы в вакууме.

Скорость на одного клиента в кластерной системе может быть ниже, чем iscsi/fc/aoe/nbd/you name it, когда запрашиваемые данные находятся на одном узле, а не могут быть прочитанны параллельно с нескольких узлов.

Вы не понимаете сути _параллельного_ приложения :) (там нет никаких отдельных "клиентов" c точки зрения приложения. Есть коммуникаторы, ранки, etc)

Собственно поэтому вам оно и кажется булшитом

суть интеграции кластерной фс со средой передачи (на примере MPI-IO) как раз и заключается в максимально возможной локализации данных

И опять же не нужно путать потоки данных в коммуникаторе (они могут быть какими угодно, p-to-p, p-to-all, all-to-all ) с операциями I/O которые априори медленней.

Обратите внимание, в вашем сообщении нет ровным счетом ничего по теме производительности :)

Это и называется маркетинговый булшит.

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

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

>Что же насчет разных методов доступа (mpi - это всего лишь более удобный интерфейс для каких-то задач. А для других будет posix. Всего-навсего), то для одного узла они всегда будут не быстрее чем скорость его соединения с кластером.

Речь идёт не о "каких-то" а именно об mpi задачах.

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

Еще какую глупость предложите ? :)

>Речь идёт не о "каких-то" а именно об mpi задачах.

Вообще-то, речь шла о производительности в сравнении с single-server/single-client соединениями как iscsi и т.п.

Интерфейс и API играют далеко не самую важную роль в этом.

А что касается производительности кластерных файловых систем - вот вы и подтвердили мысль о том, что каждый клиент по отдельности сливает любым другим сетевым системам, а отбивается это только их количеством и _только_ при возможности параллельного ввода-вывода, чтобы можно было заявлять о красивых гагабайтах в секунду, забывая добавить, что это при тысячах клиентов, задачи которых не пересекаются :)

>>Речь идёт не о "каких-то" а именно об mpi задачах.

> Вообще-то, речь шла о производительности в сравнении с single-server/single-client соединениями как iscsi и т.п.

Кто бы мог подумать :))

Какие нах "клиенты-серверы по отдельности" в HPC ?

Если вам с вашими задачами не нужны кластеры не нужно в них лезть.

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

PS: И не нужно приписывать мне ваши мысли. Я на кластерах РАБОТАЮ больше 10 лет а вы их похоже только во сне видели ;)