HPC İş Kuyruğu Yönetimi: SLURM En İyi Uygulamaları

HPC kümelerinde en sık karşılaşılan operasyonel sorunların başında iş kuyruğu yönetimi gelir. Yüzlerce kullanıcının aynı anda iş gönderdiği bir sistemde kaynakları adil ve verimli biçimde dağıtmak; hem sistem yöneticileri hem de araştırmacılar için kritik öneme sahiptir. Bu yazıda SLURM’ün sunduğu partition tasarımı, QOS politikaları, öncelik sistemi ve fairshare mekanizmalarını ele alarak pratik yapılandırma örnekleri paylaşacağız.

SLURM’ü Kısa Bir Hatırlatma ile Başlayalım

SLURM (Simple Linux Utility for Resource Management), günümüzde dünya genelindeki süperbilgisayar ve HPC kümelerinin büyük çoğunluğunda kullanılan açık kaynaklı bir iş planlayıcısıdır. Kaynak yönetimi, iş planlama ve izleme görevlerini birleşik bir çatı altında sunar. Esnekliği ve ölçeklenebilirliği sayesinde hem küçük kurumsal kümelerden hem de binlerce düğümlü ulusal altyapılarda tercih edilmektedir.

Partition Tasarımı: İş Yüklerini Mantıksal Gruplara Bölmek

Partition, SLURM’de düğümleri ve politikaları mantıksal gruplara ayıran temel yapı taşıdır. İyi tasarlanmış bir partition mimarisi; iş gecikmelerini azaltır, kaynak çakışmalarını önler ve farklı kullanıcı gereksinimlerini dengeli biçimde karşılar.

Tipik Bir Partition Yapısı

slurm.conf içinde bir partition aşağıdaki gibi tanımlanır:

# /etc/slurm/slurm.conf içinden örnek partition tanımları

PartitionName=short \
  Nodes=compute[001-016] \
  Default=NO \
  MaxTime=4:00:00 \
  MaxNodes=4 \
  State=UP \
  Priority=100

PartitionName=normal \
  Nodes=compute[001-064] \
  Default=YES \
  MaxTime=2-00:00:00 \
  MaxNodes=32 \
  State=UP \
  Priority=50

PartitionName=gpu \
  Nodes=gpu[001-008] \
  Default=NO \
  MaxTime=1-00:00:00 \
  MaxNodes=8 \
  State=UP \
  Priority=75

Partition Tasarımında Dikkat Edilmesi Gerekenler

Partition sınırlarını belirlerken iş yükü profilini iyi analiz etmek gerekir. Çok dar partition tanımları kullanıcıları kısıtlarken, çok geniş tanımlar kaynakların adil dağılımını zorlaştırır. Yeni bir HPC kümesi devreye alındığında ilk birkaç haftalık kullanım istatistiklerini toplamak ve bu verilere göre partition yapısını ayarlamak en sağlıklı yaklaşımdır.

Ayrıca bazı düğümlerin birden fazla partition’da yer almasına izin verebilirsiniz. Bu yöntem özellikle debug ve normal partition’larının aynı düğümleri paylaşmasını sağlayarak kısa test işlerinin uzun kuyrukları beklemeden çalışmasını mümkün kılar.

QOS (Quality of Service) Politikaları

QOS mekanizması, SLURM’de partition sınırlarının ötesinde ince taneli kaynak kontrolü sağlar. Her iş, gönderilirken bir QOS sınıfına atanır ve bu sınıfa tanımlanan kısıtlamalar ile öncelikler devreye girer.

QOS Tanımlama ve Yönetme

# Temel bir QOS tanımı oluşturma
sacctmgr add qos normal \
  Priority=10 \
  MaxWall=2-00:00:00 \
  MaxJobsPerUser=50 \
  MaxSubmitJobsPerUser=100 \
  GrpCPUs=512 \
  GrpMem=2048G

# Yüksek öncelikli (premium) QOS
sacctmgr add qos high_priority \
  Priority=100 \
  MaxWall=4:00:00 \
  MaxJobsPerUser=10 \
  GrpCPUs=128

# Debug işleri için kısıtlı QOS
sacctmgr add qos debug \
  Priority=200 \
  MaxWall=00:30:00 \
  MaxJobsPerUser=2 \
  GrpCPUs=32

# Mevcut QOS tanımlarını listeleme
sacctmgr show qos format=Name,Priority,MaxWall,MaxJobsPerUser,GrpCPUs

QOS sınırları, hesap (account) ya da kullanıcı düzeyinde de atanabilir. Örneğin araştırma gruplarına proje kotaları vermek için:

# Bir hesaba QOS atama
sacctmgr modify account proje_abc set qos=normal,high_priority

# Kullanıcıya varsayılan QOS belirleme
sacctmgr modify user ahmet set defaultqos=normal

GrpTRES ile Detaylı Kaynak Kotaları

Modern SLURM sürümlerinde GrpTRES parametresi sayesinde CPU, bellek ve GPU gibi farklı kaynaklar için ayrı ayrı grup kotaları tanımlanabilir:

sacctmgr modify qos gpu_users set \
  GrpTRES=cpu=256,mem=1024G,gres/gpu=16

Öncelik Sistemi: İşler Nasıl Sıralanır?

SLURM’de iş önceliği, birden fazla faktörün ağırlıklı toplamı olarak hesaplanır. Bu faktörler şunlardır:

• Fairshare — Grubun tarihsel kaynak kullanımına dayalı adil pay
• Job Age — İşin kuyrukta beklediği süre
• QOS Priority — QOS sınıfına atanmış öncelik değeri
• Partition Priority — Partition’a tanımlanan öncelik
• Job Size — İşin büyüklüğüne göre ek puan (opsiyonel)

