Состоялся (https://www.mail-archive.com/lustre-announce@lists.lust...) релиз кластерной файловой системы Lustre 2.10.1 (http://lustre.org/), используемой в большей части крупнейших (http://top500.org) Linux-кластеров, содержащих десятки тысяч узлов. Масштабируемость на столь крупных системах достигается благодаря многокомпонентной архитектуре. Ключевыми компонентами Lustre являются серверы обработки и хранения метаданных (MDS, MDT), управляющие серверы (MGT, MGS), серверы хранения объектов (OSS), серверы размещения объектов (OST, поддерживается работа поверх ext4 и ZFS) и клиенты (код клиента входит в состав штатного ядра Linux).
В новой версии добавлена (http://wiki.lustre.org/Lustre_2.10.1_Changelog) поддержка использования дистрибутива RHEL 7.4 для серверных и клиентских компонентов Lustre, а также поддержка Ubuntu 16.04 и RHEL 6.9 для клиентских компонентов. Код ZFS обновлён до выпуска ZFS on Linux 0.7.1. В клиентских компонентах добавлена поддержка ядра Linux 4.9. Предоставлена возможность сборки сервера для ldiskfs на базе штатного ядра Linux (для работы квот по-прежнему требуется наложение патчей). Добавлена поддержка MOFED 4.1 (https://github.com/Mellanox/dpdk-dev-mlnx-ofed-kernel) (Mellanox OpenFabrics Enterprise Distribution (http://www.mellanox.com/page/products_dyn?product_family=26)).
URL: https://www.mail-archive.com/lustre-announce@lists.lust...
Новость: http://www.opennet.ru/opennews/art.shtml?num=47333
Дайте пример использования. Желательно не анекдотичный.
Только анекдотичные есть: google, dell emc storages(lustre+ext2, сам в этом немного участвовал)
> google ...навряд ли, у них своих, более лучших, поделий достаточно.
>> google ...
> навряд ли, у них своих, более лучших, подeлий достаточно.это и есть их свое более лучшее подeлие. И используют они его - с 2000х годов. То есть как написали, так и используют.
Ты, наверное, что-то путаешь.Lustre просто непригодна для использования в больних датацентрах т.к. это довольно топорная ФС и у неё нет крайне важных функций: избыточность хранением данных в географически разнесённых хранилищах и автоматическая репликация. Так, по крайней мере, было минимум лет 10 и какое-то время назад обещали сделать простое избыточное хранение на уровне ФС, но судя по описаниям архитектуры, их всё ещё нет.
Надёжность и доступность данных в Lustre обеспечивается SAN, RAID'амим и прочими костылями. В компаниях врде гугла на больших кластерах не используют SAN, а вместо этого поднимают специальный софт на куче обычных хостов (см. https://en.wikipedia.org/wiki/Commodity_computing).
В общем, в гугле для этого использовали google file system (https://en.wikipedia.org/wiki/Google_File_System) и она совсем не похожа на Lustre. С тех пор они наделали ещё много чего.
> dell emc storages(lustre+ext2, сам в этом немного участвовал)а можно подробностей - как участвовал, чего пилил, чего в результате получилось?
А то с гугля (они, кстати, тоже изначально делали на ext2, и, судя по тому что по сей день что-то в ней допиливают, часть нод так на ней и осталась) толку хрен, они очень не любят делиться внутренними подробностями.
люстра + ext2 это что-то новое ;-)Лана было с ext3 - но очень давно.. а вот ext2..
не было у гугля никакой ext3, разьве что где-то в побочных проектах - они, похоже, с самого начала поняли, что оно мертворожденное.
гугль развивал в качестве подложки под люстру свой форк ext2, пока не объявил что переходит на 4 w/o journal. Но, судя по некоторым признакам (включая вылезающие на свет патчи), по сей день не перешел окончательно (или вообще без шума и пыли отменил переход).pdf с анонсом того перехода и сравнительным анализом характеристик, вероятно, ищущий еще может найти. Год примерно 2010-11, читать осторожно, поскольку сравнивается не-мэйнстримная ext2 с ext4 восьмилетней давности.
видимо, emc его читать не стала, и продолжила все ту же тему - но вот они информацией официально не делятся, поэтому очень интересно было бы услышать что-то от инсайдера.
в истории люстры был момент когда она жила на ext3+большая стопка патчей (в районе 1.4). Потом эти патчи влили в kernel.org и появилось ext4. C тех пор так и живет.
Вот 500 примеров https://www.top500.org/lists/2017/06/
С учетом того, что это специализированная ФС для определенных задач, то вам в помощь почти любой HPC кластер.
Если Вы подумыввете использовать для себя, то не советую. Скорее всего она используется из-за того, что не так много альтернатив. Эти системы, мне кажется, сделаны чтобы можно было побольше выставить счет за эти системы. Например, она похоже что чувствительна к сбоям и т.п. Дизайн 80-90-х годов.
Если нужна реально масштабируемая система, то рекомендую Ceph. И попробовать обойтись без CephFS (это удобно, но не для designed for failure систем)
Чот ты фигню порешь, брат анон.
Тебе рассказать, с какой частотой у тебя будут выходить узлы сети хранения (а люстра, это фс, с помощью которой строят сети хранения для HPC кластеров из топ500), если их там больше 100? Ну вот чисто на бумажке прикинуть вероятности. Так вот люстра умеет выживать (и спасать данные) в очень неординарных случаях. Например, когда у тебя в меланоксовском IB-свитче, сдыхает ребро к которому были подключены несколько oss. А у тебя только суммарное IO проседает, но работа продолжает кипеть. Ты звонишь инженерам в дц (или сам идёшь), перетыкаешь oss'ы на свободные порты. Проверяешь, что IB поднялся, рестартуешь сервис lustre-oss на отвалившихся oss и через некоторое время получаешь те же цифры в суммарном IO, что были до сбоя. По-моему, отличная сетевая ФС. Лучше я не видел.
Если не секрет, какая у неё скорость на копировании больших файлов? Те один тазик умеет 250мб в сек, сколько выдадут 100 тазиков с люстре?
Один OST умеет 8Gbyte/s раздавать на 16 клиентов, дальше уперлись в SAS / IB / PCIe.
подскажите реально получить такую скорость на CephFS ?
Зависит, конечно. Но как выше посоветовали - лучше попробовать обойтись без CephFS.
что зависит то? повторю вопрос -
вот на люстре IOR запущеный на 16 клиентах - дает 8-9 Gbyte/s с одной OSS ноды - упираясь в IB / SAS.
Реально получить такую скорость Ceph с posix namespace ?
Ах да, за одно - можно ли создавать на Ceph - порядка 20000-30000 файлов в секунду?
При теоритическом пределе в 100к create/s
У меня устаревшая на примерно полтора года информация, но в таком случае использования Ceph что-то дурное чудил с датами создания файлов. Осиливал, но чудил.
Как сейчас — не знаю, отошли от Ceph.