Praca z klastrami HPC

Na mojej uczelni mamy klaster obliczeniowy HPC. Używam klastra do szkolenia klasyfikatorów i tak dalej. Zwykle więc, aby wysłać zadanie do klastra (np. Skrypt scikit-learn python), muszę napisać skrypt Bash zawierający (między innymi) polecenie podobne qsub script.py.

Uważam jednak ten proces za bardzo frustrujący. Zwykle dzieje się tak, że piszę skrypt Pythona na moim laptopie, a następnie loguję się na serwerze i aktualizuję repozytorium SVN, więc otrzymuję tam ten sam skrypt Pythona. Następnie piszę ten skrypt Bash lub edytuję go, aby móc uruchomić skrypt bash.

Jak widzisz, jest to naprawdę frustrujące, ponieważ przy każdej małej aktualizacji skryptu Python muszę wykonać wiele kroków, aby wykonać ją w klastrze obliczeniowym. Oczywiście zadanie staje się jeszcze bardziej skomplikowane, gdy muszę umieścić dane na serwerze i użyć ścieżki zestawów danych na serwerze.

Jestem pewien, że wiele osób używa klastrów obliczeniowych do swoich zadań związanych z nauką danych. Chcę tylko wiedzieć, jak radzicie sobie z wysyłaniem zleceń do klastrów?

Poproś administratora sieci o dodanie twojego komputera lokalnego jako „prześlij hosta” i zainstaluj SGE (którego, jak zakładamy, używasz, właściwie nie mówisz), abyś mógł to zrobić qsubze swojego komputera.

LUB....

Użyj emacsa, a następnie możesz edytować na swoim HPC za pomocą funkcji „tramp” ssh-emacsa i utrzymywać otwartą powłokę w innym oknie emacsa. Nie mówisz, jakiego edytora / systemu operacyjnego chcesz używać. Możesz nawet skonfigurować emacsa, aby zapisywał plik w dwóch miejscach, dzięki czemu możesz zapisywać na komputerze lokalnym w celu przeprowadzenia testów i systemu plików HPC jednocześnie w przypadku dużych zadań.

Istnieje wiele rozwiązań zmniejszających obciążenie związane z kopiowaniem pliku z komputera lokalnego do węzłów obliczeniowych w klastrach. Prostym podejściem jest użycie interfejsu, który umożliwia wielodostęp do maszyn w klastrze, takich jak clusterssh (cssh). Umożliwia wpisywanie poleceń do wielu komputerów jednocześnie za pomocą zestawu ekranów terminali (każde połączenie ssh z inną maszyną w klastrze).

Ponieważ wydaje się, że klaster został qsubskonfigurowany, problem może być raczej związany z replikacją danych wzdłuż komputerów (inne niż po prostu uruchomienie polecenia w każdym węźle). Aby rozwiązać ten problem, możesz albo napisać scpskrypt, aby skopiować rzeczy do i z każdego węzła w klastrze (który z pewnością lepiej jest rozwiązać za pomocą SVN), lub możesz skonfigurować NFS. Umożliwiłoby to prosty i przejrzysty dostęp do danych, a także zmniejszyłoby potrzebę replikacji niepotrzebnych danych.

Na przykład można uzyskać dostęp do węzła, skopiować dane do takiego miejsca i po prostu użyć danych zdalnie , za pośrednictwem komunikacji sieciowej. Nie wiem, jak skonfigurować NFS, ale masz już do niego dostęp (na wypadek, gdyby Twój folder domowy był taki sam na wszystkich komputerach, do których masz dostęp). Następnie skrypty i dane można wysłać w jedno miejsce, a później uzyskać dostęp do innych. Jest to podobne do podejścia SVN, z tym że jest bardziej przejrzyste / proste.

Twoje podejście do korzystania z repozytorium wersji źródłowej jest dobre i pozwala na pracę nad klastrem, a następnie kopiowanie wszystkiego z powrotem.

