SLURM Kurulum Rehberi: Partition, Cgroup, GPU GRES Yapılandırması

SLURM’ün temel komutlarına ve mimarisine önceki rehberimizden aşinaysanız, bu yazıda bir adım ileri gidiyoruz: production HPC kümelerinde karşılaştığımız gerçek kurulum ve yapılandırma senaryolarını ele alıyoruz. Partition tasarımından GPU kaynak yönetimine, MUNGE kimlik doğrulamadan Prometheus izlemeye kadar kurumsal ölçekte SLURM’ü sağlam temellere oturtmak için dikkat edilmesi gereken tüm noktaları paylaşıyoruz.

Önce Mimari: Ne Koyacağınızı Bilin

Kuruluma geçmeden önce şu sorulara yanıt vermek kritiktir:

Kaç kullanıcı/grup var ve hangisi hangi kaynaklara erişebilir?
Hangi yazılımlar çalışacak, kaç eş zamanlı lisans var? (ANSYS, LS-DYNA, OpenFOAM, MATLAB…)
GPU düğümleri var mı? Nasıl faturalanacak?
Mevcut iş yöneticisi varsa geçiş nasıl yapılacak?

Bu kararlar netleşmeden kuruluma başlamak, ileride her şeyi yeniden yapılandırmak anlamına gelir.

MUNGE: Temel Güvenlik Katmanı

SLURM daemon’ları arasındaki iletişim MUNGE ile şifrelenir. Tüm düğümlerde aynı MUNGE anahtarı bulunmalıdır; aksi hâlde slurmctld ile slurmd birbirini tanımaz.

# Controller node'da anahtar oluştur
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

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

OpenLDAP entegrasyonu istiyorsanız kullanıcı hesaplarını merkezi dizinden senkronize edecek biçimde yapılandırın. Bu adım atlandığında küme büyüdükçe kullanıcı yönetimi kaosa dönüşür.

Partition Mimarisi: Tek Kuyruk Yetmez

Gerçek dünya HPC kümelerinde tüm işleri tek bir kuyruğa yığmak yerine partition yapısı kurulur. Her partition farklı politikalar, kaynak limitleri ve öncelikler taşır.

# /etc/slurm/slurm.conf — örnek partition tanımları
PartitionName=short   Nodes=cn[01-08] MaxTime=04:00:00 Default=YES Priority=100
PartitionName=long    Nodes=cn[01-08] MaxTime=7-00:00:00             Priority=50
PartitionName=gpu     Nodes=gpu[01-02] MaxTime=24:00:00 TRESBillingWeights="CPU=1,GRES/gpu=10"
PartitionName=debug   Nodes=cn01       MaxTime=00:30:00 MaxNodes=1   Priority=200

Bu yapıyla:

Kısa testler debug partition’ında anında çalışır
Uzun simülasyonlar long partition’ında arka plana alınır
GPU düğümleri ayrı muhasebe politikasıyla faturalanır

Cgroup: Kaynak İzolasyonu Olmadan SLURM Eksik Kalır

Modern SLURM kurulumlarında her iş Linux cgroup’larıyla izole edilir. Cgroup olmadan tek bir hatalı iş tüm düğümün belleğini tüketerek diğer işleri çökertebilir.

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

ConstrainRAMSpace=yes ile bir iş talep ettiğinden fazla bellek tüketmeye çalıştığında SLURM önce uyarır, ardından işi sonlandırır — tüm düğümü değil.

GPU Kaynakları: GRES Yapılandırması

GPU içeren düğümlerde SLURM’ün GRES (Generic Resource) eklentisi devreye girer. Her GPU ayrı bir kaynak olarak tanımlanır.

# slurm.conf'a eklenecek
GresTypes=gpu

# gres.conf (her GPU node'unda)
NodeName=gpu01 Name=gpu Type=a100 File=/dev/nvidia[0-3] Count=4
NodeName=gpu02 Name=gpu Type=h100 File=/dev/nvidia[0-7] Count=8

Kullanıcılar iş gönderirken kaç GPU istediklerini açıkça belirtir:

#SBATCH --gres=gpu:a100:2   # 2 adet A100 GPU talep et
#SBATCH --partition=gpu

Bu olmadan kullanıcılar GPU atamalarını kendileri yapmak zorunda kalır ve çakışmalar kaçınılmaz olur.

slurmdbd veritabanıyla her kullanıcıya ve gruba kaynak limitleri atanır:

# Araştırma grubu oluştur
sacctmgr add account araştirma-a Description="Araştırma Grubu A"

# Kullanıcı ekle ve CPU-saat kotası belirle
sacctmgr add user ali Account=araştirma-a MaxCPUMins=100000

# Öncelik ağırlıklarını ayarla
sacctmgr modify account araştirma-a set GrpCPUMins=500000 Priority=100

Fair-share mekanizması çok kaynak kullanan grupların önceliğini otomatik olarak düşürür; uzun vadede tüm kullanıcılar eşit erişim hakkı elde eder.

Sık Karşılaşılan Sorunlar

Kurumsal SLURM kurulumlarında yıllar içinde en sık karşılaştığımız sorunlar:

Sorun	Neden Olur	Çözüm
Düğümler `drain` durumuna düşüyor	Bellek taşması, donanım hatası, iletişim kesintisi	`scontrol update NodeName=cn01 State=resume`; `slurmd` loglarını incele
İşler sonsuza kadar `pending` kalıyor	Yetersiz kaynak veya partition politika uyumsuzluğu	`squeue -j <jobid> --start` ile bekleme nedenini sorgula
Öncelik dengesizliği	Fair-share ağırlıkları yanlış ayarlanmış	`sshare -l` ile grup kullanımını incele
Lisans çakışması	Yazılım lisans sunucusu SLURM ile entegre değil	`sbatch --licenses=ansys_hpc:4` ile talep kontrolü ekle

Prometheus + Grafana ile İzleme

SLURM metriklerini Prometheus exporter ile toplayıp Grafana’da görselleştirmek, sorunları kullanıcı şikayeti gelmeden tespit etmenizi sağlar.

# prometheus.yml
scrape_configs:
  - job_name: 'slurm'
    static_configs:
      - targets: ['slurm-controller:9341']

Takip edilmesi gereken kritik metrikler:

slurm_queue_pending — kuyrukta bekleyen iş sayısı
slurm_node_state — drain/down düğümler
slurm_job_run_time — ortalama çalışma süreleri
slurm_gpu_utilization — GPU kullanım oranları

Bir düğüm hizmetten çıktığında veya kuyruk bekleme süresi eşiği aştığında PagerDuty veya Slack üzerinden otomatik bildirim gönderilebilir.

Mevasis ile SLURM Kurulumu

Her SLURM kurulumunu müşterinin iş yüklerine ve kullanıcı profiline özel politika tasarımıyla birlikte teslim ediyoruz. Kurulum sonrasında HPC bakım paketlerimizle kümenizin sağlığını uzaktan izliyor, sorunları proaktif olarak çözüyor ve SLURM sürüm güncellemelerini yönetiyoruz.

Sıfırdan kurulum, mevcut kurulumu kurtarma veya performans optimizasyonu için iletişim sayfamızı ziyaret edin — size özel teklifimizi iki iş günü içinde iletiyoruz.

SLURM Kurulum ve Yapılandırma Rehberi: Partition, Cgroup, GPU ve İzleme