İş Kuyruğu Tasarımı: Partition, QOS ve Öncelik Mimarisi

Modern HPC kümelerinde hesaplama kaynaklarını verimli kullanmak, sadece donanım kapasitesinin değil, iş kuyruğu mimarisinin de bir fonksiyonudur. Yüzlerce kullanıcının aynı anda iş gönderdiği bir ortamda kimin ne zaman hangi kaynakları alacağını belirleyen kurallar bütünü; ekiplerin üretkenliğini, adalet anlayışını ve küme verimliliğini doğrudan etkiler. Bu yazıda SLURM özelinde partition yapısı, QOS hiyerarşisi, preemption mekanizması ve backfill politikalarını tasarım perspektifinden ele alacağız.

Partition Tasarımı: Kaynakları Mantıksal Olarak Bölmek

Partition, SLURM’ın temel yapı taşlarından biridir. Bir partition; hangi düğümleri kapsadığını, bu düğümlerde hangi sınırlara tabi olunacağını ve varsayılan kaynak limitlerinin ne olacağını tanımlar. İyi tasarlanmış bir partition yapısı, kullanıcıların doğru kaynağa kolayca ulaşmasını sağlarken yöneticilere granüler kontrol sunar.

Partition Türleri ve Kullanım Senaryoları

Pratikte çoğu küme birden fazla partition kullanır ve her biri farklı bir iş profilini hedefler:

Bu yapıda interactive partition küçük ve hızlı bir kaynak havuzuna sahipken preemptable partition, boştaki tüm düğümleri kullanabilir ancak öncelikli işler geldiğinde kesilmeye açıktır.

slurm.conf İçinde Partition Tanımı

# /etc/slurm/slurm.conf

PartitionName=interactive Nodes=node[01-04] Default=NO MaxTime=04:00:00 \
  State=UP DefMemPerCPU=4096 Priority=100

PartitionName=short Nodes=node[01-32] Default=YES MaxTime=1-00:00:00 \
  State=UP DefMemPerCPU=4096 Priority=50

PartitionName=long Nodes=node[01-32] Default=NO MaxTime=7-00:00:00 \
  State=UP DefMemPerCPU=4096 Priority=20

PartitionName=gpu Nodes=gpu[01-08] Default=NO MaxTime=2-00:00:00 \
  State=UP DefMemPerCPU=8192 Priority=50

PartitionName=highmem Nodes=bigmem[01-04] Default=NO MaxTime=2-00:00:00 \
  State=UP DefMemPerCPU=32768 Priority=50

PartitionName=preemptable Nodes=node[01-32],gpu[01-08] Default=NO \
  MaxTime=UNLIMITED State=UP Priority=1 PreemptMode=REQUEUE

Burada PreemptMode=REQUEUE ayarı sayesinde bir iş kesildiğinde kuyrukta bekler ve uygun düğüm açıldığında otomatik olarak yeniden başlar. Bu, uzun süren analizler için önemlidir çünkü tüm ilerlemenin sıfırlanmasını önler; yeter ki uygulama checkpoint desteğine sahip olsun.

QOS Hiyerarşisi: İnce Taneli Kaynak Kontrolü

Partition yapısı küme genelinde kaba bir ayrım sağlarken QOS (Quality of Service) katmanı bireysel kullanıcı veya grup düzeyinde sınırlar ve ayrıcalıklar tanımlamayı mümkün kılar. QOS, partition ile birlikte çalışır ve ikisi arasındaki en kısıtlayıcı kural geçerli olur.

QOS Düzeyleri ve Sınırlar

Tipik bir akademik ya da kurumsal HPC ortamında üç katmanlı bir QOS hiyerarşisi işlevsel sonuçlar üretir:

Temel Kullanıcı QOS (normal)

• Maksimum eş zamanlı çalışan iş sayısı: 10
• Maksimum CPU çekirdeği: 256
• Maksimum bellek: 1 TB
• Öncelik çarpanı: 1.0

Araştırma Grubu QOS (group_standard)

• Maksimum eş zamanlı çalışan iş sayısı: 30
• Maksimum CPU çekirdeği: 1024
• Öncelik çarpanı: 1.5

