SLURM Federation ile Multi-Cluster HPC Yönetimi: Teknik Rehber

Kurumsal HPC altyapıları büyüdükçe tek bir cluster üzerinden tüm iş yüklerini karşılamak hem operasyonel hem de teknik açıdan güçleşir. Farklı donanım mimarileri, coğrafi dağıtık veri merkezleri ve yüksek erişilebilirlik gereksinimleri, birden fazla cluster’ın koordineli biçimde işletilmesini zorunlu kılar. Bu rehberde SLURM Federation’ın nasıl çalıştığını, hangi bileşenlerden oluştuğunu ve yaygın karşılaşılan sorunlarla en iyi uygulamaları ele alıyoruz.

Temel Mimari ve Bileşenler

Multi-cluster yönetiminin özünde Federation katmanı yer alır. Her cluster kendi yerel slurmctld (SLURM kontrolcüsü) sürecini çalıştırmaya devam eder; ancak tüm cluster’lar ortak bir slurmdbd (veritabanı arka plan süreci) üzerinden birbirine bağlanır. Bu yapı sayesinde her cluster bağımsızlığını korurken merkezi bir orkestrasyon mekanizması devreye girer.

Temel bileşenler şunlardır:

• slurmdbd: Tüm muhasebe verilerini, kullanıcı hesaplarını ve iş geçmişini merkezi olarak tutar.
• slurmctld (her cluster için): Yerel kuyrukları ve düğümleri yönetir, federasyon kararlarını uygular.
• Ortak kimlik doğrulama (LDAP/AD): Kullanıcıların tüm cluster’larda aynı kimlik bilgileriyle çalışmasını sağlar.
• Birleşik depolama (opsiyonel): Cluster’lar arası veri erişimi için paylaşımlı dosya sistemi (Lustre, GPFS).

SLURM Federation Kurulumu: Adım Adım

Federation kurmak için önce tüm cluster’ların aynı slurmdbd örneğine bağlı olduğundan emin olun. Ardından aşağıdaki komutları kullanarak cluster’ları federasyona ekleyin:

# Mevcut federation durumunu sorgula
sacctmgr show federation

# Yeni cluster'ı federasyona ekle
sacctmgr add cluster compute2 \
  controlhost=compute2-mgmt \
  controlport=6817

# İki cluster içeren federation oluştur
sacctmgr add federation hpc-fed \
  clusters=compute1,compute2

# Belirli bir cluster'a iş gönder
sbatch --cluster=compute2 job.sh

# Tüm cluster'lardaki işleri listele
squeue --federation

# Federasyon genelinde iş önceliğini sorgula
sprio --federation

Bir kullanıcı iş gönderdiğinde SLURM önce yerel cluster’daki tahmini bekleme süresini hesaplar, ardından diğer cluster’lardaki kapasiteyi değerlendirir ve işi en kısa sürede tamamlanacağı cluster’a yönlendirir. Kullanıcı bu süreci tamamen şeffaf biçimde deneyimler.

İş Yükü Dengeleme Politikaları

Etkili bir multi-cluster stratejisi yalnızca “hangi cluster boşta?” sorusunu yanıtlamaz. Farklı kurumsal ihtiyaçlara göre çeşitli politika türleri uygulanabilir:

• Öncelik tabanlı: Kritik üretim iş yükleri her zaman belirlenmiş birincil cluster’a yönlendirilir.
• En kısa bekleme: İş, tahmini bekleme süresi en düşük olan cluster’a otomatik olarak gider; genel amaçlı kullanım için idealdir.
• Kapasite eşikleme: Bir cluster’ın doluluk oranı tanımlanan eşiği aştığında işler komşu cluster’a taşar; ani yük artışlarını karşılamak için kullanılır.
• Veri yakınlığı: İş, verinin bulunduğu depolama sistemine en yakın cluster’a gönderilir; büyük veri transferlerinden kaynaklanan gecikmeyi en aza indirir.
• Maliyet optimizasyonu: Hibrit bulut ortamlarında en düşük maliyetli kaynak otomatik seçilir; cloud bursting senaryolarında kritik öneme sahiptir.

