gluster на мелких файлах тормозной. Точнее, в моей ситуации был диагноз - очень тормозной. Lustre чуть пошустрее, но итог тот же - тормозной.
Стоит смотреть в сторону hdfs, mongodb/gridfs, riak... В общем, какой-либо распределенный nosql
Или, вариант, писать своё: много небольших серверов, скриптик, который положит файл на нужные сервера, в зависимости от каких-то параметров и, ну, скажем, nginx который спроксирует запрос на нужный сервер.
В таком случае я вижу вариант разделить хранилище на множество мелких томов, и монтировать их "рядом", для клиентов все это будет видится как большой том, но возникнет проблема по умному раскладыванию новых файлов, так чтобы и структура каталогов помимо собственного смысла, имела еще и смысл по раскладыванию. А что именно тормозило с Gluster? Он же вроде умеет кучу всего за счет фильтров, в том числе создавать реплики и балансировать запросы?
А как же Lustre в кластерах используют? Вообще, я ожидаю от распределенной файловой системы производительность бОльшей, чем от локальной файловой системы, минус издержки на сеть и обслугу. Если у меня файл лежит на трех хостах, то наверно, за счет чтения с трех хостов одновременно (в идеале), должно получаться быстрее, чем локально, хотя бы не медленне. Особенно при многопользовательском доступе.
С Gluster тормозило чтение мелких файлов. Когда данные не много больше метаданных. Да и сами по себе способы доступа к файлам - fuse по определению тормозной, а nfs, по моему скромному мнению, прошлый век.
" я ожидаю от распределенной файловой системы производительность бОльшей, чем от локальной файловой системы" -- справедливо, когда количество клиентов не больше количества серверов. В этом случае всё-равно что использовать.
по Gluster получается относительно большие транзакционные издержки на один файл, потому и тормозило? Тогда понятно, если файл больше - КПД вырастет. Дальше надо мерять насколько...
При тюнинге NFS и сети и ядра - при шаринге стораджа с виртуальными машинами на несколько ESX, в виртуалке удавалось донести скорость почти сравнимую с локальным диском. Это по мнению пузомерки в W7/Vista. Хотя, если запустить несколько таких машин одновременно - слабенький сторадж не справлялся. То есть NFS сам по себе при правильной готовке способен дать виртуальной машине хороший дисковый сервис, за счет кеширования и отложенной записи, даже в чем-то веселее, чем локальный диск.
Спасибо за мысль, будем стремиться к уравниванию клиентов и серверов, в среднем это даст баланс. Есть ли смысл тестировать Lustre/Gluster? Или совсем безнадежно?
В простейшем виде это одна (!) тушка с 2мя 24 дисковыми полками. 2х42 ТБ, если делать raid6 из 2ТБ дисков. Расширение - 4ТБ диски на подходе. А там хоть слона делайте поверх. 7 гигабит на полку, вроде. Само собой, тушку хорошо бэкапить на вторую такую же.
Если же клиентов много - то и NFS, и SMB будут плохим выбором, неважно что там под ними валяется. Если NFS последний ещё как-то можно рассматривать, то smb точно раскорячится.
"10-20 клиентов могут одновременно произвольно запрашивать файлы из хранилища." как показала практика в похожей ситуации - использовались два ящика coraid с зеркалированием с помощью drbd (это не я придумал так). то такая конструкция выдает большие задержки по I/O. то есть одна дисковая полка проблему скорее всего не решит, нужно разделять. но вот как? или есть волшебные варианты и все решит? Клиентов 10-20 вряд ли больше, виндовых из них меньшинство, сколько точно сказать не могу - не знаю. Так что если для виндовых клиентов за счет SMB будет чуть/особо медленнее - это не критично.
drdb достаточно тормоз. У меня такая тушка стоит, в пике на ней человек 40 работало по SMB. Вторая приходит и неторопливо делает rsync с flock. Правда, у меня там файло сильно больше и с синхронизацией вам придется придумывать что-то посложнее.
Полка с правильно потюненным XFS задержек в I/O больших создать не должна. В вашем случае очень и очень внимательно нужно отнестись к ФС, потому как ей от 40 ТБ мелких файлов станет плохо.
Ну и собственно вопрос - а какой latency приемлем?
вот и я думаю по rsync копии делать и от глюков ФС более застрахован, и тормозов меньше, изменения небольшие в системе. с XFS вроде как с навигацией по каталогам задержки возникают уже на 20ТБ, но там по 100 элементов каталоге. удаление очень медленно.
Вот в цифрах сказать не могу, но суть процесса такая, чем меньше задержка между запрашиваемыми файлами, тем лучше для задачи в целом - общая производительность. Но это не realtime обработка.
Кстати, есть смысл глянуть на pohmelfs2 + elliptics. Там логика работы сильно далекая от классических DFS, оно скорее nosql-storage, который транслируется в posix-совместимую FS.
Оно бы в вашем случае идеально подошло, вот только про стабильность её мне известно достаточно мало. Знаю, что оно очень тупило на заливке зеркала одного из дистрибутивов в себя, при том прекрасно прожевав до этого зеркала ещё пары-тройки десятков дистрибутивов.
Elliptics уже валяется в паблике, pohmelfs2-сорцы нужно поискать.
Comments 29
Посмотри на Amazon S3. Бюджет-то ты не озвучил.
Reply
Reply
Reply
но он не open source, хотя free
Reply
Lustre чуть пошустрее, но итог тот же - тормозной.
Стоит смотреть в сторону hdfs, mongodb/gridfs, riak... В общем, какой-либо распределенный nosql
Или, вариант, писать своё: много небольших серверов, скриптик, который положит файл на нужные сервера, в зависимости от каких-то параметров и, ну, скажем, nginx который спроксирует запрос на нужный сервер.
Reply
А что именно тормозило с Gluster? Он же вроде умеет кучу всего за счет фильтров, в том числе создавать реплики и балансировать запросы?
А как же Lustre в кластерах используют? Вообще, я ожидаю от распределенной файловой системы производительность бОльшей, чем от локальной файловой системы, минус издержки на сеть и обслугу.
Если у меня файл лежит на трех хостах, то наверно, за счет чтения с трех хостов одновременно (в идеале), должно получаться быстрее, чем локально, хотя бы не медленне. Особенно при многопользовательском доступе.
Reply
" я ожидаю от распределенной файловой системы производительность бОльшей, чем от локальной файловой системы" -- справедливо, когда количество клиентов не больше количества серверов. В этом случае всё-равно что использовать.
Reply
При тюнинге NFS и сети и ядра - при шаринге стораджа с виртуальными машинами на несколько ESX, в виртуалке удавалось донести скорость почти сравнимую с локальным диском. Это по мнению пузомерки в W7/Vista. Хотя, если запустить несколько таких машин одновременно - слабенький сторадж не справлялся. То есть NFS сам по себе при правильной готовке способен дать виртуальной машине хороший дисковый сервис, за счет кеширования и отложенной записи, даже в чем-то веселее, чем локальный диск.
Спасибо за мысль, будем стремиться к уравниванию клиентов и серверов, в среднем это даст баланс.
Есть ли смысл тестировать Lustre/Gluster? Или совсем безнадежно?
Reply
Вы ничего не сказали о количестве клиентов.
В простейшем виде это одна (!) тушка с 2мя 24 дисковыми полками. 2х42 ТБ, если делать raid6 из 2ТБ дисков. Расширение - 4ТБ диски на подходе. А там хоть слона делайте поверх. 7 гигабит на полку, вроде.
Само собой, тушку хорошо бэкапить на вторую такую же.
Если же клиентов много - то и NFS, и SMB будут плохим выбором, неважно что там под ними валяется. Если NFS последний ещё как-то можно рассматривать, то smb точно раскорячится.
Reply
как показала практика в похожей ситуации - использовались два ящика coraid с зеркалированием с помощью drbd (это не я придумал так).
то такая конструкция выдает большие задержки по I/O.
то есть одна дисковая полка проблему скорее всего не решит, нужно разделять. но вот как? или есть волшебные варианты и все решит?
Клиентов 10-20 вряд ли больше, виндовых из них меньшинство, сколько точно сказать не могу - не знаю. Так что если для виндовых клиентов за счет SMB будет чуть/особо медленнее - это не критично.
Reply
У меня такая тушка стоит, в пике на ней человек 40 работало по SMB. Вторая приходит и неторопливо делает rsync с flock. Правда, у меня там файло сильно больше и с синхронизацией вам придется придумывать что-то посложнее.
Полка с правильно потюненным XFS задержек в I/O больших создать не должна. В вашем случае очень и очень внимательно нужно отнестись к ФС, потому как ей от 40 ТБ мелких файлов станет плохо.
Ну и собственно вопрос - а какой latency приемлем?
Reply
с XFS вроде как с навигацией по каталогам задержки возникают уже на 20ТБ, но там по 100 элементов каталоге.
удаление очень медленно.
Вот в цифрах сказать не могу, но суть процесса такая, чем меньше задержка между запрашиваемыми файлами, тем лучше для задачи в целом - общая производительность. Но это не realtime обработка.
Reply
Там логика работы сильно далекая от классических DFS, оно скорее nosql-storage, который транслируется в posix-совместимую FS.
Оно бы в вашем случае идеально подошло, вот только про стабильность её мне известно достаточно мало. Знаю, что оно очень тупило на заливке зеркала одного из дистрибутивов в себя, при том прекрасно прожевав до этого зеркала ещё пары-тройки десятков дистрибутивов.
Elliptics уже валяется в паблике, pohmelfs2-сорцы нужно поискать.
Reply
Вроде слышал, что ее Яндекс активно использует.
Спасибо, посмотрю еще раз и по-внимательнее.
Reply
В яндексе используют, но далеко не везде.
Моё мнение - попробовать можно.
Reply
Reply
Reply
Leave a comment