Slurm ile HPC Küme Yönetimi: Kapsamlı Rehber

Slurm (Simple Linux Utility for Resource Management), günümüzde dünya genelindeki HPC kümelerinin %60’ından fazlasında kullanılan açık kaynaklı iş kuyruğu yöneticisidir. TOP500 süperbilgisayarlarından üniversite araştırma laboratuvarlarına, kurumsal AR-GE merkezlerinden yapay zeka eğitim altyapılarına kadar her ölçekteki hesaplama ortamında Slurm, kaynakların adil ve verimli paylaşımını sağlar.

Bu kapsamlı rehber, Slurm ile HPC küme yönetiminin tüm kritik yönlerini ele alır: mimari temellerden kurulum adımlarına, partition tasarımından GPU zamanlamaya, izleme altyapısından sık karşılaşılan sorunlara kadar. İster yeni bir küme kuruyor olun, ister mevcut Slurm altyapınızı optimize etmek isteyin, bu rehber size yol gösterecek.

Slurm Mimarisi: Temel Bileşenler

Slurm, modüler bir mimari üzerine inşa edilmiştir. Her bileşen belirli bir sorumluluğa sahiptir ve bileşenler arası iletişim MUNGE kimlik doğrulama altyapısıyla güvence altına alınmıştır.

graph TB
    subgraph "Kontrol Katmanı"
        slurmctld["slurmctld<br/>(Controller Daemon)"]
        slurmdbd["slurmdbd<br/>(Database Daemon)"]
        DB[("MySQL/MariaDB<br/>İş ve Hesap Veritabanı")]
    end

    subgraph "Kullanıcı Erişimi"
        USER["Kullanıcı / Login Node"]
    end

    subgraph "Hesaplama Katmanı"
        CN1["Compute Node 1<br/>slurmd"]
        CN2["Compute Node 2<br/>slurmd"]
        CN3["Compute Node N<br/>slurmd"]
        GPU1["GPU Node 1<br/>slurmd + GRES"]
    end

    USER -->|"sbatch / srun"| slurmctld
    slurmctld -->|"MUNGE kimlik doğrulama"| CN1
    slurmctld -->|"MUNGE kimlik doğrulama"| CN2
    slurmctld -->|"MUNGE kimlik doğrulama"| CN3
    slurmctld -->|"MUNGE kimlik doğrulama"| GPU1
    slurmctld -->|"İş ve hesap kaydı"| slurmdbd
    slurmdbd --> DB

slurmctld — Kontrol Daemon’ı

Slurm’ün beyni olan slurmctld, kümedeki tüm kaynakların durumunu izler, iş kuyruğunu yönetir ve zamanlama kararlarını verir. Her kümede yalnızca bir aktif controller bulunur; yüksek kullanılabilirlik için yedek controller yapılandırılabilir.

slurmctld‘nin başlıca sorumlulukları:

• Tüm düğümlerin durumunu takip etmek (idle, allocated, down, drain)
• Gelen işleri kuyruğa almak ve öncelik sırasına göre zamanlamak
• Partition ve QoS politikalarını uygulamak
• slurmdbd ile muhasebe verilerini senkronize etmek

slurmd — Düğüm Daemon’ı

Her hesaplama düğümünde çalışan slurmd, controller’dan gelen iş başlatma talimatlarını yerine getirir. İş başlatma, izleme ve sonlandırma işlemlerinden sorumludur. slurmd ayrıca düğümün kaynak durumunu (CPU, bellek, GPU kullanımı) periyodik olarak controller’a raporlar.

slurmdbd — Veritabanı Daemon’ı

slurmdbd, iş muhasebesi, kullanıcı hesapları, kota tanımları ve fair-share verilerini MySQL veya MariaDB veritabanında saklar. Bu bileşen olmadan sacct, sreport ve sshare gibi muhasebe komutları çalışmaz.

MUNGE — Kimlik Doğrulama

Tüm Slurm daemon’ları arasındaki iletişim MUNGE (MUNGE Uid ‘N’ Gid Emporium) ile şifrelenir ve kimlik doğrulanır. MUNGE anahtarı (/etc/munge/munge.key) tüm düğümlerde aynı olmalıdır; aksi halde slurmctld ile slurmd birbiriyle iletişim kuramaz.

