HPC İş Kuyruğu Yöneticisi: SLURM Kurulum ve Yapılandırma

HPC kümelerinde hesaplama işlerini manuel olarak yönetmek, onlarca düğüm ve yüzlerce eş zamanlı iş söz konusu olduğunda hızla sürdürülemez hale gelir. İş kuyruğu yöneticileri (job scheduler veya workload manager) bu karmaşıklığı çözmek için tasarlanmış özel yazılım katmanlarıdır. Bu rehberde SLURM başta olmak üzere önde gelen iş zamanlayıcılarının mimarisini, kurulum sürecini, sık karşılaşılan sorunları ve en iyi uygulamaları ele alıyoruz.

Mimari ve Bileşenler

SLURM Mimarisi

SLURM (Simple Linux Utility for Resource Management), merkezi denetleyici-işçi mimarisi üzerine kuruludur. Temel bileşenleri şöyle sıralanabilir:

slurmctld: Ana denetleyici daemon; iş kuyruğunu, kaynak tahsisini ve zamanlama kararlarını yönetir. Yüksek erişilebilirlik için yedek denetleyici (backup controller) yapılandırılabilir.
slurmd: Her hesaplama düğümünde çalışan işçi daemon; slurmctld ile haberleşir, işleri başlatır ve kaynak kullanımını raporlar.
slurmdbd: Muhasebe veritabanı daemon; iş geçmişini, kullanıcı istatistiklerini ve fair-share hesaplamalarını MariaDB veya MySQL üzerinde saklar.
Munge: Küme içi kimlik doğrulama servisi; daemon’lar arasındaki iletişimi imzalanmış token’larla güvence altına alır.

PBS Pro ve LSF Farkları

PBS Pro, SLURM’a benzer şekilde merkezi pbs_server ve düğüm tarafında pbs_mom daemon’larını kullanır. IBM Spectrum LSF ise mbatchd (yönetim daemon) ve sbatchd (sunucu daemon) çiftiyle çalışır. Her üç platform da çok düğümlü MPI işlerini ve GPU tahsisini destekler; ancak yapılandırma dosyası biçimleri ve politika dilleri birbirinden önemli ölçüde ayrışır.

Kurulum ve Yapılandırma Adımları

Ön Gereksinimler

Kuruluma başlamadan önce aşağıdakilerin tamamlanmış olması gerekir:

Tüm düğümlerde eşleşen kullanıcı/grup UID’leri (NIS, LDAP veya statik /etc/passwd)
NTP ile senkronize edilmiş sistem saatleri (fark 1 saniyenin altında olmalı)
Paylaşımlı dosya sistemi (NFS, Lustre veya GPFS) üzerinde ortak /etc/munge/munge.key
Düğümler arası düşük gecikmeli ağ (InfiniBand veya yüksek hızlı Ethernet)

Partition ve QOS Tasarımı

Partition (kuyruk) tasarımı, zamanlayıcı yapılandırmasının en kritik adımlarından biridir. Tipik bir akademik küme için önerilen yapı:

debug partition: Kısa süreli test işleri için ayrılmış birkaç düğüm, maksimum 1 saat
normal partition: Genel amaçlı CPU işleri, maksimum 48-72 saat
gpu partition: GPU’lu düğümler, makine öğrenmesi ve simülasyon işleri
bigmem partition: Yüksek bellekli düğümler, genomik ve CFD uygulamaları
long partition: Uzun süreli işler için düşük öncelikli kuyruk, maksimum 7-14 gün

QOS (Quality of Service) katmanları ise partition politikalarını kullanıcı veya proje bazında özelleştirmenizi sağlar. Örneğin priority_qos tanımıyla belirli proje gruplarına daha yüksek zamanlama önceliği verilebilir.

