Testy CI	Wydania galaktyki

scicore.slurm

Konfiguracja klastra SLURM

Ta rola skonfiguruje:

• daemona do rachunkowości SLURM
• głównego daemona SLURM
• węzły robocze SLURM
• hosty do składania zadań SLURM

Użytkownicy SLURM są automatycznie dodawani do bazy danych rachunkowości SLURM przy pierwszym złożeniu zadania za pomocą pluginu do składania zadań lua

Przykład inwentarza

master ansible_host=192.168.56.100 ansible_user=vagrant ansible_password=vagrant
submit ansible_host=192.168.56.101 ansible_user=vagrant ansible_password=vagrant
compute ansible_host=192.168.56.102 ansible_user=vagrant ansible_password=vagrant

[slurm_submit_hosts]
submit

[slurm_workers]
compute

Po zdefiniowaniu inwentarza upewnij się, że zdefiniujesz zmienną "slurm_master_host", wskazującą na nazwę hosta głównego

Zmienne roli

# dodaj wszystkie hosty SLURM do /etc/hosts na każdej maszynie
# adresy IP pochodzą z faktów ansible hostvars[ansible_hostname]['ansible_default_ipv4']['address']
slurm_update_etc_hosts_file: true

# wskaż tę zmienną na repozytorium git, jeśli masz konfigurację SLURM w git
# slurm_config_git_repo: ""

# domyślnie rola wdroży plugin lua do składania, który automatycznie doda użytkowników do bazy danych rachunkowości SLURM
# Sprawdź "templates/job_submit.lua.j2" dla szczegółów
slurm_config_deploy_lua_submit_plugin: true

# Użyj SLURM bezkonfiguracyjnie https://slurm.schedmd.com/configless_slurm.html
# Ta funkcja wymaga SLURM w wersji 20.02 lub wyższej
# Testowano tylko na systemach RedHat, ale powinna działać również na Ubuntu, jeśli zainstalujesz wersję 20.02 lub wyższą
slurm_configless: false

# Wdróż wymagane skrypty w głównym węźle SLURM do uruchamiania w chmurze przy użyciu OpenStack (https://slurm.schedmd.com/elastic_computing.html)
# To wdroży "ResumeProgram", "SuspendProgram" dla slurm.conf
# oraz /etc/openstack/clouds.yaml z poświadczeniem aplikacji w głównym węźle SLURM
# To wymaga własnego pliku slurm.conf. Sprawdź "templates/slurm.conf.j2.cloud.example" dla przykładu.
# Zaleca się użycie [wewnętrznego rozwiązywania DNS OpenStack] (https://docs.openstack.org/neutron/latest/admin/config-dns-int.html#the-networking-service-internal-dns-resolution)
slurm_openstack_cloud_scheduling: false
slurm_openstack_venv_path: /opt/venv_slurm
slurm_openstack_auth_url: https://my-openstack-cloud.com:5000/v3
slurm_openstack_application_credential_id: "4eeabeabcabdwe19451e1d892d1f7"
slurm_openstack_application_credential_secret: "supersecret1234"
slurm_openstack_region_name: "RegionOne"
slurm_openstack_interface: "public"
slurm_openstack_identity_api_version: 3
slurm_openstack_auth_type: "v3applicationcredential"

# nazwa klastra SLURM określona w slurm.cfg
slurm_cluster_name: slurm-cluster

# ustaw tę zmienną na ansible_hostname głównego SLURM
slurm_master_host: slurm-master.cluster.com
# ustaw tę zmienną na ansible_hostname hosta slurm-dbd (domyślnie to samo, co slurm-master)
slurm_dbd_host: "{{ slurm_master_host }}"

# grupa w inwentarzu ansible, zawierająca wszystkich pracowników SLURM
slurm_workers_group: slurm_workers

# grupa w inwentarzu ansible, zawierająca wszystkich hostów do składania
slurm_submit_group: slurm_submit_hosts

# to ustawienie "StateSaveLocation" w slurm.conf
slurm_slurmctld_spool_path: /var/spool/slurmctld

# to ustawienie "SlurmdSpoolDir" w slurm.conf
slurm_slurmd_spool_path: /var/spool/slurmd

# ustawienia dla daemona rachunkowości SLURM
slurm_slurmdbd_mysql_db_name: slurm
slurm_slurmdbd_mysql_user: slurm
slurm_slurmdbd_mysql_password: aadAD432saAdfaoiu