Jeśli zauważysz, że dokonujesz drobnych zmian w skrypcie Python na swoim laptopie, a następnie aktualizujesz katalog SVN w klastrze, dlaczego nie pracować bezpośrednio w interfejsie klastra, wprowadzać wszystkie potrzebne drobne zmiany, a następnie, pod koniec dnia, zatwierdzić wszystko tam i aktualizacja na swoim laptopie?

Wszystko, czego potrzebujesz, to zapoznanie się ze środowiskiem (OS, edytor itp.) Lub zainstalowanie własnego środowiska (zwykle instaluję w moim katalogu domowym najnowszą wersję Vima , Tmux itp. Z odpowiednimi plikami kropkowymi, więc czuję się tam dom.)

Możesz także zaktualizować swoje dane, a nawet wyniki pośrednie, jeśli pozwala na to rozmiar. Moje repozytoria często zawierają kod, dane (wersje oryginalne i oczyszczone), dokumentację i źródła papierowe do publikacji (lateks)

Na koniec możesz napisać skrypt do przesłania zadania, aby uniknąć ręcznej modyfikacji skryptów. qsubakceptuje skrypt ze standardowego wejścia, a także przyjmuje wszystkie #$komentarze jako argumenty wiersza poleceń.

Na podstawie sformułowania pytania zakładam, że masz komputer lokalny i komputer zdalny, na którym aktualizujesz dwa pliki - skrypt Python i skrypt Bash. Oba pliki są pod kontrolą SVN, a oba komputery mają dostęp do tego samego serwera SVN.

Przykro mi, ale nie mam żadnych porad dotyczących twojego systemu grid, ale pozwól mi wymienić kilka ogólnych punktów, które uznałem za ważne dla każdego wdrożenia.

Ogranicz zmiany produkcyjne do zmian konfiguracji . Piszesz, że musisz „użyć ścieżki zestawów danych na serwerze”; brzmi to dla mnie tak, jakby ścieżki były zapisane na stałe w skrypcie Python. To nie jest dobry pomysł, właśnie dlatego, że będziesz musiał zmienić te ścieżki na każdej innej maszynie, do której przenosisz skrypt. Jeśli zatwierdzisz te zmiany z powrotem do SVN, to na komputerze lokalnym będziesz mieć ścieżki zdalne, i tak dalej i dalej ... (Co jeśli nie będą tylko ścieżki, ale także hasła? Nie powinieneś mieć haseł produkcyjnych w SVN serwer.)

Dlatego przechowuj ścieżki i inne informacje dotyczące instalacji w .inipliku i użyj ConfigParser, aby go odczytać, lub użyj .jsonpliku i użyj modułu json . Zachowaj jedną kopię pliku lokalnie i jedną zdalnie, obie pod tą samą ścieżką, obie bez kontroli SVN, i po prostu zachowaj ścieżkę do tego pliku konfiguracyjnego w skrypcie Python (lub pobierz go z wiersza poleceń, jeśli nie możesz zachować obu konfiguracje pod tą samą ścieżką).

Utrzymuj konfigurację tak małą, jak to możliwe . Każda konfiguracja jest „ruchomą częścią” aplikacji, a każdy system jest bardziej niezawodny, tym mniej ma ruchomych części. Dobrym wskaźnikiem czegoś, co należy do konfiguracji jest to, że musisz ją edytować za każdym razem, gdy przenosisz kod; rzeczy, które nie wymagały edycji, mogą pozostać stałymi w kodzie.

Zautomatyzuj wdrażanie . Możesz to zrobić za pomocą skryptu Bash na komputerze lokalnym; pamiętać, że można uruchomić dowolne polecenie na komputerze zdalnym poprzez ssh. Na przykład:

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'

Aby to zadziałało, musisz oczywiście mieć login bez hasła , oparty na kluczach publicznych / prywatnych, skonfigurowany między komputerem lokalnym a komputerem zdalnym.

Jeśli potrzebujesz czegoś więcej, możesz pomyśleć o użyciu tkaniny Python lub kuchni wyższego poziomu .