Fair-share mekanizması, geçmiş kullanıma dayalı dinamik önceliklendirme sağlar. Çok kaynak tüketen kullanıcıların önceliği düşerken az kullananların önceliği yükselir. slurm.conf içinde PriorityType=priority/multifactor ve uygun PriorityWeightFairshare değeri ayarlanarak etkinleştirilir.

Yaygın Sorunlar ve Çözümleri

İşler Pending Durumunda Takılı Kalıyor

En sık karşılaşılan sorunlardan biridir. squeue -j <job_id> komutuyla görüntülenen REASON sütunu teşhis için birincil kaynaktır:

Resources: Yeterli boş kaynak yok; beklemek gerekiyor
Priority: Daha yüksek öncelikli işler kuyrukta bekliyor
QOSMaxNodePerJobLimit: İş, QOS’ta tanımlı düğüm sınırını aşıyor
ReqNodeNotAvail: Talep edilen belirli düğümler drain veya down durumunda

Düğüm drain/down Durumuna Geçiyor

scontrol show node <node> çıktısındaki Reason alanı genellikle son sistem hatası veya yönetici müdahalesini gösterir. Otomatik drain’e yol açan yaygın sebepler: bellek hatası, ağ kopuklukları ve slurmd’nin yeniden başlatılamaması. scontrol update nodename=<node> state=resume komutuyla düğüm devreye alınabilir; ancak önce altta yatan sorunun giderilmesi şarttır.

MPI İşlerinde Performans Düşüklüğü

Çok düğümlü MPI işlerinde beklentinin altında performans görülüyorsa önce --constraint ile ağ topolojisine uygun düğüm seçimi yapılmalı, ardından srun --mpi=pmix gibi doğru MPI adaptörünün kullanıldığı doğrulanmalıdır.

En İyi Uygulamalar

Kaynak tahsisini gerçekçi tutun. Kullanıcıların ihtiyaçlarından çok daha fazla kaynak talep etmesi, kuyruğun gereğinden uzun süre dolmasına ve küme verimliliğinin düşmesine yol açar. Eğitim ve örnek betiklerle kullanıcıları doğru tahminleme konusunda bilinçlendirmek önemlidir.

Hesap ve muhasebe veritabanını kullanın. slurmdbd entegrasyonu olmadan fair-share çalışmaz ve kapasite planlaması için gerekli kullanım verileri toplanamaz. Kurulum aşamasında muhasebe veritabanını devreye almak sonradan eklemeye göre çok daha kolaydır.

Prometheus + Grafana ile proaktif izleme yapın. prometheus-slurm-exporter eklentisi, kuyruk derinliği, bekleyen iş sayısı ve düğüm kullanım oranı gibi metrikleri Prometheus’a aktarır. Bu metrikler üzerine eşik bazlı uyarılar kurularak sorunlar kullanıcıları etkilemeden önce tespit edilebilir.

Düzenli politika gözden geçirmesi yapın. Küme büyüdükçe ve kullanıcı profili değiştikçe partition sınırları, QOS kuralları ve fair-share ağırlıklarının güncellenmesi gerekir. Üç ayda bir yapılan kullanım analizi, darboğazları ve optimizasyon fırsatlarını ortaya çıkarır.

Sonuç

İş kuyruğu yöneticisi seçimi ve yapılandırması, HPC altyapısının uzun vadeli başarısını doğrudan etkileyen stratejik bir karardır. SLURM açık kaynak esnekliğiyle akademik ve araştırma ortamları için ideal seçenek olurken PBS Pro ve LSF kurumsal destek gereksinimleri olan ortamlarda öne çıkmaktadır.

Bu rehberde ele alınan konular hakkında daha fazla bilgi almak veya kurumunuzun HPC kümesi için profesyonel destek almak isterseniz İş Kuyruğu Yöneticisi Çözümleri sayfamızı inceleyebilir ya da bizimle iletişime geçebilirsiniz.

HPC İş Kuyruğu Yöneticisi Teknik Rehberi: SLURM, PBS Pro ve LSF