# użytkownik i grupa SLURM, które uruchamiają daemony SLURM
slurm_user:
  RedHat: "root"
  Debian: "slurm"

slurm_group:
  RedHat: "root"
  Debian: "slurm"

# EPEL jest wymagane do instalacji pakietów SLURM i niektórych zależności w systemach CentOS/RedHat.
slurm_add_epel_repo: true

# Możesz ustawić tę zmienną na true, aby włączyć repozytoria openhpc yum w centos
# Jeśli planujesz używać pakietów z openhpc, powinieneś również zaktualizować listę pakietów dla RedHat poniżej
slurm_add_openhpc_repo: false
slurm_ohpc_repos_url:
  rhel7: "https://github.com/openhpc/ohpc/releases/download/v1.3.GA/ohpc-release-1.3-1.el7.x86_64.rpm"
  rhel8: "http://repos.openhpc.community/OpenHPC/2/CentOS_8/x86_64/ohpc-release-2-1.el8.x86_64.rpm"

# pakiety SLURM, które instalujemy w każdym członku klastra
slurm_packages_common:
  RedHat:
    - slurm
    - slurm-doc
    - slurm-contribs
  Debian:
    - slurm-client

# pakiety SLURM, które instalujemy tylko w węźle głównym
slurm_packages_master:
  RedHat:
    - slurm-slurmctld
    #  - slurm-slurmrestd
  Debian:
    - slurmctld

# pakiety SLURM, które instalujemy tylko w węźle slurmdbd
slurm_packages_slurmdbd:
  RedHat:
    - slurm-slurmdbd
    - mariadb-server
  Debian:
    - slurmdbd
    - mariadb-server

# pakiety SLURM, które instalujemy tylko w węzłach roboczych
slurm_packages_worker:
  RedHat:
    - slurm-slurmd
    - vte-profile  # unika komunikatu o błędzie "bash __vte_prompt_command command not found" w interaktywnych powłokach SLURM
  Debian:
    - slurmd

Konfiguracja harmonogramowania chmury SLURM dla OpenStack

Ta rola może skonfigurować twój klaster SLURM do korzystania z harmonogramowania w chmurze w chmurze OpenStack.

Zanim spróbujesz to skonfigurować, zaleca się zapoznanie z przewodnikiem po harmonogramowaniu w chmurze SLURM oraz dokumentacją SLURM bezkonfiguracyjnie.

Upewnij się, że twoja chmura OpenStack ma włączone wewnętrzne rozwiązywanie DNS. Jest to wymagane, aby główny węzeł SLURM mógł rozpoznać nazwę hosta nowego węzła przy użyciu wewnętrznego DNS OpenStack podczas jego uruchamiania.

Powinieneś także sprawdzić przykładowy plik konfiguracyjny slurm.conf.j2.cloud.example, który jest dołączony do tej roli. slurm.conf.j2.cloud.example jest dostarczany jako przykład i należy go dostosować do swoich specyficznych potrzeb oraz wskazać zmienną roli slurm_conf_custom_template na swoją własną konfigurację.

Przegląd konfiguracji harmonogramowania w chmurze

• Jak opisano w dokumentacji dotyczącej harmonogramowania w chmurze SLURM, gdy użytkownik składa zadanie do węzła w chmurze, główny węzeł SLURM wykona "ResumeProgram" zdefiniowany w slurm.conf, aby uruchomić węzeł obliczeniowy w chmurze.

• ResumeProgram dostarczony z tą rolą to skrypt w Pythonie, który wykorzysta API OpenStack do uruchomienia węzłów obliczeniowych. Ten skrypt w Pythonie wymaga klienta OpenStack, który jest zainstalowany w środowisku wirtualnym. Argumentem dla programu są nazwy węzłów (używając formatu wyrażenia hostlist SLURM), które mają być uruchomione.

• Gdy węzeł obliczeniowy jest bezczynny, główny węzeł SLURM wykona SuspendProgram w celu zatrzymania węzłów. Argumentem dla programu są nazwy węzłów (używając formatu wyrażenia hostlist SLURM), które mają być wyłączone.

