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