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

У моєму університеті у нас є обчислювальний кластер HPC. Я використовую кластер для підготовки класифікаторів тощо. Отже, зазвичай, щоб надіслати завдання кластеру (наприклад, скрипт python scikit-learn), мені потрібно написати сценарій Bash, який містить (серед інших) таку команду, як qsub script.py.

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

Як ви бачите, це справді засмучує, оскільки для кожного невеликого оновлення сценарію python мені потрібно зробити багато кроків, щоб виконати його на обчислювальному кластері. Звичайно завдання стає ще складнішим, коли мені доводиться розміщувати дані на сервері та використовувати шлях наборів даних до сервера.

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

Попросіть свого адміністратора сітки додати вашу локальну машину як "подати хост" і встановити SGE (який, як ми вважаємо, ви використовуєте, ви насправді не говорите), щоб потім можна було qsubзі своєї машини.

АБО….

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

Існує багато рішень для полегшення тягаря копіювання файлу з локальної машини на обчислювальні вузли кластерів. Простий підхід полягає у використанні інтерфейсу, який дозволяє багатодоступний доступ до машин кластеру, як clusterssh (cssh). Це дозволяє вводити команди на декілька машин одночасно через набір термінальних екранів (кожен - ssh-з'єднання з іншою машиною кластера).

Оскільки ваш кластер, здається, qsubналаштувався, ваша проблема може бути скоріше пов'язана з реплікацією даних уздовж машин (крім простого запуску команди в кожному вузлі). Отже, щоб вирішити цю точку, ви можете або написати scpсценарій, скопіювати речі на кожен вузол кластеру та з нього (що, безумовно, краще вирішити у SVN), або ви можете встановити NFS. Це дозволило б забезпечити простий та прозорий доступ до даних, а також зменшити потребу в тиражуванні непотрібних даних.

Наприклад, ви можете отримати доступ до вузла, скопіювати дані в таке місце і просто використовувати дані віддалено , через мережевий зв’язок. Я не знайомий із тим, як налаштувати NFS, але ви вже маєте доступ до нього (у випадку, якщо ваша домашня папка однакова на всіх машинах, до яких ви отримуєте доступ). Потім сценарії та дані можуть бути відправлені в одне місце, а пізніше отримати доступ до інших. Це схоже на підхід SVN, за винятком того, що він більш прозорий / прямолінійний.

Ваш підхід до використання сховища вихідної версії є хорошим, і він фактично дозволяє вам також працювати над кластером, а потім копіювати все назад.

Якщо ви знайдете незначні зміни свого сценарію Python на своєму ноутбуці, а потім оновіть свій каталог SVN на кластері, чому б не працювати безпосередньо на фронталі кластера, внести всі необхідні незначні зміни, а потім, наприкінці дня, зробити команду все там і оновлення на вашому ноутбуці?

Все, що вам потрібно - це ознайомитись із оточенням там (ОС, редактор тощо) або встановити власне середовище (я зазвичай встановлюю у своєму домашньому каталозі останню версію Vim , Tmux тощо з належними dotfiles, тому я відчуваю себе додому.)

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

Нарешті, ви можете скласти сценарій подання вашої роботи, щоб уникнути зміни сценаріїв вручну. qsubприймає скрипт від stdin, а також приймає всі #$коментарі як аргументи командного рядка.

З формулювання вашого запитання я припускаю, що у вас є локальна машина та віддалена машина, де ви оновлюєте два файли - скрипт 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 або кухні вищого рівня .