Slurm Kurulumu: Adım Adım

Kurumsal ölçekte bir Slurm kurulumu aşağıdaki adımları takip eder. Bu adımları sırasıyla uygulayarak sağlam temelli bir iş kuyruğu altyapısı oluşturabilirsiniz.

1. Ön Hazırlık

Kuruluma başlamadan önce aşağıdaki soruları netleştirmeniz gerekir:

• Kaç düğüm, kaç çekirdek, ne kadar bellek?
• GPU düğümleri var mı; varsa hangi modeller ve kaç adet?
• Kaç kullanıcı/grup olacak; her grup hangi kaynaklara erişecek?
• Hangi yazılımlar çalışacak; lisans kısıtlamaları var mı?
• Mevcut bir iş kuyruğu sisteminden (PBS, LSF, SGE) geçiş mi yapılıyor?

Bu soruların cevapları, partition tasarımından QoS politikalarına kadar tüm yapılandırmayı etkiler. Yanlış boyutlandırılmış bir Slurm cluster yönetimi yaklaşımı, ya kaynak israfına ya da kullanıcı memnuniyetsizliğine yol açar. Mevasis olarak her Slurm projesine bu sorularla başlıyor, iş yükü analizi ve kapasite planlaması ile doğru mimariyi belirliyoruz.

2. MUNGE Kurulumu ve Anahtar Dağıtımı

# Controller node'da
yum install munge munge-libs munge-devel -y
dd if=/dev/urandom bs=1 count=1024 > /etc/munge/munge.key
chmod 400 /etc/munge/munge.key
chown munge:munge /etc/munge/munge.key
systemctl enable --now munge

# Anahtarı tüm compute node'lara kopyala
for node in cn{01..32}; do
  scp /etc/munge/munge.key ${node}:/etc/munge/
  ssh ${node} "chmod 400 /etc/munge/munge.key && \
               chown munge:munge /etc/munge/munge.key && \
               systemctl restart munge"
done

# Test: controller'dan bir compute node'a munge kimlik doğrulaması
munge -n | ssh cn01 unmunge
# Başarılı ise: STATUS: Success (0)

3. Slurm RPM Kurulumu

# Tüm düğümlerde
yum install slurm slurm-slurmctld slurm-slurmd \
            slurm-slurmdbd slurm-perlapi slurm-torque \
            slurm-openlava -y

4. slurm.conf — Ana Yapılandırma Dosyası

/etc/slurm/slurm.conf, Slurm’ün en kritik yapılandırma dosyasıdır. Aşağıda kurumsal bir küme için örnek bir yapılandırma verilmiştir:

# slurm.conf — Kurumsal HPC Kümesi
ClusterName=arastirma
SlurmctldHost=slurm-controller(10.0.0.10)
SlurmUser=slurm
SlurmctldPort=6817
SlurmdPort=6818
AuthType=auth/munge

# Zamanlama ve öncelik
SchedulerType=sched/backfill
SelectType=select/cons_tres
SelectTypeParameters=CR_Core_Memory

# Muhasebe
AccountingStorageType=accounting_storage/slurmdbd
AccountingStorageHost=slurm-controller
JobCompType=jobcomp/none

# Düğüm tanımları
NodeName=cn[01-24] CPUs=64 RealMemory=256000 Sockets=2 CoresPerSocket=32 \
        ThreadsPerCore=1 State=UNKNOWN
NodeName=gpu[01-04] CPUs=64 RealMemory=512000 Sockets=2 CoresPerSocket=32 \
        ThreadsPerCore=1 Gres=gpu:h100:8 State=UNKNOWN

# Partition tanımları
PartitionName=debug   Nodes=cn01         MaxTime=00:30:00 MaxNodes=1  Default=NO
PartitionName=short   Nodes=cn[02-24]    MaxTime=04:00:00 Default=YES
PartitionName=long    Nodes=cn[02-24]    MaxTime=7-00:00:00
PartitionName=gpu     Nodes=gpu[01-04]   MaxTime=24:00:00

ReturnToService=1

Partition Tasarımı: Tek Kuyruk Yetmez

