Çok Kiracılı HPC: Kaynak İzolasyonu ve Adil Paylaşım

Bir üniversitenin HPC kümesini düşünün: biyoinformatik grubu gece boyunca RNA-seq analizi koşturuyor, makine öğrenmesi ekibi sabah GPU’ları doldurdu, mühendislik bölümü ise CFD simülasyonları için haftalarca kaynak istiyor. Tüm bu gruplar aynı donanımı paylaşıyor; ama kimse kimsenin işini engellemeden çalışmak istiyor. İşte bu senaryo, çok kiracılı (multi-tenant) HPC’nin tam ortasıdır.

Bu yazıda SLURM’ün sunduğu hesap (accounting), fairshare, QOS ve cgroups tabanlı izolasyon mekanizmalarını pratik yapılandırma örnekleriyle ele alacağız.

Çok Kiracılılık Neden Karmaşıktır?

Tek kullanıcılı bir sistemde zamanlama kararı basittir: boş kaynak varsa çalıştır, yoksa beklet. Birden fazla kiracı (grup, proje veya departman) devreye girdiğinde tabloya birkaç gerilim eklemlenir:

• Adillik: Bir grubun kısa vadeli aşırı kullanımı uzun vadede diğerlerini nasıl etkiler?
• İzolasyon: Bir işin bellek sızıntısı komşu işi çökertiyor mu?
• Öncelik: Acil analiz mi, yoksa haftadır bekleyen toplu iş mi önce çalışsın?
• Görünürlük: Her kiracı yalnızca kendi işlerini mi, yoksa tüm kuyruğu mu görmeli?

SLURM bu soruların tamamına yanıt üretecek araçlara sahiptir; ancak bu araçları birlikte ve tutarlı biçimde yapılandırmak gerekir.

Accounting ile Hiyerarşik Hesap Yapısı

Her şeyin temeli SLURM’ün muhasebe (accounting) katmanıdır. slurmdbd servisi kullanıcı, grup ve kullanım verilerini bir veritabanında saklar; fairshare ve QOS politikaları bu verilere dayanır.

Hesap Hiyerarşisi Oluşturma

Tipik bir üniversite yapısı şöyle modellenebilir:

# Kök hesabı oluştur
sacctmgr add account root_cluster Description="Küme kökü"

# Bölüm hesapları
sacctmgr add account bioinformatics \
    Parent=root_cluster \
    Description="Biyoinformatik Bölümü" \
    Fairshare=40

sacctmgr add account ml_lab \
    Parent=root_cluster \
    Description="Makine Öğrenmesi Laboratuvarı" \
    Fairshare=35

sacctmgr add account engineering \
    Parent=root_cluster \
    Description="Mühendislik Bölümü" \
    Fairshare=25

# Kullanıcı ekleme (hesaba bağlı)
sacctmgr add user alice Account=bioinformatics DefaultAccount=bioinformatics
sacctmgr add user bob   Account=ml_lab       DefaultAccount=ml_lab
sacctmgr add user carol Account=engineering  DefaultAccount=engineering

# Kaynak limiti atama (opsiyonel, hesap düzeyinde)
sacctmgr modify account bioinformatics \
    set GrpCPUs=512 GrpMem=2048G GrpGRES=gpu:8

Fairshare değerleri ağırlıklı pay olarak düşünülebilir: toplam 100 birimden bioinformatics 40, ml_lab 35, engineering 25 birim alır. Bu değerler mutlak kaynak tahsisi değil, öncelik hesabında kullanılan göreceli ağırlıklardır.

Kullanım Durumunu Sorgulamak

# Hesap bazlı kullanım özeti
sreport cluster AccountUtilizationByUser Start=2026-06-01 End=2026-06-17

# Fairshare değerlerini görüntüle
sshare -A bioinformatics,ml_lab,engineering -l

Fairshare: Geçmiş Kullanım ve Gelecek Öncelik

Fairshare mekanizması, bir grubun geçmişte hak ettiğinden fazla kaynak kullanıp kullanmadığına bakarak gelecekteki iş önceliğini ayarlar. Çok kullanan grupta öncelik düşer; az kullanan grupta yükselir. Bu sayede zaman içinde her grup yaklaşık olarak kendine ayrılan payı kullanmış olur.

