Bekerja dengan cluster HPC

11

Di universitas saya, kami memiliki cluster komputasi HPC. Saya menggunakan cluster untuk melatih pengklasifikasi dan sebagainya. Jadi, biasanya, untuk mengirim pekerjaan ke cluster, (misalnya skrip python scikit-learn), saya perlu menulis skrip Bash yang berisi (antara lain) perintah seperti qsub script.py.

Namun, saya merasa proses ini sangat menyebalkan. Biasanya yang terjadi adalah saya menulis skrip python di laptop saya dan kemudian saya masuk ke server dan memperbarui repositori SVN, jadi saya mendapatkan skrip python yang sama di sana. Lalu saya menulis skrip Bash atau mengeditnya, sehingga saya dapat menjalankan skrip bash.

Seperti yang Anda lihat ini benar-benar membuat frustrasi karena, untuk setiap pembaruan kecil untuk skrip python, saya perlu melakukan banyak langkah untuk menjalankannya di cluster komputasi. Tentu saja tugas menjadi lebih rumit ketika saya harus meletakkan data di server dan menggunakan jalur dataset di server.

Saya yakin banyak orang di sini menggunakan cluster komputasi untuk tugas ilmu data mereka. Saya hanya ingin tahu bagaimana kalian mengatur pengiriman pekerjaan ke kluster?

Jack Twain
sumber
1
Ah, kegembiraan penerapan ... ditingkatkan oleh kegembiraan sistem terdistribusi :)
logc

Jawaban:

5

Minta administrator jaringan Anda untuk menambahkan mesin lokal Anda sebagai "kirim host", dan instal SGE (yang kami anggap Anda gunakan, Anda tidak benar-benar mengatakan) sehingga Anda dapat qsubdari mesin Anda.

ATAU....

Gunakan emacs, maka Anda dapat mengedit pada HPC Anda melalui fasilitas koneksi ssh "tramp" emacs, dan membiarkan shell tetap terbuka di jendela emacs lain. Anda tidak mengatakan editor / sistem operasi apa yang ingin Anda gunakan. Anda bahkan dapat mengkonfigurasi emacs untuk menyimpan file di dua tempat, sehingga Anda bisa menyimpan ke mesin lokal Anda untuk menjalankan tes dan ke sistem file HPC secara bersamaan untuk pekerjaan besar.

Spacedman
sumber
4

Ada banyak solusi untuk meringankan beban menyalin file dari mesin lokal ke node komputasi dalam cluster. Pendekatan sederhana adalah dengan menggunakan antarmuka yang memungkinkan multi-akses ke mesin di cluster, seperti clusterssh (cssh). Ini memungkinkan Anda untuk mengetik perintah ke beberapa mesin sekaligus melalui satu set layar terminal (masing-masing koneksi ssh ke mesin yang berbeda di cluster).

Karena cluster Anda tampaknya telah qsubdiatur, masalah Anda mungkin agak terkait dengan mereplikasi data di sepanjang mesin (selain hanya menjalankan perintah di setiap node). Jadi, untuk mengatasi hal ini, Anda dapat menulis scpskrip, untuk menyalin sesuatu ke dan dari setiap node dalam gugus (yang tentunya lebih baik ditangani dengan SVN), atau Anda dapat mengatur NFS. Ini akan memungkinkan akses yang sederhana dan transparan ke data, dan juga mengurangi kebutuhan untuk mereplikasi data yang tidak perlu.

Misalnya, Anda dapat mengakses node, menyalin data ke tempat seperti itu, dan cukup menggunakan data dari jarak jauh , melalui komunikasi jaringan. Saya tidak mengenal cara mengatur NFS, tetapi Anda sudah memiliki akses ke sana (kalau-kalau folder rumah Anda sama di seluruh mesin yang Anda akses). Kemudian, skrip dan data dapat dikirim ke satu tempat, dan kemudian diakses dari yang lain. Ini mirip dengan pendekatan SVN, kecuali itu lebih transparan / langsung.

Rubens
sumber
4

Pendekatan Anda menggunakan repositori versi sumber adalah pendekatan yang bagus dan sebenarnya memungkinkan Anda juga mengerjakan cluster dan kemudian menyalin semuanya kembali.