Partition, Slurm’de düğümleri mantıksal gruplara ayıran ve her gruba farklı zamanlama politikası uygulayan yapıdır. İyi tasarlanmış bir partition mimarisi, küme kullanım verimliliğini dramatik ölçüde artırır.

Önerilen Partition Yapısı

Partition Tasarım Prensipleri

1. Debug partition her zaman ayrı olmalıdır. Test işleri üretim işlerinin kaynaklarını tüketmemelidir.
2. GPU partition’ı ayrı fiyatlandırma ağırlığına sahip olmalıdır. TRESBillingWeights ile GPU kullanımı daha yüksek maliyetli hale getirilebilir.
3. Default partition, en çok kullanılan partition olmalıdır. Kullanıcılar --partition belirtmediğinde iş otomatik olarak bu partition’a yönlendirilir.

İş Zamanlama ve Örnekler

Slurm’de iş göndermenin iki temel yolu vardır: toplu iş (batch) ve etkileşimli oturum.

Toplu İş Gönderimi (sbatch)

#!/bin/bash
#SBATCH --job-name=cfd_sim
#SBATCH --partition=long
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=64
#SBATCH --cpus-per-task=1
#SBATCH --time=48:00:00
#SBATCH --output=cfd_%j.out
#SBATCH --error=cfd_%j.err
#SBATCH --mail-type=END,FAIL
#SBATCH --mail-user=muhendis@kurum.com

module load openfoam/11.0
module load openmpi/4.1.5

mpirun -np 256 simpleFoam -parallel

GPU İş Gönderimi

#!/bin/bash
#SBATCH --job-name=gpu_train
#SBATCH --partition=gpu
#SBATCH --gres=gpu:h100:4
#SBATCH --nodes=1
#SBATCH --cpus-per-task=32
#SBATCH --mem=256G
#SBATCH --time=24:00:00

module load pytorch/2.4.0
module load cuda/12.4

torchrun --nproc_per_node=4 train.py --batch-size 128

İş Dizileri (Job Arrays)

Aynı işin farklı parametrelerle birden fazla kez çalıştırılması gerektiğinde job array kullanılır:

#!/bin/bash
#SBATCH --array=1-100
#SBATCH --partition=short
#SBATCH --ntasks=1
#SBATCH --time=01:00:00

INPUT_FILE="input_${SLURM_ARRAY_TASK_ID}.dat"
./simulate ${INPUT_FILE}

İş Takibi Komutları

# Kuyruktaki işleri listele
squeue -u $USER

# Kuyruk detayı (bekleme nedeni)
squeue -j 12345 --start

# İş ayrıntıları
scontrol show job 12345

# Kullanım muhasebesi
sacct -j 12345 --format=JobID,Elapsed,MaxRSS,State

# Kullanıcı veya grup bazlı kullanım raporu
sreport cluster UserUtilizationByAccount start=2026-07-01 end=2026-07-31

Cgroup Kaynak İzolasyonu

Cgroup (Control Groups), her Slurm işinin kaynak kullanımını Linux çekirdeği seviyesinde sınırlandıran kritik bir güvenlik ve kararlılık mekanizmasıdır. Cgroup olmadan, tek bir hatalı iş tüm düğümün belleğini tüketip diğer işleri çökertebilir.

Cgroup Yapılandırması

# /etc/slurm/cgroup.conf
CgroupAutomount=yes
ConstrainCores=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
ConstrainDevices=yes
AllowedDevicesFile=/etc/slurm/cgroup_allowed_devices

Bu yapılandırma ile:

• ConstrainCores=yes: Her iş yalnızca kendisine tahsis edilen CPU çekirdeklerini kullanabilir
• ConstrainRAMSpace=yes: İş tahsis edilenden fazla bellek kullanmaya çalışırsa OOM killer tarafından sonlandırılır
• ConstrainSwapSpace=yes: Swap kullanımı da sınırlandırılır, böylece bellek taşması durumunda dahi düğüm yavaşlamaz

Slurm’de GPU Yönetimi

GPU kaynakları, GRES (Generic Resource Scheduling) eklentisi üzerinden yönetilir. Her GPU fiziksel bir kaynak olarak tanımlanır ve Slurm bu kaynakların tahsisini, izolasyonunu ve muhasebesini yapar.