• Opcje OpenStack używane do uruchamiania dynamicznych węzłów obliczeniowych (flavor, obraz, sieć, klucz i grupy zabezpieczeń) muszą być zdefiniowane jako cechy węzłów w slurm.conf, np. NodeName=compute-dynamic-[01-04] CPUs=4 RealMemory=7820 State=CLOUD Features=image=centos7,flavor=m1.large,keypair=key123,network=slurm_network,security_groups=default|slurm

• Zarówno "ResumeProgram", jak i "SuspendProgram" wymagają pliku konfiguracyjnego OpenStack z ważnymi poświadczeniami. Plik ten jest domyślnie uzupełniany do "/etc/openstack/clouds.yaml" w głównym hoście SLURM. Zaleca się użycie poświadczenia aplikacji OpenStack. Sprawdź szablon templates/clouds.yaml.j2, aby znaleźć wymagane zmienne roli do uzupełnienia tego pliku konfiguracyjnego.

• Zarówno "ResumeProgram", jak i "SuspendProgram" będą zapisywać logi do "/var/log/messages" w głównym hoście SLURM. Możesz sprawdzić ten dziennik w celach debugowania podczas uruchamiania węzłów w chmurze.

Zalecane podejście do wdrażania SLURM z harmonogramowaniem w chmurze OpenStack

Upewnij się, że masz SLURM w wersji 20.02 lub wyższej w swoich repozytoriach, aby mieć wsparcie dla trybu bezkonfiguracyjnego SLURM.

Uruchom co najmniej 3 maszyny:

• główny SLURM
• SLURM do składania (węzeł logowania)
• węzeł roboczy SLURM (może to być mała maszyna, którą wykorzystamy tylko do stworzenia obrazu OpenStack z wymaganą konfiguracją dla węzłów obliczeniowych w chmurze)

Wypełnij swój inwentarz ansible i przypisz maszyny do odpowiednich grup inwentarza odnoszących się do zmiennych roli slurm_submit_group i slurm_workers_group.

Zdefiniuj zmienną roli slurm_master_host z nazwą hosta głównego SLURM. Każda maszyna w klastrze powinna być w stanie rozwiązać tę nazwę hosta do adresu IP głównego węzła. Każda maszyna w klastrze musi być w stanie połączyć się z tą maszyną (sprawdź swoje grupy zabezpieczeń i lokalną zaporę).

Utwórz kopię slurm.conf.j2.cloud.example, dostosuj ją do swoich potrzeb i wskaź na swoją konfigurację zmienną roli slurm_conf_custom_template. Twój plik konfiguracyjny powinien zapewnić partycję o nazwie "static", która zawiera tylko węzeł roboczy SLURM, który uruchomiliśmy wcześniej.

Zdefiniuj zmienną ansible slurm_configless: true, aby węzły obliczeniowe były skonfigurowane w trybie bezkonfiguracyjnym. Gdy węzeł roboczy SLURM jest skonfigurowany w trybie bezkonfiguracyjnym, daemonic slurmd skontaktuje się z głównym węzłem SLURM przy pierwszym uruchomieniu i pobierze slurm.conf do /var/run/slurm/conf/slurm.conf.

Wykonaj rolę, aby skonfigurować wszystkie maszyny, a powinieneś uzyskać działający klaster SLURM z jednym węzłem w partycji "static".

Teraz możesz uruchomić swoje własne playbooki lub skrypty, aby dostosować węzeł roboczy SLURM, np. dodać montowania NFS, zainstalować klienta LDAP, włączyć moduły oprogramowania, zainstalować dodatkowe oprogramowanie itp.

Utwórz obraz OpenStack z maszyny w partycji "static", który zawiera twoje wymagane dostosowania. Sprawdź create-slurm-compute-node-image.yml dla przykładu.

Zaktualizuj swoją kopię slurm.conf.j2.cloud.example i zdefiniuj odpowiednie cechy węzła z nazwą obrazu openstack, nazwą klucza, nazwą sieci i grupami zabezpieczeń. Ponownie uruchom playbook, aby wdrożyć zaktualizowaną konfigurację.

Teraz (miejmy nadzieję) powinieneś mieć działający klaster SLURM z obsługą harmonogramowania w chmurze. Powinieneś widzieć partycje chmury SLURM podczas wykonywania sinfo -Nel. Spróbuj złożyć zadanie do jednej z partycji chmurowych i monitoruj /var/log/messages oraz /var/log/slurm/slurmctld.log w głównym hoście SLURM.