Как динамически масштабировать StarCluster/qsub/EC2 для выполнения параллельных заданий по нескольким узлам

Question

Я новичок в использовании механизма Startcluster/qsub/grid для запуска параллельных заданий, и я попытался прочесть пару других сообщений относительно того же. Я все еще не уверен, как построить масштабируемое решение для моего конкретного требования. Я хотел бы принять еще несколько предложений, прежде чем я продолжу то же самое.

Вот мои требования:

1. У меня есть огромный архивный файл [~ 40 - 50 Гб и может доходить до 100GB] -----> Существует не так много я могу сделать Вот. Я принимаю, что в качестве входных данных используется один единственный файл tar.

2. Я должен распаковать и распаковать его -----> Я запускаю tar xvf tarfilename.tar | параллельный pbzip -d для распаковки и распаковки.

3. Результат этого несжатия - это несколько сотен тысяч файлов, около 500 000 файлов.

4. Этот несжатый файл должен быть обработан. У меня модульный код, который может принимать в каждом отдельном файле и обрабатывать его и выводить 5 разных файлов.

Tar File ----- Parallel распаковки ---> несжатых файлов ----- Parallel Processing ---> 5 выходных файлов в файл обрабатывается

1. Я в настоящее время параллельный скрипт python, который работает на 16 ядрах, 16 ГБ памяти, взяв в этом списке несжатых файлов и обрабатывая их параллельно.

2. Проблема в том, как я могу масштабировать масштаб. Например, если мой код работает в течение 10 часов, и я хотел бы добавить к нему еще одну 8-ядерную машину, я не могу сделать это в параллельном python, так как мне нужно было бы знать количество процессоров заранее.

3. В то же время, когда я динамически добавляю больше узлов в текущий кластер, как насчет доступности данных и операций чтения/записи?

Итак, я начал читать и делал основные эксперименты с помощью starcluster и qsub. Хотя я вижу, я могу отправить несколько заданий через qsub, как я могу заставить его взять входные файлы из несжатой папки ввода?

Например, могу ли я написать script.sh, который в цикле выбирает имена файлов один за другим и передает их команде qsub? Есть ли еще одно эффективное решение?

Скажем, если у вас 3 машины с 16 процессорами каждый, и если я отправлю 48 заданий в очередь, будет ли qsub автоматически запускаться в разных процессорах кластеров или мне придется использовать параметры параллельной среды, такие как -np orte команда устанавливает количество процессоров в каждом кластере соответственно. Нужно ли сделать мой скрипт python исполняемым MPI?

Как итог, у меня есть несколько сотен тысяч файлов в качестве входных данных, я хотел бы отправить их в очереди заданий на многоядерные машины. Если я динамически добавляю больше машин, задания должны автоматически распределяться.

Еще одна серьезная проблема: мне нужен весь вывод 500 000 нечетных операций для агрегирования в конце?Есть ли предложение о том, как агрегировать выходные данные параллельных заданий по мере выписки вывода?

Я тестирую несколько сценариев, но я хотел бы знать, есть ли люди, которые экспериментировали в подобных сценариях.

Любые предложения с использованием плагина Hadoop? http://star.mit.edu/cluster/docs/0.93.3/plugins/hadoop.html

Заранее спасибо Karthick

Answer 1

1. I/O и обмен данными. Если у вас низкий уровень ввода-вывода, вы можете оставить свои данные на своем главном узле и использовать nfs, чтобы поделиться им между вашими узлами. Если у вас много ввода-вывода, я бы рекомендовал использовать ведро S3.

2. Распространение: ваш скрипт bash, запускающий несколько qsub, является правильным решением. Вы можете либо вызвать его в одном файле, либо в нескольких файлах одновременно.

3. Масштабирование. См. Ваши параллельные задания, выполняемые на кластере, как различные задачи. Вам решать запустить 1 или более экземпляров вашего приложения на каждом узле. Например: если вы используете узлы cr1.8xlarge, у вас есть 32 ядра. Вы можете запустить 1 экземпляр вашего приложения там, используя 32 ядра или 4 экземпляра вашего приложения, используя 8 ядер. См. Конфигурацию «слотов» для каждого узла в Open Grid Engine. (Если вы были более склонны запускать один большой экземпляр вашего приложения, объединяющего ядра нескольких узлов, я никогда не делал этого, поэтому я не могу вам помочь.) Затем, чтобы добавить узел, вы можете использовать «addnode», команды от StarCluster. Как только узел встанет, OGS будет автоматически распространять там задания. Вы также можете использовать загрузчик StarCluster для автоматического добавления/удаления узлов.

Итак, вот мое предложение. 1. Извлеките файлы на S3. 2. Запуск StarCluster 3. Используя ваш bashscript, qsub задание для каждых нескольких файлов (может быть более эффективным для работы над 10 файлами, чем с заданием для каждого отдельного файла) 4. Ваше приложение должно I/O - s3. 5. Когда очередь пуста, попросите сценарий просмотреть результаты, чтобы убедиться, что все задания работают хорошо. Вы можете переназначить задания, когда отсутствует выход.

• Я не знаю, как ваша агрегация выполнена, поэтому я не могу сказать.
• Я никогда не использовал hadoop, поэтому я тоже не могу помочь.
• Вам не нужно создавать исполняемый файл скрипта python.
• Если вы используете гетерогенный кластер, то с самого начала вы знаете, сколько ядер будет доступно на каждом узле.
• Если вы определили узел с 32 ядрами, чтобы иметь 4 слота, то вы должны сделать ваши рабочие места не более 8 ядер каждый.

Answer 2

Спустя некоторое время, исследуя различные варианты динамического масштабирования, я решил использовать механизм очереди для распределения рабочих мест для нескольких работников.

Job_Manager - читает ввод, строит работу, добавляет задание в очередь SQS очередь на рабочих процессах сервиса очередей - Слушает очередь и обрабатывает выходные.

Приводы ввода/вывода являются NFS и доступны для всех серверов/клиентов.

Чтобы динамически масштабировать, добавьте информацию о клиенте NFS в/export и перезапустите сервер. Активные клиенты имеют rw, hard, intr конфигурацию в своем соответствующем fstab. Запустив n рабочих процессов в новом клиенте, к процессу добавляется больше рабочих.

В настоящее время он надежно и масштабируется. Я смог запустить около 90 рабочих на трех машинах и обработать 200 000 файлов менее чем за 5 часов. Раньше он занимал около 24 часов, так как я не мог распространять данные и запускать рабочих по нескольким узлам.