Jika Anda mendapati diri Anda mengedit kecil pada skrip Python di laptop Anda, kemudian memperbarui direktori SVN Anda di cluster, mengapa tidak bekerja secara langsung pada frontend cluster, buat semua suntingan kecil yang diperlukan, dan kemudian, pada akhirnya, komit semuanya ada dan perbarui di laptop Anda?

Yang Anda butuhkan hanyalah membiasakan diri dengan lingkungan di sana (OS, editor, dll.) Atau menginstal lingkungan Anda sendiri (saya biasanya menginstal di direktori home saya versi terbaru Vim , Tmux , dll. Dengan dotfile yang tepat jadi saya merasa di rumah disana.)

Selain itu, Anda dapat membuat versi data Anda, dan bahkan hasil antara Anda jika ukuran memungkinkan. Repositori saya sering terdiri dari kode, data (versi asli dan dibersihkan), dokumentasi, dan sumber kertas untuk penerbitan (lateks)

Terakhir, Anda dapat membuat skrip pengajuan pekerjaan Anda untuk menghindari memodifikasi skrip secara manual. qsubmenerima skrip dari stdin dan juga menerima semua #$komentar sebagai argumen baris perintah.

damienfrancois
sumber
3

Dari kata-kata pertanyaan Anda, saya berasumsi bahwa Anda memiliki mesin lokal dan mesin remote di mana Anda memperbarui dua file - skrip Python dan skrip Bash. Kedua file berada di bawah kendali SVN, dan kedua mesin memiliki akses ke server SVN yang sama.

Maaf saya tidak memiliki saran khusus untuk sistem grid Anda, tetapi izinkan saya mendaftar beberapa poin umum yang menurut saya penting untuk penyebaran apa pun.

Pertahankan perubahan produksi terbatas pada perubahan konfigurasi . Anda menulis bahwa Anda harus "menggunakan jalur dataset di server"; ini terdengar bagi saya seperti Anda memiliki jalur hardcoded ke skrip Python Anda. Ini bukan ide yang baik, justru karena Anda harus mengubah jalur tersebut di setiap mesin lain tempat Anda memindahkan skrip. Jika Anda mengkomit perubahan itu kembali ke SVN, maka pada mesin lokal Anda, Anda akan memiliki path jarak jauh, dan seterusnya ... (Bagaimana jika tidak hanya path, tetapi juga kata sandi? Anda seharusnya tidak memiliki kata sandi produksi di SVN server.)

Jadi, simpan jalur dan informasi pengaturan lainnya dalam .inifile dan gunakan ConfigParser untuk membacanya, atau gunakan .jsonfile dan gunakan modul json . Simpan satu salinan file secara lokal dan satu dari jarak jauh, keduanya di bawah jalur yang sama, keduanya tanpa kontrol SVN, dan simpan path ke file konfigurasi itu di skrip Python (atau dapatkan dari baris perintah jika Anda tidak bisa menyimpan keduanya konfigurasi di bawah jalur yang sama).

Pertahankan konfigurasi sekecil mungkin . Konfigurasi apa pun adalah "bagian yang bergerak" dari aplikasi Anda, dan sistem apa pun yang lebih kuat semakin sedikit bagian yang bergerak. Indikator yang baik untuk sesuatu yang termasuk dalam konfigurasi adalah Anda harus mengeditnya setiap kali Anda memindahkan kode; hal-hal yang tidak perlu diedit dapat tetap sebagai konstanta dalam kode.

Otomatiskan penyebaran Anda . Anda dapat melakukannya melalui skrip Bash di mesin lokal Anda; perhatikan bahwa Anda dapat menjalankan perintah apa pun pada mesin jarak jauh melalui ssh. Contohnya:

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'

Agar ini berfungsi, tentu saja Anda harus memiliki login tanpa kata sandi , berdasarkan kunci publik / pribadi, yang dibuat antara mesin lokal dan remote Anda.

Jika Anda membutuhkan lebih dari ini, Anda dapat menggunakan Kain Python atau masakan tingkat tinggi .

logc
sumber