# slurm.conf — GPU desteği için
GresTypes=gpu

# gres.conf — Her GPU düğümünde
NodeName=gpu01 Name=gpu Type=h100 File=/dev/nvidia[0-7] Count=8
NodeName=gpu02 Name=gpu Type=a100 File=/dev/nvidia[0-3] Count=4

GPU İş Takibi

# GPU kullanımını görüntüle
scontrol show node gpu01 | grep Gres

# GPU kullanan işleri listele
squeue -p gpu --format="%.18i %.10P %.8j %.8u %.4D %.6C %.8t %.10M %b"

# GPU muhasebesi
sacct -X --format=JobID,User,AllocTRES,Elapsed --partition=gpu

Fair-Share, QoS ve Hesap Yönetimi

Slurm’ün en güçlü özelliklerinden biri, kaynakları kullanıcılar ve gruplar arasında adil dağıtma yeteneğidir. Bu mekanizma üç katmanda çalışır: hesap yönetimi (sacctmgr), hizmet kalitesi (QoS) ve fair-share önceliklendirme.

Her Slurm HPC cluster yönetimi stratejisinin temelinde, kaynakların adil paylaşımı yatar. Doğru yapılandırılmış bir QoS ve fair-share politikası olmadan, yoğun kullanıcılar istemeden de olsa tüm kümeyi meşgul edebilir ve diğer araştırmacıların işleri günlerce kuyrukta bekleyebilir.

Hesap ve Kota Yönetimi

# Araştırma grubu ve kullanıcı oluşturma
sacctmgr add account arastirma-grubu Description="A Grubu"
sacctmgr add user ali Account=arastirma-grubu

# Grup bazlı CPU-saat kotası (aylık)
sacctmgr modify account arastirma-grubu set GrpCPUMins=500000

# Kullanıcı bazlı iş limiti
sacctmgr modify user ali set MaxJobs=50 MaxSubmit=100

QoS (Quality of Service) Yapılandırması

QoS, partition’dan bağımsız olarak işlere öncelik seviyesi atamanızı sağlar:

# Yüksek öncelikli QoS
sacctmgr add qos yuksek-oncelik \
  Priority=1000 \
  MaxWall=48:00:00 \
  MaxJobsPU=10 \
  GrpTRES=cpu=256

# Kullanıcıyı QoS ile ilişkilendir
sacctmgr modify user ali set QOS=yuksek-oncelik

Fair-Share Algoritması

Fair-share, geçmiş kaynak kullanımına dayalı dinamik bir öncelik sistemidir. Çok kaynak kullanan grupların önceliği zamanla otomatik olarak düşer; az kullanan gruplar öne çıkar:

# Fair-share durumunu görüntüle
sshare -l --format=Account,User,RawShares,RawUsage,NormUsage,EffectvUsage,FairShare,LevelFS

# Öncelik faktörlerini ayarla (slurm.conf)
PriorityType=priority/multifactor
PriorityWeightFairshare=10000
PriorityWeightAge=1000
PriorityWeightJobSize=500

Bu üç mekanizma birlikte çalışarak, hiçbir kullanıcının veya grubun küme kaynaklarını tekelleştirememesini sağlar — tam bir Slurm HPC rehberinin olmazsa olmazıdır.

Lisans Yönetimi

Kurumsal HPC ortamlarında ANSYS, LS-DYNA, MATLAB ve Altair gibi pahalı mühendislik yazılımlarının lisansları genellikle sınırlı sayıdadır. Slurm, lisans yönetimini iş kuyruğuna entegre ederek lisans çakışmalarını ve aşırı kullanımı engeller.

# slurm.conf
LicenseName=ansys_hpc Total=32
LicenseName=lsdyna Total=16

# Lisans talep eden iş gönderimi
#SBATCH --licenses=ansys_hpc:4

# Lisans kullanım durumu
scontrol show licenses

Lisanslar tükendiğinde Slurm, sonraki işleri otomatik olarak beklemeye alır — bu sayede mühendisler manuel lisans takibi yapmak zorunda kalmaz.

İzleme ve Gözlemlenebilirlik

