HPC Autoscaling: SLURM ile Dinamik Cluster Boyutlandırma

Geleneksel HPC cluster’larında kapasite planlaması büyük bir zorluk oluşturur: ya en yoğun iş yükünü karşılayacak kadar büyük bir cluster kurarsınız ve çoğu zaman boşta bekleyen donanıma para ödersiniz, ya da küçük tutup iş birikimi (job backlog) sorunuyla boğuşursunuz. Bulut tabanlı HPC autoscaling bu ikilemden çıkışı sağlar. SLURM’un yerleşik ölçekleme mekanizmalarını bulut sağlayıcıların API’leriyle birleştirerek cluster, gerçek iş yüküne göre dinamik olarak büyüyüp küçülür.

Bu yazıda SLURM tabanlı autoscaling’in nasıl çalıştığını, AWS ParallelCluster, Azure CycleCloud ve Google Cloud HPC Toolkit ile nasıl hayata geçirildiğini ve dikkat edilmesi gereken operasyonel noktaları ele alacağız.

SLURM Autoscaling’in Temel Mantığı

SLURM, 21.08 sürümünden itibaren slurmctld içinde yerel ölçekleme desteği sunar. Daha önceki sürümlerde yaygın olarak kullanılan slurm-node-provisioner ya da özel prolog/epilog betikleri yerini artık daha sağlam bir mimariye bırakmıştır.

Bileşenler ve Veri Akışı

Autoscaling döngüsü temelde üç adımdan oluşur:

1. İzleme: slurmctld kuyruklardaki bekleyen işleri (PENDING state) izler. Bir iş, mevcut düğümler üzerinde çalışamıyorsa (Reason: Resources) ya da (Reason: ReqNodeNotAvail) durumuna düşer.
2. Tetikleme: SLURM, ResumeProgram olarak tanımlanan betiği çağırır ve hangi düğümlerin açılması gerektiğini bildirir.
3. Geri Çekme: Belirli bir süre (SuspendTime) boşta kalan düğümler için SuspendProgram tetiklenir ve düğüm sonlandırılır.

slurm.conf içindeki ilgili parametreler şunlardır:

# /etc/slurm/slurm.conf - Autoscaling parametreleri

ResumeProgram=/usr/local/bin/slurm_resume
SuspendProgram=/usr/local/bin/slurm_suspend

# Boşta kalan düğümü 300 saniye sonra kapat
SuspendTime=300

# Aynı anda açılabilecek maksimum düğüm sayısı
ResumeRate=10

# Düğümün açılması için bekleme süresi (saniye)
ResumeTimeout=600

# Bekleme süresi içinde açılmazsa hata ver
SuspendExcNodes=login[1-2],storage[1-4]

SuspendExcNodes ile login ve depolama düğümleri gibi her zaman açık kalması gereken sunucular ölçekleme döngüsünün dışında tutulur.

AWS ParallelCluster ile Autoscaling

AWS ParallelCluster, SLURM’un ResumeProgram/SuspendProgram mekanizmasını EC2 API çağrılarıyla otomatik olarak entegre eder. Kullanıcının bu betikleri elle yazmasına gerek yoktur; ParallelCluster’ın slurm_plugin modülü bu görevi üstlenir.

Kuyruk ve Hesaplama Kaynağı Tanımı

# cluster-config.yaml

Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: compute
      ComputeResources:
        - Name: c5n-18xlarge
          InstanceType: c5n.18xlarge
          MinCount: 0
          MaxCount: 50
          Efa:
            Enabled: true
      Networking:
        SubnetIds:
          - subnet-0abc123def456
        PlacementGroup:
            Enabled: true
      ComputeSettings:
        LocalStorage:
          RootVolume:
            Size: 100

    - Name: gpu
      ComputeResources:
        - Name: p4d-24xlarge
          InstanceType: p4d.24xlarge
          MinCount: 0
          MaxCount: 8
      Networking:
        SubnetIds:
          - subnet-0abc123def456