Merkezi İzleme: Prometheus ve Grafana

Birden fazla cluster’ı ayrı ayrı izlemek operasyonel karmaşıklığı katlar ve körlük noktaları oluşturur. Her cluster’dan toplanan metrikler (düğüm kullanım oranı, kuyruk derinliği, iş tamamlanma süresi, ağ trafiği) merkezi bir Prometheus örneğine aktarılır. Grafana üzerinde hazırlanan birleşik panolar, tüm altyapının anlık durumunu tek ekranda sunar.

Herhangi bir cluster’da düğüm arızası, disk dolması veya kuyruk bekleme süresinin belirlenen eşiği aşması gibi olaylar anında ilgili ekiplere bildirilir. Otomatik iyileştirme akışları (runbook) sayesinde sık karşılaşılan sorunların önemli bir kısmı insan müdahalesi gerektirmeden çözüme kavuşturulur.

Yaygın Sorunlar ve Çözümleri

Saat senkronizasyonu: Tüm cluster node’larında NTP ile saat senkronizasyonu sağlanmazsa federation iletişiminde tutarsızlıklar yaşanır. chronyc tracking ile senkronizasyon durumunu düzenli olarak kontrol edin.

Hesap ve proje senkronizasyonu: slurmdbd üzerindeki kullanıcı ve proje tanımları tüm cluster’larda tutarlı olmalıdır. Hesap değişikliklerini merkezi olarak sacctmgr ile yönetin; manuel müdahaleden kaçının.

Ağ gecikmesi: Cluster’lar arası kontrol trafiği düşük gecikmeli ağ bağlantısı gerektirir. Üretim iş yükü trafiğiyle yönetim trafiğini ayrı ağ arayüzlerine taşıyın.

Geri alma planı eksikliği: Her devreye alma aşamasında geri alma prosedürü hazır olmalıdır. Federation’a eklenen bir cluster’ı geçici olarak devre dışı bırakmak için sacctmgr modify cluster komutunu kullanabilirsiniz.

En İyi Uygulamalar

Kurumsal multi-cluster altyapıları için aşağıdaki uygulamalar operasyonel olgunluğu önemli ölçüde artırır:

1. Aşamalı geçiş: Federasyonu önce test ortamında kurun; üretim geçişini kademeli ve geri alınabilir adımlarla gerçekleştirin.
2. Politika belgeleme: Hangi iş yükünün hangi cluster’a gittiğini ve neden gittiğini yazılı politikalarla kayıt altına alın.
3. Kapasite planlaması: Her cluster’ın maksimum doluluk eşiğini önceden belirleyin; taşma senaryolarını tatbikatla test edin.
4. Güvenlik: Cluster’lar arası iletişimi şifreli kanallar (TLS) üzerinden yürütün; slurmdbd erişimini güvenlik duvarıyla kısıtlayın.
5. Düzenli denetim: Federasyon durumunu, hesap tutarlılığını ve izleme uyarılarını haftalık olarak gözden geçirin.

Sonuç

SLURM Federation tabanlı multi-cluster yönetimi, dağıtık HPC altyapılarını merkezi bir kontrol düzleminde birleştirerek hem operasyonel verimliliği hem de kaynak kullanım oranını anlamlı biçimde artırır. Doğru mimari tasarım, tutarlı politika uygulaması ve merkezi izleme bir arada uygulandığında kurumlar hem planlı bakımlarda hem de beklenmedik arızalarda iş sürekliliğini koruyabilir.

Multi-cluster mimarisi hakkında daha ayrıntılı bilgi almak ve kurumunuza özel bir değerlendirme talep etmek için Çok-Küme Yönetimi çözüm sayfamızı ziyaret edebilir ya da doğrudan iletişim sayfamızdan bizimle iletişime geçebilirsiniz.