LINUX.ORG.RU
ФорумAdmin

распределенные файловые ситсемы, что есть?

 , , , ,


0

3

пробовал ceph и gluster. ceph с rbd map продолжает писать (вроде, хоть и подвисает вначале) когда нода фейлиться, что продолжает это +, но тут slow request'ы и не совсем очевидно почему оно периодически тормозит, зависимостей выявить не удалось. gluster проще ceph, но сразу перестаёт писать если нода зафейлилась, похоже он просто так устроен.

Что ещё есть из нормальных, что можно поставить и использовать без замут?

Чо уж там, хадуп. Будет чотко.

stave ★★★★★ ()

slow request'ы и не совсем очевидно почему оно периодически тормозит

Гайды профилировки достаточно подробно описывают что делать. Сеть 10Гб/сек ?

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

К сожалению нет, 1Гб/сек, не могли бы вы привести ссылку где описана эта рекомендация?

VoDD87 ()

похоже он просто так устроен

Похоже, нужно сначала почитать документацию. Например, о таймаутах.

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

Похоже, нужно сначала почитать документацию. Например, о таймаутах

приводите ссылку - почитаю.

VoDD87 ()
Ответ на: комментарий от post-factum

LMGTFY

Посмотрел, но это не относится к тому, что при выходе из строя ноды запись и чтение замирают на подмонтированный раздел замирают.

VoDD87 ()
Ответ на: комментарий от VoDD87

Ну вот расскажи мне детальнее, что к чему не относится, а я послушаю. Да так, чтобы конкретики поменьше: layout, опции, вот это вот всё — кому оно надо, правда?

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

Ну вот расскажи мне детальнее

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

VoDD87 ()
Ответ на: комментарий от VoDD87

http://docs.ceph.com/docs/jewel/start/hardware-recommendations/

Consider starting with a 10Gbps network in your racks.

Вариант LACP с двумя гигабитными сетевухами стоит рассматривать ТОЛЬКО если у тебя там кластер на поиграться без реальных данных.

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 3)
Ответ на: комментарий от Pinkbyte

Уважаемый Pinkbyte, скажите, опрашиваю ceph через nginx->radosgw при запросе на чтение данных, скажем файл на 100MiB ceph читает данные со всех OSD на которых лежат эти данные? У меня каждая копия данные хранится на 3х OSD (разные сервера) одновременно. И я вот думаю, когда идет запрос мы передаем в итоге 300MiB между нашими серверами, или ceph выбирает с какой OSD читать и читает только один раз эти 100MiB только с одной OSD?

Вообще где можно почитать про алгоритм работы ceph при чтении данных? А быть может мне нужно читать про алгоритм работы radosgw? На сколько я понимаю radosgw коннектитися к одному из мониторов и забирает данные через монитор, так что все же наверно про ceph.

Заранее, и еще раз - спасибо!

VoDD87 ()
Ответ на: комментарий от VoDD87

Я думаю начать чтение следует с официальной документации по архитектуре ceph. Картинки там достаточно наглядные. Если вкратце - мониторы рассказывают клиенту с каких OSD нужно забирать данные.

Не знаю как сейчас, но раньше чтение было только с primary osd(что такое primary osd рассказано в документации), которые выставлялось для каждой placement group через CRUSH

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)

Не использовать ФС, а использовать key-value хранилища.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.