Как стать автором
Обновить

Комментарии 18

Как читающий узнаёт о том, на каком сервере хранятся данные?
Информация, на каком сервере лежит файл, хранится с метаданными файла. Клиент, будь то NFS или HTTP будет перенаправлен на соответствующий сервер.
Спасибо. Упадёт ли вся ФС в случае падения сервера с метаданными? Не является ли сервер метаданных узким местом в производительности при работе с множеством мелких файлов?

Ещё интересует следующее: допустим мы выбрали узел, на который писать, пишем на него большой файл и вдруг место на нём заканчивается. Можно ли продолжить запись оставшихся данных на другие узлы?
Сервер метаданных является центральным компонентом и вся ФС зависит от него. На практике, мы используем репликацию базы, что позволяет поднять резервный за секунды.

dCache не разбивает файлы на блоки, и в случае переполнения сервера запись на него будет блокирована. Что-бы такая ситуация не возникала, для сервера данных есть понятие gap. Это минимальное количество дискового пространства которое должно быть у сервера, что-бы его рассматривать как возможный кандидат.
У dCache немного не такая структура, как вы ее себе представляете.
На сервере метаданных самих метаданных нет. У него все их только спрашивают. А сама информация хранится в postgresql базе данных. На сервере метаданных живет только кэш последних запросов в памяти.

У нас не очень нагруженная система (в день где-то 10 миллионов запросов к базе, не только метаданных). Из которых 54% SELECT и 30% — начало/конец транзакций. В пике 3000 запросов в секунду.

Запросы, в среднем, обрабатываются меньше чем за 0,037 секунды (верхняя граница самых «тяжелых» запросов).
Так что база узким местом не является. Сами файлы передаются дольше.
Когда она падает — неприятно. Но мы собрали HA кластер и это перестало быть бедой.
А о какой версии dCache речь?

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

www.dcache.org/manuals/Book-2./Book-fhs.shtml#cf-pm-classic
Ого! Рад видеть на Хабре человека использующего dCache.

Начиная с версии 2.2 в dCache добавлен тип раздела 'waas'. Механизм, описанный здесь, сильно упрощён, что-бы не пугать :). Полное описание алгоритма можно найти здесь.

А у вас какая версия dCache-а стоит и где (если не секрет).
У нас как раз 2.2. По исходникам суть остается именно такой: dCache смотрит только на вес пула по свободному месту (если используется партишен с такой системой выбора пулов для записи), что может привести к проблемам описанным выше.
А это только опасение? Вроде, те кто используют 'waas' довольны. Начиная с версии 2.7 классический вариант вообще не существует :).
Это не опасения. Мы раньше использовали схему с приоритетом доступного места(правда classic partition, без случайностей, просто лучший пул) и получали замечательный результат: на нас записывают болк данных, а потом 1000 клиентов этот блок начинают забирать (да, данные весьма специфичные). И все, 1000 потоков, скорость 100 мегабайт в час (на сети 1GB/s и данные 2Gb). Те пул фактически блокировался. И быть лучшим на запись, по идее быть не должен.
Со случайным выбором пула «не хуже чем», возможно тоже самое. Для трансфера может выбираться перегруженный клиентами пулл. По этому мы пожертвовали симметричностью заполненности в пользу симметричности загрузки.

2.7 еще далеко. Поскольку у нас требуется безотказная работа хранилища в режиме 24/7/365, мы используем только golden release. А на 2.6 перебраться пока нет возможности. по тем же причинам.
Мы тоже начали использовать dCache на 0.15 петабайт на нашем вычислительном кластере, пока что в тестовом режиме.
А через что клиенты забирают файлы? NFS?
Да, только NFS. Пока всё идёт хорошо, правда один раз система перестала видеть один из узлов до его перезагрузки, но надеемся, что такого больше не произойдёт. Пользователей мало, в основном запускаем тесты.

(это ответ Silvar'у, промахнулся веткой)
А с реплицированием не заморачивались? Это позволит сделать дублирование данных на уровне dCache и выход из строя пулов не будет влиять на жизнеспособность системы в целом (пока свободное место есть).

Не занимались ли вы сравнением NFS-dCache и чистого NFS, в плане производительности (iozone, например)? Очень интересно было бы сравнить производительность.
У нас узким местом оказалась сеть между узлами. Сейчас ждём infiniband-оборудование, чтобы сделать сеть быстрее.

Результаты тестирования IOR'ом. тут.
Проблему сети решит так же реплицирование: если клиентов много, то в качестве источника файла будут выбираться разные узлы.

А тестирование скорости интересовало в контексте сравнения с чистым NFS при равных условиях (у себя, к сожалению, мы такой тест провести не в состоянии из-за режим работы dCache).
Можно использовать опцию -+n для iozone, что-бы избежать перезаписи.
Infiniband говорите. Это для pool-to-pool? У нас у самих такие мысли проскальзывают. Будет интересен ваш опыт. Может добавим как RDMA как 'родной' метод для общения между компонентами.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории