Сбой сетевой файловой системы во время высоких скоростей ввода-вывода
Я являюсь пользователем кластера, использующего NFS для наших нужд хранения данных. Недавно я запустил конвейер с очень высоким I/O во время некоторых операций.
Программа, которая, по нашему мнению, является причиной проблемы, называется Bowtie, разработчиком биоинформационных конвейеров. Короче говоря, у нас есть алфавитные последовательности в фрагментированных файлах по 1 миллиону строк на файл, которые сравниваются с другим файлом, содержащим весь словарь. (Это упрощение алгоритма)
Этот словарь отображен в памяти во время процедуры. У меня есть права на передачу в очередь на три узла в кластере.
Узлы: Узел1 Узел2 Узел3 Узел4 Узел5 Узел6 Узел6 Узел7
Мое право: Node1 Node2 Node3
Количество доступных мне процессоров: 128 процессоров или 128 работающих слотов очереди.
Для запуска в кластере основной файл делится на блоки по 1 миллиону строк каждый, а затем все задания запускаются с использованием SGE.
Словарь в этот момент загружается в память на каждый узел, то есть Node1 2 и 3
Для каждого задания, активного в слоте очереди, у меня открыты следующие обработчики файлов
1 Файл задания, содержащий код для запуска 1 файл кода, содержащий код завершения процесса 1 SGE-сгенерированный STDOUT-файл 1 SGE-сгенерированный STDERR-файл 1 File Chunk 1 Выходной файл
Это означает, что во время этого процесса у меня открыто 768+3 файловых обработчика в удаленном хранилище данных, хотя первые четыре файла постоянны для каждого отдельного сценария в конвейере.
Всякий раз, когда это происходит, происходит сбой сервера NFS в хранилище данных, и весь наш кластер выходит из строя, потому что хранилище перестает отвечать на запросы.
Наш ИТ-персонал предположил, что это может быть связано с большим количеством операций ввода-вывода во время этого процесса, и, возможно, NFS предназначалась только для небольших кластеров, а не для крупных.
Поэтому мы обошли это решение, в котором мы планируем запустить этот процесс на одном из узлов. Но тогда смысл наличия кластера в нашем распоряжении сводится на нет, потому что мы будем записывать на диск узла, а не на хранилище данных, разделяемое между всеми кластерами.
Я не могу поверить, что NFS была разработана для небольших кластеров и никогда не была успешно реализована в решениях для крупных предприятий. Может ли существовать другая причина, по которой NFS внезапно обрывает сетевое соединение?
Я уверен, что процесс - это вопрос, который является причиной замораживания кластера, но я не уверен, что скорость чтения / записи, которую он требует, является причиной сбоя. Кто-нибудь из вас сталкивался с такой проблемой ранее? Является ли полная миграция протоколов единственным решением, которое у нас есть?
1 ответ
Несколько предложений, полученных за эти годы.
- Минимизируйте нагрузку на сервер NFS:
установить параметры экспорта NFS: async,insecure,no_subtree_check
установить параметры монтирования NFS soft,noatime,nodiratime,nolock,vers=3
также установите: noatime,nodiratime на данных / TMP / нуля монтирует. Убедитесь, что шифрование NFS отключено, чтобы уменьшить нагрузку. Остановите процесс блокировки NFS.
Попробуйте включить кадры JUMBO для сети на всех хостах (если поддерживается сетевым оборудованием) - установите MTU на 9k или около того.
Убедитесь, что хранилище raid10 используется (избегайте raid5/6 по ВСЕМ затратам) для случайного ввода-вывода. Есть SSD?
Увеличьте количество открытых ручек FS (по умолчанию 2K в некоторых системах), установите 1M или около того.
Есть ли шанс скопировать базу данных сопоставления с входными данными в локальное хранилище пустых узлов, а затем объединить / отсортировать полученные файлы sam как отдельный шаг?
Увеличьте размер обрабатываемого чанка (чтобы он обрабатывался не менее 30 минут и более).
Если возможно, разделите задания на максимально возможный уровень (попробуйте сопоставить / отсортировать 10 отдельных геномов / образцов на 10 различных узлах параллельно, вместо того, чтобы пытаться отобразить каждый геном последовательно, используя 10 хостов). Попытайтесь установить контрольную точку после завершения всех процессов.
Измените исходный код программы, чтобы он считывал данные большими блоками - например, 1M вместо 4k.
Помните о конфликте между процессорами и ОЗУ (особенно в системах с сокетами AMD 4-8), иногда запуск 12-24 потоков на 48-ядерном процессоре происходит быстрее, чем 48 потоков. Попробуйте разные уровни использования. Убедитесь, что NUMA включен и настроен для многопроцессорных систем. Перекомпилируйте с включенным NUMA.
PS: Управление эффективным кластером похоже на планирование / управление строительной площадкой с 1k+ работников...