Работа с кластерами HPC

11

В моем университете у нас есть вычислительный кластер HPC. Я использую кластер для обучения классификаторов и так далее. Поэтому, обычно для отправки задания в кластер (например, сценарий python scikit-learn) мне нужно написать сценарий Bash, который содержит (среди прочего) такую ​​команду qsub script.py.

Тем не менее, я нахожу этот процесс очень разочаровывающим. Обычно происходит то, что я пишу скрипт python на своем ноутбуке, а затем захожу на сервер и обновляю SVN-репозиторий, так что я получаю там тот же скрипт python. Затем я пишу сценарий Bash или редактирую его, чтобы запустить сценарий Bash.

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

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

Джек Твен
источник
1
Ах, радости развертывания ... усиливаются радостями распределенных систем :)
logc

Ответы:

5

Попросите администратора сети добавить ваш локальный компьютер в качестве «хоста отправки» и установить SGE (который, как мы предполагаем, вы используете, вы на самом деле не говорите), чтобы вы могли вернуться qsubс вашего компьютера.

ИЛИ....

Используйте emacs, тогда вы можете редактировать на своем HPC с помощью emacs «tramp» ssh-соединений и держать оболочку открытой в другом окне emacs. Вы не говорите, какой редактор / операционная система вам нравится использовать. Вы даже можете сконфигурировать emacs для сохранения файла в двух местах, чтобы вы могли сохранить его на локальном компьютере для выполнения тестов и в файловой системе HPC одновременно для больших заданий.

Spacedman
источник
4

Существует множество решений, облегчающих копирование файла с локального компьютера на вычислительные узлы в кластерах. Простой подход заключается в использовании интерфейса, который обеспечивает множественный доступ к компьютерам в кластере, например clusterssh (cssh). Это позволяет вам вводить команды для нескольких машин одновременно через набор окон терминала (каждый из которых является ssh-соединением с другой машиной в кластере).

Поскольку ваш кластер, кажется, qsubнастроен, ваша проблема может быть скорее связана с репликацией данных на компьютерах (кроме простого запуска команды на каждом узле). Таким образом, для решения этой проблемы вы можете либо написать scpсценарий, чтобы скопировать объекты на каждый узел кластера и с него (что, безусловно, лучше решать с помощью SVN), либо вы можете настроить NFS. Это позволит обеспечить простой и прозрачный доступ к данным, а также уменьшит необходимость репликации ненужных данных.

Например, вы можете получить доступ к узлу, скопировать данные в такое место и просто использовать данные удаленно , через сетевую связь. Я не знаком с тем, как настроить NFS, но у вас уже есть доступ к нему (если ваша домашняя папка одинакова на всех компьютерах, к которым вы обращаетесь). Затем сценарии и данные могут быть отправлены в одно место, а затем доступны для других. Это сродни подходу SVN, за исключением того, что он более прозрачен / прост.

Рубенс
источник
4

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

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

Все, что вам нужно, это ознакомиться с окружающей средой (ОС, редактором и т. Д.) Или установить собственную среду (я обычно устанавливаю в своем домашнем каталоге последнюю версию Vim , Tmux и т. Д. С соответствующими точечными файлами, поэтому я чувствую, что дома есть.)

Кроме того, вы можете изменить свои данные и даже промежуточные результаты, если позволяет размер. Мои репозитории часто содержат код, данные (исходные и очищенные версии), документацию и бумажные источники для публикации (латекс).

Наконец, вы можете написать свою работу, чтобы избежать изменения сценариев вручную. qsubпринимает скрипт от stdin, а также принимает все #$комментарии в качестве аргументов командной строки.

damienfrancois
источник
3

Из формулировки вашего вопроса я предполагаю, что у вас есть локальный компьютер и удаленный компьютер, на котором вы обновляете два файла - скрипт Python и скрипт Bash. Оба файла находятся под контролем SVN, и обе машины имеют доступ к одному и тому же серверу SVN.

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

Держите производственные изменения, ограниченные изменениями конфигурации . Вы пишете, что вам нужно «использовать путь наборов данных на сервере»; для меня это звучит так, будто у вас есть пути, жестко закодированные в вашем скрипте Python Это не очень хорошая идея, потому что вам нужно будет изменить эти пути на каждом другом компьютере, на который вы переместите скрипт. Если вы передадите эти изменения обратно в SVN, то на локальном компьютере у вас будут удаленные пути, и так далее, и так далее ... (Что делать, если есть не только пути, но и пароли? У вас не должно быть рабочих паролей в SVN сервер.)

Поэтому сохраните пути и другую информацию о настройках в .iniфайле и используйте ConfigParser для его чтения, либо используйте .jsonфайл и используйте модуль json . Сохраняйте одну копию файла локально и одну удаленно, оба по одному пути, оба без контроля SVN, и просто сохраняйте путь к этому файлу конфигурации в скрипте Python (или получите его из командной строки, если вы не можете сохранить оба конфигурации по тому же пути).

Сохраняйте конфигурацию как можно меньше . Любая конфигурация является «движущейся частью» вашего приложения, и любая система тем более устойчива, чем меньше в ней движущихся частей. Хороший индикатор того, что относится к конфигурации, это то, что вам нужно редактировать это каждый раз, когда вы перемещаете код; вещи, которые не нуждались в редактировании, могут оставаться постоянными в коде.

Автоматизируйте развертывание . Вы можете сделать это через скрипт Bash на вашем локальном компьютере; обратите внимание, что вы можете выполнить любую команду на удаленной машине через ssh. Например:

svn export yourprojectpath /tmp/exportedproject
tar czf /tmp/yourproject.tgz /tmp/exportedproject
scp /tmp/myproject.tgz youruser@remotemachine:~/dev

## Remote commands are in the right hand side, between ''
ssh youruser@remotemachine 'tar xzf ~/dev/yourproject.tgz'
ssh youruser@remotemachine 'qsub ~/dev/yourproject/script.py'

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

Если вам нужно больше, вы можете подумать об использовании Python's Fabric или кухне более высокого уровня .

logc
источник