Ceph мы тоже любим. Он у нас в проде для S3 хранилища. И, кстати, он отлично справляется с миллионами как мелких, так и больших файлов. По Гластеру мы скорее набираем экспертизу, используем его под бэкапы и остальные не самые критичные вещи, поэтому с мелкими файлами не тестировал. В прошлом посте было об этом: habr.com/company/croccloudteam/blog/353666
Можно ссылочку про 64мб? И как скорость heal зависит от размера шарда? Есть какие-то наблюдения? Касательно надувания, у меня было около 15 тонких дисков с виртуальным размером 1тб, а реальным около 10гб. И после замены брика вижу:
Спасибо за вопросы:
1) XFS была выбрана, так как мы практически везде используем Centos 7, а она уже давно стала их дефолтной файловой системой. Так же RedHat во всех мануалах рекомендует именно ее. XFS мы, так же, давно используем в Ceph, и массовых проблем с развалом файлухи не наблюдаем. Да, бывало, что она сыпалась, причем даже не только в случае холодной перезагрузки, но в основном она нас полностью устраивает.
2) Я наблюдаю сейчас тенденции именно к использованию JBOD, а всю логику по репликации на себя берут уже SDS решения. Если у вас есть острая необходимость в повышении уровня надежности сохранности данных, вы можете собрать под Гластером зеркала, или RAID5, но это значительно увеличит стоимость вашего хранилища. Касательно производительномсти, тут ответ разный в зависимости от типа вольюма(тома). Для striped лучше куча дисков, так как данные ровными слоями пишутся на все брики одновременно. Для разных distributed с включенным шардингом производительность одного потока записи не изменится, но при нескольких потоках, общая производительность кластера будет выше. В остальных типах производительность не изменится.
3) Если речь идет о UUID, то пробовали, но уже после публикации статьи.
4) Вся документация, что мы читали, была на английском языке и так вышло, что к нам в обиход пришли слова в raw формате =) брик(brick), вольюм(volume) и тд.
На момент тестирования LTSкой была 3.10, на ней мы проводили большую часть тестирования, также мы пробовали стабильную версию от Red Hat (rhgs-3.3), но по сути разницы не было, основные проблемы со striped вольюмами оставались.
Да, пробовали, работает стабильно, но с ним слишком много ограничений. Например, максимальный размер файла = размер брика — уже занятое на нем пространство. В этом случае, конечно, должен помочь Sharding xlator, но мы пока мы его только тестируем и рано делать выводы
шарды нормального брика:
шарды курильщика:
1) XFS была выбрана, так как мы практически везде используем Centos 7, а она уже давно стала их дефолтной файловой системой. Так же RedHat во всех мануалах рекомендует именно ее. XFS мы, так же, давно используем в Ceph, и массовых проблем с развалом файлухи не наблюдаем. Да, бывало, что она сыпалась, причем даже не только в случае холодной перезагрузки, но в основном она нас полностью устраивает.
2) Я наблюдаю сейчас тенденции именно к использованию JBOD, а всю логику по репликации на себя берут уже SDS решения. Если у вас есть острая необходимость в повышении уровня надежности сохранности данных, вы можете собрать под Гластером зеркала, или RAID5, но это значительно увеличит стоимость вашего хранилища. Касательно производительномсти, тут ответ разный в зависимости от типа вольюма(тома). Для striped лучше куча дисков, так как данные ровными слоями пишутся на все брики одновременно. Для разных distributed с включенным шардингом производительность одного потока записи не изменится, но при нескольких потоках, общая производительность кластера будет выше. В остальных типах производительность не изменится.
3) Если речь идет о UUID, то пробовали, но уже после публикации статьи.
4) Вся документация, что мы читали, была на английском языке и так вышло, что к нам в обиход пришли слова в raw формате =) брик(brick), вольюм(volume) и тд.