Öncelikli Kullanıcı QOS (priority_user)

• Hızlı başlangıç için rezervasyon hakkı
• Preemption koruması
• Öncelik çarpanı: 3.0

# QOS tanımları sacctmgr ile oluşturulur

sacctmgr add qos normal \
  MaxJobsPerUser=10 MaxTRESPerUser=cpu=256,mem=1000G \
  Priority=10

sacctmgr add qos group_standard \
  MaxJobsPerUser=30 MaxTRESPerUser=cpu=1024 \
  Priority=15 Flags=DenyOnLimit

sacctmgr add qos priority_user \
  MaxJobsPerUser=50 MaxTRESPerUser=cpu=2048 \
  Priority=30 Flags=NoReserve

# Kullanıcıya QOS atama
sacctmgr modify user ahmet where account=researchgroup \
  set qos=normal,group_standard DefaultQOS=group_standard

DenyOnLimit bayrağı önemlidir: bu bayrak olmadan SLURM bir QOS sınırına ulaşıldığında işi otomatik olarak düşük öncelikli bir QOS’a düşürmeye çalışır. DenyOnLimit ile iş, sınır aşıldığında reddedilir ve kullanıcı açık bir hata mesajı alır. Bu, özellikle faturalandırma modeli olan sistemlerde tercih edilir.

Fairshare ve Öncelik Hesabı

SLURM’ın çok faktörlü öncelik sistemi birkaç bileşeni bir arada değerlendirir:

Job Priority = (PriorityWeightAge × Age Factor)
             + (PriorityWeightFairshare × Fairshare Factor)
             + (PriorityWeightJobSize × Job Size Factor)
             + (PriorityWeightPartition × Partition Factor)
             + (PriorityWeightQOS × QOS Factor)

Fairshare faktörü, bir grubun tahsis edilen kaynakların ne kadarını kullandığını tarihsel olarak izler. Az kullananlar yüksek fairshare skoru alır, bu da kuyruktaki işlerinin önce çalışmasını sağlar. Decay faktörü eski kullanımın etkisini zamanla azaltarak sistemi dengede tutar.

# slurm.conf içinde öncelik ağırlıkları
PriorityType=priority/multifactor
PriorityWeightAge=1000
PriorityWeightFairshare=10000
PriorityWeightJobSize=100
PriorityWeightPartition=1000
PriorityWeightQOS=5000
PriorityDecayHalfLife=7-0        # 7 günde yarılanma
PriorityMaxAge=7-0

Bu yapılandırmada fairshare ağırlığı diğer faktörlerin önüne geçer. Uzun süre hiç iş göndermemiş bir araştırmacı yüksek öncelik kazanarak birikmiş kaynak hakkını kullanabilir.

Preemption: Acil İşleri Öne Almak

Preemption, yüksek öncelikli bir işin çalışmakta olan düşük öncelikli işleri kesebilmesi mekanizmasıdır. Doğru yapılandırılmadığında kaotik sonuçlar doğurabilir; ancak iyi tasarlandığında küme verimliliğini ciddi ölçüde artırır.

Preemption Modları

SLURM üç preemption modu sunar:

• CANCEL: Düşük öncelikli iş sonlandırılır, kurtarılamaz.
• REQUEUE: İş durdurulur ve kuyruğa geri alınır. Checkpoint gerektirmez.
• CHECKPOINT: Uygulama checkpoint alır, daha sonra kaldığı yerden devam eder.

Çoğu ortam için REQUEUE en dengeli seçenektir. Kullanıcı hesabı ücretlendirilmemiş çalışma süresini kaybetmez ve iş sistem açıldığında otomatik olarak devam eder.

# Preemption hiyerarşisi tanımı
# Hangi QOS hangi QOS'u preempt edebilir?

sacctmgr modify qos priority_user set Preempt=normal,group_standard
sacctmgr modify qos group_standard set Preempt=normal

# Partition düzeyinde preemption etkinleştirme
# slurm.conf
PreemptType=preempt/qos
PreemptMode=REQUEUE
PreemptExemptTime=300   # İlk 5 dakika preempt edilemez