Öncelik Hesabı

SLURM’ün çok faktörlü öncelik sistemi (PriorityType=priority/multifactor) şu bileşenlerden oluşur:

slurm.conf içinde bu ağırlıklar şöyle tanımlanır:

PriorityType=priority/multifactor
PriorityWeightFairshare=30
PriorityWeightAge=20
PriorityWeightJobSize=5
PriorityWeightQOS=30
PriorityWeightPartition=15

# Fairshare çürümesi: eski kullanım verisi zamanla silinir (gün cinsinden)
PriorityDecayHalfLife=14-0
PriorityUsageResetPeriod=NONE

PriorityDecayHalfLife=14-0 ile 14 gün önceki kullanım etkisi yarıya iner; bu parametre “hafıza uzunluğunu” belirler. Kısa yarı ömür kısa vadeli adilliği, uzun yarı ömür uzun vadeli dengeyi öne çıkarır.

QOS: İnce Ayarlı Politika Katmanı

Quality of Service (QOS) katmanı, hesap hiyerarşisinin üzerine binen ek kısıtlama ve ayrıcalık mekanizmasıdır. Bir kullanıcıya veya hesaba birden fazla QOS atanabilir; iş gönderilirken hangi QOS’un kullanılacağı seçilir.

QOS Tanımları

# Normal kullanım için standart QOS
sacctmgr add qos normal \
    Priority=10 \
    MaxWall=7-00:00:00 \
    MaxCPUsPerUser=256 \
    MaxGRESPerUser="gpu:4"

# Kısa süreli yüksek öncelikli işler için "burst" QOS
sacctmgr add qos burst \
    Priority=50 \
    MaxWall=04:00:00 \
    MaxCPUsPerUser=512 \
    MaxJobsPerUser=2 \
    Preempt=normal \
    PreemptMode=requeue

# Uzun süreli düşük öncelikli arka plan işleri
sacctmgr add qos background \
    Priority=1 \
    MaxWall=30-00:00:00 \
    MaxCPUsPerUser=1024 \
    GraceTime=00:30:00

# Hesaplara QOS atama
sacctmgr modify account bioinformatics set QOS=normal,background
sacctmgr modify account ml_lab        set QOS=normal,burst,background

İş Gönderirken QOS Belirtme

sbatch --qos=burst --time=02:00:00 --ntasks=64 my_analysis.sh

burst QOS’u normal işleri preempt edebilir (kuyruğa geri alabilir) ancak en fazla 4 saat çalışabilir ve kullanıcı başına en fazla 2 iş açık olabilir. Bu yapı, acil analiz ihtiyaçlarına hızlı yanıt verirken sistemin uzun süreli arka plan işlerini de barındırmasını sağlar.

Kaynak İzolasyonu: cgroups ile Bellek ve CPU Sınırlaması

Fairshare ve QOS politikaları zamanlama katmanında çalışır; bir işin gerçekte ne kadar kaynak tükettiğini sınırlamaz. Gerçek izolasyon için Linux cgroups entegrasyonu gerekir.

slurm.conf ve cgroup.conf Yapılandırması

# slurm.conf içinde
TaskPlugin=task/cgroup
ProctrackType=proctrack/cgroup

# cgroup.conf dosyası
CgroupMountpoint=/sys/fs/cgroup
CgroupAutomount=yes
ConstrainCores=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
ConstrainDevices=yes

# Bellek aşımında işi sonlandır (kill), bekletme
MemorySwappiness=0
AllowedRAMSpace=100
AllowedSwapSpace=0

Bu yapılandırmayla SLURM, bir işe atanan CPU çekirdeklerini ve bellek miktarını cgroup hiyerarşisi aracılığıyla zorla uygular. Bir iş --mem=64G ile gönderildiyse 64 GB’ın üstünü kullanamaz; kernel bu sınırı doğrudan uygular.

GPU İzolasyonu

GPU’lar için gres.conf ile donanım bağlayıcılarını ve NVIDIA MIG (Multi-Instance GPU) dilimlerini tanımlayabilirsiniz:

# GRES yapılandırması (gres.conf)
AutoDetect=nvml
Name=gpu Type=a100 File=/dev/nvidia[0-7]