Bu ağırlıklar slurm.conf içinde şu şekilde yapılandırılır:

# Öncelik hesaplama yöntemi
PriorityType=priority/multifactor

# Ağırlık değerleri (toplamları 1'e eşit olması gerekmez)
PriorityWeightFairshare=100000
PriorityWeightAge=10000
PriorityWeightJobSize=1000
PriorityWeightQOS=10000
PriorityWeightPartition=5000

# Maksimum bekleme bonusu için yaş sınırı (dakika)
PriorityMaxAge=7-00:00:00

# Fairshare hesaplama periyodu
PriorityDecayHalfLife=14-0

Bir işin anlık öncelik puanını görmek için:

sprio -j <job_id>
# veya tüm kuyruktaki işler için
sprio -l | sort -k 3 -n -r | head -20

Fairshare Mekanizması

Fairshare, SLURM’ün en güçlü ve en sık yanlış anlaşılan özelliklerinden biridir. Temel fikir şudur: bir kullanıcı ya da grup sistemin kendine ayrılan payından fazlasını kullanmışsa, gelecekteki işlerinin önceliği geçici olarak düşer. Bu sayede sistem kaynakları zaman içinde dengeli biçimde dağıtılır.

Fairshare Yapılandırması

Fairshare hesaplaması için her hesabın sistem üzerindeki hak payı (share) tanımlanmalıdır:

# Kök hesap altında proje hesapları oluşturma
sacctmgr add account proje_a \
  Cluster=mevasis-hpc \
  Share=40 \
  Description="Malzeme Bilimi Grubu"

sacctmgr add account proje_b \
  Cluster=mevasis-hpc \
  Share=30 \
  Description="Biyoinformatik Grubu"

sacctmgr add account proje_c \
  Cluster=mevasis-hpc \
  Share=30 \
  Description="Hesaplamalı Kimya Grubu"

# Kullanıcıları hesaplara ekleme
sacctmgr add user mehmet Account=proje_a
sacctmgr add user ayse Account=proje_b

Mevcut fairshare durumunu izlemek için:

sshare -l -a
# Belirli bir hesap için
sshare -A proje_a -l

Decay Half-Life Ayarı

PriorityDecayHalfLife parametresi, geçmiş kullanımın ne kadar sürede yarıya ineceğini belirler. 14 günlük bir değer, iki hafta önceki yoğun kullanımın bugünkü önceliği üzerindeki etkisini %50 oranında azaltır. Bu süreyi kısa tutmak sistemi daha reaktif yapar; uzun tutmak ise uzun vadeli adaleti ön plana çıkarır.

İş Gönderme ve İzleme: Kullanıcı Perspektifi

Sistem yöneticilerinin kurduğu bu altyapı, kullanıcılar tarafından SBATCH betikleri aracılığıyla kullanılır. Doğru partition ve QOS seçimi, işin ne zaman çalışacağını doğrudan etkiler:

#!/bin/bash
#SBATCH --job-name=molekuler_dinama
#SBATCH --partition=normal
#SBATCH --qos=normal
#SBATCH --account=proje_a
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=32
#SBATCH --mem-per-cpu=4G
#SBATCH --time=24:00:00
#SBATCH --output=%x_%j.out
#SBATCH --error=%x_%j.err

module load gromacs/2024.1-intel
srun gmx_mpi mdrun -v -deffnm simülasyon

Kullanıcıların kendi işlerinin önceliğini sorgulaması için:

# Kuyruktaki işleri görme
squeue -u $USER --format="%.18i %.9P %.30j %.8T %.10M %.6D %R"

# Fairshare durumumu görme
sshare -u $USER -l

Yaygın Sorunlar ve Çözüm Önerileri

Kuyruklarda uzun bekleme süreleri: Çoğunlukla büyük kaynak talep eden işlerin birikiminden kaynaklanır. short partition’ına makul sınırlar koymak ve küçük işlerin önceliğini artırmak bu sorunu hafifletir.

Belirli kullanıcıların kaynakları tekeline alması: Fairshare ağırlığını artırmak ve MaxJobsPerUser sınırı getirmek en etkili çözümdür.

GPU kaynaklarının boşta kalması: GPU işleri genellikle daha az CPU gerektirir. GPU partition’ının DefMemPerGPU ve MaxCPUsPerGPU parametrelerini doğru ayarlamak, GPU düğümlerinde gereksiz CPU bloklarını önler.

Backfill planlayıcısının yetersiz çalışması: SLURM’ün backfill mekanizması, küçük işleri büyük işlerin arasına sığdırarak boşta kalan kaynakları değerlendirir. SchedulerParameters=bf_max_job_test=500,bf_resolution=30 gibi parametreleri artırmak backfill etkinliğini iyileştirir; ancak planlayıcı yükünü de artırır.

Sonuç

SLURM iş kuyruğu yönetimi; partition tasarımı, QOS politikaları, öncelik ağırlıkları ve fairshare mekanizmalarının bir arada düşünülmesini gerektiren çok katmanlı bir süreçtir. Her kümenin iş yükü profili farklı olduğundan evrensel bir yapılandırma şablonu yoktur. Ancak bu yazıda paylaşılan prensipler ve örnekler, kendi sisteminiz için sağlam bir başlangıç noktası sunar.

Mevasis olarak SLURM yapılandırması ve HPC iş kuyruğu yönetimi konusunda size destek olmaktan memnuniyet duyarız. İletişim için formu doldurun.