MinCount: 0 ayarı, kuyrukta iş olmadığında tüm hesaplama düğümlerinin kapatılmasına olanak tanır; bu sayede boşta bekleme maliyeti sıfıra iner.

Yerleşim Grupları ve Ağ Gecikmesi

MPI tabanlı paralel iş yüklerinde düğümler arası gecikme kritiktir. PlacementGroup: Enabled: true ile AWS, düğümleri aynı fiziksel raf yakınlığına yerleştirir. EFA (Elastic Fabric Adapter) ile birleştirildiğinde, hız 100 Gbps’e ve gecikme mikrosaniye mertebesine iner.

Ancak yerleşim grupları kapasiteyle ters orantılıdır: küçük bir bölgede 50 adet c5n.18xlarge talep ettiğinizde InsufficientInstanceCapacity hatasıyla karşılaşabilirsiniz. Bu riski azaltmak için birden fazla kuyruğu farklı Availability Zone’larda tanımlamak iyi bir pratiktir.

Azure CycleCloud ile Autoscaling

Azure CycleCloud, kendi orkestrasyon katmanını SLURM ile entegre eden kapsamlı bir HPC yönetim platformudur. CycleCloud’un en güçlü yanlarından biri, Spot/Low-priority sanal makineleri birden fazla boyutta önceliklendirip otomatik olarak geçiş yapabilmesidir.

CycleCloud SLURM Entegrasyonu

CycleCloud, cyclecloud_slurm Python paketini düğüm önyüklemesi sırasında otomatik olarak yükler. Bu paket, SLURM’un ResumeProgram/SuspendProgram çağrılarını yakalayıp CycleCloud REST API’sine iletir.

Cluster şablonunda heterojen VM boyutlarını şu şekilde tanımlayabilirsiniz:

[nodearray compute]
MachineType = Standard_HB120rs_v3, Standard_HB60rs
MaxCoreCount = 2400
Interruptible = false
AdditionalClusterInitSpecs = $ClusterInitSpecs

[nodearray compute-spot]
MachineType = Standard_HB120rs_v3, Standard_HB60rs
MaxCoreCount = 4800
Interruptible = true
SpotMaxPrice = 0.5

Interruptible = true ile Azure Spot VM’ler devreye girer. Spot fiyatı SpotMaxPrice değerini aştığında CycleCloud, on-demand havuzuna otomatik olarak geçer. Maliyet ile süreklilik arasındaki bu dengeyi SLURM kuyruklarına yansıtmak için:

# Spot kuyruğuna job gönderimi
sbatch --partition=compute-spot --nodes=16 mpi_job.sh

# Spot kesintisine toleranslı olmayan kritik işler için
sbatch --partition=compute --nodes=16 critical_job.sh

Google Cloud HPC Toolkit ile Autoscaling

Google Cloud HPC Toolkit (eski adıyla ghpc), SLURM cluster’ını Terraform blueprint’leri üzerinden tanımlar. Autoscaling, SLURM ile gcloud CLI’nin entegrasyonuyla sağlanır.

Blueprint Örneği

# hpc-cluster.yaml

vars:
  project_id: my-hpc-project
  region: us-central1
  zone: us-central1-c

deployment_groups:
  - group: primary
    modules:
      - id: hpc-network
        source: modules/network/vpc

      - id: slurm-cluster
        source: community/modules/scheduler/schedmd-slurm-gcp-v6-controller
        use: [hpc-network]
        settings:
          machine_type: n2-standard-8
          partition:
            - name: compute
              machine_type: c2-standard-60
              node_count_dynamic_max: 100
              node_count_static: 0
              bandwidth_tier: gvnic_enabled
            - name: highmem
              machine_type: m2-megamem-416
              node_count_dynamic_max: 10
              node_count_static: 0

node_count_static: 0 ile tüm hesaplama kapasitesi dinamik hale getirilir. node_count_dynamic_max ise her kuyruk için üst sınırı belirler; bu sayede bütçe aşımlarının önüne geçilir.

