Соответствующая сетевая файловая система для больших (5+ Гб) файлов
У меня есть несколько серверов, используемых для HPC / кластерных вычислений, и я заметил, что, учитывая тот факт, что часть выполняемых ими вычислений использует огромные файлы по NFS, это вызывает значительные узкие места. Мне интересно, как решить проблему.
Настройка:
- 34 сервера с Debian Squeeze (42 ГБ ОЗУ каждый)
- 12 физических ядер на машину + HT
- 2 "головные" машины (head1 и head2) с дисками по 500 Гбайт каждая
- 32 "подчиненных" компьютера, которые выполняют PXE-загрузку с head1
- head1 экспортирует файловую систему NFS для 32 PXE-серверов
- head2 экспортирует каталог "data" через NFS, который содержит файлы данных для всех остальных машин
- каталог data содержит очень большие файлы (5+ Гб)
- связь между машинами: Gigabit Ethernet
- большинство машин не в одной физической стойке
- Использует Open Grid Scheduler (он же Grid Engine) для пакетной обработки заданий
Одно из вычислений, которое выполняет этот кластер, включает для каждого из "ведомых" чтение очень больших наборов файлов (3Gb + 3Gb + 1,5 Гб + 750M) перед началом различных вычислений. Я заметил, что когда это происходит, большинство рабов фактически тратят значительное время (несколько минут), читая их (в то время как фактические вычисления намного быстрее).
В настоящее время я увеличил количество потоков в демоне NFS в head2 и поставил rsize а также wsize до 32к в опциях ведомого монтирования, но все же это существенное узкое место.
Что я могу сделать, чтобы улучшить производительность, или я должен позволить рабам размещать эти файлы на своих жестких дисках? Или я должен пойти с совершенно другой ФС для хранения?
3 ответа
Поскольку вы проводите анализ производительности, первый вопрос должен звучать так: "На каких данных я основываю предположение? Существуют ли сетевые трассировки или другие данные о производительности, которые поддержали бы эту гипотезу?"
В такой системе существует множество возможных узких мест, и я бы поставил под сомнение выбор сетевой файловой системы в последнюю очередь, особенно если учесть, что вы не пишете значительные объемы данных и блокировку / параллелизм, и связанные с этим проблемы с задержкой наиболее вероятны узкое место вызывает с NFS.
С другой стороны, 32 одновременных запроса на 8 ГБ данных каждый может перегружать любой диск SATA из-за довольно ограниченной оценки IOPS для одного диска. Простой расчет, предполагающий размер блока чтения 64 КБ на запрос и 100 IOPS для диска, даст скорость всего 6,4 МБ / с для запросов случайного чтения - это то, что вы будете получать с таким количеством одновременных считывателей, если только Вы сильно кешируете данные.
Вы должны внимательно посмотреть на показатели эффективности, предоставляемые iostat чтобы увидеть, не перегружен ли ваш диск. И если это так, примите соответствующие меры (например, получите достойную подсистему хранения, способную справиться с нагрузкой), чтобы исправить ситуацию.
Скорее всего, это не ограничение NFS, с которым вы здесь сталкиваетесь.
Также примите во внимание, что эти 5 гигабайт занимают по крайней мере 40 секунд для передачи с гигабитной проводной скоростью - для каждого клиента. У вас 32 из них забивают голову2, и они вряд ли будут запрашивать одинаковые блоки в одно и то же время. Добавьте Ethernet, TCP/UDP и NFS, и вы скоро начнете тратить минуты, которые вы описали.
Поэтому, прежде чем пытаться заменить NFS чем-то другим (да, есть протоколы с меньшими издержками), проверьте каждую часть пути, которую данные (начиная с дисковой подсистемы), принимают на возможные возможные узкие места. Тест в случае сомнений.
Устранить эти узкие места (если таковые имеются) с помощью дополнительного или более качественного оборудования будет проще, чем изменить все настройки программного обеспечения.
У меня довольно схожая среда (множество блейд-серверов в качестве рабочих узлов и огромные файлы на каждые несколько ГБ или даже ТБ). Я использую распределенную файловую систему Hadoop (HDFS). Проверять, выписываться:
http://en.wikipedia.org/wiki/Hadoop_Distributed_File_System
http://hadoop.apache.org/docs/r0.18.0/hdfs_design.pdf
Возможно, вам будет немного сложнее настроить его, чем NFS.