PreemptExemptTime parametresi küçük ama kritik bir ayardır. Yeni başlayan bir iş hemen preempt edilirse başlangıç maliyeti boşa gider. Bu değer sayesinde iş en az 5 dakika çalışmadan kesilemez.

Backfill Zamanlayıcısı: Boşlukları Doldurmak

SLURM’ın ana zamanlayıcısı işleri öncelik sırasıyla çalıştırır. Backfill zamanlayıcısı ise bu sıranın önüne geçmeden, yakında kaynak açılacaksa küçük işleri bu boşluklara yerleştirerek küme kullanımını optimize eder.

Örneğin 2 saate kadar çalışan yüksek öncelikli bir iş, 1 saat sonra biteceği bilinen bir düğümü bekliyor olabilir. Backfill zamanlayıcısı bu aralığa 30 dakikalık küçük bir işi yerleştirebilir; bu sayede hem büyük iş zamanında başlar hem de kaynak boşta kalmamış olur.

# slurm.conf backfill ayarları
SchedulerType=sched/backfill
SchedulerParameters=bf_max_job_test=1000,bf_resolution=600,\
  bf_max_time=60,bf_continue,bf_window=2880

# bf_max_job_test: Her backfill döngüsünde değerlendirilen iş sayısı
# bf_resolution: Zaman çözünürlüğü (saniye)
# bf_max_time: Backfill hesaplaması için maksimum süre (saniye)
# bf_window: İleriye bakış penceresi (dakika, burada 48 saat)

bf_continue parametresi özellikle büyük kümeler için önemlidir: bir backfill döngüsü tamamlanmadan bile bulunan uygun işler çalıştırılmaya başlanır; yönetim düğümünde gereksiz yük oluşmaz.

Tasarım Prensipleri ve Yaygın Hatalar

Önce Kullanıcı Profillerini Anlayın

Partition ve QOS tasarımına başlamadan önce kümedeki iş profillerini analiz etmek gerekir. Çoğu kullanıcı kısa işler mi gönderiyor? GPU işleri öncelikli mi? Birkaç büyük kullanıcı mı yoksa yüzlerce küçük kullanıcı mı var? Bu sorulara verilen yanıtlar doğrudan mimariyi şekillendirir.

Çok Karmaşık Yapılardan Kaçının

Onlarca partition ve QOS kombinasyonu, yönetimi güçleştirir ve kullanıcıların doğru seçimi yapmasını zorlaştırır. Başlangıçta sade bir yapı kurup zaman içinde ihtiyaca göre genişletmek, tersinden başlamaktan çok daha sağlıklı sonuç verir.

Limitleri Gerçekçi Tutun

Çok düşük limitler kullanıcıları kısıtlar ve geçici çözüm aramaya iter; çok yüksek limitler ise kaynakların tek bir kullanıcı tarafından monopolize edilmesine neden olur. İdeal limit, tarihi kullanım verilerine dayandırılmalıdır.

İzleme ve Raporlamayı İhmal Etmeyin

# Kuyruk durumunu analiz etmek için faydalı komutlar
squeue --format="%.18i %.9P %.8j %.8u %.8T %.10M %.9l %.6D %R" --sort=-p
sshare -a -l       # Fairshare durumu
sprio -l           # Öncelik bileşenlerini göster
sacct -S 2026-06-01 --format=JobID,Partition,QOS,State,CPUTime

Bu komutlardan elde edilen veriler düzenli olarak incelendiğinde tasarım kararlarının doğruluğu test edilebilir ve gerekli iyileştirmeler yapılabilir.

Sonuç

Etkili bir SLURM iş kuyruğu mimarisi; partition tanımları, QOS hiyerarşisi, preemption politikaları ve backfill ayarlarının birlikte düşünülmesini gerektirir. Her kümenin kendine özgü iş profili ve kullanıcı topluluğu vardır; bu nedenle tek bir evrensel yapılandırma yoktur. Önemli olan, tasarım kararlarını verilerle desteklemek, değişiklikleri küçük adımlarla uygulamak ve sistemin davranışını sürekli izlemektir.

Mevasis olarak SLURM iş kuyruğu tasarımı ve HPC küme mimarisi konusunda size destek olmaktan memnuniyet duyarız. İletişim için formu doldurun.