Кластерная файловая система Lustre снова публично доступна.

green **** (Score: 482 MaxScore: 482) (*) (16.11.2005 21:39:41)
Проверено: green (*) 16.11.2005 21:53:42
Создано: green.

Правда?

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

"Звуки хорошие"! :)

А нафига это надо?

Если файлы не делить, надеюсь что нет, то в чем смысл и выигрышь?

Ну подмонтируй разные разделы в одном а это зачем?

>Если файлы не делить, надеюсь что нет, то в чем смысл и выигрышь?

Во всех кластерных системах файлы хранятся вразбивку (striped) на всех серверах. Помимо этого метаданные хранятся на выделенном сервере.

Вопрос только, чем Luster так уж существенно отличается от pvfs1/2? Или от MosixFS?

Люстра рулит?

светит :))

Lustre скалится до достаточно больших размеров кластера практически линейно (io-wise). А pvfs? А MosixFS?

Цитата с http://www.pvfs.org/pvfs2/

Clusters need a parallel file system that can scale as the number of nodes increases to the thousands and tens of thousands. PVFS2 is our answer.

Любопытно было бы взглянуть на цифры.

В lustre есть возможность хранить метаданные тоже на нескольких метадата серверах (их количество наверно ограничено только скалабилити). Но эта фича еще не в продакшн качестве, хотя супер тесты от HP проходит без проблем.

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

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

(2) что произойдет если наприемр 1000 клиентских нодов будет модифицировать один и тот же файл терабайтного размера? Если они это переживут, то как быстро это будет работать?

(3) как у них с acl, xattrs, mmap, security?

(4) как у них с производительностью? Например с create rate чтобы далеко не ходить?

добавлю еще кое что пока не забыл, дабы было что пообсуждать :)

(5) backend FS на серверах в принципе может быть любой. Добавить поддержку новой FS занимает разумное количество времени. Например поддержку tmpfs я добавил за 5 полных дней пару лет назад, при том что тогда я о lustre знал не так много. Ясно что поддержка reiser4 займет больше времени, но не сильно :)

(6) существуют например кеширующие сервера. Благо архитектура позволяет творить и не такие вещи.

Ну, вот - стоило только вылезти с маленьким вопросом, как тут же в ответ целую кучу накидали ;)

>>>(1) как у них с рековери? Что произойдет с приложением которое например активно создает файлы в директории или чтото пишет, когда произойдет обрыв соединения или наприемр завалится один из серверов?

(2) что произойдет если наприемр 1000 клиентских нодов будет модифицировать один и тот же файл терабайтного размера? Если они это переживут, то как быстро это будет работать?

(3) как у них с acl, xattrs, mmap, security? <<<

1-2 насколько я понимаю взаимосвязаны (?). Т.е. как вы stripes раскидали по узлам - так оно и будет. Если "внахлест", то какую-то часть узлов можно безболезненно вывести из строя. Если файл размазан достаточно "тонким" слоем по узлам, то тем большее число клиентов могут его использовать. В этом смысле pvfs, на мой взгляд ,более гибкая, чем Люстра (прошу прощения за фамильярность). По крайней мере MPICH (параллельная библиотека) предлагает API, позволяющее ручками задавать распределение stripes по узлам. В Люстре, насколько я понял, это еще только в проекте - т.е. алгоритм жестко задается драйвером.

3 у pvfs никак. Униксовые плоские permissions. Security (ИМХО) на вычислительных кластерах вещь не особенно нужная. Кластер - он как кащеева смерть - чужой фиг доберется.

MOSIX - отстой, в своё время долго пытались с ним работать, всё время что-то виснет и глючит. А файловая система там так, для галочки - это не кластерная файловая система.

PVFS1 - страшный тормоз ! Если много мелких файлов, то проще повеситься. Сервер метаданных иногда падает. А еще он хардлинков не понимает ;)

PVFS2 - кривая пока, рушится под нагрузкой.

Только на люстру и надежда. Год назад еще по ней облизывался...

О! Я вспомнил про pvfs, это нам про нее походу рассказывали как ее сравнивали с люстрой типа скорость открытия файлов, причем pvfs через mpi api, а люстру через legacy (ну неиу пока у люстры его пока, но будет, кто-то уже занялся этим, вроде).

Далее по 1-2 - А pvfs подерживает stripes "внахлест", так что данные для одного кусочка хранятся сразу на двух разных storage (эдакий raid1)? (сразу скажу что люстра так неумеет пока (в продакшен версии)).

stripes в люстре можно задавать юзерспейсовой тулзой per-directory или при создании файла через ioctl.

> Далее по 1-2 - А pvfs подерживает stripes "внахлест", так что данные для одного кусочка хранятся сразу на двух разных storage (эдакий raid1)? (сразу скажу что люстра так неумеет пока (в продакшен версии)).

Это только PVFS 2 - он пока кривой как сама смерть.

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

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

(2) имелось ввиду след:
- будет ли терабайтный файл коректным на всех нодах, то есть как там у них с кешированием? Как с кеш-инвалидацией? На чем она построена? Если один нод зачитал какую то часть файла, а другой модифицировал, то первый должен выбросить только те странички файла из pagecache которые модифицировались.

- насколько он их правильно выбрасывает? Перебирать все странички из терабайтного файла не совсем правильно. Будет ли нод доступен во время кеш-инвалидации? Если нет, то легко организовать чтото типа "отказ в обслуживании"

- чтото у них ничего не сказано об каком либо подобии distributed locking manager. Или у них его нету? Если нету то... все плохо.

(3) ну не скажи :) бывает нужно. Криптование, капабилити например или еще что... типа пускать только определенных клиентов в кластер.

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