# MIG dilimlerini iş script'inde kullanma
#SBATCH --gres=gpu:a100:1
#SBATCH --constraint=mig_3g.40gb

Görünürlük ve Veri Erişim Kontrolü

Çok kiracılı sistemlerde bir grubun işlerini başka bir grup görmemeli ya da iş çıktılarına erişmemelidir. Bu iki katmanda ele alınır:

SLURM düzeyinde: PrivateData parametresi ile kullanıcılar yalnızca kendi iş bilgilerini görebilir:

# slurm.conf
PrivateData=jobs,usage,users

Dosya sistemi düzeyinde: Her grubun çalışma dizini Unix grup izinleri veya ACL’lerle korunmalıdır:

# Grup çalışma dizini oluşturma
mkdir -p /scratch/bioinformatics
chown root:bioinformatics /scratch/bioinformatics
chmod 2770 /scratch/bioinformatics    # setgid bit: alt dosyalar grubu miras alır

Paralel dosya sistemlerinde (Lustre, GPFS) kota yönetimi ek bir katman sunar:

# Lustre proje kotası
lfs setquota -p 1001 --block-softlimit 10T --block-hardlimit 12T /scratch

Pratik İzleme: Sistem Yöneticisi Perspektifi

Çok kiracılı bir sistemi sağlıklı tutmak gerçek zamanlı izleme gerektirir. Birkaç temel komut:

# Tüm hesapların anlık fairshare durumu
sshare -a -l | sort -k7 -n

# Hesap bazlı kuyruk derinliği
squeue -o "%.18i %.9P %.8j %.8u %.8a %.2t %.10M %.6D %R" | column -t

# Son 24 saatin CPU ve GPU kullanımı (hesap bazlı)
sreport cluster AccountUtilizationByUser \
    Start=$(date -d '24 hours ago' +%Y-%m-%dT%H:%M) \
    End=$(date +%Y-%m-%dT%H:%M) \
    Format=Accounts,Login,Used

# Bekleme süresi istatistikleri
sacct -a --starttime=2026-06-01 \
    --format=Account,User,JobID,Submit,Start,Elapsed,CPUTimeRAW \
    --state=COMPLETED | awk 'NR>2 {print $1, $2, $7}'

Bu çıktıları bir izleme panosuna (Grafana + Prometheus + SLURM exporter) aktarmak, sorunları iş sona ermeden önce fark etmenizi sağlar.

Yaygın Tuzaklar ve Çözümleri

Fairshare değerlerini hiç güncellememek: Yıllar içinde grupların kaynak ihtiyaçları değişir. Altı ayda bir fairshare ağırlıklarını gözden geçirin.

QOS limitsiz bırakmak: MaxCPUsPerUser veya MaxWall tanımlanmamış bir QOS, bir kullanıcının tüm kümeyi doldurmasına izin verir. Her QOS’un mutlaka bir üst sınırı olsun.

cgroups olmadan bellek limiti: --mem parametresi SLURM’e bildirim niteliğindedir; cgroups yapılandırılmamışsa bellek aşımını kernel değil, ancak bir sonraki zamanlama döngüsü fark eder. Gerçek izolasyon için ConstrainRAMSpace=yes şarttır.

Preemption politikasını belgesiz bırakmak: Bir işin preempt edilebileceğini bilmeyen kullanıcı, işi checkpoint almadan yazar ve yeniden başlatmada saatler kaybeder. Kullanıcı belgelerinde hangi QOS’un preempt edebileceğini açıkça belirtin.

Sonuç

Çok kiracılı bir HPC kümesini başarıyla işletmek; donanımı satın almaktan çok daha fazlasını gerektirir. SLURM’ün accounting, fairshare, QOS ve cgroups katmanlarını birlikte ve tutarlı biçimde yapılandırmak, hem sistem yöneticilerine hem de araştırmacılara tahmin edilebilir, adil ve izole bir çalışma ortamı sunar.

Mevasis olarak çok kiracılı HPC mimarisi, SLURM yapılandırması ve kaynak izolasyonu konusunda size destek olmaktan memnuniyet duyarız. İletişim için formu doldurun.