Karşılaştırma: Üç Platform

Operasyonel Dikkat Noktaları

Soğuk Başlatma Gecikmesi

Bir düğümün EC2, Azure VM ya da GCE instance olarak başlatılıp SLURM’a kayıt yaptırması tipik olarak 3-8 dakika sürer. Bu süre; VM türüne, önyükleme scriptlerinin karmaşıklığına ve AMI/image boyutuna bağlı olarak değişir. Uzun bekleme süreleri iş sırası performansını olumsuz etkiler.

Gecikmelerle başa çıkmanın başlıca yöntemleri:

• Önceden hazırlanmış image: Tüm HPC yazılımlarını içeren özel AMI/image oluşturun; önyükleme süresini 2-3 dakikaya indirin.
• Warm pool (AWS): Birkaç düğümü durdurulmuş (stopped) ama başlatılmaya hazır halde tutun.
• Küçük statik çekirdek: node_count_static: 2 gibi minimal bir statik taban belirleyerek küçük işlerin anında çalışmasını sağlayın.

Maliyet Kontrolü

Autoscaling maliyet tasarrufu sağlar, ancak yanlış yapılandırılmış SuspendTime değerleri veya iş döngüsü hataları (“spinning jobs”) faturanızı beklenmedik biçimde artırabilir.

sacct ile iş maliyetlerini izlemek için basit bir örnek:

# Son 24 saatteki iş maliyeti özeti
sacct -a --starttime=$(date -d '1 day ago' +%Y-%m-%dT%H:%M:%S) \
  --format=JobID,JobName,Partition,NNodes,CPUTimeRAW,State \
  --noheader | awk '{cpu_sum += $5} END {print "Toplam CPU-saat:", cpu_sum/3600}'

Bütçe uyarıları için bulut sağlayıcının yerel araçlarını (AWS Budgets, Azure Cost Alerts, GCP Budget Alerts) mutlaka etkinleştirin ve aylık eşiklere alarm kurun.

Düğüm Sağlık Kontrolü

Hatalı başlayan bir düğüm SLURM kuyruğunu kilitleyebilir. ResumeTimeout süresi dolduğunda SLURM düğümü DOWN durumuna alır, ancak bulut tarafında VM hâlâ çalışmaya devam edebilir. Bu kaynak israfına yol açar.

Düğüm sağlık kontrolü için prolog scriptine basit bir doğrulama eklemek iyi bir uygulamadır:

#!/bin/bash
# /usr/local/sbin/slurm_prolog.sh

# Shared filesystem bağlantısını kontrol et
if ! mountpoint -q /scratch; then
  logger "SLURM prolog: /scratch bağlantısı yok, düğüm reddediliyor"
  exit 1
fi

# GPU düğümlerde CUDA sürücü kontrolü
if [[ "${SLURM_JOB_PARTITION}" == "gpu" ]]; then
  if ! nvidia-smi > /dev/null 2>&1; then
    logger "SLURM prolog: GPU erişim hatası"
    exit 1
  fi
fi

Sonuç

SLURM autoscaling, HPC altyapısında hem maliyet verimliliği hem de esneklik açısından ciddi avantajlar sunar. AWS ParallelCluster daha basit bir kurulum deneyimi ve AWS ekosistemine sıkı entegrasyon sunarken, Azure CycleCloud GUI tabanlı yönetim ve kapsamlı kota yönetimiyle ön plana çıkar. Google Cloud HPC Toolkit ise Terraform tabanlı altyapı-kod yaklaşımıyla DevOps ekiplerine tanıdık bir deneyim sunar.

Hangi platformu seçerseniz seçin, soğuk başlatma gecikmesi, maliyet kontrolü ve düğüm sağlık izleme, autoscaling’in başarısını belirleyen üç temel operasyonel unsurdur.

Mevasis olarak HPC autoscaling mimarisinin tasarımı, kurulumu ve optimizasyonu konusunda size destek olmaktan memnuniyet duyarız. İletişim için formu doldurun.