Sağlam bir HPC altyapısı, kapsamlı izleme olmadan eksiktir. Slurm metriklerini Prometheus ve Grafana ile toplamak, sorunları kullanıcı şikayeti gelmeden tespit etmenizi sağlar.

# prometheus.yml — Slurm metrik toplama
scrape_configs:
  - job_name: 'slurm'
    static_configs:
      - targets:
        - 'slurm-controller:9341'    # slurm_exporter
        - 'slurm-controller:9100'    # node_exporter
        - 'slurm-controller:9400'    # dcgm_exporter (GPU)
    scrape_interval: 30s

Kritik İzlenecek Metrikler

Grafana’da oluşturacağınız dashboard’larla bu metrikleri gerçek zamanlı izleyebilir, eşik aşımında Slack veya e-posta üzerinden otomatik bildirim alabilirsiniz. Aylık kapasite raporları için sreport komutunu kullanın:

# Aylık küme kullanım raporu
sreport cluster Utilization --start=2026-07-01 --end=2026-07-31

# Kullanıcı bazlı kullanım
sreport user TopUsage --start=2026-07-01 --end=2026-07-31 --topcount=10

Bu raporlar, kapasite planlaması ve bütçe kararları için somut veri sağlar — Slurm rehber niteliğindeki bu dokümanın en kritik bölümlerinden biridir.

Sık Karşılaşılan Sorunlar ve Çözümleri

Yıllar içinde kurumsal Slurm kurulumlarında en sık karşılaştığımız sorunlar ve çözümleri:

1. Düğümler Drain Durumuna Düşüyor

# Drain nedenini sorgula
scontrol show node cn05 | grep Reason

# Düğümü yeniden kullanıma aç
scontrol update NodeName=cn05 State=resume Reason="Sorun giderildi"

# slurmd loglarını incele
journalctl -u slurmd -n 100 --no-pager

En sık drain nedenleri: bellek taşması (OOM), slurmd iletişim kesintisi, donanım arızası (ECC bellek hatası).

2. İşler Sonsuza Kadar Pending Durumunda Kalıyor

# İşin neden beklemede olduğunu sorgula
squeue -j 12345 --start

# Yaygın nedenler:
# - Resources: yetersiz boş kaynak
# - Priority: daha yüksek öncelikli işler var
# - PartitionTimeLimit: iş süresi partition limitini aşıyor
# - QOSMaxWallDurationPerJobLimit: QoS süre limiti aşıldı

3. MUNGE Kimlik Doğrulama Hataları

# munge durumunu kontrol et
systemctl status munge

# Saat senkronizasyonunu kontrol et (MUNGE için kritik)
chronyc tracking

# munge anahtarını test et
munge -n | ssh cn01 unmunge

MUNGE, düğümler arası saat farkına karşı çok hassastır. Tüm düğümlerde NTP/Chrony’nin düzgün çalıştığından emin olun. Saat farkı 5 dakikayı aşarsa kimlik doğrulama başarısız olur.

4. GPU İşleri Başlatılamıyor

# GPU durumunu kontrol et
nvidia-smi

# GRES yapılandırmasını doğrula
scontrol show node gpu01 | grep Gres

# slurmd loglarında GPU hatası ara
journalctl -u slurmd | grep -i gpu

Mevasis ile Slurm Küme Yönetimi

Bu rehberde ele aldığımız tüm konular — mimari tasarım, kurulum, partition optimizasyonu, GPU yönetimi ve izleme — Mevasis’in kurumsal HPC hizmetlerinin temelini oluşturur.

12 yıllık HPC tecrübemizle, sıfırdan küme kurulumundan mevcut Slurm altyapısının optimizasyonuna, 7/24 yönetilen operasyon hizmetlerinden özel eğitim programlarına kadar her aşamada yanınızdayız.

• Slurm Hizmetlerimiz — Kurulum, danışmanlık ve yönetilen destek paketleri
• HPC Bakım ve Destek — Sürekli izleme ve proaktif müdahale
• HPC Eğitim — Sistem yöneticisi ve son kullanıcı eğitimleri

Projenizi görüşmek için ücretsiz keşif toplantısı planlayın. Mevcut altyapınızı değerlendirip size özel çözüm önerisi hazırlayalım.